Frontier AI Transparency Laws: What Model Developers Must Disclose

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), the same category of risk AI safety institutes were set up to study.
• 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:

No comprehensive federal AI law exists in the US as of this writing, which is precisely why state legislatures have moved first, adding to an already fragmented picture of global AI regulation — 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:

1. How the company defines and categorizes catastrophic risk for its models.
2. What testing and evaluation processes it runs before releasing a new model (red-teaming, third-party evaluations, capability testing for dangerous domains).
3. What mitigations it applies if a model is found to have concerning capabilities.
4. 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 — a dynamic closely tied to broader debates over compute governance.
• 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.

Benefits of Frontier AI Transparency Laws

Disclosure regimes are sometimes dismissed as paperwork. In practice they create several things that did not reliably exist before, for the public and for businesses alike.

Public visibility into how labs manage serious risk

Before these laws, what a lab did to test for dangerous capabilities was disclosed when and how the lab chose. A required, published safety framework means anyone can read how a developer defines catastrophic risk, what it tests for, and what it does when a threshold is crossed. That does not prove the practices are followed, but it creates a public baseline against which behaviour can be compared, and it makes vague or missing commitments visible.

New due diligence material for buyers

Companies choosing a model provider used to rely on marketing pages and sales conversations for anything about safety. Published frameworks, release-time transparency reports, and incident disclosures give procurement and risk teams documents they can read, compare, and cite. That turns model selection into something closer to a standard vendor review, with a written basis for choosing one provider over another.

An early-warning channel for regulators

Mandatory incident reporting, with short windows, means a state authority hears about serious events from the developer rather than from the press months later. Regulators gain a running picture of what kinds of incidents occur and how often. That information is what future rules, and future enforcement priorities, can be built on, instead of speculation about risks nobody has documented.

Protection for people who raise concerns

Whistleblower provisions shield employees who report safety problems internally or to a regulator. Inside a lab, the people closest to a model's behaviour are often the first to see a problem. Legal protection makes it more likely that concerns surface, and the requirement to disclose an internal reporting channel makes it harder for that channel to exist only on paper.

Oversight without a licensing bottleneck

Because these are disclosure regimes rather than approval regimes, developers do not need government sign-off before each release, and the laws do not prescribe specific safety techniques. That keeps the administrative burden concentrated on the small number of companies above the threshold, avoids slowing down the much larger set of firms building applications, and leaves room for safety methods to evolve faster than statute could.

Frontier AI Transparency Law Use Cases

The laws regulate a short list of developers, but the documents they produce are already being put to work by a much wider group. These are the main ways the disclosures get used.

Model selection and vendor review

A company deciding which model to build a customer-facing product on can add the provider's safety framework and transparency reports to its evaluation. Reviewers check whether the documents cover the specific model version, whether they name risk categories and evaluation methods, and how often they are updated. The outcome is a documented rationale for the choice that a risk committee or customer can inspect later.

Contract terms with model providers

Procurement and legal teams are using the existence of incident reporting to ask for something concrete in return: notification if a model they depend on is involved in a reported safety incident, and advance notice of deprecations or major behaviour changes. Writing those terms into agreements turns a public obligation on the developer into a private commitment to the customer, with a clear trigger for review.

Internal governance at frontier developers

For labs above the threshold, the safety framework becomes a governing document. Boards and leadership teams use it to decide what evaluations must pass before release and who can approve exceptions. Versioning the framework and tying release decisions to it gives the organisation an auditable record of how each release was justified, which matters when the attorney general or an internal whistleblower asks.

Deployer risk programmes under consequential-use laws

Businesses using AI in hiring, lending, housing, insurance, or healthcare decisions in Colorado have their own obligations, and supplier documentation feeds directly into their risk assessments. A deployer can reference the developer's published limitations and evaluation results when documenting why a system is fit for its intended use, and update that assessment when the developer publishes new material.

Research and public accountability

Researchers, journalists, and civil society groups compare published frameworks across labs and track whether stated practices match observed behaviour. Early comparisons are likely to show wide variation in depth and specificity. That comparative scrutiny is part of the theory behind disclosure laws: public, side-by-side reading puts pressure on weaker frameworks without a regulator having to prescribe what good looks like.

Frontier AI Transparency Law Best Practices

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, which is pushing many legal teams toward AI compliance automation rather than manual tracking.
• 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 — part of closing the kind of shadow AI governance gaps that unreviewed vendor tools tend to create.
• 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

How to Review a Model Provider's Safety Disclosures

For most businesses, the practical use of these laws is as a new input to vendor selection. A published safety framework only helps if someone actually reads it with a purpose. A simple review process:

1. Find the documents. Locate the provider's current safety framework, the transparency report or system card for the specific model version you use, and any published incident disclosures.
2. Check scope and version. Confirm the documents cover the model you're actually calling, not just an earlier or larger sibling.
3. Look for specifics, not principles. Strong frameworks name the risk categories they test for, describe evaluation methods, and state what happens when a threshold is crossed. Vague commitments without process detail are a weaker signal.
4. Note update cadence. A framework with version history and dated revisions suggests an active process; a single undated page suggests the opposite.
5. Map it to your use case. Catastrophic-risk disclosures matter, but you also need the provider's documentation on data handling, misuse policies, and known limitations relevant to your product.
6. Write it into the contract. Ask for notification if a model you depend on is involved in a reported safety incident, and for advance notice of model deprecations or major behavior changes.
7. Re-review on major releases. Treat this like any vendor review: repeat it when the provider ships a new model generation or materially updates its framework.

This won't replace your own testing, but it gives procurement and risk teams a documented basis for choosing one provider over another.

