How should AI companies approach internal use reporting under SB 53? An explainer for technical staff

Summary

Technical staff at AI companies can influence employer compliance with California’s internal use reporting requirements under the Transparency in Frontier Artificial Intelligence Act, commonly referred to as SB 53. Their market position allows them to make demands of their employers, and their insider status means they’re uniquely well-positioned to assess the accuracy of their employer’s reporting.

When it comes to compliance with SB 53, technical staff can: 

1. Encourage their employers to make binding commitments in their required safety frameworks to share the detailed results of internal use assessments with CA officials.
2. Make sure their employers’ reporting meets baseline standards for mandatory internal use reporting.
3. Ask their employers to adopt any voluntary reporting template provided by CA officials.
4. Press their employers to disclose any underlying documents or data relevant to fully understanding their internal use reports.
5. Call on their employers to develop a process to certify the accuracy of their reports.

Technical staff can also encourage their employers to proactively engage in reporting serious incidents to CA officials, to supplement what’s legally required under SB 53.

If you have any feedback on this explainer, we invite you to submit comments.

Introduction

Technical experts at AI labs are vital to the success of SB 53. Given their highly in-demand expertise and their internal knowledge of the AI companies where they work, they have a unique ability to ensure that compliance with the law is optimized for the public’s benefit.

This explainer focuses on large frontier developers’ obligation to report “a summary of any assessment of catastrophic risk resulting from internal use of its frontier models” to Cal OES, the state agency primarily responsible for implementing SB 53’s requirements.^1[1] This requirement is motivated by the distinctive risks that internal use poses, especially as AI R&D becomes increasingly automated. However, SB 53 imposes only minimal requirements on AI labs—most notably, it doesn’t establish any minimum safety standards for their frontier AI frameworks, or specify any criteria that must be addressed in internal use reports.

Below are five different actions technical staff at AI labs can take to encourage proactive and meaningful compliance with SB 53’s internal use assessment provisions. This explainer concludes with a few recommendations for how to enhance SB 53 incident reporting as well.

Finally, while this explainer doesn’t cover SB 53’s special whistleblower protections or other whistleblower protections that exist under California law, you should know that those may apply in some circumstances to protect certain disclosures.^2[2] Please note that this is not legal advice, and that you should consult an attorney before making a disclosure to determine whether legal protections apply.^3[3]

1. Encourage companies to commit to sharing detailed results of internal use assessments with Cal OES as part of their Frontier AI Frameworks, so that those commitments are binding.

When AI companies make commitments in their required frontier AI frameworks under SB 53, those commitments become binding, meaning companies can’t ignore or deviate from them without updating the framework itself.^4[4] 

SB 53 is silent on what companies need to include in a “summary of any assessment” of internal use risk. But you can help ensure that useful information is consistently reported to Cal OES by encouraging your employer to commit in its frameworks to providing substantial, detailed reports about internal use assessments.

Without such binding commitments, companies’ reports may be vague and only minimally informative, which would satisfy the letter but not the purpose of SB 53.

In addition to encouraging your employer to make those binding commitments, you can also help identify the assessment and reporting criteria that would be most helpful to Cal OES. Among some of the possible criteria:

• The ways in which the internal model or system differs from the developer’s most capable publicly deployed model, including the marginal increase in catastrophic risk created by internal use, relative to risk posed by current publicly available models;
• Any expectations about where capabilities are headed in the next 6-12 months;
• The approximate share of experimental, training, and inference compute used for AI-assisted or AI-directed R&D, as well as any evidence of faster development cycles or effective compute gains;
• The system permissions available to the internal model or agent, including internet access, code execution, credentials, internal files (including model weights), internal systems, communications with humans or other agents, persistence, logging, human approval gates, and shutdown permissions;
• Any evidence about evaluation awareness, deception, and sandbagging, including any discrepancy between evaluation behavior and behavior in more realistic internal use settings, as well as information about the types of evaluations conducted prior to internal deployment; and
• Any internal near misses or concerning behaviors or patterns that triggered escalation, retraining, or further investigation, as well as information about the specific mitigations applied to internal use to reduce risk.

Moreover, you can urge your employer to commit to conducting internal use assessments frequently. SB 53 requires companies to report on “any” qualifying assessment that’s actually performed. So if companies carry out more assessments, more information will flow to Cal OES to improve its awareness and operations. Likewise, you can ask your employer to commit to providing internal use reports to Cal OES more often than the default of every three months established by SB 53,^5[5] e.g., within 30 days of completing any qualifying assessment. That would also increase the flow of timely information to Cal OES.^6[6]

2. Know that, even if companies do not commit to detailed internal use reporting in their frameworks, technical staff can still help ensure their employers meet the mandatory reporting baseline.

SB 53 requires major AI labs to provide “a summary of any assessment of catastrophic risk resulting from internal use of its frontier models,” every three months or pursuant to another reasonable schedule.^7[7] So if there’s any assessment of catastrophic risk from internal use of frontier models—whether performed by a lab or a third-party evaluator—a summary of that assessment must be provided to Cal OES.

In other words, the trigger for mandatory internal use reporting under SB 53 is not limited to situations where a company has committed itself to doing an assessment under its framework. Rather, mandatory reporting is required whenever a company or other evaluator actually conducts a qualifying assessment, whether it was required to or not.^8[8]

