Most EU AI Act compliance programmes run in the wrong order. They begin with policy drafting, proceed to vendor questionnaires, and arrive at classification last — by which point the policies are addressed to obligations the institution may not have and the questionnaires ask for evidence nobody can use. This is a sequenced roadmap for a high-risk deployment, written in the order that survives contact with an actual system.
The sequence that actually works
Five steps, strictly ordered, because each produces the input to the next: inventory and classification; gap assessment against Articles 9–15; technical documentation and logging; conformity assessment and registration; post-market monitoring. Everything else — training, policy, vendor management — hangs off these five and should not precede them.
One preliminary point on roles. The Act distributes obligations between provider and deployer, and an institution that modifies a system substantially, or puts its own name on it, can become a provider without intending to. Settle the role per system before anything else; the entire obligation set turns on it.
1. Inventory and classification
List every AI system in operation, procurement and pilot. For each, record purpose, decision influenced, affected persons, data categories, the operating dependency and the intended role (provider or deployer).
Then classify. The practical order of questions:
- Does the system fall into a prohibited practice? If yes, the roadmap ends; the system is withdrawn.
- Is it a safety component of a regulated product, or listed in Annex III (biometrics, critical infrastructure, education, employment, essential public and private services, law enforcement, migration, justice)? If yes: high-risk.
- Does it carry transparency obligations — interacting with people, generating synthetic content, emotion recognition?
- Otherwise: minimal risk, but keep it in the inventory. Scope changes, and a minimal-risk system that acquires a new use case has quietly become something else.
Record the reasoning for each classification, including the ones you decide are not high-risk. The negative classifications are the ones a supervisor will test first, and Annex III's own derogations require documented justification.
2. Gap assessment against Articles 9–15
For each high-risk system, assess the current state against the substantive requirements, and score by evidence rather than by opinion.
- Art. 9 — risk management. A continuous, documented, iterative process over the lifecycle. The common gap is that the institution has a pre-deployment risk assessment and nothing after go-live.
- Art. 10 — data governance. Training, validation and testing data examined for relevance, representativeness and bias in the deployment context. Reusing a vendor's evaluation set as if it described your population is the most frequent single finding.
- Art. 11 and Annex IV — technical documentation. Must exist before placing on the market and be kept current.
- Art. 12 — logging. Automatic recording of events over the lifetime, sufficient for traceability. Check retention and, crucially, readability: logs that cannot be reconstructed into a decision narrative do not discharge the obligation.
- Art. 13 — transparency to deployers. Instructions for use that are actually usable by the staff who operate the system at 3am.
- Art. 14 — human oversight. Designed-in, with override authority, competence requirements and automation-bias mitigation.
- Art. 15 — accuracy, robustness, cybersecurity. Declared metrics measured against the operating environment, with degradation thresholds defined in advance.
Deployer-side obligations under Article 26 deserve their own line: using the system per instructions, assigning competent oversight staff, monitoring operation, keeping logs, and informing affected persons where required. Public-sector deployers also face a fundamental rights impact assessment under Article 27 — do it alongside the DPIA, not in a separate workstream.
3. Technical documentation and logging
Annex IV documentation is not a report written at the end. It is an artefact maintained continuously: system description, design choices, architecture, data provenance, training methodology, evaluation results, risk management outputs, oversight design, change log.
Build it where the work happens — versioned alongside the system, with generation automated wherever possible. Documentation maintained in a separate document-management system diverges from reality within one release cycle, and divergence is itself the finding.
4. Conformity assessment and registration
Most Annex III high-risk systems go through internal control conformity assessment; certain biometric cases involve a notified body. The output is an EU declaration of conformity, CE marking where applicable, and registration in the EU database before the system is put into service. Public authorities deploying high-risk systems have their own registration duty.
Two scheduling realities. First, the assessment must be repeated after a substantial modification — define in advance what counts as substantial for your system, or you will be arguing about it under time pressure. Second, work backwards from the applicable date for your class of system and add a quarter; the binding constraint is usually evidence collection, not paperwork.
5. Post-market monitoring and incident reporting
A documented post-market monitoring plan, actively collecting performance data from the field, is the requirement that converts compliance from a project into an operating function. Serious incidents must be reported to the competent authority within defined windows.
Align those clocks with your existing regimes. An institution whose AI Act, DORA and NIS2 incident windows run on different definitions and different clocks will spend the first real incident reconciling its own timestamps instead of managing the failure. One incident taxonomy, one clock, three reports. The reasoning behind that consolidation is in the AI Act and critical infrastructure.
General-purpose models in the chain
If a general-purpose model sits underneath your high-risk system, its provider carries its own obligations — documentation, copyright policy, training-data summary, and for systemic-risk models, evaluation and incident reporting. You inherit none of them, but you depend on all of them.
Two contractual consequences. Require the upstream documentation as a deliverable, not a courtesy. And require notice of model changes with a window long enough to re-evaluate, because a silent upstream update can invalidate your Article 15 declarations without anyone at your institution noticing.
Frequently asked
What is an EU AI Act compliance roadmap? A sequenced programme — inventory and classification, gap assessment against Articles 9–15, technical documentation and logging, conformity assessment and registration, then post-market monitoring — that takes a high-risk AI system from unassessed to defensible.
Are we a provider or a deployer? You are a deployer if you use a system under your authority. You can become a provider by putting your name on it, substantially modifying it, or changing its intended purpose. The distinction decides which obligations apply, so settle it per system in step one.
Where do most programmes lose time? Evidence collection for Articles 10 and 12 — representative deployment-context data and reconstructable logs. Both depend on decisions taken long before the compliance programme started, which is why classification comes first and policy comes last.
First published July 2026 · Frankfurt am Main.