The EU AI Act for AI Product and Engineering Teams: What You Actually Have to Build

TL;DR: What the EU AI Act Requires and When

The EU AI Act (Regulation (EU) 2024/1689) sorts AI systems into four risk tiers and attaches obligations to each. The high-risk regime, the one that actually generates engineering work, was deferred in July 2026 and now applies from 2 December 2027 for standalone Annex III systems and 2 August 2028 for AI embedded in Annex I products. Everything below is checked against the consolidated text as amended on 27 July 2026.

If you have seen a version of this timeline with an August 2026 high-risk deadline, it predates the amendment. Most secondary coverage still carries the old dates.

What Is the EU AI Act?

The EU AI Act is an EU regulation that governs artificial intelligence systems by risk level. It entered into force on 1 August 2024 and applies in phases. It exists to replace a patchwork of national AI rules with one harmonised rulebook that reads the same in Lisbon and in Warsaw.

The Act applies to providers, deployers, importers, and distributors of AI systems, and the obligations depend on which role you play. For product and engineering teams the practical question is narrower than the legal theory: does this affect what we ship, and what do we have to build and document.

That harmonisation is good news operationally. Compliance work done for one EU market covers all of them. The tradeoff is a dense rulebook that now runs to 113 numbered articles plus six inserted by the 2026 amendment, written in risk-tier language that does not map onto how engineering teams describe their own systems.

Where this guide sits next to our other compliance posts. This one covers the EU AI Act alone, article by article, and stops at the boundary of engineering work. If you need the multi-regulation view, LLM safety and AI regulations maps the EU AI Act against NIST AI RMF and ISO 42001 and tells you what is binding versus voluntary. The GenAI compliance framework covers how the AI Act layers on top of GDPR, CCPA and sector rules. AI agent compliance and governance is the runtime playbook for enforcing policy in production. For a one-paragraph definition, see the EU AI Act glossary entry.

Does the EU AI Act Apply to Your Team?

Yes, if your AI system’s output is used by or affects people in the EU, regardless of where your company is based. That extraterritorial reach catches far more non-EU companies than product teams expect.

The role you play determines which obligations apply. A US company that calls OpenAI’s or Anthropic’s API and ships a feature to EU users is typically a deployer of that system, not a provider of the model. Deployer status still carries real duties under Article 26: assign human oversight to competent people, monitor the system in operation, keep the logs, and notify the provider and market surveillance authority on a serious incident.

A single company can hold both roles at once. Fine-tuning a third-party foundation model for a specific EU-facing use case can move you from deployer to provider for that system, because substantial modification is one of the Act’s own triggers for reclassification. Teams that customise models beyond prompting should treat this as a live question.

This section is informational, not legal advice. Role determination and risk classification carry financial consequences, so have counsel confirm your status before you build a compliance plan on top of it.

The Four Risk Tiers, Explained

The EU AI Act sorts every AI system into one of four risk tiers, and the tier determines what you document, what you test, and how much exposure you carry when something goes wrong.

Unacceptable Risk (Prohibited)

This tier bans practices outright, with no compliance path. Article 5’s list includes social scoring, manipulative or subliminal techniques causing significant harm, untargeted scraping of facial images, emotion recognition in workplaces and schools, certain biometric categorisation, and real-time remote biometric identification in public spaces for law enforcement, subject to narrow exceptions.

Most of that list has been banned since 2 February 2025. Two prohibitions are newer and land later. The 2026 amendment added Article 5(1)(ba) and (bb), covering AI systems that generate or manipulate non-consensual intimate imagery of an identifiable person and AI systems that generate child sexual abuse material. Both apply from 2 December 2026, not February 2025. If you ship image, video or audio generation, that is a real deadline on your calendar this year, and Article 5(1a) makes clear it bites when such generation is a reasonably foreseeable and reproducible outcome of the system without adequate safeguards, not only when it is the stated purpose.

High-Risk

