EU AI Act Compliance Checklist: What Applies When and How to Prepare for High-Risk Rules

Correction, 3 October 2026: An earlier version of this article, published on 29 June 2026, presented this checklist as a 33-day countdown to the EU AI Act’s high-risk obligations becoming enforceable on 2 August 2026, and advised readers not to expect any deferral before then. That was not correct. The AI Omnibus, which entered into force on 27 July 2026, moved the high-risk obligations to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. What did apply from 2 August 2026 was the general application of the Act, including the Article 50 transparency obligations and the enforcement powers of the AI Office and national authorities. The article, including its title, has been corrected throughout.

The EU AI Act became generally applicable on 2 August 2026, but its obligations do not all start at once. Some already apply and are now enforceable; the high-risk obligations, which account for most of the compliance engineering, apply from 2 December 2027 for systems listed in Annex III and from 2 August 2028 for AI in products covered by Annex I. This checklist separates the two.

This article is an EU AI Act compliance checklist for organisations that need a defensible position. It is deliberately tactical — no retrospective analysis, no explainer of the regulation’s history. The technical readiness guide published on this site in February 2026 explains what the high-risk requirements involve; this article is about what to do, and in what order.

The audience is CTOs, heads of compliance, AI programme leads, and the engineering teams doing the work. The phased plan below is the order in which we recommend tackling the high-risk work; it is our recommendation, not a sequence the Act prescribes. It is not legal advice, and classification decisions in particular should be confirmed with your legal advisers.

A note on timing, covered in more detail later in the article: the high-risk dates have already moved once, through the AI Omnibus. Article 113 of the amended Act now sets them as fixed dates. Our advice is to plan against those dates rather than to hope for a further move.

What Already Applies

Before the high-risk preparation work, check the obligations that are already in force. They apply to far more organisations than the high-risk rules do:

1. Prohibited practices (Article 5) have applied since 2 February 2025. Confirm that no system you provide or deploy falls within them. The AI Omnibus added further prohibitions, covering AI generation or manipulation of non-consensual intimate material and child sexual abuse material, which apply from 2 December 2026.
2. AI literacy (Article 4) has applied since 2 February 2025. As amended by the AI Omnibus, providers and deployers “shall take measures to support the development of AI literacy” of their staff and others operating AI systems on their behalf; the obligation “does not require providers or deployers to guarantee any specific level of AI literacy of any individual.”
3. Transparency obligations (Article 50) have applied since 2 August 2026. Providers must ensure people are informed when they are interacting with an AI system, unless that is obvious; providers of systems generating synthetic audio, image, video or text must mark outputs in a machine-readable format and make them detectable as artificially generated; deployers of emotion recognition or biometric categorisation systems must inform the people exposed to them; and deployers must disclose deep fakes, and AI-generated text published to inform the public on matters of public interest, unless an exception applies. The only grace period is for the marking obligation, for systems placed on the market before 2 August 2026, which must comply from 2 December 2026.
4. General-purpose AI (GPAI) model obligations have applied since 2 August 2025. Providers of models placed on the market before that date have until 2 August 2027 to comply.
5. Enforcement. The enforcement powers of the AI Office and the national competent authorities apply from 2 August 2026, for the provisions that are already applicable.

What Has to Be True Before the High-Risk Dates

For an organisation that provides a high-risk AI system, the position by the applicable date — 2 December 2027 for Annex III systems, 2 August 2028 for Annex I systems — must include, at a minimum:

1. A complete inventory of AI systems, with each system classified against Article 6: the Annex III use cases and the Annex I product legislation.
2. A risk management system (Article 9) running across the lifecycle of each high-risk system.
3. Data governance (Article 10) for training, validation, and testing datasets evidenced.
4. Technical documentation (Article 11 and Annex IV) finalised for each high-risk system.
5. Automatic logging (Article 12) built into each system.
6. Human oversight (Article 14) implemented in design and operations.
7. Accuracy, robustness, and cybersecurity (Article 15) achieved, validated and documented.
8. A quality management system (Article 17) in operation across the AI development and deployment lifecycle.
9. Conformity assessment (Article 43) completed for each system.
10. EU declaration of conformity (Article 47), CE marking (Article 48) and, for Annex III systems, registration (Article 49).
11. Post-market monitoring (Article 72) operational, with serious incident reporting procedures (Article 73).
12. Documentation and log retention (Articles 18 and 19) in place.

