EU AI Act risk-tier primer for SaaS product leads

Why risk tier matters for SaaS

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.

Our classification workflow

Step 1: Capture system description

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.

Step 2: Map features to AI Act annexes

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.

Step 3: Assign preliminary tier

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.

Step 4: Run gap check

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.

Tier breakdown and obligations

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

Common pitfalls we see

Overlooking general purpose AI

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.

Misreading transparency obligations

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.

Ignoring post‑market monitoring

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.

What this is NOT

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.

How we keep the classifier up to date

Monitoring official updates

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.

Integrating community feeds

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.

Quarterly internal audit

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.

Operator checklist for EU AI Act risk-tier primer for SaaS product leads

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.

Before you change production

- Freeze the branch or config revision you will measure against. - Record the current failure mode with one concrete input and one concrete output. - Confirm which identity the job runs as, and whether that identity can reach data it should not. - Open the primary references you will cite: https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age_en, https://genai.owasp.org/llmrisk/llm01-prompt-injection.

While you run the check

- Prefer one reproducible path over ten anecdotal screenshots. - Write the expected safe outcome before you trigger the tool or query. - Capture the exact command, prompt, schema, or regex under test — not a paraphrase. - If the system can act (send, write, delete, transfer), require a confirmation boundary in the same pass.

After you finish

- File residual risk with an owner and a date, even when the scan is clean. - Do not convert a green check into sales language that claims completeness. - Re-run the same checklist when the model, tool schema, or validation rules change.

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.

How I explain limits to buyers

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.

References

- https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age_en - https://genai.owasp.org/llmrisk/llm01-prompt-injection - https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene - https://www.nist.gov/itl/ai-risk-management-framework