EU AI Act compliance: what applies to your AI system, and on which date
Most teams start EU AI Act compliance in the wrong place. They buy a policy template, or a scanning tool, before they have decided what role they play under the regulation — and the role decides everything that follows. A team that places a system on the EU market and a team that uses one internally do not have the same duties, the same dates, or the same paperwork. This is the checklist we run before we scope any compliance engagement in the EU: find the role, find the classification, then find the date.
What EU AI Act compliance actually covers
Regulation (EU) 2024/1689 applies to systems placed on the EU market or put into service in the Union, and to the people who place them there. Compliance is not one obligation. It is a set of obligations that depends on two decisions: the role you play, and the classification of the system.
Both decisions are checkable against the instrument itself, and the instrument is public. The EU AI Act Explorer carries the regulation article by article, including Annex III; the Commission’s regulatory framework page carries the guidance and the dates. If a summary you were given does not match the instrument, the instrument wins — and that rule is worth more than any checklist, ours included.
Step one: find your role
Four roles decide the duties. A provider develops the system or has it developed and places it on the market under its own name or trademark. A deployer uses it under its own authority, in a professional capacity. An importer brings a system into the Union, and a distributor passes one on. Most teams are a provider and a deployer at once — for two different systems, or for the same system at two points in its life.
The role is the cheapest hour of work in the whole engagement, because it decides which of the remaining questions you have to answer at all. Answer it before you buy anything.
Which obligations are already in force
Three sets are already with you, and none of them wait for 2027:
- Prohibited AI practices, in force since 2 February 2025.
- The AI-literacy duty, in force since 2 February 2025 — the obligation to make sure the people who operate your systems are competent to use them.
- General-purpose AI model obligations, in force since 2 August 2025.
From 2 August 2026 the Article 50 transparency duties for synthetic content apply, with no grace period for systems placed on the EU market on or after that date. The four-month grace period ending 2 December 2026 applies only to systems already on the EU market before 2 August 2026. If your team has been treating the Act as a 2027 project, this is the date to correct first.
What changes on 2 December 2027
If the system is high-risk under Annex III, the Chapter III Sections 1–3 duties apply from 2 December 2027: risk management (Art. 9), data governance (Art. 10), technical documentation (Art. 11), record-keeping (Art. 12), transparency (Art. 13), human oversight (Art. 14), and accuracy, robustness and cybersecurity (Art. 15). Article 72 post-market monitoring sits with them.
Two dates, two very different kinds of work. The 2026 obligations are mostly labelling and disclosure. The 2027 obligations are an operating system of evidence: a risk management process, a data trail, a documentation set that stays true as the code changes, and a monitoring plan for what happens after release. A team that starts in 2027 with nothing is buying a documentation retrofit. A team that starts now is building the trail it will need.
One caveat on planning: the dates have already moved once, and the guidance is still moving with them. A trail built as artefacts, checks and versioned evidence absorbs a change in scope or timetable as a version bump rather than as a rewrite of the compliance folder.
The evidence a compliance file has to hold
This is the test a buyer can apply without reading the regulation: ask to see the file. For one high-risk system it should hold a technical file to Annex IV, a conformity assessment, an Article 49 registration entry for the EU database, a deployer-information pack, and a post-market monitoring plan.
Two questions decide whether the file is real. First: can it be produced on demand, from the system as it runs today, rather than assembled for an audit? Second: does every artefact point at evidence you already produce — a commit, a test run, a log line — rather than at a document somebody wrote once and nobody has revisited since? The second question is what separates a trail from a folder.
What to automate, and what to leave to a person
Compliance work is not a document project. A large part of it is the same class of work we do for back-office teams: a rule decides, a model proposes, a named person confirms.
- Automate the classification and the inventory. Which systems exist, what role each one plays, what it is used for, which inputs it touches. This is rule-shaped, frequent and checkable — the three properties that make a workflow worth building at all.
- Automate the evidence collection. Logs, test results, version references and monitoring output, gathered continuously and attached to the system they belong to, rather than requested by hand before every review.
- Leave the judgement to a person. Whether a system is high-risk under Annex III, whether a control is adequate, whether a residual risk is acceptable, and any commitment to a customer or a regulator. Those decisions carry accountability, and they are not the model’s to make.
Where that work sits, and how a fixed first milestone around it is scoped, is described on our EU AI Act compliance service page.
Questions to ask before you buy help
Six questions that separate a compliance partner from a template shop.
- Which role do we play for each system, and where is that recorded?
- What is the classification of each system under Annex III, and who signed it off?
- Can the technical file be produced from the running system, today, with no audit in progress?
- What is in scope for the first milestone, what is explicitly out of scope, and what is the success metric?
- What happens when the guidance changes — is the trail versioned?
- Who owns the decision when a classification is contested?
If a supplier cannot answer the third question, they are selling documents, not a trail. The process page is the version of this we run ourselves, the security page is the default posture we ship, and the trust index lists the artefacts a procurement or DPO team asks for.
Questions teams ask
Is the EU AI Act compliance deadline 2027?
Partly. Three sets of obligations are already in force: the prohibited AI practices and the AI-literacy duty, both since 2 February 2025, and the general-purpose AI model obligations since 2 August 2025. The Article 50 transparency duties for synthetic content apply from 2 August 2026, with no grace period for systems placed on the EU market on or after that date. What lands on 2 December 2027 is the Annex III high-risk duty set for systems classified as high-risk.
Do we need this if we only use AI tools?
Usually as a deployer rather than a provider, and yes, some of it applies to you. Using a system under your own authority in a professional capacity makes you a deployer, and the AI-literacy duty since 2 February 2025 reaches the people operating it. What you do not get as a deployer is the provider’s technical documentation and conformity assessment — but you do get the duty to use the system according to the instructions, to inform affected people, and to keep a log where the provider asks for one.
What documentation do we actually have to keep?
For a high-risk system: a technical file to Annex IV, a conformity assessment, an Article 49 registration entry for the EU database, a deployer-information pack and a post-market monitoring plan. The useful test is not whether the folder exists but whether it can be produced on demand from the system as it runs today, with every artefact pointing at evidence you already produce — a commit, a test run, a log line.
Can a tool do this for us?
The mechanical half, yes. Classification against the instrument, the system inventory and continuous evidence collection are rule-shaped, frequent and checkable, which is exactly what automation is good at. The judgement does not transfer: whether a system is high-risk under Annex III, whether a control is adequate and whether a residual risk is acceptable stay with a named person. We build and operate the EU AI Act Scanner for the mechanical half, and client work runs the same method against your system, your data and your evidence.