Article 16 requires the conformity assessment to be carried out before a high-risk system is placed on the market or put into service, so the evidence above has to exist before that point, not be assembled afterwards. The phases below walk through each item in delivery-friendly form.

Deployers of high-risk systems have a different list, set out in Article 26: use the system in accordance with its instructions for use; assign human oversight to people with the necessary competence, training and authority; monitor the system’s operation and inform the provider and authorities of risks and serious incidents; keep the logs under their control for at least six months; inform workers’ representatives and affected workers before using the system in the workplace; and inform people that they are subject to decisions made or assisted by an Annex III system. Public bodies, private entities providing public services, and deployers of credit-scoring and life or health insurance pricing systems must also carry out a fundamental rights impact assessment before first use (Article 27).

One transitional rule matters for systems already in production. Under Article 111(2), as amended, the Act applies to high-risk systems placed on the market or put into service before the relevant Chapter III date “only if, as from that date, those systems are subject to significant changes in their designs” — although providers and deployers of high-risk systems intended to be used by public authorities must comply by 2 August 2030. Our view is that this should not be planned on as an exemption: systems under active development tend to change, and anything placed on the market after the date is fully in scope. Take legal advice on how the rule applies to specific systems.

Phase One: Classification and Scope

The first phase is about confirming what is actually in scope. A common mistake is treating every AI system as high-risk; this both inflates the work and dilutes attention to genuinely in-scope systems.

Action 1: Complete the AI system inventory. Every system that uses an AI component — whether developed in-house, procured, or embedded in a third-party tool — must be on the inventory. For many enterprises this list is longer than expected. Include systems you might be tempted to dismiss (HR screening tools, credit assessment algorithms, customer support automation, fraud detection).

Action 2: Classify each system against Article 6. A system is high-risk either because it is a safety component of, or is itself, a product covered by the Union harmonisation legislation listed in Annex I that must undergo third-party conformity assessment (Article 6(1)), or because it falls within an Annex III use case (Article 6(2)). The Annex III areas are: biometrics; critical infrastructure; education and vocational training; employment, workers’ management and access to self-employment; access to and enjoyment of essential private services and essential public services and benefits; law enforcement; migration, asylum and border control management; and administration of justice and democratic processes. Each area has specific scope criteria; the classification is not “this looks like AI in employment, so high-risk.” It is a structured assessment against the regulation’s text. Annex III point 5(b), for example, covers AI used to evaluate creditworthiness but expressly excludes AI systems used to detect financial fraud. The Commission has consulted on draft guidelines on high-risk classification and says the final guidelines will be adopted by the end of 2026; check your classifications against them when they are published.

Action 3: Identify systems that are out of scope or not high-risk, and document why. Article 2 excludes, among others, AI systems used exclusively for military, defence or national security purposes; systems developed and put into service for the sole purpose of scientific research and development; research, testing and development before a system is placed on the market or put into service (testing in real-world conditions is not covered by that exclusion); and systems released under free and open-source licences, unless they are high-risk or fall under Article 5 or 50. Separately, Article 6(3) allows an Annex III system not to be considered high-risk where it does not pose a significant risk of harm — for example, because it performs a narrow procedural task — but never where it performs profiling of natural persons. A provider relying on Article 6(3) must document its assessment before placing the system on the market and register it under Article 49(2). Document the basis for every exclusion; this becomes part of your compliance evidence even though the system itself is not subject to the high-risk requirements.

Action 4: Identify your role per system. The Act distinguishes between providers (who develop and place AI systems on the market) and deployers (who use AI systems in a professional capacity). Your obligations differ depending on which role you occupy for each system. Many enterprises are both — providers of internal AI systems they have built, and deployers of third-party systems they have procured. Each role attracts its own obligations.

Output for Phase One: A signed-off inventory document with classification rationale and role assignment per system. This is the foundational artefact; everything else hangs on it.

Phase Two: Documentation Sprint

