California SB 53 (Transparency in Frontier AI Act)

Informational data, not legal advice. Summaries are TwinEthos's own words and rules have not been reviewed by a lawyer: check the official text before relying on any of it. A guard addresses an item; adding it is not a statement that your code meets any law.

Official text: oag.ca.gov.

Binding law — in force

Large frontier developers must publish an implemented frontier AI risk framework (California SB 53)

Cal. Bus. & Prof. Code 22757.12 (frontier AI framework) [per CA AG summary] · official text · In force: applies since 1 Jan 2026 · California (US-CA)

Under California's Transparency in Frontier Artificial Intelligence Act (SB 53; Bus. & Prof. Code 22757.10 et seq., effective 2026-01-01 — the first US statute focused squarely on AI safety), large frontier developers must write, implement, and clearly and conspicuously publish on their website a frontier AI framework applying to their frontier models, describing how they approach: incorporating national/international standards and industry-consensus best practices; defining and assessing thresholds used to identify whether a frontier model has capabilities that could pose a catastrophic risk; applying mitigations to address potential catastrophic risks; identifying and responding to critical safety incidents; and assessing and managing catastrophic risk arising from internal use of their frontier models. They must additionally submit to the Office of Emergency Services a summary of any assessment of catastrophic risk from internal use. Detect a frontier-model development context with no published risk framework or no internal-use catastrophic-risk assessment.

Who it applies to

Duty falls on: developer
FRONTIER DEVELOPERS training foundation models above the statutory compute threshold (>10^26 FLOPs), with enhanced duties for LARGE frontier developers (>$500M annual revenue). Effective 2026-01-01. Not applicable to ordinary AI-integrating applications — this binds model developers, not deployers.
Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Organizational artifact to keep (not verifiable from code); the guard is the record, its owner and its upkeep.

Publish a frontier AI framework covering capability thresholds, mitigations, incident response, and internal-use risk, and gate model releases on it.

A public framework page, linked from the developer's website and owned by the frontier-safety lead, that maps each covered topic to the policy implementing it: standards adopted, catastrophic-capability thresholds and the evaluations that test them, mitigations applied when thresholds are reached, critical safety incident identification and response, and assessment of catastrophic risk from internal use. Show that it is implemented: release checklists cite the threshold evaluation results, a versioned changelog records changes with reasons and dates, and internal-use risk summaries sent to regulators are tracked with receipts. A CI or release gate refuses to promote a frontier model whose release record lacks the evaluations the framework calls for.

Where it goes: 12 repository artifacts, 14 user-facing text, 11 CI/CD pipeline.

What this provision adds:

Submit to the Office of Emergency Services a summary of any assessment of catastrophic risk from internal use of the developer's frontier models.

Example (Model release record + CI gate), before:

# releases/model-x.yaml
model: model-x
approved_by: research-lead

After:

# releases/model-x.yaml (CI fails if a required field is missing)
model: model-x
framework_version: 2.3     # https://example.ai/frontier-framework
threshold_evals:
  bio_uplift: evals/results/model-x/bio.json
  cyber_offense: evals/results/model-x/cyber.json
  autonomy: evals/results/model-x/autonomy.json
thresholds_crossed: [cyber_offense]
mitigations: [classifier-gating, staged-access]
incident_runbook: docs/safety/critical-incident-response.md
approved_by: frontier-safety-lead

Control: Frontier AI developer without a published catastrophic-risk framework. The same guard addresses 3 items with binding law in 3 jurisdictions. Engineering guidance, not legal advice.

Rule id ca-sb53.frontier-ai-framework · review status: primary source derived

Binding law — in force

Frontier developers must not suppress or retaliate against AI safety whistleblowers (California SB 53)

Cal. Labor Code 1107.1 (covered-employee disclosure) [per CA AG summary] · official text · In force: applies since 1 Jan 2026 · California (US-CA)

Under California SB 53 (Labor Code 1107.1), employees responsible for assessing, managing, or addressing the risk of critical safety incidents regarding AI foundation models ('covered employees') may disclose to the Attorney General or other specified entities information they have reasonable cause to believe shows either that the frontier developer's activities pose a specific and substantial danger to public health or safety resulting from a catastrophic risk, or that the developer has violated the Transparency in Frontier AI Act. Frontier developers cannot make or enforce rules, regulations, policies, or contracts that prevent covered employees from making such disclosures, or that retaliate against them for doing so. Detect employment agreements, policies, or internal controls that restrict AI-safety disclosures, or the absence of a protected internal reporting channel.

Who it applies to

Duty falls on: developer
Frontier developers of AI foundation models with California-covered employees. Effective 2026-01-01. Binds employment policy/contract terms, not the AI system itself.
Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Organizational artifact to keep (not verifiable from code); the guard is the record, its owner and its upkeep.

Carve AI-safety and legal-violation disclosures out of every NDA and policy, adopt non-retaliation, and run an internal safety-concern channel for covered employees.

Legal and HR own the employment and confidentiality templates (offer letters, NDAs, separation agreements, codes of conduct) and add an explicit carve-out stating that nothing in them stops a covered employee from reporting catastrophic-risk concerns or violations of the law to the authorities the statute names, or requires company approval first. Pair it with a written non-retaliation policy and an internal reporting channel for safety concerns (anonymous where required) with a documented triage and response procedure. Re-check every template when it is edited; the repository can hold the policy, the clause, and a CI check that each agreement template still contains the carve-out.

Where it goes: 12 repository artifacts, 14 user-facing text.

What this provision adds:

The carve-out protects covered employees (those responsible for assessing, managing or addressing critical-safety-incident risk) disclosing to the Attorney General or the other entities the statute specifies.

Example (Employee NDA template), before:

Employee shall not disclose any Confidential Information to any third party, including any government body, without the Company's prior written consent.

After:

Employee shall not disclose Confidential Information to any third party without the Company's prior written consent.

<!-- SAFETY-DISCLOSURE-CARVE-OUT -->
Nothing in this Agreement prevents Employee, without notice to or approval from the Company, from reporting to a government authority or through the Company's internal safety channel information Employee reasonably believes shows a specific and substantial danger to public health or safety from a catastrophic risk, or a violation of law. The Company will not retaliate against Employee for such a report.

Control: Frontier developer restricts or retaliates against safety whistleblowers. The same guard addresses 2 items with binding law in 2 jurisdictions. Engineering guidance, not legal advice.

Rule id ca-sb53.frontier-whistleblower-protection · review status: primary source derived