The EU AI Act Timeline: Key Dates Every IT Company Should Know
Every date in the Act reads like a filing deadline. Read it instead as a capability that has to be live inside your operating model by then, owned by a named role. Same calendar, different seat.
In most technology companies I look at, the EU AI Act file has quietly become the biggest folder in the room and the smallest change to how the company actually works. The policy is drafted. The responsible-AI page on the website has been refreshed. A working group has met twice. Then someone in delivery asks the ordinary question: which of the AI features shipping this quarter need a human sign-off before they reach a customer, and who owns that sign-off per deployment. The folder has no answer. It never could have. The answer lives in how the org decides, builds, deploys, and measures, and that part hasn't been touched.
That gap, between the file on the desk and the workflows in the org, is what this piece is about. The Act is rolling out in phases between 2024 and 2030, and every ranking guide on the timeline reads it the same way: as a legal countdown of who is a provider, who is a deployer, which article applies, what the penalty ceiling is. All of that is correct. None of it tells the operator what to actually build. So this is the same calendar, read from a different seat.
A deadline is not a document you file. It is a capability that has to exist by a date.
Start with the reframe that reorganizes the whole timeline. Each date in the Act is usually described as "when X becomes applicable," which sounds like a filing deadline. Read it instead as "by this date, a specific capability has to be live inside your operating model, owned by a named role, running on its own without anyone chasing it." AI literacy has to become a real training path with an owner. Transparency has to be a live capability wired into the product. High-risk oversight has to be a running control.
What they are not is interchangeable. Before you assign an owner, name the control type, because the calendar mixes several distinct ones: preventive (a prohibition you must not cross), design-time (a property the product ships with), disclosure, evidentiary (documentation you have to be able to produce on request), assessment (a pre-market gate that re-triggers on substantial modification, though changes you predetermined and documented in the original assessment do not count as one), monitoring (a loop that runs for the life of the system), and governmental (infrastructure a Member State builds, not you). A machine-readable content marker is a design-time property, not a recurring workflow. A prohibition has no cadence. A conformity assessment is not a training program with a different owner. Ownership is useful governance for every one of them, but it does not make them the same kind of thing, and a build plan that treats them as one shape will schedule the wrong work.
The reason this matters is audit-readiness, not paperwork completeness. A compliance folder can be complete on the exact day the obligation lands and still describe workflows that never changed. When the test arrives, and I'll define what "the test" is later, the folder is not what it stops at. Some of those documents are themselves the required evidence: technical documentation is a conformity-assessment artifact and an authority-review artifact, so producing it is the obligation, not a proxy for it. What the folder cannot do is stand in for a control that was supposed to run. So the test inspects the artifacts the Act requires and, where the obligation is a recurring control, the trace the operating model leaves behind: who decided this system was low-risk and on what evidence (for an Annex III system a provider claiming the Article 6(3) exception owes a documented assessment; the wider habit of recording a classification for every system is an operating install, not a duty the Act imposes), and, where a review duty actually applies, who performed the review and where it is recorded. Be careful with that last one. The Act does not require a human to check every AI output before it reaches a customer. Human oversight under Articles 14 and 26 attaches to high-risk systems and has to be proportionate to the risk, and Article 50(4) treats editorial review as a route out of one specific disclosure duty, not as a general rule. Which trace you owe depends on the system's classification, your role, and the control in question. If the capability is a document and not a running control, the trace is empty, and where the obligation calls for a demonstrable running control, an empty trace can become the finding.
GDPR is the closest precedent, and it's worth holding in mind through the whole calendar. Privacy didn't become compliant when companies published a privacy policy. It became compliant, slowly and expensively, when data handling changed inside every workflow that touched personal data: who could access what, what got logged, how deletion actually happened. The EU AI Act is on the same path.
It's an operating-model change wearing a compliance-deadline costume.
Not every date is your date, and that is the most useful thing about the calendar.
The single most common mistake I watch companies make with this timeline is to treat it as one undifferentiated wall of deadlines that all apply to everyone.
They don't.
Each milestone binds a specific actor. Some obligations land only on providers of general-purpose AI models. Some land only on deployers of particular high-risk systems. Several apply only to EU institutions or to Member States, not to companies at all. A handful of dates that show up in every timeline graphic are, for a normal software or services company, simply not your problem.
This is the reframe, not a footnote, because the question "which actor am I on which date" is an operating-model question before it's a legal one. It maps directly onto the seven parts of an operating model: roles and responsibilities, decision rights, workflows and handoffs, review and control standards, information and system access, incentives and measures, and operating cadence. Your provider-or-deployer status for a given system follows the legal definitions and the facts, not an internal preference, but owning that assessment is a decision-rights question, and its answer changes which controls you owe. The role attaches to the legal entity and the activity, not to a product record, so the same company can be a provider in one transaction and a deployer in another, and Article 25 can move it from one seat to the other on a system it only meant to use. If your leadership team can't say, per AI system and per activity, which role you hold and which obligations follow, that's the first gap, and it's an org-design gap, not a legal-research gap.
The companion piece to this one works that provider-versus-deployer distinction all the way down, with a diagnostic you can run in a single leadership meeting. If you build software with AI inside it, or you deploy AI tools inside your own delivery, what the deployer's seat actually requires is the piece to read alongside this calendar. This piece is the map of dates. That one is the argument about the seat you're sitting in.
The timeline, read as a build order
Below is the calendar itself, kept as the reference you can bookmark. The dates reflect the Act as amended by the Digital Omnibus on AI, the simplification package the Council gave final adoption on 29 June 2026, signed on 8 July 2026, and published in the Official Journal on 24 July 2026 as Regulation (EU) 2026/1744. It entered into force on 27 July 2026, three days after publication, on an expedited timetable the regulation justifies by the 2 August application date it amends. The amended dates are the binding legal outcome, not a pending one. Two things to say before the table. First, the official EU AI Act Service Desk timeline is guidance, and guidance is not the binding legal text; where a date carries real consequence, confirm it against the amending regulation and the consolidated Official Journal version, because summaries lag and get revised. Second, the middle column is deliberately not "what the law says." It's what has to be true inside your operating model by that date, if the obligation applies to you.
| Date | What becomes applicable | What has to exist in the operating model |
|---|---|---|
| 1 Aug 2024 | The Act entered into force | Nothing operational yet. This is the day to establish, per AI system and per activity, which role you hold: provider, deployer, importer, distributor, or product manufacturer. One company routinely holds several at once, provider of the thing it builds and deployer of the tools it buys, and Article 25 can convert a deployer or distributor into a provider. That classification drives everything after it. |
| 2 Feb 2025 | General definitions, AI literacy (Article 4), and the prohibited practices apply | Your first live obligation. A named owner for AI literacy, measures that actually build literacy among the people operating AI on your behalf (in practice, a real training path), and a control that keeps prohibited uses (social scoring, untargeted facial scraping, certain manipulation) out of your workflows. |
| 2 Aug 2025 | Rules for general-purpose AI (GPAI) models apply; EU and national governance must be in place | If you provide a general-purpose AI model, the Article 53(1) duties begin: technical documentation of the model, information and documentation for the downstream providers who build on it, a policy for complying with EU copyright law, and a sufficiently detailed public summary of the training content. Providers of qualifying free and open-source models are exempt from parts of the documentation duties unless the model carries systemic risk, and a systemic-risk model picks up the additional Article 55 obligations on top. For most companies the relevant change is external: Member States designate the authorities and set the penalties you will answer to. |
| 2 Aug 2026 | The bulk of the operative obligations apply, including transparency (Article 50), and national penalty regimes bite. "Enforcement begins" is loose shorthand: the governance chapter largely applied from August 2025, and Commission powers over general-purpose AI, national market surveillance, and the various obligation groups switch on across different dates rather than all at once | The transparency capability has to be live. Users must be told when they are interacting with AI where it is not obvious (a provider design duty). AI-generated deepfakes must be disclosed (a deployer duty). Providers of generative AI must mark synthetic content in a machine-readable way. Deployers of emotion-recognition or biometric-categorisation systems must inform the people exposed to them (Article 50(3)). The obligations differ by actor, and each carries its own carve-outs: for evidently artistic, creative, satirical, fictional or analogous work the deployer's deepfake disclosure is modified rather than removed (you still disclose, but in a way that does not spoil the display or enjoyment), it is disapplied only where the use is authorised by law to detect, prevent, investigate or prosecute a criminal offence, and the provider's synthetic-content marking has a separate carve-out for assistive editing that does not substantially alter the content. |
| 2 Dec 2026 | New prohibitions plus a synthetic-content transition | Prohibitions on AI that generates non-consensual sexual deepfakes and child sexual abuse material apply. The provider and deployer tests differ: the provider test turns on intended purpose and on foreseeable, reproducible outcomes given reasonable safeguards, while the deployer test turns on purposeful use, and consent and other defined limits shape the scope on both sides. Separately, systems placed on the market before 2 August 2026 must meet the machine-readable synthetic-content marking of Article 50(2) by this date. That transition is a run-off for existing systems, not a general postponement: anything placed on the market from 2 August 2026 owes the marking from day one. |
| 2 Aug 2027 | Regulatory sandboxes operational; legacy GPAI deadline | Each Member State should have at least one AI regulatory sandbox. GPAI models placed on the market before 2 Aug 2025 must be brought into compliance by this date. |
| 2 Dec 2027 | High-risk AI systems in Annex III apply | The high-risk controls that fall to your role, provider or deployer, have to be running for use-case systems classified high-risk under Article 6(2) and Annex III, subject to the narrow Article 6(3) exception for systems that do not pose a significant risk: use cases such as recruitment and worker management, education, biometrics, critical infrastructure, essential services, migration, the administration of justice, and certain law-enforcement uses. This is a use-case classification, not a product-category one. |
| 2 Aug 2028 | High-risk AI embedded in regulated products | Where AI is a safety component of, or is itself, a product covered by the Annex I legislation, for example medical devices, lifts, and certain radio equipment, and that product is required to undergo third-party conformity assessment under that same legislation, the high-risk obligations extend to it. Both Article 6(1) conditions are cumulative, so Annex I coverage on its own does not make a system high-risk. The Digital Omnibus moved machinery out of this Annex I scope, into delegated acts under the Machinery Regulation, so it is no longer the example to reach for. |
| 2 Aug 2030 | Legacy public-sector high-risk systems | High-risk AI intended to be used by public authorities, placed on the market before the rules applied, must be brought into compliance, with a firm 31 December 2030 deadline for certain large-scale EU IT systems (Annex X). Confirm current status against the amended text, since the omnibus reshuffled several legacy dates. |
Read down the middle column and the pattern is obvious. For the obligations that actually bind your company, almost none are "publish a document." Each is "make a workflow do a thing it didn't do before, reliably, with an owner." Several dates on the full calendar bind Member States, EU institutions, or general-purpose-AI model providers instead, and those aren't your build. That's the reading the legal guides don't give you, and it's the only one that survives contact with an actual audit.
What I keep watching happen as these dates approach
The field pattern repeats across delivery orgs almost regardless of size. The calendar gets read once, at the top, as a risk register. Someone maps each date to a legal obligation, colour-codes the ones that apply, and hands the result to a working group. The working group produces documents. The documents are genuinely good. And then the dates arrive and nothing in delivery has changed, because no one converted a single obligation into an owned, running control.
The worst version I've watched goes like this. A company reads the 2 Aug 2026 transparency obligation, writes a clear policy that AI-generated content and AI interactions will be disclosed, files it, and moves on. Six months later a support chatbot ships without a disclosure line, because the policy lived in a governance folder and the chatbot lived in a delivery team, and nothing connected the two. The obligation was documented and unwired at the same time. The rule was still broken, but the root cause wasn't a gap in legal knowledge. It was a handoff failure, which is an operating-model failure.
So the more useful way to hold the timeline is as a phased build order, a compliance roadmap organized by capability rather than by legal category: not "what applies when," but "what capability has to exist by when, and who owns it." Four phases cover the practical work for most companies.
| Phase | Target date | Capability the operating model must have | Named owner |
|---|---|---|---|
| 1. Literacy and prohibited-use controls | Live since 2 Feb 2025 | Literacy measures reach the people operating AI on your behalf; prohibited uses are made materially harder and detectable by proportionate technical and organisational controls (access, procurement, approval gates, monitoring), with a response path for the bypasses those controls will not catch, rather than addressed by a memo. Where a hard block is feasible at a real enforcement point, use one and name it; elsewhere the honest goal is risk reduction, detection and response | Whoever owns people development plus a security or governance lead |
| 2. Governance and inventory | Before 2 Aug 2026 | An AI system inventory, a risk classification per system, an acceptable-use policy that bites, an incident-reporting path | The role that holds decision rights over deployment |
| 3. Transparency wired into product | From 2 Aug 2026 | Disclosure of AI interaction, of emotion-recognition or biometric-categorisation exposure (Article 50(3)), and of qualifying AI-generated content (deepfakes and certain public-interest text), machine-readable synthetic-content marking, built into the product, not the terms page | Product plus delivery leadership |
| 4. High-risk controls | Before 2 Dec 2027, if in scope | A responsibility matrix, not one stack. Provider duties, and this list is the shape of the obligation set rather than the whole of it: risk management, technical documentation, quality management, bias and performance evaluation, conformity assessment, post-market monitoring (Articles 9, 11, 17, 43, 72). The provider set runs across Articles 8 to 22 with the conformity and registration machinery in Articles 43 to 49, plus the post-market monitoring and serious-incident reporting workflows in Articles 72 and 73, so scope it against the text rather than against this row. Deployer duties, again the shape rather than the whole: use the system per the provider's instructions, assign competent human oversight, monitor operation, retain the logs under your control, report risks and incidents (Article 26). Which Article 26 branches bite depends on the deployment, and Article 27 adds a fundamental-rights impact assessment for some public-body and named-sector deployers, so scope it per system rather than per company. You take on provider duties only when an Article 25 trigger fires: rebranding, substantial modification, or changing the intended purpose so the system becomes high-risk. | Split by role. Provider duties to the accountable executive for the system; deployer duties to the platform lead, the service owner, or whoever signs the release |
Be precise about what these phases are, because they are not all the same kind of thing. Phase 1 is a direct obligation: Article 4 binds providers and deployers, and the prohibited practices bind everyone. Phase 2 is not. An AI inventory, a risk classification per system, an acceptable-use policy and an incident path are recommended enabling controls, the implementation method most companies need in order to answer the direct obligations, not duties the Act imposes in their own right. Phase 1 reaches nearly every company that lets its people use AI; Phase 2 reaches nearly every company that intends to answer for Phase 1. Phase 3 is in scope only where you meet one of the Article 50 tests: you provide a system people interact with and the interaction is not already obvious to a reasonably attentive person (50(1)); you provide a system generating synthetic audio, image, video or text (50(2)), subject to the statutory exclusions for assistive editing that does not substantially alter the input and for systems performing a standard editing function; you deploy an emotion-recognition or biometric-categorisation system, in which case you must inform the people exposed to it (50(3)); or you deploy one to produce a deepfake or qualifying public-interest text (50(4)). Provider marking and deployer disclosure are separate controls, and the Commission is explicit that provider marking alone does not discharge the deployer's duty. Phase 4 applies if an Annex III use case is in play, and that is broader than "one of your products". A system you bought and deployed internally for an Annex III purpose, screening job applicants for example, triggers deployer duties just as surely as one you built. The Article 6(3) exception is narrower than it looks too: it applies only where the system falls into one of the listed conditions (a narrow procedural task, an improvement on prior human work, a pattern-detection or preparatory task) and does not profile individuals. Plenty of companies land outside Phase 4, but that is a conditional judgement about your own inventory rather than a statistic, so check the tools you deploy, not just the products you ship. The value of reading it this way is that "later" stops being a vibe and gets a date and an owner.
AI literacy is the earliest obligation, and the one most companies read as a memo
Of everything on the calendar, AI literacy is the one I'd start with, because it's been live since 2 Feb 2025 and because it's where the gap between document and capability is widest. It's worth being precise about what the law actually requires here, because it's easy to overclaim. As amended by the Digital Omnibus, Article 4 requires providers and deployers to take measures to support the development of AI literacy among their staff and the other people operating AI on their behalf. It doesn't prescribe a curriculum. It doesn't mandate role-specific modules or a particular number of training hours. It expressly doesn't require you to guarantee any specific level of literacy in any individual. It's an obligation of effort, not result, and it leaves the mechanism to you.
That distinction is the whole game.
The legal requirement is thin: support the development of literacy. The operating-model install that actually delivers it isn't thin at all, and it's entirely your design. One baseline that holds up in a lot of orgs is a mandatory AI-use training for everyone who touches AI, covering what these tools can and cannot do, how to use them securely, how they intersect with GDPR and personal data, why outputs have to be verified and how hallucination shows up, bias and fairness, copyright and IP, who stays responsible for AI-assisted work, the transparency obligations, the prohibited practices, and how to report an AI incident. On top of that base, role-specific modules for the people whose work changes most: developers, project managers, HR and recruiters, architects, QA engineers, and the business teams running AI-assisted processes. That shape is neither prescribed nor automatically sufficient. Amended Article 4 asks you to take measures that account for the technical knowledge, experience, education and training of the people involved, the context the systems are used in, and the people they affect. So the defensible version isn't one course pushed at everyone. It's a documented choice of measures per group, with a reason on the record for why that measure suits that group.
The literacy program is where you can feel the operating-model claim become concrete. It has an owner or it drifts. It has a completion measure or you can't show it happened. It has a cadence, because literacy for a tool that changes every quarter isn't a one-time event. Build it as a slide deck sent once and you have a document. Build it as an owned, measured, recurring control and you have the first real capability on the calendar. The company that does the second one hasn't just met the earliest deadline. It's learned how to meet every deadline after it, because the shape of the work is the same.
What is "the first real test"?
I've said twice that the folder fails the first real test, so it's worth being concrete about what the test is, because "an audit" is doing a lot of vague work in most of these conversations. The test is rarely a regulator knocking on the door. It's usually one of five things, and all of them arrive without warning.
A customer runs a security and AI due-diligence review before signing, and asks you to show, not describe, how a specific AI feature is governed. A prospect's procurement team sends a questionnaire that asks who signs off on AI-assisted deliverables. An incident happens, a wrong AI output reaches a customer, and someone has to reconstruct who reviewed it and when. A conformity assessment is required for a high-risk system and the technical documentation has to already exist. Or a regulator or an auditor samples evidence and wants the trace behind a decision. In every one of those the question has the same shape, though not the same answer: which obligation applies, to you in which role, through which mechanism, and what evidence does that mechanism owe. Sometimes the evidence is a document the Act requires outright. Sometimes it is the record a recurring control left behind. Knowing which of the two you owe, per obligation, is the work. A policy that says the control exists isn't evidence that it ran.
This is why the audit-readiness framing beats the paperwork framing. Paperwork asks "do we have a document for this obligation." Audit-readiness asks "if someone sampled our evidence tomorrow, would the trace be there." The second question is the one that maps to the operating model, because a trace only exists if a workflow produced it, and a workflow only produces it if someone owns it and runs it on a cadence. The companies that stay calm when the test arrives are the ones whose controls were running long enough to leave a record, not the ones with the thickest folders.
Governance stops being a project and becomes a standing capability
The EU AI Act is often filed under "compliance," alongside the things you do once and forget. That filing is the mistake. Compliance regimes that touch how work actually happens don't resolve; they become permanent parts of the operating model, the way privacy did after GDPR and the way information security did after the first serious customer demanded a real answer. The calendar between now and 2030 is the schedule on which a new organizational capability, AI governance, comes online phase by phase and then keeps running, not a list of deadlines to clear and be done with.
So the practical takeaway is smaller and harder than "get compliant." It's this: pick the phase you're actually in, name the owner, and turn one obligation from a document into a running control this quarter. If you're like most companies, that means AI literacy and a real system inventory, owned and measured, not drafted. Do that once, well, and you'll have built the muscle the rest of the calendar needs. Leave it as paper, and every date on the timeline will find you exactly where the last one did, with a complete folder and an empty trace.
The reader most ready to act on this is the owner or the CTO who can name the phase, assign the owner, and fund the control by the end of the week. If that's you, the useful question isn't "are we compliant." It's "which obligation is still a document, and who's turning it into a control before the date makes the choice for us."
