by ClauseGuard (LX AI)
Obligations follow risk tier. ClauseGuard drafts a classification and gap list from your system description.
Not legal advice — counsel still owns the filing.
When you ship a feature that uses AI, the EU AI Act looks at the risk the system poses to health, safety, or fundamental rights. The regulation splits AI into four tiers: unacceptable, high, limited, and minimal. Each tier triggers a different set of legal duties. If you mis‑classify, you may either over‑invest in controls that are not required or, worse, ship a product that violates the law and faces fines or market bans. I built ClauseGuard to turn a plain text description of your software into a first‑pass tier label and a list of gaps you must close before launch. The tool reads your description, checks it against the annexes of the Act, and returns a tier together with a checklist of items such as documentation, testing, and monitoring that the law expects. In the sections below I walk through the exact steps we use, show the table of obligations per tier, and share the common mistakes we see in early‑stage SaaS teams.
We ask the product lead to write a short narrative that covers three points: the core function of the AI component, the data it consumes and produces, and the intended users or affected persons. The narrative does not need to be technical; a plain English paragraph works fine. We store this text as the seed for the next steps. Because the Act focuses on the purpose and context, we keep the description free of implementation details such as programming language or cloud provider, which could distract the classifier.
The Act’s annexes list specific AI practices that are considered high risk, such as biometric identification, critical infrastructure management, or employment screening. We tokenize the description and look for keywords that match those annex entries. For example, if the text mentions “face recognition” or “employee performance scoring”, we flag a potential high‑risk match. We also check for limited‑risk triggers like chatbots that interact with consumers or emotion‑recognition systems. This step produces a provisional tier based on the strongest match found.
If any annex entry for unacceptable risk is found (e.g., social scoring, real‑time remote biometric identification in public spaces), we label the system as unacceptable and stop further processing because the Act prohibits such AI. If no unacceptable match appears but at least one high‑risk annex entry is present, we set the tier to high. When only limited‑risk entries appear, we set the tier to limited. If no annex entry matches at all, we default to minimal. This rule‑based approach gives a transparent first output that a lawyer can later review.
Once the tier is set, we generate a checklist of obligations that correspond to that tier. For high risk the list includes items such as risk management system, data governance documentation, technical documentation, logging, transparency information, human oversight measures, conformity assessment, and post‑market monitoring. For limited risk the list focuses on transparency obligations like informing users that they are interacting with AI. For minimal risk the list is empty, but we still recommend basic security hygiene. The gap check compares your current artifacts (e.g., existing data sheets, test reports) against each checklist item and marks any missing pieces.
| Risk tier | Typical AI examples | Key obligations under the Act |
|---|---|---|
| Unacceptable | Social scoring, real‑time remote biometric identification in public spaces, manipulative AI that exploits vulnerabilities | Prohibited; no placement on the market allowed |
| High | Biometric access control, critical infrastructure AI, recruitment tools, medical device software, credit scoring | Risk management system, data governance, technical documentation, logging, transparency, human oversight, conformity assessment (CE marking), post‑market monitoring, incident reporting |
| Limited | Chatbots, emotion recognition, deep‑fake generators, AI‑based video games with adaptive difficulty | Transparency obligation: inform users they are interacting with AI; provide clear notice before interaction |
| Minimal | Spam filters, recommendation engines for e‑commerce, AI‑assisted spelling correction | No specific AI Act obligations; general product safety and data protection rules still apply |
Many teams treat a large language model as a generic tool and assume it falls into minimal risk because the model itself is not tied to a specific use case. The Act, however, looks at the intended purpose. If you embed the model in a feature that generates legal advice or financial recommendations, the system may be classified as high risk. We advise product leads to describe the exact output use, not just the underlying model, when filling out the system description.
For limited‑risk AI the law requires a clear notice that the user is interacting with an AI system. Some teams place the notice in a lengthy terms‑of‑service document or hide it behind a tooltip. The guidance from the Commission expects the notice to be presented at the moment of interaction, in plain language, and with sufficient contrast to be easily noticed. We have seen cases where a missing or unclear notice led to a finding of non‑compliance during an audit.
High‑risk AI demands a plan for monitoring performance after release, including logging of inputs and outputs, periodic testing for drift, and a process to report serious incidents. Early‑stage teams often focus on pre‑launch validation and forget to build the logging pipeline. The Act expects the monitoring plan to be part of the technical documentation and to be updated at least annually. We recommend integrating the logging step into your CI/CD pipeline so that each deployment automatically adds a log entry to a secure store.
This guide does not give a legal guarantee that any classification produced by ClauseGuard will be accepted by a regulator. The tool provides a first‑pass view based on the text you supply; it does not replace a formal legal analysis. It does not promise 100 % coverage of every possible AI scenario, nor does it claim that following the checklist will never miss an obligation. The output is meant to inform your internal review and to help you prepare questions for counsel. Always involve a qualified lawyer before submitting any conformity assessment or filing with a national authority.
We subscribe to the Official Journal of the European Union and watch for amendments to the AI Act. When a new delegated act or implementing regulation appears, we review the changes and adjust our keyword lists accordingly. For example, the recent update on generative AI transparency added new phrases that we now check for in the system description.
We follow trusted sources such as the OWASP LLM Risk page (https://genai.owasp.org/llmrisk/llm01-prompt-injection) and the NIST AI Risk Management Framework (https://www.nist.gov/itl/ai-risk-management-framework) to capture emerging threat models and best practices. When those sources highlight a new risk pattern, we add corresponding triggers to our mapping step.
Every three months we run a internal review where a product lead, a security engineer, and a legal consultant classify a set of sample features using the current classifier. We compare the results to the expectations from the latest guidance and log any mismatches. Those mismatches drive updates to the rule set or to the documentation examples we provide to users.
I keep a written checklist next to every release that touches this topic. The list is boring on purpose: name the owner, name the evidence artifact, and name the rollback. If a step cannot produce a file, a ticket, or a log line, it is not a step — it is a wish.
| Signal | What to record | Stop-ship? |
|---|---|---|
| Unexpected write or send | Tool name, args, identity | Yes until gated |
| Missing confirmation on destructive action | Call path and bypass | Yes |
| Untrusted text treated as instruction | Source surface and resulting action | Yes for agent reach |
| Scanner clean, judgment open | Deferred items + owner | Only if core path safe |
clauseguard helps with the measurable first pass. Architecture choices, legal sign-off, and customer-facing claims still need a human owner. Treat every checklist row as decision support, not a certificate.
When a prospect asks whether the product "covers everything," I answer with the boundary: automated checks catch known patterns; novel chains and policy judgment still need review. That honesty keeps support load down and keeps the blog aligned with what the product actually does.
If you need a second opinion, pair this write-up with the references below and with your own staging reproduction. Do not skip the reproduction step just because a model wrote a confident summary.
Obligations follow risk tier. ClauseGuard drafts a classification and gap list from your system description.
Not legal advice — counsel still owns the filing.
Want to try the product? ClauseGuard
Generated 2026-09-17 · primary sources only · no fabricated traffic metrics