In August we argued that AI customer service has split into two schools, and that only one of them survives regulatory contact. That piece was about the interaction layer: whether a model is permitted to execute a transaction, or whether it hands a directive to a deterministic orchestrator that does.
On September 10, ServiceNow CEO Bill McDermott went on CNBC’s “Squawk on the Street” and put the same fault line on national television, one layer up.
He was not talking about customer service. He was talking about how an enterprise governs every AI running inside it. The split is identical. This time the stakes are the entire AI estate rather than a single workflow.
What he got right
McDermott’s case, in his words: “AI can do a lot of things for you. It can also do a lot of things to you.” Every AI in the enterprise, native or third-party, has to be visible. You have to govern it and secure it. “You can’t have blind spots running a company.” Take the 400-plus global AI regulations already on the books and turn them into rules and rails. Track token consumption, enforce budgets, measure return. And if agents go out of control, you need a kill switch.
He is right about all of it. An enterprise that cannot inventory its own AI cannot govern it, and by his account most enterprises still cannot distinguish a personal AI account from a corporate instance. That work is necessary and overdue, and an institution that skips it is exposed.
The question is not whether to build that layer. It is what that layer can and cannot do.
What a kill switch concedes
Consider what a kill switch presumes. It presumes the system can enter a state you need to stop. It presumes something has already begun to go wrong, that someone or something noticed, and that the intervention arrived in time to matter.
Compliance functions have a term for a safeguard shaped like that. It is a detective control.
Detective controls identify failures after they occur. Preventive controls stop failures from occurring. Every internal control framework a regulated institution operates under ranks preventive above detective, and every examiner who has ever walked a process will ask which one you have. This is not our framing. It is theirs.
A kill switch is a detective control. Determinism is a preventive control.
Why detection is not enough at the point of transaction
Three reasons, and they compound.
Timing.
In a regulated interaction, the failure and the harm are the same event. By the time an agent has skipped a required disclosure, misquoted a rate, or failed to capture consent, the customer has already received it. There is no interval between the error and the exposure in which an emergency stop does useful work. You can stop the next one. You cannot unsay the last one.
Evidence.
An incident log proves that something failed and that you caught it. That is not what examiners ask for. They ask you to demonstrate conformity across a population of transactions, every time, not to demonstrate that your exception handling works. A record of exceptions is the wrong artifact. Provable repeatability is the right one.
Burden.
Under a supervision model, the obligation to prove the AI behaved sits permanently with the compliance function. It does not decay. Every new model version, every new agent, every vendor update reopens it.
The sector is not positioned to absorb that burden. Wolters Kluwer’s Q1 2026 banking compliance research found that only 26.4% of banks are confident their AI meets regulatory requirements, and only 12.2% describe their AI strategy as well defined and resourced. The deadlines do not wait for the other 87.8%. EU AI Act high-risk obligations take effect August 2. The Colorado AI Act lands June 30.
The same question, asked twice
At the interaction layer, the question was whether the model executes the transaction or hands it to something deterministic.
At the governance layer, the question is whether your control over AI is observational or architectural.
These are the same question. A supervision architecture watches behavior and intervenes when it goes wrong. A deterministic architecture removes the wrong behavior from the set of available outcomes. One produces alerts. The other produces conformity.
An enterprise can have world-class visibility into an agent that has just mis-sold a product. Seeing it perfectly does not unsell it.
What the alternative looks like
In a deterministic architecture, the AI agents still sit at the front of the interaction. They still assess the request. They still evaluate risk and context. What they do not do is execute. They hand a directive to a deterministic orchestrator, and the orchestrator, not a model, is what touches the system of record.
The disclosures, validations, consents, and handoffs are enforced as conditions of execution rather than as instructions a model is asked to follow. There is nothing to police because deviation is not available.
The axiom is simple. AI evaluates, the system executes within enforced rules, humans govern.
None of this is an argument against AI-powered self-service. Self-service is not the risk. Ungoverned self-service is. The entire point of building the deterministic layer is to make self-service safe enough to scale.
This is both, not either
Both layers are real and neither replaces the other.
An enterprise needs to know what AI is running across its estate, who authorized it, what it consumes, and how to stop it. That is supervision, and it should be bought.
An enterprise also needs the transactions that touch regulated outcomes to execute correctly the first time and to produce evidence that they did. No amount of observability produces that.
The mistake is assuming the first covers the second. A control tower tells you an agent went off the rails. It does not keep the agent on them.
Where compliance is not a policy but a specification
There is a second reason the two layers cannot collapse into one, and it is structural rather than architectural.
A governance platform that has to work for every company in every industry must keep its rules layer generic. Map the regulations, expose the configuration, hand the customer rails and let them build the track. That is the only design a horizontal platform can afford, and for most of the economy it is the right one. Nobody needs a pre-built workflow for approving a laptop request.
Some industries are not built that way. In financial services, insurance, healthcare, utilities, and telecommunications, the execution path is itself prescribed. The sequence of disclosures, the eligibility checks and their order, the consent captured before the next step is permitted, the notice served with the required timing: these are not policies layered on top of a workflow. They are the workflow. Deviating from the prescribed sequence is a violation even when the outcome is correct.
That is the property those five industries share, and it is the reason a generic rules engine does not close the gap. You cannot configure your way to a lending adverse action sequence, a claims handling path that satisfies unfair claims practice statutes, a disconnection notice that meets a state commission’s requirements, or a customer authorization that satisfies telecom privacy rules. Each one is a specification, written by a regulator, examined against.
A horizontal platform cannot ship that depth across five regulatory regimes. Its economics forbid it, and that is a rational choice rather than a failure. It is also why breadth and depth are bought separately.
Where we sit
Callvu builds for those five industries and no others. We enforce compliance policy, business rules, and standard operating procedures at runtime, inside the workflow, as it executes. Not as a prompt. Not as a post-hoc review.
Two artifacts come out the other side. Decision Trace is the record of what the AI evaluated and why it routed the interaction the way it did. Audit Trace is the immutable record of what was enforced and what was executed. Together they answer the two questions an examiner asks in sequence: what did the system decide, and what did it do.
That is what makes the control preventive rather than detective.
One question for your next vendor conversation
Ask it of every AI vendor in your stack, and ask it of us:
Is this control preventive or detective?
If the answer is that you will be able to see the problem, monitor the problem, and stop the problem, you have bought a detective control. That has real value and you probably need one. It is not conformity.
If the answer is that the problem cannot occur because the execution path does not permit it, you have bought a preventive control. That is the one your examiner is asking about.
Do not take our word for it. The sandbox is live at try.callvu.com. Run a real regulated workflow, on our AI or point your own AI at it, and read the Audit Trace yourself.
Related Reading: Two Schools of AI Customer Service, and Why Only One Survives Regulation covers the same fault line at the interaction layer.
Sources: Bill McDermott, CNBC “Squawk on the Street,” September 10, 2026. Wolters Kluwer Q1 2026 Banking Compliance and AI Trend Report.
