GPAI Model Obligations for API Users: What Applies to Your Enterprise

What the GPAI model obligations cover

The Act treats a GPAI model as a component, separate from an AI system. Models do not constitute AI systems on their own. They need additional components, such as a user interface, to become one. The model-level obligations sit with the entity that places the model on the market, and the Act names APIs as one of the ways that happens, alongside libraries, direct download and physical copy.

Article 53 requires GPAI model providers to draw up and keep up to date the model's technical documentation, including its training and testing process and evaluation results. That documentation must contain at least the Annex XI information and be provided on request to the AI Office and national competent authorities. The Commission also describes provider duties to disclose certain information to downstream system providers and to maintain policies ensuring compliance with EU copyright law and related rights.

Providers of models with systemic risk carry additional duties to identify and mitigate those risks and to ensure adequate cybersecurity protection. Providers of the most advanced models are legally obliged to notify the AI Office. These duties apply to providers whether they are established in the Union or in a third country. The Commission states that provider obligations have applied since 2 August 2025 and that it will enforce them, including with fines.

The Act does not describe an enterprise that merely calls a vendor's API as the party that holds these duties. That reading follows from the model and system distinction, the provider-focused wording of Articles 53 and 55, and the Commission's significant-modification test described below.

Three roles, three sets of responsibility

Role determination is made per use case, not per company. One enterprise can be a deployer for one workflow and an AI system provider for another. The table summarises how responsibility is allocated.

• GPAI model provider: Places the model on the market, including through an API. Holds technical documentation, information for downstream providers, copyright policy and, where relevant, systemic-risk duties.
• Downstream AI system provider: Builds an AI system on a GPAI model and offers it. Must have access to the necessary information from the model provider and ensure the system complies with the Act.
• Deployer: Uses an AI system, for example a bank using a CV-screening tool. For high-risk systems, must take appropriate technical and organisational measures to use the system according to its instructions, with monitoring and record-keeping as appropriate.
• Enterprise calling an API only: Does not hold the model-level duties on this structure. Holds the system-level duties that match how it builds and uses the system.
• Enterprise that significantly modifies a model: Can be treated as a GPAI model provider for the modified model. Minor changes do not trigger this.

Conditions that change your role

The Commission's guidelines clarify that only those making significant modifications to a model need to comply with the obligations for GPAI model providers. Those making minor changes do not. Recitals note that GPAI models may be further modified or fine-tuned into new models, so fine-tuning is the case to watch most closely.

Two other conditions change which obligations apply without making you a model provider. The first is offering an AI system built on the model. The Commission describes the provider of an AI system that integrates a GPAI model as responsible for ensuring the system complies, and it expects that provider to have access to the necessary information. The second is a high-risk use case. The Commission states that high-risk AI systems will be subject to strict obligations before being placed on the market starting 2 December 2027, as of November 2026.

Treat each of these as an internal trigger for re-assessment: any fine-tuning or other model modification, any change in how the system is branded or offered, and any new use case that may be high-risk. Record the reasoning, for example why a change was judged minor rather than significant, and date it so it can be revisited when guidance changes.

What stays with the enterprise, and what to ask the vendor

Because the model-level duties sit with the vendor, the enterprise's own responsibilities attach to the system it builds around the model: the interface, orchestration and integrations. The Act's deployer provisions require appropriate technical and organisational measures for use in line with instructions, monitoring of the system's functioning and record-keeping, as appropriate. Map oversight and transparency duties per use case, and keep a clear line between your obligations and the vendor's.

Vendor due diligence supports this split. Ask whether the vendor considers itself the GPAI model provider for the model you call, and what downstream information it will make available to you as a system provider. Ask what it states about its copyright policy and technical documentation, whether it has signed the voluntary GPAI Code of Practice, and whether its model is classified as presenting systemic risk. File the answers.

Treat those answers as vendor-supplied information. A reference to the Code of Practice, which is a voluntary tool for providers covering transparency, copyright, and safety and security, is not legal assurance of your own compliance. The Annex XI documentation goes to authorities, so you will not normally hold it. What you can hold is the information the vendor provides to downstream system providers.

Where runtime enforcement fits

Documents and policies show intent. A regulator or auditor will also ask what your system was permitted to do and what it did on a given interaction. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, so each interaction or tool call is allowed, redacted, blocked, rate limited or escalated for human approval at runtime, not reviewed after the fact.

That enforcement produces continuous, audit-ready evidence mapped to the EU AI Act among other frameworks. It is scoped to individual interactions and tool calls. It supports your own deployer and system-level evidence. It does not replace the vendor's model-level documentation, and it does not determine your role under the Act. Trussed deploys self-managed in the customer cloud, with configurable retention and data residency.