THE SHORT VERSION

Do not wait for one national AI rulebook: inventory high-impact systems now and preserve the risk assessments, incident records, security decisions, and independent evidence that emerging frameworks repeatedly ask for.

Update — August 13, 2026: This article no longer describes state and federal policy as simple convergence. It now distinguishes California law, the White House AI Action Plan, NIST’s technical work, and OpenAI’s policy proposal, then turns those layers into an evidence-retention plan.

OpenAI is urging the United States to build a national frontier-AI safety framework from requirements emerging in individual states. In a July 15 policy essay, the company called the approach “reverse federalism”: states test workable rules, their common elements become a federal baseline, and federal expertise handles national-security evaluations that states cannot easily duplicate.

That is OpenAI’s policy position, not a description of a completed national system. Congress has not produced the single framework the company is requesting. Still, California’s enacted law and the federal government’s existing evaluation work make the proposal useful as an early map of the evidence advanced-AI developers may increasingly be expected to produce.

The common controls matter more than the slogan

OpenAI identifies recurring elements in state approaches: a documented safety framework, risk assessments and public disclosures, reporting of serious incidents, and objective or independent audits. It also supports security standards and whistleblower protections while arguing that state requirements should stay focused on frontier-model risks.

California already provides a concrete reference point. Governor Gavin Newsom signed SB 53, the Transparency in Frontier Artificial Intelligence Act, in September 2025. The official summary says the law requires large frontier developers to publish a framework, creates a channel for reporting critical safety incidents, protects qualifying whistleblowers, and permits civil penalties for noncompliance.

The federal layer is real, but it is still developing

At the federal level, the Center for AI Standards and Innovation at NIST says it serves as the government’s main industry contact for testing and collaborative research on commercial AI systems. Its remit includes voluntary standards, evaluations of capabilities that may create national-security risks, and coordination with other federal agencies.

That supports one part of OpenAI’s argument: specialized cyber, biological, chemical, and national-security testing benefits from a central technical institution. It does not mean CAISI currently certifies every model or that its voluntary guidance automatically becomes a legal requirement. Teams should track the difference between a law, a draft guideline, an evaluation program, and a vendor commitment.

Federal and state policy can overlap without agreeing

The White House AI Action Plan is a federal policy roadmap, not a comprehensive AI safety statute. It calls for stronger evaluation science, secure-by-design systems, incident-response capacity, and national-security testing. It also directs federal agencies to scrutinize state rules that the administration considers burdensome while acknowledging that states can pass prudent laws. That is tension, not a settled division of responsibility.

California SB 53 is an enacted state law aimed at large frontier developers. CAISI guidance and evaluation programs can inform practice without creating the same legal duty. OpenAI’s essay is an interested company’s proposal. A compliance record should label each source by authority and applicability instead of blending all four into a generic “US requirement.”

  • Law or regulation: identify jurisdiction, covered entity, effective date, and enforceable duty.
  • Government policy: identify the agency action it directs and whether implementation exists.
  • Voluntary standard or draft guidance: record version, status, and how the team chose to use it.
  • Vendor commitment or proposal: retain it as evidence of product governance, not as governing law.

What an AI team can prepare now

Most organizations do not train frontier models, so SB 53 may not apply to them directly. But the same evidence is valuable when buying, adapting, or deploying high-impact AI. Start with a system inventory: owner, model and version, data sources, connected tools, affected users, failure modes, and the person authorized to stop deployment.

Then connect each material risk to a test, a decision, and a retained record. A polished principles page is weak evidence if nobody can show what was evaluated, which incident threshold was used, or how a reported problem changed the system. The practical direction of travel is from broad promises toward traceable controls.

  • Keep dated risk assessments and evaluation results for material releases.
  • Define a serious-incident threshold, reporting route, owner, and response clock.
  • Record model, prompt, data, permission, and tool changes that alter exposure.
  • Use an independent reviewer for the highest-impact claims and controls.
  • Protect internal escalation and document why deployment continues after a known risk.

Build one evidence register, then map obligations to it

Create an evidence register for each material AI system rather than a separate folder for every new policy announcement. For each record, name the system version, owner, date, decision, supporting test, affected users, applicable jurisdiction, and retention period. Link an incident or exception back to the exact control and deployment version it changed.

This does not replace legal analysis. It reduces the operational cost of answering a lawyer, customer, auditor, or executive with the same underlying evidence. Recheck applicability when the model, connected tools, deployment geography, intended use, or provider terms change.

  • System inventory and intended-use statement.
  • Dated risk assessment and evaluation protocol.
  • Security review for data, credentials, tools, and external actions.
  • Incident criteria, reports, remediation, and notification decisions.
  • Independent review evidence where the risk or claim justifies it.
  • Approval, exception, stop authority, and next review date.
Sources and reporting notes

This article explains the practical implications of the primary material below. PatchMemo does not publish vendor copy as editorial coverage and does not accept payment for positive coverage.

Editorial independence

PatchMemo independently selects and evaluates the topics it covers. Analysis and recommendations are ours; sources are linked so readers can check the underlying claims. We clearly label sponsorships and affiliate relationships, and neither determines coverage or conclusions.