Common Frontier AI Transparency Law Mistakes

Assuming you are unaffected because you don't train frontier models

Most companies are right that California's frontier law does not apply to them directly. The mistake is stopping there. Colorado-style rules regulate how AI is used in consequential decisions, regardless of who built the model, and those obligations fall on deployers. A business using AI to screen applicants or price insurance can have real duties without ever training a model. Check use cases, not just model size.

Treating the safety framework as a one-time publication

Developers that publish a polished framework and then leave it untouched create a document that drifts away from actual practice with every new model generation. That gap is exactly what whistleblower provisions and outside comparison are designed to expose. Version the framework, date each revision, and tie updates to release decisions so the published document always describes the process actually in use.

Building the incident process after the first incident

Reporting windows are generally measured in days. A team that has not already defined what counts as a critical safety incident, who classifies it, and who files the report will spend those days arguing about definitions. Set up the classification criteria, escalation path, and reporting template in advance, and rehearse it with a simulated incident so gaps show up before they matter.

Reading a published framework as proof of safety

For buyers, a well-written framework is a useful signal, not a guarantee. Disclosure laws do not independently verify that stated practices are followed. Treat the documents as one input alongside your own testing, the provider's incident history, and contractual commitments. A vendor review that ends with "they published a framework" has not asked the questions that matter for your use case.

Assuming smaller or open models are exempt everywhere

A model trained below the California threshold, or released with open weights, is not automatically outside every rule. Some state proposals attach obligations to how a model is deployed rather than how it was trained, and consequential-use laws apply to the decision, not the model's origin. Teams that pick a smaller model partly to avoid regulation can find the deployment still carries obligations they did not plan for.

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.

Teams navigating this patchwork of AI transparency and compliance obligations while shipping actual products can get hands-on help from Woyce Technologies.

FAQ

What is the California Transparency in Frontier AI Act?

It's a California state law, often referred to by its bill number SB 53, that took effect January 1, 2026. It requires developers of frontier-scale AI models to publish a safety framework describing how they assess and mitigate catastrophic risks, issue transparency reporting around model releases, report critical safety incidents to the state, and protect employees who raise safety concerns. It is a disclosure law rather than a licensing regime, enforced through civil penalties brought by the state attorney general rather than private lawsuits.

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. In practice this covers a small number of the largest AI labs rather than most companies building AI products, and some obligations are scaled further by company size or revenue. Businesses that build applications on top of those labs' models through an API are generally not the regulated party, although they are affected indirectly through vendor due diligence and contracts.

How is this different from the Colorado AI Act?

California's law targets frontier model developers based on compute scale and focuses on disclosure of safety practices and incidents. Colorado's AI Act targets "high-risk" AI systems based on how they're used, such as in hiring, credit, housing, insurance, or healthcare decisions, and places obligations on both developers and deployers of those systems, including risk assessments and impact documentation. A company could be untouched by California's law but have significant obligations under Colorado's if it uses AI in consequential decisions about Colorado residents.

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, and the laws don't mandate specific safety techniques. What they require is that developers publish their safety practices, document the basis for release decisions, and report specified incidents within set time windows. The theory is that public scrutiny, whistleblower protections, and regulatory oversight will shape behavior more effectively than a technical rulebook that would quickly go out of date.

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, a model evading its developer's intended controls in a dangerous way, or unauthorized access to model weights that creates serious risk. Reporting windows are typically measured in days, which is why developers need an incident-classification process in place before anything happens rather than designing one afterward.

Do these laws affect companies that just use AI models, not build them?

Directly, usually not, because the disclosure obligations fall on frontier model developers. Indirectly, yes. Businesses deploying AI in regulated contexts, like Colorado's high-risk use cases, can have their own obligations regardless of which model they use. Vendor due diligence increasingly includes reviewing a model provider's published safety disclosures, and enterprise customers may ask you how you chose and monitor your providers. Contract terms around incident notification are becoming a standard part of AI vendor agreements.

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. Federal proposals have been introduced but have not passed, and the question of whether a federal law would preempt state rules remains politically contested. Until that changes, many companies treat the strictest applicable state requirements as their practical baseline.

How should a business prepare for AI transparency laws?

Start by working out which category you fall into: frontier developer, deployer of AI in consequential decisions, or builder on third-party models. Frontier developers need a published framework, incident pipeline, and whistleblower process. Deployers in sensitive areas should inventory those uses and prepare risk assessments. Everyone else should add provider safety-disclosure review and incident-notification clauses to procurement. Track legislative activity in the states where you operate, since new bills often borrow from California and Colorado.

Conclusion

Frontier AI transparency laws change the default from "trust us" to "show us." California now requires the largest model developers to publish safety frameworks, report critical incidents, and protect whistleblowers, while Colorado regulates AI by the consequences of its use in areas like hiring, credit, and healthcare. Together they mark the start of binding AI oversight in the US, built state by state.

The key insight is that the two laws reach different people. Very few companies train models large enough to fall under California's regime, but many deploy AI in decisions that Colorado-style rules cover, and almost every company building on third-party models now has new disclosure material to use in vendor reviews and contracts.

The caveats are significant. Enforcement is largely untested, compute thresholds are an imperfect proxy for risk, disclosure is not the same as safety, and the state-by-state patchwork shows no sign of being replaced by a federal standard soon. This overview isn't legal advice, and specific obligations should be confirmed with counsel.

A practical next step is to identify which category your organization falls into and update procurement to include provider safety-disclosure review. If you're building AI products and want the logging, oversight, and documentation pieces designed in from the start, book a call with our team.