The EU AI Act did not switch on all at once. It entered into force in August 2024, prohibited practices and AI-literacy provisions began applying in February 2025, and the broad August 2, 2026 milestone brought most remaining provisions into application. Some obligations have later dates.
The useful first question
Before asking “are we compliant by August 2026?”, classify the system. A prohibited practice, a general-purpose AI model, a high-risk system, and a transparency-only system do not follow an identical path.
| Layer | What to establish |
|---|---|
| Role | provider, deployer, importer, distributor, or product manufacturer |
| System class | prohibited, high-risk, transparency, minimal risk, or GPAI |
| Geography | whether the Act's territorial scope is triggered |
| Date | which obligation applies at the date of deployment |
Classification is not a one-time dropdown. A company can be the provider of one system and the deployer of another. A general-purpose model can sit inside a downstream product whose own use case requires a separate assessment. The useful unit is therefore a specific system, role, use case, and date—not “the company uses AI.”
A decision sequence for product teams
Start with the use case and affected people, then work outward:
- describe what the system does in operational language, including the decision or content it produces;
- identify who develops, places on the market, imports, distributes, or deploys it;
- test the use against prohibited-practice and high-risk categories;
- identify transparency duties that can apply even when a system is not high-risk;
- check whether a general-purpose model layer introduces separate obligations;
- attach the applicable date and evidence owner to each conclusion.
This produces a branching record rather than a single “compliant / non-compliant” badge. The branch also shows which conclusion must be revisited when the product changes.
Why one date can mislead
“The AI Act applies in 2026” is directionally true and operationally incomplete. It hides obligations already in force, category-specific rules, and later milestones. A timeline becomes useful when it is joined to a decision tree.
It can also hide the difference between an implementation milestone and a new legislative event. The August 2026 date was part of the staged application sequence; an article updated on that date should not imply that lawmakers passed an entirely new Act that morning.
This visual is an orientation aid, not legal advice. The European Commission page and the Act itself remain the authority.
What evidence belongs behind each node
A useful compliance map links conclusions to artifacts. The system-description node should point to a current product specification. The role node should name the legal entity and distribution relationship. Classification should point to a written analysis with assumptions. Operational duties should have an owner, completion state, and evidence location.
| Node | Example evidence |
|---|---|
| System scope | product spec, model card, data-flow diagram |
| Role | contracts, terms, distribution architecture |
| Classification | documented legal and technical assessment |
| Human oversight | procedure, interface control, training record |
| Monitoring | logs, incident process, review cadence |
| Transparency | notice copy and placement evidence |
This table is intentionally generic. The required evidence depends on the system and role; it is not a universal compliance checklist.
A reusable compliance map
The diagram is deliberately separated into milestones rather than legal chapters. That makes it easier for a product team to annotate each date with an owner, an evidence artifact, and a review status. The same structure can be recreated as an editable MyMap timeline for a product-specific compliance plan.
The best internal version has two views. The executive view shows deadlines, system count, and unresolved classifications. The working view expands each system into duties and evidence. Keeping them linked prevents a simplified status report from becoming the only record.
Failure modes
Do not classify solely from a vendor's marketing category, assume that using a third-party model removes deployer duties, or copy one assessment across materially different use cases. Do not treat a future implementation date as permission to ignore duties already in application. And do not mark a node complete merely because a policy document exists; the evidence should show the control operating for the system in scope.
Update policy
We review this page when the European Commission changes its implementation guidance or timetable. The “updated” date therefore describes our last source check, not a claim that the legislation itself changed that day.
Material changes include a revised official timeline, adopted implementing guidance that alters the decision path, or a correction to our classification language. Minor copy edits do not reset the substantive review date. Every archived version should retain the source access date so readers can reconstruct what guidance was available at the time.