EU AI Act high-risk checklist: readiness before August 2026

The finding first: most organizations treating the EU AI Act as a distant problem are mis-reading its timeline. Regulation (EU) 2024/1689 entered into force in August 2024 and applies in stages. Prohibited practices and AI literacy duties came first, obligations for general-purpose AI models followed in 2025, and the bulk of the high-risk regime under Annex III applies from August 2026. A further window exists for high-risk AI embedded in products already covered by EU product safety legislation, but for standalone Annex III systems, August 2026 is the operative deadline.

The evidence burden is what makes the date tight. The high-risk obligations are not a policy statement to sign. They require a functioning risk management system, documented data governance, a complete technical file, logging that actually retains records, and a conformity assessment before the system is placed on the market or put into service. For a regulated mid-size organization, that is 12 to 20 weeks of structured work, and that estimate assumes the inventory already exists.

Classification is the gate every other obligation depends on, and it is where most readiness programs start wrong. The check has two layers. First, Annex III lists the use-case categories that make an AI system high-risk: biometrics, critical infrastructure, education, employment and worker management, access to essential services and credit, law enforcement, migration and border control, and the administration of justice. Second, the Act provides a derogation: a system in an Annex III area may escape the high-risk label if it performs a narrow procedural task and does not materially influence decisions, but claiming that exemption requires a documented and retained assessment, not a verbal judgment.

Two scoping errors recur. Deployers assume that buying a model from a vendor moves the obligations to that vendor; it does not. Deployers carry their own duties, including human oversight, input data control and log retention, and an organization that substantially modifies a high-risk system or rebrands it can become a provider with the full provider obligations. The second error is conflating a GDPR DPIA with the AI Act's fundamental rights impact assessment required of certain deployers. They overlap; they are not the same document.

Articles 9 to 15 define what a high-risk system must demonstrably have. Treat each row as a checklist item: the obligation on the left is only satisfied when the artifact on the right exists, is current, and can be handed to a market surveillance authority without rework.

On top of the system-level requirements sit the provider's process obligations: a quality management system, the conformity assessment itself, the EU declaration of conformity and CE marking, registration in the EU database, and post-market monitoring with serious incident reporting. For most Annex III systems the conformity route is internal control; third-party assessment by a Notified Body applies in specific cases such as remote biometric identification.

A checklist self-completed by the team that built the system has the same weakness as a SOC self-assessment: it flatters. The SOC-CMM 2026 report found self-assessments overestimate maturity by about 0.6 points per element, and there is no reason to expect AI compliance self-reviews to be more honest. An independent third-party readiness assessment walks the same checklist but demands the artifact for every item, scores the gap, and produces three deliverables: a classification memo per system, a gap matrix against Articles 9 to 15 with the missing evidence named, and a prioritized remediation plan sequenced against the August 2026 date.

The value is the same as in a SOC maturity assessment: the board gets a defensible position rather than an optimistic one, and the compliance function gets a work plan instead of a 113-article regulation. The assessment does not certify conformity, and no serious assessor will claim it guarantees compliance. It evidences where you stand and what remains.

Article 15 and Article 12 are operational, not legal. A high-risk system must be resilient against attacks specific to AI, including data poisoning and adversarial inputs, and must log events throughout its lifetime. Someone has to monitor those logs, detect those attacks and feed confirmed incidents into the post-market reporting process. That someone is the SOC, and most SOCs are not ready for it: the 2026 SOC-CMM data shows roughly 57% of SOCs operate without a formal AI strategy.

Practically, AI Act readiness adds four items to the SOC's plate: onboard the high-risk systems' logs as monitored sources, build detection use cases for model abuse and anomalous model behavior, define an escalation path from SOC incident to AI Act serious-incident report, and include the AI systems in threat modeling. A SOC maturity assessment that covers use case management and log onboarding tells you whether the SOC can absorb this work; the AI readiness assessment tells you what work it is. The two read best together.

Do not wait for the documentation to start the monitoring. The technical file can be drafted in the final months. Log onboarding, detection content and oversight testing cannot. If the SOC has not started ingesting and watching the high-risk systems by early 2026, the Article 12 and Article 15 evidence will not exist when the deadline arrives, because logs cannot be backfilled.

1. 1.Inventory every AI system built, bought or embedded, with use case, data flows and the vendor or internal owner.
2. 2.Classify each against Annex III; document the exemption reasoning for anything you rule out.
3. 3.Run the gap assessment against Articles 9 to 15 and the provider or deployer process obligations.
4. 4.Close documentation gaps: risk register, data governance records, Annex IV technical file, instructions for use.
5. 5.Operationalize: logging into the SOC, human oversight tested, post-market monitoring and incident reporting rehearsed.
6. 6.Complete the conformity assessment, declaration and registration before placing or keeping the system in service.