The Date That Did Not Move: GPAI Enforcement Is Now Live

Two summers ago the AI Act gave the calendar one anchor date that almost everyone circled: 2 August 2026. Then the Digital Omnibus moved the headline obligations — the core high-risk requirements in Chapter III now apply from 2 December 2027 and 2 August 2028¹ (we analysed that deferral in The AI Act Delay Is Not a Reprieve) — and the collective exhale was audible. But under that headline, one date did not move. On 2 August 2026 the European Commission’s supervision and enforcement powers over providers of general-purpose AI (GPAI) models became applicable². The substantive GPAI obligations have applied since 2 August 2025; what arrived with that date is the machinery to enforce them — and the power to fine. The enforcement architecture is now operational, although the compliance position of an individual model still depends on when it was placed on the Union market. For a DACH CISO or DPO, the right question is not “are we a model provider?” — most ordinary enterprise users are not, though fine-tuning, rebranding or placing a modified model on the market can change that assessment — but “what does live GPAI enforcement do to the model sitting underneath many of the generative-AI tools we deploy?”

Key Takeaways

• The asymmetry is the story. The core Chapter III obligations for high-risk AI systems were deferred; GPAI enforcement was not. As of 2 August 2026, the Commission can exercise its Chapter V powers against GPAI model providers².
• The powers are concrete: request information (Art. 91), conduct evaluations including model access where information under Art. 91 proves insufficient or a systemic risk is under investigation (Art. 92), and, where necessary and appropriate, request measures up to market restriction, withdrawal and recall (Art. 93)³.
• The fines are real: up to 3% of worldwide annual turnover or €15 million, whichever is higher, under Article 101⁴.
• But legacy models have until 2027. Providers of GPAI models placed on the Union market before 2 August 2025 must comply by 2 August 2027 under Article 111(3) — a date the Omnibus left untouched. The enforcement powers are live now; the underlying compliance deadline still depends on when the model was placed on the market⁵.
• You are most likely a downstream provider or a deployer, not a model provider — and the distinction decides which duties attach. Downstream providers depend on the model provider’s documentation (Art. 53(1)(b)) and hold a complaint right that feeds enforcement (Art. 89(2))⁶.
• Another major set of obligations became applicable the same day: the Article 50 transparency duties — but they are allocated by role, not imposed uniformly, and only the provider’s machine-readable marking duty under Art. 50(2) gets a transition to 2 December 2026⁷.

What “enforcement powers become applicable” actually means

The obligations and their enforcement were deliberately split in time. GPAI model providers have been subject to the substantive duties of Chapter V — keeping technical documentation current, passing information down to downstream providers, adopting an EU-copyright policy, and publishing a training-content summary — since 2 August 2025⁸. But providers were given a one-year adjustment period before the Commission could start acting against them. That period ended on 2 August 2026².

One qualification belongs next to that sentence. Under Article 111(3), providers of GPAI models placed on the Union market before 2 August 2025 have until 2 August 2027 to bring those models into compliance — a date the Digital Omnibus left untouched⁵. So the machinery is live for everyone, but a legacy model is not automatically in breach. Which side of 2 August 2025 a model falls on is now a due-diligence question with a concrete answer.

From that date, the Commission — which holds the exclusive power to supervise and enforce Chapter V under Article 88 and exercises it through the AI Office — can do four things³:

Read those together and the design becomes clear: this is not a documentation regime. The Commission can require a frontier-model provider to grant access to the model for evaluation, and where a systemic risk is substantiated, request mitigation or, ultimately, market restriction, withdrawal or recall. This centralised enforcement structure is unusual within the AI Act, which otherwise assigns much of the supervisory architecture to national authorities. And it lands while the core high-risk regime is still on the runway.

Why a DACH organisation that builds nothing should care

Most German and Austrian organisations — and Swiss organisations falling within the AI Act’s territorial scope under Article 2 — are not GPAI model providers. They are downstream providers, meaning they integrate a model into an AI system they then place on the market or put into service, or they are deployers, meaning they use an AI system under their own authority⁶. That distinction is not cosmetic: it decides which duties attach and whom you can ask for what. It is tempting to read GPAI enforcement as a fight between Brussels and the large labs that has nothing to do with you. Three reasons it does.

First, your compliance may rest on their documentation. Under Article 53(1)(b), the model provider must make information and documentation available to providers of AI systems who intend to integrate the model into their AI systems — downstream providers, not deployers generally⁸. If you integrate a model into a high-risk AI system as a downstream provider, your technical documentation and conformity work will depend heavily on what the upstream provider hands you when the relevant high-risk obligations become applicable in December 2027 or August 2028; how the DPIA and the FRIA interlock in that work is its own exercise, which we set out in DPIA vs. FRIA. If you are only a deployer of a finished SaaS product, your route runs through your immediate vendor rather than the model provider — which makes the contract the control. Enforcement, applicable as of 2 August 2026, is what gives the upstream obligation teeth. The practical move now is to check your AI vendor contracts for whether that documentation flow is actually promised — the same gap we examined in The DPA Is a Promise, Not a Control.

