The EU AI Act’s general-purpose AI rules are pushing model developers to account for how their systems were built, tested and changed over time. From 2 August 2025, the Act’s obligations for providers of general-purpose AI models have applied to models placed on the EU market after that date. The change is not simply a compliance deadline. It tests whether companies can produce reliable evidence about training data, model capabilities, safety evaluations, copyright practices and incidents identified after release.

The rules cover a category that includes foundation models designed for a wide range of uses and capable of being integrated into downstream products. They do not ban such models or require providers to publish every item of training data. Instead, they establish baseline documentation, transparency and risk-management duties intended to help downstream providers and regulators understand how a model can be used and where its limitations may lie.

The operational challenge is substantial. AI regulation is increasingly an information-management problem: can an organization reconstruct the decisions behind a model after datasets, suppliers, teams, versions and deployment contexts have changed?

EU AI Act general-purpose AI rules are now operational

The EU AI Act entered into force on 1 August 2024, with its provisions applying in stages. Chapter V, which covers general-purpose AI models, became applicable on 2 August 2025. Providers of general-purpose AI models placed on the market before that date have until 2 August 2027 to comply with the Chapter V requirements.

Before the rules took effect, the European Commission published guidelines and a General-Purpose AI Code of Practice to support implementation. The Code is voluntary and does not replace the legal obligations in the AI Act. However, it is intended to provide a route by which participating providers can demonstrate how they meet relevant requirements.

The European AI Office, established within the Commission, has a central role in overseeing general-purpose AI models. The wider framework also involves national competent authorities. The rules treat documentation and risk controls as continuing responsibilities rather than a task completed at a model’s initial release.

What providers must document and disclose

For general-purpose AI models that are not classified as presenting systemic risk, the core obligations focus on traceability and information-sharing. Providers must prepare and maintain technical documentation on the model, including its training and testing processes, capabilities and limitations. They must also provide specified information and documentation to downstream providers building AI systems on top of their models.

Providers must also:

• put in place a policy to comply with EU copyright law, including rules on rights reservations;
• publish a sufficiently detailed summary of the content used to train the model, using a template provided by the AI Office; and
• keep technical documentation current and provide it to the AI Office or national authorities when requested.

The training-data summary is a central compromise in the law. It does not require publication of a full dataset, model weights, source code or confidential technical material. It is intended to provide an overview of the types and sources of training content. How informative those summaries become will depend on regulatory interpretation and enforcement.

Some providers of free and open-source models may qualify for limited exemptions from certain technical-documentation and downstream-information duties. Those exemptions are conditional, do not remove the copyright-policy or training-data-summary requirements, and do not apply to models with systemic risk.

Models with systemic risk face additional duties

The AI Act creates a stricter regime for general-purpose AI models with systemic risk. A model is presumed to present systemic risk when the cumulative computing power used for its training exceeds 10²⁵ floating-point operations. The Commission may also designate a model as carrying systemic risk based on its capabilities or impact. Providers can, in certain circumstances, seek to rebut the presumption.

For these providers, AI Act compliance requires more than maintaining records. They must evaluate models using appropriate protocols and tools, including adversarial testing, to identify and mitigate systemic risks at EU level. They must assess and mitigate those risks throughout the model lifecycle, maintain an adequate level of cybersecurity protection, and track, document and report serious incidents and possible corrective measures without undue delay.

This is different from a company stating that a model passed internal testing. The rules require providers to consider whether testing addresses plausible failures, whether risks can be identified after deployment, and whether the organization can show how it responded.

Why AI model documentation is difficult

Modern model development does not always produce a single, stable record. Training data may combine licensed material, publicly available content, synthetic data, internal datasets and third-party sources. A base model may then be fine-tuned, distilled, modified through post-training, connected to external tools or incorporated into products by organizations far removed from the original developer.

Important decisions are distributed across research, engineering, legal, security and product teams. These include data-filtering choices, annotation rules, benchmark selection, safety tuning, threshold settings and decisions about known limitations. If those decisions are not recorded when they are made, reconstructing them later may be difficult.

The practical consequence is that providers will need more than a compliance document assembled shortly before release. They will need version histories, data-governance records, reproducible evaluation results, change-management records, incident workflows and clear ownership for maintaining documentation.

What credible evidence may include

• Records connecting a specific model version to its training, fine-tuning and safety processes.
• Evaluation reports identifying the model tested, methodology used, known limitations and conditions in which results may not apply.
• Risk assessments linking identified hazards to mitigation measures and follow-up testing.
• Incident logs showing how reports were received, assessed, investigated and escalated.
• Documentation for downstream providers that supports safe integration and does not merely shift responsibility.

Such records cannot guarantee that a model will be safe or lawful in every setting. Models can behave unexpectedly in new contexts, and testing cannot anticipate every misuse. But evidence makes claims about safety and reliability easier to scrutinize when failures occur.

The effects may extend beyond the EU

The Act applies to providers that place general-purpose AI models on the EU market. Its scope can also reach some actors outside the EU where AI-system outputs are used in the Union, subject to the Act’s scope provisions. Global developers may therefore decide that common internal documentation, evaluation and incident-response processes are more practical than maintaining separate governance systems for each market.

That outcome is not inevitable. Companies can use different releases, contractual terms or deployment options across jurisdictions. Still, internal controls such as model inventories, evaluation records and incident-reporting processes may be easier to standardize than product-specific technical changes.

The unresolved question is what “enough” means

The law establishes obligations, but practical standards will be shaped by guidance, supervisory practice and enforcement. Regulators will need to assess how detailed training-data summaries must be, whether evaluations test plausible risks rather than generate reassuring metrics, and how requirements should be applied proportionately.

Trade-secret protections remain relevant. The AI Act does not require authorities to publish confidential information they receive. At the same time, confidentiality cannot eliminate the need for regulators to assess provenance, testing and foreseeable risks. The purpose of the regime is not public access to every technical detail; it is access to sufficient information for oversight to function.

The real test of the EU AI Act general-purpose AI rules will be whether they make models more inspectable when failures occur. If developers can identify the deployed model version, explain what it was trained and tested to do, document known risks and show corrective action, the rules may improve accountability. If compliance produces only polished paperwork disconnected from development practice, the new requirements will add records without adding much knowledge.

Image by michelbossart on Pixabay.