If you train a model above a certain compute threshold and sell access to it in California, you now have to tell the public how you're managing the risk of it causing catastrophic harm. Not in a research paper, not in a blog post when it's convenient — in a disclosure filed on a schedule, reviewable by regulators, and subject to enforcement if you skip it. That's the practical effect of California's Transparency in Frontier AI Act, which took effect on January 1, 2026, and it marks the first time a US state has put binding transparency obligations on the companies building the largest AI models.
This isn't an AI ethics framework or a voluntary pledge. It's a statute with reporting deadlines, defined thresholds, and a state attorney general who can bring civil penalties. Colorado has its own AI Act arriving on a parallel track, with obligations that start hitting deployers on June 30, 2026. Together, these two laws are the clearest signal yet that "trust us, we have an internal safety team" is no longer going to be an acceptable answer to how frontier models get built and released.
This piece walks through what these laws actually require, who they apply to, why they emerged now, and what both AI developers and the businesses that build on top of their models need to do differently.
What "Frontier AI Transparency" Actually Means
Frontier AI transparency laws are a distinct category of AI regulation. They don't tell you what your model can or can't do, and they don't require pre-approval before you release something. Instead, they require developers of the most capable models to publicly document their safety practices — and to report certain incidents when things go wrong.
The core mechanics tend to look similar across jurisdictions, even when the specific thresholds differ:
- A compute or capability threshold that defines which models count as "frontier" and trigger the law's obligations — typically tied to the amount of computing power used in training, sometimes combined with revenue or deployment scale of the company.
- A published safety framework — a document describing how the company identifies, assesses, and mitigates catastrophic risks (think: models that could meaningfully assist in creating biological, chemical, nuclear, or cyber weapons, or that could act autonomously in harmful ways).
- Incident reporting — a requirement to notify a state agency, sometimes within a fixed number of days, when a "safety incident" occurs, such as a model exhibiting unexpected dangerous capabilities or being involved in a real-world harm event.
- Whistleblower protections — provisions shielding employees who raise safety concerns internally or externally from retaliation.
- Enforcement teeth — usually civil penalties enforced by the state attorney general rather than a private right of action, which keeps the compliance burden focused on large developers rather than opening the door to mass litigation.
What these laws deliberately don't do is dictate model behavior, mandate specific safety techniques, or require pre-market licensing. They're disclosure regimes, not approval regimes. The theory behind that design choice is that if you force the handful of companies training the largest models to say publicly what risks they've identified and how they're addressing them, market and reputational pressure — plus regulatory scrutiny — will do more to shape behavior than a rigid technical mandate that goes stale the moment model architectures change.
Why This Is Happening Now
California's Transparency in Frontier AI Act (often referred to by its bill number, SB 53) took effect January 1, 2026. It followed an earlier, more aggressive bill — SB 1047 — that Governor Newsom vetoed in 2024 after intense pushback from the AI industry over provisions seen as too prescriptive, including a "kill switch" requirement and expansive liability. SB 53 is the narrower, disclosure-focused successor that industry groups were more willing to live with, and it's the one that actually became law.
Colorado took a different route. Its AI Act focuses less narrowly on frontier model developers and more broadly on "high-risk" AI systems used in consequential decisions — employment, housing, credit, healthcare — with obligations falling on both developers and deployers of those systems. Its effective date, originally set for February 2026, has been the subject of legislative delay efforts, with June 30, 2026 emerging as the date frequently cited for deployer obligations to begin. The Colorado law reflects a different regulatory instinct: rather than targeting the biggest models by compute, it targets AI systems by the consequences of their use, regardless of which company built the underlying model.
The reason both laws matter simultaneously is that they represent two competing philosophies for regulating AI that are likely to keep coexisting rather than converging:
| Approach | Trigger | Primary obligation | Example |
|---|---|---|---|
| Frontier-model transparency | Compute/capability threshold | Publish safety framework, report incidents | California SB 53 |
| Consequential-use regulation | Deployment context (hiring, credit, etc.) | Risk assessments, impact documentation | Colorado AI Act |
| EU-style tiered risk regulation | Risk category of the system | Conformity assessments, CE-marking-style compliance | EU AI Act |
No comprehensive federal AI law exists in the US as of this writing, which is precisely why state legislatures have moved first — and why companies operating nationally now have to track a patchwork rather than a single rulebook. That patchwork dynamic is familiar to anyone who has dealt with US privacy law post-CCPA: individual states set the bar, and companies operating nationally end up complying with the strictest state's rules as a practical default, because building fifty different compliance postures isn't worth the marginal savings of a laxer standard elsewhere.
What Model Developers Must Actually Disclose
For a company whose models cross the relevant threshold, the disclosure obligations under a law like California's break down into a few concrete deliverables rather than vague principles.
The safety framework
Developers must publish a document — typically on their website — describing their approach to identifying and mitigating catastrophic risk. This isn't a marketing page. It needs to cover things like:
- How the company defines and categorizes catastrophic risk for its models.
- What testing and evaluation processes it runs before releasing a new model (red-teaming, third-party evaluations, capability testing for dangerous domains).
- What mitigations it applies if a model is found to have concerning capabilities.
- How the framework itself gets reviewed and updated over time.
Transparency reports at release
Alongside major model releases, developers are expected to publish transparency reporting that summarizes what evaluations were performed and what the results showed — enough for outside researchers and regulators to understand the basis for the release decision, without necessarily disclosing proprietary training details or creating a roadmap for misuse.
Incident reporting
If a "critical safety incident" occurs — language that generally covers things like a model providing substantial uplift toward creating weapons capable of mass casualties, a model acting autonomously to cause serious harm, or a model evading the control of its developer in a dangerous way — the company has to report it to the relevant state authority within a defined window, often measured in days rather than weeks.
Whistleblower channels
Companies have to establish and disclose an internal reporting mechanism for employees who have safety concerns, and they're barred from retaliating against employees who raise those concerns either internally or to a regulator.
The common thread is that none of this requires a developer to change how it builds models. It requires them to document and publish what they're already supposed to be doing internally — which is exactly the point. The law is a bet that most of the compliance cost is administrative, not technical, for companies with mature safety practices, and a real cost for companies that have been treating safety as an afterthought.
Why It Matters Right Now
The "why now" here isn't abstract policy momentum — it's a concrete compliance deadline that already passed. California's Transparency in Frontier AI Act took effect January 1, 2026, which means any company whose models meet the compute threshold and that makes those models available to California users is already operating under this law, not preparing for it. Colorado's AI Act adds a second, broader layer on top, with obligations for deployers converging around June 30, 2026.
That timing compresses what used to be a multi-year runway into something companies are dealing with in real time. A few things follow from that:
- Legal and compliance teams at AI labs are no longer treating this as future work. Safety framework publication, incident-reporting infrastructure, and whistleblower policy updates needed to be operational before January 1, 2026 — not drafted afterward.
- "Frontier" thresholds create a bright line that shapes competitive behavior. Companies close to the compute threshold have an incentive to understand exactly where it sits, because crossing it triggers a meaningfully different compliance posture.
- Multi-state compliance is now a design constraint, not a hypothetical. A company building AI products has to reason about California's disclosure regime and Colorado's risk-assessment regime simultaneously, alongside whatever the EU AI Act requires if they operate internationally.
- The absence of federal preemption means this list of states will grow. Once California and Colorado have working statutes, other state legislatures have a template to borrow from, and several have introduced similar bills.
For businesses that don't build frontier models themselves but build products on top of APIs from companies that do, this still matters — because the transparency reports and safety frameworks these laws produce are becoming a new category of vendor due diligence material. A company evaluating which model provider to build on can now, at least in principle, read a provider's published safety framework and incident history the way they might read a SOC 2 report today.
Practical Implications for Businesses and Builders
The direct legal obligations fall on developers who cross the frontier compute threshold — a short list of companies training the largest models. But the second-order effects reach much further, into any organization building products with AI or selecting AI vendors.
If you're a frontier-scale developer
Compliance means building durable infrastructure, not a one-time document:
- Establish a process for tracking your training compute against the statutory threshold, because crossing it changes your obligations going forward, including for models already in production.
- Stand up an incident-classification and reporting pipeline before you need it — the reporting windows in these laws are generally too short to build the process after an incident occurs.
- Treat the safety framework as a living document with version history, not a PDF published once and forgotten.
- Coordinate legal, safety, and communications teams on what gets disclosed publicly versus what stays internal, since transparency reports are read by competitors, researchers, and regulators simultaneously.
If you're building on top of frontier models
You're not directly regulated by California's transparency law in most cases, but you should still adjust:
- Add "read the vendor's published safety framework" to your model-selection and vendor-review checklist, the same way you'd check a cloud provider's security certifications.
- Watch Colorado's AI Act closely if you deploy AI in hiring, lending, insurance, housing, or healthcare decisions — that law's obligations fall on deployers, not just developers, and the bar is about your use case, not your model choice.
- Build contractual language into vendor agreements that requires notification if a model you depend on is involved in a reported safety incident.
- Don't assume a smaller or open-source model is exempt from all obligations just because it wasn't trained by a frontier-scale lab — some state proposals extend obligations based on how a model is deployed, not only how it was trained.
A quick self-check
| Question | If yes |
|---|---|
| Did you train a model above the California compute threshold? | You likely need a published safety framework and incident-reporting process. |
| Do you deploy AI in hiring, credit, housing, or healthcare decisions in Colorado? | You likely have deployer obligations under the Colorado AI Act. |
| Do you build products on third-party frontier models? | Add vendor safety-disclosure review to procurement; monitor incident reports. |
| Do you operate only in states without AI-specific transparency laws — for now? | Track legislative activity; the list of states is expanding. |
Limitations and Open Questions
These laws are new enough that several important questions don't have settled answers yet.
Enforcement is largely untested. A statute with civil penalties only matters if the enforcing authority actually investigates and penalizes noncompliance. California's attorney general has broad discretion in how aggressively to pursue this, and it will likely take a real incident or a high-profile gap in disclosure before we see how enforcement actually plays out in practice.
The compute threshold is a blunt instrument. Defining "frontier" by training compute made sense when capability tracked compute fairly closely, but techniques that squeeze more capability out of less compute — distillation, more efficient architectures, better data curation — mean a model could plausibly pose frontier-level risks without crossing a compute-based threshold, or vice versa. Lawmakers wrote these thresholds knowing they'd need revisiting.
Disclosure doesn't equal safety. A company can fully comply with a transparency law by publishing a thorough, well-written safety framework and still ship a model with real risks, if its actual internal practices are weaker than what the document describes. These laws create a paper trail and a whistleblower incentive structure to catch that gap, but they don't independently verify that disclosed practices are being followed.
The patchwork problem has no near-term fix. With Colorado, California, and likely additional states developing their own frameworks on different timelines with different definitions of "frontier" or "high-risk," companies face a genuine compliance complexity cost — and there's no indication Congress is close to passing preemptive federal legislation that would replace the patchwork with a single standard.
International alignment is loose at best. The EU AI Act uses a different risk-tiering structure altogether, and jurisdictions like the UK have leaned toward voluntary commitments over binding statute. A frontier lab operating globally is reconciling several materially different transparency regimes, not implementing one law with local variations.
What to Watch Next
A few developments will shape how much this area of law matters over the next year or two:
- How California's attorney general handles the first enforcement actions or investigations — this will set the real bar for what "adequate" disclosure looks like in practice, beyond the statutory text.
- Whether other states introduce similar frontier-transparency bills in their next legislative sessions, and whether any converge on shared definitions with California's thresholds.
- How the Colorado AI Act's effective date and scope evolve — it has already seen delay and amendment activity, and deployer-side obligations tend to generate more pushback than developer-side disclosure requirements.
- Whether Congress makes another serious attempt at federal AI legislation that would preempt the state patchwork, following prior attempts that stalled.
- How the published safety frameworks from major labs compare to each other once a full disclosure cycle has run — early transparency reports will likely vary widely in depth and specificity, and that gap itself will become a talking point.
FAQ
What is the California Transparency in Frontier AI Act?
It's a state law, often referred to by its bill number SB 53, that took effect January 1, 2026, requiring developers of frontier-scale AI models to publish safety frameworks, report critical safety incidents to the state, and protect employee whistleblowers who raise safety concerns.
Which companies does the frontier AI transparency law apply to?
It applies to developers whose models exceed a defined training-compute threshold and who make those models available to users in California. This generally covers a small number of the largest AI labs rather than most companies building AI products.
How is this different from the Colorado AI Act?
California's law targets frontier model developers based on compute scale and focuses on disclosure. Colorado's AI Act targets "high-risk" AI systems based on how they're used — in hiring, credit, housing, or healthcare decisions — and places obligations on both developers and deployers of those systems.
Does frontier AI transparency law require pre-approval before releasing a model?
No. These are disclosure regimes, not licensing regimes. Developers don't need government sign-off before releasing a model; they need to publish their safety practices and report specified incidents after the fact.
What counts as a reportable safety incident?
Definitions vary by statute, but they generally cover events like a model providing substantial assistance toward creating weapons capable of mass casualties, a model acting autonomously to cause serious harm, or a model evading its developer's intended controls in a dangerous way.
Do these laws affect companies that just use AI models, not build them?
Directly, usually not — the disclosure obligations fall on model developers. Indirectly, yes: businesses deploying AI in regulated contexts (like Colorado's high-risk use cases) can have their own obligations, and vendor due diligence increasingly includes reviewing a model provider's published safety disclosures.
Is there a federal AI transparency law in the US?
Not as of this writing. Regulation has moved forward at the state level, with California and Colorado as the most developed examples, creating a multi-state patchwork that companies operating nationally need to track individually until or unless federal legislation is passed.
Teams navigating this patchwork of AI transparency and compliance obligations while shipping actual products can get hands-on help from Woyce Technologies.