Mapping Your AI Safety Program to the EU AI Act’s GPAI Code of Practice

The GPAI Code of Practice gives providers of general-purpose AI models a voluntary way to demonstrate compliance with the EU AI Act’s Article 53 and Article 55 obligations. What it doesn’t give you is a mapping from the safety program you already run — a risk register, a governance framework, an incident response process — onto its chapters and measures. This guide is that mapping: where your existing artifacts already satisfy a Code commitment, where they need extending, and where the Code asks for something you don’t have yet.

Who this mapping is actually for

The Code binds a narrower group than “any organization using AI.” Its Transparency and Copyright chapters apply to all providers of general-purpose AI models under Article 53. Its Safety and Security chapter — the one with the most structural overlap with an internal safety program — applies only to providers whose models are classified as posing systemic risk under Article 55, currently models with cumulative training compute above 10^25 FLOP. In practice that is a small number of frontier labs, not the research institutions, hospitals, and universities that make up most of an internal AI-governance audience. A downstream organization that fine-tunes or deploys someone else’s GPAI model becomes a provider in its own right only if the modification consumes roughly a third or more of the original training compute — a threshold most fine-tuning and RAG deployments don’t reach.

If you’re not a GPAI provider under either article, the Code still has a use: as an external structure to check an internal safety program against, the way organizations already use NIST AI RMF or ISO/IEC 42001 as reference frameworks rather than binding law. The mapping below works either way — as a compliance exercise if you’re in scope, or as a structural gap-check if you’re using it for benchmarking.

The Code’s three chapters, and what each one actually asks for

The Code of Practice was published 10 July 2025 under Article 56 of the AI Act, and provider obligations under Articles 53 and 55 entered into application on 2 August 2025. The Commission’s enforcement powers begin 2 August 2026; providers of models already on the market before 2 August 2025 have until 2 August 2027 to come into compliance. It’s organized into three separately authored chapters:

• Transparency — standardized, up-to-date model documentation (the Code includes a Model Documentation Form), retained for ten years and made available to the AI Office and, in a narrower form, to downstream deployers. Applies to all GPAI providers.
• Copyright — a copyright policy covering lawful data acquisition, compliance with machine-readable rights reservations, and a complaint-handling mechanism. Applies to all GPAI providers.
• Safety and Security — a Safety and Security Framework (SSF), systemic-risk assessment, external evaluator access, incident reporting, and governance/accountability measures. Applies only to providers of models with systemic risk under Article 55.

Roughly two dozen providers have signed the Code so far, including OpenAI, Google, Microsoft, Anthropic, and Mistral; Meta declined to sign, citing legal uncertainty, and xAI signed only the Safety and Security chapter. Signing is not mandatory — non-signatories can still demonstrate compliance by other means, but face more direct information requests from the AI Office.

Mapping your risk register to the Safety and Security Framework

If you already maintain an AI risk register, most of the raw material the SSF asks for already exists in it — the Code just wants it organized around systemic risk specifically, and assembled before a model reaches the market rather than reviewed periodically. The Code’s systemic-risk analysis process has five parts: compiling model-independent information (what’s already known about risks in the relevant capability class), running GPAI model evaluations against that information, modeling how the systemic risk could materialize, estimating its likelihood and severity, and post-market monitoring that folds end-user and deployer feedback back into the assessment.

A general-purpose risk register usually already captures the modeling and estimation steps in some form — that’s what a register’s likelihood/severity fields are for. What it more often lacks is the evaluation step done through external evaluators with model access, which the Code specifically requires for systemic-risk models; an internal-only evaluation program doesn’t satisfy this on its own. NIKOLAI’s evaluator independence and external review elements describe the structural conditions — access, independence, disclosure rights — that make an outside evaluation credible rather than nominal.

Timing matters here too: the Code requires the SSF itself to be in place no later than four weeks after notifying the Commission that a model qualifies as general-purpose, and no later than two weeks before the model is placed on the market. A risk register that’s reviewed on a quarterly cadence unrelated to release timing will usually need a release-triggered checkpoint added specifically for this.

Mapping your governance framework to the Code’s accountability measures

The Safety and Security chapter’s governance measures ask for systemic-risk responsibilities to be defined at every level of the organization, adequate resourcing for the function, a management board with explicit supervisory duties and reporting lines into it, and protections for staff who raise noncompliance concerns internally. If you’ve already built an AI governance framework with a council, defined decision authority, and an accountable decision-maker, the structural pieces are mostly there — what the Code adds is a specific requirement that this authority chain reach the management board, not stop at a cross-functional council one level below it.

