When California’s frontier-AI transparency law took effect on January 1, 2026, publishing a safety framework became a legal obligation for qualifying large developers. But publication was only part of the requirement. The developer also had to implement and comply with the framework.
That difference is the important part of SB53. A document can describe careful testing and restrictions on deployment. Whether those procedures governed the release of a model is a separate question.
The law connects the two. It makes the developer’s stated approach to catastrophic risk a basis for examining what the developer actually did.
The Law Starts With a Defined Group of Developers
Governor Gavin Newsom signed SB53 on September 29, 2025. The Transparency in Frontier Artificial Intelligence Act targets advanced general-purpose models and their developers. It does not impose its framework requirement on every organization using AI.
Under the enacted definitions, a frontier model crosses a training-compute threshold of more than 10²⁶ operations. A large frontier developer also exceeds $500 million in annual gross revenue, together with its affiliates, in the preceding calendar year. Different duties apply to frontier developers and large frontier developers.
This scope matters. A hospital buying an AI application does not become a large frontier developer simply because the application influences important decisions. And a framework addressing catastrophic model risks does not, by itself, establish that a particular clinical or administrative use is safe.
Publication Makes the Approach Visible
The California Attorney General explains that the framework must describe how the developer defines and assesses the thresholds it uses to identify capabilities that could pose a catastrophic risk, applies mitigations, handles critical safety incidents, and manages risks from internal use. The required account also addresses standards and best practices.
This gives readers something more concrete than an assurance that the developer takes safety seriously. They can examine the approach it says it uses.
The public document is still not a certificate of safety. A reader needs to distinguish a described method from evidence that it was followed and evidence that it was effective. Those are related questions, but they require different support.
Compliance Makes the Approach Consequential
Section 22757.12 requires large frontier developers to write, implement, comply with, and publish their frameworks. The same section also requires a transparency report at or before the deployment of a new or substantially modified frontier model, and a summary of any internal-use catastrophic-risk assessment submitted to the Office of Emergency Services every three months by default. Section 22757.15 expressly identifies failure to follow one’s own framework as grounds for an Attorney General civil action against a large frontier developer, with penalties up to $1 million per violation. See the enacted provisions.
Consider a hypothetical developer whose framework requires a further evaluation when testing reveals a specified dangerous capability. The model reaches that threshold, but the team releases it without performing the promised evaluation.
The useful compliance question is specific: did the developer perform the evaluation its framework required? It is not answered by pointing to the framework’s publication date or the length of its safety section.
This is an illustration, not an allegation about any developer. It shows why records of testing and deployment decisions matter. They allow an organization to compare the process it committed to with the process it followed.
A Serious Incident Raises a Separate Reporting Question
SB53 requires frontier developers to report defined critical safety incidents to the Office of Emergency Services within 15 days of discovery. An imminent risk of death or serious physical injury requires disclosure within 24 hours to an authority, including a law enforcement or public safety agency. These duties turn on statutory incident definitions, not every inaccurate or undesirable output. The reporting duty binds frontier developers generally, while the civil penalty for a reporting failure reaches only large frontier developers. See section 22757.13.
Reporting an incident does not establish that the developer failed to follow its framework. A risk can materialize despite compliance. Conversely, a missed procedure need not produce a catastrophe before the failure to follow the framework matters.
The reporting obligation serves another purpose: it brings specified evidence of serious problems outside the developer. The government can learn about a qualifying event even when its causes and implications are still being examined.
Information Must Also Be Able to Leave Through Employees
The Attorney General’s SB53 guidance explains protections for specified employees responsible for assessing or managing critical safety risks. Developers cannot prevent protected disclosures or retaliate against covered employees who report qualifying dangers or violations to designated recipients. Those protections sit in Labor Code sections 1107 and 1107.1, not in the Business and Professions Code sections above.
That addresses a different source of information. An organization’s official report and an employee’s concern do not necessarily describe the same event in the same way. Protected reporting helps prevent the organization’s preferred account from becoming the only account available. Section 22757.14 also directs the Attorney General to publish an annual anonymized, aggregated report on covered-employee reports, beginning in 2027.
The existence of a disclosure does not establish that its contents are correct. Its value is that evidence can reach someone able to examine it, rather than being suppressed because it challenges a release decision or a public assurance.
