EU AI Act compliance: what your AI system has to do, by risk tier
The EU AI Act is risk-tiered. This guide helps you classify your AI use and maps the transparency, documentation, oversight, and logging duties that follow.
6 min readStallwart
The one-line answer
The EU AI Act assigns each AI use to a risk tier, and your obligations follow the tier: most business uses land in limited or minimal risk with light or no transparency duties, while high-risk uses carry documentation, human oversight, logging, and quality-management obligations. Your first compliance task is classification, because the tier decides everything after it.
This is practical guidance, not legal advice. The Act's definitions and timelines are detailed and its guidance is still maturing, so treat what follows as a map for classifying your own systems and scoping the work, and confirm specifics with counsel for your situation.
The four tiers, plainly
The Act sorts AI into four buckets by the risk it poses, plus a separate track for general-purpose AI models. Getting your systems into the right bucket is the whole game, because the duties are wildly different across them.
- Unacceptable risk: a short list of prohibited practices, such as social scoring by public authorities and certain manipulative or exploitative uses. These are banned outright, not permitted-with-controls.
- High risk: AI used as a safety component of regulated products, or in listed sensitive areas such as employment, education, essential services, credit, and certain biometric and critical-infrastructure uses. This tier carries the heavy obligations.
- Limited risk: systems that interact with people or generate content, such as chatbots and synthetic media. The duty here is mainly transparency: tell people they are dealing with AI or that content is AI-generated.
- Minimal risk: everything else, the large majority of business AI, such as spam filters and recommendation features. No specific obligations beyond the law that already applies to you.
- General-purpose AI models: a parallel track with its own transparency and documentation duties for model providers, and additional obligations where a model carries systemic risk.
How to classify your own use
Classification is not a one-time judgment call; it is a per-system determination you should be able to defend in writing. Start from the use, not the technology. The same model can be minimal risk in one product and high risk in another, because the tier is about what the system does and to whom.
Work through it in order. First, is the use on the prohibited list? If so, stop; you do not deploy it. Second, is it a safety component of a regulated product, or does it fall in one of the listed high-risk areas such as hiring, credit, or access to essential services? If yes, plan for the high-risk obligations. Third, does it interact with people or generate content? If yes, you owe the transparency duties even if nothing else applies. If none of these fit, it is likely minimal risk, and you record why.
The recurring mistake is classifying by vibe rather than by use. A resume-screening feature is not low risk because it feels like a small convenience; screening for employment is a listed high-risk area. Write the classification and its reasoning down for each system. That written basis is both good practice and the thing a regulator or customer will ask you to produce.
What high-risk actually requires
If a system lands in the high-risk tier, the obligations are concrete and they are mostly about evidence and control rather than about the model's accuracy in the abstract. In broad strokes, a provider of a high-risk system is expected to operate a risk-management process across the lifecycle, apply data-governance practices to training and input data, maintain technical documentation, keep automatic logs of the system's operation, ensure meaningful human oversight, and hit thresholds for accuracy, robustness, and security. Deployers, the organizations using the system, carry their own duties, including using it per instructions and maintaining oversight.
Read that list again and notice what it is: an inventory of what your AI is and does, a written basis for the decisions behind it, runtime controls including human oversight, logs that record operation continuously, and a path to intervene or roll back when something goes wrong. These are operational capabilities, not documents you can backfill convincingly after the fact.
Two duties deserve emphasis because teams underestimate them. Logging is not optional telemetry; the system must record its operation in a way that supports traceability. And human oversight must be real, meaning a person who can understand the output, override it, and stop the system, not a nominal reviewer who rubber-stamps. Building these in from the start is far cheaper than retrofitting them under a deadline.
Making the obligations a byproduct of the system
The AI Act rewards the same posture that ISO 42001 does: governance that falls out of the system running, rather than a scramble before a review. For a high-risk system, that means the model inventory is live rather than a spreadsheet, the reasoning behind consequential decisions is captured as decisions are made, human oversight and runtime controls leave records as they operate, logs accumulate continuously, and rollback is a tested path. When those are in place, producing your technical documentation or answering a deployer's due-diligence question is a read of state you already hold.
This is where Stallwart works. We do not interpret the law for you and we do not certify or attest that you comply; conformity for high-risk systems runs through the Act's own assessment routes, and legal judgment belongs with your counsel. What we build is the substrate the obligations rest on: the live inventory, the written basis for decisions, the runtime controls and human oversight, and the continuous evidence trail. When the transparency notice, the documentation, or the log export is asked for, it already exists.
The short version
- The EU AI Act is risk-tiered; classify each use first, because the tier determines every obligation that follows.
- Most business AI is limited or minimal risk with light transparency duties or none; the heavy obligations attach to the high-risk tier.
- High-risk duties are operational: risk management, data governance, documentation, continuous logging, meaningful human oversight, and a tested rollback path.
- Stallwart does not interpret the law or attest compliance; it builds the inventory, written basis, controls, and evidence trail the obligations rest on.
Questions this raises
- Is my AI system high risk under the EU AI Act?
- It is high risk if it is a safety component of a regulated product or falls in a listed sensitive area such as employment, credit, education, essential services, or certain biometric and critical-infrastructure uses. Classify by what the system does and to whom, not by the technology, and write the reasoning down per system.
- What are the obligations for a limited-risk AI system?
- Mainly transparency. If your system interacts with people or generates content, you generally must make clear that people are dealing with AI or that content is AI-generated. There are no high-risk-style documentation or oversight duties, but the disclosure duty still applies.
- What does a high-risk system have to do?
- In broad terms: run a lifecycle risk-management process, apply data governance, keep technical documentation, maintain automatic operation logs, ensure meaningful human oversight, and meet accuracy, robustness, and security thresholds. Deployers who use the system carry their own oversight and usage duties.
- Does the EU AI Act apply to companies outside the EU?
- It can. The Act reaches AI placed on the EU market or whose output is used in the EU, so providers and deployers outside the EU can fall within scope. Whether it applies to you is a legal question to confirm with counsel; this guide helps you scope the work, not decide jurisdiction.
- Does Stallwart make us compliant with the EU AI Act?
- No. Stallwart does not interpret the law, certify, or attest compliance, and conformity for high-risk systems runs through the Act's own routes with your counsel. We build the live inventory, written basis for decisions, runtime controls, human oversight, and continuous evidence trail the obligations rest on, so the documentation and logs an assessment asks for already exist.
Recognize this in your own operation?
Bring us the version of it happening in your business and we will tell you which part a system can take over.
Book a call