Your AI Controls Watch. They Don't Stop.
Observability makes behavior visible. A control plane makes policy operational — and the difference decides what an agent can do to a member record.
The review that decides whether an agent touches production at a health plan usually comes down to one exchange. The team presents the governance slide — traces, dashboards, an audit log, an evaluation suite — and someone from risk asks the only question that matters: which of these can stop the agent from doing something we never sanctioned? Traces record. Dashboards display. An audit log is a list of things that already happened. The honest answer, most days in most rooms, is that nothing on the slide can stop anything.
That is the distinction this piece is about, and it is worth stating as plainly as we know how: observability tells you what the AI did. A control plane governs what it can do. Observability makes behavior visible; a control plane makes policy operational. Governance writes the rules; the control plane is the machinery that applies them while the work happens. A log that records a violation has already permitted it.
The gap is tolerable when AI drafts a summary a person reads before sending. It stops being tolerable the moment an agent writes to a claims system, drafts an adverse determination, or reads a member record — because at that point the question is no longer what happened. It is what was allowed to happen, and what stood in the way.
Sort every control by when it acts
Ask of any AI control exactly one question: when does it act, and can it stop the thing it objects to? Every control in an enterprise estate lands in one of four classes.
Preventive verifiers act before generation. The framing is "the agent cannot": tool allowlists, scoped credentials, data-boundary rules, policy as code. Every constraint applied here is a class of defect nobody has to catch later — and a well-bounded agent is also a cheaper one, because it searches less and guesses less.
Inline verifiers act during generation. "Checked while working, not after." They run while the agent produces work, block on failure, and hand back a correction the agent must resolve before it can proceed. This is the class that turns an unsupervised generator into a supervised one — and it is the class most organizations are missing entirely. Nearly everyone has allowlists, because identity teams have built them for years. Nearly everyone has dashboards. Almost nobody has anything that objects mid-flight.
Gate verifiers act before release. "Nothing ships unverified." Deterministic analysis fused with reasoned review, closing at a named human authority. A failed gate creates remediation work; it never transfers accountability to an agent.
Continuous verifiers act after release. Drift, regression, incident feedback. Necessary — and the last line, not the control, because by the time they speak the event has occurred. An estate whose whole AI story lives in this class has visibility without authority.
What we actually run
The reasonable response to a taxonomy is "show me yours." Here is how the four classes are built into the platform we deploy — the application layer itself, not a policy binder beside it.
Before generation: every workflow runs as a typed agent graph, and each step declares the tools it may call and the class of data it may see. A step that was never granted the claims writer cannot discover it. The PHI boundary is a fail-closed gate — protected data does not leave except through a declared egress, and when the gate cannot decide, it refuses.
During generation: every tool result is checked against its contract before the next step may consume it, and every consequential act — an adverse determination above all — halts at a human gate. The signer is named, the signature is part of the record, and the workflow cannot advance around it. In our own delivery of the platform we hold ourselves to the same class of control: protected lanes an agent cannot write into, and secret and scope checks on every diff.
Before release: a workflow is promoted into an operation through a gate the plan's own accountable owner signs, and our releases ship through a gate that seals its verdict against the exact bytes of the tree it verified — change one file and the verdict no longer covers it. Verification that cannot be bypassed casually is the point; a gate with a side door is a dashboard with a signature line.
After release: the record itself is the instrument — an append-only, hash-chained account of every step, tool call, and human signature, verifiable offline, years later, without trusting the system that produced it. Continuous monitoring watches for drift. But the record is what makes the watching mean something, because a finding that cannot be reconstructed is an anecdote.
No agent grades its own homework
Two rules decide whether any of this is real. The first is independence: no agent verifies its own output. A verifier is a different model lineage or a deterministic tool, and a named person owns the disposition. Risk officers recognize this instantly, because it is not a new idea — it is segregation of duties, applied to a new kind of actor.
The second is fusion. Deterministic checks — schemas, tests, secret scans, data-flow analysis — catch the known and the mechanical, identically every time, and cannot tell you whether the work does the right thing. Reasoned review judges intent and business logic, and on its own is not repeatable. Neither substitutes for the other; fused, they cover each other's blind spots.
The objection worth taking seriously
Verification adds work to an individual generation step and removes ambiguity from everything after it. The comparison that matters is the full delivery system: defects caught before integration, review time spent on material decisions, releases supported by evidence, and incidents that can be reconstructed quickly. Each program should measure that curve against its own baseline. Verification is what converts generated output into governed delivery capacity.
So the question to put to your own organization is not "do we have AI governance." It is an inventory: name every AI control you run, sort each one by when it acts, and mark whether it can block. Most organizations discover their entire answer lives in the after column. The ones that will run agents safely at scale are the ones whose answer starts with before.
Related briefings
AI staffing, recruiting, or an FDE team: choose the ownership model
A practical guide to selecting AI talent and implementation partners by the work, decisions, and production outcomes they will own.
Agentic workflows: an implementation guide for enterprise teams
Define the task, constrain the tools, test the failure paths, and give each consequential action an accountable owner.
Everyone Has the Models. Almost Nobody Has the Results.
Getting value from AI takes engineers who understand the business well enough to change how its work gets done.
