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 are now law. The Digital Omnibus on AI, Regulation (EU) 2026/1744, was signed on 8 July 2026, published in the Official Journal on 24 July 2026, and entered into force on 27 July 2026, six days before the original 2 August 2026 high-risk date would have applied. The dates are fixed in the statute; the Commission's earlier idea of tying them to the readiness of harmonised standards did not survive the negotiation. Thirteen 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, marking synthetic content) since 2 August 2026, which is also the date the AI Office and the national authorities began enforcing. If you run a customer-facing assistant today, that last one is not a 2027 question. The model vendors are treating it as current: on 5 October 2026 OpenAI said it would watermark ChatGPT and Codex text for EU users to meet the marking duty, after Anthropic said in August it would mark Claude's output worldwide.

What the Omnibus Changed, and What It Did Not

The Omnibus is a dates-and-scope amendment. It did not rewrite the high-risk obligations, and it did not touch the record-keeping articles this post is organised around. The dated items, as they now stand:

Date	What applies
2 February 2025	Prohibited practices (Article 5) and the AI-literacy duty (Article 4)
2 August 2025	General-purpose model obligations and the governance chapter
2 August 2026	Article 50 transparency; enforcement by the AI Office and national authorities; Commission fines for general-purpose model providers
2 December 2026	Two new prohibitions (below); end of the marking grace period for generative systems that were on the market before 2 August 2026
2 August 2027	National regulatory sandboxes must be operational; general-purpose models on the market before 2 August 2025 must comply
2 December 2027	High-risk obligations for standalone Annex III systems
2 August 2028	High-risk obligations for AI embedded in Annex I regulated products
2 August 2030	High-risk systems that public authorities already had in service

The dates are from the Commission's AI Act page and the article-by-article reading in ActuIA's 6 October 2026 review of what is in force. What the Omnibus changed beyond the calendar:

• Two new prohibitions, from 2 December 2026. Systems that generate or manipulate intimate or sexually explicit depictions of an identifiable person without consent, and systems that produce child sexual abuse material. For a provider the ban bites where that is the intended purpose or a reasonably foreseeable and reproducible outcome without adequate safeguards. Prohibited-practice fines are the top tier: up to 35 million euros or 7% of worldwide annual turnover.
• A four-month marking grace, now almost over. Providers of generative systems placed on the market before 2 August 2026 have until 2 December 2026 to mark their output in a machine-readable way under Article 50(2). Systems placed on the market after 2 August 2026 got no grace, and the duty to tell people they are talking to an AI system (Article 50(1)) was never extended. The Cloud Security Alliance's note on the marking deadline adds that signatories of the transparency code of practice committed to an interoperable detection mechanism by 2 February 2027.
• AI literacy softened. Article 4 now asks providers and deployers to take measures that support the development of AI literacy among the people operating their systems, and says in terms that no specific level has to be guaranteed for any individual. The duty still exists and the national authorities enforce it.
• Registration of "not high-risk" assessments stays. The Commission had proposed dropping the duty to register a system that sits in an Annex III area but which the provider has assessed as not high-risk under Article 6(3). The Parliament and Council put it back, with a simplified set of information to file. The assessment itself still has to be documented before the system goes live.
• Relief for small mid-caps. The simplified technical documentation form and the lower fine ceilings that SMEs had are extended to small mid-cap enterprises as the Commission defines them, and both get priority access to sandboxes, including a new EU-level sandbox the AI Office may run.
• Embedded AI narrowed. The "safety component" definition is tightened so that AI which only assists or optimises a product's performance does not make the product high-risk by itself, and products under the Machinery Regulation are handled through that regulation rather than directly under the Act.
• Who enforces what. The AI Office has exclusive competence over systems built on a general-purpose model by the same provider or group, and over AI inside the largest online platforms and search engines. National authorities keep law enforcement, borders, courts, and financial institutions. Both have had their powers since 2 August 2026.
• Bias detection. Processing special categories of personal data to detect and correct bias is permitted where strictly necessary, and the permission now reaches deployers and systems that are not high-risk, under conditions.

What it did not change is the part that drives the plan below. Articles 12 (automatic recording of events), 19 (provider retention), 26(6) (deployer retention), 14 (human oversight) and 99 (the 15 million euro or 3% tier for high-risk non-compliance) read as they did in 2024. No harmonised standard for Article 12 logging has been published, so the evidence architecture is still the operator's call. The deadline moved. The evidence did not.

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 is now.

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:

When	What has to be true
Q4 2026	Inventory signed. Owners named. Program costed into the 2027 budget. Evidence-store design chosen.
Q1 2027	Oversight redesign complete and the record running on every high-risk system. Retention schedule in force.
Q2 2027	First rehearsal: documentation set, incident reconstruction, chain verified by someone outside the build team.
Q3 2027	Gaps from the first rehearsal closed. Second rehearsal, with an outside verifier.
Q4 2027	Eight months of continuous record on every system. Application date arrives with the trail already in place.

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.

Two dates fall inside this plan that have nothing to do with high-risk status. On 2 December 2026 the two new prohibitions apply and the marking grace for older generative systems ends, so any system that writes, draws, or speaks to the public needs its output marked and its purpose checked against the new Article 5 points before then. On 2 August 2027 the national sandboxes have to be open, which matters if a sandbox is part of how you plan to test a borderline system.

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?
6. Does any system you run generate text, images, audio, or video that reaches people, and is that output marked in a machine-readable way today?

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.