The EU AI Act for Engineering Teams: What You Must Ship, and by When

Almost everything written about the EU AI Act is written for lawyers. It is accurate, it is thorough, and it is close to useless on a Tuesday when an engineering lead has to decide whether the retrieval service needs an audit log this quarter or next year. The Act gets summarised into obligations, the obligations get forwarded to engineering, and somewhere in that handoff the actual question goes missing: what are we building, and by when.

This guide answers that. It reads the Act as a build list — what is already in force, what starts applying next, how to work out whether a given system is even in scope, and the specific artifacts your team has to produce. It is written for the people who will implement it, not the people who will sign off on it.

One thing to be clear about first: this is engineering guidance, not legal advice. The obligations described here are structural, drawn from the published implementation timeline, and your legal counsel owns the interpretation for your specific product. What follows is the part engineering owns.

What already applies, and what lands on 2 August 2026?

The Act does not arrive all at once. It applies in phases, and the phase boundaries are what determine your roadmap. Working from the published implementation timeline:

Already in force

2 February 2025 — the prohibitions on certain AI practices, together with the AI literacy requirements, started to apply (Chapters I and II). If you are running anything in the prohibited categories, that deadline is well behind you.

2 August 2025 — rules on general-purpose AI (GPAI) models under Chapter V, governance under Chapter VII, notified bodies, confidentiality under Article 78, and the penalties regime under Articles 99 and 100 all started to apply.

2 February 2026 — the deadline for the Commission to provide guidelines on the practical implementation of Article 6, including post-market monitoring, under Article 112(1).

The one in front of you

2 August 2026 — under Article 113, the remainder of the Act starts to apply, with the exception of Article 6(1). This is the milestone that turns the high-risk regime into an operating reality for most teams: it is the point at which the Regulation applies to operators of high-risk AI systems. Member States must also have at least one AI regulatory sandbox operational at national level by this date, under Article 57.

Still ahead

2 August 2027 — Article 6(1) and its corresponding obligations start to apply. Providers of GPAI models that were placed on the market before 2 August 2025 must be compliant by this date.

2 August 2030 — providers and deployers of high-risk systems intended for use by public authorities must have completed the steps needed to comply. Separately, AI systems that are components of the large-scale IT systems listed in Annex X and were placed on the market before 2 August 2027 have until 31 December 2030.

The practical read: if you build or deploy anything that could land in the high-risk category, the 2 August 2026 boundary is the one that governs your current planning cycle, not a future one.

Does the Act actually apply to your system?

Most engineering teams lose weeks here, because the answer is decided by what the system is used for rather than by what it is built from. A gradient-boosted model and a large language model can land in completely different tiers, and two identical models can land in different tiers depending on deployment context. The high-level summary of the Act and the European Commission regulatory framework page are the reference points; the shape of the decision is below.

Choose the prohibited tier if:
- The system does something in the banned categories that took effect on 2 February 2025
- No amount of documentation or oversight changes that answer
- This is a stop-shipping conversation, not a compliance-workstream conversation

Choose the high-risk tier if:
- It is used in one of the regulated contexts the Act designates as high-risk
- A wrong output materially affects a person's access to employment, education, credit, essential services or legal standing
- It operates as a safety component of a regulated product
- If you are arguing internally about whether it qualifies, plan as though it does until counsel says otherwise

Choose the transparency tier if:
- Users interact with it directly and could reasonably not realise they are dealing with an AI system
- It generates or manipulates content that could be mistaken for authentic
- The obligation is disclosure rather than a full control framework

There is a separate track for general-purpose AI models under Chapter V, in force since 2 August 2025, which matters if you are a provider of such a model rather than someone building on top of one. For most product teams building applications, you are a deployer of someone else's GPAI model and a potential provider of your own system — and those are two different sets of obligations that people routinely conflate.

What does engineering actually have to ship?

This is the translation that usually goes missing. For a system in the high-risk category, the obligations resolve into artifacts — things that exist in your repository and your infrastructure, not things a policy document asserts.

