GPAI Code of Practice: Enforcement, Audit Readiness & August 2026 Compliance Checklist
Post #5 in the sota.io EU AI Act GPAI Code of Practice Series
August 2, 2026 is no longer a distant planning horizon. It is the enforcement date for the EU AI Act's General-Purpose AI chapter — and with it, the moment when theoretical obligations become enforceable law. The European AI Office gains investigative powers, non-compliant providers face fines measured in global annual turnover, and organisations that treated the GPAI Code of Practice as optional reading now face the consequences.
This fifth and final post in the GPAI Code of Practice series covers what enforcement looks like in practice, how to prepare your organisation for an AI Office audit, and provides a 30-item compliance checklist that consolidates everything covered across the previous four posts.
What Posts #1–#4 Covered
Before the checklist, a brief recap of the series:
- Post #1 — Introduction: What the CoP is, the two-tier GPAI structure, why signing matters, and the compliance presumption mechanism.
- Post #2 — Model Cards & Transparency Documentation: Art.52 technical documentation requirements, model card structure, downstream provider information obligations.
- Post #3 — Copyright Compliance & Training Data Audit: Art.53 copyright track, rights reservation compliance (TDM opt-out), training data documentation.
- Post #4 — Systemic Risk Assessment & Red Teaming: Art.53 systemic risk regime, the 10²⁵ FLOPs threshold, adversarial testing protocols, incident notification to the AI Office.
This post covers what happens after the August 2 deadline — the enforcement regime, audit process, penalties, and the practical compliance roadmap.
The EU AI Office: Enforcement Authority for GPAI
The EU AI Office (EUAIO), established within the European Commission's DG CNECT, is the primary enforcement body for GPAI model providers. Unlike national competent authorities that handle high-risk AI system oversight, the AI Office holds exclusive Union-level jurisdiction over GPAI models — regardless of where in the EU those models are accessed.
What the AI Office Can Do Post-August 2026
Under the market surveillance and enforcement framework in Article 74 of the EU AI Act, the AI Office holds investigative and corrective powers that include:
Investigation powers:
- Request technical documentation, model cards, and training data records from GPAI providers
- Commission independent model evaluations by qualified experts at the provider's expense
- Access internal audit trails, red teaming results, and incident logs
- Conduct on-site inspections at provider premises
Interim measures:
- Order temporary suspension of a GPAI model's access in the EU market where imminent risk exists
- Require immediate corrective actions within defined deadlines
Enforcement actions:
- Issue binding decisions requiring compliance measures
- Impose financial penalties where non-compliance is found
For systemic risk models, Article 74 also enables qualitative classification reviews — the AI Office can reclassify a model as systemic risk based on capability assessments, even if the model falls below the 10²⁵ FLOPs compute threshold.
Penalties Under Article 99
Article 99 of the EU AI Act sets financial penalties at levels designed to have deterrent effect on large-scale operators:
| Violation | Maximum Fine |
|---|---|
| Non-compliance by GPAI model provider (all obligations) | €15,000,000 or 3% of global annual turnover — whichever is higher |
| Systemic risk obligation non-compliance | €30,000,000 or 6% of global annual turnover — whichever is higher |
| Provision of incorrect, incomplete or misleading information to AI Office | €7,500,000 or 1% of global annual turnover — whichever is higher |
Two critical notes for SaaS developers:
1. "Provider" liability extends to API integrators in some contexts. If your organisation fine-tunes a GPAI model for deployment, you may be considered a provider under the Act — not merely a deployer — for the fine-tuned model. This distinction matters significantly for penalty exposure.
2. Deployers face separate obligations. Even organisations that only integrate GPAI APIs without modification face transparency obligations under Article 50 (covered in the previous series) and must maintain documentation of their GPAI API usage. Non-compliance here carries separate penalty exposure.
What an AI Office Audit Looks Like
The GPAI enforcement framework is not primarily complaint-driven. The AI Office can initiate investigations on its own motion — it is not waiting for a third party to file a complaint. Organisations that monitor the AI Office's activity (via the EU AI Act official journal and the EUAIO website) will see an increase in formal inquiries starting in Q4 2026.
The Audit Request Pattern
An AI Office audit typically initiates with a formal information request — a written demand for documentation under Article 74. The request will specify:
- The model or models under investigation
- The documentation categories required (technical docs, training data summary, red teaming results, incident logs)
- The deadline for response (typically 30 days, with possible extension on request)
- The consequence of non-response or incomplete response (enforcement action under Article 99)
The organisation then has three phases:
Phase 1 — Document assembly: Gather all CoP deliverables (model card, training data documentation, copyright compliance evidence, red teaming reports, systemic risk assessment if applicable) and verify they are current and complete.
Phase 2 — Legal review: Counsel reviews documentation for any claims that cannot be substantiated. Any gaps identified at this stage create significant risk — the AI Office may treat gaps as evidence of non-compliance, not as items to fix during the audit.
Phase 3 — Response submission: Provide the full documentation package to the AI Office within the deadline. Maintain a record of what was submitted and when.
The Difference Between Documented and Defensible
The most common compliance failure in regulatory audits is not the absence of a compliance programme — it is the inability to demonstrate that the programme operates continuously and was operational at the time of the alleged non-compliance.
For GPAI CoP purposes: documentation dated after August 2, 2026 that was created in response to an audit request does not retroactively establish compliance. The AI Office will ask for evidence of pre-August 2 implementation — model evaluations completed before the deadline, training data audits that existed before August 2, red teaming exercises that were conducted, not planned.
This is why the checklist below front-loads documentation requirements with explicit dating and version control.
The CoP Compliance Presumption: How It Works
One of the GPAI Code of Practice's central mechanisms is the compliance presumption. Providers that sign the CoP and demonstrably implement its obligations receive a presumption of compliance with the corresponding EU AI Act articles — shifting the burden of proof to the AI Office if they seek to establish non-compliance.
This presumption is not automatic. It requires:
- Active signing — the provider is listed as a signatory on the AI Office's official CoP registry
- Implementation documentation — evidence that CoP measures are implemented operationally, not just stated in a policy document
- Update tracking — as the CoP evolves (the final text was expected July 2026), signatories must adopt updated requirements within the grace periods specified
For non-signatories: compliance with the EU AI Act is still possible, but the organisation must demonstrate compliance through alternative means acceptable to the AI Office. This creates significantly more documentation and legal overhead than CoP adherence.
30-Item GPAI Compliance Checklist
The following checklist consolidates obligations from the entire five-post series. It is structured by priority: items that must be complete before August 2, 2026, followed by ongoing post-deadline operations.
Pre-August 2 Mandatory Completions
Model Documentation (Art.52, Post #2)
- Model card drafted, reviewed, and dated with version number
- Training data scope documented (data categories, sources, geographic distribution)
- Model capabilities and limitations formally described
- Known failure modes and edge case behaviours documented
- Architecture documentation at sufficient detail for downstream assessment
- Information package for downstream deployers prepared and available
Copyright Compliance (Art.53, Post #3)
- Training data sources reviewed for rights reservation notices
- TDM opt-out compliance verified: your crawler respects machine-readable opt-out signals
- Copyright compliance procedure documented and dated
- Legal basis for each training data source category established
Systemic Risk Classification (Art.51, Post #4)
- Training compute calculated and documented (or confirmed below 10²⁵ FLOPs)
- For sub-threshold models: compute documentation retained to rebut potential qualitative classification
- For systemic risk models: classification documented and communicated to AI Office
Systemic Risk Obligations (Art.53 systemic risk track, Post #4)
- Model evaluation against standardised protocols completed and documented
- Adversarial testing (red teaming) conducted by qualified independent experts
- Red teaming report dated, versioned, and retained
- Serious incident threshold definitions documented
- Incident notification procedures established and tested
AI Office Registration
- GPAI model registered in the EU AI Act database
- Registration entry current and matching technical documentation version
CoP Engagement
- CoP signing status confirmed (signatory or alternative compliance path documented)
- If signatory: compliance with current CoP draft version verified
- If non-signatory: alternative compliance documentation prepared
Ongoing Post-August 2 Operations
Continuous Monitoring
- Model evaluation schedule established (frequency appropriate to model update cadence)
- Red teaming exercises scheduled at regular intervals
- Training data policy review procedure in place for model updates
Incident Management (Art.73)
- Serious incident monitoring active
- AI Office notification procedure operational (contact points, response templates)
- Incident log maintained with timestamps
Market Surveillance Readiness (Art.74)
- Information request response procedure established
- Documentation storage organised for rapid retrieval under 30-day response window
- Legal contacts identified for Art.74 enforcement proceedings
Downstream Obligations
- Current information package available to all downstream deployers
- Update distribution procedure for material model changes
- Deployer documentation of API terms of service aligned with AI Act obligations
Infrastructure Compliance: Where Your GPAI Stack Runs
One aspect of GPAI compliance that often receives insufficient attention is the infrastructure layer — where model inference runs, where audit logs are stored, and where training data evidence is held.
The EU AI Act imposes documentation obligations that require records to be producible to the AI Office within defined timeframes. If those records live in US-headquartered cloud infrastructure, they are subject to the US CLOUD Act — meaning US law enforcement can compel their disclosure without your knowledge or consent, and potentially without the ability to notify you.
For organisations building compliance programmes designed to withstand AI Office scrutiny, this creates a structural tension: you are building documentation designed to demonstrate EU regulatory compliance, while storing that documentation on infrastructure governed by a competing legal regime.
The practical response is to ensure that audit-relevant records — model evaluation reports, red teaming documentation, incident logs, training data summaries — are stored on EU-native infrastructure not subject to US jurisdiction. Hetzner Germany, managed through a platform without US parent company exposure, provides a clean jurisdictional boundary.
sota.io is built specifically for this: EU-native managed hosting, Hetzner Germany infrastructure, no US parent, no CLOUD Act exposure. For GPAI providers building audit-ready infrastructure, the hosting layer is part of the compliance stack.
Summary: The GPAI Code of Practice Series
This five-post series has covered the complete GPAI compliance landscape for organisations subject to the EU AI Act GPAI chapter:
| Post | Focus | Core Obligation |
|---|---|---|
| #1 Introduction | What is the CoP, who it applies to, the compliance presumption | CoP signing + understanding two-tier structure |
| #2 Model Documentation | Technical documentation and transparency requirements | Art.52 model cards and downstream information |
| #3 Copyright Compliance | Training data audit and rights reservation compliance | Art.53 copyright track |
| #4 Systemic Risk Assessment | Red teaming, capability evaluation, incident thresholds | Art.53 systemic risk obligations |
| #5 Enforcement & Audit Readiness | Penalties, AI Office powers, audit preparation | Art.74 market surveillance + Art.99 penalties |
The enforcement window opens in 57 days. Organisations that have completed the checklist above are positioned to respond to AI Office requests with confidence. Those that have not started face a compressed timeline — but the checklist is still achievable before August 2 if work begins now.
The EU AI Office's first enforcement actions will establish precedent for how rigorously GPAI obligations are interpreted. Being audit-ready before that precedent is set — not after — is the strategic position.
This post is the fifth in the sota.io EU AI Act GPAI Code of Practice series. Previous posts covered the CoP introduction, model documentation, copyright compliance, and systemic risk assessment. sota.io is an EU-native managed PaaS — Hetzner Germany, no CLOUD Act, GDPR-native — designed for teams building EU-compliant AI infrastructure.
EU-Native Hosting
Ready to move to EU-sovereign infrastructure?
sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.