Governance After Deployment

Governance attaches to novelty. A new capability draws review boards, risk assessments, sign-offs, and a documented decision. This is appropriate, and it is also when the system is least dangerous, because at that point nothing depends on it.

The consequential period begins later — once the capability is routine, the people who approved it have moved on, and the organisation has quietly reorganised around its availability. Very little oversight is designed for that period.

The decay is structural, not cultural

It is tempting to describe this as discipline slipping. That framing is comfortable and mostly wrong. The decay is produced by ordinary organisational mechanics.

Approval is an event with a budget, an owner, and a completion date. Continued assurance is a process with none of those things. The reviewer who understood the system’s limitations has been promoted. The threshold set at launch was calibrated against a baseline nobody records any more. The vendor has shipped fourteen updates, none individually significant enough to trigger re-assessment. The exception queue that a human was meant to inspect has grown past the rate at which inspection is possible, and the inspection has become a sample, then a formality.

At no point did anyone decide to stop governing the system. Each step was locally reasonable. The aggregate is a system operating with materially less oversight than it was approved with, and no artefact that records the change.

The test that matters

There is a single diagnostic question we find more useful than most maturity assessments:

If this system had been wrong for six months, what would have told us?

The answers cluster. Sometimes there is a genuine detector — a monitored metric with a threshold and an owner, or a periodic review that reconciles outputs against an independent source. More often the answer is that a customer would have complained, that someone would probably have noticed, or that the annual audit would have picked it up. The last three are not detectors. They are the absence of one, described optimistically.

The value of the question is that it cannot be answered with policy. It requires pointing at a mechanism.

A control that produces no evidence is a preference. It may be a sincerely held one, and it will not survive contact with an auditor, an incident, or a court.

Evidence has to be a by-product

Assurance that depends on people remembering to produce evidence tends to fail at exactly the moment evidence matters, because that moment is usually busy.

The controls that hold up produce their artefacts as a by-product of operating. The evaluation runs on a schedule and writes its result whether or not anyone reads it. The threshold breach raises a ticket rather than an email. The model version, the configuration, and the data cut are recorded because the deployment pipeline records them, not because an engineer filled in a form. The override is captured because the system requires a reason to proceed.

This has a design implication that governance functions often under-appreciate: whether an obligation can be met is largely determined by engineering decisions made before the obligation was contemplated. If the system does not emit the record, no amount of policy will produce it retrospectively.

Deployment is a beginning

The framing we would argue for is straightforward, though it cuts against how most approval processes are built.

Deployment approval should be treated as the point at which ongoing obligations commence, not the point at which review concludes. That means the approval itself should specify what will be monitored, at what frequency, against what threshold, by whom, and what happens when the threshold is crossed — and those commitments should be as reviewable as the original risk assessment.

It also means accepting that some systems will need to be re-approved rather than merely maintained. A capability that has expanded in scope, absorbed adjacent decisions, or become depended upon by processes that did not exist at launch is not the system that was approved. Treating it as such is a documentation convenience rather than a governance position.

Why this is worth the effort

Institutional consequences arrive late and are difficult to reverse. By the time a regulator, a claimant, or a customer asks how a decision was made, the answer is fixed — it consists of whatever records happen to exist.

The organisations that answer that question well are rarely the ones with the most elaborate frameworks. They are the ones whose systems were built to leave a trail, by people who assumed someone would eventually ask.