AIAI Toolbox
Submit a tool
AI POLICY

EU AI Act GPAI Compliance Checklist for Model Providers

A practical evidence plan for general-purpose AI model providers facing active EU enforcement, including the extra duties for systemic-risk models.

By AI Toolbox Team··12 min read

A general-purpose AI model provider should first document whether it places a GPAI model on the EU market and whether it is also a systemic-risk model. It should then maintain authority-facing technical documentation, give downstream system providers usable capability and limitation information, operate an EU copyright-compliance policy, publish the required training-content summary, appoint an EU authorised representative when applicable, and preserve evidence of cooperation. Systemic-risk providers also need notification, model evaluation and adversarial testing, risk assessment and mitigation, serious-incident reporting, and appropriate cybersecurity. The voluntary GPAI Code of Practice can provide a compliance route, but the provider remains responsible for the binding AI Act duties.

Key takeaways

  • Determine provider, model, market, modification, and systemic-risk status before building controls
  • Keep separate documentation for authorities and for downstream AI system providers
  • Treat copyright policy and the public training-content summary as operating processes, not launch-page copy
  • Open-source exceptions are limited and do not remove every GPAI obligation
  • Systemic-risk models add notification, evaluation, risk, incident, and cybersecurity duties
  • Code signatories still need evidence that commitments operate for each covered model

Decide whether the organisation is a GPAI provider

Start with a release map, not a compliance template. Record the entity that developed the model, the entity placing it on the EU market, names and licences used, distribution channels, API and weight availability, release dates, and every material post-training or architectural modification. The Commission guidelines distinguish model providers from downstream providers and explain that a party making a significant modification can acquire provider obligations. Minor integration work should not automatically be treated as model provision, but the conclusion needs facts and an accountable legal analysis.

Document why the model is or is not general-purpose. A model's label, parameter count, or intended product does not decide the issue alone. Examine the generality of the tasks it can perform, how it is placed on the market, and whether exclusions in the Act and guidelines apply. If the provider is outside the Union, assess the authorised-representative duty before market placement and define who receives authority requests and preserves the underlying evidence.

Then assess systemic-risk status. Article 51 provides a high-impact-capability route and a Commission-designation route. The Act currently presumes high-impact capability when cumulative training compute exceeds 10^25 floating-point operations. Keep auditable compute records and capability evidence, monitor legal updates, and establish a trigger before the threshold is met: Article 52 calls for notification without delay and generally within two weeks after the requirement is met or the provider knows it will be met.

Build the core documentation and transparency evidence

Article 53 creates two different documentation audiences. Technical documentation for the AI Office and competent authorities covers development, training, testing, evaluation, resources, and other Annex XI elements. Information for downstream AI system providers must help them understand capabilities and limitations and comply with their own duties, with Annex XII as the minimum. A public model card may contribute to both, but one generic document is unlikely to satisfy confidential authority needs and practical integration needs equally well.

Create an evidence index rather than a one-time report. Link every assertion to a model version, dataset or data class, evaluation configuration, result, known limitation, mitigation, owner, approval, and update date. Give downstream teams stable change notices, input and output expectations, supported tasks, foreseeable limitations, integration constraints, and evaluation information they can actually use. Preserve protected intellectual property and trade secrets while still delivering the legally required information.

The public training-content summary is a separate obligation. Use the AI Office template and connect its categories to internal data lineage, licences, collection methods, and update controls. The summary does not require publishing every training item, but it must be sufficiently detailed and defensible. If a new training run changes the data mixture, the public summary and supporting record should change together.

Add the systemic-risk safety and security layer

Providers of GPAI models with systemic risk face the Article 55 duties in addition to the baseline. These include model evaluation using appropriate state-of-the-art protocols and tools, documented adversarial testing, assessment and mitigation of possible Union-level systemic risks, tracking and reporting serious incidents and corrective measures, and an adequate level of cybersecurity protection for the model and its physical infrastructure.

Organize evaluations around risk pathways rather than a single benchmark average. Name the capability, plausible actor, access route, affected population or system, severity, uncertainty, mitigation, residual risk, and release decision. Maintain independence between the teams optimizing performance and those challenging the safety case. Test the complete release boundary—including safeguards, access tiers, tool interfaces, monitoring, and documentation—because production controls can materially change both likelihood and consequence.

