Frontier Models

Highly capable AI models attract additional governance attention, but frontier model, general-purpose AI (GPAI), systemic risk and high-impact AI are not interchangeable legal categories. This chapter separates binding duties, voluntary compliance tools, testing partnerships and developer commitments. Classify the model and provider under each applicable regime before selecting the required evidence.

What counts as a “frontier model”?

There is no universal definition. Distinguish these criteria:

• Compute — EU AI Act Article 51(2) presumes high-impact capabilities above 10²⁵ floating-point operations of cumulative training compute; this is not a universal frontier-model definition. The Commission can amend the threshold by delegated act.
• Capability — ability to perform a wide range of distinct tasks, particularly tasks plausibly relevant to severe harm (CBRN, cybersecurity, autonomous replication, deception).
• Designation — the European Commission can designate GPAI models with systemic risk on capability or impact criteria; Article 52 also provides a process for a provider to substantiate an exceptional case against classification.¹

A product name or a high benchmark score is not a legal classification. Record the exact model version, compute evidence where available, capabilities, distribution method, provider role and relevant designation. Reassess material updates; a static list of brand names becomes stale quickly.

EU GPAI obligations and the voluntary Code

Articles 53–55 establish GPAI duties, with scope-specific exceptions and transitional treatment. Depending on the model and provider, these include:

• Maintain technical documentation of the model (training, evaluation, capabilities, limitations).
• Provide downstream documentation to providers integrating the model into AI systems.
• Comply with Union copyright law, including TDM opt-outs.
• Publish a summary of training content.
• For systemic-risk GPAI: evaluations including adversarial testing, risk assessment and mitigation, serious-incident tracking/reporting, and cybersecurity.

The GPAI Code of Practice, published 10 July 2025, is a voluntary route to demonstrating compliance; the underlying law is binding for in-scope providers. Its Safety and Security chapter concerns systemic-risk GPAI. Providers choosing another route still need adequate evidence. Check the Commission’s current signatory list and chapter coverage: a signature is not independent proof that every model and practice complies. See EU AI Act for dates and exceptions.

CAISI testing agreements (United States)

On 5 May 2026, NIST announced new CAISI agreements with Google DeepMind, Microsoft and xAI, building on earlier partnerships. These were not 2025 agreements. The announcement describes pre-deployment evaluation and research; CAISI’s stated role includes voluntary agreements and unclassified national-security capability evaluations.²

These partnerships are not a general US model-licensing requirement or certification scheme. Do not infer unpublished contractual terms, mandatory release approval, or coverage of every model from a press announcement. For a participating provider, record the actual agreement, evaluation scope and follow-up obligations.

California SB 53 — Transparency in Frontier AI Act

California SB 53, signed 29 September 2025, distinguishes a frontier developer from a large frontier developer (the latter includes an annual-revenue threshold). Its requirements include:³

• For large frontier developers, implement and publish a frontier AI framework, with specified risk and governance content.
• Publish a transparency report before or concurrently with a new or substantially modified frontier-model deployment, with additional assessment summaries for large developers.
• Report covered critical safety incidents to Cal OES within 15 days of discovery; imminent death or serious-injury risk has a separate 24-hour notification rule to an appropriate authority.
• Protect covered employee disclosures under its whistleblower provisions.

The statute does not simply require a document called a “safety case” for every release. A model card or other larger document can contain the required disclosures. Cross-mapping to an EU framework may save work, but does not establish equivalence. See US State Laws for scope.

Korea AI Basic Act — frontier safety track

Korea’s AI Basic Act and Enforcement Decree took effect 22 January 2026. MSIT describes a safety-obligation track requiring all three criteria: training compute above 10²⁶ floating-point operations, state-of-the-art technology, and a risk of broad and significant effects on fundamental rights. That track is distinct from high-impact AI, which depends on listed uses and risk. MSIT also announced an enforcement grace period with serious-harm exceptions; it is not a blanket exemption from every duty. Check the current Korean text, subordinate rules and territorial criteria rather than assuming every service accessible in Korea is identically covered.⁴

Voluntary frameworks and the AI Safety Institute network

Several voluntary mechanisms supplement statutory obligations:

• Responsible Scaling Policies (RSPs) — published by Anthropic and (in different forms) by other developers; commit to specific capability evaluations and risk thresholds.
• Frontier Model Forum — an industry organisation focused on frontier-AI safety research and shared practices; membership is not certification.
• Safety benchmarks — bounded evaluation datasets, not guarantees of safety outside the tested tasks. Record benchmark version, configuration, contamination risks and coverage gaps.
• International AI Safety Report 2026, published 3 February 2026 — an international scientific synthesis of GPAI capabilities, risks and safeguards, not binding regulation or a product endorsement.⁵

National evaluation organisations and international research partnerships can support shared methods and evidence. Their names, mandates and participation change; consult the responsible institution for the current programme. Do not treat network participation as a regulatory approval or assume that all members share every incident or evaluation result.

Common frontier-safety architecture

The following is this handbook’s practical synthesis, not a claim that every cited regime mandates the same seven steps:

1. Capability evaluations at defined thresholds — before initial deployment, before scaling, after substantial updates.
2. Risk identification and mitigation — with documented thresholds at which mitigation actions trigger.
3. Safety case — structured argument that residual risk is acceptable, addressed to a defined audience (internal governance, regulator, public).
4. Pre-deployment testing — either internal or in cooperation with AI Safety Institutes.
5. Post-deployment monitoring — for misuse, incidents, capability change.
6. Incident reporting — map the actual recipient, threshold, deadline and confidentiality requirements for each applicable duty or agreement.
7. Transparency — published framework, safety case, model card.

Planning posture for frontier developers

Start with an applicability record and build proportionate evidence. Distinguish required actions from optional mechanisms:

• EU GPAI compliance where in scope, using the Code or another adequate route, with the relevant transition dates recorded.
• Government testing partnerships where available and appropriate; a CAISI agreement is not a universal condition for US operations.
• California and Korean applicability reviews using their separate model, developer and territorial criteria.
• Published frontier AI framework / RSP with specified capability thresholds and mitigation actions.
• Release decision record, potentially organised as a safety case, identifying evidence, residual risk and approval authority.
• Management-system controls, with ISO/IEC 42001 considered where useful or contractually required; certification is not a universal legal duty.
• Incident reporting procedures consistent with all applicable regimes.

For deployers and downstream integrators

If you integrate frontier models rather than develop them, the governance focus is:

1. Evaluate upstream evidence, not just a compliance badge: applicable disclosures, model limitations, testing scope, contractual rights and incident contacts.
2. Receive and act on downstream documentation provided under Article 53(1)(b) EU AI Act.
3. Implement use-case-specific risk management — the frontier-safety framework of the upstream developer does not substitute for your own risk assessment of the deployed application.
4. Maintain provenance — document which model version is in production, what changed when, and your validation of those changes.
5. Monitor for incidents in your deployment and feed back to the upstream developer.

Footnotes

1. Regulation (EU) 2024/1689, Articles 51–55. ↩

2. NIST, 5 May 2026 agreement announcement and CAISI mandate. ↩

3. California Legislature, SB 53, chaptered text, particularly Business and Professions Code sections 22757.11–22757.13. ↩

4. MSIT, The AI Basic Act Comes into Force, January 2026. ↩

5. International AI Safety Report 2026, 3 February 2026. ↩