You Use a Foundation Model. Now What? GPAI Obligations for Engineering Teams

Since August 2025, the EU AI Act has imposed direct obligations on providers of general-purpose AI models ("foundation models") such as GPT-5.2, Claude Opus, Gemini, Llama, and Mistral.

Among those obligations is that providers must supply organisations that build on top of those models with technical documentation covering training methodology, evaluation results, known limitations, and a summary of training data.

If your organisation integrates a foundation model into a product that serves EU users, those obligations directly affect you, because you need to incorporate this documentation into your own compliance artefacts, assess whether it is sufficient for your specific use case, and fill the gaps where it falls short.

This article examines the General-Purpose AI (GPAI) chapter of the Act (Articles 51 through 56). It explains what model providers must do, what you must do, and where the practical gaps are.

For a comprehensive, structured treatment of all obligations and how they translate into engineering artefacts, see our full guide: Compliance-as-Architecture: An Engineering Leader's Guide to the EU AI Act.

What counts as a general-purpose AI model

Before anything else, it helps to clarify the vocabulary the Act uses.

A general-purpose AI model (GPAI model) is a model that can perform a wide range of tasks and be integrated into many different systems.

In plain terms, this would again cover the popular OpenAI, Anthropic, and other "off the shelf" foundation models. These are all GPAI models under the Act.

The definition covers both proprietary models accessed via API and open-weight models you host yourself.

The Act also draws a clear line between the model and the system built on top of it:

• The model is the trained artefact: the weights, the architecture, the training process.
• The system is everything you build around it: the prompts, the orchestration logic, the retrieval pipelines, the tool integrations, and the user interface.

For example, OpenAI provides the model. You build the system.

This distinction matters because the Act assigns different obligations to each side.

Model providers have obligations as model providers. You, as the organisation building a system on top of that model, have obligations as a system provider.

The two sets of obligations are separate and complementary. You cannot point to OpenAI's system card and claim that covers your Article 11 documentation. Both layers must exist independently.

What model providers must do (this is probably not you)

The Act establishes two tiers of obligations for GPAI model providers (again, the companies that train and release foundation models, such as OpenAI, Anthropic, etc).

If your organisation consumes these models rather than building them, these obligations do not apply to you directly.

• The first tier (Article 53) requires every model provider to maintain technical documentation, supply it to organisations that use their models, publish a training data summary, and comply with copyright law.
• The second tier (Article 55) adds adversarial testing, incident reporting, and cybersecurity requirements for the largest models; at the time of writing, only a handful qualify.

