Europe’s rules for general-purpose artificial intelligence are moving from policy design into day-to-day compliance. The obligations for providers of general-purpose AI, or GPAI, started applying on August 2, 2025. The European Commission says it can use its enforcement powers for those obligations from August 2, 2026, while models placed on the market before August 2025 have a later compliance date in 2027.
That timetable matters beyond a small group of model developers. General-purpose models sit underneath writing assistants, coding tools, search products, customer-service systems, and many specialized applications. Documentation and risk controls at the model layer affect what downstream companies can learn about the systems they deploy.
GPAI Is a Layer, Not Every AI Product
The EU AI Act separates a general-purpose model from an AI system built around it. A model is a trained component with broad capabilities. A system adds interfaces, instructions, retrieval, tools, safety controls, and a defined use. A company that provides a broadly capable model in the EU can have GPAI obligations even when another company builds the consumer-facing product.
This distinction prevents teams from treating compliance as a label attached only to an app. It also makes provider identity important. A business that substantially modifies an existing model may become a provider for the modified model, depending on what it changes and how it places the result on the market. The Commission’s guidelines explain how it will approach these definitions, including significant modifications and the roles of actors in the value chain.
Documentation Must Travel Down the Supply Chain
A GPAI provider must prepare and maintain technical documentation and give relevant information to downstream providers. The goal is not to publish every trade secret. It is to give integrators enough reliable information to understand capabilities, limitations, intended uses, and technical requirements.
That information can support the more concrete evaluations described in our guide to real-world AI testing. A downstream team still has to test its own application, users, data, and operating environment. Model documentation is an input to that work, not a substitute for it.
Useful documentation also needs version discipline. A safety finding for one model release may not apply after new training, fine-tuning, tool access, or a changed context window. Providers and deployers need a way to connect evidence to the exact model and configuration in use.
Copyright Policy and Training Summaries Are Separate Duties
The Act requires GPAI providers to maintain a policy for complying with EU copyright law. It also requires a sufficiently detailed public summary of the content used to train the model, following a template from the Commission. These are related transparency measures, but they are not the same thing.
A training-content summary will not normally function as a complete list of every individual item in a large dataset. Its value is to make major data categories, sources, and collection approaches more visible. The copyright policy concerns how the provider handles lawful access, rights reservations, and other obligations. Neither requirement automatically settles a dispute about a particular work.
This is also different from proving where a finished image or video came from. Our article on content credentials and media provenance explains that separate, output-focused problem.
Open-Source Models Receive a Limited Exemption
The AI Act provides exemptions from some documentation duties for certain models released under a free and open-source license with publicly available parameters. The exemption is not universal. The Commission’s guidelines describe conditions around access, information, and monetization, and the lighter treatment does not remove the additional duties for a model with systemic risk.
That nuance matters because “open source” is often used loosely. Publishing model weights is not necessarily enough to satisfy every condition, and a license label does not answer questions about training data, evaluation, or downstream safety. Teams should examine the actual release terms and the way the model is distributed.
Systemic-Risk Models Face a Higher Bar
GPAI models with systemic risk have additional obligations. The Act creates a presumption based on training compute above 10^25 floating-point operations, while also allowing designation based on capabilities and impact. Providers of these models must perform model evaluations, assess and mitigate systemic risks, track and report serious incidents, and provide an adequate level of cybersecurity protection.
The relevant risks can be broader than an inaccurate answer in one chat. They may include the spread of a powerful capability across many downstream systems, misuse, loss of control over access, or failures that affect public safety and fundamental rights. Evaluation therefore has to connect technical tests with plausible deployment conditions and threat models.
Reporting a benchmark score alone is not enough. Providers need evidence about the tests used, known blind spots, mitigations, incident processes, and how results change after updates. Downstream developers need to decide what additional controls their particular application requires.
The Code of Practice Offers a Compliance Route
The voluntary General-Purpose AI Code of Practice is organized around transparency, copyright, and safety and security. The European Commission and the AI Board assessed it as an adequate voluntary tool for providers to demonstrate compliance with the relevant AI Act obligations.
Signing the code is not the same as receiving immunity from enforcement. It offers a structured route for showing how obligations are met. Providers can use other methods, but they must still demonstrate compliance. For buyers, participation in the code can be one signal to investigate, alongside documentation quality, evaluation evidence, change notices, and contract terms.
What Changes for Ordinary Businesses
Most businesses using an AI service will not become GPAI providers simply because employees use a model. They can still feel the effects through new documentation, updated service terms, model-risk information, and requests from suppliers or customers. A company embedding a model into a high-impact workflow has its own responsibilities that depend on the use case and its role under the Act.
A practical preparation list is straightforward:
- Record the exact models, versions, providers, and regions used in each important product.
- Keep provider documentation and change notices with the application’s own test evidence.
- Define who reviews a major model update before it reaches users.
- Map known limitations to human oversight, access controls, and incident response.
- Avoid assuming that a vendor’s GPAI compliance makes every downstream use compliant.
AI agents make this inventory more important because a model can be connected to files, accounts, and software actions. The security boundaries discussed in our AI agents guide remain application-level design decisions.
What the Rules Do Not Prove
Compliance does not prove that a model is accurate, unbiased, secure in every deployment, or suitable for a particular decision. It creates duties for information, process, evaluation, and risk management. The quality of implementation and enforcement will determine how useful those duties become.
The rules also continue to develop through guidelines, templates, standards, and enforcement practice. Companies should rely on the final legal text and current Commission material, and seek qualified legal advice for decisions about their own role. This article is a technical overview, not legal advice.
What to Watch Next
The key date is August 2, 2026, when the Commission says its enforcement powers for GPAI obligations become applicable. Watch for early supervisory practice, clearer evidence expectations for systemic-risk evaluations, adoption of the Code of Practice, and the way providers communicate model changes to integrators.
The larger test is whether compliance information becomes usable engineering material. If documentation, evaluation results, and incident notices can be tied to a specific model release, downstream teams can make better decisions. If they become static paperwork, the most important risks will still be discovered only after deployment.
Leave a Reply