The EU AI Act Deadline Passed. Here Is What Compliance Actually Requires, and Why Most Enterprises Are Not There Yet.

August 2026 marks the full application of the EU AI Act's obligations for high-risk AI systems. Boards have been briefed. Policy documents have been written. Compliance teams have checked boxes. And the vast majority of enterprises deploying AI in regulated contexts are still not compliant, not because they ignored the regulation, but because they misread what it actually requires.

The misreading is consistent across industries and geographies. Enterprises treated the EU AI Act like a data privacy regulation: build a policy, appoint an owner, document your systems, and you are done. The EU AI Act is not that. It is a product safety regulation applied to AI. The obligations it imposes are ongoing, technical, and tied to evidence of understood behavior, not just evidence of documented intent.

This piece is for the CIO, the Chief AI Officer, the General Counsel, and the board member who has been told that your organisation is compliant. It is a specific account of what the regulation actually requires at the level of technical obligation, where the gap between policy compliance and substantive compliance sits, and what closing that gap looks like in practice. If you are a journalist covering this beat, I am available to discuss the specific enterprise patterns I have observed.

What the Regulation Actually Says

The EU AI Act (Regulation 2024/1689) establishes a risk-tiered framework. Most enterprise attention has focused on the prohibited practices under Article 5 and the high-risk classification criteria under Article 6 and Annex III. Less attention has been paid to the substantive obligations in Articles 9 through 17, which are where most enterprises have material gaps.

Article 9 requires a risk management system that is a continuous iterative process throughout the entire lifecycle of a high-risk AI system. Not a risk assessment conducted at deployment. A continuous process that identifies known and foreseeable risks, evaluates risks in light of post-market monitoring data, and is updated as new information becomes available. Most enterprise risk management for AI stops at deployment. The regulation does not.

Article 11 requires technical documentation that must be drawn up before the high-risk AI system is placed on the market or put into service, and updated as necessary. The documentation must include a general description of the system, a description of its design and development process, information about training data and validation procedures, test results, a description of the monitoring and logging system, and the human oversight measures required for appropriate use. This is not a two-page system description. The European AI Office has indicated that documentation packages for complex AI systems should run to dozens of pages covering each element in specificity.

Article 13 requires that high-risk AI systems be designed and developed to ensure that their operation is sufficiently transparent to enable deployers to interpret the system's output and use it appropriately. The instructions for use must specify the level of accuracy and the relevant metric used to measure it, the expected output, the known or foreseeable circumstances that may affect accuracy, and the relevant input data specifications. This requirement is not met by publishing a model card. It requires deployer-specific characterisation of the system in the context of the specific intended use.

The Four Compliance Gaps Most Enterprises Have Right Now

Across the enterprise AI deployments I have worked with and reviewed, four gaps appear with consistent regularity. They are not exotic edge cases. They are the default state of organisations that have done good-faith but insufficient compliance work.

Most enterprises have compliance theater, not compliance substance. The difference will become apparent when the first enforcement actions land.

What "Actually Compliant" Looks Like

The organisations that are genuinely compliant with the EU AI Act's high-risk system obligations share several characteristics that distinguish them from those that have completed a compliance checklist.

They have a living technical documentation system, not a static document. Each high-risk AI deployment has a documentation package that is versioned, linked to the specific model version in use, and updated when the model, the deployment context, or the known failure modes change. The documentation is owned by a named individual who is responsible for keeping it current, and there is a defined trigger for re-documentation when material changes occur.

They have a behavioral characterisation of each system that goes beyond benchmark performance. The characterisation identifies specific input types and contexts associated with elevated failure risk, documents the testing evidence that supports those characterisations, and is specific enough to inform the design of human oversight. A compliance team member can read the characterisation and describe concretely what a human reviewer needs to watch for to catch the failure modes that have been identified.

They have a post-market monitoring process with documented outputs. Anomalies in production are flagged, investigated, and either explained or used to update the system's risk characterisation. The monitoring outputs are retained and form part of the evidence base for the continuous risk management process required by Article 9.

They have designed human oversight around what the system actually needs, not around what is convenient to implement. The oversight process is calibrated to the specific failure modes of the system in the specific deployment context. Human reviewers have been trained on those failure modes and have tools that help them identify when the system may be operating in a regime where its outputs are less reliable.

The Enforcement Timeline Is Shorter Than You Think

