General-purpose AI model obligations under the EU AI Act are not a future concern: Articles 51 through 56 entered into application on 2 August 2025, placing immediate requirements on providers of GPAI models and creating a compliance boundary that every regulated European organisation running an open-weight model such as Mistral or Llama must now locate precisely. For government bodies, financial institutions, healthcare operators and legal organisations that choose sovereign, on-premises AI deployment to keep sensitive data out of US jurisdiction, understanding where provider obligations begin and deployer protections end is the first governance task.
What the GPAI Provisions of the AI Act Actually Require
Articles 51-56 of Regulation (EU) 2024/1689 create two tiers of obligation for GPAI providers. All providers must maintain technical documentation, comply with EU copyright law and publish a sufficiently detailed summary of training data used. Providers of GPAI models assessed as carrying systemic risk (generally those trained above a threshold of 10^25 FLOPs) face additional adversarial testing, incident reporting and cybersecurity obligations. For sovereign deployers running quantised versions of Mistral 7B or Llama 3 on local GPU infrastructure, the critical question is not which tier applies but whether their organisation qualifies as a provider at all.
The AI Act defines a provider as an entity that develops a GPAI model and places it on the market or puts it into service. Downloading an open-weight model and running it internally does not, by itself, place it on the market. The Commission’s July 2025 Guidelines on GPAI Scope confirm this: an organisation that deploys a GPAI model exclusively for internal purposes and does not place it on the market or put it into service for third parties does not, as such, become a provider under the AI Act. This single clarification is the legal foundation of the sovereign AI deployment strategy.
When Fine-Tuning or RAG Integration Triggers Provider Status
The July 2025 Commission Guidelines introduce the concept of “significant modification” to determine when an organisation transforms from deployer to provider. A significant modification is one that materially alters the general-purpose capability of the model, effectively creating a new GPAI model that could be used across a wide range of tasks beyond the original scope.
The Guidelines provide practical demarcation. Retrieval-augmented generation (RAG), in which the model queries an internal document store without retraining, does not alter the model’s weights or general-purpose capability and does not constitute a significant modification. Instruction fine-tuning on a narrow, domain-specific corpus (for example, internal legal templates or clinical protocols) that restricts rather than extends the model’s capabilities generally falls below the threshold. Architectural changes, full retraining on a substantially different and larger corpus, or modifications that introduce new general-purpose downstream potential cross into provider territory.
Documenting the Threshold in Practice
A CISO or DPO managing a sovereign AI deployment should maintain a modification record for every change applied to a base model. This record should state the type of modification (quantisation, instruction tuning, adapter-based fine-tuning, RAG pipeline integration), the dataset used (size, domain scope, whether it extends or constrains capability), and a written conclusion referencing the July 2025 Guidelines criteria. This document becomes the primary evidence artefact if the AI Office or a national supervisory authority asks why the organisation has not registered as a GPAI provider.
| Modification type | Significant modification under July 2025 Guidelines? | Provider obligations triggered? |
|---|---|---|
| Quantisation (e.g. GGUF 4-bit) for local inference | No | No |
| RAG integration with internal document corpus | No | No |
| Instruction fine-tuning on narrow domain data | Generally no, if capability is restricted | No, document the restriction |
| Full retraining on a large, multi-domain corpus | Yes | Yes (Articles 51-56) |
| Redistribution as a service to separate legal entities | Yes (placing on market) | Yes |
The GPAI Code of Practice: Controls for On-Premises Operators
The GPAI Code of Practice, the voluntary compliance instrument submitted to the European Commission and developed under the auspices of the AI Office, translates the obligations of Articles 51-56 into concrete measures. More than 1,000 organisations participated in its drafting process during the first round convened in late 2024 (European AI Office, 2024).
Even for organisations that conclude they are deployers rather than providers, the Code of Practice is worth implementing. National supervisory authorities and procurement bodies in regulated sectors are already referencing it as a benchmark for responsible AI use. The Code identifies four control domains particularly relevant to on-premises operators: model transparency documentation (model cards describing capabilities, limitations and training data provenance), copyright compliance records (evidence that training data used in any fine-tuning respects EU copyright law and the Text and Data Mining exception under Directive 2019/790), safety evaluation logs (adversarial testing records and red-team outputs), and incident tracking (a process to detect and document model-generated harmful or misleading outputs).
The AI Office has stated publicly: “The Code of Practice is not a box-ticking exercise. It is the instrument through which we expect providers to demonstrate that safety and transparency are built into the model, not bolted on afterwards.” For a sovereign deployer that is not technically a provider, implementing these controls is still the operationally defensible posture.
Training Data Transparency in a Closed, Air-Gapped Deployment
Article 53 of the AI Act requires GPAI providers to prepare and maintain a sufficiently detailed summary of training data, made available to the public. This obligation sits with the original model developer, not with an organisation that merely runs the model. When Mistral AI or Meta publish their training data summaries, they satisfy Article 53 for the base weights. A sovereign deployer running those weights internally does not inherit that obligation unless it has carried out a significant modification.
This is one of the concrete advantages of closed, air-gapped on-premises deployment over using a public API. When an organisation sends queries to a public cloud AI API, it is using a service governed by the provider’s terms, subject to the provider’s jurisdiction (including potential US CLOUD Act reach) and dependent on the provider’s compliance status. Running the same model locally means the organisation controls the data entirely, no query or response crosses a network boundary subject to foreign jurisdiction, and the Article 53 transparency obligation rests with the model developer, not the operator. For healthcare records, legal case files or financial supervisory data, this boundary is not academic: it is the difference between a data breach risk and a contained internal process.
Governing the GPAI/High-Risk Boundary Under the AI Omnibus Timeline
The AI Omnibus, for which political agreement was reached on 7 May 2026, modifies several transition periods in the AI Act. For high-risk AI systems that embed a GPAI model (for example, a clinical decision-support tool or an automated credit-scoring engine that uses Llama as its reasoning layer), the full conformity assessment obligations may not apply until 2028 under the extended timeline for embedded systems.
A CISO or DPO managing such a system during the transition window needs to document the functional boundary between the GPAI component and the high-risk application layer. The recommended approach is a two-layer model governance record: first, the GPAI modification record described above, establishing that the base model is used without significant modification; second, a high-risk system classification record that identifies the application layer as high-risk under Annex III of the AI Act, names the intended purpose, lists the affected persons and records the preliminary conformity assessment steps taken. This two-layer record is the evidence baseline the AI Office will expect when full enforcement powers take effect.
The average total cost of a data breach globally reached USD 4.88 million in 2024, the highest in IBM’s tracking history (IBM Cost of a Data Breach Report, 2024). Deploying AI on internal infrastructure without a clear governance record creates liability exposure that dwarfs the implementation cost of proper documentation.
The EU SEND Platform and Internal Redistribution
The EU SEND platform is the Commission’s designated channel through which GPAI providers submit notifications and model documentation to the AI Office. For an organisation that downloads Mistral weights and runs them on a private server for a single legal entity’s internal users, SEND registration is not required. The model is not being placed on the market.
The liability picture changes if a regulated organisation’s IT department modifies a GPAI model and then makes it available to subsidiary entities, partner organisations or separate legal entities, even within a regulated group. That distribution may constitute placing a modified model into service. In that scenario, the modifying entity should analyse whether a significant modification has occurred, and if so, treat itself as a provider, which means registering model information via SEND, maintaining the full Article 53 documentation set, and establishing a model-weight custody chain: a logged record of which version of weights was deployed to which entity, when, and under what access controls.
The custody chain also matters for incident response. If a model produces a harmful output in a subsidiary’s deployment, the AI Office will ask which entity controlled the weights, which entity carried out any modification and which entity bears provider responsibility. A clean custody chain, maintained in an internal model registry, answers those questions before they become enforcement questions. The average share of breaches initiated via stolen credentials was 16% in 2024 (IBM Cost of a Data Breach Report, 2024), underscoring that access controls around model weights must be treated with the same rigour as access controls around sensitive data stores.
FAQ
Does downloading and running Mistral or Llama on internal servers automatically make my organisation a GPAI provider under the EU AI Act?
Not automatically. The Commission’s July 2025 GPAI Guidelines clarify that purely internal deployment without placing the model on the market or putting it into service for third parties does not trigger provider status. The key question is whether your organisation has carried out a significant modification that effectively creates a new GPAI model capability, or whether it is acting as a downstream deployer of the original developer’s model.
What counts as a significant modification under the July 2025 Commission Guidelines?
The Guidelines focus on modifications that materially alter the model’s general-purpose capability: full retraining on a substantially different corpus, or architectural changes that create new downstream use-case potential. RAG alone, standard instruction-tuning on a narrow domain corpus and quantisation for local inference are generally not treated as significant modifications, provided the base model’s general-purpose nature is not extended.
My organisation uses a closed, air-gapped deployment with no public API. Do training-data transparency obligations still apply?
If your organisation is not a provider (no significant modification, no redistribution), the Article 53 transparency and public training-data summary obligations apply to the original model developer, not to you. Running a closed on-premises instance avoids the data-disclosure exposure that public API providers face, but you should document this clean boundary in your AI governance records to demonstrate the position to supervisory authorities.
What is the EU SEND platform and when does it affect internal redistributors of GPAI models?
SEND is the Commission’s designated notification and documentation submission channel for GPAI providers. If an internal redistribution or significant modification inside a regulated organisation creates a new GPAI model made available to other legal entities or separate business units, the modifying organisation may need to register via SEND and maintain full Article 53 documentation. Organisations that keep deployment strictly within a single legal entity and do not redistribute externally can generally document their position without a SEND submission, but the reasoning should be recorded explicitly.
How does the AI Omnibus affect the transition timeline for high-risk AI systems that embed a GPAI model?
The AI Omnibus, with political agreement reached in May 2026, extends the transition period for certain embedded high-risk AI systems, with some categories potentially not reaching full applicability until 2028. During this window, the AI Office expects regulated organisations to implement interim governance controls: documented model cards, a risk classification record distinguishing GPAI from high-risk functionality, and a preliminary conformity assessment trail. These interim controls become the baseline evidence set when full enforcement begins.