The EU AI Act and your product

For most of 2025 and early 2026, teams building AI features planned around August 2, 2026 as the date the EU AI Act's high-risk obligations would begin to apply. Shortly before that date, they were deferred.

What changed

The compliance date for standalone high-risk AI systems under Annex III moved from August 2, 2026 to December 2, 2027, and for AI embedded in products already covered by EU product safety law under Annex I, to August 2, 2028 [1][2].

The reason matters for how you should read it. The original timeline assumed that harmonised technical standards, notified bodies able to perform conformity assessments, and national supervisory authorities with the resources to supervise would all be in place. By late 2025 they were not ready: the harmonised standards work was behind schedule, supporting guidance was still in draft, and a number of member states had not designated or resourced market surveillance authorities [2].

So this is a delay caused by the supporting standards and authorities not being ready, not by a reconsideration of whether the requirements are wanted. Reading it as a signal that the obligations may be dropped without notice would be a mistake.

The distinction matters for a planning decision teams are making right now: whether to keep a compliance workstream staffed through the deferral or fold it back into general engineering until the new date gets closer. Folding it back is the natural response to a deadline moving more than a year out, and it is also how the same scramble happens again in 2027, because the obligations themselves, risk management across the lifecycle, data governance, lifetime logging, did not get easier to build while the calendar moved. A deferred date changes when a requirement is checked. It does not change how long the artefacts behind it take to build, and some of them take longer to build the more time passes before anyone starts, because they depend on a history that only accumulates once you begin recording it.

What did not change

The Article 50 transparency obligations were not deferred, including the requirement to disclose to users when they are interacting with an AI system [1]. Those proceed on the original schedule.

That is the provision most likely to reach an ordinary product today. It is also cheap to satisfy and worth doing regardless of jurisdiction, because a user discovering they were talking to a model after assuming otherwise is a trust problem in any market.

The prohibitions on unacceptable-risk practices and the AI literacy duty also remain where they were.

Why a deferral is harder to plan around than a deadline

A fixed date organises work. Everyone can see it, budgets get approved against it, and the argument about whether to start is settled by the calendar rather than by opinion. A deferral removes that organising force and replaces it with nothing, which is a real reason teams respond to one by stopping rather than by continuing at a slower pace.

The pattern is predictable, because it has happened before with other compliance deadlines that moved. Work scheduled against the original date gets moved to a backlog that nobody prioritises against features with a visible deadline. The engineer who did the original scoping analysis moves to a different project, or a different company. Months later the new date approaches, the analysis is out of date because the product has changed underneath it, and the people who understood the reasoning are gone. The work restarts nearly from the beginning, except now there is less runway than there was the first time.

There is a second cost that is easy to miss because it does not show up until the deadline is close. Some of the obligations in this Act are about history rather than a single point-in-time state. A logging requirement satisfied on the day it takes effect produces a log that starts that day, with no record of anything before it. An evaluation suite assembled the week before an assessment produces one measurement, not a demonstrated trend over time. Both kinds of requirement are ultimately about being able to show what the system has actually been doing, and a team that waits until the new date arrives can satisfy the words of the requirement while having a record that only goes back a week.

Whether you are in scope

Two questions, and neither is an engineering judgment.

Territorial scope. The Act's reach follows where systems are placed on the market or where their output is used, rather than where the developer is based. A team in the United States selling into the EU, or whose system's output is used in the EU, can be in scope. Assuming otherwise because your company is not European is the most common scoping error.

Risk category. Whether a system is high-risk depends on the enumerated categories, and several of them intersect directly with the industry guides on this site: employment and worker management, access to essential private and public services including creditworthiness evaluation, and certain uses in education and law enforcement. A screening or scoring product in housing or credit should assume this question is open rather than settled.

Both determinations belong with counsel. What engineering must provide is an accurate description of what the system does and decides, which is the decision inventory described on what regulation reaches a real estate product and applies equally to any sector.

Three scoping errors show up often enough to name, and each one is a description problem rather than a legal one, which is why engineering can prevent them before counsel is even asked to weigh in.

Describing the feature by its interface instead of its effect. A team calls something a recommendation, a ranking, or a score shown for information only. Those words describe what appears on the screen. The scoping question is what happens next: if an applicant who ranks low is never contacted, the system participates in the decision whether or not a human technically signed off on the outcome. Counsel cannot see that from a feature name alone, so the decision inventory has to record the effect, not the label the team gave the feature internally.

Assuming a third-party model moves the obligation to whoever built the model. Building a feature on a general-purpose model licensed from another company does not, by itself, move responsibility for how that feature behaves in your product to that company. The obligations attach to the system placed on the market, which is the one your users interact with. This matters more as the number of models inside a single product grows, because it becomes harder to say what the product actually decides without listing every place a model's output reaches a person.

Treating a small pilot as out of scope because it has few users. Scope follows what the system is and where its output is used, not how many people are currently using it. A pilot that is expected to become the production system is worth scoping while it is still a pilot, because that is the point at which changing the design costs the least.

What high-risk obligations look like as engineering work

Without going into the legal detail, the structure of the requirements is familiar to anyone who has read this hub: risk management across the lifecycle, data governance covering training and validation data, technical documentation, automatic logging of events over the system's lifetime, transparency to deployers, human oversight, and appropriate accuracy, robustness, and cybersecurity.

Read that list as an engineer and most of it is things we would argue you should do anyway. Logging over the lifetime of the system is an audit trail. Data governance is knowing what your training data contains and where it came from. Human oversight is the design question on when a human must stay in the loop. Accuracy and robustness are an evaluation suite.

Which is the practical point of this page. The deferral gave teams more time, and the cheapest way to use it is to build the artefacts the obligations describe, because they are also the artefacts that make a system maintainable and defensible in every other jurisdiction.

How to use the extra time

Four things, in order of how much they help and how expensive they are to retrofit.

Keep a decision inventory. What each feature decides, what it uses, and whether a human reviews the output before it takes effect. This is the input to every scoping conversation, and it takes an hour a quarter.

Log the system's behaviour over its lifetime. Not just application logs: the inputs, outputs, model version, and decision context, retained. This is the single most expensive thing to add retrospectively, because the data you did not capture is gone. It is covered on building an audit-ready codebase.

Know your training and validation data. Where it came from, what it contains, what rights you have to it, and what its known limitations are. Teams that assembled datasets casually over several years find this genuinely hard to reconstruct, and the difficulty is not a matter of discipline after the fact: if the ingestion pipeline never recorded a source for each item, no later effort recovers what was never written down. This is also where a decision inventory earns its cost, because a feature that trains on a dataset with unclear rights is a scoping problem an inventory surfaces early, before a model has shipped and the question becomes harder to unwind.

Build the evaluation suite. Accuracy and robustness are demonstrated with measurement, and a suite built now produces a history by the time it is needed. That history is the part that cannot be created later, as covered on using evals as compliance evidence.

A team that does those four things is in a good position whichever way the timeline moves again, and has a better-instrumented product either way.

If you want help scoping what your product would need, get in touch.