Recommendations for Implementing IVOs Pursuant to EO N-9-26

Overview

When Fathom began advocating to create a regulated market for Independent Verification Organizations (IVOs), we endorsed a voluntary system that developers could join to prove they were acting responsibly across a range of risk domains. However, the acceleration of AI-related cybersecurity and loss-of-control incidents over the past few months have demonstrated that governments ought to require deployment of IVOs specializing in catastrophic risk domains, and that the government oversight of IVOs that Fathom has called for must be articulated in concrete terms. This memo overviews Fathom’s suggestions for legislative and regulatory changes California can pursue to implement appropriate oversight of the IVO market.

1. Outcome Standards

   • Through amendments to SB53, frontier labs should be statutorily required to engage an IVO to evaluate for catastrophic risks, providing independent assessment and verifying adherence to critical safety measures.

   • California should set the outcome standards necessary to regulate against catastrophic risk. It is a red herring to say that we must wait for universally agreed-upon technical standards to regulate against a harm, especially where there is no technical consensus on how to prevent these harms. California should define an acceptable level of catastrophic risk mitigation in statute and leave assessment of whether it was achieved to IVOs, instead of presupposing a narrower technical standard that could be complied with even while not achieving the desired outcome.

   • Outcome standards are necessary for the IVO model to remain robust to threat model changes. Specific technical standards alone address specific risk pathways and technical challenges, which may enable developers to narrowly optimize against them. Broader outcome standards enable IVOs to quickly pivot toward assessing novel risk vectors, irrespective of developer compliance in less relevant domains.

2. IVO Payment and Selection

   • Evolve the rules around compensation & selection of IVOs as the IVO market becomes more mature. Start with state assignment from a pre-designated pool on a time-and-material basis, then hand selection to developers as the pool deepens, while keeping the state’s power to veto, mandate IVO rotation, select additional IVOs in risk areas as needed, and decertify at every stage.

   • Prioritize decertification of ineffective or industry-captured IVOs. California regulators and policymakers should focus on what it will take to decertify an IVO. A credible threat of revocation keeps the verifier market honest.

3. IVO Readiness and Market Maturity

   • Trigger the mandate on the supply of IVOs. The requirement should bind once the state has designated IVOs with appropriate capacity and expertise in a risk area.

4. Continuous and “Embedded”-level Access for IVOs

   • Define “embedded” as continuous employee-like access with the ability to have an ongoing physical presence, backed by statutory confidentiality, anti-retaliation, and redaction rules.

   • The state should set the contours of every engagement. Today the IVO and the developer negotiate scope and access privately. The state should publish a standard engagement framework and resolve disputes when the two sides disagree.

5. Addressing Recursive Self-Improvement

   • Give embedded evaluators a specific recursive self-improvement (RSI) mandate: internal-use governance, pre-registered capability tripwires, and verification of control measures. Consider advancing legislative requirements that labs license evaluators as a first priority for any frontier research above a certain RSI threshold.

6. Enforcement

   • Enforce through the Attorney General and a narrow administrative emergency power. IVO powers should be limited to findings, prescribing corrective actions, verifying safety claims, and referring potential risks to relevant state authorities.

Recommendations

1. Outcome Standards

California should specify an appropriate risk outcome and allow IVOs to develop technical criteria. Government already regulates its hardest technical domains this way. The Clean Air Act sets standards “requisite to protect the public health” with “an adequate margin of safety” and hands the science to an independent committee. FAA certification requires catastrophic failure conditions to be “extremely improbable,” and relies on delegated private experts to verify compliance. FDA approval requires a finding of “safe and effective.” None of these statutes specifies a test. All of them hold the delegated experts accountable for the result.

