Institutions are preparing for an AI examination as though it were an event on a calendar. It is not. The evidence either exists at the moment the agent acts, or it does not exist at all.

I have sat through a lot of examination preparation over the years, and it always has the same rhythm. A date appears. A programme forms. Somebody builds a tracker. For eight weeks, a group of capable people assemble artefacts, reconcile them against a request list, and rehearse the answers. The examiner arrives, works through the file, and issues findings. The programme disbands. The tracker goes stale.

That rhythm works when the thing being examined holds still between examinations. A lending policy holds still. A capital model holds still, more or less, and when it changes there is a change record with a date on it and a person who signed it.

An autonomous agent does not hold still, and this is the part that has not landed yet.

The artefact you validated is not the thing that is running

An agent chooses its own route through the tools available to it. It calls other agents. It reads sources that were not in scope when it was reviewed. Its behaviour on Thursday can differ materially from its behaviour on Tuesday with no code change, no release, and no ticket to point at — because a tool returned something different, or the context window filled differently, or an upstream agent phrased a handoff another way.

So when an examiner asks what the agent did in March, the honest answer in most institutions today is a reconstruction: here is the application log, here is the prompt template we believe was in force, here is the model version we think was deployed, here is a person who remembers approving something adjacent. Every step of that chain is an inference, and every inference is a place where the examination goes badly.

A log is not evidence

This distinction is worth being precise about, because a lot of programmes are being run on the assumption that logging is the same as evidence.

A log records that something happened. Evidence establishes what was permitted, what was applied, what was decided, and by whose authority — in a form that a party who was not present can verify without taking your word for it.

Concretely, an evidentiary record of an agent decision needs to carry, at minimum:

• The action proposed, normalised to a form that does not depend on which platform the agent was running on.
• The behavioural contract in force for that agent at that moment, identified by revision.
• The scoring model applied, identified by version — because a score of 0.72 means nothing without knowing what produced it.
• The thresholds in force at that timestamp, snapshotted rather than looked up later.
• The enforcement decision and the level at which it landed.
• The accountable owner, resolved at the time, not reconstructed from an org chart that has since changed.
• A signature over all of it, on a chain that breaks if anything is modified afterwards.

None of that can be added retrospectively. Every one of those fields is only available at the moment the decision is made. This is why runtime is not a preference or an architectural style — it is the only point in the lifecycle where the evidence physically exists.

What the supervisors have actually said

The regulatory picture stopped being ambiguous some time ago. The Federal Reserve extended model risk governance explicitly to AI agents operating in production, with continuous monitoring, behavioural drift detection and examination-ready evidence packages named as requirements rather than aspirations. The EU AI Act put Articles 9 through 15 in force for high-risk systems, with penalties calibrated to global turnover. The FCA published guidance for agents touching payments and consumer credit. The CFPB and OCC made clear that fair lending law applies to an agent's decision regardless of whether anyone intended the outcome.

And IOSCO published a supervisory toolkit for AI examination — a document, not software. Which is the more interesting fact, because it tells you where the supervisory community actually is: they have agreed what should be examined, and they do not yet have the instrument to examine it.

The uncomfortable implication

If you accept the argument to this point, one conclusion follows that most governance programmes are not structured to handle.

An institution that instruments its agents today has evidence starting today. It does not have evidence for last quarter, and no amount of programme effort will produce it. The window for the period you are currently operating in closes continuously, every hour, whether or not anyone has approved a budget.

That is what the phrase means. There is no date to prepare for, because the record is being written or not written right now. When the examination does arrive, it will look backwards at a period during which you either had the instrumentation or you did not.

A rating of four on a governance readiness scale does not mean you are going to receive a finding. It means the finding is already written. You have not seen it yet.

Vyasa Murthy is the founder of Venture Vertex LLC and the author of No Exam Date.

The GPU utilisation problem is a working capital problem wearing a technology costume. The quality problem underneath it is worse, because a cluster producing wrong answers at high utilisation looks healthy on every dashboard you own.

Nobody commissions a manufacturing plant without knowing the unit economics of every line in it. You would know which lines were profitable, which were marginal, and which were running because somebody started them and nobody ever stopped them. That is not sophisticated financial management. It is the minimum condition for operating a capital asset.

AI infrastructure got bought differently, and for understandable reasons. It was bought fast, on strategic urgency, in the middle of a capability race, with a business case written at the level of the entire estate. That was defensible in year one. In year three, when the CFO asks which half of the spend is working, the honest answer in most organisations is that nobody has ever measured it at that resolution.

Start with the arithmetic

Take a hundred-thousand-GPU cluster. At current acquisition costs that is three to five billion dollars of investment. At the industry-average utilisation figure that keeps showing up in operator data — around eighteen per cent — eighty-two thousand of those GPUs are producing nothing at any given moment. Call it two and a half billion dollars of idle capital, before you count the power bill for keeping it available.

