What became applicable on 2 August 2025
The EU AI Act’s obligations for providers of general-purpose AI models apply from 2 August 2025. These duties sit on the model provider, not automatically on every enterprise that integrates or uses a GPAI model inside an application. For AI governance leaders, the first compliance task is to inventory GPAI models that the organization develops, substantially modifies and places on the market, procures, or embeds in production systems, then map each asset to the correct legal role.
Baseline obligations apply to all GPAI model providers. Providers must draw up and keep up-to-date technical documentation covering training and testing processes and evaluation results, and make that documentation available to the AI Office and national competent authorities upon request. They must establish a policy to comply with Union copyright law and publish a sufficiently detailed summary of the content used for training. They must also prepare and share information and documentation with downstream providers of AI systems so those parties can meet their own AI Act obligations.
Compliance with GPAI obligations may be demonstrated through adherence to approved codes of practice until harmonised standards are published. The GPAI Code of Practice process is led with the EU AI Office. Internal control frameworks should therefore map documentation, copyright, evaluation, and information-sharing practices to code commitments and retain gap analyses as guidance and standards mature.
Systemic-risk GPAI models: additional obligations
A GPAI model is presumed to present systemic risk when the cumulative amount of compute used for training exceeds 10^25 floating-point operations. The Commission may also designate models as presenting systemic risk based on capabilities and impact. Designation beyond the compute presumption is case-by-case, so organizations near the threshold need monitoring processes for both internal compute records and official designation decisions.
Providers of GPAI models with systemic risk must go beyond the baseline package. They must perform model evaluation, including adversarial testing; assess and mitigate systemic risks; document and report serious incidents to the AI Office; and ensure an adequate level of cybersecurity protection. Serious-incident reporting and related post-market monitoring duties complement technical documentation and risk-mitigation evidence. For enterprise programs, this typically means continuous evaluation pipelines, a living systemic-risk register, hardened model-serving and training environments, and AI Office incident-reporting runbooks with defined retention and escalation paths.
| Obligation area | All GPAI providers | Systemic-risk GPAI |
|---|---|---|
| Technical documentation | Up-to-date docs on training, testing, and evaluation; available to authorities on request | Same baseline, plus evaluation and risk evidence supporting systemic-risk controls |
| Copyright and transparency | Union copyright-compliance policy; sufficiently detailed public training-content summary | Same baseline expectations |
| Downstream information | Share information and documentation with downstream AI-system providers | Same baseline expectations |
| Evaluation and risk | Covered through baseline documentation and testing records | Model evaluation including adversarial testing; assess and mitigate systemic risks |
| Incidents and security | Baseline operational controls as applicable | Serious-incident reporting to the AI Office; adequate cybersecurity protection |
Provider, modifier, and downstream deployer accountability
Enterprises must classify their relationship to each GPAI model before they assign controls. Original providers develop and place models on the market. Modifiers who substantially change a model and place the result on the market can take on provider obligations for the modified model. Downstream deployers integrate or use models inside AI systems and applications; they do not automatically inherit full GPAI provider duties, but they do carry AI-system and use-context obligations where those apply.
Role analysis should follow model lineage: base model, fine-tune or modification, and the system version that reaches production. That lineage determines who must produce technical documentation, copyright materials, training-content summaries, and systemic-risk files, and who must instead obtain downstream information packs and govern runtime use.
Documentation, copyright, and downstream evidence
Technical documentation expectations for GPAI models cover architecture and training-process descriptions, data governance relevant to training, compute used, evaluation methodologies and results, and known limitations. These materials should be versioned and stored in immutable or tamper-evident form so they can be produced on authority request. Logging, evaluation traces, and incident records are core evidence artifacts for both baseline GPAI and systemic-risk duties.
Copyright and transparency evidence is distinct from full dataset disclosure. Providers need a maintained copyright-compliance policy and a public training-content summary that is detailed enough to support copyright and transparency objectives without dumping raw training data. Downstream information packages must be sufficient for AI-system providers to complete conformity, transparency, and risk documentation when building on the model. Practically, that means structured exports of capabilities, limitations, acceptable-use constraints, and evaluation summaries that procurement and system-compliance teams can validate before production use.
Organizations that only deploy or integrate models should contractually require upstream GPAI providers to deliver mandated downstream documentation and update channels. Gate production release on receipt and validation of those artifacts. Organizations that develop or re-place models must stand up internal evidence workflows for technical documentation versioning, copyright-policy attestation, training-content summary publication, and, where relevant, systemic-risk evaluation and incident files.
Control planes for GPAI evidence and runtime AI operations
Enterprise architecture should separate the model-provider evidence plane from the runtime AI-system and agent control plane. The evidence plane holds training documentation, copyright policy records, evaluation reports, systemic-risk assessments, and serious-incident files. The runtime plane governs how GPAI-enabled applications and agents act: who the agent is, what tools it may call, which policies apply, and what audit trail is retained.
Lineage metadata should link base GPAI models, fine-tunes or modifications, and downstream system versions. That lineage is how governance teams determine who holds provider versus deployer duties for each release. Downstream information packs should be consumable by procurement and system-provider compliance workflows, not trapped in ad hoc documents.
For GPAI-enabled agents and tool use, runtime controls support auditable operations even when the organization is not the GPAI model provider. Agent identity, least-privilege permissions, tool approval paths, and policy enforcement at the tool-call gateway create records of purpose, decision, and outcome for consequential actions. Those records help demonstrate governance of AI-system behavior, human oversight arrangements where required, and investigation readiness when downstream misuse or serious incidents are reported. Trussed AI focuses on this runtime governance layer for enterprise agents, including agent identity, permissions, policy enforcement, and audit logging, which complements provider-side model documentation rather than replacing it.
Operational separation
Keep provider-side model evidence (docs, copyright, evals, incidents) distinct from deployer-side runtime controls (identity, permissions, policy, logs). Connect both with lineage so audits can show which role applies to each release.
Operational checklist for AI governance leaders
Translate the August 2025 applicability date into concrete operating decisions across engineering, legal, security, procurement, and AI governance.
- Inventory GPAI models the organization develops, substantially modifies and places on the market, procures, or embeds in production.
- Map each model and release to original provider, modifier-provider, or downstream deployer roles using lineage metadata.
- For provider roles: version technical documentation, maintain copyright-compliance policy attestation, publish or prepare the training-content summary, and package downstream information for AI-system providers.
- For systemic-risk models: run evaluation including adversarial testing, maintain a systemic-risk register, harden training and serving environments, and define AI Office serious-incident reporting runbooks.
- For deployer roles: contract for upstream documentation and update channels; gate production on validated downstream packs.
- Stand up runtime controls for GPAI-enabled agents: identity, least-privilege tool permissions, policy enforcement, and retained decision logs.
- Map practices to approved codes of practice while standards mature, and retain gap analyses.
Governance practices that keep roles and evidence coherent
Strong GPAI programs stay useful under audit because they separate model obligations from system and use-context obligations, then connect both with lineage and logging.
- Do not collapse provider and deployer duties: Original and modifier providers own GPAI model obligations. Deployers own AI-system and use-context obligations, including high-risk rules and human oversight where those apply.
- Treat evidence as a product, not a binder: Version technical docs, eval results, copyright attestations, and incident records so they can be exported to authorities, customers, and downstream system teams on demand.
- Use runtime policy enforcement as operational proof: Identity-bound tool permissions, approval workflows, and retained decision logs show how GPAI-enabled agents were constrained in production, which supports governance even when model weights are upstream.
- Plan for uncertainty without delaying controls: Codes of practice, fine-tuning edge cases, and designation criteria will continue to refine expectations. Maintain conservative role analysis and update paths rather than waiting for perfect clarity.