GPAI Code of Practice sovereign on-premises evaluation guide

The GPAI Code of Practice sovereign on-premises evaluation framework defines how organisations that self-host open-weight general-purpose AI models must satisfy EU AI Act transparency, safety-testing, and incident-reporting obligations, without delegating that compliance work to the cloud providers those obligations were partly designed to scrutinise. For compliance officers, CISOs, and data protection officers in regulated sectors, the practical implication is clear: moving AI inference onto sovereign infrastructure solves a data-jurisdiction problem, but it does not reassign regulatory duties.

Why on-premises GPAI deployment does not eliminate AI Act obligations

The EU AI Act assigns GPAI obligations to the provider role, defined as any natural or legal person that places a GPAI model into service, including internal deployment. The on-premises architecture removes data from US-controlled hyperscalers, but it does not transfer the obligation to maintain technical documentation, conduct capability evaluations, or report serious incidents.

The GPAI Code of Practice, published by the EU AI Office in 2025, makes this explicit for open-weight models. Although open-weight models receive certain downstream-use carve-outs under the Code, an organisation that deploys such a model in a regulated-sector context, especially at scale or for high-risk use cases, cannot treat the open-weight designation as a compliance exemption. The decisive question is not where the weights are hosted, but whether the deploying organisation has taken on provider-equivalent responsibilities by customising, fine-tuning, or distributing the model within its own enterprise.

Transparency and technical documentation requirements

Articles 53 and 55 of the EU AI Act require providers of GPAI models to draw up and maintain technical documentation covering training methodology, evaluation results, and known limitations before the model is placed into service.

For an on-premises deployer of a model such as Mistral or a model produced under the OpenEuroLLM programme, this means the organisation must produce its own technical documentation layer on top of whatever the upstream model developer has published. The upstream provider’s documentation covers the base model; the deployer’s documentation must cover any fine-tuning decisions, the specific deployment context, the downstream use cases, and the results of internal capability evaluations. The EU AI Office Model Evaluation Framework provides the structured methodology for this layer.

Critically, technical documentation is a living artefact. Each fine-tuning run, prompt-engineering iteration, or retrieval-augmented generation configuration that materially changes model behaviour triggers a documentation update obligation. Organisations should version-control their documentation alongside their model checkpoints so that auditors can reconstruct the state of the system at any point in time.

Designing a systematic capability evaluation programme

A compliant capability evaluation programme under Articles 55 and 56, and as elaborated in the GPAI Code of Practice, has four structural components: scope definition, benchmark selection, adversarial testing, and documented findings.

Scope definition

The organisation must first determine whether its deployed model meets or approaches the systemic-risk threshold of 10^25 training FLOPs defined in the Act. For derivatives of large open-weight models such as Llama or OpenEuroLLM releases, the upstream training compute is often publicly disclosed. If the base model exceeds the threshold, the deployer should treat its derivative as potentially systemic-risk-adjacent and apply the full evaluation protocol unless the EU AI Office Model Evaluation Framework provides a contrary guidance.

Benchmark selection and execution

Benchmarks must be chosen to reflect the actual deployment context, not generic leaderboard performance. A legal-sector deployment demands evaluation on tasks such as contract analysis, jurisdiction-specific legal reasoning, and handling of privileged information. A healthcare deployment requires evaluation on clinical decision support, medication dosing language, and behaviour under ambiguous or contradictory clinical information. Generic benchmarks such as MMLU or HellaSwag can serve as baselines but cannot substitute for domain-specific evaluation.

Adversarial robustness and red-teaming

The GPAI Code of Practice, citing the EU AI Office’s own drafting language, requires that models posing systemic risk be subject to adversarial testing by qualified evaluators. For an on-premises deployment, this means commissioning red-team exercises that probe the model for: prompt injection vulnerabilities, data extraction via inference, harmful output generation, and evasion of content-safety guardrails configured at the application layer.

Red-teaming findings must be recorded in the technical documentation with sufficient granularity to demonstrate to a supervisory authority that the organisation understood the risk, assessed its severity, and took proportionate mitigation steps. Vague entries such as “model tested for adversarial inputs, no critical issues found” do not satisfy this requirement. The documentation should record the attack methodology, the inputs used, the model outputs, the severity classification, and the control implemented in response.

Interaction with GDPR Article 35 DPIA obligations

When a sovereign on-premises GPAI model processes special-category personal data under GDPR Article 9, a Data Protection Impact Assessment under GDPR Article 35 is mandatory. The DPIA and the AI Act capability evaluation are legally distinct instruments, but they overlap substantially in regulated-sector deployments.

In practice, the DPO and the CISO must coordinate so that red-teaming findings that reveal risks to data subjects, for example, the model reproducing training data containing patient records, feed directly into the DPIA’s residual risk section. The two documents should cross-reference each other so that a supervisory authority inspecting either one can trace the full risk picture.

