The EU AI Act Goes Live in 33 Days: Final Compliance Checklist for August 2
There are 33 days between the publication of this article and the date that the EU AI Act high-risk obligations become enforceable. On 2 August 2026 the regulatory regime that has been on a multi-year preparation arc reaches the point at which non-compliance generates exposure: penalties up to EUR 15 million or 3% of global turnover for the most serious infringements, with material fines for lesser categories.
This article is the EU AI Act compliance checklist for organisations that need to be defensibly compliant on day one. It is unapologetically tactical — no further retrospective analysis, no further explainer of the regulation’s history, no further comfort. The Q1 2026 readiness guide on this site explained what the regulation requires; this article is about what to ship in the next four weeks to actually be compliant.
The audience is CTOs, heads of compliance, AI programme leads, and the engineering teams executing in the closing window. McKenna Consultants delivers compressed-timeline EU AI Act compliance engagements, and the structure here is the structure we use in those engagements.
A note on the Digital Omnibus situation, addressed candidly later in the article: at this point, no further deferral is reliably going to land before 2 August. Plan as if the deadline is the deadline.
What Has to Be True on 2 August
For an organisation that places, deploys, or uses a high-risk AI system in scope of the Act, the position on 2 August must include — at a minimum:
- A complete inventory of in-scope AI systems, with each system classified against the Annex III high-risk criteria.
- Technical documentation (Article 11) finalised for each high-risk system.
- A quality management system (Article 17) in operation across the AI development and deployment lifecycle.
- Data governance (Article 10) for training, validation, and testing datasets evidenced.
- Human oversight (Article 14) implemented in design and operations.
- Accuracy, robustness, and cybersecurity (Article 15) benchmarks met and documented.
- Post-market monitoring (Article 72) operational, with incident reporting procedures.
- Conformity assessment route selected and (where applicable) initiated.
- CE marking and EU declaration of conformity prepared for products that require them.
- Records retention and traceability mechanisms in place.
If any of these is materially incomplete on 1 August, the position on 2 August is non-compliant for that system. The checklist below walks through each in delivery-friendly form.
Week One (Now to 7 July): Classification and Scope
The first week is about confirming what is actually in scope. The mistake organisations make in compressed-timeline compliance 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 most 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: Apply the Annex III classification per system. The high-risk categories include AI used in: biometric identification, management and operation of critical infrastructure, education and vocational training, employment and worker management, access to essential private services and public services, law enforcement, migration, and administration of justice and democratic processes. Each category 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.
Action 3: Identify systems explicitly excluded. Some AI systems are out of scope (research-only systems, AI for purely military purposes, free and open-source AI components in specific contexts) or fall below thresholds. Document the basis for exclusion; this becomes part of your compliance evidence even though the system itself is not subject to the Article 11-15 obligations.
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 Week One: A signed-off inventory document with classification rationale and role assignment per system. This is the foundational artefact; everything else hangs on it.
Week Two (8-14 July): Documentation Sprint
With scope confirmed, the second week is the documentation sprint. Article 11 requires technical documentation that demonstrates the system’s compliance posture. 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. A typical Article 11 documentation file is 30-80 pages depending on system complexity. For systems already documented internally, this is structuring and filling gaps; for systems with patchy documentation, this is a substantial writing exercise.
Action 6: Establish or formalise the data governance evidence (Article 10). Training, validation, and test datasets must be evidenced with provenance, quality controls, bias assessment, and where appropriate, demographic representativeness analysis. If your organisation has been treating training data as developer-managed material rather than as governed assets, this is the week to formalise the governance.
Action 7: Document the system’s intended purpose and reasonably foreseeable misuse. The Act requires explicit assessment of how a high-risk AI system might be misused and what the provider has done to guard against misuse. This is harder than it sounds for organisations that have not previously worked with this framing.
Action 8: Capture the conformity assessment route. Some high-risk systems require a notified body assessment; some require internal control. Identify the route per system, and for those requiring notified body involvement, confirm the engagement is in flight (most notified bodies are oversubscribed in the run-up to 2 August — initial engagement should already be underway).
Output for Week Two: Technical documentation files for each in-scope high-risk system, ready for review and sign-off.
Week Three (15-21 July): 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. The QMS must cover policies for compliance, design and development procedures, quality control procedures, examination, test and validation procedures, technical specifications, data management procedures, risk management procedures, post-market monitoring, incident reporting, communication with authorities, record-keeping, and resource management.
For organisations that already operate ISO 9001 or similar quality systems, the AI Act QMS can often be aligned with the existing quality framework. For organisations without an established QMS, a fit-for-purpose QMS specific to AI development is the practical alternative — it does not need to be ISO-grade, but it needs to be evidenced.
Action 10: Implement human oversight (Article 14). Each high-risk system must have human oversight measures designed in and operationalised. This means:
- The interface allows a competent human to interpret the system’s output and intervene.
- The system’s output is presented in a way that supports informed human decision-making.
- The human can override or disregard the system’s output where appropriate.
- The human can interrupt the system or stop its operation.
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 ship them in this week.
Action 11: Validate accuracy, robustness, and cybersecurity (Article 15). The Act requires that high-risk systems achieve appropriate accuracy, robustness, and cybersecurity for their intended purpose. 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 (adversarial inputs, distribution shift, edge cases).
- Document the cybersecurity controls in place against attacks specifically targeting AI systems (prompt injection for LLM-based systems, model extraction, membership inference, evasion).
Output for Week Three: Operational QMS, evidenced human oversight per system, validated accuracy and robustness results per system.
Week Four (22-28 July): Post-Market Monitoring and Final Preparation
Article 72 requires that providers have an active post-market monitoring system that collects, documents, and analyses data on the performance of high-risk AI systems through their lifetime, with serious incidents reported to the authorities.
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 (typically monthly for high-risk systems, more frequent 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. Serious incidents must be reported to the relevant national authority within tight timeframes (15 days for serious incidents, sometimes less). 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: CE marking and EU declaration of conformity. Where required by the conformity assessment route, prepare the CE marking and the EU declaration of conformity. The declaration must be retained for at least 10 years after placing the system on the market.
Action 15: Records retention. The Act requires records — technical documentation, declaration of conformity, automatic logs of high-risk system operations — to be retained for defined periods (typically 10 years). Confirm the retention infrastructure is in place.
Action 16: Final sign-off. A documented sign-off by the responsible executive that, for each in-scope system, the obligations are met. The sign-off is itself part of the compliance evidence — it is the artefact that demonstrates governance ownership.
Output for Week Four: Operational post-market monitoring, incident reporting procedure, CE marking where applicable, executive sign-off file.
The Digital Omnibus and the Postponement Question
The European Commission has proposed, through the Digital Omnibus package, postponing certain Annex III high-risk obligations to December 2027. The proposal is in the legislative process. As of late June 2026, it has not been adopted. The realistic position:
- If the postponement adopts before 2 August, organisations subject to the postponed obligations gain additional time. This is not certain.
- If the postponement does not adopt, the deadline stands.
- The compliance preparation needed is the same in either case.
The reasonable posture is to prepare as if the deadline is the deadline, treat any postponement as a windfall rather than a plan, and certainly not pause compliance work in anticipation of a postponement that may not materialise. Organisations that paused work in expectation of postponement and were caught short are the ones most at risk in the closing window.
Penalties and the Enforcement Posture
The penalties under the Act:
- Up to EUR 35 million or 7% of global turnover for prohibited AI practices.
- Up to EUR 15 million or 3% of global turnover for non-compliance with high-risk system obligations.
- Up to EUR 7.5 million or 1% of global turnover for incorrect or misleading information to authorities.
The enforcement posture in the early months of the regime is unlikely to be aggressive against organisations demonstrating genuine compliance effort. National authorities have signalled that the focus is on prohibited practices and on flagrant non-compliance. Organisations that have made bona fide compliance effort and have credible documentation are unlikely to face punitive action even if specific elements of the implementation are imperfect.
This does not mean that organisations can defer compliance and rely on a soft enforcement posture. The position on 2 August 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 first is non-compliance; the second is compliant in practice.
What to Skip If You Cannot Do Everything
For organisations entering the four-week window without sufficient preparation, the prioritisation:
Cannot skip: the inventory and classification (Action 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) — a fit-for-purpose AI-specific QMS rather than full ISO alignment is acceptable in the short term. Post-market monitoring (Action 12) — start with manual monthly review and instrument over time. Records retention infrastructure (Action 15) — interim retention via existing document management systems is acceptable.
Can defer to immediately after 2 August: broader QMS rollout across non-AI processes, retrospective documentation of low-risk systems, optimisation of monitoring and reporting workflows.
The principle is to be defensibly compliant on 2 August on the highest-risk surface, with documented improvement plans for the lower-priority elements.
Common Mistakes in the Final Window
A few patterns we have seen in compressed compliance engagements:
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.
Bundling compliance with broader AI governance. Some organisations attempt to use the deadline pressure to push through wider AI governance reform. This is laudable but rarely fits the four-week window. Defer the wider work; ship the compliance.
Underestimating the inventory effort. Many organisations have more in-scope AI systems than they think. The discovery phase routinely takes longer than planned. Start week one early.
Overestimating in-house capacity. The four-week window assumes dedicated capacity. Programmes that try to fit AI Act compliance around existing delivery commitments tend to slip. Free up capacity or bring in additional capacity.
Assuming the postponement. As above, do not bet on the Digital Omnibus.
How McKenna Helps in the Final Window
McKenna Consultants offers two engagement shapes for the closing window:
Compressed-timeline compliance delivery. A four-to-six-week engagement that delivers the compliance position end-to-end. Includes inventory and classification, technical documentation drafting, QMS standup, human oversight implementation, post-market monitoring instrumentation, and final documentation packaging. Typical engagement size: small to medium delivery team for the duration of the sprint.
Compliance review and gap analysis. A two-to-three-week engagement that reviews the customer’s existing compliance position, identifies gaps, and provides a prioritised remediation plan. The customer’s team executes the remediation; McKenna provides advisory backup. Suitable for organisations that have done the bulk of the work and want experienced confirmation of where the gaps are.
McKenna is a UK-based AI consultancy with a deep AI governance practice. Our team has been working with the AI Act since the political agreement in late 2023, through the staged implementation in 2024 and 2025, and into the high-risk obligations enforcement in August 2026. If your organisation is approaching the deadline with material compliance work outstanding, contact us — the deadline does not move, but the engagement starts the conversation that gets you across it.
The 33-day window is enough, with focused execution. It is not enough with delay. Use the window.