With scope confirmed, the second phase is documentation. Article 11 requires technical documentation, drawn up before the system is placed on the market or put into service and kept up to date, that demonstrates the system’s compliance with the high-risk requirements. The required content (per Annex IV) includes the system’s purpose, architecture, training data, validation methodology, accuracy and robustness metrics, the system’s design specifications, and the changes made through the lifecycle.

Action 5: Draft or finalise technical documentation per high-risk system. The size of the file depends on the system’s complexity. For systems already documented internally, this is structuring and filling gaps; for systems with patchy documentation, this is a substantial writing exercise. SMEs, including start-ups, and small mid-cap enterprises (SMCs) may provide the Annex IV elements in a simplified manner, using a form the Commission is to establish (Article 11(1)).

Action 6: Establish or formalise the data governance evidence (Article 10). Training, validation, and test datasets must be subject to data governance and management practices covering, among other things, data collection processes and the origin of data, data preparation, examination for possible biases, measures to detect, prevent and mitigate those biases, and the identification of data gaps. The datasets must be relevant, sufficiently representative and, to the best extent possible, free of errors and complete, with appropriate statistical properties as regards the people the system is intended to be used on. If your organisation has been treating training data as developer-managed material rather than as governed assets, this is the phase to formalise the governance.

Action 7: Document the system’s intended purpose and reasonably foreseeable misuse. Article 9 requires the risk management system to estimate and evaluate the risks that may emerge when the system is used in accordance with its intended purpose and under conditions of reasonably foreseeable misuse, and to adopt targeted measures to address them. This is harder than it sounds for organisations that have not previously worked with this framing.

Action 8: Capture the conformity assessment route. Article 43 sets the route. For Annex III systems in points 2 to 8, it is internal control (Annex VI), with no notified body. For biometric systems under Annex III point 1, a notified body assessment (Annex VII) is required where the provider has not applied harmonised standards or common specifications in full; otherwise the provider can choose between the two. Annex I products follow the conformity assessment procedure of their own sectoral legislation. Identify the route per system. If a notified body will be involved, our advice is to engage early rather than assume capacity will be available close to the date.

Output for Phase Two: Technical documentation files for each in-scope high-risk system, ready for review and sign-off.

Phase Three: Quality Management System and Operational Controls

Article 17 requires a quality management system that documents the development and deployment lifecycle of high-risk AI systems. This is not a one-document artefact; it is an operational capability.

Action 9: Confirm the QMS scope and structure. Article 17(1) requires the QMS to cover, at least: a strategy for regulatory compliance, design and development procedures, quality control and quality assurance procedures, examination, test and validation procedures, technical specifications, data management procedures, the risk management system, post-market monitoring, serious incident reporting, communication with authorities and other parties, record-keeping, resource management, and an accountability framework setting out the responsibilities of management and other staff.

For organisations that already operate ISO 9001 or similar quality systems, the AI Act QMS can often be aligned with the existing quality framework, and providers already subject to QMS obligations under sectoral Union law may include the AI Act aspects in that system (Article 17(3)). For organisations without an established QMS, a fit-for-purpose QMS specific to AI development is the practical alternative. Article 17(2) makes implementation proportionate to the size of the provider’s organisation, in particular for SMEs and SMCs, while still requiring “the degree of rigour and the level of protection required”. It does not need to be ISO-certified, but it needs to be evidenced.

Action 10: Implement human oversight (Article 14). Each high-risk system must be designed so that it can be effectively overseen by natural persons while it is in use, with oversight measures either built in by the provider or identified by the provider for the deployer to implement. Article 14(4) requires that the people assigned to oversight are enabled, as appropriate and proportionate, to:

• Understand the system’s capacities and limitations and monitor its operation, including detecting anomalies and unexpected performance.
• Remain aware of the tendency to rely or over-rely on the system’s output (automation bias).
• Correctly interpret the system’s output.
• Decide not to use the system, or to disregard, override or reverse its output.
• Intervene in the system’s operation or interrupt it through a “stop” button or similar procedure that brings it to a halt in a safe state.