The alternative, enshrining methods in statute, will not be enough to ensure the safety of AI systems. We do believe that there are many examples of process, governance, and even technical standards that can be adopted by government and enforced directly on a developer, and that it will be important for California to continue to identify and enforce these standards as part of a comprehensive governance regime. However, California has recognized, through the passage of SB 813, that traditional standard setting with government enforcement will not do enough to accelerate the science of AI safety, and may lack the flexibility to fully govern the frontier of AI. For example, rules written only 6 months ago may rely heavily on chain-of-thought review and activation probing. Both those techniques are losing power as capabilities rise, and models are now frequently able to identify when they are in evaluation environments. In short, relying solely on more traditional standard setting risks creating safety regulations that are either no longer relevant, or that a model could easily meet while remaining catastrophically dangerous. A better approach would be for the work group to advance the overall design of SB813 while also proposing outcomes the state can adopt. We suggest some here.

Two statutory models California can draw on. Virginia’s IVO bill (HB797), as passed by the House of Delegates, would license IVOs “to assess artificial intelligence systems’ or applications’ adherence to standards reflecting best practices for the prevention of personal injury and property damage,” and would require each applicant to submit “a proposed definition of acceptable levels of risk” with measurable metrics, targets, and an evaluation protocol. The state would only license IVOs with plans that mitigated risk to an acceptable level and would be compelled to revoke a license if a verified system caused the harm the IVO existed to prevent, or if technology made the IVO’s methods obsolete. That is the right model for non-catastrophic harms and for SB 813’s voluntary tier.

For the mandatory frontier tier, the federal FRONTIER Act (HR 9925) seeks to set the outcome in the statute. It defines “acceptable levels of catastrophic risk mitigation” as “risk mitigation adequate to ensure that the anticipated benefits of a frontier model made available or used in interstate or foreign commerce outweigh its level of catastrophic risk, taking into consideration the probability and magnitude of the model’s anticipated benefits and catastrophic risks.” An IVO’s role is to ensure whether or not a frontier model developer has achieved acceptable levels of catastrophic risk mitigation, and must say how its methods will “keep pace with technological and organizational changes.”

Suggested California language. California already defines catastrophic risk in SB 53. It should be modified to create a standard for mandatory IVOs:

“Acceptable levels of catastrophic risk mitigation” means risk mitigation adequate to ensure, based on extensive testing and ongoing monitoring by a designated independent verification organization, that the development, internal use, or deployment of a frontier model is unlikely to increase the risk of catastrophic harm above the level that would exist absent the model, and that the model’s anticipated benefits outweigh its residual catastrophic risk, taking into account the probability and magnitude of each.

Establishing this status quo baseline gives GovOps a legal test to administer, gives IVOs a target to build metrics toward, and gives courts specific language to review. It does not require California to write a single benchmark. The implementation of the standard should be understood to essentially give the IVO three options in its assessment: (a) Yes, there is an acceptable level of risk mitigation. (b) No, there is not an acceptable level of risk mitigation, and here are the steps that can be taken to cure that. (c) No, there is not an acceptable level of risk mitigation, and there are no known steps to achieve an acceptable level.

Over time, a growing body of research and professionalization will create industry standards for the IVOs.

2. IVO Payment and Selection

Many organizations have weighed in on this question. We agree with the principles most of them share: competitive selection on expertise rather than price, developers pay, and payment is never contingent on results. We differ on the end state. In order to create the race-to-the-top we should see in a mature verification market, we believe that developers should have the ability to choose their IVO and switch among them, with IVOs competing on cost and service. Licensing would set the quality floor for IVOs along with a statutory definition for what should be considered an acceptable level of risk mitigation. Meaningful developer choice is important to draw capital and talent into verification and make a race to the top possible. Removing developer choice permanently would lead to the state running a procurement process rather than overseeing a market. Investment in a thriving market of independent verification is critical to ensuring the science of evaluation can keep pace with rapidly expanding capabilities of frontier models. We have a window of time to close the gap between investment in capability and investment in safety. To get there, we must avoid a long-term system that centralizes verification among a government-selected group of entities, which would limit capital investment into this critical new sector.

