This week's briefing
AI Governance5 min read2026.05.17

The EU AI Act enters its enforcement phase

What general-purpose model providers must document by August, and how enterprise deployers should prepare conformity evidence.

Enforcement obligations under the EU AI Act begin landing in waves through 2026. The first wave affects general-purpose model providers, with technical documentation, training-data summaries, and copyright policies due by August. The wave is significant because it sets the documentation pattern that downstream deployers will be expected to consume — and because the regulators conducting the early reviews will be establishing precedent that shapes the next several years of enforcement.

The substance of the documentation requirements is less novel than the procedural rigor they require. Most serious model providers can produce technical documentation, in some form, on request. Producing it in a form that conforms to the Act's expectations, that is current at the moment of regulator inquiry, and that has been reviewed by counsel in the relevant member states is a different operational commitment. The providers that have prepared in advance will look responsive; the providers that have not will spend the summer in a scramble that becomes visible to their customers.

What the obligations actually require

The technical documentation has to describe the model's architecture, training process, evaluation methodology, and known limitations in enough detail that a competent reviewer can form an opinion about its risk profile. The training-data summary has to characterize the sources, the curation process, and the rights position with enough specificity to support the copyright policy that accompanies it. The copyright policy itself has to be implementable, not aspirational; it has to describe how the provider responds to opt-out signals and rights-holder requests, with timelines and contact points.

Providers that have treated these requirements as a marketing exercise are discovering that the documentation has to survive cross-examination by regulators who have, by now, read a lot of model documentation and have a clear sense of what is substantive and what is filler. The bar has risen quietly. The reviews that have been published so far show the regulators asking pointed follow-up questions when the original submission glosses over the harder topics, which means that the documentation has to be written with the follow-up questions in mind, not just the initial filing.

What enterprise deployers should do now

Even organizations that only deploy third-party models inherit obligations: maintain logs, conduct fundamental-rights impact assessments for high-risk uses, and ensure meaningful human oversight. Most of this work is documentation discipline, not engineering, but it has to be done with the same seriousness that the provider documentation requires. A fundamental-rights impact assessment that was written for a slide deck will not survive the same scrutiny as a technical documentation file that was written for engineers.

The most useful preparation is to map every production AI use case against the Act's risk categories, identify the high-risk uses, and start the impact assessments on those first. The assessments themselves are not difficult; gathering the inputs — the data flows, the affected populations, the alternative approaches considered, the residual risk after mitigations — is the work. Organizations that begin this mapping now will have it ready when their regulator asks; organizations that begin it after the request will be working under time pressure they did not need to accept.

The meaningful-oversight requirement deserves particular attention because it is the obligation most often misunderstood. The requirement is not that a human reviews every output; it is that a human can intervene meaningfully when the system behaves unexpectedly. Meaningful intervention requires that the human has the information needed to evaluate the situation, the authority to act on it, and the time to do so before the consequence is locked in. Programs that have wired their AI systems to surface anomalies to humans who lack the time, the information, or the authority are not meeting the obligation, even if a human technically appears in the loop.

Conformity evidence in practice

Conformity evidence is the term the Act uses for the artifacts an organization can produce to demonstrate that its AI use complies with the obligations. The artifacts are familiar in shape: risk assessments, technical documentation, monitoring records, incident logs, and the decision trails that connect them. The organizations that produce conformity evidence efficiently are the ones whose underlying systems were instrumented for the purpose; the organizations that have to manufacture the evidence after the fact spend disproportionate time doing so.

The pragmatic preparation is to identify the three or four highest-risk AI uses in the organization, build the conformity evidence pipeline for those, and use them as the reference for everything that follows. The pipeline is reusable: the same instrumentation that produces evidence for one use case produces evidence for the next, with marginal effort. The organizations that have done this find that adding a new high-risk use is a manageable engineering task rather than a compliance project, which is the operational posture the Act was designed to reward.

What to watch in the coming quarter

Two signals will indicate how the enforcement phase is actually unfolding. The first is the substance of the early reviews — whether regulators are accepting the documentation patterns the major providers have established, or pushing for more detail. The second is the pattern of enterprise-side enforcement — whether regulators are pursuing deployers who relied on insufficient provider documentation, which would shift the obligation more clearly onto the deployer's diligence rather than the provider's filing.

Either signal is worth tracking, because the answer will shape how enterprise procurement of AI evolves over the next eighteen months and how much of the assurance work is done in-house versus inherited from providers. The early indications suggest that regulators are willing to pursue both sides of the boundary, which would mean that deployers cannot rely on provider documentation as a complete defense. The organizations that have built their own evidence chain will be best positioned for the resulting regime; the organizations that assumed they could outsource the evidence to their providers will need to revisit that assumption.

Coordination with member-state regulators

Enforcement is happening through a constellation of national competent authorities, not a single central regulator, and the early inquiries are revealing meaningful variation in how different member states are approaching the same obligations. Organizations operating across multiple jurisdictions will need a coordination function that tracks the variation, anticipates conflicts, and produces a unified posture that respects each regulator's local emphasis without fragmenting the underlying compliance program. The function does not need to be large; it needs to be senior enough to make decisions when the requirements diverge and connected enough to know when a divergence is emerging before it becomes a problem.

The pragmatic move for the next two quarters is to identify the regulator most likely to inquire first — usually the one where the organization's largest AI deployment touches the most affected users — and to prepare the evidence chain for that regulator first. The investment will pay against the inquiries that follow, because the evidence chain is reusable across jurisdictions even when the framing of the answer has to be adapted to local emphasis.