High-risk splits two ways. Annex III lists eight areas: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration and border control, and administration of justice and democratic processes. Annex I covers AI used as a safety component of a product already subject to third-party conformity assessment, such as medical devices and in-vitro diagnostics, lifts, pressure equipment, and toys. Machinery was removed from the Annex I list by the 2026 amendment and is handled under the machinery Regulation instead.

Being listed in Annex III is not the end of the analysis. Article 6(3) lets a system out of the high-risk tier if it does not pose a significant risk of harm, for example because it performs a narrow procedural task, improves the result of completed human work, or performs a preparatory task. Two conditions bound that escape hatch. Article 6(3) itself says a system that performs profiling of natural persons is always high-risk, derogation or not. And under Article 6(4) the provider has to document the assessment before placing the system on the market, and register under Article 49(2).

The 2026 amendment narrowed the Annex I route as well, and the exact wording carries the weight. Article 6(1a) excludes AI that is “solely used for non-safety related aspects of user assistance, performance optimisation, service efficiency, automation or convenience or quality control” from counting as a safety component. Drop the bolded qualifier, as a lot of secondary coverage does, and the exclusion reads far wider than it actually is.

Article 6(1b) then pulls back: if the failure or malfunction of that AI would endanger health and safety, it counts as a safety component regardless. A new Article 6(1c) also carves out products that need third-party assessment only for reasons like radio-spectrum or electromagnetic interference that do not affect health and safety.

Limited Risk (Transparency Obligations)

Chatbots, deepfakes, synthetic content, and emotion-recognition or biometric-categorisation systems land here. Article 50(1) requires telling a person they are interacting with an AI system unless it is obvious. Article 50(2) requires providers of systems generating synthetic audio, image, video or text to mark the output in a machine-readable format. Article 50(4) puts disclosure duties on deployers who publish deepfakes or AI-generated text on matters of public interest.

Minimal Risk

Everything else, with no AI Act-specific obligations. General product law and data protection law, including GDPR, still apply at every tier.

What Changed in July 2026, and What Deadline Applies Now?

Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026 and rewrote Article 113. The two high-risk deadlines moved, and they moved by more than a year.

Standalone high-risk systems under Article 6(2) and Annex III now have until 2 December 2027, a sixteen-month deferral from 2 August 2026. AI classified as high-risk under Article 6(1) and Annex I now has until 2 August 2028, a twelve-month deferral from 2 August 2027. The European Commission’s AI Act page confirms both.

Two dates never moved. The original prohibited practices and the AI literacy duty took effect on 2 February 2025, and only the two prohibitions added in 2026 sit later. General-purpose AI model obligations, governance and penalty provisions began on 2 August 2025.

Article 50 transparency also stayed on schedule and has applied since 2 August 2026. One narrow transitional carve-out is widely misreported, so read it precisely: Article 111(4) gives providers of systems generating synthetic audio, image, video or text that were already on the market before 2 August 2026 until 2 December 2026 to comply with Article 50(2) only, the machine-readable marking duty. It does not extend the Article 50(1) duty to tell users they are talking to an AI. That one has been live since August.

There is a second transitional rule worth knowing before you panic about legacy systems. Under Article 111(2), high-risk systems already placed on the market before the Chapter III application date only come into scope if they undergo significant changes in design after that date. Public-authority deployments are the exception and have until 2 August 2030 regardless.

The Commission’s stated reason for the deferral is that harmonised standards, common specifications, and national conformity-assessment infrastructure were not ready, not that the obligations changed. The practical read is that the work is the same work, with more runway. Conformity assessment, Annex IV documentation, and evaluation infrastructure take months to build, and the significant-modification trigger can reopen a system your team assumed was settled. Start mapping now.

What Do You Have to Prove for a High-Risk System?

The Chapter III Section 2 Requirements

