EU AI Act, in depth: an engineering guide to classification, evidence and the 2026 to 2028 deadlines

The shape of the regulation

Regulation (EU) 2024/1689 entered into force on 1 August 2024 and applies in stages. It regulates by risk tier, and it assigns duties by role. The tiers are: practices that are prohibited outright; high-risk systems, which carry most of the obligations; systems with specific transparency duties; and everything else, which is largely unregulated by the Act beyond a general duty to support AI literacy. Separately, it regulates general-purpose AI (GPAI) models, the foundation models underneath many products.

The main roles are the provider, who develops a system or model and places it on the market or puts it into service under its own name; the deployer, who uses a system in a professional capacity; and importers and distributors. Roles attach to each system, not to the company. If you fine-tune a third-party model and ship it in your product, you are a deployer of the model API you call and the provider of the product built on it. A deployer who puts its own name on a high-risk system, or substantially modifies one, can become its provider.

The Act has extraterritorial reach: it applies to providers placing systems on the EU market and to providers and deployers outside the EU whose system's output is used in the EU.

Classifying a system

Classification is the decision everything else depends on, so make it explicit and write it down for every system in your inventory.

1. Is it an AI system at all? The Act's definition centres on a machine-based system that infers from its inputs how to generate outputs such as predictions, content, recommendations or decisions. A fixed rules engine typically falls outside; an ML model or LLM-based feature typically falls inside. The Commission has published guidelines on the definition.
2. Is it prohibited? Article 5 bans practices including manipulative or deceptive techniques that cause significant harm, exploiting vulnerabilities due to age or disability, social scoring, untargeted scraping of facial images to build recognition databases, emotion recognition in workplaces and schools (with medical and safety exceptions), and certain biometric categorisation and real-time remote biometric identification uses. These have applied since 2 February 2025. The 2026 amendment adds a prohibition on systems that generate or manipulate non-consensual intimate imagery or child sexual abuse material, operative from 2 December 2026; check the final text for its exact scope.
3. Is it high-risk? Two routes. Annex I covers AI that is a safety component of, or is itself, a product under listed EU product legislation, such as machinery, medical devices or toys, when that product needs third-party conformity assessment. Annex III lists use cases: biometrics, critical infrastructure, education, employment and worker management, access to essential services including credit scoring and insurance pricing, law enforcement, migration, and justice and democratic processes.
4. Does the Article 6(3) exception apply? An Annex III system is not high-risk if it does not pose a significant risk of harm, for example because it performs a narrow procedural task or improves the result of a completed human activity. The exception never applies if the system profiles natural persons. A provider relying on it must document the assessment.
5. Do Article 50 transparency duties apply? These cover systems that interact with people, generate synthetic content, perform emotion recognition or biometric categorisation, or produce deepfakes.

High-risk obligations as engineering artefacts

Articles 9 to 15 set the requirements for high-risk systems, and Article 17 requires a quality management system around them. Read as engineering work, each one names something you build, keep and can show to an assessor.

Providers also need a conformity assessment before placing the system on the market (Article 43). For most Annex III systems this is an internal control procedure, without a notified body; Annex I products follow their own sectoral procedures. They also need an EU declaration of conformity, CE marking, registration in the EU database, and post-market monitoring (Article 72) feeding serious incident reports (Article 73) to market surveillance authorities within short fixed deadlines.

Logging that satisfies Article 12

Logging is where engineering choices most directly decide whether you can comply. The Act requires logs that allow the system's functioning to be traced and that support post-market monitoring and the identification of risky situations. Providers must keep the logs under their control, and deployers the logs they hold, for a period appropriate to the purpose and at least six months unless other law says otherwise. A record per decision usually looks like this:

{
  "event_id": "01J9Z6R8K4...",
  "timestamp": "2026-10-01T14:03:22.418Z",
  "system_id": "credit-scoring-eu",
  "system_version": "4.7.2",
  "model_version": "gbm-2026-09-12-a1f3",
  "input_ref": "s3://evidence/inputs/01J9Z6R8K4.json.enc",
  "input_hash": "sha256:7c1e...",
  "output": {"score": 0.31, "decision": "refer_to_human"},
  "explanation_ref": "s3://evidence/expl/01J9Z6R8K4.json",
  "human_reviewer": "rev-0193",
  "human_action": "approved_with_override",
  "policy_flags": ["low_confidence"]
}

Store inputs by reference and hash rather than inline, encrypt them, and apply data-protection retention rules; the Act's logging duty sits alongside the GDPR, not above it, and the two must be reconciled. Make the store append-only with integrity protection, so the record still stands up under dispute. The mechanics are covered in audit logging for LLM systems, and the data-protection side in GDPR for LLM applications.

Human oversight is a design feature

Article 14 is often misread as "have a human somewhere in the loop". It actually asks the provider to design the system so that the people overseeing it can understand its capabilities and limits, notice anomalies, avoid over-relying on its output, interpret it correctly, and decide not to use it, override it or stop it. That is a user-interface and workflow requirement. A reviewer who sees only an approve button and approves 99.8 percent of recommendations is not oversight.