The hard question is how to get to a mature verification market safely, starting from a pool of two or three IVOs. Our answer: first, phase in developer choice as the pool of IVOs deepens, loosening selection rules only when enough qualified IVOs exist to compete. Second, engage in a qualitative assessment of how well the state is monitoring the efficacy of IVOs. Third, leverage the state’s power to decertify weak IVOs as the main safeguard, so the system stays sound even if the selection rules at any one stage are imperfect. Fourth, give the government tools to continue to add redundancies, checks, and balances where appropriate.

State powers in every phase: The state should retain certain checks throughout the phases to guard against industry capture, poor quality, and systemic failures. These powers include a veto on IVO choice, rotation rules, concentration caps, an ability to assign an additional state-chosen IVO to any risk, and decertification. Additionally, the state will need a mechanism to investigate retaliation and ensure that IVOs critical of a lab are not unfairly denied future contracts. GovOps should declare when a gate has been reached and create a timeline for when the system will move into the next phase.

Phase I. GovOps designates IVOs by risk area. For each mandatory engagement, the state chooses an IVO. Contracts run between developer and IVO on time-and-materials at state-benchmarked rates, so the state never becomes the contracting party and the Department of General Services doesn’t enter procurement processes. The developer pays directly; SB 813 already bars outcome-contingent terms. The state issues the formal acceptance of each report.

Phase II. Developers choose among designated IVOs from a state-selected pool, subject to three limits: a revenue concentration cap (no IVO takes more than a set share of its revenue from one developer), a market share cap (no IVO holds more than a set share of mandatory engagements in a risk area), and rotation on a fixed cycle. The state should have the power to exercise a veto within a reasonable timeline (e.g. thirty days). If independence problems appear in the direct-payment model, the state can move to a pooled fund it administers, but only in response to evidence.

Phase III. Developers choose and switch freely. The state’s attention should be on evaluating the evaluators: inspections of IVO evaluation records modeled on the Public Company Accounting Oversight Board (PCAOB), state-commissioned reproduction of a sample of findings, a public scorecard, an annual report on the market’s competitiveness and independence, and whistleblower channels for IVO and lab staff. There should also be redundancy: for example, the state could require developers to engage with at least two IVOs that specialize in different risk domains, one of which is chosen by the state on the highest-stakes engagements (e.g. RSI, kill switch efficacy), with no shared personnel or subcontractors.

Importance of Decertification. Delegating verification to private bodies works only if the state keeps a credible threat, and uses it to condition, suspend, or revoke the designation of any IVO that skimps on rigor to win a developer’s business. California should write mandatory revocation grounds into the statute rather than leave them wholly to rulemaking: a materially misleading plan, failure to follow the plan, a material change compromising independence, obsolete methods, and a verified model that causes the harm the IVO was designated to prevent, unless the IVO identified the deficiency and the developer failed to act. Add graduated tools short of revocation (corrective action plans, suspension from new engagements, public findings) and a cure period where the public interest supports one. When an IVO loses designation, the state should reassign its open engagements and re-review its assessments.

Retaliation. A developer may not remove a named evaluator or terminate an engagement mid-cycle without notice to the state and a stated reason. Cooling-off periods should run in both directions between IVO staff and the labs they assess. Developers may correct errors of fact and request IP redactions, with the state resolving disputes.

3. IVO Readiness and Market Maturity

We understand the general concern that the AI evaluator ecosystem is not big or expert enough to meet a mandate across all risk areas. While this characterization is partly true today, there is more capacity and expertise than many presume. In any event, California should sequence the IVO mandate rather than stall implementation to wait for supply. Supply will be catalyzed by a credible demand signal. We saw this when, just one week after Dario Amodei’s September 2026 essay, Anthropic and Accenture committed a reported $1 billion each over five years to continuous third-party evaluation. The policy challenge here is to set meaningful requirements that will also act as an effective demand signal.

Four mechanisms do that:

1. A capacity trigger. Any new statutory requirement for a given risk area takes effect after GovOps has determined sufficient IVO capacity in that area.

2. Phasing by risk area. GovOps and the IVO ecosystem should move with all deliberate speed to develop the science and criteria necessary to ensure catastrophic risk mitigation across all relevant risk domains. That said, the government should also recognize that effective verification tools will be developed for some risk domains prior to others, and CA should move to implement the system as those come online instead of waiting for effective IVOs in all risk domains. We would ask that the government give special attention to RSI as soon as possible, as it will be both a technically challenging risk area and is likely to play an outsized role shortly.

3. Subcontracting with pass-through obligations. Let a designated IVO assemble different specialists across multiple risk domains under its own designation, with the IVO fully responsible and every subcontractor bound by the same independence, confidentiality, and qualification rules.

4. Lower the cost of entry. Scale licensing fees to the size of the applicant, recognize national and international testing bodies, allow philanthropic funding for field-building (evaluation science, training, seed support for entrants) rather than for engagements, and extend qualified immunity to designated IVOs acting in good faith, which removes a liability overhang that otherwise keeps serious organizations out.

California should also expect the ecosystem to be national. SB 813’s designated pool will serve federal and other-state demand as it emerges, and the state should design for that rather than for a California-only market, which cannot sustain competition on its own.

4. Continuous and “Embedded”-level Access for IVOs

Embedding should be defined as a standing relationship with the lab, not a physical presence requirement. The closest working analogy is the resident examiner program at large banks: continuous access, periodic on-site intensives, and the right to be in the room when decisions are made. California should define the minimum terms in statute and let the IVO’s designated plan fill in the rest.

Adequate Physical Access. Require the AI labs to give the ability to have physical presence at defined decision points (training run go/no-go, internal deployment of a new frontier model, external release, any critical safety incident review) and on a periodic on-site schedule. Physical presence is one of the IVO’s tools. It should not be the measure of compliance by the IVO.

Systems Access. Require timely access on request to unredacted materials, records, personnel, and systems reasonably necessary to the assessment. Concretely, that means observer status at safety governance meetings and the minutes or recordings of those meetings; read access to the framework’s decision logs, internal evaluation results, incident reports, and monitoring dashboards; a sandbox for the IVO’s own testing on developer-controlled infrastructure; and interviews with staff without management present. The report must describe any limits the developer places on access, so the state and the public can weigh the finding accordingly.

Engagement terms set by the state. Today, when developers voluntarily engage with third party AI evaluators (e.g. METR, Redwood Research, Apollo Research, etc.), the two parties negotiate scope, access, and timeline with no one else in the room. That leaves too much room for a developer to narrow scope quietly, or for an evaluator to accept a thin engagement to win the work. When building the IVO system, the state should publish a standard engagement framework that sets the general contours: the minimum access described above, the decision points at which the IVO must be present, the categories of material the IVO may review, the turnaround time for access requests, and what the IVO may publish. IVO and developer fill in the specifics within that frame, and the report discloses any departure from it. The framework can be paired with a dispute resolution channel at GovOps. When an IVO and a developer disagree over access, scope, redaction, or timing, the dispute can be brought to a designated state official.

Confidentiality and IP can be addressed in three layers:

1. Statutory: assessment reports and supporting materials filed with GovOps are exempt from the Public Records Act, and the IVO and its staff are bound by a statutory duty of confidentiality enforced by decertification and civil liability.

2. Contractual: the developer may impose security protocols narrowly tailored to trade secrets and confidential business information, including on-premises review, limits on copying and note-taking, and personnel vetting, so long as these protocols do not materially affect the assessment.

3. Technical: model weights never leave the developer’s infrastructure; the IVO tests through access to the developer’s controls and logs. Public reporting can include redactions limited to trade secrets, cybersecurity, risk-prevention mechanisms, public safety, and national security, and a state process to review redactions that look overbroad.

