The GPAI Code of Practice has been the most quietly important AI regulatory milestone of 2026. It becomes enforceable on 2 August 2026, three weeks before the EU AI Office’s first reporting cycle opens. After that date, the Office can request evidence under Articles 88–92.

If you’re building agents on a GPAI model — and almost every production agent in 2026 is — your deployer obligations under the Code start binding. This article is the operational view: what “enforcement” actually means, what evidence the Office (or your member state’s supervisory authority) will ask for, and what the realistic onset timeline looks like.

Who the Code applies to #

Three tiers of accountability:

GPAI model providers. Headline obligations: model cards, training summaries, copyright compliance, evaluation against systemic risk indicators. Most agent builders aren’t providers — OpenAI, Anthropic, Google, Meta, Mistral are.

GPAI model providers with systemic risk. Additional obligations: adversarial testing, incident reporting, cybersecurity measures appropriate to the model’s risk profile. The current threshold is 10²⁵ FLOPs training compute — the frontier-class models.

Deployers of GPAI-derived systems. This is most agent builders. The Code itself is provider-facing, but the deployer obligations under Articles 9, 13, 14, 16, and 17 are chained through the Code’s provider obligations. If the provider’s Code compliance depends on the deployer’s evidence (e.g. monitoring data), the deployer has to deliver it.

What “enforcement” actually means #

The AI Office is real, staffed, and operational. The European Centre for Algorithmic Transparency (ECAT) is its technical arm. National supervisory authorities have parallel competence in each member state. From 2 August 2026 onward, enforcement powers include:

  • Article 88 — Information requests. The Office or supervisory authority can request technical documentation, model cards, training data summaries, evaluation results, runtime evidence. The request comes with a stated purpose and a deadline (typically 10–30 days).
  • Article 89 — On-site inspections. Less common, but the authority can inspect the provider/deployer’s premises. For cloud deployers, “premises” includes the operational systems that produce the evidence — i.e. your Cloud Logging, your hash-chained audit log, your Vertex Model Registry.
  • Article 90 — Withdrawal from market. The nuclear option for models that demonstrate systemic risk that can’t be mitigated.
  • Articles 91–92 — Fines. Up to €35M or 7% of global annual turnover for the most serious infringements, lower tiers for procedural failures.

What enforcement looks like in practice — based on EU history with GDPR and DMA enforcement — is a phased approach:

  1. Quiet observation period. First 6 months: the Office watches, asks informational questions, doesn’t issue formal information requests. The largest providers (Google, OpenAI, Anthropic, Meta, Mistral, xAI) get most attention.
  2. First wave of formal requests. Q4 2026 to Q1 2027: targeted formal Article 88 requests, usually to providers but with chained-deployer expectations.
  3. First formal proceedings. Mid-2027 onward: against the procedurally non-compliant first (no documentation, no incident reporting). The substantive proceedings (real safety failures, actual systemic risk realised) come later.

Deployer obligations through 2 August #

For deployer-side compliance, the operational checklist for the period leading up to 2 August looks like:

  • Article 9 risk management running and emitting evidence. Your ADK agent’s policy plugin decisions land in a hash-chained audit log with framework citations.
  • Article 13 transparency. End-users interacting with the agent are clearly informed they’re interacting with an AI. The disclosure event is in the audit log.
  • Article 14 human oversight. HITL on high-impact tool dispatches via ADK’s ToolConfirmation primitive, captured in the audit chain.
  • Article 16 — recordkeeping for providers (chained to deployers). Your audit chain is the deployer-side record. Retain for at least the duration of the regulation’s requirement — typically 10 years, which exceeds Regulus’s default of 24 months.
  • Article 17 — quality management system. A documented QMS that covers the AI system. Your audit trail is the operational evidence the QMS references.

What a deployer-side request looks like #

Realistically, deployers will see two kinds of requests:

From the provider. “We received an Article 88 request from the AI Office about systemic risk evaluation. We need evidence from your deployment to respond. Specifically: outcomes monitoring data for the period X to Y, broken down by [demographic or use category]. 30-day deadline.” The provider’s contract with you (your model provider terms) typically obliges you to provide this.

From the supervisory authority directly. Member-state authorities have parallel competence. A national authority might inspect a high-profile EU deployer of an AI agent — typically in financial services, healthcare, or public sector — and ask for runtime evidence.

In both cases, the answer is the same: your hash-chained audit envelope, filtered to the requested scope, exported as a signed envelope with framework citations attached.

What to do in the next 90 days #

If you’re a deployer, the practical checklist:

  1. Confirm your audit log is GPAI-Code-aligned. Article 9 risk categories tagged, framework citations attached, retention long enough.
  2. Establish a 30-day-deadline information-request response runbook. When the request lands, you have 30 days. Practise it.
  3. Reach out to your model provider about their Code commitments and what deployer-side evidence they’ll need from you.
  4. Document the chain. Have your DPO or AI governance lead write the narrative of how your deployment maps to each Article-9 obligation. The runtime evidence is the easy part; the narrative is what makes it audit-ready.

For more, see the EU AI Act profile page and the companion cornerstone Article 9 in code.