Key takeaways
- The Europe Artificial Intelligence Act is Regulation (EU) 2024/1689, the world’s first horizontal law on artificial intelligence. It applies across all 27 EU member states without national transposition.
- It uses a four-tier risk pyramid: unacceptable (prohibited since 2 February 2025), high (the bulk of the obligations), limited (transparency duties), and minimal (no specific obligation).
- It applies to four operator roles (provider, deployer, importer, distributor) plus a separate track for General-Purpose AI (GPAI) model providers. Your role decides which articles bind you.
- Compliance deadlines are dated and staged: 2 February 2025, 2 August 2025, 2 August 2026, 2 August 2027, 2 August 2028.
- Maximum fines reach 35 million euros or 7% of worldwide annual turnover for prohibited practices, 15 million or 3% for most other obligations.
What the Europe Artificial Intelligence Act actually is
The Europe Artificial Intelligence Act, formally Regulation (EU) 2024/1689 of the European Parliament and of the Council, was signed on 13 June 2024 and published in the Official Journal on 12 July 2024. It entered into force on 1 August 2024 and becomes fully applicable on 2 August 2026, with several earlier and later staging dates that we map below (European Commission).
It is a regulation, not a directive. That distinction matters in practice: it applies directly in every member state, with no national implementation step. A single text, one regulator network, the same obligations from Lisbon to Tallinn.
Article 1(2) sets out the subject matter in plain terms. The Act lays down harmonised rules for placing AI systems on the EU market, prohibitions of certain practices, specific requirements for high-risk AI systems and obligations for operators, transparency rules for certain systems, market surveillance and governance rules, and support measures for innovation (AI Act Service Desk – Article 1).
Scope is intentionally broad. Article 2 brings in any provider placing an AI system or GPAI model on the EU market, regardless of where the provider sits, and any deployer established or located in the EU. Critically, Article 2(1)(c) extends the regulation to providers and deployers outside the EU whenever the output of the AI system is used in the Union. A US analytics vendor whose model scores credit applications in Madrid is therefore in scope, even if it has no European office.
The Act also leaves carve-outs. It does not apply to AI systems developed and used exclusively for military, defence or national security purposes, to scientific research and development before market placement, or to purely personal non-professional activity by natural persons. These exclusions are narrow. Most enterprise use cases land squarely inside the regulation.
The risk-based architecture in one diagram
The regulation organises AI systems into four layers, each with its own set of duties.
Unacceptable risk: prohibited practices
Article 5 lists practices considered incompatible with EU fundamental rights. They have been illegal since 2 February 2025. The list includes subliminal manipulation that materially distorts behaviour and causes harm, exploitation of vulnerabilities tied to age or disability, social scoring by public authorities, untargeted scraping of facial images to build recognition databases, and real-time remote biometric identification in publicly accessible spaces by law enforcement (subject to narrow exceptions).
If your system sits anywhere on this list, no risk assessment, no documentation and no human oversight will rescue it. You stop deploying it, or you face the highest fines in the regulation.
High risk: most of the obligations live here
A system is high-risk in two situations. First, when it is a safety component of a product covered by EU harmonisation legislation listed in Annex I (machinery, toys, medical devices, vehicles, lifts). Second, when it falls into one of the eight areas listed in Annex III: biometrics, critical infrastructure, education and vocational training, employment and workers management, access to essential private and public services, law enforcement, migration and border control, administration of justice and democratic processes (Annex III).
Article 6(3) gives providers a narrow self-assessment route to exit the high-risk bucket when their Annex III system performs only a procedural task or improves the result of a prior human activity. Article 6(4) is then explicit: a provider who reaches that conclusion must document the assessment in writing before placing the system on the market and register it in the EU database under Article 49(2). The exit is not a shortcut. It is a recorded determination, reviewable by authorities.
Limited risk: transparency duties
Article 50 attaches a thin layer of disclosure obligations to chatbots, emotion recognition systems, biometric categorisation, and synthetic content (deepfakes). End users must be told they are interacting with AI, and AI-generated media must be machine-readable as such.
Minimal risk: no specific duty
Spam filters, recommender systems used in non-essential contexts, AI in games. The Act asks for nothing beyond voluntary codes of conduct. This is where most enterprise AI sits today, which is precisely why the four-tier picture matters: do not regulate yourself into a higher tier than the law requires.
Are you a provider, deployer, importer or distributor?
The single most expensive mistake at the start of an AI Act programme is to skip role classification and assume “we are the deployer”. Your role determines your obligations more than the technology does.
- Provider: an entity that develops an AI system, or has it developed, and places it on the market or puts it into service under its own name or trade mark, paid or free. Article 3(3).
- Deployer: an entity using an AI system under its authority, except where the use is purely personal and non-professional. Article 3(4).
- Importer: a natural or legal person established in the EU that places on the market an AI system bearing the name or trade mark of a third-country entity.
- Distributor: any other actor in the supply chain making the system available without altering it.
The same organisation can be a provider for one system and a deployer for another. The mapping is system-by-system, not company-by-company.
Three edge cases trip up most teams. First, white-labelling: if you market a third-party system under your own brand, Article 25(1)(a) deems you the provider, with all the documentation, conformity assessment and post-market duties that follow. Second, substantial modification: if you fine-tune, retrain or repurpose a high-risk system or a GPAI model into a new intended purpose, Article 25(1)(c) likewise makes you the provider. Third, fine-tuning a GPAI model: when you take an open or licensed GPAI model and adapt it into a downstream system whose intended purpose is high-risk, you become a provider of a high-risk AI system, not merely a deployer.
Map every AI system in your portfolio against these four roles before you write a compliance plan. Then attach the obligations.
What providers of high-risk AI systems must do
Providers carry the heaviest load. Chapter III, Section 2 stacks the obligations.
Article 9 requires a documented risk management system that runs across the entire lifecycle, not a one-off pre-launch assessment. Identified, evaluated, evaluated again after market release, mitigated and retested.
Article 10 governs data and data governance. Training, validation and testing data sets must be relevant, sufficiently representative, free of errors as far as possible, and appropriate in light of the intended purpose. Statistical bias controls are explicit.
Article 11 requires technical documentation before the system is placed on the market. Annex IV lists the content: general description, design and development process, data used, monitoring and control mechanisms, risk management measures, change management. Article 12 adds automatic logging of events during operation, retained for at least six months.
Article 13 demands transparency to deployers: clear instructions for use, expected accuracy, robustness and cybersecurity properties, known limitations and the conditions of use under which the system is fit for its purpose. Article 14 requires human oversight measures designed into the system. Article 15 stipulates accuracy, robustness and cybersecurity.
Then the conformity machinery. Article 16 lists the provider’s overarching obligations. Article 17 mandates a quality management system. Article 43 sets the conformity assessment route (internal control for most Annex III systems, third-party assessment for biometrics in some cases, and any system embedded in a product covered by NLF legislation). Once the assessment passes, the provider draws up an EU declaration of conformity (Article 47), affixes the CE marking (Article 48), and registers the system in the EU database (Article 49). Post-market monitoring (Article 72) and serious-incident reporting (Article 73) continue throughout the life of the system.
What deployers must do
Deployer obligations are lighter in volume but heavier in operational consequence, because they are the ones running the system in production.
Article 26 sets the headline duties: use the system in accordance with the instructions for use, assign human oversight to natural persons with the necessary competence, ensure that input data is relevant and sufficiently representative for the intended purpose, monitor operation and suspend use when it produces risks under Article 79.
Deployer logging duties under Article 26(6) require retaining the automatically generated logs for at least six months, unless longer retention is required by sectoral law. Article 26(7) demands an information notice to employees before deploying a high-risk AI system in the workplace.
Article 27 imposes a Fundamental Rights Impact Assessment (FRIA) on a specific subset of deployers: bodies governed by public law, private operators providing public services, and operators of high-risk systems used for credit scoring or life and health insurance pricing. The FRIA captures the intended purpose, the categories of natural persons affected, foreseeable risks to fundamental rights, the human oversight measures, and the actions to be taken if risks materialise. It is not a generic privacy impact assessment.
Article 4 imposes a baseline that applies to every deployer of any AI system, not only high-risk ones: AI literacy for staff dealing with the operation and use of AI systems. The obligation entered into force on 2 February 2025 alongside the prohibitions. It is enforceable today.
General-Purpose AI models: the second regulatory track
Chapter V of the Act creates a parallel track for General-Purpose AI (GPAI) models, defined in Article 3(63) as models that display significant generality and are capable of competently performing a wide range of distinct tasks. Article 3(66) extends the same logic to GPAI systems built on top of them.
GPAI providers face three tiers of duty. Article 53 covers all GPAI providers: maintain up-to-date technical documentation of the model, supply downstream providers with the information they need to comply with their own obligations, implement a copyright policy aligned with the text and data mining opt-out under Directive (EU) 2019/790, and publish a sufficiently detailed summary of the training content.
Article 55 adds obligations for GPAI models with systemic risk. The presumption uses computational scale as a proxy: training compute above 10^25 floating-point operations triggers systemic-risk classification. Such models must undergo state-of-the-art evaluation, assess and mitigate systemic risks at Union level, track and report serious incidents to the AI Office, and ensure adequate cybersecurity protection.
The third tier is voluntary but practical: the General-Purpose AI Code of Practice, finalised in 2025, gives a presumption of conformity for those who sign it.
Two operational consequences for downstream organisations. First, fine-tuning shifts liability. A bank that fine-tunes a GPAI model into a credit-scoring engine becomes a provider of a high-risk AI system under Article 25 and inherits the full Chapter III, Section 2 stack. Second, information chain duties under Article 53(1)(b) force GPAI providers to give you a documentation package you can rely on. Demand it in procurement.
The compliance timeline you actually have to plan around
Article 113 sets a staggered application schedule. Five dates anchor the plan.
- 2 February 2025: prohibitions in Article 5 apply, and the AI literacy duty in Article 4 applies. Audit your portfolio for prohibited use cases first; if any system is captured, sunset it before this date.
- 2 August 2025: GPAI obligations (Chapter V) apply, the governance architecture (AI Office, AI Board, national competent authorities) becomes operational, and the penalties framework (Article 99) becomes enforceable for the obligations already in force.
- 2 August 2026: the bulk of the regulation applies. High-risk AI obligations in Chapter III, Section 2, transparency duties in Article 50, the EU database, conformity assessment routes. This is the deadline most teams plan against.
- 2 August 2027: GPAI models placed on the market before 2 August 2025 must reach full compliance. The grace period closes.
- 2 August 2028: extended transition for high-risk AI systems embedded in regulated products covered by Annex I, Section A (machinery, medical devices, in-vitro diagnostics, etc.).
The staggered schedule means a single AI portfolio can have obligations active today, more obligations active next August, and a final wave landing in 2028. Plan in waves, not in a single Big Bang.
Penalties and enforcement
Article 99 sets three penalty bands. Prohibited practices: up to 35 million euros or 7% of worldwide annual turnover for the preceding year, whichever is higher. Most other obligations (high-risk requirements, transparency, post-market): up to 15 million euros or 3% of turnover. Misleading information to authorities: up to 7.5 million or 1%.
For SMEs and start-ups, the maximum applies as the lower of the two figures, not the higher. The drafters built that to avoid disproportionate harm to small actors, while keeping the deterrent intact for hyperscalers.
Enforcement runs on three layers. The AI Office, sitting in DG CONNECT, has direct enforcement powers over GPAI providers from 2 August 2026. National competent authorities, designated by each member state, supervise AI systems in their territory. The European Artificial Intelligence Board coordinates the network, harmonises practice, and issues opinions on contested classifications. The European Data Protection Supervisor handles EU institutions.
The governance artefacts the Act forces you to produce
The Act is structured around documents you must be able to show on demand. If you operationalise the regulation as a list of artefacts, the rest of the programme falls into place.
- Risk management system file (Article 9): living record of identified risks, residual risks, mitigations and the rationale for accepting residuals.
- Technical documentation (Article 11 + Annex IV): pre-market dossier the provider hands to the conformity assessment body and to authorities upon request.
- Automatically generated logs (Article 12): retained six months minimum, immutable, queryable.
- Instructions for use (Article 13): the deployer-facing manual covering limits, accuracy, oversight requirements.
- Quality management system documentation (Article 17): the provider’s organisational backbone, including responsibilities, escalation paths and resource allocation.
- EU declaration of conformity (Article 47) and CE marking records (Article 48).
- EU database registration (Article 49): the public-facing entry for high-risk systems.
- Post-market monitoring plan (Article 72) and serious incident reports (Article 73).
- Fundamental Rights Impact Assessment (Article 27): the deployer-side dossier.
- AI literacy programme records (Article 4): training plans and completion evidence for staff.
Whoever owns the artefact owns the obligation. Map each one to a department before launch: Legal owns the conformity declaration, Risk owns the FRIA, MLOps owns the logs, HR owns AI literacy, Procurement owns the GPAI documentation chain.
FAQ
Is my chatbot high-risk under the Europe Artificial Intelligence Act? A general-purpose chatbot used for customer service is usually limited-risk, triggering only the transparency duty in Article 50 (tell users they are talking to AI). It becomes high-risk if it sits inside an Annex III use case, for example screening job candidates or determining access to public benefits. The classification depends on the intended purpose, not the underlying model. Same chatbot, different deployment, different tier.
Does the Act apply to a US company with no EU office? Yes, if the output of the AI system is used in the EU. Article 2(1)(c) brings third-country providers and deployers into scope as soon as their output reaches the Union. A US vendor scoring loan applications for a Spanish bank is captured. The vendor must appoint an authorised representative in the EU under Article 22, and meet provider obligations.
When does the law apply to a model trained before August 2025? GPAI models placed on the market before 2 August 2025 have a transition period and must reach full compliance by 2 August 2027. AI systems already in service before 2 August 2026 are not retroactively swept in, but any substantial modification after that date triggers full application.
What happens if I fine-tune a GPAI model? Do I become a provider? It depends on the result. Fine-tuning a GPAI model into a downstream system with a new intended purpose makes you the provider of that system under Article 25. If the new purpose is high-risk (credit scoring, recruitment, medical triage), you take on the full Chapter III, Section 2 stack. Recital 109 and Article 25(2) frame the test.
Are open-source AI models exempt? Partially. Article 2(12) excludes free and open-source AI components from most obligations, with carve-outs. The exemption does not apply to GPAI models with systemic risk, to systems used as high-risk AI, or to systems falling under the Article 5 prohibitions. Open-source is not a regulatory free pass; it is a narrow shelter.
How does the AI Act interact with GDPR? The two regulations apply cumulatively. GDPR governs personal data processing; the AI Act governs the AI system itself. Article 26(7) and Article 27 explicitly cross-reference the GDPR’s data protection impact assessment. A high-risk AI processing personal data needs a DPIA under GDPR Article 35 and, where applicable, a FRIA under AI Act Article 27. The European Data Protection Board issued guidance in 2025 on how to reconcile the two impact assessments without duplicating evidence.
What about ISO 42001 and the EU AI Act? ISO/IEC 42001 is a voluntary AI management system standard. CEN-CENELEC is drafting harmonised European standards (the prEN 18228 family, plus the prEN 18282 terminology baseline) that, once published, will give a presumption of conformity with specific AI Act articles under Article 40. Adopting ISO 42001 today is a credible interim move; it covers many of the same management-system controls the harmonised EN will demand.
Conclusion
The Europe Artificial Intelligence Act is not a single deadline. It is a five-date schedule, four operator roles, a four-tier risk pyramid, a second track for general-purpose models, and roughly a dozen named artefacts you must be able to produce on demand. The teams who treat it as a legal text to be read miss the point. The teams who treat it as an operating manual, role by role, system by system, artefact by artefact, finish the programme without surprises.
If you are running an AI portfolio across the EU, start with role classification, attach obligations system by system, build the artefact list as a backlog, and stage the work against the dated milestones. AI Sigil is built around exactly that operating model: see the AI Sigil platform for the underlying governance framework that maps the Act’s obligations to the artefacts your team has to produce.