The EU AI Act is Regulation (EU) 2024/1689, a binding European law that regulates artificial intelligence by the risk it poses. It sorts AI into four tiers: a small set of prohibited practices, high-risk systems that carry a full requirement set, limited-risk systems that mainly owe transparency, and minimal-risk systems that owe little beyond staff literacy. It binds providers, who build or supply AI, and deployers, who put it to use. It reaches any organization whose system is placed on the EU market or whose output is used in the Union, wherever that organization sits. The obligations arrive on a phased timeline running through 2025, 2026, and 2027, and the top penalty for a prohibited practice reaches EUR 35 million or 7 percent of worldwide turnover. What separates a compliant program from an exposed one is documented evidence of where each system sits and what controls are in place.
Most technology rules tell an organization how to build a thing. The AI Act starts from a different question: what could this system do to the people affected by it, and how do you prove you have controlled that risk. A model can be technically excellent and still be banned, and another can be permitted only once a defined set of controls and records is in place. Under the Act, most of the work is classifying the system correctly and keeping the evidence that supports that classification.
This guide is a practitioner's walk through the Act as it operates today: what it is and who it binds, the four risk tiers, the requirement set for high-risk systems, the duties on general-purpose AI models, the conformity and registration path, post-market monitoring and incident reporting, the penalties, and the phased timeline. Where a point turns on detail, defer to the Regulation itself, which is the source of record.
What the AI Act is
The AI Act is a regulation, which means it applies directly across all EU member states without each country having to pass its own version. It governs an AI system, defined in Article 3 as a machine-based system that operates with some autonomy, may adapt after deployment, and infers from its input how to generate outputs such as predictions, content, recommendations, or decisions. A piece of software that simply executes fixed rules written by people is generally outside that definition.
The Act reaches beyond Europe's borders. Under Article 2 it applies to providers placing AI systems on the Union market regardless of where they are established, to deployers located in the Union, and to providers and deployers in other countries where the system's output is used in the Union. A US or UK company with no EU office can still fall squarely within scope.
Some uses are carved out, including national security and defence, systems built solely for scientific research and development, pre-market testing, purely personal non-professional use, and certain free and open-source systems. Even where a system is in scope, one duty applies to almost everyone: under Article 4, providers and deployers must ensure a sufficient level of AI literacy among the staff who operate the system.
Who it binds: provider versus deployer
The Act assigns duties by the role an organization plays, and one organization can hold more than one role. The two that matter most are the provider and the deployer.
| Role | What it covers |
|---|---|
| Provider | An organization that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. The provider carries the build-side duties under Article 16: meeting the requirements, running a quality management system, keeping documentation and logs, completing the conformity assessment, drawing up the declaration of conformity, affixing the CE marking, registering the system, and taking corrective action. |
| Deployer | An organization that uses an AI system under its own authority in a professional context. The deployer carries the use-side duties under Article 26: following the instructions for use, assigning competent human oversight, ensuring input data is relevant where it controls that input, monitoring operation, reporting risks and serious incidents, keeping logs, informing affected people, and informing workers before a workplace deployment. |
The line between the two can move. Under Article 25, a deployer that puts its own name on a high-risk system, or substantially modifies one, becomes a provider and inherits the heavier provider obligations. An organization that buys an AI tool and reconfigures it materially should check whether it has stepped across that line.
The four risk tiers
The Act's central mechanism is a four-tier classification. Each system sits in one primary tier, and the tier decides how much obligation attaches.
Prohibited practices
Article 5 bans a defined set of AI practices outright. They include manipulative or deceptive techniques that cause significant harm, exploitation of vulnerabilities tied to age, disability, or socio-economic situation, social scoring that leads to unjustified detrimental treatment, predicting criminal offending based solely on profiling or personality traits, untargeted scraping of facial images to build facial-recognition databases, inferring emotions in the workplace or in education except for medical or safety reasons, biometric categorisation that deduces sensitive traits such as race or political opinion, and real-time remote biometric identification in public spaces for law enforcement, subject to narrow exceptions. For a prohibited practice there is no compliance path. The only lawful outcome is not to place the system on the market and not to deploy it.
High-risk systems
A system is high-risk by one of two routes. The first, under Article 6(1), is where the system is a safety component of, or is itself, a product already regulated under listed EU product-safety legislation that requires third-party assessment. The second, under Article 6(2), is where the system falls within one of eight areas set out in Annex III. These systems are permitted, but they carry the full requirement set and a conformity assessment before they reach the market.
| Annex III area | Examples |
|---|---|
| Biometrics | Remote biometric identification, biometric categorisation, and emotion recognition, where not already prohibited. |
| Critical infrastructure | Safety components in the management of road traffic, water, gas, heating, and electricity. |
| Education and vocational training | Systems determining admission, evaluating learning outcomes, or monitoring exams. |
| Employment and worker management | Recruitment, screening, promotion and termination decisions, and task allocation. |
| Essential services and benefits | Eligibility for public benefits, creditworthiness scoring of individuals, and risk-pricing in life and health insurance. |
| Law enforcement | Risk assessment of individuals, evidence reliability evaluation, and profiling in the course of investigation. |
| Migration, asylum, and border control | Risk assessment, examination of applications, and detection of irregular entry. |
| Administration of justice and democratic processes | Assisting judicial authorities in researching and interpreting facts and law, and influencing elections. |
There is a narrow off-ramp. Under Article 6(3), an Annex III system is not high-risk if it does not pose a significant risk of harm and meets one of four conditions, such as performing a narrow procedural task or improving the result of a completed human activity. One override cuts through it: a system that performs profiling of individuals is always high-risk. A provider relying on the off-ramp must document the assessment and still register the system.
Limited-risk transparency
Article 50 sets transparency duties that apply on top of any other tier. People must be told when they are interacting with an AI system. Synthetic audio, image, video, and text must be marked as artificially generated in a machine-readable form. Emotion-recognition and biometric-categorisation systems must disclose their operation to the people exposed to them. Deep fakes and AI-generated text published to inform the public on matters of public interest must be labelled.
Minimal risk
Everything not caught by the tiers above carries no specific AI Act obligation beyond the Article 4 AI-literacy duty. Most ordinary business AI sits here. The right move is still to document the classification, so that the conclusion is on the record if a regulator asks.
The high-risk requirement set
For a confirmed high-risk system, Articles 9 through 15 set out the controls the system must satisfy before it can be placed on the market. Read each as a control objective with evidence behind it.
| Requirement | What it means in practice |
|---|---|
| Risk management (Art 9) | A continuous, documented process across the system's life: identify foreseeable risks under intended use and foreseeable misuse, mitigate them, and test against defined metrics before going to market. |
| Data governance (Art 10) | Training, validation, and testing data must be relevant, sufficiently representative, and to the extent possible free of errors, with bias examined and mitigated. |
| Technical documentation (Art 11) | A documentation set, drawn up before market and kept current, covering the system's design, capabilities, and limits. Smaller companies may use a simplified form. |
| Record-keeping and logging (Art 12) | Automatic logging over the system's lifetime, sufficient for traceability and for post-market monitoring. |
| Transparency (Art 13) | Operation transparent enough for deployers to interpret output, plus instructions for use that state capabilities, limitations, accuracy figures, and human-oversight measures. |
| Human oversight (Art 14) | Designed so people can understand the system's limits, counter automation bias, override the output, and stop the system. |
| Accuracy, robustness, cybersecurity (Art 15) | Appropriate accuracy with declared metrics, resilience to errors and feedback loops, and resilience against attacks such as data poisoning and adversarial examples. |
Any requirement left unmet is a conformity gap, and the gap has to be closed before the organization can sign the EU declaration of conformity. Some Annex III biometric systems carry extra duties, including specific logging and oversight by at least two competent people.
General-purpose AI models
The Act treats general-purpose AI (GPAI) models separately from systems. A GPAI model is a model trained on broad data that can perform a wide range of tasks and be built into many downstream systems. The large foundation models that power chat assistants and content tools are the clearest examples. Under Article 53, every GPAI model provider owes a baseline: technical documentation, information for the organizations that integrate the model downstream, a policy to respect EU copyright reservations, and a publicly available summary of the content used to train the model. Providers of open-source models are relieved of part of this baseline unless their model carries systemic risk.
A subset of models carry systemic risk. Under Article 51, a model is presumed to have systemic risk when the cumulative compute used to train it exceeds a defined threshold, expressed as ten to the power of twenty-five floating-point operations, or where the Commission designates it. Providers of these models must notify the Commission when they cross the threshold, and they take on the heavier Article 55 obligations: model evaluation including documented adversarial testing, assessment and mitigation of systemic risk at Union level, tracking and reporting of serious incidents to the AI Office, and adequate cybersecurity for the model and its infrastructure.
Conformity assessment, CE marking, and the EU database
Before a high-risk system reaches the market, the provider runs a conformity assessment under Article 43 to confirm it meets the requirement set. For most Annex III systems this is an internal-control assessment the provider performs itself. For certain biometric systems, where harmonised standards have not been applied, an independent notified body, an accredited third party, performs the assessment. A substantial modification to the system triggers a fresh assessment.
Once the assessment is complete, the provider draws up the EU declaration of conformity under Article 47, kept for ten years, and affixes the CE marking under Article 48, the same conformity mark used across regulated products in Europe. The provider then registers the system in the EU database under Article 49 before placing it on the market. Public-authority deployers register their use of high-risk systems, and sensitive law-enforcement and border-control systems are recorded in a secure non-public section of the database.
Post-market monitoring and serious-incident reporting
Conformity is not a one-time gate. Under Article 72, the provider must run a documented post-market monitoring system that collects and analyses performance data across the system's life, so problems that only surface in real use are caught. Under Article 73, the provider must report serious incidents to the relevant national market surveillance authority. The reporting clock is tight: a serious incident must be reported without undue delay after a causal link is established, and no later than fifteen days, with shorter windows where a death is involved or where the incident is widespread.
Penalties
The Act backs its requirements with fines tied to global turnover. Under Article 99, breaching the prohibited-practice rules carries the top exposure: up to EUR 35 million or 7 percent of total worldwide annual turnover, whichever is higher. Breaching most other operator obligations, including the provider duties in Article 16 and the deployer duties in Article 26, carries up to EUR 15 million or 3 percent. Supplying incorrect or misleading information to authorities carries up to EUR 7.5 million or 1 percent. Smaller companies and start-ups pay the lower of the percentage or the fixed amount.
The timeline
The Act does not switch on all at once. It entered into force in 2024 and applies in phases, with the heavier obligations arriving later to give organizations time to prepare. The dates below reflect the phased schedule in the Regulation. Treat them as evolving and verify the current applicable date for the specific system at issue, because the timeline has continued to shift.
| Date | What applies |
|---|---|
| 2 February 2025 | The prohibited-practice ban and the AI-literacy duty take effect. |
| 2 August 2025 | Obligations on general-purpose AI models, plus the governance bodies and the penalty rules, take effect. |
| 2 August 2026 | The general date of application, including most high-risk obligations for Annex III systems. |
| 2 August 2027 | High-risk systems that are safety components of regulated products, and general-purpose AI models already on the market before 2 August 2025, must be in compliance. |
| 2 December 2027 | Under the Digital Omnibus, the Council and Parliament reached a provisional agreement on 7 May 2026 to defer the high-risk obligations for stand-alone Annex III systems to this date, and to 2 August 2028 for AI embedded in regulated products. It is not yet adopted, so 2 August 2026 above remains operative until it is published in the Official Journal; formal adoption is expected before then. |
Because the Commission can also amend the high-risk list and the prohibited-practice list by delegated act, the safe practice is to confirm the live position for each system rather than working from a remembered date.
Holding evidence rather than asserting readiness
The most common failure under a risk-tiered regime is rarely a refused conformity. More often it is an organization that believed it was compliant and could not produce the records when asked. The Act runs on documented evidence: a classification with reasoning, a requirement-by-requirement status for each high-risk system, the conformity record, and the monitoring data. Here is the contrast in practice.
"We take AI governance seriously. Our systems are built responsibly and we are confident they meet the EU AI Act. We have policies in place and our team is aware of the obligations."
"The credit-scoring model is classified high-risk under Annex III area 5(b), with the Article 6(3) off-ramp considered and rejected because the system profiles individuals. The Article 9 to 15 gap table shows risk management, data governance, and logging met; transparency instructions are in remediation with an owner and a date. The internal-control conformity assessment is scheduled, and the system is registered in the EU database."
The strong version names the tier and the basis, walks the requirement set, records the open gaps with owners, and points to the conformity and registration path. That is the record a regulator asks for, and it is the record that holds up.
An EU AI Act readiness checklist
Run this against each AI system before treating it as ready.
- Each system is confirmed as an AI system in scope, with any exclusion documented.
- The organization's role for each system is identified: provider, deployer, or both.
- Every system is screened against the prohibited-practice list before anything else.
- Each system has a risk-tier classification with the reasoning recorded, including the profiling override where it applies.
- High-risk systems have a requirement-by-requirement gap table across risk management, data governance, documentation, logging, transparency, human oversight, and accuracy.
- Provider and deployer role duties are assigned, and a Fundamental Rights Impact Assessment is performed where required.
- General-purpose AI models are checked for systemic risk and the matching obligation set.
- The conformity, CE marking, and registration path is mapped for each high-risk system.
- Post-market monitoring and serious-incident reporting procedures are in place with the reporting clock understood.
- For uncertain points, the position is checked against Regulation (EU) 2024/1689 and the current applicable date is verified.
The Act rewards organizations that can show their work. With a confident statement, you assert that you meant to comply. With a classification backed by reasoning, a closed requirement set, a signed declaration, and live monitoring data, you can show that you did. That is what the Regulation asks for.
For the terms used throughout this guide, see the EU AI Act glossary. For the related EU privacy regime the Act repeatedly defers to, see the GDPR compliance guide.