We measure last quarter. The systems act this second.
I've spent three decades running the business of technology inside large banks, and for most of that time our risk tooling and our technology moved at roughly the same speed. Change was planned, released, and reviewed on cycles a human calendar could hold. A key risk indicator refreshed monthly was a reasonable proxy for reality.
That assumption just broke. Agentic systems — software that plans, decides, and acts — change their behavior in production, continuously. Against that, the standard apparatus of technology risk management is a set of lagging indicators: KRIs assembled after the fact, control tests run on samples, attestations signed quarterly about a world that no longer exists by the time the signature dries.
The uncomfortable truth is that the artifacts aren't the risk management. They're the exhaust of risk management as it was practiced when humans were the only actors. Keep producing them on a quarterly cadence while your systems act hourly, and the gap between what you report and what is actually happening becomes the largest unmanaged risk on your books.
Evidence computed, not assembled.
The alternative is to move the point of control from the review meeting to the runtime. Concretely, that means three things.
Controls become versioned, testable code. A control that lives in a policy document is an intention. A control expressed as policy-as-code executes on every relevant action, cannot be skipped by busy humans, and carries a version history the second line can challenge line by line.
Every execution self-evidences. When the control runs in the path of the work, the evidence of its operation is generated at the moment of execution — signed, immutable, mapped to the obligation it satisfies. Nobody assembles an evidence package before an exam. The evidence already exists.
Exposure is computed continuously. Residual risk stops being a rating negotiated in a workshop twice a year and becomes a number derived from live control performance, with drift visible the day it starts, not the quarter it's discovered.
None of this weakens governance. It's the same obligations with stronger answers — and it's the only architecture I can see that lets a regulated institution adopt autonomous systems honestly, because it's the only one where the control layer runs as fast as the thing being controlled.
The dual rail: run both, retire one on evidence.
You don't get to flip a switch on this, and you shouldn't ask anyone — least of all your second line or your examiners — to take a new system on faith. The transition I'd run is a dual rail over eighteen to twenty-four months: the traditional KRI and attestation rail keeps operating exactly as it does today, while the runtime rail comes up beside it, domain by domain.
The quiet weapon is the reconciliation log. For every domain on both rails, you record where the runtime evidence and the traditional artifacts agree and where they diverge, and you disposition every divergence. When reconciliation holds for consecutive cycles, you've built the evidentiary case to retire the manual rail for that domain — on data, not on trust. The transition has an owner and an end state. A permanent dual system is a failure, not a compromise.
Where to start matters. I'd begin on the agentic estate itself: it's where the gap between change velocity and assessment cadence is widest, and no legacy KRI regime has earned incumbency there. Prove the spine on the sharpest edge — a live inventory of agents and their permissions, autonomy tiers that are earned through evidence gates rather than granted by calendar, and one existing committee metric rendered directly from runtime data with full lineage. Ninety days to first value, then expand deliberately.
Same obligations. Stronger answers.
For institutions under heightened supervisory standards, this is not a workaround — it's strengthened compliance. The examiner conversation changes from "show me your testing" to "here is the decision log."
| Supervisory expectation | Today's answer | Runtime answer |
|---|---|---|
| Front line owns and demonstrates control effectiveness | Quarterly self-attestation, sampled testing, issues raised after the fact | Every execution self-evidences; the front line's controls prove themselves in production |
| Independent risk management challenges effectively | Second line reviews stale samples and challenges the testing approach | Second line challenges the policy itself — versioned, testable code — and monitors the full population |
| Timely escalation of breaches to risk appetite | Breach discovered at the next testing cycle; escalation measured in weeks | Breach blocked or flagged at execution; escalation measured in minutes |
| Talent and capacity commensurate with risk profile | Thousands of hours consumed producing and checking manual attestations | Those hours move to policy design, agent oversight, and hard risk judgment |
| Governance keeps pace with new activities | Agent activity governed by controls designed for human-speed change | Agents can't act outside policy — the control layer runs at the same speed as the agents it governs |
Where this goes wrong — named in advance.
I have more credibility proposing this if I name its failure modes myself. There are four I watch.
Start where the gap is sharpest.
If you run technology or technology risk inside a regulated institution, the question in front of you isn't whether autonomous systems arrive — they're already in your pipelines. The question is whether your control environment governs them or merely documents them after the fact.
My argument: pick the domain where the gap between change velocity and assessment cadence hurts most. Codify your top controls as policy. Instrument the evidence at execution. Run the dual rail, keep the reconciliation log, and let the data retire the old system domain by domain. Ninety days to the first control that proves itself in production. Everything after that is expansion.
Risk management at the speed of the business used to be an aspiration. For autonomous systems, it's the entry fee.