If you build, deploy, or embed AI systems that touch the EU market, the EU AI Act is no longer a future problem.
Prohibited-practice rules have been enforceable since February 2, 2025, general-purpose AI model obligations since August 2, 2025, and the bulk of the regulation, including most high-risk system requirements, applied from August 2, 2026.
A Digital Omnibus package adopted by the European Parliament in June 2026 pushed some high-risk deadlines further out, which means the checklist your compliance team downloaded last year may already cite the wrong date.
This is not legal advice. It is a practical, engineering-facing breakdown of what the Act actually asks you to build, in the order most teams need to build it. Pair it with counsel who can confirm your specific risk classification and jurisdictional exposure.
Key takeaways
- Core obligations for high-risk systems, transparency rules, and GPAI fine enforcement all became binding by August 2, 2026; prohibited practices have been enforceable since February 2, 2025.
- A June 2026 Digital Omnibus deferred the high-risk classification deadline for most standalone systems (Article 6(2)) to December 2, 2027, and for AI embedded in regulated products (Article 6(1)) to August 2, 2028.
- Penalties reach up to €35 million or 7% of global annual turnover for prohibited practices, and up to €15 million or 3% for other high-risk and GPAI violations, whichever figure is higher (Article 99).
- Risk classification turns on intended purpose and context of use, not model architecture or company size: the same LLM can be minimal risk in one deployment and high-risk in another.
- General-purpose AI models trained above roughly 10^25 cumulative FLOPs face added systemic-risk obligations, including adversarial testing and incident reporting to the EU AI Office (Article 51).
- Engineering owns most of the build: system inventory, risk classification, technical documentation, human-oversight design, and monitoring. Legal review still matters for classification calls and conformity-assessment strategy.
What the EU AI Act actually regulates
The Act does not regulate “AI” as a category. It regulates specific uses of AI systems based on the risk they pose to health, safety, and fundamental rights, and it assigns obligations to different roles: providers who build a system, deployers who put it into use, importers, and distributors. Your obligations change depending on which role you play for a given system, and a single company can be a provider for one system and a deployer for another.
Four risk tiers sit underneath everything else in the Act:
| Risk tier | What it covers | What it requires |
|---|---|---|
| Unacceptable | Social scoring, manipulative or exploitative systems, most real-time remote biometric identification in public spaces, emotion inference in workplaces and schools | Banned outright, no compliance path |
| High-risk | Systems used in Annex III areas: employment and worker management, education access, credit scoring, law enforcement, migration, critical infrastructure, and biometric categorization, plus AI embedded in products already regulated under EU safety law (medical devices, machinery, toys) | Risk management, data governance, technical documentation, human oversight, conformity assessment |
| Limited risk | Chatbots, deepfakes, emotion recognition outside prohibited contexts, AI-generated content | Transparency: users must know they are interacting with or viewing AI output |
| Minimal risk | Spam filters, recommendation engines, most internal productivity tooling | No mandatory obligations, voluntary codes of conduct encouraged |
Most engineering time goes into the high-risk tier, because it is the only one with a full technical and organizational compliance program attached.
The checklist
1. Inventory every AI system you build, deploy, or embed
Start with a system-level register, not a project-level one. For each system, record its intended purpose, the data it consumes, the decisions or outputs it produces, who it affects, whether it is in production or pilot, and who owns it internally. Include AI functionality embedded in third-party tools you’ve licensed, since deploying someone else’s model can still make you a deployer with obligations under the Act. Teams that skip this step usually discover mid-audit that a vendor-supplied resume screener or fraud model was never classified at all.
2. Classify each system’s risk tier
Walk every system in your inventory against Annex III and the prohibited-practice list in Article 5. Classification depends on intended purpose and the context of use, not the underlying model architecture or your company’s size. A general-purpose LLM used for internal drafting is minimal risk; the same model fine-tuned to screen job applicants is high-risk. Document the classification reasoning for each system, because auditors and regulators will ask how you arrived at it, not just what the answer was.
3. Rule out prohibited practices first
Before investing in documentation for a system, confirm it doesn’t fall under Article 5. Social scoring, subliminal manipulation, biometric categorization inferring sensitive attributes like political opinions or sexual orientation, and untargeted scraping of facial images to build recognition databases are banned regardless of what safeguards you add. There is no conformity assessment or documentation package that makes a prohibited practice legal. If a system might qualify, escalate before writing another line of the compliance file.
4. Build the technical documentation your Annex IV file requires
High-risk systems need a technical documentation file, defined in Annex IV, that a regulator can request at any point, covering the system’s design specifications, the datasets used for training, validation, and testing, the metrics used to measure accuracy and robustness, and known limitations. In practice this means your ML team needs to maintain, alongside the model itself, a data lineage record, an evaluation report, and a change log every time the model is retrained or the training data changes materially. Treat this like SOC 2 evidence collection: automated wherever possible, because manually reconstructing training data provenance six months after the fact is close to impossible.
5. Wire risk management and data governance into the pipeline
The Act requires a risk management system that runs across the entire lifecycle of a high-risk AI system, not a one-time assessment before launch. That means identifying foreseeable misuse, testing for it, and documenting mitigations, then repeating that process after every significant model update. Data governance obligations sit alongside this: training, validation, and testing datasets need to be relevant, representative, and examined for biases that could affect the outcomes for people the system touches. If your MLOps pipeline doesn’t already produce a dataset statistics report on every training run, this is the step that forces it.
6. Design for human oversight, not just human review
Human oversight under the Act means a person can understand the system’s output, intervene in it, and override or halt it, and that this capability is designed into the system rather than bolted on as a support ticket process. A “human in the loop” button that nobody has time to press because the interface buries it under three menus does not satisfy the requirement. Interfaces for high-risk systems need to surface confidence levels or key decision factors clearly enough that a non-technical reviewer can act on them within the time the workflow actually allows.
7. Run a Fundamental Rights Impact Assessment where it’s required
If you’re a public-sector body, or a private deployer of high-risk systems used for credit scoring or life and health insurance risk assessment, Article 27 requires a Fundamental Rights Impact Assessment before you put the system into use. It documents how the system’s deployment could affect the fundamental rights of the people subject to it, what mitigations you’ve put in place, and how you’ll notify the relevant market surveillance authority. This obligation is tied to the same December 2, 2027 date as the Annex III classification deadline above, since it applies to systems classified under Article 6(2). Most engineering teams outside those specific deployer categories won’t need one, but check this before assuming step 5’s risk management file covers it, since a FRIA is a separate, deployer-side obligation with its own documentation trail.
8. Prepare for conformity assessment and CE marking
Most high-risk AI systems go through a conformity assessment, either self-assessed against harmonized standards or, for a smaller set of use cases like biometric identification, assessed by a notified body. Passing it lets you affix a CE marking and register the system in the EU database for high-risk AI systems before placing it on the market. Build your technical documentation (step 4) and risk management file (step 5) with this assessment in mind from the start; retrofitting them afterward tends to surface gaps that delay launch.
9. Handle general-purpose AI model obligations if you build or fine-tune foundation models
If your organization trains or substantially modifies a general-purpose AI model, separate obligations apply regardless of downstream use case, and they have applied since August 2, 2025. These cover technical documentation for the model itself, information disclosure to downstream deployers who integrate it, and a copyright policy covering training data. Models trained with cumulative compute above roughly 10^25 FLOPs face additional systemic-risk obligations under Article 51, including adversarial testing and incident reporting to the EU AI Office. Fine-tuning an open-weight model for a narrow internal task usually doesn’t trigger these, but check the threshold before assuming it doesn’t apply.
10. Set up post-market monitoring and incident reporting
Compliance doesn’t end at deployment. Providers of high-risk systems need a post-market monitoring plan that collects performance data in production and feeds it back into the risk management process, and a defined process for reporting serious incidents, meaning outcomes that caused death, serious harm, infrastructure disruption, or fundamental rights violations, to the relevant market surveillance authority. Build the logging for this into the system itself rather than promising to add it later; monitoring plans written after an incident already looks bad to a regulator.
11. Track evidence continuously, not before an audit
Every step above produces evidence: classification memos, dataset reports, human oversight test results, incident logs. Store them in one place, tied to the specific system version they cover, and update them as part of your normal release process rather than as a quarterly scramble. Version-controlled compliance evidence is the difference between a conformity assessment that takes a week and one that takes a quarter.
The compliance timeline, updated for the 2026 Digital Omnibus
The Act’s original schedule got revised mid-rollout. The Digital Omnibus on AI, approved by the European Parliament in June 2026 and given final Council sign-off later that month, amended Article 113 to push back some high-risk deadlines. If you’re working from a checklist published before mid-2026, verify these dates against the current text before you plan around them.
| Date | What applies |
|---|---|
| February 2, 2025 | Prohibited AI practices (Article 5) become enforceable |
| August 2, 2025 | General-purpose AI model obligations, governance structure, and penalty framework take effect |
| August 2, 2026 | Core provisions apply broadly, including transparency obligations for limited-risk systems and GPAI fine enforcement |
| December 2, 2027 | High-risk classification and obligations apply to Annex III standalone systems (Article 6(2)) |
| August 2, 2028 | High-risk obligations apply to AI embedded in products covered by existing EU product-safety law (Article 6(1)) |
Penalties scale by violation type: up to €35 million or 7% of global annual turnover for prohibited practices, up to €15 million or 3% for other high-risk and GPAI violations, and up to €7.5 million or 1% for supplying incorrect information to regulators, whichever figure is higher in each tier. Small and medium businesses get the inverse rule: whichever amount is lower applies to them.
Frequently asked questions
Does the EU AI Act apply if my company isn’t based in the EU? Yes, if your AI system is placed on the EU market or its output is used within the EU. Location of incorporation doesn’t matter; where the system operates does. A US company selling an AI-powered hiring tool to an EU-based customer is in scope as a provider.
What counts as a “high-risk” AI system? A system falls into one of two paths: it’s used in an area explicitly listed in Annex III (employment, education, credit, law enforcement, migration, critical infrastructure, and similar), or it’s a safety component of a product already regulated under EU harmonization law, like medical devices or machinery. Intended purpose and context of use drive the classification, not the model’s technical sophistication.
Do I need a lawyer, or can engineering handle this alone? Engineering owns the technical documentation, risk management pipeline, and monitoring infrastructure, but classification calls and conformity assessment strategy benefit from legal review, especially where a system’s use case sits near a boundary between risk tiers. Treat this as a joint effort from the inventory stage onward rather than something engineering hands to legal at the end.
Is ISO/IEC 42001 the same as EU AI Act compliance? No. ISO 42001 is a voluntary AI management system certification, and the Act is a binding legal regulation. They overlap heavily in structure, an AI management system built around ISO 42001 will cover much of the governance and risk management the Act requires, but certification against ISO 42001 doesn’t substitute for the Act’s mandatory conformity assessment on high-risk systems.
What happens if I just wait and see? The penalty tiers are calculated on global turnover, not EU revenue alone, and enforcement is already active for prohibited practices and GPAI obligations. Waiting until an incident or an audit forces the issue means building documentation retroactively, which is slower, more expensive, and harder to make convincing to a regulator than building it alongside the system from the start.
Next step
Read the current consolidated text of the Act directly rather than relying on any single summary, including this one, since the Digital Omnibus amendments are still being folded into secondary guidance. The EUR-Lex official text and the EU AI Office’s implementation resources are the two sources worth bookmarking before you finalize a risk classification you plan to stand behind.