# Frontier AI Safety and Security Framework: [Developer] [Model family]

> Safety and security framework for a developer of advanced or
> general-purpose AI models: scope and applicability, systemic risk
> identification, capability thresholds and risk tiers, evaluations and
> red teaming, safety and security mitigations, model weight security,
> deployment decisions, model reports, serious incident reporting,
> whistleblower channels, governance, external review and framework
> updates. The structure follows the ten commitments of the Safety and
> Security chapter of the EU General-Purpose AI Code of Practice
> (final, 10 July 2025) for providers of general-purpose AI models with
> systemic risk under Articles 51 and 55 of the EU Artificial
> Intelligence Act (Regulation (EU) 2024/1689 as amended by Regulation
> (EU) 2026/1744), and maps to the frontier AI framework required by
> California SB 53, the Transparency in Frontier Artificial
> Intelligence Act (in force 1 January 2026), and the New York RAISE
> Act as amended in March 2026 (effective 1 January 2027). Replace every
> `[bracketed]` value and every row marked *Example*. Thresholds shown
> are examples, not regulatory values unless the text says so; check
> the consolidated texts. This is a documentation format, not legal
> advice.

<!--
Guidance: How to use this template
- Decide first which regimes apply (section 1). A model above the AI
  Act systemic risk presumption is not automatically a "frontier model"
  under SB 53 or RAISE, and the reverse; record each test separately.
- The framework is a public commitment in California and New York for
  large frontier developers: write it so that it can be published, and
  keep confidential details (exact thresholds, security controls) in a
  restricted annex with a note of what was redacted and why.
- Sections 2 to 8, 10 and 12 implement the Code of Practice Safety and
  Security chapter commitments 1 to 10. Keep the mapping in section 13
  current so a reviewer can trace each commitment to its section.
- Your own framework binds you: SB 53 and RAISE penalise failing to
  follow it. Do not write commitments you cannot keep.
- Read the official texts of the Regulation, the Code, SB 53 and the
  RAISE Act; seek legal advice.
-->

## Document control

<!-- Guidance: Identify the developer, the models covered and the people accountable for systemic risk decisions. Record the publication status separately from approval. -->

| Field | Value |
|---|---|
| Document ID | [FSF-001] |
| Developer | [Legal name, affiliates included in revenue test] |
| Models covered | [Model family, versions, release dates] |
| Regimes | [EU AI Act GPAI with systemic risk / SB 53 / RAISE / voluntary] |
| Code of Practice signatory | [Yes: Safety and Security chapter, date / No] |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Published / Superseded] |
| Owner | [@frontier-safety-lead] |
| Approvers/reviewers | [@ceo], [@board-risk-committee], [@cso], [@general-counsel], [@head-of-research] |
| Last updated | YYYY-MM-DD |
| Next scheduled assessment | YYYY-MM-DD (at least every 12 months) |
| Publication | [URL of published version / redacted annex reference] |
| Classification | [Public version / Restricted annex: confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Executive management body | [@name] | [Approve / Reject] | YYYY-MM-DD |
| Supervisory body (board risk committee) | [@name] | [Oversight confirmation] | YYYY-MM-DD |
| Head of frontier safety | [@name] | [Approve] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Approve security sections] | YYYY-MM-DD |
| General counsel | [@name] | [Approve] | YYYY-MM-DD |

### Revision history

<!-- Guidance: SB 53 and RAISE require material modifications to be published with a justification within 30 days. Record every change, whether material, and its publication date. -->

| Version | Date | Author | Change summary | Material? | Published |
|---|---|---|---|---|---|
| 0.9 | YYYY-MM-DD | [@name] | Draft for board review | n/a | No |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* First approved framework | Yes | YYYY-MM-DD |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Added autonomous replication evaluation to loss-of-control tier 2 | Yes | YYYY-MM-DD |

## Contents

<!-- Guidance: Keep aligned with the headings below. -->