Model-weight integrity and provenance controls

Organisations downloading and fine-tuning models from the OpenEuroLLM programme or other EU-aligned open-weight repositories must maintain a cryptographically verifiable chain of custody. The GPAI Code of Practice does not prescribe a specific hash algorithm, but current best practice calls for SHA-256 or BLAKE3 checksums recorded at each stage: initial download, pre-processing, fine-tuning checkpoint, and production deployment.

Weights should be stored in an access-controlled, immutable registry, ideally air-gapped from internet-facing infrastructure. Each version of the weights should be signed with an organisational PKI key, and the signing event should generate an entry in a tamper-evident audit log. This posture serves two compliance purposes: it satisfies the technical documentation traceability requirement of the GPAI Code of Practice, and it provides evidence of integrity in the event of a security incident or a supervisory authority inspection.

When fine-tuning introduces new training data, that data’s provenance and copyright status must also be documented. The EU AI Act’s copyright transparency obligation under Article 53(1)(d) applies to the fine-tuning process, not only to the base model’s original training.

Structuring sovereign incident reporting under Article 73

Article 73 of the EU AI Act requires providers to notify the EU AI Office of serious incidents, defined as incidents that result in death, serious harm to health, significant property damage, or a serious and irreversible disruption of infrastructure, without undue delay and in any case within defined timeframes.

The critical constraint for sovereign infrastructure operators is that the incident reporting pipeline must itself be sovereign. Routing telemetry or incident alerts through a US-controlled SaaS monitoring platform creates two risks: the CLOUD Act exposure that the entire sovereign architecture was designed to avoid, and the possibility that the monitoring platform is itself affected by the incident being reported.

A compliant sovereign incident reporting architecture should include: a self-hosted security information and event management (SIEM) system running on EU-jurisdiction infrastructure, a documented escalation workflow that maps AI-specific anomalies (unexpected model outputs, inference anomalies, weight tampering alerts) to the Article 73 seriousness criteria, a secure and authenticated channel for submitting notifications to the EU AI Office (which does not require a commercial SaaS tool), and tabletop exercises at least annually to verify that the workflow functions under adverse conditions.

As ENISA’s Threat Landscape 2023 found, ransomware remained the dominant threat to critical sectors, meaning the scenario where an organisation’s monitoring infrastructure is compromised in the same incident it needs to report is not hypothetical. The incident reporting channel must be architecturally separated from the systems it monitors.

IBM’s Cost of a Data Breach Report 2024 recorded an average breach cost of USD 4.88 million, the highest figure in the study’s history. Organisations that cannot demonstrate a functioning Article 73 reporting channel face not only regulatory sanctions under the AI Act but also the reputational and financial consequences of delayed or incomplete incident disclosure.

FAQ

Does running an open-weight GPAI model entirely on-premises exempt an organisation from EU AI Act GPAI obligations?

No. The EU AI Act and the GPAI Code of Practice attach obligations to the provider role, which includes any organisation that places a GPAI model into service, even internally. On-premises deployment changes the data-flow architecture but does not reassign the regulatory duty to maintain technical documentation, conduct capability evaluations, and report serious incidents.

At what compute threshold does a GPAI model qualify as posing systemic risk under Articles 55 and 56?

The EU AI Act sets an indicative threshold of 10^25 floating-point operations used in training. Models trained at or above this level are presumed to pose systemic risk. Fine-tuned derivatives of such models may inherit this classification depending on the scope of fine-tuning, and organisations should consult the EU AI Office Model Evaluation Framework when assessing inherited risk.

How should a DPIA under GDPR Article 35 and an AI Act capability evaluation be coordinated for the same on-premises GPAI deployment?

Both instruments assess risk to individuals but from different angles. The DPIA focuses on data-subject rights and privacy risk; the capability evaluation examines model behaviour and systemic risk. The technical documentation required for the GPAI Code of Practice should be cross-referenced in the DPIA, and red-teaming findings that reveal risks to data subjects must be incorporated into the DPIA’s residual-risk assessment.

What does model-weight provenance control mean in practice for organisations fine-tuning an OpenEuroLLM-derived model?

It means maintaining a cryptographically verifiable chain of custody from the canonical model release through any intermediate checkpoints to the production weights. Practically: download weights over verified HTTPS from the official repository, record SHA-256 or BLAKE3 checksums at each stage, sign fine-tuned checkpoints with an internal PKI, and store these artefacts in an access-controlled registry that generates an immutable audit log.

Can Article 73 serious incident reports be submitted through a sovereign self-hosted platform rather than a cloud-based reporting tool?

Yes. Article 73 requires notification to the EU AI Office without undue delay but does not mandate a specific technical channel. Organisations may build or self-host a sovereign incident management workflow, provided the notification reaches the EU AI Office within the required timeframe and the reporting process is documented, tested, and does not depend on infrastructure that could itself be compromised in the incident being reported.