You can ask your employer to confirm that qualifying internal use assessments have been reported to Cal OES, or even ask to review or be involved in the process of drafting the required summaries of assessments to ensure technical accuracy and completeness. As technical staff, you’ll likely have much greater awareness than Cal OES or other outside observers about when labs are conducting qualifying assessments, positioning you as a powerful backstop.

3. Ask companies to adopt any voluntary template that Cal OES may provide for internal use reports.

SB 53 lacks guidance about the details that internal use reports should or must contain. Without coordination from Cal OES, companies’ reports will likely differ from one another and may not consistently surface the most relevant facts and upshots for Cal OES. Because of that, Cal OES may publish a template for internal use reports or endorse a reporting rubric developed externally. 

Such a template would ideally focus on the highest-value data points on internal use (perhaps expanding on the list in section 1 above), with the added benefit that the standardized format would make it easier for Cal OES to compare and contrast results. While Cal OES might encourage companies to use the template to structure their reports, it likely can’t require them to use it due to legal constraints.

If Cal OES does publish or endorse a voluntary template for internal use reports, you should encourage your employer to adopt it. You might also look for ways to provide feedback on the template itself, helping Cal OES improve its information gathering. More generally, you can encourage your employer to engage constructively with Cal OES in developing templates or best practices.

4. Press companies to voluntarily disclose to Cal OES any underlying materials needed to fully understand their internal use risk assessments.

Under SB 53, a company is required to provide Cal OES only with a “summary” of any assessment of catastrophic risk resulting from internal use of its frontier models, but not with the underlying assessment materials themselves.^9[9] As a result, reports may end up being vague or omit critical information that Cal OES needs to fully understand the risk posed by an internal system.^10[10]

You can encourage your employer to provide underlying assessment materials to Cal OES whenever possible, particularly where such materials are necessary for Cal OES to have a full picture of the risk or uncertainty presented by an internal system. In so doing, you can cite SB 53’s confidentiality protections to assuage employer concerns about sharing sensitive information.^11[11]

More broadly, you can urge your employer to share the information and materials it reports to Cal OES with trusted third-party experts like METR. Those third parties could provide essential support in evaluating assessment results and advising on how to manage internal use risks, particularly as Cal OES works to build out those functions at this early stage of administering SB 53. You can also ask your employer to share certain information with the public, including redacted versions of internal use reports, so that a wider range of experts, policymakers, and citizens can both remain aware of how internal use risks are evolving, and potentially contribute to efforts to understand and mitigate those risks.

5. Call on companies to voluntarily establish a procedure for certification of internal use submissions.

SB 53 does not require labs to formally certify the accuracy or completeness of their internal use reports, though it does prohibit them from making “materially false or misleading statement[s] about catastrophic risk . . . or [their] management of catastrophic risk.”^12[12] That prohibition against false statements applies to internal use reports, because they address catastrophic risk resulting from internal use of frontier models.^13[13]

You could ask your employer to establish an internal process where a member of technical staff has to validate an internal use report before it’s submitted to Cal OES. This might be someone who led or worked on an assessment and has the necessary expertise to attest to the accuracy and completeness of the summary of that assessment.

It would be up to companies whether to establish this review and validation process. But it’s a prudent way to ensure that they don’t run afoul of SB 53’s prohibition against false statements and could improve the quality of information submitted to Cal OES.

A note on SB 53 incident reporting

Recent cybersecurity breaches, such as the breach of Hugging Face by a pre-release model from OpenAI and a less-safeguarded version of GPT 5.6 Sol, demonstrate how internal use assessments can also potentially implicate “critical safety incidents” under SB 53.^14[14]

Critical safety incidents trigger their own reporting requirements to Cal OES under SB 53,^15[15] though it’s worth noting that the bar for mandatory reporting of incidents is high. Depending on the incident type, it must have resulted in “death or bodily injury”; “materialization of a catastrophic risk” (i.e., death or serious injury of more than 50 people, or more than one billion dollars in damage to or loss of property); or, at minimum, a “materially increased catastrophic risk.”^16[16] Short of that, labs aren’t required to report incidents to Cal OES.

Under that definition, the Hugging Face breach likely did not qualify as a “critical safety incident.” Even if it did qualify, the information that SB 53 requires in a report is very minimal: the date of the incident, the reasons it qualifies as an incident, a short and plain statement describing the incident, and whether the incident was associated with internal use of a frontier model.^17[17] Developers aren’t required to provide logs or other underlying data with their reports.

However, you can encourage your employer to provide additional information to Cal OES on a voluntary basis, increasing its awareness and understanding of emerging capabilities and risks, and augmenting its ability to respond to future incidents. 

With respect to incidents, you should urge your employer:

• To respond fully to both mandatory and voluntary questions posed by Cal OES on its incident reporting form or in other communications.
• To voluntarily report near misses to Cal OES, as well as trusted third-party experts (and for large frontier developers, to commit to near-miss reporting in their binding frameworks).
• To voluntarily provide underlying artifacts and other incident-related materials to Cal OES so it has a full picture of the risk, harm, or uncertainty surrounding an incident, as well as providing such materials to trusted third-party experts.
• To involve technical staff in the process of reporting incidents to Cal OES, such as by voluntarily establishing an internal process where technical staff has to validate incident reports before they’re submitted to Cal OES.
• To provide redacted versions of incident reports, as well as other information regarding incidents and near misses, to the public, to increase awareness and build trust.

Finally, SB 53 also gives members of the public the ability to submit incident reports,^18[18] in addition to the special whistleblower protections it offers.^19[19]