One important caveat on fine-tuning: If your organisation fine-tunes a foundation model (for example, fine-tuning GPT-5.2 on your own domain-specific data through OpenAI's fine-tuning API), the Act treats the result as a new model and classifies your organisation as its provider.

At that point, the Article 53 obligations do apply to you, for the fine-tuned model.

Conversely, calling an API, using retrieval-augmented generation (RAG), or writing system prompts does not trigger this. Fine-tuning does.

The pillar post in this series covers this reclassification risk in more detail in Where do you fit?.

You are not the regulatory target of these articles. But these obligations exist to produce documentation that flows downstream to you, and the quality of what you receive depends on how seriously providers take them. When their disclosures fall short, knowing what the Act requires of them gives you a basis for pushing back.

What you must do as a system provider (this is you)

This is the section that applies to most readers of this article. If your organisation builds a product or service on top of a foundation model and that product serves EU users, you are a system provider. The Act places specific obligations on you, and they exist independently of whatever your upstream model provider does or does not supply.

If your system is high-risk

If your system falls within Annex III of the Act (which covers areas like employment, credit scoring, law enforcement, and critical infrastructure), you must produce technical documentation under Article 11 that covers the entire system, including the foundation model you have integrated.

Concretely, this means your documentation must describe:

• How the foundation model is used within your system
• How the model's known limitations interact with your system's intended purpose
• What supplementary evaluation you conducted on the model for your specific use case
• What mitigations you implemented to address identified risks

Referencing your upstream provider's documentation is necessary but not sufficient.

You must demonstrate that you evaluated the model in the context of your specific deployment.

A system card from OpenAI does not satisfy your Article 11 obligation. It is an input to your documentation, not a replacement for it.

This creates a practical dependency that is important to understand: if your provider's documentation is vague, incomplete, or inaccessible, you have a gap in your compliance chain. That gap is your responsibility to fill, not the model provider's. The Act places the burden of system-level compliance squarely on you.

If your system is not high-risk

Even if your system does not fall within Annex III, you still have transparency obligations under Article 50. If your system generates synthetic content (text, audio, image, or video), you must ensure that outputs are marked as artificially generated, in a machine-readable format where technically feasible. This applies regardless of risk classification.

The short version

• Your model provider documents the model.
• You document the system.

Both must exist. Your provider's documentation is an input to yours, not a substitute for it. If their documentation has gaps, those gaps become your problem.

Assessing what you have received from providers

Now that you know what you must produce, the practical question is: does what your model provider has given you actually help you get there?

The Act requires model providers to supply documentation that is detailed enough for you to understand the model's capabilities and limitations and to meet your own compliance obligations. In practice, this means you should have received (or be able to access) the following from each model provider you depend on:

• Technical documentation describing the model's architecture, training methodology, evaluation results, known limitations, and intended use. This needs to be detailed enough to inform your own risk assessment. A marketing data sheet or a blog post announcing the model does not satisfy the requirement.

• Capability and limitation disclosures with quantitative performance evidence, known failure modes, and conditions under which performance degrades. If you are building a high-risk system, you need this information to satisfy your Article 13 transparency obligations.

• An acceptable use policy setting out conditions under which the provider permits or prohibits use of the model, including any restrictions on high-risk applications.

• A training data summary published according to a template from the AI Office. This is a public document intended to help you assess potential biases, coverage gaps, and representativeness issues in the training data.

The reality today

Most GPAI model providers are large US-based companies. Their documentation is improving, but it is not yet optimised for the specific requirements of the EU AI Act. System cards tend to describe what a model does well rather than where it fails. Evaluation results are often presented in aggregate, without the demographic or domain-specific breakdowns you need for bias evaluation. Training data summaries vary considerably in depth, which means you cannot rely on them uniformly.

The gap between what providers currently supply and what you need for your own compliance documentation is real. The next section explains what to do about it.

Practical actions for engineering leaders

If your organisation integrates foundation models into products that serve EU users, here is what you should do:

1. Catalogue every foundation model your system depends on. This includes the obvious ones (your primary LLM) and the less obvious ones: embedding models, reranking models, classification models, and any models consumed indirectly through third-party services. For each model, record the provider, the model version, how you access it (API, hosted weights, downloaded weights), and what documentation you have received.
2. Determine your regulatory role. Are you a deployer (consuming a model via API without modification)? A system provider (integrating a model into a product, especially a high-risk one)? Or a GPAI model provider (because you have fine-tuned a foundation model)? The obligations are different for each role, and a single organisation can hold more than one role at the same time.
3. Assess your provider documentation against what you actually need. For each model, check whether the documentation you have received covers: capabilities, limitations, evaluation results (ideally broken down by relevant dimensions, not just aggregate scores), training data summary, and acceptable use conditions. Where there are gaps, write them down. You will need to address them.
4. Run your own evaluations where provider documentation falls short. If a model provider has not given you disaggregated evaluation results for your domain, run your own evaluations tailored to your specific use case, input distribution, and risk criteria. Document the results. For high-risk systems, this is not optional; Article 11 requires system-level evaluation.
5. Document the full chain from model to output. Your technical documentation should trace the path from the upstream model to your system's outputs. Describe the model dependencies, the documentation you received from each provider, the supplementary evaluations you performed, and your assessment of model suitability. Where gaps exist in provider documentation, document the gap and explain how you mitigated it.
6. Monitor the Codes of Practice. The AI Office coordinates Codes of Practice that specify how GPAI model providers should comply with their obligations. The first General-Purpose AI Code of Practice was published in draft form in late 2025, with revisions ongoing. Providers that adhere to the applicable Code benefit from a presumption of conformity. This matters to you because the baseline of documentation you can reasonably expect from providers will evolve as the codes mature. Track AI Office publications and update your assessments accordingly.

A note on enforcement

GPAI model obligations are enforced centrally by the AI Office within the European Commission, regardless of whether the model provider is established in the EU, the UK, or the United States, provided the model is placed on the EU market or made available to EU users.

By contrast, your obligations as a system provider are enforced by the market surveillance authority of the Member State in which you place the system on the market, or where your authorised representative is established. These are distinct regulatory relationships, even if they arise from the same value chain.

This matters for one reason: if the AI Office finds that a model provider has failed to meet its documentation obligations, that finding could affect the compliance position of every organisation that relied on that documentation. Your compliance chain has a supply-chain dimension. If your upstream provider is found non-compliant, you need to know how that affects your own documentation and what steps you took to mitigate the dependency. This is another reason to document the gaps rather than assuming provider documentation is sufficient.

Conclusion

The GPAI chapter does not replace the high-risk system obligations covered elsewhere in this series. It adds a regulatory layer. Where a high-risk system integrates a GPAI model, both sets of obligations apply. The resulting engineering effort is substantial but structurally bounded. The chain of responsibility is traceable. The question is whether your organisation has traced it.

Systima works with engineering teams to map the full compliance chain from upstream GPAI model to downstream system deployment. If your organisation is building on foundation models and needs to understand precisely where provider obligations end and system-level obligations begin, talk to us.