The EU AI Act's enforcement architecture is still being built. National supervisory authorities are being designated in each member state. The European AI Office, established within the European Commission, has oversight responsibilities for general-purpose AI models and coordination responsibilities across the national authorities. Full enforcement capacity will develop over 2026 and 2027.

But the timeline for enforcement readiness is shorter than most enterprise legal teams have communicated to their boards. The regulation is already in force. The obligations already apply. Supervisory authorities do not need to be fully staffed before they can open investigations based on complaints, incidents, or proactive market surveillance. The financial services sector in particular has already seen preliminary inquiry activity from regulators seeking to understand how AI governance frameworks map to the Act's requirements.

More importantly, enforcement risk from the EU AI Act is not only regulatory. It is contractual and commercial. Enterprise procurement increasingly includes AI governance representations and warranties. A deployer organisation that cannot demonstrate substantive compliance with Articles 9 through 17 is increasingly at risk of failing vendor qualification requirements from its own enterprise customers, particularly in financial services, healthcare, and critical infrastructure sectors where counterparties have their own regulatory obligations around AI system governance.

The Sectors with the Highest Immediate Exposure

What Boards Need to Ask Their AI Governance Teams This Week

If you sit on a board or in a C-suite of an organisation deploying AI in any of the eight Annex III high-risk areas, there are five questions you should be able to get clear answers to before the end of this quarter. If the answers are vague, that vagueness is your compliance exposure.

First: can you show me the technical documentation package for each high-risk AI system we operate? Not the governance policy. Not the AI risk register. The specific technical documentation for each specific system, in the format that Article 11 requires.

Second: who is responsible for keeping that documentation current, and what triggers an update? The regulation requires living documentation, not a point-in-time artifact. If there is no named owner and no defined trigger, the documentation will drift from reality as the system evolves.

Third: what does our post-market monitoring system produce, and where do those outputs go? If the answer is that we monitor output quality through user feedback and escalation, that is not a post-market monitoring system in the sense the regulation contemplates. There should be a defined process, defined metrics, defined thresholds, and a documented trail of monitoring outputs and responses.

Fourth: have our human oversight processes been designed around the specific failure modes of each system, or around what was convenient to implement? The distinction matters for Article 14 compliance and for whether your oversight actually catches what it needs to catch.

Fifth: what is our process for handling an AI incident that causes harm to an individual or group? Article 73 requires serious incident reporting to national supervisory authorities. If you do not have a defined incident response process for AI, you are not prepared for the enforcement contact that follows an incident.

The Cost of Waiting

The argument for waiting that I hear most frequently from enterprise legal and compliance teams is that enforcement is uncertain, supervisory authority capacity is limited, and the first enforcement actions will likely target egregious cases rather than documentation gaps. This argument is probably correct in the short term and dangerously wrong in the medium term.

Enforcement builds from precedent. The first enforcement actions establish what substantive compliance looks like in practice, and those precedents apply retroactively to the governance evidence that existed at the time of the violation. An organisation that defers building a continuous risk management process until after the first enforcement actions are announced will be judged against a standard established while it was waiting.

More practically: the cost of building compliant governance now, while your AI deployments are relatively few and relatively simple, is substantially lower than building it after your AI portfolio has grown, after a harm event has occurred, or after a regulatory inquiry has begun. Governance built under time pressure and regulatory scrutiny is more expensive, less well-designed, and produces worse documentation than governance built proactively. The organisations that will handle EU AI Act enforcement the best are the ones that built their governance systems before they needed them.

The Practical First Step

If your organisation needs to close the compliance gap quickly, the highest-leverage first step is an inventory and classification exercise: a structured review of every AI system in operation that asks three questions. Is this system used in one of the eight Annex III high-risk areas? If yes, does our current documentation, monitoring, and oversight satisfy the substantive requirements of Articles 9, 11, 13, 14, 72, and 73? If no, what is the gap and who owns closing it?

This exercise typically takes four to eight weeks for a mid-sized enterprise with a moderate AI portfolio. It produces the single most valuable artifact for EU AI Act readiness: an honest assessment of where you are, not where you thought you were. Most organisations find the exercise clarifying and uncomfortable in equal measure. That discomfort is productive. It is the distance between your current governance and the governance the regulation requires, made visible before it becomes visible to a regulator.

The regulation is in force. The deadline has passed. The question now is not whether to comply but how quickly and how well.