For AI systems already in production, this often requires changes to the user interface and to the operational procedures around the system. Identify the changes, scope them, and plan them into the delivery roadmap well ahead of the applicable date.

Action 11: Validate accuracy, robustness, and cybersecurity (Article 15). The Act requires that high-risk systems achieve an appropriate level of accuracy, robustness, and cybersecurity, and perform consistently in those respects throughout their lifecycle; the levels of accuracy and the relevant accuracy metrics must be declared in the instructions for use. This is not a one-time test; it is a benchmark with documented validation. For each system:

• Identify the accuracy metrics that align with the system’s purpose.
• Run validation against representative test data.
• Document the results, including the conditions under which accuracy degrades.
• Identify the robustness scenarios the system has been tested against (errors, faults and inconsistencies, distribution shift, edge cases, and feedback loops for systems that continue to learn after deployment).
• Document the controls in place against attacks specifically targeting AI systems. Article 15(5) names data poisoning, model poisoning, adversarial examples or model evasion, confidentiality attacks and model flaws. In our view, prompt injection against LLM-based systems belongs under this heading, as do model extraction and membership inference as forms of confidentiality attack.

Output for Phase Three: Operational QMS, evidenced human oversight per system, validated accuracy and robustness results per system.

Phase Four: Post-Market Monitoring and Final Preparation

Article 72 requires providers to establish and document a post-market monitoring system that actively and systematically collects, documents, and analyses relevant data on the performance of high-risk AI systems throughout their lifetime. The system is based on a post-market monitoring plan that forms part of the technical documentation; the Commission is to adopt guidance, including a template, for that plan by 2 September 2027. Serious incidents must be reported to the authorities under Article 73.

Action 12: Stand up post-market monitoring. For each in-scope system:

• Define the monitoring metrics aligned with the system’s intended purpose and risks.
• Stand up the telemetry collection.
• Define the analysis cadence (our suggestion: at least monthly to start, more frequently during early production).
• Document the monitoring procedure as part of the QMS.

For organisations that have invested in AI agent observability — covered in our 26 May 2026 article — much of the technical infrastructure is already in place. The compliance work is wrapping the existing observability in defined processes that produce evidence for Article 72.

Action 13: Prepare incident reporting procedures. Article 73 requires a serious incident to be reported to the market surveillance authority immediately after the provider has established a causal link with the AI system, or the reasonable likelihood of one, and in any event no later than 15 days after becoming aware of it. The limit is two days for a widespread infringement or a serious and irreversible disruption of critical infrastructure, and ten days where a person has died. An incomplete initial report may be followed by a complete one. Establish the procedure: who detects, who decides, who reports. Most incidents will not require reporting — but the procedure for the ones that do must be ready before the first one happens.

Action 14: EU declaration of conformity, CE marking and registration. Once the conformity assessment is complete, draw up the EU declaration of conformity (Article 47), which must be kept at the disposal of the national competent authorities for 10 years after the system is placed on the market or put into service, and affix the CE marking (Article 48) — a digital CE marking for systems provided digitally. Providers of Annex III systems must also register themselves and the system in the EU database before placing it on the market (Article 49); critical infrastructure systems under Annex III point 2 are registered at national level instead.

Action 15: Records retention. Providers must keep the technical documentation, the QMS documentation, relevant notified body documents and the EU declaration of conformity for 10 years after the system is placed on the market or put into service (Article 18). Automatically generated logs have a different rule: providers and deployers must keep the logs under their control for a period appropriate to the system’s intended purpose, of at least six months, unless other Union or national law, in particular data protection law, provides otherwise (Articles 19 and 26(6)). Confirm the retention infrastructure is in place, and that each system can generate the logs in the first place (Article 12).

Action 16: Final sign-off. A documented sign-off by the responsible executive that, for each in-scope system, the obligations are met. The Act does not prescribe this step in those words, but Article 17(1) requires an accountability framework setting out the responsibilities of management, and a sign-off is the natural evidence that the framework operates. It is the artefact that demonstrates governance ownership.

Output for Phase Four: Operational post-market monitoring, incident reporting procedure, declaration of conformity, CE marking and registration where applicable, executive sign-off file.

The AI Omnibus: What Changed and What Did Not

