The EU AI Act, for people who build the product.
A plain-language, designer-first read on Regulation (EU) 2024/1689: how the risk tiers work, the articles and dates that matter, and the interface patterns behind the common obligations — so you can design for it from the start.
The risk check opens the Future of Life Institute’s EU AI Act Compliance Checker — an external tool.
- Prohibited: unacceptable risk
- High-risk
- Limited risk: transparency duties
- Minimal risk
Educational information only. This guide explains how the EU AI Act is structured. It is not legal advice and does not classify or certify any specific product. For decisions that carry legal weight, consult qualified counsel.
Four tiers, from banned to barely touched.
The Act scales its demands to the risk a system poses. Here’s what each tier means in general — the examples are illustrative, not a ruling on any particular product.
Prohibited: unacceptable risk
This practice is banned under Article 5. It must not be developed or deployed in the EU.
For example: A public surveillance system doing real-time facial recognition on city streets to track people and alert police.
High-risk
Permitted, but subject to the Act's most demanding obligations before and after it goes to market.
For example: An AI in an autonomous vehicle that decides when to brake or change lanes, a safety-critical component.
Limited risk: transparency duties
Allowed, with specific disclosure duties so people know when they're dealing with AI.
For example: A customer-service chatbot answering product questions. It must tell users it isn't human.
Minimal risk
No mandatory obligations under the Act. Voluntary codes of conduct are encouraged.
For example: An indoor positioning system tracking equipment for logistics. It makes no autonomous decisions and doesn't affect anyone's rights.
Wondering where your system sits?Don’t take a verdict from a web page — work through an established self-assessment and confirm anything that matters with counsel.
Open the EU AI Act Compliance Checker →The interface patterns behind the obligations
Several obligations are, in practice, design problems — human oversight, disclosure, and record-keeping all show up in the UI. These are common patterns teams reach for. They’re design guidance, not a guarantee of compliance.
Human oversight & intervention
Supports Article 14 (human oversight)
Give a person a real, timely way to understand, question, and override what the AI is doing — before the consequence lands.
- Clear override / “take over” controls and a visible stop or pause
- Confidence or uncertainty shown alongside every recommendation
- Escalation to a human at defined thresholds, with the state made obvious
Watch out: An override that only arrives after the action executed isn't oversight. Put the decision in front of the human while it still matters.
Transparency & disclosure
Supports Articles 50 & 13 (transparency, instructions)
Make it unmistakable when someone is dealing with AI — and honest about what it can and can't do.
- “You're talking to AI” indicators and labelled AI-generated content
- Plain-language notes on purpose, limitations, and known failure modes
- In-context explanations for a recommendation or automated decision
Watch out: A disclosure buried in the footer, or shown once at onboarding, doesn't land. Keep it present at the moment of the interaction.
Logging & auditability
Supports Article 12 (record-keeping)
Design the surfaces that let a team see what the system did — and prove it later.
- Admin views of AI decisions, inputs, and human feedback over time
- Exportable event logs tied to specific outputs
- A place to attach evidence — the PR, the design file, the policy
Watch out: Logs no one can read or export aren't evidence. Design the review surface, not just the database table.
Key articles
Straight to the official text.
- Article 2: Scope↗
- Article 3: Definitions↗
- Article 5: Prohibited practices↗
- Article 6: Classification rules for high-risk↗
- Annex I: Union harmonisation legislation↗
- Annex III: High-risk use cases↗
- Article 50: Transparency obligations↗
- Article 51: General-purpose AI models↗
- Article 2: Open-source exemptions↗
- Article 25: Responsibilities along the value chain↗
- Article 27: Fundamental Rights Impact Assessment↗
- Article 60: Real-world testing↗
When it applies
The Act phases in. The dates that tend to matter most:
- 2 Feb 2025Prohibited-practice ban and AI-literacy duties apply.
- 2 Aug 2025General-purpose AI model obligations and governance apply.
- 2 Aug 2026Most obligations apply, including Annex III high-risk systems.
- 2 Aug 2027High-risk obligations for Annex I regulated products apply.
A discovery checklist for AI teams
Questions worth asking in discovery or sprint planning — to surface the right considerations early. It’s a prompt for your team’s own thinking, not an assessment.
Scope & role
- Is what we're building an “AI system” as the Act defines it, and does it reach EU users?
- Are we the provider (we build/put it on the market) or the deployer (we use it)? Could we be both?
Risk & rights
- Does any part touch a prohibited practice, or a high-risk use case in Annex III?
- Who could be affected if the system is wrong, and how would they notice or push back?
Design surfaces
- Where does a human stay in the loop — and can they actually override in time?
- How do we disclose that this is AI, and surface its confidence and limits?
- What do we log, and who can review those decisions afterwards?
Design for it early, and it stops being a scramble.
The obligations that feel like a legal tax are mostly good product hygiene: oversight, honesty about what the AI does, and a record of its decisions. Build those in, and the rest is paperwork.
Educational information only. This guide explains how the EU AI Act is structured. It is not legal advice and does not classify or certify any specific product. For decisions that carry legal weight, consult qualified counsel.