The Record Was Right the Day It Was Written

Most errors in an AI register are not mistakes. They are records that were true when they were written and stopped being true afterwards, through changes made by reasonable people for good reasons. That is what makes them hard to find, and it is why the checks most institutions run cannot find them at all: those checks confirm that the register agrees with itself, and a register can agree with itself perfectly while describing a system that no longer exists.

I have argued that every AI governance control attaches to a description of a system rather than the system itself. This piece is about how the description goes wrong when nobody does anything wrong.

A record that was true in June

Here is an illustrative case, and it is illustrative precisely because nothing about it is unusual.

An internal assistant drafts correspondence for an operations team. Its register entry is careful and complete: business owner named, purpose stated, risk tier argued, approval minuted, the model it calls recorded by name and version. Everything in the entry was verified when it was written.

In June the primary model provider starts rate limiting during peak hours, and the drafts begin to stall. An engineer does exactly what a good engineer should. She configures a fallback route, so that when the primary provider is saturated, requests go to a second provider instead. The stalls stop. Nobody complains.

By August the second provider is serving roughly a fifth of production traffic. Its data processing terms were never reviewed. It was never assessed. The register still names one model, because nobody thought of a resilience fix as a change to what the system is.

No one in this story was careless. The record was right the day it was written. The engineer solved a real problem. The approval was valid for the system that was approved. And the institution is now running a capability one fifth of which no control has ever looked at.

The dangerous change is the reasonable one

Unauthorized changes get caught. They trip access controls, they show up in change management, someone asks who did this. The changes that open the gap are the sanctioned ones: the resilience fix, the library upgrade, the vendor's quiet model refresh, the integration added to save someone an afternoon. Each passes its own local review, because locally it is a good decision. None of them is filed as a change to the AI estate, because nobody making it is thinking about the AI estate.

So drift is not a discipline problem, and more discipline will not fix it. You cannot instruct a thousand reasonable people to anticipate which of their sensible decisions alters the description in a register they have never seen.

Your checks prove the register agrees with itself

Now look at what an institution actually does to keep its register honest. It reviews entries against its AI policy. It runs attestations, where owners confirm their entries are current. It checks that required fields are filled, that tiers match the policy's criteria, that approvals have not lapsed.

All of that is worth doing. None of it would have caught the fallback route.

Every one of those checks compares documents to documents: the register against the policy, the entry against the owner's memory, the tier against the criteria written by the same function that wrote the register. An institution that checks its register against its own policy is checking that it wrote two documents consistently. It proves nothing about the estate.

A register can be complete, internally consistent, attested by every owner, and wrong. The attestation in the case above would have come back clean, because the owner sincerely believed the entry was true. Sincerity is not evidence.

The only kind of check that can catch drift compares the record against something its author did not write. Most institutions already own such a thing, and most have never thought to point it at the register.

Latency nobody measures

A comment on an earlier piece named the deeper problem better than I had: the latency between operational reality and management reality. The estate changes continuously. The register changes when someone remembers to change it. Governance runs on the register.

Finance would never tolerate this. A trading desk knows the staleness of its market data to the millisecond, because a price that is late is a price that is wrong. Nobody in most institutions can say how stale the AI register is, in days or in months, and what is unmeasured is unbounded. Governance is not running against yesterday's reality. It is running against a yesterday of unknown age.

The test you can run this quarter

Take the five most consequential AI capabilities in your register. For each one, ask a single question: when was this record last compared against the running system, by whom, and against evidence that the record's author did not produce?

Then ask the owner to show you, not tell you, that the record is still true. If showing means opening the register, or the policy, or the last attestation, you have learned only that the register agrees with itself. That is consistency, not truth. If nobody can show anything at all, you have your finding, and it applies to the other entries too.

The position I hold

A record is a claim about a system at the moment it was written. Every check that compares the record to other documents tells you the claim was made consistently. Only a check against something the author did not write tells you whether it is still true.

The record was right the day it was written. Governance that cannot tell you whether it is right today is governing the day it was written.