The EU AI Act, Regulation (EU) 2024/1689, is product-safety law applied to software. It does not regulate AI in general; it attaches duties to specific roles (provider, deployer, importer, distributor) for specific uses, scaled by risk, plus a separate set of duties for providers of general-purpose AI models. It applies to anyone placing AI systems on the EU market or whose system's output is used in the EU, wherever the company is based.
This article is for engineering and product teams who need to know what the Act asks of a system they build or run, and what to put in the repository to prove it. It covers the timeline as amended by the AI Digital Omnibus, roles, a classification procedure you can encode, obligations per role, a worked example, and the failure modes that cause late surprises. It is a technical orientation, not legal advice: confirm your classification with counsel and against the consolidated text. For how the Act lines up with NIST AI RMF and ISO/IEC 42001, see AI safety frameworks, in depth.
The timeline as of October 2026
The Act entered into force on 1 August 2024 with staggered application dates. In 2026 the AI Digital Omnibus amended the high-risk dates; it was adopted in June, signed on 8 July and entered into force on 27 July 2026. The table reflects that amendment.
| Date | What applies |
|---|---|
| 2 February 2025 | Prohibited practices (Article 5) and the AI literacy duty (Article 4) |
| 2 August 2025 | General-purpose AI model obligations, governance bodies, the penalty regime |
| 2 August 2026 | Article 50 transparency duties, most remaining provisions, Commission fines on GPAI model providers |
| 2 December 2026 | Article 50(2) machine-readable marking for generative systems already on the market before 2 August 2026 |
| 2 August 2027 | GPAI models placed on the market before 2 August 2025 must comply; national regulatory sandboxes deadline |
| 2 December 2027 | High-risk systems listed in Annex III (stand-alone use cases), moved from 2 August 2026 |
| 2 August 2028 | High-risk systems that are safety components of products under Annex I legislation, moved from 2 August 2027 |
The deferral moved dates; it did not remove obligations. The stated reason was that harmonised standards and national authorities were not ready. Some summaries of the Omnibus also report new Article 5 prohibitions on systems generating non-consensual intimate imagery, applying from December 2026; sources disagree on this point, so check the published text before relying on it either way. Several changes proposed along the way, including to Article 4, should likewise be confirmed against the final consolidated text.
Roles decide your duties
A provider develops an AI system or has it developed and places it on the market or puts it into service under its own name. A deployer uses an AI system under its authority in a professional capacity. Importers and distributors sit in the supply chain, and a non-EU provider of a high-risk system needs an authorised representative in the EU. Providers of general-purpose AI models carry their own obligations, separate from any system built on their models.
Roles are not fixed by contract. Under Article 25 a deployer, distributor or importer becomes the provider of a high-risk system if it puts its name or trademark on it, makes a substantial modification, or changes the intended purpose of a system so that it becomes high-risk. That last case catches many teams: wrapping a general-purpose model in a product used to rank job applicants makes you the provider of a high-risk system, even though you trained nothing. Fine-tuning a GPAI model can also make you the provider of the modified model; the Commission's GPAI guidelines use an indicative threshold of modifications that use more than a third of the original model's training compute.
Classifying a system
Classify each AI system separately and in a fixed order. First, is it in scope at all: is it an AI system as defined in Article 3(1), and does an exclusion apply, such as military use or pure scientific research? Second, is it a prohibited practice under Article 5: manipulative or deceptive techniques that cause significant harm, exploiting vulnerabilities due to age, disability or a specific social or economic situation, social scoring, predicting crime purely from profiling, untargeted scraping of facial images, emotion recognition in workplaces and schools except for medical or safety reasons, biometric categorisation inferring sensitive traits, and real-time remote biometric identification in public spaces for law enforcement outside narrow exceptions.
Third, is it high-risk? Either it is a safety component of a product covered by Annex I legislation that requires third-party conformity assessment (machinery, medical devices, toys and so on), or its intended purpose falls in an Annex III area: biometrics, critical infrastructure, education, employment and worker management, access to essential private and public services (including credit scoring and life and health insurance pricing), law enforcement, migration and border control, and the administration of justice and democratic processes. Article 6(3) lets an Annex III system escape if it performs a narrow procedural task, improves the result of a completed human activity, detects decision patterns without replacing human assessment, or does preparatory work, but never if it profiles natural persons. A provider using that filter must document the assessment and still register the system.
Fourth, independently of the above, does Article 50 apply? Everything else is minimal risk, with the AI literacy duty and voluntary codes.
from dataclasses import dataclass, field
ANNEX_III = {"biometrics", "critical_infrastructure", "education", "employment",
"essential_services", "law_enforcement", "migration", "justice_democracy"}
@dataclass
class System:
name: str
is_ai_system: bool
prohibited_practice: str | None # Article 5 point, if any
annex_i_safety_component: bool # needs third-party conformity assessment
annex_iii_area: str | None
profiles_people: bool
art_6_3_condition: str | None # e.g. "narrow_procedural_task"
interacts_with_people: bool
generates_synthetic_content: bool
notes: list = field(default_factory=list)
def classify(s: System) -> dict:
if not s.is_ai_system:
return {"tier": "out_of_scope"}
if s.prohibited_practice:
return {"tier": "prohibited", "basis": s.prohibited_practice}
tier = "minimal"
if s.annex_i_safety_component:
tier = "high_risk_annex_i"
elif s.annex_iii_area in ANNEX_III:
if s.art_6_3_condition and not s.profiles_people:
s.notes.append("Art 6(3) derogation: document and register")
else:
tier = "high_risk_annex_iii"
art50 = [d for d, on in [("50(1) disclose AI interaction", s.interacts_with_people),
("50(2) machine-readable marking", s.generates_synthetic_content)] if on]
return {"tier": tier, "article_50": art50, "notes": s.notes}The function is a checklist made executable, not a legal oracle. Its value is that every system in the inventory gets the same questions, and the inputs become reviewable data.
Obligations by role
Providers of high-risk systems carry the heaviest load, in Articles 9 to 17 and 43 to 49: a risk management system across the lifecycle; data governance for training, validation and test data, including examination for bias; technical documentation following Annex IV; automatic logging; instructions for use; designed-in human oversight; appropriate accuracy, robustness and cybersecurity; a quality management system; a conformity assessment, which for most Annex III systems is internal control; CE marking; registration in the EU database; post-market monitoring; and serious incident reporting under Article 73, generally within 15 days and faster for deaths or widespread incidents.
Deployers of high-risk systems (Article 26) must use them according to the instructions, assign human oversight to people with the competence and authority to act, ensure input data they control is relevant, monitor operation, keep automatically generated logs for at least six months, and inform workers before using such systems at work. Public bodies, private entities providing public services, and deployers using credit scoring or life and health insurance pricing must also complete a fundamental rights impact assessment (Article 27). See human-in-the-loop controls for designing oversight that is real rather than a rubber stamp.
Article 50 duties are lighter but broad: providers must design systems that talk to people so users know they are dealing with AI unless it is obvious; providers of generative systems must mark synthetic audio, image, video and text in a machine-readable, detectable way; deployers must disclose deepfakes, disclose AI-generated text published to inform the public on matters of public interest unless it has had human editorial review, and inform people exposed to emotion recognition or biometric categorisation. The marking techniques are covered in content provenance.
General-purpose model providers (Article 53) must keep technical documentation, give downstream providers the information they need to comply, maintain a policy to comply with EU copyright law including text-and-data-mining opt-outs, and publish a summary of training content using the AI Office template. Models trained with more than 10 to the 25 floating-point operations are presumed to carry systemic risk and must also be evaluated, including adversarial testing, have systemic risks assessed and mitigated, report serious incidents and maintain cybersecurity (Article 55). The General-Purpose AI Code of Practice, published in July 2025, is voluntary, but signing it is a recognised way to demonstrate these duties; non-signatories must show compliance by other adequate means.
Penalties
Under Article 99, prohibited practices can draw fines of up to 35 million euros or 7 percent of worldwide annual turnover, whichever is higher; most other breaches, including Article 50, up to 15 million euros or 3 percent; supplying incorrect or misleading information to authorities, up to 7.5 million euros or 1 percent. For SMEs the lower of the two figures applies. Fines on GPAI model providers are imposed by the Commission, up to 15 million euros or 3 percent.
Worked example: a hiring product
A company sells a recruitment platform to EU employers. It has two AI features: a ranking service that scores CVs against a job description using a third-party general-purpose model through an API, and a chat assistant that answers candidates' questions about the process.
The ranking service is in scope and not prohibited. Its intended purpose, analysing and filtering job applications, sits in Annex III point 4 (employment). The Article 6(3) filter does not help because scoring candidates profiles natural persons. It is a high-risk Annex III system, and the company is its provider because it sells it under its own name, even though it did not train the model. Its high-risk obligations apply from 2 December 2027. The employers are deployers: they owe human oversight, log retention and worker information. The model vendor owes Article 53 information to the company, which the company needs for its own technical documentation, so that clause belongs in the procurement contract now.
The chat assistant is not high-risk, but it interacts with people, so Article 50(1) disclosure has applied since 2 August 2026. A line in the chat header stating that the assistant is an AI system meets the intent. The work plan therefore has a short item due already and a long programme due in late 2027: risk management, bias examination of the ranking on representative data, Annex IV documentation, logging, an oversight design that lets recruiters see and override scores, a quality management system and registration.
Evidence as code
Regulators and auditors ask for evidence, and evidence assembled by hand before an inspection is always incomplete. Keep an inventory record per AI system in the repository, reviewed like code, and generate documentation from it. LLM audit preparation covers turning such records into populations an auditor can sample.
# ai-inventory/cv-ranker.yaml
system: cv-ranker
owner: talent-ml-team
role: provider # Article 25 reasoning in docs/role.md
intended_purpose: rank applications against a job description
classification:
tier: high_risk_annex_iii
annex_iii: "4(a) recruitment and selection"
art_6_3: not_available # profiles natural persons
article_50: []
applies_from: 2027-12-02
upstream_models:
- vendor: example-gpai-vendor
art_53_docs_received: 2026-09-15
evidence:
risk_register: docs/risk/cv-ranker.md
bias_eval: evals/cv-ranker/bias-2026-09.json
logging: logging/schema/cv-ranker.json
oversight: docs/oversight/recruiter-override.md
review: { last: 2026-09-30, next: 2026-12-31 }
Failure modes
- Classifying the company instead of the system. One organisation can be a provider for one system, a deployer for another and outside scope for a third.
- Assuming an API wrapper carries no duties. Intended purpose, not model ownership, decides high-risk status, and your name on the product makes you the provider.
- Reading the deferral as a reprieve. Data governance, bias evaluation and logging changes take a year or more; December 2027 is close for a system you have to re-engineer.
- Silent purpose drift. A support tool that sales starts using to score leads for credit decisions has changed intended purpose. Re-run classification on every material feature change.
- Overlooking Article 50 because nothing is high-risk. Chatbot disclosure and synthetic content marking already apply.
- Treating the GDPR as covering it. Personal data duties continue in parallel; see GDPR for LLM systems. The AI Act does not replace them.
What to do next
- Build an inventory of every AI system you provide or deploy in the EU, with owner and intended purpose.
- Run each through the four-question classification and record every answer and its evidence, including Article 6(3) assessments.
- Ship Article 50 disclosure and marking now for any system that talks to people or generates media or text.
- For each high-risk system, plan backwards from 2 December 2027 or 2 August 2028: risk management, data governance, logging, oversight, documentation, conformity assessment and registration.
- Add Article 53 information duties and incident-notification terms to contracts with model vendors.
- Add a classification check to the product change process so a new intended purpose triggers review.
- Re-read the consolidated text after each amendment and confirm unsettled points with counsel.