EU AI Act August 2026: High-Risk Readiness Checklist
The 2 August 2026 high-risk deadline is real. A practitioner checklist for Annex III conformity assessment, documentation, and oversight.
The EU AI Act stopped being a policy debate the moment dates entered the regulation. The one that matters now for most enterprises is 2 August 2026 — the day the obligations for high-risk AI systems under Annex III become enforceable. If you operate a CV-screening tool, a credit-scoring model, an access-to-services decision engine, or any AI that materially shapes outcomes for people in a regulated domain, this deadline is yours.
This is a practitioner checklist, not a legal essay. It reflects how we at CC Conceptualise actually take high-risk systems through readiness — what gets built, what gets documented, and where teams reliably underestimate the work.
TL;DR — Key takeaways
- The hard date is 2 August 2026. From that day, Annex III high-risk systems need a completed conformity assessment, EU database registration, technical documentation, post-market monitoring, and human oversight before they go to market.
- Classification is the first and most consequential step. Misclassifying a high-risk system as limited-risk is the most expensive mistake we see, and "a human signs off at the end" does not downgrade it.
- Documentation is an engineering artefact, not a Word file. The technical file under Article 11 and Annex IV must reflect what your system actually does, with traceable evidence.
- Penalties are board-level. Up to EUR 15 million or 3 percent of global turnover for high-risk non-compliance; up to EUR 35 million or 7 percent for prohibited practices.
- ISO/IEC 42001 turns a scramble into a system. Pair it with the Act to make conformity repeatable.
Why this deadline is different
Earlier AI Act milestones were easy to defer mentally. The prohibitions that took effect in early 2025 affected a narrow set of practices. The general-purpose AI (GPAI) obligations that applied from 2 August 2025 landed mainly on model providers, and GPAI models already on the market before that date have until 2 August 2027 to comply. For most enterprises building or deploying AI in their own products and operations, none of that forced a programme of work.
The high-risk obligations do. Annex III is where the majority of enterprise AI lives — hiring, lending, insurance underwriting, access to essential services, critical infrastructure, education, and law enforcement support. If you place such a system on the EU market or put it into service after the deadline without meeting the obligations, you are non-compliant from day one.
For a deeper treatment of which systems land in scope, see our breakdown of Annex III high-risk classification.
The readiness checklist
Work through these in order. Each one gates the next.
1. Inventory and classify every AI system
You cannot comply with what you cannot see. Most organisations we engage discover AI in places no central register captured — a procurement scoring spreadsheet with an embedded model, a vendor SaaS feature quietly switched on, a data-science notebook promoted into a business process.
- Build a single inventory: system name, purpose, owner, data inputs, decision influence, deployment status.
- Classify each against the four tiers (unacceptable, high, limited, minimal).
- Record the reasoning for every high-risk decision. A regulator and your own auditors will ask "why did you conclude this was high-risk — or not?"
A common trap: an internal tool that ranks job applicants is high-risk even when a recruiter makes the final call. The Act treats systems that assist decisions in Annex III domains as high-risk. Human-in-the-loop does not reclassify the system.
2. Confirm your conformity assessment route
Once a system is high-risk, decide how conformity will be demonstrated.
| Conformity route | When it applies | What it means for you |
|---|---|---|
| Internal assessment (self-assessment) | Most Annex III systems, using harmonised standards in full | You run the assessment, but the documentation burden is on you and must be defensible |
| Notified body (third-party) | Certain biometric systems; where sectoral product law already requires it | An accredited body reviews and certifies before market placement; budget time and cost |
Confirm the route in writing early. Discovering at the eleventh hour that a system needs a notified body is a schedule killer. Our full walkthrough of the process is in the conformity assessment guide.
3. Build the technical documentation
The technical file required under Article 11 and Annex IV is the spine of compliance. It is not a marketing document; it is evidence. At minimum it must cover:
- General description — intended purpose, the people behind it, system version and how it interacts with other systems.
- Detailed design and development — architecture, design choices and trade-offs, computational resources, and the logic of the system.
- Data and data governance — training, validation, and test data sets; provenance, labelling, and bias-mitigation steps.
- Accuracy, robustness, and cybersecurity — performance metrics, known limitations, and the controls protecting the system.
- Risk management — the identified risks and the risk management measures applied, kept current through the lifecycle.
- Logging and traceability — how events are recorded so behaviour can be reconstructed.
We maintain a reusable scaffold for this so teams are not inventing structure under deadline pressure — see the technical documentation template.
4. Implement human oversight and risk management
Human oversight is a design requirement, not a disclaimer. The people overseeing the system must be able to understand its outputs, recognise automation bias, interpret results correctly, and intervene or stop the system. That means real interfaces, real training, and real authority to override.
Risk management measures must be tested under realistic conditions, not just described. If your mitigation for a known failure mode has never been exercised, it is a hypothesis, not a control.
5. Register, declare, and CE-mark
Before the high-risk system goes to market or into service:
- Register it in the EU database for high-risk systems.
- Draw up the EU declaration of conformity, signed by an accountable role.
- Affix the CE marking.
These are formal, sequenced steps. They cannot be backfilled cleanly after launch.
6. Stand up post-market monitoring
Compliance does not end at launch. You need an operational post-market monitoring plan that collects performance and incident data, a defined process for reporting serious incidents, and change management that re-triggers assessment when the system is substantially modified. A material change can pull the system back into a fresh conformity obligation.
A realistic timeline
| Activity | Lead time before 2 Aug 2026 |
|---|---|
| Inventory and classification | Done now; refresh quarterly |
| Confirm conformity route | At least 4–6 months prior |
| Technical documentation build | 3–6 months prior |
| Human oversight and risk-control testing | 2–4 months prior |
| Registration, declaration, CE marking | Before placing on market |
| Post-market monitoring operational | At go-live |
If you are reading this and your inventory is not yet complete, you are behind — but not fatally. The systems that fail are the ones still arguing about classification in July.
Where ISO/IEC 42001 fits
The Act tells you what outcomes to achieve; it does not hand you an operating model. ISO/IEC 42001, the AI management-system standard, provides that operating model — accountable roles, a risk-management lifecycle, documentation discipline, and continual improvement. Certification to 42001 does not confer AI Act conformity, but mapping its controls onto Annex III obligations is the difference between doing this once, painfully, and running it as a repeatable capability. In our delivery work we treat 42001 as the management layer and the Act's requirements as the conformity layer that sits inside it.
The mistakes that cost the most
- Treating classification as a formality. The most expensive errors are upstream, in scoping.
- Writing documentation that describes the intended system, not the deployed one. Auditors compare the file to reality.
- Assuming a vendor model means vendor liability. If you place the system on the market, you hold provider obligations regardless of who trained the model. Push documentation flow-down into contracts.
- Leaving human oversight as a policy sentence. It must be a working capability with people who can actually intervene.
Getting help
We take enterprise AI systems through this end to end — classification, conformity route, technical file, oversight design, and the management system around it. If you have an Annex III system and an August 2026 deadline, the time to start is now. Learn more about our AI and data platform engineering services, or get in touch for a focused readiness review.
FAQ
What exactly is due on 2 August 2026 under the EU AI Act? From 2 August 2026, the obligations for high-risk AI systems listed in Annex III become enforceable. Providers must complete a conformity assessment, register the system in the EU database, maintain technical documentation, run post-market monitoring, and ensure effective human oversight before placing the system on the market.
How do I know if my AI system is high-risk under Annex III? A system is high-risk if it is used in an Annex III domain such as employment and worker management, access to essential private and public services, credit scoring, critical infrastructure, education, or law enforcement. Systems acting as safety components of products already regulated under EU law are also high-risk. If a tool materially influences decisions about people in these areas, treat it as high-risk until a documented assessment proves otherwise.
Can we self-assess, or do we need a notified body? Most Annex III high-risk systems can use internal conformity assessment based on harmonised standards, provided you apply them in full. Third-party assessment by a notified body is required mainly for certain biometric systems and where sectoral product legislation already mandates it. The route should be confirmed in writing as part of your readiness work.
What are the fines for getting high-risk compliance wrong? Non-compliance with high-risk obligations can reach up to EUR 15 million or 3 percent of global annual turnover, whichever is higher. Prohibited practices carry steeper penalties of up to EUR 35 million or 7 percent. The financial exposure alone justifies treating the August 2026 deadline as a board-level matter.
How does ISO/IEC 42001 relate to the EU AI Act? ISO/IEC 42001 is the AI management-system standard. It does not grant AI Act conformity by itself, but it gives you the governance scaffolding — roles, risk management, lifecycle controls, and documentation discipline — that makes meeting Annex III obligations repeatable rather than a one-off scramble. We typically map 42001 controls directly onto the Act's requirements.
We use a third-party or general-purpose model. Are we off the hook? No. If you place a high-risk system on the market or put it into service, you carry provider obligations even if the underlying model comes from a vendor. You need contractual evidence, documentation flow-down, and clarity on who holds which obligation across the supply chain. GPAI providers have their own separate timeline, with pre-August-2025 models required to comply by 2 August 2027.
Topics