What are GPAI obligations under the EU AI Act?
GPAI obligations under the EU AI Act are the duties placed on providers of general-purpose AI models — models trained on broad data at scale that can perform a wide range of distinct tasks. Article 53 requires every GPAI provider to maintain technical documentation of the model, supply information and documentation to downstream providers who integrate it, put in place a policy to comply with Union copyright law, and publish a sufficiently detailed summary of the content used for training. Article 55 adds a second tier for models classified as presenting systemic risk: model evaluation including adversarial testing, assessment and mitigation of systemic risks, reporting of serious incidents to the AI Office, and an adequate level of cybersecurity protection.
These duties sit in the Regulation's dedicated chapter on general-purpose AI models. They are distinct from the high-risk system rules, and distinct again from the transparency duties in Article 50. A company can be caught by one, two or none of them depending on what it actually does.
Who counts as a GPAI provider, and who does not?
The obligations in Articles 53 and 55 fall on the provider of the general-purpose AI model — the party that develops the model, or has it developed, and places it on the Union market under its own name or trade mark. In practice that is a small population: the labs building foundation models.
Most European SMEs are on the other side of the line. If your company calls a model API, embeds a hosted model in a product, or deploys a chat assistant internally, you are ordinarily a deployer of an AI system and possibly a provider of the AI system you have built — but not the provider of the underlying model.
The grey zone: fine-tuning and modification
Modifying a general-purpose model can shift responsibility. As a compliance matter, the question is whether the modification is substantial enough that the resulting model is a different model placed on the market by you. Light-touch adaptation — prompt engineering, retrieval augmentation, a thin instruction layer — does not usually make you a model provider. Substantial further training that materially changes the model's general capabilities, and then distributing that model, moves you much closer to the provider role. Where a modification is made, the resulting obligations are generally understood to attach to the modification rather than requiring the fine-tuner to re-document the entire base model.
- Calling a hosted API in your own product: you are a provider of the AI system, not of the model.
- Fine-tuning a model on your own data and using it internally: normally still not a GPAI model provider.
- Substantially further training an open-weights model and distributing it under your own name: assess carefully — the GPAI provider role may apply.
- Distributing a base model unchanged under your own brand: you are likely placing a GPAI model on the market.
Getting this determination recorded — with the reasoning, not just the conclusion — is the part that matters at audit. Step-by-step guidance is in the Veritome Help Center (help.veritome.eu).
What Article 53 requires of every GPAI provider
Technical documentation of the model
Providers draw up and keep up to date technical documentation covering the model's training and testing process and the results of its evaluation. The Regulation sets out the minimum elements in an annex to the GPAI chapter, and requires the documentation to be made available to the AI Office and to national competent authorities on request.
Information for downstream providers
A separate documentation package goes to providers of AI systems that intend to integrate the model. Its purpose is to give downstream providers a good understanding of the model's capabilities and limitations so they can meet their own obligations. This is the mechanism that makes the value chain work: an SME building a high-risk system on a foundation model relies on this package to complete its own technical documentation.
A copyright policy
Providers put in place a policy to comply with Union law on copyright and related rights, including identifying and respecting reservations of rights expressed under the text-and-data-mining exception in the Copyright Directive. In practice this means honouring machine-readable opt-outs during data collection.
The public training-content summary
Providers draw up and make publicly available a sufficiently detailed summary of the content used to train the model, following a template provided by the AI Office. The point is transparency for rightsholders and the public — not disclosure of trade secrets or a dataset-by-dataset inventory.
What is the GPAI training-data summary?
The training-data summary is a public document, published by the GPAI model provider, describing the content used to train the model in sufficient detail. It is a narrative and categorical account — the main data collections and sources, the types of data, and how content was obtained and processed — rather than a full list of files or records.
The Regulation directs the AI Office to provide a template, and providers are expected to use it so summaries are comparable across models. The audience is rightsholders wanting to know whether their material may have been used, and researchers and authorities wanting a view of the model's data provenance.
For an SME integrating someone else's model, the summary is a useful due-diligence artefact. It will not answer every question about licensing exposure, but its presence — or absence — is a signal about the provider's compliance posture, and it belongs in your vendor file.
When does a general-purpose AI model have systemic risk?
A general-purpose AI model is classified as having systemic risk when it has high-impact capabilities — capabilities matching or exceeding those recorded in the most advanced models. The Regulation sets a presumption: a model is presumed to have high-impact capabilities when the cumulative amount of computation used for its training, measured in floating-point operations, is greater than 10^25 FLOPs. The Commission may also designate a model as having systemic risk on the basis of a decision taken on its own initiative or following a qualified alert from the scientific panel, using criteria set out in an annex to the Regulation.
Providers that meet or expect to meet the compute threshold notify the Commission without delay, and in any event within two weeks of the requirement being met or of it becoming known that it will be met. A provider may argue that, despite crossing the threshold, its model does not present systemic risk — but it has to substantiate that, and the Commission can reject the argument.
Article 55: what the systemic-risk tier adds
- Perform model evaluation according to standardised protocols and tools, including conducting and documenting adversarial testing to identify and mitigate systemic risk.
- Assess and mitigate possible systemic risks at Union level, including their sources, that may stem from the development, placing on the market or use of the model.
- Track, document and report serious incidents and possible corrective measures to the AI Office and, as appropriate, to national competent authorities, without undue delay.
- Ensure an adequate level of cybersecurity protection for the model and its physical infrastructure.
Providers may rely on codes of practice to demonstrate compliance until a harmonised standard is published. The compute threshold is not fixed for all time — the Regulation empowers the Commission to amend the thresholds and add benchmarks as technology moves.
What an SME building on a foundation model does and does not inherit
Nothing in Articles 53 or 55 transfers automatically to a downstream company. You do not inherit the duty to publish a training-data summary, to maintain the model's technical documentation, or to run adversarial evaluations of the base model. Those stay with the model provider.
What you do carry are the obligations that attach to what you have built. Three questions decide the shape of your file:
- Does the use case fall within Annex III, or is the system a safety component of a product covered by Union harmonisation legislation? If so, the high-risk regime applies to you as provider of that system — risk management, data governance, logging, human oversight, technical documentation and conformity assessment.
- Does the system interact directly with people, generate synthetic content, or produce deepfakes or emotion-recognition output? Article 50 transparency duties then apply, largely independently of risk classification.
- Are you within scope of the AI literacy duty? Article 4 requires providers and deployers to take measures to ensure a sufficient level of AI literacy among staff dealing with the systems, and it has applied since 2 February 2025.
The practical consequence is contractual. If you are building a high-risk system on a third-party model, your own technical documentation will depend on information only the model provider holds. Secure it in writing at procurement time, along with the training-content summary, capability and limitation documentation, acceptable-use terms, and a commitment to notify you of material model changes. Retrofitting that into a signed contract is considerably harder.
Step-by-step guidance on building a value-chain evidence file is in the Veritome Help Center (help.veritome.eu).