Frontier AI standards need an action layer

Demis Hassabis has proposed a serious upgrade to frontier model governance: replace broad promises with changing tests, independent technical capacity, and a review process that can become a condition of deployment. He is right about the release boundary. The enterprise problem begins one boundary later, when an approved model receives private data, tools, permissions, and authority to affect real work.

What the proposed standards body would do

In his July proposal, Hassabis describes a United States-led standards body modeled on a federally overseen public-private partnership or self-regulatory organization. He points to FINRA, which describes itself as a government-authorized nonprofit overseen by the Securities and Exchange Commission. The analogy matters because it moves the discussion from voluntary principles toward an institution with technical staff, assessment protocols, and a path to formal authority.

The proposed body would define which models qualify as frontier class, work with federal agencies and national laboratories, and maintain evaluations for cyber, biological, deception, guardrail-bypass, and agentic risks. Its board would include independent technical experts and open-source representatives. Frontier labs would initially share models voluntarily up to thirty days before release. Once the protocol proved effective, passing review could become a requirement for deployment in the United States.

The strongest part of the proposal is its treatment of evaluations as a living system. Hassabis calls for regularly replacing saturated benchmarks and building independent held-out tests so labs cannot optimize only for a public exam. He also includes post-release vulnerability work and the possibility of coordinating a slowdown if the evidence demanded it. The framework would apply to open and closed frontier models that meet the capability threshold.

That is a better governance shape than a static pledge. It establishes an institution whose testing can change as capabilities change. It gives public policy a technical surface to inspect. It also creates a common baseline for enterprise buyers who currently receive model cards, internal safety claims, and vendor-specific assurance packages that are hard to compare.

What pre-release testing cannot observe

A frontier evaluation asks whether a model has a dangerous capability or a meaningful tendency under controlled conditions. The evaluator owns the prompt set, the environment, the rubric, and the threshold. That control is the point. It makes comparisons possible and creates a reason to hold back a model whose inherent capability is too risky.

The same control limits what the test can see. It cannot reproduce every enterprise's data model, permissions, vendor integrations, local policies, retrieval quality, approval chain, or human operating habits. It cannot know that one company connected the model to a read-only knowledge base while another connected it to a system that can change records. It cannot evaluate a workflow that did not exist when the model was submitted.

Release review therefore answers a necessary question: should this model be available for deployment at all? It does not answer the later question a chief risk officer has to sign: should this configured system be allowed to take this action, on this evidence, inside this company, today?

That distinction is easy to miss because both are called AI governance. Model capability governance studies the engine. Enterprise action governance studies the assembled system and the authority it has been given. A model can pass a deception evaluation and still produce a wrong recommendation because the local context is incomplete. It can pass a cyber evaluation and still be granted an overly broad tool permission. It can be safe enough to release and unsafe to let act silently.

Deployment changes the object under review

An enterprise deploys more than a model. It deploys a context pipeline, retrieval rules, system connections, prompts, tool schemas, identity controls, and a sequence of human handoffs. Each component can change the result. A correct model response grounded in the wrong employee record is still a wrong enterprise recommendation. A sound recommendation executed with the wrong permission is still an incident.

The data changes too. New policies appear. System fields drift. Two sources disagree. A business owner creates an exception that never reaches the retrieval index. The application may combine several models or agents, each with a different job and permission set. None of those details invalidate the frontier evaluation. They show why the enterprise has to evaluate the configured system again.

This is where shadow evaluation belongs. Before a new model or configuration receives production authority, it runs beside the incumbent against pre-specified local criteria. The team records where it improves, where it regresses, and which failures matter for the actual workflow. Release approval establishes eligibility. Shadow evaluation earns local promotion.

Promotion is still not permission to act without a gate. A locally approved model can encounter a novel case tomorrow. It can retrieve conflicting evidence. It can propose an action whose cost is obvious to a business owner and invisible to the model. The object under governance changes with every live decision.

The enterprise action layer

The action layer sits between reasoning and execution. Every workflow the system wants to run arrives first as a proposal. The proposal states what the system read, what it concluded, what it wants to change across which systems, and the cost of acting versus declining to act. Evidence links back to the source records. A named human can approve, edit, or decline.

This is an approval gate, not a notification after the fact. The system waits. Regulated workflows can require a second signer with distinct authority. Only after the required approval does execution begin. The result is then logged beside the proposal and the human input.

A signed Decision Trace makes the decision queryable: what happened, where, why, what the reasoning was, and what input any human gave. It is captured in the reasoning path instead of reconstructed from application logs months later. The trace does not certify that the original model was safe. It shows how one deployed action was formed and controlled.

That record matters for more than audit. It creates local evaluation data. Declines reveal where the configured system misunderstood the business. Edits show which evidence or constraint it missed. Approved actions that later produce poor outcomes become test cases for the next candidate. The action layer closes the loop between deployment behavior and model promotion without allowing the model to grade or promote itself.

The local layer also makes a national warning operational. If the standards body identifies a new failure mode after release, an enterprise with queryable traces can search for exposure, suspend affected workflows, assemble an evaluation set, and test a replacement. Without action-level records, the same warning becomes a broad instruction to investigate with no reliable map of where the model acted.

Two layers of governance, one chain of evidence

National standards and enterprise controls govern different decisions. The standards body decides whether a frontier model clears a shared capability floor. The enterprise decides whether a specific configuration clears its local promotion gate and whether a specific action clears its human approval gate. The layers reinforce each other when evidence can move between them.

The public layer gives buyers a comparable model assessment and a channel for post-release vulnerabilities. The local layer supplies deployment evidence that broad evaluations cannot generate. Patterns found in enterprise traces can inform new held-out tests. New frontier tests can become local regression cases. Governance becomes continuous because each layer has an artifact the other can use.

This framing also keeps responsibility legible. A lab remains responsible for the model it releases. A vendor remains responsible for the application and controls it sells. The enterprise remains responsible for the authority it grants and the humans it names as approvers. No party can point to a passed frontier evaluation as a substitute for its own part of the chain.

What an AI council should ask next

An AI council should ask for the frontier assessment when one exists, then keep going. Which exact model and checkpoint is deployed? What changed after the assessment? Which local evaluation earned promotion? What tools can the system call? Which actions require one approver, which require a second signer, and where are declines recorded?

Then ask to inspect one real control path. Show a proposal. Show the source evidence. Show a human edit or decline. Show the resulting Decision Trace and the rollback path for the model or workflow version involved. The vendor questions should produce records, not adjectives.

Hassabis is right that frontier governance needs dynamic testing and independent technical capacity. The enterprise extension is equally concrete. Review the model before release. Review the configured system before promotion. Review the action before execution. Keep the evidence from all three. Frontier AI standards establish the floor. The action layer keeps that floor beneath the system after it starts moving.

Sources

A Framework for Frontier AI and the Dawning of a New Age

FINRA: About

Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises.