The EU AI Act is the first comprehensive, binding law that regulates artificial intelligence by how risky it is rather than by what industry uses it. It entered into force on 1 August 2024 and phases in over four years. If your organization builds, sells, or simply uses AI that touches people in the European Union, the Act almost certainly reaches you, and it does so with fines that can exceed those under the GDPR.
This guide explains the whole structure in plain terms: what the law does and why it exists, who counts as a provider versus a deployer, the four risk tiers with concrete examples, the full compliance timeline as it stands in mid-2026, the specific obligations high-risk systems carry, the rules for general-purpose AI models, the penalty regime, and a practical sequence for getting ready. It is written for compliance, risk, legal, and AI leaders who need an accurate picture, not a summary that glosses over the parts that cost money.
What the EU AI Act Is and Why It Exists
Regulation (EU) 2024/1689, known as the AI Act, is a single law that applies across all 27 member states. It regulates AI systems by risk category, from outright bans to light-touch transparency, rather than writing separate rules for each sector.
The core idea is proportionality. A spam filter and a system that decides who gets a mortgage are both AI, but they carry very different consequences when they fail. The Act mirrors that difference. Some uses are banned because the risk to fundamental rights is judged unacceptable. A defined set of high-stakes uses is allowed but heavily regulated. A middle band carries transparency duties only. Everything else is essentially unregulated by the Act. This structure means the obligations you face depend on what your system does and to whom, not on whether you call it AI.
Why write it at all? Three pressures converged. First, AI decisions were already affecting hiring, credit, policing, and healthcare with little accountability and few ways for affected people to contest an outcome. Second, member states were starting to draft their own AI rules, which threatened to fragment the single market. A common EU framework prevents 27 conflicting regimes. Third, the EU wanted to set a global reference point the way the GDPR did for privacy, exporting its standard through the practical reality that firms build to the strictest market they serve.
One clarification that saves a lot of confusion: the Act regulates uses and systems, not the underlying technology in the abstract. The same large language model can be minimal risk in one deployment (drafting internal marketing copy) and high risk in another (screening job applicants). Classification follows the application.
Who It Applies To: Providers, Deployers, and Reach Beyond the EU
Two roles carry most of the obligations, and they carry different ones. Knowing which role you occupy for each system is the first practical step, because the same company is often a provider of some systems and a deployer of others.
| Role | Definition | Core Obligations |
|---|---|---|
| Provider | Develops an AI system or has one developed and places it on the EU market or puts it into service under its own name or trademark | Carries the heaviest load: risk management, technical documentation, conformity assessment, registration, post-market monitoring |
| Deployer | Uses an AI system under its own authority in a professional capacity (an employer, a bank, a hospital using a bought tool) | Use the system per instructions, ensure human oversight, monitor operation, keep logs, inform affected people where required |
The line matters because it determines who does what. A vendor that builds a CV-screening tool is the provider and owns the conformity assessment and documentation. The bank that buys and runs it is the deployer and owns human oversight, monitoring, and, in many cases, telling candidates the tool is being used. There is a trap here: if a deployer substantially modifies a high-risk system, or puts its own name on it, or uses it for a purpose the provider did not intend, the deployer can legally become a provider and inherit the full provider obligations. Rebadging a third-party model as your own is the fastest way to acquire responsibilities you did not plan for.
Extraterritorial Reach
The Act does not stop at the EU border. Like the GDPR, it applies based on where the effect lands, not where the company sits. Three triggers pull a non-EU organization into scope:
- Placing a system on the EU market. Selling or otherwise making an AI system available in the EU, wherever you are based, brings it within scope.
- Being established in the EU as a deployer. An EU subsidiary or office using AI in its operations is covered directly.
- Output used in the EU. This is the broad one. If a provider or deployer is outside the EU but the output of the AI system is used inside the EU, the Act can apply. A US firm scoring EU-based job applicants, or generating content consumed by EU users, is reachable.
The practical read for global firms. If you have EU customers, EU employees, or EU users whose data or decisions flow through your AI, assume you are in scope until a documented analysis says otherwise. Most enterprises with any European footprint will find at least some systems captured.
The Four Risk Tiers
Everything in the Act flows from this classification. Your obligations, deadlines, and exposure all depend on which tier a given system falls into. Get the tiering right and the rest of compliance becomes a defined task list.
| Tier | Status | What Applies | Concrete Examples |
|---|---|---|---|
| Unacceptable | Prohibited | Banned since 2 Feb 2025. No compliance route exists; these uses are simply illegal. | Government social scoring, manipulative or exploitative systems, untargeted facial-recognition scraping, most real-time remote biometric identification in public, emotion recognition at work or school |
| High | Heavily regulated | Permitted but subject to the full obligation set: risk management, data governance, documentation, human oversight, conformity assessment. | CV screening and hiring, credit scoring, insurance pricing, medical devices, critical infrastructure, education admissions and grading, law enforcement and migration tools |
| Limited | Transparency | Transparency duties under Article 50: tell people they are interacting with AI or viewing synthetic content. | Chatbots and virtual assistants, deepfakes, AI-generated images, audio, video, and text intended to inform the public |
| Minimal | Unrestricted | No mandatory obligations under the Act. Voluntary codes of conduct are encouraged. | Spam filters, AI in video games, inventory optimization, most recommender systems, basic productivity features |
Two points trip people up. First, the vast majority of AI in ordinary business use is minimal or limited risk, not high risk. High-risk classification is reserved for the specific use cases listed in Annex III (the standalone list, such as hiring and credit) and Annex I (AI embedded as a safety component in already-regulated products, such as medical devices and machinery). If your system is not on those lists and is not prohibited, it is very likely minimal or limited risk.
Second, general-purpose AI models (the large foundation models behind many products) sit on a separate track with their own rules, covered in Section 06. A GPAI model is not automatically high risk. It is regulated as a model, and the product built on top of it is classified on its own merits.
The classification is the compliance project. Most of the cost and risk in an AI Act program comes from getting tiering wrong: either missing a high-risk system entirely, or gold-plating a minimal-risk tool with controls it never needed. An accurate, documented, and maintained inventory is the foundation everything else rests on.
The Compliance Timeline
The Act does not switch on all at once. Obligations phase in over four years, and the dates were amended in 2026. Treat the schedule below as the plan of record and work backward from the deadline that hits your systems first.
Prohibitions and AI literacy. The banned practices in Article 5 became illegal. Article 4 also requires providers and deployers to ensure staff who work with AI have an adequate level of AI literacy. This duty is live now and applies to almost every organization using AI.
GPAI obligations and penalty powers. Rules for general-purpose AI models took effect, governance bodies (the AI Office and national authorities) became operational, and the penalty provisions of Article 99 became applicable.
Article 50 transparency. Transparency duties for limited-risk systems apply: disclosure for chatbots, and marking and labelling of AI-generated or manipulated content. These were not deferred by the 2026 amendments.
New prohibitions and a marking grace period. A prohibition on AI-generated child sexual abuse material and non-consensual intimate imagery takes effect. Generative systems already on the market get until this date to meet Article 50 machine-readable marking.
Standalone high-risk (Annex III). Obligations for high-risk systems on the Annex III list, such as hiring, credit, and education tools, apply. The 2026 Digital Omnibus moved this from the original 2 Aug 2026 date.
Embedded high-risk (Annex I). High-risk obligations for AI that is a safety component of products already regulated under EU law, such as medical devices and machinery, apply in full.
High-Risk Obligations in Detail
High-risk systems carry the heaviest requirements in the Act. These are the obligations that turn AI governance from a policy document into an engineering and documentation program. Providers own most of them; deployers own a focused subset.
1. Risk Management (Art. 9)
A continuous, documented process running across the whole lifecycle: identify foreseeable risks to health, safety, and fundamental rights, test mitigations, and update as the system and its use change. Not a one-time assessment.
2. Data Governance (Art. 10)
Training, validation, and test data must be relevant, representative, and examined for bias. You need documented data sources, quality criteria, and steps taken to detect and reduce discriminatory outcomes.
3. Technical Documentation (Art. 11)
Detailed records, per Annex IV, that let an authority assess conformity: system design, intended purpose, capabilities and limits, and the risk and data steps taken. This is the evidence file a regulator asks to see.
4. Human Oversight (Art. 14)
Systems must be designed so a person can understand the output, intervene, and override or stop the system. Oversight has to be real and effective, not a rubber-stamp step, and the assigned people must have the competence and authority to act.
5. Logging and Traceability (Art. 12)
Automatic recording of events over the system's lifetime so operation can be traced and reconstructed. Logs support incident investigation, post-market monitoring, and the ability to prove what happened and when.
6. Accuracy and Robustness (Art. 15)
Appropriate levels of accuracy, robustness, and cybersecurity, declared and maintained. Systems must resist errors, faults, and adversarial manipulation such as data poisoning and model-evasion attacks.
On top of these, providers of high-risk systems must put the system through a conformity assessment before it goes to market, affix the CE marking, register it in the EU database, and run post-market monitoring with an obligation to report serious incidents. Deployers of high-risk systems carry a lighter but real set: use the system according to instructions, assign competent human oversight, monitor operation and keep logs, and, for certain systems, conduct a fundamental rights impact assessment and inform affected individuals.
The through-line across all of this is evidence. Every obligation implies a record you can produce on demand. A mature program does not treat documentation as an afterthought; it captures the inventory, risk assessments, data lineage, oversight decisions, and monitoring results as it goes, so the audit file assembles itself rather than being reconstructed under deadline pressure. Continuous monitoring and drift detection matter here too, because a system that was accurate at launch can degrade quietly, and Article 15 is a continuing obligation, not a launch gate.
General-Purpose AI and Systemic-Risk Models
The large foundation models that power much of today's AI get their own regime, separate from the risk tiers. The Act splits them into two groups: all GPAI models, and the subset judged to carry systemic risk.
Every provider of a general-purpose AI model, the kind that can be adapted to many downstream tasks, has baseline duties that took effect on 2 August 2025. They must maintain up-to-date technical documentation, provide information and documentation to downstream providers who build on the model, put in place a policy to respect EU copyright law, and publish a sufficiently detailed summary of the content used for training. These obligations recognize that whoever builds on a foundation model needs to understand what they are inheriting.
The Systemic-Risk Threshold
A smaller group of the most capable models is presumed to carry systemic risk. The Act sets the trigger at models trained using more than 1025 floating-point operations (FLOPs) of compute, a proxy for the frontier of capability. Providers of these models take on extra duties: model evaluations including adversarial testing (red-teaming), assessment and mitigation of systemic risks, serious-incident tracking and reporting, and adequate cybersecurity for the model and its physical infrastructure.
The GPAI Code of Practice, finalized in July 2025, gives model providers a practical way to show they meet these obligations. It is voluntary, but signing it creates a presumption of conformity and reduces the compliance burden of proving each requirement independently. For most enterprises the takeaway is narrower: if you deploy someone else's foundation model rather than train your own, you are almost never the GPAI provider. Your obligations attach to how you use the model in a specific product, which is classified under the four tiers like any other system.
Penalties Under Article 99
The Act carries fines that scale with the severity of the breach and with company size. The top band exceeds the GDPR's maximum, which is what has moved AI compliance onto board agendas.
For each band the fine is the higher of the fixed amount or the percentage of global turnover, so the percentage bites hardest on large companies and the fixed cap protects smaller ones from proportionally ruinous fines. There is a specific carve-out: for small and medium enterprises and startups, each band applies as the lower of the two figures instead, a deliberate softening for smaller providers. Fines are set and enforced by national market surveillance authorities in each member state, with the AI Office coordinating on GPAI matters.
Two things are worth holding in view. The financial penalty is rarely the whole cost. A prohibited-use finding or a serious high-risk failure brings mandatory correction, potential withdrawal of the system from the market, reputational damage, and the diligence questions that follow in every future deal. And enforcement runs on the timeline in Section 04: the penalty powers themselves have been live since August 2025, even though the high-risk obligations they can punish phase in later.
How to Prepare: A Practical Sequence
Preparation is less about legal interpretation than about visibility and evidence. You cannot classify what you cannot see, and you cannot prove compliance you did not record. Five steps, run in order, cover most of the work.
-
1. Inventory every AI systemBuild a complete register of AI systems in use, in development, and embedded in tools you have bought. This is harder than it sounds because much of it is invisible.
- Capture purpose, owner, data used, and vendor for each system
- Include AI features inside SaaS products and unsanctioned tools staff adopted on their own (shadow AI)
- Automated discovery beats a survey, which always misses the systems nobody wants to report
-
2. Classify each system by tierRun every system against the four tiers and the Annex III and Annex I lists. Record the reasoning, not just the verdict.
- Flag anything prohibited for immediate remediation, since those rules are already live
- Identify high-risk systems and note whether you are provider or deployer for each
- Confirm limited-risk systems that will need Article 50 disclosure by August 2026
-
3. Close documentation and control gapsFor each high-risk system, compare what you have against the Article 9 to 15 obligations and list what is missing.
- Assess risk management, data governance, technical documentation, human oversight, logging, and accuracy
- Prioritize by exposure: the systems that affect the most people or the highest-stakes decisions first
- Map one control set to multiple frameworks so EU AI Act work also serves NIST AI RMF and ISO 42001
-
4. Assign clear ownersGovernance fails when responsibility is diffuse. Every system and every obligation needs a named owner.
- Name an accountable owner for each high-risk system and for the program overall
- Assign the human-oversight role to people with the competence and authority to intervene
- Deliver the AI literacy training that Article 4 has required since February 2025
-
5. Set up continuous monitoringCompliance is a state you maintain, not a milestone you pass. Systems drift and the inventory changes weekly.
- Monitor high-risk systems for accuracy, drift, and fairness against defined thresholds
- Keep the inventory live as new tools appear and existing ones change purpose
- Maintain audit-ready evidence and a full audit trail so a regulator request is a query, not a fire drill
Start now, start with risk. The high-risk deadline moved to December 2027, but the prohibitions, AI literacy duty, and GPAI and transparency obligations are already live or arrive in 2026. Beginning with your prohibited and highest-risk systems cuts real exposure fastest while you build the rest of the program.
Common Misconceptions
Several beliefs about the Act are common, confidently held, and wrong. Each one leads to a predictable and expensive mistake.
| The Misconception | The Reality |
|---|---|
| "We're not an EU company, so it doesn't apply to us." | Scope follows the effect, not the address. If your system's output is used in the EU, or you serve EU users or employees, you can be in scope wherever you are based. |
| "All our AI is high risk." | High risk is a defined list (Annex III and Annex I). Most ordinary business AI is minimal or limited risk. Over-classifying wastes resources on controls the law never asked for. |
| "We just buy AI, so we have no obligations." | Deployers carry real duties: human oversight, monitoring, logging, and disclosure. Modify a system or rebrand it and you can become a provider with the full obligation set. |
| "The deadline moved to 2027, so there's nothing to do now." | Prohibitions and AI literacy have applied since February 2025. GPAI and penalty powers since August 2025. Article 50 transparency lands in August 2026. Only some high-risk duties moved. |
| "If we comply with GDPR, we comply with the AI Act." | They overlap on data but govern different things. GDPR governs personal data; the AI Act governs AI systems and their safety, oversight, and transparency. You need both. |
Key Takeaways
- The EU AI Act regulates AI by risk, not by sector. Four tiers, from prohibited to minimal, determine every obligation and deadline you face.
- Scope is extraterritorial. Non-EU firms are covered when they place systems on the EU market or when their AI's output is used in the EU. Most global enterprises have systems in scope.
- Providers carry the heavy obligations; deployers carry a real but focused set. The same company is often both, and modifying a bought system can turn a deployer into a provider.
- The timeline moved in 2026 but did not soften. Prohibitions, AI literacy, GPAI, and penalty powers are live; Article 50 transparency lands August 2026; standalone high-risk moved to December 2027 and embedded high-risk to August 2028.
- Fines reach €35M or 7% of global turnover under Article 99, above the GDPR ceiling. An accurate, monitored, evidence-backed AI inventory is the foundation of any credible compliance program.
From policy to practice. Spreadsheets and ticket queues rarely keep up with how fast AI spreads across an enterprise. Dedicated AI governance platforms give governance teams one place to discover, assess, monitor, and evidence every model and agent against frameworks like the EU AI Act, NIST AI RMF, and ISO 42001.
Frequently Asked Questions
The questions global teams ask most often about the Act, answered against the law as it stands in mid-2026.
Often, yes. The Act reaches beyond the EU in the same way the GDPR does. A US company is in scope if it places an AI system on the EU market, if it has an EU establishment using AI, or if the output of its AI system is used inside the EU. A US firm screening EU-based job applicants or generating content consumed by EU users can be covered even with no EU office. If you have EU customers, employees, or users touched by your AI, assume some systems are in scope until a documented analysis shows otherwise.
In phases. Prohibited practices and the AI literacy duty applied from 2 February 2025. General-purpose AI obligations and the Article 99 penalty powers applied from 2 August 2025. Article 50 transparency duties apply from 2 August 2026. After the 2026 Digital Omnibus, standalone high-risk (Annex III) obligations apply from 2 December 2027, and embedded high-risk (Annex I) from 2 August 2028. The deferrals covered high-risk only; the earlier dates were not moved.
High-risk systems fall into two groups. Annex III lists standalone uses in sensitive domains: employment and hiring, credit and insurance, education, essential public and private services, biometrics, critical infrastructure, law enforcement, and migration. Annex I covers AI used as a safety component in products already regulated by EU law, such as medical devices and machinery. If a system is not on either list and is not prohibited, it is almost certainly limited or minimal risk. Classification depends on the specific use, so the same model can be high risk in one deployment and minimal in another.
Under Article 99, prohibited practices can draw up to €35 million or 7% of total worldwide annual turnover, whichever is higher. Breaching most other obligations, including high-risk and GPAI duties, can reach €15 million or 3% of turnover. Supplying incorrect or misleading information to authorities can cost up to €7.5 million or 1%. Small and medium enterprises and startups face the lower of the fixed amount or the percentage rather than the higher. National authorities set and enforce fines, and non-financial consequences such as forced withdrawal of a system often matter as much as the fine.
GPAI models are regulated on a separate track from the four risk tiers. Every GPAI provider must keep technical documentation, inform downstream developers, respect EU copyright, and publish a summary of training content. Models trained with more than 10^25 FLOPs are presumed to carry systemic risk and take on extra duties: evaluation and red-teaming, risk mitigation, incident reporting, and model-level cybersecurity. The GPAI Code of Practice, finalized in July 2025, is a voluntary way to demonstrate compliance. If you deploy someone else's model rather than train your own, you are usually not the GPAI provider; your product is classified under the four tiers.
They are separate laws that overlap where AI processes personal data. The GDPR governs how personal data is collected and used, including rights around automated decision-making. The AI Act governs AI systems themselves: their risk classification, safety, human oversight, transparency, and documentation. Complying with one does not satisfy the other. A high-risk hiring tool, for example, must meet GDPR rules on candidate data and AI Act rules on risk management, oversight, and record-keeping. In practice, mapping a single control set to both, alongside NIST AI RMF and ISO 42001, is far more efficient than running each in isolation.
