The EU AI Act timeline, translated for governance teams

The EU AI Act entered into force on 1 August 2024, and its obligations phase in over several years. A date on a calendar becomes useful when a team turns it into a decision and a record.

This article translates the published milestones into that form. It offers general information, and nothing in it is legal advice. Amendments to the timeline have been proposed, so confirm the current official dates with official EU sources and your legal advisors before you plan around any of them.

The milestones as originally scheduled

The table lists the milestones as they were set out when the Act entered into force.

Each milestone raises a decision for your team and calls for a record that shows the decision was made.

2 February 2025, prohibited practices and AI literacy

The decision is whether any current or planned AI use falls into a prohibited practice. Screen each use case, and record who screened it and what they concluded.

AI literacy asks organizations to make sure the people who work with AI have the knowledge for the job. Keep guidance or training records with dates and audiences, and attach them to the roles they cover.

2 August 2025, general-purpose AI models

These obligations apply mainly to the organizations that provide general-purpose AI models. If you build on a model from a provider, record which models you use, which versions, and the documentation the provider supplies.

If you develop or significantly modify a model yourself, ask counsel whether provider obligations apply to you.

2 August 2026, most remaining obligations

This date brings most remaining obligations, including many requirements for high-risk AI systems. The decisions multiply here. For each system, plan to decide the risk class, your organization's role, the accountable owner, how human oversight works, what gets logged, and what triggers a fresh review.

Put those decisions in the inventory entry for the system, so the record lives with the asset it describes.

2 August 2027, AI in regulated products

High-risk AI embedded in regulated products follows a year later. Product teams that build such products should decide how the AI component enters their existing product compliance process, and who owns that link.

Start with your role and your inventory

Obligations depend on what you do with AI. The Act distinguishes roles such as provider and deployer, and it classifies AI systems by risk. You cannot answer either question without knowing which AI systems exist.

An AI inventory that records each system's purpose, owner, data, and role is the base record for each milestone above. Build it first, and keep it current as teams add tools.

Risk classification is a decision that needs a named reviewer. Record the reasoning, including the cases where you decided a system falls outside the high-risk requirements, because those are the cases someone will question later. The glossary entries on the EU AI Act and AI risk classification cover the vocabulary.

Treat each date as a prompt to ask which decision is due and where its record lives.

Questions to answer for each system

The following questions turn the milestones into work for each AI system in scope.

• Which risk category applies, and who decided?
• What is our role for this system, such as provider or deployer?
• Who provides human oversight, and what can that person do in practice?
• What logs exist, how long are they kept, and who can read them?
• What do people affected by the system get told?
• Which changes would trigger a fresh review?

Your counsel decides what the Act requires for each answer. Your governance team makes sure each answer exists, has an owner, and leaves a record.

A hypothetical example

For example, a recruiting team might adopt a tool that ranks job candidates. The governance team adds the tool to the inventory with its purpose, owner, and data. It records the organization's role as deployer, and it asks counsel whether the use falls into a high-risk category.

The hiring director becomes the accountable owner, a named reviewer provides human oversight, and a change in the vendor's model triggers a fresh review. Each decision lands in a dated record. The team can show a reviewer what it decided, who decided it, and when, whatever answer counsel gives.

Records that hold up

Records matter most when they are specific. Date each one, name the system and version, name the person who decided, and keep the version of the policy that applied.

The records come from several places.

• HR. Literacy and training records.
• Legal. Role determinations.
• Product. The description of intended use.
• Runtime. What the system did.

Runtime records fit this pattern well. Policy decisions, approvals, denials, and configuration changes show how oversight worked on a given day. A record from last quarter says little about a policy that changed last week, so keep the version history.

Keep one owner for the timeline

Because amendments have been proposed, assign one person to track the official timeline. Write the current dates into your program calendar with a review date next to each one. When a date changes, update the calendar and the affected decisions together, and keep the old version for the record.

Treat any date you read in a blog post, including this one, as a pointer to check against the official text.

How Halo helps

Halo records evidence that supports governance programs aligned to the EU AI Act. Its AI inventory records what discovery finds with classifications, source, and confidence, and policy decisions, approvals, and audit logs export as CSV and JSON. Halo does not automate compliance mapping or make an organization compliant, and legal conclusions stay with your counsel. Learn more about AI compliance evidence or book a walkthrough.