A risk management process that leaves a trail

Not a document written once. A repeatable process, with records, that runs across the lifecycle and is revisited when the system changes. Engineering's part is making the record a by-product of how you already work rather than a separate artifact someone assembles before an audit.

Data governance evidence

What went into training, validation and testing; where it came from; what you did about known gaps and bias. If your training pipeline cannot currently answer "which data version produced this model", that is the first gap to close, and it is an engineering gap rather than a policy one.

Technical documentation

A description of the system complete enough for an assessor to understand how it works and why it behaves as it does. The teams that suffer least here are the ones generating documentation from the system rather than writing it alongside.

Automatic logging and traceability

The system must record events over its lifetime to a standard that supports tracing an outcome after the fact. In practice: durable, queryable inference logs with inputs, model and prompt versions, retrieval context where relevant, and outputs — retained long enough to answer a question asked months later. This is the single most common thing missing when we audit an existing system.

Human oversight that actually functions

A named person must be able to understand, intervene in and override the system. Engineering owns whether that is genuinely possible: is there an override path, does it work under load, is it exercised, and is the exercise recorded.

Accuracy, robustness and cybersecurity

Declared performance characteristics with evidence behind them, and resilience against manipulation. For anything language-model based this means a real evaluation suite with recorded results over time, not a launch-week benchmark screenshot.

Post-market monitoring

Ongoing observation of how the system behaves in the field, with a route for incidents to come back into the risk process. Article 112(1) specifically anticipated Commission guidance on the practical implementation of this area.

Read that list again and notice what it mostly is: logging, versioning, evaluation, documentation and an override path. Four of those seven are things a well-run engineering organisation already wants for its own reasons — which is why the teams that treat this as an engineering-quality programme finish faster than the teams that treat it as a legal exercise.

What breaks when compliance is retrofitted late?

The failures are predictable, and they are all consequences of the same thing: the evidence the Act asks for is generated at runtime, so it cannot be recreated retrospectively.

• The logs do not exist for the period you are asked about. You can start logging today, but you cannot log last quarter. Every month without traceable inference logs is a month you cannot evidence, and no amount of engineering effort recovers it.
• No data lineage. The model in production was trained by someone who has left, from a dataset that was overwritten. Reconstructing provenance after the fact ranges from expensive to impossible, and it blocks the documentation obligation entirely.
• Evaluation exists as a screenshot. Someone ran a benchmark before launch and pasted the result into a slide. There is no eval suite, no history, no way to show the system still performs as declared — which is the actual obligation.
• Human oversight is theoretical. There is an override in the admin panel that nobody has used in eleven months and that fails when the queue is deep. Untested oversight is not oversight.
• Documentation drifts from the system. Hand-written docs describe last year's architecture. The gap is invisible until an assessor finds it, and then the remediation is a rewrite under time pressure.
• The roadmap freezes. The costliest failure. Teams that leave it late end up stopping feature work for a quarter, because the retrofit touches the data layer, the inference path and the release process simultaneously.

We see the same pattern in adjacent regimes: the enterprise AI security review and data residency questions both reward the teams who designed for evidence early and punish the ones who bolted it on. It is the same discipline that separates a demo-grade retrieval system from a production RAG system that survives contact with real traffic.

How do you build for it without freezing the roadmap?

The workable approach is to make the evidence a by-product of normal operation, so compliance stops being a project and becomes a property of the system.

Concretely, four moves cover most of it. Make inference logging structural — every call records model version, prompt version, retrieval context, inputs, outputs and the decision path, to durable storage with a defined retention period. Version everything that influences an output, so "which data and which model produced this" is a query rather than an investigation. Run evaluations continuously in the pipeline rather than at launch, so declared performance has a history behind it. And put the override path in the product rather than the admin panel, then exercise it deliberately so you can show it works.

