What the EU AI Act actually requires, in plain language

Not "is this AI," but "which category does this specific use case fall into."

A short list: social scoring by governments, real-time biometric identification in public spaces (with narrow law-enforcement exceptions), systems designed to manipulate behavior in ways that cause harm, and a few others. Almost no ordinary business use case lands here. If you're building a support assistant, a growth engine, or an internal tool, this tier isn't the one to worry about.

This covers AI used in specific contexts the regulation treats as consequential: employment decisions (screening candidates, evaluating performance), credit scoring, insurance pricing, critical infrastructure management, and a defined list of others. If your system falls here, the obligations are substantial: a documented risk management system maintained across the system's lifecycle, data governance practices covering training data quality and bias testing, technical documentation detailed enough for a regulator to audit, logging sufficient to reconstruct how a decision was made, human oversight designed into the system rather than bolted on, and a conformity assessment before the system goes to market. This is comparable in scope to a medical device or financial-services compliance program — not a checkbox.

Chatbots, AI-generated content, emotion-recognition systems, and similar — the core obligation is transparency. A user interacting with an AI system has to be able to tell that it's AI, unless it's obvious from context. This is the tier a support assistant, a marketing chatbot, or an AI-written article usually lands in, and the compliance bar is genuinely lower: disclose that it's AI, keep that disclosure clear and not buried, and you're largely there.

Spam filters, recommendation engines in a low-stakes context, and similar tools carry no specific obligations under the Act, though general product-safety and consumer-protection law still applies as it always did.

General-purpose AI models carry their own separate obligations, layered on top of whatever tier the application built on them falls into. Providers of general-purpose models — the underlying foundation models, not the applications built with them — have documentation and transparency requirements, and models above a defined computing-power threshold (deemed to carry "systemic risk") face additional obligations around risk assessment and incident reporting. If you're building on top of a major provider's API, most of this obligation sits with the model provider, not with you — but it's worth confirming that in writing as part of vendor due diligence, not assuming it.

The Act entered into force on 1 August 2024. Prohibited-practice bans took effect first, on 2 February 2025. General-purpose AI model obligations followed on 2 August 2025. High-risk system obligations were originally set for 2 August 2026, but a targeted amendment — the Digital Omnibus on AI, Regulation (EU) 2026/1744, which entered into force on 27 July 2026 — pushed that back: standalone high-risk systems under Annex III (employment, credit, law enforcement, and the rest of that list) now have until 2 December 2027, and high-risk AI embedded in regulated products under Annex I (medical devices, machinery, vehicles) until 2 August 2028. The four-tier structure and the prohibited-practices list weren't touched — this was a timing and compliance-burden change, not a rewrite of what counts as high-risk. If you're planning a system now, the honest approach is still to build as though the obligations are live, because a system designed without a risk-management process from the start is expensive to retrofit one onto later, and a regulator's clock resetting once doesn't mean it won't move again before your system ships. (Regulation (EU) 2024/1689, Article 113, as amended by Regulation (EU) 2026/1744; see EUR-Lex, OJ L, 24.7.2026.)

figure out the tier before you scope the system, not after. A credit-scoring feature and a support chatbot are both "AI," and one of them needs a conformity assessment while the other needs a disclosure line in the UI. Getting the tier wrong early is the expensive mistake — not because the compliance work itself is unreasonable, but because a high-risk system designed without the risk-management and logging requirements in mind from day one usually needs real architectural changes to retrofit them, not just a documentation exercise at the end.

treating "we use AI somewhere in the process" as the trigger for high-risk obligations, when the actual trigger is the specific use case the AI is applied to. A company using a language model to draft internal meeting summaries and a company using one to screen job applicants are both "using AI," but only one of them is anywhere near the high-risk tier. Conflating the two either produces unnecessary compliance overhead on a low-stakes tool, or — more dangerously — a false sense that because the internal tool was fine, the hiring tool must be too.

Before scoping a new AI system, we walk through four questions with a client, in this order:

• What specific decision or output does this system produce, and who or what does that decision affect?
• Does that decision or output fall into one of the Act's named high-risk categories — employment, credit, insurance pricing, critical infrastructure, law enforcement, and a short list of others?
• If it's customer-facing and not high-risk, does a user need to be told they're interacting with AI?
• If we're building on a third-party model, what does that provider's own documentation say about their obligations, and is that written down anywhere we can point to later?

That order matters. Skipping straight to "what does the Act require of AI systems in general" produces a generic checklist nobody actually applies correctly. Starting from the specific decision the system makes gets you to the right tier in one pass.