Practical patterns: show confidence and the main factors with each recommendation; route low-confidence and out-of-distribution cases to review by default; require a reason for overrides and log it; sample approved cases for second review; and monitor reviewer agreement rates as a signal of automation bias. Deployers then have their own duties under Article 26: assign oversight to trained staff, monitor operation, keep logs and inform affected workers. Certain deployers, including public bodies and providers of essential services, must also carry out a fundamental rights impact assessment. Patterns for review queues are in human-in-the-loop controls.

Article 50: transparency for chatbots and generated content

Article 50 applies to far more products than the high-risk rules, including most LLM applications, and it applies from 2 August 2026. Providers must design systems that interact directly with people so users are informed they are dealing with an AI, unless that is obvious from the context. Providers of systems that generate synthetic audio, images, video or text must mark outputs in a machine-readable format so they are detectable as artificially generated, using technical solutions that are effective, interoperable, robust and reliable as far as technically feasible. Deployers must disclose deepfakes, and AI-generated text published to inform the public on matters of public interest unless it has undergone human editorial review.

For the marking duty, the 2026 amendment gives providers of generative systems already on the market before 2 August 2026 until 2 December 2026 to implement it. The disclosure duties are not delayed. Engineering choices include metadata-based provenance such as C2PA content credentials, watermarking in the generated signal, and logging that lets you check a piece of content against your own outputs; each has known weaknesses against stripping or transformation, so combine them. See content provenance for the trade-offs.

General-purpose AI models

Obligations for GPAI model providers have applied since 2 August 2025 (Article 53): technical documentation for the AI Office and for downstream providers, a policy to comply with EU copyright law including text-and-data-mining opt-outs, and a public summary of training content using the Commission's template. Open-source models released under a free licence are exempt from some of these unless they present systemic risk. Models trained with more than 10^25 floating-point operations are presumed to have systemic risk and must also perform model evaluations including adversarial testing, assess and mitigate systemic risks, report serious incidents and ensure adequate cybersecurity (Article 55). A voluntary General-Purpose AI Code of Practice, published in July 2025, is the main route for demonstrating compliance. The Commission's power to fine GPAI providers applies from 2 August 2026, and models placed on the market before 2 August 2025 have until 2 August 2027.

If you only call a GPAI model through an API, these duties sit with the model provider, but you will need what they publish, documentation and acceptable-use terms, to complete your own technical documentation. If you fine-tune or modify a GPAI model significantly, check whether you have become a provider of a modified model.

The timetable after the 2026 Digital Omnibus

In 2026 the EU adopted a targeted amendment, the Digital Omnibus on AI, mainly because harmonised standards and national authorities were not ready for the original high-risk deadline. It was approved by Parliament and Council in June 2026 and published in the Official Journal in July 2026. The resulting dates for planning:

The delay changes when enforcement starts, not what is required. Annex IV documentation and Article 12 logging are hard to produce retroactively: you cannot backfill a log of decisions you did not record. Teams that use the extra time to build the evidence pipeline will be ready; teams that pause will be in the same position in 2027. Penalties reach up to 35 million euros or 7 percent of worldwide annual turnover for prohibited practices, and up to 15 million euros or 3 percent for most other breaches.

Building compliance into delivery

• Inventory as code. Keep a machine-readable register of AI systems with owner, purpose, role, classification and rationale, reviewed on every material change, not once a year.
• Documentation generated from source. Produce Annex IV sections from the model registry, evaluation reports and architecture docs in the release pipeline, so the documentation describes the version that shipped.
• Evaluation gates. Declare accuracy and robustness metrics with their conditions, test them on every release, and block releases that regress. Include security testing; red teaming provides evidence for Articles 9 and 15.
• Change control. Define what counts as a substantial modification, which can trigger a new conformity assessment, and make retraining or a model swap pass through that decision.
• Incident path. Wire monitoring alerts to a triage process that can decide within days whether something is a serious incident, because Article 73 deadlines are counted in days.

What to do next

1. Build the inventory: every AI system, its owner, intended purpose, your role, and the models and vendors it depends on.
2. Classify each system against Article 5, Annex I, Annex III and Article 50, record the reasoning, and have counsel review the high-risk and Article 6(3) decisions.
3. For LLM and generative features, ship Article 50 disclosures and content marking now; the transparency duties apply from 2 August 2026.
4. For each high-risk candidate, start the risk register, dataset cards and Article 12 decision logging now, even though enforcement starts on 2 December 2027.
5. Design oversight into the interface: confidence, reasons, override with justification, and monitoring of reviewer agreement.
6. Automate Annex IV documentation and evaluation gates in the release pipeline.
7. Collect GPAI providers' documentation for every model you depend on, and track the harmonised standards and Commission guidelines as they are published.