Chapter III, Section 2 sets seven requirements for high-risk systems, one per article: a continuous risk management system (Article 9); data governance covering training, validation and test data quality plus bias examination (Article 10); technical documentation to the Annex IV template (Article 11); automatic logging over the system lifetime (Article 12); transparency and instructions for use for deployers (Article 13); human oversight measures (Article 14); and accuracy, robustness and cybersecurity (Article 15).

Article 16 then lists twelve provider obligations on top of those requirements, including a quality management system, conformity assessment before market placement, the EU declaration of conformity, CE marking, and registration in the EU database.

One 2026 addition matters directly to anyone running fairness evaluations. Article 4a now permits providers of high-risk systems to process special categories of personal data where strictly necessary for bias detection and correction under Article 10(2)(f) and (g), subject to safeguards. Before that, the honest answer to “how do we measure demographic bias without holding demographic data” was awkward.

Article 4a(2) matters more to most readers, because it is not limited to high-risk providers. Deployers of high-risk systems, and providers and deployers of any other AI system or model, get the same carve-out where the processing is strictly necessary to catch bias likely to harm health and safety, damage fundamental rights, or produce unlawful discrimination — provided every safeguard in 4a(1) is applied. The Article also says plainly that it creates no obligation to run bias detection in the first place.

What Counts as a “Significant Modification”

Routine engineering work can trigger it. A model swap, a meaningful prompt rewrite, or a fine-tuning pass can amount to a substantial modification and reopen conformity assessment obligations a team assumed were closed.

The fix is unglamorous: version and log every material change to model, prompt, or data pipeline. Being able to show exactly what changed and when is the difference between a routine release and an unplanned re-assessment.

The table below adds one row beyond those seven: Article 43 conformity assessment sits in Section 5, not Section 2, but it is the gate everything else feeds into.

What If You Build on Someone Else’s Model?

Any team building on a general-purpose AI model needs to know what the model provider owes them. Under Article 53, GPAI providers must keep technical documentation, make information and documentation available to downstream providers integrating the model, put a copyright-compliance policy in place, and publish a sufficiently detailed summary of training content. Article 53(2) exempts some open-source models from the first two, but not models with systemic risk.

Article 51(2) presumes systemic risk once cumulative training compute exceeds 10^25 floating-point operations. That triggers the heavier Article 55 duties: model evaluation including adversarial testing, systemic risk assessment and mitigation, serious-incident reporting to the AI Office, and cybersecurity protection.

Almost no team outside the largest labs will train near that threshold. The relevance is indirect. Before you build on a provider’s API, ask two things: what documentation do they publish for downstream providers, and have they disclosed whether the model is classified as systemic risk. The answers tell you how much of your own obligation their paperwork covers and how much gap you fill with your own evaluation and logging.

Note the timing wrinkle for GPAI models that were already on the market. Article 111(3) gives providers of models placed on the market before 2 August 2025 until 2 August 2027 to comply. If your provider is relying on that window, their documentation may still be incomplete.

What Happens If You Get It Wrong?

Fines scale sharply with the type of violation, per Article 99. Prohibited practices under Article 5 carry up to EUR 35 million or 7% of total worldwide annual turnover, whichever is higher.

Non-compliance with operator obligations, including provider duties under Article 16, deployer duties under Article 26, and Article 50 transparency, sits at up to EUR 15 million or 3%. Supplying incorrect, incomplete or misleading information to notified bodies or national authorities carries up to EUR 7.5 million or 1%.

SMEs and start-ups get the lower of the amount or the percentage rather than the higher, under Article 99(6). The 2026 amendment extended a similar cap to small mid-cap companies for the 3% and 1% tiers.

The fine is often not the expensive part. National market surveillance authorities enforce in each member state and can order a non-compliant system withdrawn from the market. For a product team, a withdrawal order stops revenue immediately.

Building Compliance Into Your Engineering Workflow, Not Bolting It On

Most high-risk obligations map onto work engineering teams already do, or should. Logging, human oversight, robustness testing and record-keeping are not separate compliance tasks bolted onto a shipped product. They are instrumentation and evaluation that belongs in the pipeline from day one.