Independence of judgment. The IVO sets its own test plan and schedule. Developers may correct errors of fact and seek redactions. They may not pre-clear findings or condition payment on the result. Evaluators who report pressure should have the same whistleblower protection AB 1405 already extends to auditor employees.

5. Addressing Recursive Self-Improvement

RSI is the risk area where embedding is most important. Every frontier lab has said it will devote a large share of its compute to automated AI research by its own models. The resulting capability gains happen inside the lab, often before a model reaches any external release gate, and they can outrun the evaluations meant to catch them. IVOs should be mandated to monitor the risk of RSI in both internal and external use.

Fathom believes much more work needs to be done on how IVOs can best contribute to RSI safety. However, we can say that, today, IVOs will contribute at least three things to aid in better control over RSI:

1. Verify internal-deployment governance. Confirm that a lab’s framework effectively prevents unsafe internal model deployment: who may run autonomous research agents, with what permissions, compute, and monitoring, and what human sign-off sits at each step. Report any gap between the published framework and internal practice.

2. Monitor both inputs and outputs. Track the share of research and engineering work the lab’s own agents perform and the lab’s own measures of research acceleration. A rising curve is itself a finding that should trigger more frequent assessment.

3. Pre-register tripwires. Agree in advance with the developer on capability thresholds, drawn from the IVO’s own plan, that trigger notification to the state and a hold on further scaling of internal deployment until the IVO re-assesses.

6. Enforcement

If IVO assessments become mandatory for catastrophic risk, a finding of significant catastrophic risk must lead somewhere. We recommend the following:

Primary mechanism: Attorney General enforcement. Vest enforcement in the Attorney General, with authority to seek injunctive relief halting development, internal use, or deployment of a model after an IVO reports an unmitigated catastrophic risk, and to seek civil penalties. Provide, as Connecticut’s recent AI law does, that injunctive relief may not be stayed pending appeal. Use per-day penalties for continuing violations, as California already does in its AI transparency law, per-violation penalties for point-in-time failures such as a missed report, and punitive damages for reckless or intentional conduct. Authorize recovery of investigation costs and fees. This approach maintains the technical role of the IVO, allows appropriate state officials to pause development where appropriate, and gives the Attorney General a view across all covered developers that no single IVO has. The weakness of this mechanism is speed.

Emergency mechanism. Where speed is necessary, authorize the administration or the Attorney General to issue a temporary administrative order suspending internal use or deployment of a specific model on an IVO referral of imminent catastrophic risk, modeled on the emergency decision provisions of California’s Administrative Procedure Act, which allow interim relief in a situation involving an immediate danger to public health, safety, or welfare. The authorizing regulations must define the triggering circumstances, the relief available, and the procedures before and after issuance. Limit the order to imminent catastrophic risk, cap its duration absent renewal on a fresh finding, provide an expedited hearing, and make judicial review available on a final determination. The FRONTIER Act’s emergency order provisions (provisional orders that lapse in 45 days, an expedited hearing within 30 days, exclusive expedited judicial review) are a template California can adapt. The legislature should also fund the technical capacity GovOps needs to act on referrals within days.

Define sanctionable conduct. Failure to retain a designated IVO; failure to provide the access the statute requires; failure to implement corrective actions the IVO identifies as necessary; deployment or continued internal use after an IVO finding of unmitigated catastrophic risk; failure to maintain a functional, IVO-verified kill switch; and material misrepresentation in a post-assessment response.

What not to do. Do not give IVOs standing to seek injunctions. Such standing would afford IVOs an inappropriate law-enforcement proxy role, inviting developers to treat them as adversaries and restrict access, and could expose IVOs to liability if a court later finds a shutdown unnecessary. Do not make IVO findings self-executing. An automatic pause on a private finding, with no state or judicial step, delegates a governmental function with major commercial consequences to a private actor and places the full weight of the system on a single determination. The IVO’s role is to find, prescribe corrective action, render an opinion on the developer’s response, and refer imminent risk to the state within 72 hours.