Installing governance is not the same as maintaining it. Governance drifts one change at a time, until the structure describes an organization that no longer exists. Why tighter enforcement is the wrong response, and what a maintenance architecture actually requires.
Last week we established the gap between a system audit trail and a decision audit trail, and why the organizations that close that gap are the ones that can defend an AI-influenced decision when it matters. This week addresses the question that follows immediately after. Not how to build it. How to make sure it is still accurate six months from now.
Because the organizations I work with aren't just asking how to install AI governance. They're asking why the organizations that do install it often find themselves, within months, holding a governance structure that no longer reflects how decisions are actually being made.
That is not a failure of intention. It is a failure of architecture. And it has a name: governance drift.
A decision audit trail is accurate when it reflects operational reality, when the documented consequence tiers, decision owners, validation requirements, and authorization structures match what is actually happening in the workflows they govern.
Governance drift is what happens when that correspondence breaks down. Not all at once. One change at a time.
A personnel change occurs. The individual named as the decision owner for a high-consequence AI-influenced workflow moves to a different role. The governance documentation is not updated. The workflow continues. The decision ownership now points to a position that is either vacant, restructured, or held by someone who was never briefed on the accountability they inherited.
A workflow is modified. The AI system deployed to classify behavior in one context is extended to a second: adjacent, similar, seemingly equivalent. The consequence tier and validation requirements were defined for the original use case. They were never formally applied to the extension. The new use runs under governance designed for something slightly different.
A tool is updated. The AI system receives a software update from the vendor. Its outputs shift: confidence thresholds, classification categories, output formats. This is the failure mode no human-employee analogy captures. People don't quietly become different operators between Tuesday and Wednesday. AI does. The validation requirements in the governance documentation reference the previous behavior. Reviewers are calibrating against a system that no longer works the way the documentation describes.
Volume increases. As the AI-influenced workflow matures and throughput grows, the validation step, designed for a lower volume, becomes operationally inconvenient. It is not formally removed. It is informally shortened, compressed, or in practice skipped for the classifications that seem obvious. The documented requirement exists. The actual practice has drifted from it.
None of these drifts are dramatic. Each one looks manageable in isolation. The problem is that they accumulate, and by the time something goes wrong, the governance structure describes a version of the organization that no longer exists.
Earlier this year, South Africa's government withdrew a draft national AI policy after it was discovered that the document contained fake citations, references to sources that do not exist, generated by AI. The problem was not that AI hallucinated. That is expected behavior, known and documented. The problem was that the output moved through a formal process without enough verification. No one with authority caught it before it became an official document.
That is governance drift at the institutional level. The structure existed. The review requirement existed. The actual practice had separated from it, quietly, incrementally, without anyone deciding to let it happen.
For organizations operating AI in consequential workflows, the parallel is direct. The governance documentation exists. Whether it reflects what is actually happening is a different question. And most organizations have not asked it.
The instinct, when governance drifts, is to treat it as a compliance failure. The policy existed. The people didn't follow it. Tighten enforcement.
That framing is wrong, and it leads to the wrong response.
Governance drift is not primarily a behavior problem. It is a structural problem. Governance structures drift because they are not designed with maintenance in mind. They are built as point-in-time documents, accurate at installation, with no mechanism to detect or correct the gap when operational reality changes.
Compliance enforcement addresses the symptom. It does not address the structure. Enforcing a policy that has drifted from operational reality does not make governance more accurate. It makes compliance theater more rigorous. The documentation still doesn't reflect what's actually happening. The decisions still aren't defensible when they need to be. The same is true of any enforcement mechanism downstream of the governance definition itself. Whether enforcement happens at audit time or at execution time, it enforces against whatever the governance structure currently says, and if the structure no longer reflects operational reality, faster enforcement just produces faster failure.
The organizations that maintain accurate governance over time are not the ones with the strictest enforcement. They are the ones that build maintenance into the governance architecture itself, so that when operational reality changes, the governance structure changes with it.
Maintaining an accurate decision audit trail requires three things that most installed governance structures do not have.
The first is change triggers. Defined events that automatically require a governance review before operations continue. A decision ownership role changes hands: governance review required before the new owner acts on a consequential AI output. A workflow is modified or extended: governance review required before the modification goes live. A tool is updated: governance review required to confirm that existing validation requirements still apply to the updated system behavior.
Change triggers do not require a governance team to monitor everything. They require the organization to define in advance which changes are consequential enough to require a governance review, and to build that requirement into the change management process.
The second is scheduled accuracy reviews. At defined intervals, quarterly for high-consequence workflows, semi-annually for lower-consequence ones, someone with accountability for governance accuracy confirms that the documented structure still reflects operational reality. Not a full rebuild. A structured verification: does the documented decision owner still hold that role? Does the validation requirement still match the actual workflow tempo? Does the consequence tier still reflect the actual operational stakes?
The third is ownership of the governance structure itself. This is the one most organizations miss. The four elements of a decision audit trail, consequence tiering, decision ownership, validation requirements, and authorization documentation, are owned by someone when they are built. Who owns their accuracy six months later?
In most organizations, no one does. The governance structure was installed by a function or an external engagement. That function moved on. The documentation exists. No one has accountability for whether it is still accurate.
Assigning a named role with defined accountability for governance accuracy, not just compliance but accuracy, is what separates governance that holds from governance that drifts.
For any AI governance structure your organization has in place, ask three questions.
What are the events that automatically trigger a governance review? If they are not defined, changes in your AI-influenced workflows are accumulating without a mechanism to capture them.
When was the last scheduled accuracy review conducted? If there is no scheduled review, the governance documentation is aging in real time with no mechanism to detect drift.
Who owns the accuracy of the governance structure itself? Not who runs decisions within it. Who is accountable for the documentation staying current, the decision ownership staying assigned, the validation requirements staying applicable?
If the honest answer to that third question is no one, then the structure is unmaintained. It may have been accurate at installation. Whether it is accurate now is unknown.
A governance structure that was accurate at installation and has not been reviewed is not a governance structure. It is a document. Documents do not defend decisions.