This is not a benchmark or a projection. It is arithmetic applied to public pricing and observed utilisation. Run it against your own estate and the shape does not change, only the magnitude.

The leverage point is what makes it interesting. Ten points of utilisation on that cluster is ten thousand GPUs. Buying that capacity costs roughly three hundred million dollars and takes the better part of a year to land. Recovering the same capacity from hardware you already own is an operational exercise measured in weeks. The gap between those two options is the entire argument.

The second problem is worse because it is invisible

Now consider a cluster running at eighty-five per cent utilisation — a number any operator would be pleased with — on an agent whose output quality has silently drifted from ninety-two to sixty-seven.

The effective utilisation of that cluster is zero. The spend is entirely real. The outputs are wrong. And because nothing crashed and no threshold was breached, no alert fired. Industry mean time to detect that kind of drift is measured in hours, and the honest version is that a lot of it is detected by a customer complaint rather than by an instrument.

This is why utilisation on its own is a misleading metric, and why the number that actually matters is utilisation multiplied by quality. A busy cluster producing degraded output is more expensive than an idle one, because you are paying for the compute and then paying again to fix what it produced.

Behavioural drift is an economic signal

Here is the reframe that changes how the problem gets managed. Drift is usually treated as a quality issue, which routes it to an engineering team and a backlog. Treated as an economic signal, it routes to the person who owns the budget, and it moves.

The mechanism is straightforward once you accept the framing. Track behavioural dimensions continuously using statistical process control — CUSUM has run manufacturing quality for sixty years and works perfectly well here. When a dimension drifts, adjust the workload's economic score in real time. A workload that is technically healthy but producing degraded output stops scoring as if it were fine, immediately, without waiting for a human to notice.

Express the result as a single ratio: value produced per hour over cost per hour. Below one, that workload loses money every hour it runs. Above 1.4, it is your best use of capital. The point of the ratio is that it produces an action rather than a conversation.

Why the cuts always land in the wrong place

The predictable failure mode, when the budget pressure finally arrives, is that the cuts land on whatever is easiest to switch off rather than whatever is least productive. Which in practice means the workloads killed are the ones with the weakest internal sponsor, not the ones with the weakest economics.

That is not a failure of will. It is a failure of instrumentation. If you cannot rank workloads by return, you will rank them by politics, because politics is the only ranking available.

Give an organisation a per-workload economic score and the conversation changes shape entirely. It stops being a negotiation about whose project survives and becomes an operational review of a portfolio. That is a much better meeting, and it is the meeting the plant manager has been having for a hundred years.

Vyasa Murthy is the founder of Venture Vertex LLC and the author of No Exam Date.

Policy documents describe intent. A behavioural contract is the machine-enforceable version: what this agent may do, scored across twelve dimensions, with a graduated response and a signature over the result.

Most enterprise AI governance today lives in a document. The document says the right things: agents shall operate within approved scope, sensitive data shall be protected, human oversight shall be maintained for consequential decisions. It is reviewed by a committee, approved, published, and then plays no part whatsoever in what happens at three in the morning when an agent decides to release a payment.

The gap between an approved policy and an enforced control is the whole problem. Closing it means expressing governance intent in a form a machine can evaluate in single-digit milliseconds, and doing it without collapsing into a rules engine that anyone with a novel phrasing can walk around.

Twelve dimensions, not one score

The instinct is to produce a single safety number. Resist it. A composite score with no structure tells an operator that something is wrong and nothing about what.

The dimensions that matter in regulated environments, in our experience, are these: authority claims, governance bypass, financial action, harm potential, personal data access, deception patterns, cross-agent delegation, retrieval provenance, compliance boundary, intent drift, data classification, and temporal context.

Score each of those independently and two useful things happen. First, the verdict becomes explicable — not "risk 0.78" but "authority claims elevated to 0.91 while provenance fell to 0.34," which a compliance officer can read and act on. Second, the dimensions can carry different weights in different industries, because what constitutes an escalation in banking is genuinely different from healthcare or defence.

The scoring is not the interesting part. The ladder is.

Binary allow-or-block is the single most common design mistake in this space, and it fails in both directions. Set the threshold tight and you block legitimate work until an operator disables the control. Set it loose and you have a monitoring product wearing an enforcement badge.

A graduated ladder solves this. Five levels, roughly: observe, flag, human-in-the-loop, block or freeze, and decommission — with the top level writing back to the identity platform to reduce the agent's permissions automatically. The important property is that most decisions land in the lower levels, which means the control stays switched on, which means it is there on the day it matters.

The other important property is that the response can account for history. The same prompt from an agent with no prior violations and an agent that has accumulated governance debt over a thirty-day window should not receive the same treatment. That is behavioural intelligence rather than rule matching, and it is the difference between a control that adapts and one that gets gamed.

What gets written down

Every verdict produces a record, and the contents of that record are what determine whether any of this survives an examination.