When this article was first published, the Commission’s proposal to postpone the high-risk obligations had not completed the legislative process. It has now. The European Parliament approved the trilogue agreement on 16 June 2026, the Council adopted the act on 29 June 2026, and the AI Omnibus entered into force on 27 July 2026. Under Article 113 as amended, the high-risk requirements and obligations apply:

• From 2 December 2027 for AI systems classified as high-risk under Article 6(2) and Annex III.
• From 2 August 2028 for AI systems classified as high-risk under Article 6(1) and Annex I.

What did not move: the Act became generally applicable on 2 August 2026, the Article 50 transparency obligations applied from that date (with the limited marking grace period to 2 December 2026), and so did the enforcement powers of the AI Office and the national authorities. The Omnibus also added new prohibitions from 2 December 2026, extended some simplifications previously reserved for SMEs, such as simplified technical documentation, to small mid-cap companies, and recast the AI literacy obligation.

Our view: the extra time is real, but the preparation needed is the same. The inventory, documentation, and operational controls take as long as they took before; the difference is that they can now be done properly rather than in a compressed window. Treat the new dates as the plan, not as a reason to pause.

Penalties and the Enforcement Posture

Article 99 sets the maximum fines:

• Up to EUR 35 million or 7% of total worldwide annual turnover, whichever is higher, for prohibited AI practices (Article 5).
• Up to EUR 15 million or 3%, whichever is higher, for breaches of other operator obligations, including providers’ high-risk obligations (Article 16), deployers’ obligations (Article 26) and the Article 50 transparency obligations.
• Up to EUR 7.5 million or 1%, whichever is higher, for supplying incorrect, incomplete or misleading information to notified bodies or national competent authorities in reply to a request.

For SMEs, including start-ups, each fine is capped at whichever of the two figures is lower; for SMCs, the lower figure applies to the second and third tiers. Member States lay down the national rules on penalties.

We would not plan on a lenient early enforcement posture. What the Act does say is that, when deciding whether to impose a fine and how large it should be, authorities must have regard to factors including the operator’s degree of responsibility “taking into account the technical and organisational measures implemented by it”, its cooperation with the authorities, and any action taken to mitigate harm (Article 99(7)). Our reading is that genuine, documented compliance effort counts for something. It is not a substitute for compliance.

This does not mean that organisations can defer compliance and rely on a soft enforcement posture. The position must be defensible. “We are working on it” is materially different from “we have a credible compliance position with documented gaps and a remediation plan.” The second is a far stronger position to be in when an authority asks.

What to Prioritise If You Cannot Do Everything

For organisations with limited capacity, our suggested prioritisation:

Cannot skip: the obligations that already apply (see “What Already Applies” above), the inventory and classification (Actions 1-4), technical documentation for the highest-risk systems (Action 5), human oversight (Action 10), incident reporting procedure (Action 13), executive sign-off (Action 16). Without these the compliance position is indefensible.

Can compress: the QMS (Action 9) — in our view, a fit-for-purpose AI-specific QMS, proportionate as Article 17(2) allows, is a reasonable starting point rather than full ISO alignment. Post-market monitoring (Action 12) — start with manual monthly review and instrument over time. Records retention infrastructure (Action 15) — existing document management systems can often serve in the interim.

Can follow later: broader QMS rollout across non-AI processes, retrospective documentation of systems that are not high-risk, optimisation of monitoring and reporting workflows.

The principle is to have the obligations that already apply covered now, and to be defensibly compliant on the highest-risk surface by the applicable high-risk date, with documented improvement plans for the lower-priority elements.

Common Mistakes to Avoid

Some common pitfalls to check for:

Treating compliance as a documentation exercise rather than an operational one. Documentation matters, but the Act requires operational capabilities (QMS, oversight, monitoring), not just documents. Documentation without operations is not compliance.

Letting a wider governance programme swallow the compliance work. Broader AI governance reform is worthwhile, and the longer runway makes it easier to align the two. Keep the specific obligations on their own tracked plan, so that they do not slip behind the broader programme.

Underestimating the inventory effort. Organisations often have more AI systems in use than they realise, because AI components are embedded in procured tools as well as in-house builds. Discovery often takes longer than planned. Start it early.

