What happens when two of the loudest voices in AI policy disagree about who should be responsible for a model’s mistakes? That question sits at the heart of the debate between David Sacks, the White House AI and Crypto Czar, and Dario Amodei, the CEO of Anthropic. California’s SB 53 pushed the argument into law in late 2025, and by 2027 the practical fallout will land on teams that ship AI features, not on the people arguing in podcasts and hearing rooms. The real question for builders is simpler than the political fight: how do you prove your model’s output is good when nobody agrees on who approves it or who gets sued when it fails?
What SB 53 Actually Does, and What It Doesn’t
SB 53, the Transparency in Frontier Artificial Intelligence Act, was signed by Governor Newsom on September 29, 2025. Its core requirements are disclosure-based. Large frontier developers must publish risk frameworks describing how they assess and manage catastrophic risk, and they must report critical safety incidents to the state. The law also protects whistleblowers inside those companies.
Notice what is missing. There is no pre-market approval gate. No regulator signs off before a model ships. No license is required. The law is a transparency and incident-reporting regime, not a licensing regime and not, in the ordinary tort sense, a liability statute. That distinction gets flattened constantly in commentary, and the flattening causes real confusion for compliance teams trying to figure out what they must do.
The backdrop matters. In September 2024, Newsom vetoed SB 1047, the earlier and much broader frontier-model safety bill. His veto message argued that a hard safety standard tied to compute thresholds could apply to models regardless of whether they were deployed in high-risk settings, and that a narrower approach made more sense. SB 53 is the narrower approach. It bets that sunlight, disclosure, and incident reporting do more good than a permission slip.
For a product team, the takeaway is unglamorous but useful: SB 53 does not hand you a checklist that proves your output quality. It hands you a reporting culture. The evaluation work is still yours.
The Sacks vs. Amodei Framing, Stripped Down
David Sacks was announced as AI and Crypto Czar in December 2024. He came to the role as a venture investor and podcast host, and his public posture has generally leaned toward treating heavy regulation as a drag on American competitiveness. Dario Amodei, by contrast, has spent years arguing that frontier systems carry serious risk and that targeted regulation, including transparency and testing requirements, is worth the cost. His October 2024 essay “Machines of Loving Grace” lays out the optimistic case too: AI could compress decades of biomedical progress into five to ten years, but only if the risks are managed.
Here is the trap. It is tempting to cast this as approval versus liability, or safety versus speed. That binary is mostly a media convenience. SB 53 is neither a licensing gate nor a classic liability regime. It is a disclosure law. Sacks and Amodei may disagree about how much government should be in the room, but neither position maps cleanly onto “approve every model before launch” or “let the courts sort it out.”
Anyone citing either man’s position should go to primary sources: transcripts, filings, official announcements, the essay itself. Secondary coverage tends to harden nuance into a quote, and quotes travel further than context.
Why Approval and Liability Both Fail as Quality Signals
A regulator’s stamp of approval tells you a process happened. It does not tell you that your customer support bot will avoid hallucinating a refund policy at 2 a.m. Liability, meanwhile, tells you who pays after something breaks. Neither one tells you whether the output was good on Tuesday.
That gap is exactly where evaluation lives. Output quality is a property of a specific system, a specific task, and a specific population of users. A model that scores beautifully on a general benchmark can still fail a narrow domain task where the stakes are high and the training data was thin. A model that looks mediocre in a demo can be excellent inside a tightly scoped workflow with good retrieval and guardrails.
The EU AI Act offers a useful contrast here. It entered into force in August 2024 and uses a risk-tiered model with conformity assessment for high-risk systems, which is closer to an approval-style regime than anything in California. Even there, conformity assessment is a process obligation, not a guarantee of quality. The lesson repeats: regulation sets the floor for process. Evaluation sets the ceiling for performance.
A Practical Evaluation Stack for 2027
So what does a credible evaluation program look like when the law is transparency-first and the tools are changing every quarter? The most defensible answer borrows from frameworks that already exist rather than inventing a new one.
The NIST AI Risk Management Framework, released in January 2023, organizes risk work into four functions: Govern, Map, Measure, and Manage. It is voluntary, which is precisely why it travels well across jurisdictions. The Generative AI Profile published in July 2024 extends that framework to generative systems, with explicit guidance on evaluation and red-teaming. Together they give a team a shared vocabulary that survives a change in vendor, a change in model, or a change in the political weather.
A workable stack looks like this:
- Govern. Write down who owns quality decisions, what counts as a failure, and how incidents get escalated. If SB 53-style reporting ever applies to you as a downstream deployer, this is the muscle you will need.
- Map. List every task where the model touches a user or a business decision. Rank them by harm if wrong. A recipe suggestion and a medical dosage suggestion do not belong in the same bucket.
- Measure. Build a task-specific test set from real inputs, not synthetic ones. Score outputs with rubrics, not vibes. Track regressions across model versions.
- Manage. Decide what happens when a score drops. Roll back, add retrieval, add a human reviewer, or narrow the scope.
That fourth step is where most teams quietly fail. They measure, they see a regression, and nobody has pre-agreed on what to do about it. The framework is only as good as the decision rights behind it.
Red-Teaming Without the Theater
Red-teaming has become a box that gets checked. A vendor runs a session, produces a slide, and everyone moves on. Real red-teaming is adversarial and specific. It asks: what is the worst plausible input, and what does the system do with it?
In practice, the teams that get value from red-teaming do three things differently. They include people who actually use the product, not just security engineers. They write down the failures they find in a shared log with reproduction steps. And they re-run the same attacks after every model change, because a fix for one model version is not a fix for the next.
Generative systems add a wrinkle: the same prompt can produce different outputs on different days. That means a single passing test proves very little. Sampling matters. Ten runs of the same adversarial prompt tell you more than one.
If you are comparing model families for a research-heavy workflow, it helps to look at how they handle citations and sourcing under pressure, which is a quality dimension worth testing directly rather than assuming. A structured comparison of citation behavior across assistants, like this breakdown of Perplexity vs ChatGPT research citation quality and speed, is a useful starting point for building your own test set.
Where Output Quality and Policy Actually Collide
Here is the uncomfortable truth that neither Sacks nor Amodei needs to resolve for you: policy determines what you must disclose, but it does not determine what your users experience. A company can be fully compliant with a transparency law and still ship a model that confabulates confidently.
The collision point is documentation. Incident reporting under SB 53-style rules requires you to know when something went wrong. That means your evaluation pipeline and your incident log have to be the same system, or at least connected. If quality monitoring lives in one spreadsheet and incident reporting lives in another, you will discover the gap at the worst possible moment.
A second collision point is model churn. When a provider updates a model, your evaluation baseline goes stale. Teams that treat evaluation as a one-time launch task get caught flat-footed. Teams that treat it as a continuous process with versioned test sets and scheduled re-runs stay ahead. The same discipline applies whether you are judging a writing assistant or a coding copilot; a side-by-side look at Claude vs ChatGPT writing draft quality across revisions shows how much output quality shifts between drafts, which is exactly the kind of drift your test set needs to catch.
Common Mistakes That Undermine Evaluation
A few patterns show up again and again, and they are worth naming plainly.
Testing only happy paths. Teams build test sets from clean, well-formed inputs. Real users type fragments, paste garbage, switch languages mid-sentence, and ask for things the system was never designed to do.
Confusing fluency with accuracy. A confident, well-structured answer feels correct. It often is not. Rubrics need a factual accuracy dimension that is scored separately from tone and readability.
Ignoring the long tail. Aggregate scores hide the failures that matter. A model that is 95 percent accurate overall but wrong on the one task that touches money is a liability, regardless of the average.
Skipping the human baseline. If you cannot say how a competent human would perform on the same task, you have no anchor for whether the model is good enough. Set the human benchmark first.
Letting the vendor grade the homework. Provider-reported benchmarks are marketing until you reproduce them on your own data. Treat them as a starting hypothesis, not a conclusion.
There is also a practical trap in benchmarking itself: benchmarks age. A test set that was hard in 2024 may be saturated by 2027. The discipline is to refresh the test set as capability rises, not to keep scoring against a stale ceiling.
Building for 2027 Without Guessing
Nobody can predict the exact evaluation standard that will be conventional in 2027. What is predictable is the shape of the work. Transparency laws will keep asking for documentation. Model providers will keep shipping updates. Users will keep finding edge cases. The teams that handle all three well will be the ones that built evaluation as a habit rather than a launch ritual.
That means a few durable investments. Keep a versioned, task-specific test set built from real inputs. Keep an incident log that feeds directly into your quality reviews. Keep a short written policy on what happens when scores drop. And keep reading primary sources on the policy side, because the difference between a disclosure law and a licensing law changes what you owe the state, not what you owe your users.
The Sacks-Amodei argument will keep generating headlines. Your evaluation pipeline should not depend on who wins it. If you want a model for how to think about tooling choices that age well, the same logic that governs choosing the best upscaler by GPU, game, and quality target applies here: match the tool to the specific job, measure the result, and do not trust the marketing spec sheet.
Conclusion
SB 53 settled one question in California: the state chose transparency and incident reporting over a pre-market approval gate. It did not settle the question that matters most to anyone shipping AI features, which is how to know whether a model’s output is actually good. That work belongs to the teams building the products, and it looks the same regardless of which side of the Sacks-Amodei debate you find persuasive. Govern the process, map the risks, measure against real inputs, and decide in advance what you will do when the numbers move. Do that consistently through 2027, and the policy fights become context rather than crisis.
FAQ
What is California SB 53?
SB 53 is the Transparency in Frontier Artificial Intelligence Act, signed on September 29, 2025. It requires large frontier AI developers to publish risk frameworks and report critical safety incidents to the state, and it protects whistleblowers. It does not create a licensing or pre-approval regime.
Is SB 53 a liability law?
Not in the ordinary tort sense. SB 53 is a disclosure and incident-reporting law. It creates transparency obligations, not a general standard for who pays when an AI system causes harm. That distinction is often lost in commentary that frames the debate as approval versus liability.
What did SB 1047 have to do with SB 53?
SB 1047 was the broader frontier-model safety bill that Governor Newsom vetoed in September 2024. His veto message argued for a narrower approach. SB 53 is that narrower approach, built around transparency and reporting rather than a hard safety standard tied to compute thresholds.
Who are David Sacks and Dario Amodei?
David Sacks is the White House AI and Crypto Czar, announced for the role in December 2024, and a former venture investor and podcast host. Dario Amodei is the CEO of Anthropic and the author of the October 2024 essay “Machines of Loving Grace.” Their public positions on AI regulation differ, but neither maps cleanly onto a simple approval-versus-liability split.
How should a team evaluate AI output quality?
Use a structured framework. The NIST AI Risk Management Framework organizes the work into Govern, Map, Measure, and Manage, and the Generative AI Profile extends it to generative systems with evaluation and red-teaming guidance. In practice, build task-specific test sets from real inputs, score with rubrics, track regressions across model versions, and decide in advance what happens when scores drop.
Will evaluation standards be different in 2027?
The specific benchmarks will likely change as models improve and older test sets saturate. The shape of the work probably will not: documentation, task-specific testing, red-teaming, and incident review. Building those habits now is more useful than trying to predict which benchmark will be standard in 2027.