• The scorer version. A score is meaningless without knowing what produced it. Pin the engine version to the record.
• The configuration hash. Governance configuration changes. The record must say which configuration was in force.
• The threshold snapshot. Thresholds move as an institution tunes its posture. Capture them at decision time rather than looking them up later.
• The effective-from timestamp. So the configuration in force on any historical date can be established without archaeology.
• A signature over all of it, on a hash chain that breaks if anything is altered.

That last property is the one that matters most and is most often skipped. The record has to be independently verifiable — a third party should be able to confirm it has not been modified without trusting the vendor that produced it. A governance record you have to take a vendor's word for is not evidence. It is marketing with a timestamp.

Why the boundary is the wrong place to stand

Existing security tooling sits at the perimeter and watches instructions arrive and results leave. That was a reasonable place to stand when the thing in the middle answered one question at a time.

It is no longer sufficient, and the reason is structural rather than a matter of vendor capability. The attack classes that matter for agentic systems now happen mid-session, inside the execution loop. An agent whose objective has been corrupted by a poisoned tool response looks entirely normal from outside: every individual turn is clean. The attack exists only in the arc across turns.

Catching it requires scoring every instruction, every tool response as it re-enters the loop, and every turn against a session baseline. That is an inside-the-loop position. You cannot get there from the perimeter, no matter how good the perimeter product is.

The test

Here is the question I would ask of any runtime governance design, including ours. Take a consequential decision an agent made ninety days ago. Can a person who was not present establish what was proposed, what was permitted, what was applied, what was decided, who was accountable, and whether the record has been altered — without asking anyone to trust the vendor?

If the answer is yes, the design is sound. If the answer requires a person to vouch for a step, it is a monitoring product, and it will be found out at the worst possible moment.

Vyasa Murthy is the founder of Venture Vertex LLC and the author of No Exam Date.

Every enterprise software category eventually produces a challenger that asks the customer to migrate. In validated environments, that pitch is not brave. It is a misunderstanding of what the customer is protecting.

When we started building in drug safety, the obvious commercial move was to position against the incumbent safety database. The incumbent is expensive, the workflows are dated, and there is a genuine capability gap on the intelligence side. Every instinct trained by a decade of enterprise software says: build the modern replacement and go take the seat.

We did not, and the reasoning generalises well beyond pharmacovigilance.

What the customer is actually protecting

A validated safety database is not just software. It is a validated system in the regulatory sense — qualified, documented, audited, connected to every downstream submission process the company owns, and named in inspection responses going back years. Replacing it is not a migration project. It is a revalidation programme with regulatory exposure attached, run by a team whose day job is already oversubscribed.

So when a vendor opens with "replace your system of record," the head of pharmacovigilance is not hearing a product pitch. They are hearing a proposal to take on institutional risk in exchange for features. That conversation ends politely and quickly, and it should.

The same structure appears everywhere in regulated enterprise. The core banking platform. The identity provider. The general ledger. The claims system. These are not chosen on merit any more; they are load-bearing, and the cost of replacement is dominated by revalidation and regulatory exposure rather than by licence fees.

The layer that is actually missing

Once you stop trying to take the seat, the real gap becomes visible. The incumbent holds the record extremely well. What it does not do is read the narrative, run causality assessment in seconds rather than hours, rank a signal queue by anything other than volume, or produce a benefit-risk assessment from case data.

That is an intelligence layer, and it sits above the record rather than in place of it. It reads from the system of record, enriches what it finds, and writes back in the formats the record already understands. The customer keeps the validated system, keeps the inspection history, keeps the downstream integrations, and gets the capability they were missing.

The commercial consequence is significant. The addressable population is not "customers willing to migrate," which is a small and reluctant group. It is "customers who already own the incumbent," which is the entire installed base.

The same logic across the portfolio

This is not a pharmacovigilance-specific insight, and once we saw it clearly, it shaped everything else.

• Runtime governance for AI agents does not ask an institution to change its agent platform. It normalises actions from whatever platform is running and governs them from the decision path.
• Factory intelligence does not ask an operator to change their scheduler or their GPU vendor. It reads existing telemetry as a side-channel observer and never touches the inference path, because anything that adds latency gets removed the first time a workload misses an SLA.
• Examination tooling does not require the institution to be instrumented at all. Where a governed estate exists, it reads the evidence. Where it does not, it runs as a structured examination and still produces a comparable score.

The discipline this imposes

Choosing the augmentation position is easy to say and harder to hold, because it forces you to be genuinely good at integration rather than merely adequate. You inherit someone else's data model, someone else's API, someone else's release schedule, and someone else's edge cases. None of that is glamorous and all of it is real work.

It also forces honesty about where the value actually is. If your product only wins because the customer had to throw away their incumbent to use it, you never find out whether the capability was worth anything on its own merits. Sitting on top of a working system of record is a harsher test, and passing it is a much better signal.

Vyasa Murthy is the founder of Venture Vertex LLC and the author of No Exam Date.