The EU AI Act’s most demanding obligations — the ones covering high-risk systems — become enforceable on 2 August 2026. The Act applies extraterritorially: if your model touches a person in the EU, or your output is used in the EU, you are in scope regardless of where you are headquartered. Penalties top out at €35 million or 7% of global annual turnover, whichever is higher.
We have spent the last six months walking US, Indian, and UK companies through their first conformity assessments. The good news: the work is bounded, the documentation templates are converging, and the regulator is showing reasonable patience for good-faith effort. The bad news: most companies discover, late, that decisions made two years ago — model choice, hosting region, training-data provenance — quietly push them into the high-risk tier where the bar is materially higher.
Below is the working checklist we use with clients. It is not legal advice. It is an engineering-and-ops list designed to surface the work, not bury it.
Step 1 — Confirm the Act applies to you
You are in scope if any of the following is true:
- You place an AI system on the EU market, even as a free service.
- An EU-based deployer uses your system, even via API.
- Your system’s output is used in the EU — for instance, scoring an EU resident’s loan application from a US server.
Open-source, internal-use-only, and pure research systems get carve-outs, but the carve-outs are narrower than most teams assume. If you ship to enterprise customers anywhere in EMEA, assume scope until your counsel confirms otherwise.
Step 2 — Classify every model and product
Build a single AI inventory before you do anything else. For every model, agent, or product, capture:
- Owner and accountable executive
- Foundation model(s) and providers
- Training data sources, licences, and dates
- Deployment surface (web, mobile, embedded, B2B API)
- Intended purpose, as written for users — not as the engineering team understands it
Classify each system into one of the four risk tiers: prohibited, high-risk, limited-risk (transparency obligations only), and minimal-risk. Anything touching credit, employment, education, law enforcement, migration, justice administration, or critical infrastructure is presumptively high-risk under Annex III. So is most biometric processing. So are models that act on a user’s behalf in regulated workflows — which now sweeps in a large slice of the agentic-AI wave.
The classification fight you do not want: training a credit-decision copilot because “it just suggests, the human decides.” If the human routinely follows the suggestion, the regulator will treat the AI as making the decision in practice.
Step 3 — Stand up the documentation pack for high-risk systems
High-risk systems require a documentation set that should feel familiar to anyone who has worked with medical devices or aerospace: a permanent technical file, kept current, with sections covering:
- System description and intended purpose
- Risk management process and outputs
- Data governance and training/validation/test data documentation
- Logging and traceability
- Human oversight architecture
- Accuracy, robustness, and cybersecurity testing
- Quality management system describing how the above is maintained
The most common mistake: treating this as a one-off document. The Act requires post-market monitoring, which means the technical file is a living artefact. Build it inside your normal docs system (Confluence, Notion, Markdown-in-Git), not as a Word file in a SharePoint folder that nobody touches after submission.
Step 4 — Wire up logging and traceability
High-risk systems must log inputs, outputs, model versions, and material events with enough fidelity to reconstruct any individual decision after the fact. In practice this means:
- Immutable structured logs, retained for the period set by your sectoral law (often six years for finance)
- A stable system version identifier on every log line
- A correlation ID that ties inputs, retrieval context (for RAG), tool calls (for agents), and final outputs
- Redaction of personal data at the storage layer if you cannot justify retention
This is not optional. If you cannot show a regulator how a decision was made for a specific person on a specific day, you fail the audit. Build this in before you ship to production — retrofitting traceability after launch is an order of magnitude harder.
Step 5 — Design human oversight as a product feature
The Act demands that high-risk systems are designed so that humans can oversee them — not that humans are nominally in the loop. The distinction matters. A human who has 8 seconds to approve 200 cases per hour is not exercising oversight; they are rubber-stamping.
Build for genuine oversight: confidence scores, top-feature contributions, a clear “why this answer” surface, an obvious override mechanism, and audit-friendly logging of when overrides happen. If the model is going to be approved 99% of the time anyway, surface that statistic to the reviewer so they recognise their own complacency.
Step 6 — Test for robustness, accuracy, and cybersecurity
Three families of testing are required:
- Accuracy and robustness. Documented test sets covering the intended population, with calibration analysis across protected attributes. Include adversarial inputs and distribution shift.
- Cybersecurity. Prompt-injection and jailbreak testing for LLM systems; classic AI-specific threats from MITRE ATLAS and the OWASP LLM Top 10. Document the scope, methodology, and findings.
- Resilience to misuse. A foreseeable-misuse analysis with mitigations baked in. “Users should not do that” is not a mitigation.
Step 7 — Register and CE-mark where required
Most high-risk systems require a CE-style marking and entry into the EU database of high-risk AI systems before they reach the market. Allow 8–12 weeks for the conformity assessment process for an in-house system; longer if a notified body is involved. Bundle this with your existing regulatory cadence rather than running it as a separate stream.
Step 8 — Plan for general-purpose AI (GPAI) obligations
If you build on top of a general-purpose model, the provider carries the GPAI obligations — but you carry the deployer obligations, which include ensuring the model you use complies and that your downstream use respects copyright, prohibited categories, and the deployer-specific transparency rules. Get written confirmation from your foundation-model provider that they comply with the GPAI duties (training data summaries, copyright respect, systemic-risk management for the largest models). Their compliance is not automatic — recent public exchanges between the AI Office and large providers have shown that some gaps remain.
Step 9 — Build the cross-functional operating model
Compliance is not an engineering problem alone. The teams that ship cleanly all run a small standing AI governance council with:
- An executive sponsor (often the CTO or CIO)
- Legal / DPO representation
- Information security
- The AI engineering lead
- A business owner per high-risk system
The council meets monthly, reviews the AI inventory, signs off on classification changes, and tracks remediation. This is the artefact a regulator most wants to see in an audit — that decisions are made by people, with names, on dates.
Step 10 — Stress-test against ISO/IEC 42001
ISO 42001 (AI management systems) has become the de facto certification track for organisations operating AI at scale. It is not legally required by the AI Act, but it covers the same management-system controls the Act expects and gives you a defensible, third-party-audited story. If you are running multiple high-risk systems, target ISO 42001 in parallel with your conformity work — you are doing the controls anyway.
What to do this quarter
If you do nothing else before August 2026, do these four things:
- Build the AI inventory. You cannot govern what you cannot list.
- Classify every system into a risk tier with written reasoning.
- Pick one high-risk system and run a dry-run conformity assessment against it. Learn where the gaps are while there is still time to close them.
- Stand up the governance council and start the meeting cadence.
The teams that prepare quietly through 2026 will move fastest in 2027 — when the Act’s long tail of guidance, sectoral rules, and enforcement decisions starts landing. The cost of preparation is small. The cost of being caught short is not, and the regulator’s patience is finite.