Second, there is a route into enforcement. A downstream provider has the right to lodge a duly reasoned complaint with the AI Office alleging an infringement by a model provider (Art. 89(2)); any natural or legal person may complain to a national market surveillance authority, which can in turn ask the Commission to use its Chapter V powers (Art. 85, Art. 88(2))⁶. If a model you depend on is non-compliant in a way that exposes you, you are not a bystander — you have a formal complaint route. Note the precision: this is an administrative complaint mechanism, not judicial standing, and using it means documenting how the upstream failure actually blocks your own compliance work. The existence of that route may also strengthen escalation discussions with an upstream provider — which is why it belongs in your vendor-escalation playbook alongside the documentation clauses of your DPA and SLA, rather than being invented under pressure.

Third, the Code of Practice tells you where to look. The Commission has said it will focus enforcement on monitoring signatories’ adherence to the GPAI Code of Practice, and that signatories benefit from increased trust⁹. That makes a provider’s signature — or its absence — a procurement signal, but not a compliance certificate. Adherence is voluntary and assessed chapter by chapter: xAI, for instance, signed only the Safety and Security Chapter and must demonstrate compliance with the transparency and copyright obligations by alternative adequate means¹⁰. The practical step is to map each AI tool in your estate to its underlying model and provider, check that provider against the official signatory list, note which chapters were signed, and add the question to your procurement questionnaire.

The same-day obligations that may apply to your organisation

Article 50 does not impose the same obligation on every organisation, and reading it as “we must label our AI content” is the most common way to get this wrong. Providers of systems intended to interact directly with natural persons must design them so that people are informed they are dealing with an AI system, unless that is obvious (Art. 50(1)). Providers of systems generating synthetic audio, image, video or text are responsible for marking the outputs in a machine-readable format, detectable as artificially generated or manipulated — watermarking is one technique, not the legal standard (Art. 50(2)). Deployers have separate disclosure duties in specified cases: emotion-recognition and biometric-categorisation systems (Art. 50(3)), deepfakes, and AI-generated text published to inform the public on matters of public interest (Art. 50(4))⁷.

The four-month transition to 2 December 2026 is narrower than it is usually reported. New Article 111(4), inserted by the Omnibus, gives providers of generative AI systems placed on the market before 2 August 2026 until that date to comply with the Article 50(2) machine-readable marking duty. It does not postpone the Article 50(3) or 50(4) deployer duties, and it does not apply to anything placed on the market from 2 August 2026 onward — that complies immediately⁷. And classification still comes first: whether a given tool is even “an AI system” in the legal sense, and in which role you meet it, decides which obligations attach at all — which is where any honest compliance programme has to begin (we set out that test in What Is an AI System?).

Three things to do this week

1. Build the model inventory — with dates and roles. For every AI tool in your estate, record which model sits underneath it, who provides that model, whether it was placed on the Union market before or after 2 August 2025, whether the provider signed the Code of Practice and which chapters, and — for each tool — whether your organisation is acting as a deployer or as a downstream provider. Most organisations can name their vendors; far fewer can name the models, the dates and their own role. That gap is the whole problem in one line.
2. Route the documentation request correctly. Where Article 53(1)(b) applies because you or your immediate vendor qualify as a downstream provider, request the documentation through the contractual supply chain and log who cannot produce it. If you are only a deployer, require your AI-system vendor to provide what you need for your own governance, impact assessment and oversight duties. That log is your evidence when the high-risk obligations become applicable, and your leverage at the next renewal.
3. Run an Article 50 sweep by role. List every system you provide and every system you merely deploy. For the ones you provide: interaction disclosure under 50(1) and machine-readable marking under 50(2), with the 2 December 2026 transition available only for generative systems already on the market before 2 August 2026. For the ones you deploy: check whether emotion recognition, biometric categorisation, deepfakes or public-interest text apply — those duties have no transition. The seven-step version of that sweep — with the Article 5 prohibitions screened first — is in Article 50 Implementation Strategy.

The delay reshaped the calendar; it did not empty August. The first enforceable edge of the AI Act sharpened on schedule.

The organisations that misread this date are the ones that filed the whole AI Act under “2027.” The core high-risk clock moved. The enforcement clock did not. Which model sits underneath your most-used AI tool, when was it placed on the market — and can you show, in your own records, that its provider is one you would want a regulator to evaluate?