Notice that none of those four are compliance features. They are the same capabilities that make an AI system debuggable, improvable and safe to operate. That is the argument to take to a product owner who is protective of roadmap: you are not spending a quarter on paperwork, you are spending it on observability that happens to satisfy a regulator.

Where a genuine compliance-only cost remains — documentation packages, conformity work, the formal risk file — scope it as its own workstream with its own owner, and keep it out of the engineering backlog where it will lose every prioritisation argument against shipping features.

If you want the tooling landscape rather than the obligations, our review of AI compliance tools covers what is available to buy. For the architecture question underneath all of this, an architecture audit is usually the faster route to knowing where you actually stand, and our AI governance and compliance work covers the programme end to end.

Where should a team start this week?

Start with scope, because everything downstream depends on it. List every AI system you build or deploy, and put each one in a tier. Most teams discover they have more systems than they thought and that a few of them are in a tier nobody expected.

Then audit for evidence, not for compliance. For each system ask one question: if someone asked us to explain a specific output from three months ago, could we? That single question surfaces the logging, versioning and lineage gaps faster than any framework, and those gaps are the ones that cannot be closed retroactively.

Then fix logging first, regardless of what else is on the list. It is the only obligation where every day of delay permanently destroys evidence you will later be asked for. Documentation can be written later. Logs cannot.

And get the tier classification confirmed by someone who owns the legal interpretation. Engineering can and should do the initial pass — you know what the systems do — but the classification decides the size of the entire programme, and it is the wrong thing to be confidently wrong about.

Frequently asked questions

When does the EU AI Act actually apply to my system?

In phases. Prohibitions and AI literacy obligations applied from 2 February 2025. GPAI model rules, governance and the penalties regime applied from 2 August 2025. Under Article 113, the remainder of the Act — including application to operators of high-risk systems — starts to apply on 2 August 2026, with Article 6(1) and its related obligations following on 2 August 2027. Which of those dates governs you depends entirely on your system's tier and your role as provider or deployer.

Does the Act apply to a company outside the EU?

Scope follows the market rather than your registered address: what matters is whether your system is placed on the market or used within the EU, and whether its outputs are used there. A US or UAE company serving EU users should assume it is in scope and confirm with counsel, rather than assuming geography exempts it. This is the single most common misreading we encounter.

Is a large language model automatically high-risk?

No. The tier follows the use case, not the technology. A language model summarising internal documents and the same model screening job applicants sit in very different places. There is also a separate obligation track for providers of general-purpose AI models under Chapter V, in force since 2 August 2025, which is distinct from the high-risk regime applying to systems.

What is the difference between a provider and a deployer?

Broadly, a provider develops the system and places it on the market; a deployer uses it. Most product teams building on someone else's foundation model are deployers of that model and providers of their own system, which means they carry obligations in both directions. Getting this wrong is common and consequential, because the two roles owe different things.

What happens if we are not ready by the deadline?

The penalties regime under Articles 99 and 100 has applied since 2 August 2025, and the exposure is significant enough that it is a board-level matter rather than an engineering one. The more useful framing for a technical team is that the evidence obligations are time-dependent: fines are a legal question, but missing logs are an engineering fact that no remediation budget can undo.

Can we buy a tool that makes us compliant?

Tools help with documentation, monitoring and evidence collection, and they are worth having. What they cannot do is generate logs your system never produced, reconstruct data lineage you did not keep, or make an override path work that was never wired in. Buy tooling to reduce the manual burden, not to substitute for the engineering changes underneath.

Need help scoping your EU AI Act work?

We audit AI systems against the obligations above and come back with a tiered list: what is missing, what is recoverable, and what has to be built before the deadline that applies to you. You keep the assessment either way.

Get a scoped assessment →

Prefer to ask one question first? Send it here →

Related Services

• AI Governance & Compliance
• EU AI Act Compliance
• AI Architecture Audit

Further Reading

Best AI compliance tools Enterprise AI security review Enterprise AI data residency Production RAG failures