A Rule Is Not Yet a Control
A statute can prohibit an action. A control must stop it where it happens, and produce evidence that it did.
By Edward Meyman
Governments are beginning to write rules for artificial intelligence in the settings where the stakes are highest. Proposals now circulate to keep human authority over nuclear decisions, to bar the use of AI for domestic surveillance, and to require human judgment before autonomous systems use lethal force. This is necessary work, and it is overdue. It is also only the first half of the problem.
A prohibition and a control are different things. A prohibition is a statement about what should not happen. A control is a mechanism that prevents it. A statute can express the first. It rarely specifies the second, because the second is not a question of law. It is a question of what a system does at runtime, at the moment the prohibited action would execute. The rule lives in legislation and in oversight bodies that meet on a human schedule. The action lives inside software, often faster than review and sometimes with no person in the loop. A rule is not yet a control until that gap is closed.
That the gap exists, and that watching a system is not the same as governing it, is a case I have argued elsewhere in the context of critical infrastructure, in Watching Is Not Stopping. I take it as the premise here. This piece is about the two questions that follow once the premise is accepted and the rule in question is a law rather than an operating procedure. The first is how anyone confirms the rule held. The second is what happens at the exceptions.
Who has to know the rule held
When the rule is an operating procedure, the people who need to know it was followed are often nearby. When the rule is a law, they are not. They are a committee, an inspector general, an auditor, a court. They arrive after the fact, they were never in the room, and they cannot take the system's word for what it did. For them, enforcement is necessary but not sufficient. They also need to be able to confirm that enforcement happened.
This is where most of what passes for AI governance falls short, because the standard record is often a log, and a log is usually an account a system keeps of itself. It can be incomplete. It can be changed. It does not contain the reasoning that produced a decision. What independent oversight requires is different in kind. It requires each consequential decision to produce its own evidence: a record sufficient for someone who was not present to reconstruct what was requested, what rule applied, the relevant system state, who held authority, and why the action was permitted, denied, or held. That kind of evidence converts a statutory prohibition from a policy expectation into a condition that can be independently verified. Without it, oversight is reduced to assuming the rules held, which is not oversight.
The distinction matters most for the rules that turn on human authority. A statute can say that a human must remain in control of a given class of decision. The language preserves that authority in principle. Whether it is preserved in practice depends on something the statute does not state: whether, at runtime, an AI-originated action in that class cannot proceed without an affirmative human authorization, and whether that authorization is itself captured as evidence. If it is, human control is a property of the system. If it is not, human in the loop is a sentence in a law and nothing more.
The exception is where the rule is won or lost
No serious rule operates without exceptions. High-consequence prohibitions almost always include a provision for waivers or overrides under defined conditions, and they should. Real operations encounter circumstances no rule anticipated, and a system that cannot bend under extraordinary conditions will be worked around or switched off. The waiver is not a flaw. It is a necessity.
But the waiver is also the seam in the rule, and a rule tears at its seams. An exception is easy to write as a broad standing authority and hard to write as a bounded, accountable act. The governance question for any exception is whether it is general or specific, indefinite or time-limited, opaque or reviewable. A waiver written as a broad authority can quietly swallow the prohibition it was meant to qualify, until the exception is the rule and the prohibition is the exception. A waiver expressed as a bounded authorization, scoped to a defined situation, limited in duration, and recorded as verifiable evidence, preserves the exception without dissolving the rule.
For anyone drafting these limits, this is the most consequential design choice in the text, and it is easy to underweight. A prohibition will not be tested in the ordinary case. It will be tested at its exceptions, under pressure, in the moment someone has a reason to invoke one. The enforcement and verification that the rule requires, the exception requires more, because the exception is where a rule is most likely to be hollowed out without anyone deciding to hollow it.
Why this is a condition for deployment
It would be a mistake to read any of this as resistance to the adoption of AI. In the settings where these rules are being written, trust is not optional, and capability without demonstrable limits is not deployable. An organization cannot put a capable system into a high-consequence environment unless it can show that the limits on that system hold and can be checked. Enforcement at the point of action and decisions that carry their own evidence are what make that demonstration possible. They are how a policy constraint becomes something operational, and they are what let an institution say yes to a capable system rather than no to all of them. Governance of this kind does not slow deployment. It is the precondition for it.
The measure that is coming
The current moment is doing the necessary first thing. It is naming the actions that high-consequence AI should not take. The harder and quieter work comes next. It is making those prohibitions hold where the action happens, defaulting to no when authorization is unclear, governing the exceptions as tightly as the rules, and producing evidence that an independent party can check long after the moment has passed. The strength of a rule for high-consequence AI will not be measured by how firmly it prohibits. It will be measured by whether the prohibition can be enforced at the point of action and proven, afterward, to everyone whose job is to make sure it held.
Edward Meyman is the founder of FERZ, where he works on authorization and verification infrastructure for AI systems in regulated and high-consequence environments.