EU AI Act Compliance Timeline: What to Stand Up Before December 2027

The EU AI Act's high-risk obligations apply from 2 December 2027 for standalone Annex III systems and 2 August 2028 for AI embedded in regulated products. Those dates come from the Digital Omnibus, adopted by the Parliament on 16 June 2026 and the Council on 29 June 2026, and they are the dates to plan against. Fifteen months is not slack. Here is why the calendar does not work that way, and what a compliance program has to stand up, in what order, to be ready when the date arrives.

This is the program-planning half of a pair. The statute half, which maps each article to the evidence it demands, is the EU AI Act capability crosswalk published by AGLedger, a sibling project; we cite it below rather than restate it.

Parts of the Act already apply. Prohibited practices and the AI-literacy duty have applied since 2 February 2025, the general-purpose model obligations since 2 August 2025, and the Article 50 transparency duties (telling people they are dealing with an AI system, labelling synthetic content) since 2 August 2026. If you run a customer-facing assistant today, that last one is not a 2027 question.

Why a 2027 Date Is a 2026 Problem

Three properties of the high-risk obligations pull the work forward.

The record is retrospective. Article 12 puts the recording duty on the system: events are captured automatically for as long as it runs. Article 19 then sets a floor of six months on how long a provider holds what was captured, and Article 26(6) says the same to deployers. That floor governs how long you keep a record, not how much history you must arrive with. The practical problem is different and harder: a record is evidence of what happened, and it cannot be created after the fact. The first request an authority makes will be about a decision already in the past. A program that switches the record on in November 2027 has nothing behind it.

Accuracy is worth reading against the record. Article 15 requires high-risk systems to be accurate, resilient, and secure against attempts to alter their use, outputs, or performance. Nothing in Article 12 says the record itself has to be tamper-evident. Our position is that it has to be anyway: a record any administrator can edit after the fact proves nothing to an authority. The standard we would hold a client to is the one the crosswalk describes: each entry signed, each chained to the one before it, none ever rewritten, so that an export produced ten years from now still verifies against the chain that produced it. Getting that property into production systems is an engineering change, and engineering changes take quarters.

The money is decided a year early. Most companies set the 2027 budget in the fall of 2026. Instrumentation, an evidence store, and a named overseer for each high-risk system are line items, and the penalty side of the ledger is specific: Article 99 puts non-compliance with most high-risk obligations, record-keeping included, at fines of up to 15 million euros or 3% of worldwide annual turnover. A program that is not costed by the time 2027 budgets close will spend the first half of 2027 arguing for money instead of running.

Put together: the obligations apply in December 2027, a defensible record needs months of history behind it by then, the instrumentation that produces it has to be built and proven in the first half of 2027, and the plan and budget that fund it have to exist in the last quarter of 2026. Which starts in three weeks.

Does This Apply to a US Company?

More often than assumed, and on a specific test. The Act reaches providers who place a system on the EU market, deployers established in the EU, and providers and deployers located anywhere whose system's output is used in the Union. Having EU customers is not by itself the trigger; where the output is used is. A US company whose hiring tool screens applicants in the EU, whose scoring model's output reaches an EU decision, or whose EU subsidiary runs its credit models is in scope for those systems. The eight Annex III areas are where to look first: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services (which is where credit scoring and life and health insurance pricing sit), law enforcement, migration and border control, and the administration of justice and democratic processes.

Even where the Act does not reach, the pattern does. HIPAA's Security Rule requires audit controls that record activity in systems holding health data, SOX internal-control audits expect a trail behind automated financial processing, and Colorado's AI Act imposes its own documentation and impact-assessment duties on high-risk systems. The crosswalk makes this point about the evidence layer; it is equally true of the program around it. A company that stands up one accountable record for its automated decisions serves every one of those regimes from a single source.

What the Program Has to Stand Up

Five things, and the order matters because each one is an input to the next.

1. An inventory you would sign

Every system where a model reads, classifies, decides, or drafts on behalf of the company, with its Annex III area (or "none") and its risk classification recorded and dated. The methodology is yours; the Act sets the categories, not the method. Where a system sits in an Annex III area and you conclude it is nonetheless not high-risk, Article 6(3) requires you to document that assessment, and Article 49 requires you to register it. The reason this is first is that every later step is scoped by it, and the reason it is hard is shadow AI: the tools your teams adopted without asking are in scope whether or not they are in the inventory. Expect the first pass to be incomplete, and plan a second one against expense reports and single sign-on records rather than team self-reports.

2. A name on every obligation

The crosswalk's article table has a "you own" column, and it is the most useful thing on the page for a program lead, because every row in it needs a person. The Act separates the provider (who builds and places the system) from the deployer (who uses it), and many companies are both for different systems. For each high-risk system: who is the human overseer the deployer assigns under Article 26(2), with the competence, training, and authority the Act asks for written down; who owns the Article 9 risk management process; who owns the retention schedule; who signs the Article 27 fundamental rights impact assessment where one is required. A compliance program is a list of names next to a list of obligations. Without the names it is a reading list.

3. A record that survives its own operator

This is the engineering core. For each in-scope system, decide which events are in scope for Article 12 (a scope decision the Act leaves to you), then make those events land in a store with three properties: every entry is signed by the component that produced it, entries are chained so that altering one breaks the ones after it, and the store has no delete or update path for anything inside the retention window. An application log that the application can edit fails the third property. A database table with an admin role fails it too.

The reason to insist on this rather than trust self-reporting is measured. When AGLedger tested whether agents could keep their own audit trail, between 0% and 47% of failed writes were recorded as successes in the agent's own account of its work, depending on the model. The independent signed chain contained none of them. The record has to be held by something the system under scrutiny cannot reach.

In the vocabulary we use for this, every consequential piece of work is a Record that states the intent, the performer files a Completion that states what was done, and where a human is required to decide, a Gate holds the work until a signed Verdict is rendered. The audit trail is the Record, the Completion, and the Verdict, notarized, in order. Which article each one satisfies is the crosswalk's subject, not this post's; what matters here is that the program produces all three, for every consequential decision, from the day the record goes on.

4. Oversight built into the workflow, not beside it

Article 14 asks providers to design high-risk systems so that a person can understand, intervene, and override; Article 26 asks deployers to actually assign that person. In practice this means the consequential steps in an automated workflow (approve the loan, reject the applicant, send the notice) wait for a person, and that person's decision is itself recorded. This is the same deterministic scaffolding around a reasoning core that makes automation reliable in the first place; the regulation is asking for the pattern good engineering already wanted. If your agentic workflows already have a person over the consequential steps, you are most of the way there. If they do not, this is the redesign, and it should happen before the record goes on, so the record captures the oversight rather than its absence.

5. A rehearsal

Twice before the application date, produce what the Act will ask for: the Article 11 technical documentation set, an Article 73 incident reconstruction for a real (or staged) failure, and a verification of the chain by someone who did not build it. The first rehearsal finds the events you forgot to record. The second finds the ones you recorded but cannot explain. A program that has never produced its own evidence is not ready, whatever the checklist says.

The Timeline, Quarter by Quarter

Working back from 2 December 2027 for a standalone Annex III system:

Systems on the August 2028 date get eight more months, and they follow the product-conformity route rather than the standalone one. Every one of those months should go to running the record longer, not to starting it later.

A Readiness Check

Five questions. If any answer is a shrug, that is where the program starts.

1. Can you list every system where a model makes or shapes a decision about a person, with its Annex III area, today?
2. For each one, can you name the person with authority to override it?
3. If an authority asked for the trail behind one decision made last Tuesday, could you produce it, and could someone outside your team verify it had not been altered?
4. Is the money for the evidence layer in the 2027 budget?
5. Have you ever produced the documentation set and an incident reconstruction end to end?

Standing up a program like this is design and deployment work inside the business, which is what we do. If you want to walk through the sequence against your own inventory, tell us what is running.