On August 2, 2025, a less visible part of the AI Act began to apply: the obligations relating to general-purpose AI models, or GPAI. This development may seem remote from companies purchasing an assistant, an API, or a business application. The obligations primarily target the providers of these models. Yet they change the position of integrators and users: they now have a clearer basis for asking what a model can do, what it cannot do, and under what conditions it may be used.
The European Commission announced on August 1, 2025 that these rules would begin to apply. For new models placed on the market from August 2 onward, providers must, in particular, prepare technical documentation, make information available to parties integrating the model, adopt a policy to comply with copyright law, and publish a summary of the content used for training. Models already on the market before that date have until August 2, 2027 to comply.
This distinction is important. A French company that uses a model through a provider is not, by default, the provider of the general-purpose model. It cannot transfer its own deployment obligations to the vendor or ask it to resolve every risk associated with its application. But it can stop selecting a model as though it were merely an interchangeable commodity.
Documentation becomes part of the architecture
The regulation targets models capable of performing a wide range of tasks and being integrated into many systems. Their general-purpose nature explains the difficulty: the same model can be used to write, classify, search, or produce code, depending on the application layer built around it. The Commission's fact page on obligations for GPAI models therefore distinguishes the general documentation, copyright, and transparency requirements from the additional requirements for models presenting systemic risk.
For teams developing an application, this documentation is not a legal add-on. It helps them design a realistic use case. What capabilities and limitations does the provider identify? Which parameters influence the model's behavior? What conditions are specified for integration and use? Without actionable answers, it becomes difficult to define tests, inform users, or handle an incident.
Article 53 of the AI Act provides that the information intended for downstream system providers must enable them to understand the model's capabilities and limitations so that they can comply with their own obligations. The text is available through the official AI Act Service Desk. This is a practical development: a company building an assistant should no longer accept having only a sales presentation and API documentation at its disposal.
Specifications can now make concrete requests for the information required by the use case: documented scope, update procedures, conditions for accessing logs, retention policy, incident procedure, and exit strategy. Scoping an AI project before deployment makes it possible to tie these requests to a business process rather than checking them off in the abstract.
Companies using these models must organize their own accountability
The regulatory change does not turn an API into a reliable system. The company integrating it still decides which documents it consults, which users can access it, and how an employee can challenge its response. An assistant that produces a contract summary must be evaluated in that specific context, not on the basis of general performance claimed by its vendor.
The model documentation must therefore become part of the other evidence: tests using representative data, human validation rules, version traceability, and feedback handling. A team does not need to wait for the regulation's final deadline to introduce these practices. It is in its interest to put them in place before the tool becomes difficult to replace or its responses influence a sensitive decision.
The status of data remains central. The copyright policy and summary of training content required from providers concern their production chain. They do not answer the more immediate question for the user of what happens to a contract, an HR record, or a strategy memo submitted to an application. This is why the choice of sovereign hosting and governance must be discussed with reference to actual data flows, access rights, and the provider's commitments.
Nor is the AI Act limited to closed models. The exceptions provided for certain open-source models do not eliminate the need for analysis: an organization that adapts or distributes a component must identify its role and the corresponding obligations. In every case, “open” means neither adequately documented nor ready for deployment in a regulated business.
An opportunity to put contracts and testing on an equal footing
Perhaps the most useful consequence of the August 2025 milestone is that it makes an elementary requirement harder to evade: requesting verifiable evidence before integration. A business unit can define unacceptable errors. IT can establish logging and permissions. Procurement can secure commitments on documentation, support, and reversibility. None of these roles is sufficient on its own.
This organization avoids two extremes. The first is waiting for perfect compliance before running any pilot, thereby losing the opportunity to learn within a closed scope. The second is deploying a tool because it is easy to try, only to discover afterward that no one can explain its data, access rights, or updates. Support from design through deployment can assign an owner to each of these decisions.
In November 2025, the new development is therefore not that every company must suddenly produce its own general-purpose model documentation. It is that the European ecosystem is beginning to demand greater transparency from those who provide these models. Organizations that take advantage of this will not seek a regulatory seal of approval. They will turn this information into selection criteria, tests, and contractual clauses. This is the only way to make a general-purpose model a controlled component of a business system.