Your GPAI Model Provider's Compliance Documentation Doesn't Cover Your Deployment

When the Council and Parliament reached provisional agreement on the Digital Omnibus on May 7, most enterprise compliance teams read the headline — Annex III high-risk system obligations moved from August 2026 to December 2027 — and exhaled. Sixteen months of additional runway on requirements that a lot of organizations weren't close to meeting. We covered the full timeline breakdown when the agreement landed: EU AI Act Omnibus VII: High-Risk Deadlines Delayed to 2027–2028.

What the extension didn't touch is the deployer-layer governance obligation that attaches to every GPAI model already running in production. That obligation isn't tied to the Annex III conformity assessment deadline. It runs on a separate track, and for organizations that have been treating their model provider's compliance documentation as their own compliance program, the gap it creates is both provable under audit and getting wider as enterprise GPAI adoption accelerates.

Original Annex III Deadline

Aug 2026 High-risk standalone system obligations under the EU AI Act as originally enacted.

New Annex III Deadline

Dec 2027 16-month extension granted under the Digital Omnibus provisional agreement, May 7, 2026.

Article 50 — Unchanged

Aug 2026 Transparency obligations requiring disclosure when users interact with AI systems. This date did not move.

How the EU AI Act Divides Responsibility Between Providers and Deployers

The EU AI Act's GPAI provisions establish two distinct obligation sets that apply to two different parties. Under Article 53, providers of general-purpose AI models are required to maintain technical documentation, provide information necessary for downstream compliance, establish a copyright policy, and publish a summary of the content used to train the model. These are transparency obligations that apply to the model as a product — what it is, how it was built, what it can do. They apply at the point of supply.

When an enterprise integrates that model into a production environment, a second set of obligations attaches to the deployer. The deployer must ensure appropriate human oversight over consequential decisions, manage risks specific to how the system operates in their environment, and maintain records sufficient to demonstrate that governance ran correctly over actual decisions in actual production sessions. The provider's documentation covers the model as shipped. The deployer's governance program has to cover what the model does once it's running inside the enterprise.

Those are genuinely different things, and no amount of provider documentation produces deployer-layer evidence. Consider a straightforward example: an insurance company integrates a GPAI model into its commercial underwriting workflow. The model provider has published a technical summary, maintained a model card, and fulfilled Article 53 notification requirements. The compliance team files all of it and logs it as EU AI Act coverage. In practice, the agent operates against a proprietary policy document corpus, runs under customer data processing agreements, and generates coverage recommendations that go directly to broker review. Every condition under which the agent operates — the data it can access, the outputs it produces, the customers it affects — was determined by the deployer. When a regulator examines a specific adverse underwriting decision, the provider's model card says nothing about what that agent did in that session, against that customer's data, on that date. That's the deployer's record to produce. If the deployer's governance program didn't generate it, it doesn't exist.

"Provider compliance documents the model as shipped. Deployer governance attests to what the model did in production. These are not the same record, and no regulator examining a specific incident will treat them as equivalent."

OpenBox — "The Shared Responsibility Problem in GPAI Compliance," June 3, 2026

Provider Obligations — Article 53

Technical documentation covering the model's architecture, training data summary, and intended capabilities. This applies to the model as a product at the point of supply.

Downstream compliance information — what the model can do, its known limitations, and what deployers need to know to use it responsibly.

A publicly available training data summary and a copyright compliance policy. These obligations entered into force August 2025 and are not affected by the Digital Omnibus extension.

Deployer Obligations — Production Environment

Human oversight measures appropriate to the specific deployment context — not the provider's reference conditions, but the conditions under which the deployer has actually configured and connected the system.

Risk management documentation specific to the deployment: the data scope, the customer population affected, the decisions the system influences, and the controls in place over each of those.

Production records demonstrating that governance operated correctly over specific decisions. A session-level record that can answer questions about what the agent did, what data it accessed, and what policy governed its behavior.

What the Digital Omnibus Actually Moved

The Digital Omnibus extension was targeted specifically at Annex III conformity assessment requirements — the formal process for proving that a high-risk system meets the Act's technical standards before it goes into production. That deadline moved to December 2, 2027, and for Annex I systems embedded in regulated products, to August 2, 2028. The co-legislators were explicit about why: the technical standards and guidance documents enterprises need to actually conduct conformity assessments weren't ready. The delay is an infrastructure problem, not a policy retreat. The obligation structure didn't change. The clock on proving compliance against it did.

What the extension left alone is everything that was already running. The GPAI model obligations under Article 53 entered into force in August 2025 and are unchanged. Article 50 transparency obligations — the requirement to disclose to users when they are interacting with an AI system — proceed from August 2, 2026 on the original schedule. And the deployer governance obligations that apply to GPAI model integrations already in production don't have a conformity assessment deadline to hide behind. Organizations that deployed GPAI models through 2025 have been accumulating production decisions that were either governed or weren't. The extension doesn't retroactively govern them.

What Enterprise Teams Are Expected to Have in Place

Most enterprise AI compliance programs were built around evaluating what goes into production. The procurement process reviews the provider's documentation. The risk assessment covers the model's known characteristics. The deployment design document describes how the system will be configured. All of that work is correct and necessary. It is also entirely focused on the model before it runs. The EU AI Act's deployer obligations are focused on what happens after — what the model does in the specific environment the deployer controls, over time, against real data, in real sessions.

Three things a deployer compliance program needs to be able to produce that provider documentation cannot produce for them. First, a session-level production record — not a log of outputs, but a record that attests to whether the system was authorized to act under the deployer's current policy conditions at the moment it acted. Logs tell you what the system produced. A governance record tells you whether it was supposed to. Second, a named owner for each production AI system with documented response obligations before an adverse output occurs. The accountability question needs a specific answer before the incident, not after. Most enterprise programs have a general AI risk management framework. A general framework is not an answer to who was responsible for governing a specific decision on a specific date. Third, for high-risk deployments, evidence that human oversight operated in a specific session — not that a review process exists in policy documentation, but that it ran when it was supposed to.

The Workday hiring lawsuit, which we covered earlier this year, is the clearest documented example of what this looks like in practice. Monitoring logs existed. A bias audit had been conducted. But when the accountability question arrived through litigation, what was missing was the governance infrastructure — named owners, human response trails, an audit methodology that could answer questions about specific decisions. The monitoring didn't prevent the liability. See the full coverage: Workday's AI Hiring Lawsuit Exposed the Governance Failure Nobody Wants to Talk About.