The clearest gap is usually the whistleblower piece: a general AI governance framework often has an escalation path for risks discovered through normal review, but not a protected channel for someone to flag suspected noncompliance without going through their own chain of command. NIKOLAI’s accountable decision-maker element and its noncompliance/whistleblower reporting element are useful as a checklist for both pieces — who is on record as accountable, and what the protected reporting path looks like when the concern is about the program itself rather than a specific model risk.

Mapping your incident response program to the Code’s reporting commitments

An internal AI safety incident response program built for operational incidents — a model behaving unexpectedly in production, a safeguard failing — covers most of the detection and triage work the Code’s incident-reporting commitment also needs. What changes under the Code is who gets notified and on what timeline. The Code sets staggered reporting timelines to the AI Office based on incident severity, rather than a single fixed deadline; an incident program built only around internal escalation and customer notification will need an added branch that routes systemic-risk incidents to the regulator on the Code’s schedule rather than whatever internal SLA the program already runs on. NIKOLAI’s incident reporting deadline element and its general incident element are a reasonable structural reference for building that branch: what counts as a reportable incident, and what the clock starts on.

The Transparency and Copyright chapters: don’t skip these because Safety and Security is the interesting one

Because Safety and Security maps so directly onto risk-register/governance/incident-response work, it’s easy to treat Transparency and Copyright as an afterthought — but they apply to every GPAI provider, including ones with no systemic-risk exposure at all. The Transparency chapter’s Model Documentation Form is closer to a compliance-documentation exercise than a safety-program one: capability descriptions, known limitations, and points of contact, kept current and retained for ten years, with a subset made available to downstream deployers building on the model. The Copyright chapter is largely outside a safety program’s usual scope — it’s a data-governance and legal-process question (lawful acquisition, rights-reservation compliance, a complaint mechanism) that typically sits with legal or data-governance functions rather than the AI safety team, even though the same program often ends up coordinating it.

A starting sequence

1. Confirm scope. Are you a GPAI provider under Article 53, and does your model meet the systemic-risk threshold under Article 55? This determines which chapters bind you versus which you’re using as a benchmark.
2. Inventory what exists. Lay your risk register, governance framework, and incident response program next to the three chapters and mark, section by section, covered / partial / missing.
3. Close the external-evaluation gap first. It’s the piece most programs are missing entirely, and it has the longest lead time to arrange.
4. Add the regulator-notification branch to incident response, timed to the Code’s severity-based schedule rather than an internal SLA.
5. Extend governance accountability up to board level and add a protected whistleblower channel if one doesn’t already exist.
6. Hand Transparency and Copyright to the functions that already own documentation and data governance, rather than trying to run them entirely inside the safety program.

FAQ

Do we need to comply with the GPAI Code of Practice if we only use third-party AI models, not build our own?

Generally no. The Code binds providers of general-purpose AI models under Articles 53 and 55. An organization that deploys a vendor’s GPAI model without modifying it substantially enough to become a provider in its own right isn’t directly bound by the Code, though downstream deployer obligations elsewhere in the AI Act may still apply depending on how the system is used.

Is signing the Code mandatory?

No. It’s a voluntary tool created under Article 56 to give providers a streamlined way to demonstrate compliance. Non-signatories can still comply with Articles 53 and 55 through other means, but the AI Office has indicated it will focus more direct scrutiny and information requests on providers that haven’t signed.

What’s the actual deadline pressure here?

Obligations under Articles 53 and 55 already apply as of 2 August 2025. The Commission’s enforcement powers begin 2 August 2026, and providers of models already on the market before 2 August 2025 have until 2 August 2027 to reach compliance — so the practical urgency depends on when your model was or will be placed on the market, not a single fixed date.

How is this different from the ISO/IEC 42001 or NIST AI RMF mapping most programs already do?

Those are general-purpose AI management frameworks usable for any AI system. The GPAI Code of Practice is specific to general-purpose AI models and, in its Safety and Security chapter, specific to models with systemic risk — it asks for things like external evaluator access and regulator-facing incident timelines that a general ISO 42001 or NIST AI RMF program doesn’t require on its own. Programs built against those frameworks usually have the organizational bones the Code needs; they still need the systemic-risk-specific pieces added.

Where does NIKOLAI fit into this?

NIKOLAI is a structured element set for describing frontier AI safety frameworks — thresholds, evaluations, incidents, governance commitments — in comparable terms. It isn’t a substitute for the Code’s legal text, but its elements are a useful checklist for the specific structural pieces (accountable decision-maker, evaluator independence, incident reporting deadlines, whistleblower reporting) that the Safety and Security chapter asks for and that a general safety program sometimes leaves implicit.