1. [Scope and applicability](#1-scope-and-applicability)
2. [Systemic risk identification](#2-systemic-risk-identification)
3. [Systemic risk analysis and evaluations](#3-systemic-risk-analysis-and-evaluations)
4. [Risk tiers, thresholds and acceptance](#4-risk-tiers-thresholds-and-acceptance)
5. [Safety mitigations](#5-safety-mitigations)
6. [Security mitigations and model weights](#6-security-mitigations-and-model-weights)
7. [Deployment decisions and model reports](#7-deployment-decisions-and-model-reports)
8. [Serious incident tracking and reporting](#8-serious-incident-tracking-and-reporting)
9. [Whistleblower and internal reporting channels](#9-whistleblower-and-internal-reporting-channels)
10. [Governance and responsibility allocation](#10-governance-and-responsibility-allocation)
11. [External review and transparency](#11-external-review-and-transparency)
12. [Framework assessment and updates](#12-framework-assessment-and-updates)
13. [Regulatory mapping](#13-regulatory-mapping)
14. [Glossary and references](#14-glossary-and-references)

## 1. Scope and applicability

<!-- Guidance: Record each legal test with the figure you used and its source (training compute estimate, revenue). If you rely on an estimate, keep the method. Pitfall: excluding fine-tuning and reinforcement learning compute, which SB 53 counts towards the training total. -->

### 1.1 Applicability tests

| Regime | Test (summary) | Our figure | Applies? | Evidence |
|---|---|---|---|---|
| EU AI Act Art. 51 | GPAI model with high-impact capabilities; presumed when cumulative training compute exceeds 10^25 floating-point operations, or designated by the Commission | *Example:* 3.1 x 10^25 FLOP (estimate method M-02) | Yes | Compute report EV-001 |
| EU AI Act Art. 52 | Notify the Commission within two weeks of meeting, or knowing you will meet, the threshold | *Example:* notified YYYY-MM-DD | Done | EV-002 |
| California SB 53 | Frontier model: foundation model trained with more than 10^26 operations, including fine-tuning, reinforcement learning and material modifications; large frontier developer: frontier developer with affiliates above 500 million USD annual gross revenue in the preceding year | *Example:* 1.4 x 10^26; revenue above threshold | Yes, large frontier developer | EV-003 |
| New York RAISE Act (amended) | Frontier model and large frontier developer tests broadly aligned with SB 53 after the March 2026 chapter amendment; check the enacted text | *Example:* same figures as SB 53 | Yes from 1 January 2027 | EV-004 |
| Korea AI Basic Act | Safety duties for AI above a cumulative compute level set by Enforcement Decree (reported as 10^26 FLOP) | [Figure] | [Yes / No] | [Evidence] |

### 1.2 Models and activities covered

| Model | Stage | Release type | Internal use? | Covered by |
|---|---|---|---|---|
| MDL-001 *(Example)* [Model] v3 | Deployed | API and chat product | Yes, research agents | All regimes above |
| MDL-002 *(Example)* [Model] v4 | In training | Planned closed release | Yes | All; pre-deployment review required |
| MDL-003 *(Example)* Distilled small model | Deployed | Open weights | No | AI Act GPAI obligations only (below systemic risk threshold) |

Internal use counts: SB 53 asks the framework to address catastrophic
risk from internal use, including a model circumventing oversight, and
large frontier developers send periodic summaries of internal-use risk
assessments to the California Office of Emergency Services.

## 2. Systemic risk identification

<!-- Guidance: Code of Practice Commitment 2. Start from the specified systemic risks in the Code's appendix (chemical, biological, radiological and nuclear; loss of control; cyber offence; harmful manipulation) and add any others your model profile suggests. Write a scenario for each so evaluations test something concrete. -->

### 2.1 Risk register

| ID | Systemic risk | Source of the risk | Scenario (summary) | Code appendix type | SB 53 catastrophic risk? |
|---|---|---|---|---|---|
| SR-CBRN *(Example)* | Chemical, biological, radiological, nuclear | Expert-level uplift to novices | Model provides step-by-step guidance that meaningfully lowers barriers to producing a biological agent | Specified | Yes |
| SR-CYB *(Example)* | Cyber offence | Autonomous vulnerability discovery and exploitation | Agentic model chains discovery and exploitation against critical infrastructure without human direction | Specified | Yes (cyberattack without meaningful human oversight) |
| SR-LOC *(Example)* | Loss of control | Deception, oversight evasion, self-exfiltration | Model under agent scaffold disables monitoring and copies its weights | Specified | Yes (evading control) |
| SR-MAN *(Example)* | Harmful manipulation | Persuasion at scale | Model targets individuals with tailored political persuasion | Specified | Usually no; record reasoning |
| SR-OTH-01 *(Example)* | [Other identified risk] | [Source] | [Scenario] | Identified by us | [Yes / No] |

### 2.2 Catastrophic risk definition used

SB 53 defines catastrophic risk as a foreseeable and material risk that
the developer's model materially contributes to the death of, or
serious injury to, more than 50 people, or more than 1 billion USD in
property damage, from a single incident involving expert-level CBRN
assistance, a cyberattack or serious crime conducted without meaningful
human oversight, or the model evading the control of its developer or
user. Record here how your internal severity scale relates to that
definition: [*Example:* internal severity level S4 and S5 correspond to
the SB 53 definition.]

## 3. Systemic risk analysis and evaluations

<!-- Guidance: Code of Practice Commitment 3; AI Act Article 55(1)(a) requires model evaluation using standardised protocols and tools reflecting the state of the art, including adversarial testing. Plan evaluations before training ends, run them at defined checkpoints and again before each deployment decision. Pitfall: evaluating a weakly elicited model; elicit capabilities with the best available scaffolds, tools and fine-tuning. -->

### 3.1 Evaluation suite

| ID | Risk | Evaluation | Type | Elicitation | Run by | Checkpoints |
|---|---|---|---|---|---|---|
| EVL-001 *(Example)* | SR-CBRN | Biology protocol troubleshooting benchmark | Automated benchmark | Best prompting plus tool access | Internal | 25%, 50%, final, pre-deployment |
| EVL-002 *(Example)* | SR-CBRN | Expert red team, wet-lab uplift study design review | Human red team | Unrestricted model, expert testers | External lab [name] | Final |
| EVL-003 *(Example)* | SR-CYB | Capture-the-flag suite, professional difficulty | Agentic | Full agent scaffold, 50 attempts per task | Internal | Each checkpoint |
| EVL-004 *(Example)* | SR-CYB | Range exercise against emulated industrial network | Agentic | Scaffold plus human-in-the-loop baseline | External | Final |
| EVL-005 *(Example)* | SR-LOC | Oversight evasion and sandbagging probes | Behavioural | Agent with monitoring hooks | Internal alignment team | Final, pre-deployment |
| EVL-006 *(Example)* | SR-LOC | Autonomous replication and adaptation tasks | Agentic | Cloud sandbox | External | Final |
| EVL-007 *(Example)* | SR-MAN | Persuasion study with consenting participants | Human study | Production system prompt | Internal research, ethics approved | Major versions |

### 3.2 Risk modelling and estimation

For each risk, describe the pathway from model capability to harm,
the steps where the model provides uplift, and the estimate of
likelihood and severity with and without mitigations. *Example:* for
SR-CBRN the model is mapped against an attack chain of seven steps; the
evaluations measure uplift at the three steps where knowledge is the
main barrier.

### 3.3 Post-market monitoring inputs

| Source | Signal | Feeds |
|---|---|---|
| *Example:* Abuse detection classifiers | Rate of blocked CBRN queries | SR-CBRN estimate |
| *Example:* Bug bounty and researcher reports | Jailbreak reports | Safeguard effectiveness |
| *Example:* Downstream provider reports | Misuse cases | All risks |
| *Example:* Internal agent telemetry | Oversight anomalies | SR-LOC |

## 4. Risk tiers, thresholds and acceptance

<!-- Guidance: Code of Practice Commitment 4 (systemic risk acceptance determination); SB 53 asks the framework to define and assess thresholds, which may be multi-tiered. Define tiers before you see results. Each tier needs a capability threshold, the mitigations required, and who can accept the risk. Keep exact numeric thresholds in the restricted annex if publishing them would help misuse. -->

### 4.1 Tier definitions

| Tier | Meaning | Required mitigations | Acceptance authority |
|---|---|---|---|
| T0 *(Example)* | No meaningful uplift over public resources | Baseline safety training and usage policy | Head of frontier safety |
| T1 *(Example)* | Early warning: capability approaching a level of concern | Enhanced monitoring, targeted refusals, security level S2 | Head of frontier safety |
| T2 *(Example)* | Capability that could provide significant uplift to a known threat actor | Classifier safeguards, trusted access programme, security level S3, external review | Executive management body |
| T3 *(Example)* | Capability that could cause catastrophic harm if misused or uncontrolled | Do not deploy externally; restrict internal use; security level S4; notify board | Supervisory body; default is not to proceed |

### 4.2 Capability thresholds per risk

| Risk | T1 trigger | T2 trigger | T3 trigger |
|---|---|---|---|
| SR-CBRN *(Example)* | Exceeds median expert baseline on EVL-001 | Red team confirms meaningful uplift on two or more attack chain steps | Uplift across full chain in EVL-002 |
| SR-CYB *(Example)* | Solves 30% of professional CTF tasks | Completes an end-to-end range intrusion with minor human help | Completes range intrusion autonomously |
| SR-LOC *(Example)* | Any successful oversight evasion in probes | Repeated evasion or sandbagging detected | Successful autonomous replication in sandbox |

### 4.3 Safety margins and acceptance

Explain the margin between measured capability and each threshold, how
uncertainty in elicitation is handled, and the rule when results are
ambiguous. *Example:* where results fall within 10 percentage points of
a trigger, the model is treated as having reached the next tier.

## 5. Safety mitigations

<!-- Guidance: Code of Practice Commitment 5. List mitigations by layer and the tier that requires them. Test each mitigation; a mitigation with no measured effectiveness is a hope. -->

| ID | Mitigation | Layer | Required from tier | Effectiveness evidence | Owner |
|---|---|---|---|---|---|
| MIT-001 *(Example)* | Refusal and safe-completion training for CBRN | Model | T1 | Refusal rate on held-out set | [@alignment-lead] |
| MIT-002 *(Example)* | Input and output classifiers for CBRN and cyber | System | T2 | Red team bypass rate | [@safeguards-lead] |
| MIT-003 *(Example)* | Trusted access programme for dual-use cyber capability | Access | T2 | Vetting records | [@trust-safety] |
| MIT-004 *(Example)* | Account-level abuse detection and enforcement | Operations | T1 | Enforcement metrics | [@trust-safety] |
| MIT-005 *(Example)* | Staged release: internal, trusted testers, general availability | Release | T2 | Stage gate records | [@release-lead] |
| MIT-006 *(Example)* | Agent sandbox with egress controls and human approval for high-impact actions | Internal use | T1 for agents | Sandbox audit | [@platform-security] |

Open-weight release: state the rule. *Example:* models at T2 or above
in any risk are not released as open weights, since system-level
safeguards cannot be enforced after release.

## 6. Security mitigations and model weights

<!-- Guidance: Code of Practice Commitment 6; AI Act Article 55(1)(d) requires an adequate level of cybersecurity protection for the model and its physical infrastructure; SB 53 asks the framework to describe cybersecurity practices for unreleased model weights. Define security levels and the threat actors each one resists. Keep control details in the restricted annex. -->

### 6.1 Security levels

| Level | Threat actors resisted | Example controls | Applies to |
|---|---|---|---|
| S1 *(Example)* | Opportunistic attackers | Standard enterprise controls, MFA, encrypted storage | T0 models |
| S2 *(Example)* | Organised criminal groups | Weight access limited to named staff, hardware-backed keys, egress monitoring | T1 |
| S3 *(Example)* | Well-resourced groups, insiders | Two-person rule for weight access, isolated training clusters, insider risk programme | T2 |
| S4 *(Example)* | Highly resourced state actors | Air-gapped storage, confidential computing, continuous red teaming | T3 |

### 6.2 Weight security controls

| ID | Control | Level | Evidence |
|---|---|---|---|
| SEC-001 *(Example)* | Inventory of every copy of weights, with owner and location | S1 | Inventory export |
| SEC-002 *(Example)* | Access requests approved by two people, logged and reviewed weekly | S3 | Access logs |
| SEC-003 *(Example)* | Rate limits and output monitoring on APIs to detect distillation or extraction | S2 | Monitoring dashboard |
| SEC-004 *(Example)* | Background checks for staff with weight access, as lawful | S3 | HR records |
| SEC-005 *(Example)* | Annual external penetration test of training and serving infrastructure | S2 | Test report |

## 7. Deployment decisions and model reports

<!-- Guidance: Code of Practice Commitment 7 requires a Safety and Security Model Report to the AI Office before placing a model on the market; SB 53 and RAISE require a transparency report published before or at the time of deploying a new or substantially modified frontier model. Record each decision, its evidence and who made it. -->

### 7.1 Decision record

| ID | Model and version | Decision point | Tier reached per risk | Decision | Conditions | Decided by | Date |
|---|---|---|---|---|---|---|---|
| DEC-001 *(Example)* | MDL-002 v4 | External deployment | CBRN T1, CYB T2, LOC T0, MAN T0 | Proceed with conditions | MIT-002 and MIT-003 live; S3 confirmed | Executive management body | YYYY-MM-DD |
| DEC-002 *(Example)* | MDL-002 v4 | Open-weight release | CYB T2 | Do not proceed | n/a | Executive management body | YYYY-MM-DD |

### 7.2 Model report contents (EU)

| Element (summary) | Location |
|---|---|
| Model description, capabilities, intended uses, versions and model specification | [Report section] |
| Reasons for proceeding, safety margins and the conditions under which that reasoning would no longer hold | [Section] |
| Results and methods of systemic risk identification, analysis and mitigation, including evaluation results | [Section] |
| Reports from independent external evaluators | [Section] |
| Material changes to the systemic risk landscape | [Section] |

### 7.3 Transparency report contents (California and New York)

| Element (summary) | Location |
|---|---|
| Developer website, contact mechanism, release date, languages, output modalities, intended uses and restrictions | [Published page] |
| Summary of catastrophic risk assessments and results (large frontier developers) | [Section] |
| Extent of third-party evaluator involvement | [Section] |
| Other steps taken to fulfil the framework | [Section] |
| Redactions, with the reason (trade secret, cybersecurity, public safety, national security) and the unredacted version retained | [Annex reference] |

## 8. Serious incident tracking and reporting

<!-- Guidance: Code of Practice Commitment 9; AI Act Article 55(1)(c) requires tracking, documenting and reporting serious incidents and possible corrective measures to the AI Office, and to national competent authorities as appropriate, without undue delay. SB 53 and RAISE add critical safety incident reporting to state authorities. Build one intake and run all clocks from it. Pitfall: waiting for full facts before the first report. -->

### 8.1 Reporting clocks

| Regime | Event | Initial deadline | Recipient | Follow-up |
|---|---|---|---|---|
| GPAI Code of Practice (EU) | Serious and irreversible disruption of critical infrastructure | 2 days from awareness of model involvement | AI Office (and national authorities as appropriate) | Intermediate report at least every 4 weeks; final report within 60 days of resolution |
| GPAI Code of Practice (EU) | Serious cybersecurity breach, including weight exfiltration and cyberattacks | 5 days | AI Office | Same |
| GPAI Code of Practice (EU) | Death of a person | 10 days | AI Office | Same |
| GPAI Code of Practice (EU) | Serious harm to health, fundamental rights, property or the environment | 15 days | AI Office | Same |
| California SB 53 | Critical safety incident | 15 days from discovery | California Office of Emergency Services | As OES requires |
| California SB 53 | Critical safety incident with imminent risk of death or serious physical injury | 24 hours | Appropriate authority, including law enforcement or public safety agency | Then OES |
| New York RAISE Act (amended) | Critical safety incident | 72 hours from determination or reasonable belief (check the enacted text) | State oversight office (reported as an office within the Department of Financial Services) | As the office requires |

### 8.2 Incident log

| ID | Date found | Model | Category | Clocks triggered | Reports sent | Status |
|---|---|---|---|---|---|---|
| INC-001 *(Example)* | YYYY-MM-DD | MDL-001 v3 | Unauthorised access attempt to weight store, contained | EU 5 days (assessed as not serious, reasoning recorded) | None required; internal record | Closed |

Retain incident documentation for at least five years (Code of
Practice), and link each record to `ai-data/ai-incident-report`.

```mermaid
flowchart LR
  A["Signal: staff, monitoring, user, researcher"] --> B["Triage within 4 hours"]
  B --> C{"Serious or critical safety incident?"}
  C -->|No| D["Record reasoning, monitor"]
  C -->|Yes| E["Start all applicable clocks"]
  E --> F{"Imminent risk to life?"}
  F -->|Yes| G["24-hour notice to authority"]
  F -->|No| H["Initial reports: EU, California, New York"]
  G --> H
  H --> I["Corrective measures and follow-up reports"]
  I --> J["Final report and framework review"]
```

## 9. Whistleblower and internal reporting channels

<!-- Guidance: SB 53 (Labor Code provisions) protects covered employees who disclose specific and substantial dangers to public health or safety from catastrophic risk, or violations of the Act, and requires large frontier developers to provide a reasonable anonymous internal process with monthly status updates to the reporter. The Code of Practice (Measure 8.3) asks signatories to inform workers annually of the whistleblower policy and not to retaliate. The EU Whistleblower Directive (EU) 2019/1937 covers reports of AI Act breaches. -->

| Item | Value |
|---|---|
| Anonymous internal channel | [Provider or tool, URL] |
| Who receives reports | [Independent function, with escalation to board risk committee] |
| Update to reporter | *Example:* at least monthly until closed |
| Periodic briefing to officers and directors | *Example:* quarterly summary of disclosures and responses |
| Notice of rights to covered employees | *Example:* posted on intranet and in offices; annual acknowledgement |
| External channels named | AI Office, California Attorney General, other competent authorities |
| Non-retaliation statement | [Policy reference] |
| Contract review | *Example:* confidentiality agreements checked so they do not prevent protected disclosures |

## 10. Governance and responsibility allocation

<!-- Guidance: Code of Practice Commitment 8 allocates responsibility for systemic risk oversight, ownership, support and monitoring, and assurance across the supervisory body, executive management, operational teams and internal and external assurance. Name people, not only functions, and give them resources. -->

| Responsibility | Supervisory body | Executive management | Operational teams | Internal assurance | External assurance |
|---|---|---|---|---|---|
| Oversight *(Example)* | Board risk committee reviews framework yearly | CEO accountable | n/a | Internal audit reports to committee | n/a |
| Ownership *(Example)* | n/a | Head of frontier safety | Evaluation and safeguards teams | n/a | n/a |
| Support and monitoring *(Example)* | n/a | CFO allocates budget | Security, trust and safety | Risk function | n/a |
| Assurance *(Example)* | Receives reports | n/a | n/a | Annual audit of adherence | Independent evaluators per release |

Resources: [*Example:* the frontier safety budget is set as a share of
the training compute budget and approved by the board each year;
evaluation teams have priority access to pre-release checkpoints.]

Risk culture: [Describe how staff can raise concerns, how dissent on a
deployment decision is recorded, and how incentives avoid rewarding
speed over safety.]

## 11. External review and transparency

<!-- Guidance: The Code of Practice expects independent external evaluation unless an exception applies; SB 53 asks the framework to describe the use of third-party assessors. Record who reviewed what, with what access, and whether their findings were addressed. -->

| ID | Reviewer | Scope | Access given | Report | Findings addressed |
|---|---|---|---|---|---|
| EXT-001 *(Example)* | [External evaluation organisation] | SR-CYB and SR-LOC on MDL-002 v4 | Pre-release checkpoint, no safeguards, 4 weeks | EXT-001 report | 5 of 6, one accepted with rationale |
| EXT-002 *(Example)* | [Government AI safety institute] | SR-CBRN | API access with safeguards off | Summary letter | Yes |

Public summary: [Describe what you publish: framework, model reports in
summarised form, transparency reports, and where.]

## 12. Framework assessment and updates

<!-- Guidance: Code of Practice Measure 1.3: assess the framework when there are reasonable grounds to think its adequacy or your adherence is materially undermined, and at least every 12 months. SB 53 and RAISE: review at least annually and publish material modifications with a justification within 30 days. -->

| Trigger | Action | Deadline |
|---|---|---|
| Annual cycle | Full framework assessment | Every 12 months from YYYY-MM-DD |
| New capability evidence (internal or external) | Targeted reassessment of affected risks | [30] days |
| Serious or critical safety incident | Reassessment of the related tier and mitigations | Before next deployment |
| Material modification of the framework | Publish new version with justification | Within 30 days (SB 53, RAISE) |
| Change in law, Code or guidance | Legal review and mapping update | [60] days |

Adherence review: [*Example:* internal audit checks each deployment
decision of the year against sections 3 to 7 and reports to the board
risk committee.]

## 13. Regulatory mapping

<!-- Guidance: Show where each requirement is met. Use the commitment and section numbers from the official texts; this table paraphrases them. -->

| Requirement (summary) | Code of Practice S&S | AI Act | SB 53 | RAISE | This document |
|---|---|---|---|---|---|
| Written framework, implemented and kept current | Commitment 1 | Art. 55(1)(b) | Framework duty | Framework duty | Whole document, 12 |
| Identify systemic or catastrophic risks | Commitment 2 | Art. 55(1)(b) | Framework content | Framework content | 2 |
| Evaluate and analyse, including adversarial testing | Commitment 3 | Art. 55(1)(a) | Assessments | Assessments | 3 |
| Thresholds and acceptance | Commitment 4 | Art. 55(1)(b) | Thresholds | Thresholds | 4 |
| Safety mitigations | Commitment 5 | Art. 55(1)(b) | Mitigations | Mitigations | 5 |
| Security and weights | Commitment 6 | Art. 55(1)(d) | Weight security | Weight security | 6 |
| Model and transparency reports | Commitment 7 | Art. 55 with Art. 53 | Transparency report | Transparency report | 7 |
| Responsibility allocation and governance | Commitment 8 | Art. 55 | Internal governance | Internal governance | 10 |
| Serious or critical safety incidents | Commitment 9 | Art. 55(1)(c) | 15 days, 24 hours | 72 hours | 8 |
| Documentation and retention | Commitment 10 | Art. 53, 55 | Unredacted records 5 years | [Check text] | 7, 8 |
| Whistleblowing | Measure 8.3 | Directive (EU) 2019/1937 | Labor Code protections | [Check text] | 9 |

EU timeline: GPAI obligations apply from 2 August 2025; the Commission's
enforcement powers for GPAI providers apply from 2 August 2026; models
placed on the market before 2 August 2025 must comply by 2 August 2027.
Check the consolidated text for changes made by Regulation (EU)
2026/1744.

## 14. Glossary and references

<!-- Guidance: Define the terms used in thresholds and decisions, and list the sources with dates. -->

| Term | Meaning |
|---|---|
| Systemic risk | Under the AI Act, a risk specific to the high-impact capabilities of GPAI models with significant effects on the Union market or on public health, safety, security, fundamental rights or society |
| Catastrophic risk | Under SB 53, the mass-casualty or large-loss risk described in section 2.2 |
| Critical safety incident | Under SB 53 and RAISE, events such as unauthorised access to weights causing harm, harm from a catastrophic risk, loss of control, or deceptive subversion of controls |
| Elicitation | Effort to draw out a model's maximum capability during evaluation |
| Uplift | Increase in an actor's ability to cause harm compared with resources already available |
| Model weights | Learned parameters of a model |

References:

- Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744,
  Articles 3, 51, 52, 53, 55, 101 and 113 (consolidated text).
- General-Purpose AI Code of Practice, Safety and Security chapter
  (final, 10 July 2025), digital-strategy.ec.europa.eu.
- California SB 53 (2025), Transparency in Frontier Artificial
  Intelligence Act, Chapter 138, Statutes of 2025; Business and
  Professions Code, Chapter 25.1 (from Section 22757.10).
- New York RAISE Act (signed 19 December 2025) and chapter amendment
  (signed 27 March 2026), effective 1 January 2027.
- Directive (EU) 2019/1937 (Whistleblower Directive).
- Related templates: `ai-data/gpai-model-documentation`,
  `ai-data/ai-red-team`, `ai-data/ai-incident-report`,
  `ai-data/ai-post-market-monitoring`, `ai-data/model-card`,
  `compliance/ai-regulatory-applicability-register`.

## Standard and licence note

Based on Regulation (EU) 2024/1689 (the Artificial Intelligence Act) as
amended by Regulation (EU) 2026/1744, Articles 51 to 55; structure
aligned with the ten commitments of the Safety and Security chapter of
the General-Purpose AI Code of Practice (10 July 2025); and mapped to
California SB 53 (2025) and the New York RAISE Act as amended in 2026.
Legislative texts are free to reuse; all requirements are paraphrased
in original wording and no text of the Regulation, the Code or the
state laws is reproduced. Check the consolidated text on EUR-Lex, the
Commission's Code of Practice pages, leginfo.legislature.ca.gov and
nysenate.gov for the binding wording and later changes. This is a
documentation format, not legal advice. Template licence: MIT.