An AI model that has passed through a rigorous development governance process, including bias review, explainability documentation, validation testing, and deployment approval, is a model that was well-governed at one moment in time. The moment it entered production and began making decisions in a live operational environment, a different governance problem started. Most enterprise governance frameworks are designed for the first problem. Very few have been designed for the second.
This is not a minor gap. It is the difference between governing an artefact and governing a continuously operating system. The implications for AI risk are substantial and are accumulating in most large enterprises right now.
What development governance does and does not cover
Development governance is a quality gate. Its function is to assess whether a model is fit to deploy: whether it was trained on appropriate data, whether it behaves as expected across relevant test populations, whether its failure modes are understood, and whether its outputs can be explained to a sufficient standard for the deployment context.
That assessment is valuable and necessary. It is also inherently retrospective. It answers the question of whether the model was acceptable at the moment it was evaluated. It does not answer, and is not designed to answer, the question of whether the model remains acceptable six months into a production environment where transaction patterns have shifted, cardholder behaviour has evolved, and adversarial actors have adapted their methods to exploit its known characteristics.
The assumption embedded in most development governance frameworks is that a model deployed in a stable environment will continue to perform as validated. For AI deployed in operational environments, including payments, fraud, credit, and insurance, that assumption is structurally wrong. The environments are not stable. They change continuously, and the models that operate in them degrade continuously as the distance between production conditions and training conditions grows.
The volume problem
Development governance operates at human decision cadence. A governance committee reviews a model before deployment. An explainability audit produces documentation. A validation team runs test scenarios. These are appropriate governance mechanisms for decisions made at the pace of committee deliberation.
They do not function as governance for a model making ten thousand decisions per second in a live transaction environment. A quarterly model review cannot identify the degradation pattern that emerged three weeks ago and has been accumulating losses since. A pre-deployment bias assessment does not detect the distributional shift in a customer population that has changed its spending behaviour in ways the original training data did not include.
The volume problem is not solved by increasing the frequency of conventional governance reviews. A monthly review of a model making ten thousand decisions per second is still reviewing the aggregate consequences of approximately twenty-six billion decisions after the fact. The governance mechanism appropriate for that decision velocity is not a faster version of committee review. It is a different architecture entirely.
What production governance requires
Production governance for operational AI has three components that are structurally different from their development governance counterparts.
Continuous monitoring is the operational equivalent of the development validation process, but running against live production data rather than test data, and updating on a frequency proportionate to the decision volume of the model. For a high-volume fraud model, daily performance metrics are the minimum. The monitoring must cover both detection effectiveness and false positive rate. Both dimensions degrade, and both have financial consequences that accumulate quickly at scale.
Automated degradation detection with defined thresholds is the production governance mechanism that replaces the deployment approval gate. Rather than a one-time decision about whether a model is acceptable to deploy, it is a continuous decision about whether the model remains within its acceptable operating parameters. When it crosses a defined threshold, the governance response is automatic: escalation, investigation, and refresh trigger. The threshold is the governance framework, and it operates without the latency of committee review.
Refresh governance manages the cycle from detection to redeployment: data preparation, retraining, validation, deployment, and verification that the refreshed model has corrected the degradation that triggered the cycle. Without defined refresh governance, degradation detection produces alerts that are not consistently acted on, and the gap between detection and correction remains open longer than it should.
The question organisations need to answer
The honest governance question for any organisation running AI in operational environments is not whether the development governance process was rigorous. It probably was. The question is what is governing the model right now, in production, today, and whether the answer is a continuous monitoring and intervention capability or an assumption that the development governance review from the last deployment cycle is still sufficient.
Most organisations that have asked that question clearly have found that the honest answer is the latter. The governance investment that development processes receive has not been matched by equivalent investment in production governance infrastructure. The result is AI that is well-governed in theory and inadequately governed in practice, in the environments where governance matters most.