Cybersecurity needs to cover training infrastructure, model weights and checkpoints, code and dependency integrity, privileged identities, insider risk, exfiltration, serving infrastructure, and incident recovery. Tie controls to the relevant threat and preserve proof: access reviews, build provenance, security tests, monitoring coverage, remediation, and exercises. This article applies official law and Commission guidance; it does not claim legal advice, hands-on assessment, or certification of any named provider.

Choose a compliance route and operate it continuously

The GPAI Code of Practice is voluntary. Its Transparency and Copyright chapters address all covered GPAI providers, while Safety and Security addresses systemic-risk providers. Adhering to an approved code can offer a clearer way to demonstrate compliance until harmonised standards cover the obligations. A provider that does not adhere must be ready to explain alternative adequate means; the Commission guidance also identifies compliance reports among documents submitted through EU SEND.

Make the choice commitment by commitment. Map each legal duty to the code measure or alternative control, the model versions in scope, required artifact, owner, frequency, approval, exception path, and evidence location. Do not label the code as certification or assume signing proves implementation. The Commission's July 2026 Q&A says the code does not impose new legal obligations; it supplies a voluntary route for demonstrating existing ones.

Operate change control across model, training data, compute, capability, licence, distribution, safety framework, and incident taxonomy. Define which changes require documentation updates, renewed evaluation, downstream notice, revised public summary, systemic-risk reassessment, or authority submission. Run periodic evidence reviews and incident exercises. Enforcement powers have applied since August 2, 2026, so a defensible program must show what was true for a particular model release—not merely what the organisation intends to build next quarter.

Practical checklist

  • Identify the legal provider, EU market pathway, model release date, versions, and authorised representative
  • Record the analysis supporting GPAI status and any significant-modification conclusion
  • Assess the systemic-risk compute presumption and the Commission designation criteria
  • Create and maintain the Annex XI technical-documentation evidence set
  • Give downstream providers current Annex XII capability, limitation, and integration information
  • Implement a copyright policy that detects and respects machine-readable rights reservations
  • Publish the training-content summary using the AI Office template
  • Choose, scope, and evidence GPAI Code commitments or document adequate alternative compliance
  • For systemic-risk models, notify on time and run evaluations, adversarial testing, and risk mitigation
  • Define serious-incident detection, escalation, evidence preservation, correction, and EU SEND reporting
  • Test cybersecurity across model artifacts, infrastructure, access, exfiltration, and release processes
  • Review evidence after material model, data, licence, capability, distribution, or code changes

Warning signs

  • The team cannot identify which entity is the provider for an EU release or modification
  • A marketing model card is treated as both authority documentation and downstream integration guidance
  • The copyright policy exists on paper but no system detects or acts on rights reservations
  • The public training summary is unsupported by data lineage or cannot be updated after a new training run
  • Systemic-risk notification depends on a person remembering a deadline after training finishes
  • Incident monitoring cannot connect a harmful event to a model version, evaluation, mitigation, or corrective action
  • Code adherence is treated as certification rather than a voluntary way to demonstrate compliance

Frequently asked questions

When did EU AI Act GPAI enforcement begin?

The GPAI provider obligations applied from August 2, 2025. The Commission's enforcement powers, including fines, applied from August 2, 2026. Models placed on the market before August 2, 2025 have a transition deadline of August 2, 2027.

Is the GPAI Code of Practice mandatory?

No. It is voluntary. A provider may use an approved code to demonstrate compliance until harmonised standards apply, or it may demonstrate alternative adequate means. The AI Act obligations themselves remain binding.

Are open-source GPAI models exempt?

Only partly and only when the statutory licence, access, weight, architecture, and usage-information conditions are met. The Article 53 technical and downstream documentation exception is limited, and it does not apply to systemic-risk GPAI models.

What makes a GPAI model a systemic-risk model?

The Act covers models with high-impact capabilities or equivalent capability or impact designated by the Commission. It currently presumes high-impact capability above 10^25 cumulative training FLOP, subject to legal updates and case-specific assessment.

Does this checklist apply to a company that only uses a third-party model?

Usually the GPAI provider duties target the model provider, not every deployer or downstream integrator. But a company that places a model on the EU market under its name or makes a significant modification may become a provider; separate AI Act duties may also apply to its resulting system.

Primary sources and further reading

Research before you rely.

AI products, prices, policies, and capabilities change. Verify consequential details with primary sources and test tools using representative work.