The concrete practices are short. Version every model, prompt, and data change. Keep an audit trail of production decisions, not just a changelog. Maintain human-review queues for high-risk outputs. Run structured evaluation before and after every change, not only before first launch. Generate Annex IV documentation as a build artifact rather than a document someone writes the week before an audit.

Do not skip Article 4. AI literacy has been a live obligation since February 2025 for every provider and deployer, whatever tier your system sits in, and it is one of the few duties that already applies to teams with nothing high-risk in production. The 2026 amendment softened it: you must take measures to support staff AI literacy, but you are not required to guarantee any individual reaches a particular level. Training records are the evidence.

Some things stay firmly out of engineering’s lane. Risk classification, conformity assessment, and CE marking need legal and compliance sign-off. No platform self-certifies a system for you. Good instrumentation produces the evidence; it does not replace the judgment call sitting on top of it.

How Future AGI Supports EU AI Act Evidence Requirements

Future AGI is not a legal compliance or conformity-assessment tool. It does not classify risk tiers and it does not issue CE marks, so nothing here replaces the legal work above. What it does is produce the evidence those obligations ask for, as a byproduct of running the system.

Future AGI is open source and self-hostable. You can sign up free and run it as a managed service, or deploy the Agent Command Center inside your own network on Docker or Kubernetes, including air-gapped, which is usually the shorter conversation when EU data residency is the constraint. The open-source Agent Learning Kit (pip install ai-evaluation) runs 72 local metrics and sub-10ms guardrail scanners with zero API calls, so evaluation evidence can be generated without any request leaving your infrastructure.

Evaluate runs 50+ built-in evaluators and custom evals through a single evaluate() call, combining LLM-as-judge and deterministic scoring for groundedness, hallucination, PII exposure and rubric checks. That is evidence for the Article 15 accuracy and robustness requirement, and annotation queues put human reviewers on traces, sessions and eval output, which is the review record that supports an Article 14 human-oversight claim rather than the oversight mechanism itself.

Observe provides OpenTelemetry-native tracing across 30+ framework integrations, with span-level logs and latency, which is the automatic record-keeping Article 12 describes. Protect ships 28 guardrail checks: 10 first-party, including PII detection, prompt injection, secrets detection, content moderation, topic restriction, system-prompt protection and data-leakage prevention, and 18 provider-backed, including Llama Guard, Lakera Guard and GraySwan, plus tool-permission and MCP-security controls. Each rule is set to Enforce, Monitor, or Log, and guardrail decisions land on the trace, so the Article 15 robustness and cybersecurity story has a record behind it.

Simulate runs scripted phone-call and chat conversations against a voice or chat agent, covering accents, interruptions and edge cases before launch. That is pre-deployment testing evidence, not a substitute for the Article 43 conformity assessment.

One precision point, because it gets misstated. Future AGI’s SOC 2 Type II, ISO 27001 and HIPAA attestations cover the managed service. They do not transfer to a deployment you host yourself; a self-hosted install inherits your own control environment, and an auditor will treat it that way.

For turning existing instrumentation into audit-ready evidence, see the guides on AI model governance and observability versus monitoring for AI agents.

Where to Start Mapping Your Obligations

The EU AI Act rewards teams that build evidence into the pipeline early rather than reconstructing it before an audit. If you ship a standalone high-risk system, the date that matters is 2 December 2027. If your AI is embedded in an Annex I product, it is 2 August 2028. Article 50 transparency is already live, and the two new prohibitions land on 2 December 2026.

The next step is a two-column map: which risk tier each system falls into, and which engineering artifact already covers each obligation for that tier. Version control, traces, eval runs and review queues usually cover more of it than teams expect. Start with the systems where a model or prompt change is likely in the next year, because that is where the significant-modification trigger bites first.

This article is informational and not legal advice. EU AI Act role determination, risk classification, and conformity assessment require qualified legal counsel familiar with your specific system and jurisdiction.