Overestimating in-house capacity. Fitting AI Act work around existing delivery commitments is a common way for it to slip. Ring-fence capacity or bring in additional capacity.

Overlooking what already applies. The prohibitions, AI literacy and the Article 50 transparency obligations were not deferred by the AI Omnibus.

Treating the new dates as a reason to pause. The AI Omnibus moved the high-risk dates; it did not reduce the work. Pausing now recreates the compressed window this checklist was originally written for.

How McKenna Consultants Can Help

McKenna Consultants offers two engagement shapes for EU AI Act work:

Compliance delivery. We work alongside your team to deliver the compliance position end to end: inventory and classification, technical documentation drafting, QMS set-up, human oversight built into the user interface, post-market monitoring instrumentation, Article 50 transparency features such as AI interaction notices and machine-readable content marking, and final documentation packaging.

Compliance review and gap analysis. A review of your existing compliance position that identifies gaps and provides a prioritised remediation plan. Your team executes the remediation; McKenna provides advisory backup. Suitable for organisations that have done the bulk of the work and want an independent check of where the gaps are.

McKenna Consultants is a UK-based software consultancy that has been designing and building software since 2004, including AI systems with governance and human-in-the-loop controls built in. We are engineers rather than lawyers, and we work alongside your legal advisers. If your organisation has EU AI Act work outstanding, contact us.

The high-risk dates are further away than they were when this checklist was first written. That is time to do the work properly, not a reason to defer it.

Sources

• European Commission — AI Omnibus enters into force: entry into force on 27 July 2026, the new high-risk dates, the extension of SME simplifications to small mid-caps, the AI literacy change and the new prohibitions.
• European Parliament Think Tank — Digital Omnibus on AI: Parliament’s approval of the trilogue agreement on 16 June 2026.
• Council of the European Union — Voting result: Digital Omnibus on AI, adoption of the legislative act (ST 11301/26): adoption by the Council on 29 June 2026.
• European Commission — AI Act: general application from 2 August 2026, with prohibitions and AI literacy from 2 February 2025 and governance and GPAI obligations from 2 August 2025.
• European Commission — The enforcement framework of the AI Act: enforcement powers of the AI Office and national authorities from 2 August 2026, and the prohibitions on AI-generated non-consensual intimate material and CSAM from 2 December 2026.
• European Commission — Transparency obligations under Article 50 of the AI Act: Article 50 applies from 2 August 2026, with a marking-only grace period to 2 December 2026 for systems placed on the market before 2 August 2026.
• European Commission — Targeted consultation on the draft guidelines for the classification of high-risk artificial intelligence systems: final classification guidelines planned for adoption by the end of 2026.
• European Commission AI Act Service Desk — Article 113: Entry into force and application: the amended application dates, including 2 December 2027 for Annex III and 2 August 2028 for Annex I high-risk systems.
• European Commission AI Act Service Desk — Article 111: high-risk systems already on the market, public-authority systems by 2 August 2030, GPAI models placed on the market before 2 August 2025, and the Article 50(2) transition.
• European Commission AI Act Service Desk — Article 2, Article 4, Article 6 and Annex III: scope and exclusions, AI literacy, classification rules and the Annex III use cases.
• European Commission AI Act Service Desk — Article 9, Article 10, Article 11, Annex IV, Article 12, Article 14, Article 15 and Article 17: the high-risk requirements and the quality management system.
• European Commission AI Act Service Desk — Article 16, Article 18, Article 19, Article 43, Article 47, Article 48 and Article 49: provider obligations, retention periods, conformity assessment routes, declaration of conformity, CE marking and registration.
• European Commission AI Act Service Desk — Article 26 and Article 27: deployer obligations and fundamental rights impact assessments.
• European Commission AI Act Service Desk — Article 50: the transparency obligations for providers and deployers.
• European Commission AI Act Service Desk — Article 72, Article 73 and Article 3: post-market monitoring, serious incident reporting deadlines and the definition of a serious incident.
• European Commission AI Act Service Desk — Article 99: Penalties: fine ceilings, the SME and SMC caps, and the factors authorities must consider.