Then the model is deployed. And the governance discipline that applied during development does not automatically follow it into production.
Why This Matters Now
Model risk management programs in financial services, AI governance programs in regulated industries, and EU AI Act compliance programs in European enterprises have all invested heavily in the model development lifecycle. Pre-deployment testing, validation, documentation, and approval processes have matured significantly. The discipline applied to AI systems before deployment is generally the best-governed phase of the AI lifecycle.
Deployment is where that discipline ends for many programs. The model enters production, begins making decisions, and operates under significantly lighter governance than was applied during development. Configuration changes, integration modifications, input distribution shifts, and operational environmental changes accumulate in the deployed system without triggering the governance review that would have applied to an equivalent change during development.
The most carefully governed AI system is the one that has not yet been deployed. The risk surface expands the moment deployment occurs, and in most organizations, governance coverage contracts at the same moment.
The Governance Problem Beneath the Surface
The governance asymmetry between development and deployment reflects a structural feature of AI development organizations. Development occurs in controlled environments under the oversight of teams specifically responsible for model quality and governance. Deployment places the model in the hands of operations, infrastructure, and business teams whose primary accountability is service availability and business performance, not model governance.
The handoff from development to deployment is the point at which AI governance most frequently fractures. The model's behavior in production is determined not just by its design but by its operational environment: the data it receives, the infrastructure it runs on, the configuration applied to it, and the downstream systems that consume its outputs. All of these operational factors can influence model behavior in ways that development testing did not capture and that deployment governance frequently does not monitor.
Model governance in production requires a different set of disciplines than model governance in development. Most AI governance programs have built the development disciplines and have not yet built the production disciplines.
What This Actually Means in Enterprise Practice
Configuration Changes Post-Deployment Create Unreviewed Variation
Deployed AI systems are configured through parameters that affect their behavior: decision thresholds, feature preprocessing steps, output rounding, and integration settings. These configuration parameters are often managed by operations teams rather than model development teams, through change management processes that treat configuration changes as operational rather than governance events. A threshold change that shifts decision boundaries for ten percent of cases may not trigger the model governance review that an equivalent change to the model itself would require.
Input Distribution Shift Is Silent Degradation
Models trained on a specific data distribution perform best on inputs that resemble their training data. As the world changes, the inputs a production model receives shift away from the training distribution. Customer behavior evolves. Economic conditions change. Regulatory environments shift. The model's calibration, which was accurate at training time, becomes progressively less accurate as input distributions drift. Without production monitoring specifically designed to detect distribution shift, this degradation is invisible until it produces a detectable error rate or a consequential failure.
Distribution shift is the most common post-deployment risk and the least monitored. It is silent, gradual, and detectable only through instrumentation that most organizations have not specifically built for their AI systems.
Integration Changes Alter Effective Model Behavior
AI models in production receive inputs through integration layers that preprocess data before it reaches the model. When those integration layers change, the effective inputs the model receives change, even if the model itself is unchanged. A data pipeline update that changes how missing values are handled, a feature engineering change that modifies how a continuous variable is binned, or a data source change that introduces systematic differences in input quality can all materially alter model behavior without any change to the model itself. These integration changes are often managed outside the AI governance program entirely.
Operational Feedback Loops Introduce Unintended Learning
In some AI deployment architectures, operational data is used to retrain or update models on an ongoing basis. When the model's own outputs influence the data used to retrain it, feedback loops can introduce systematic biases that compound over time. A recommendation model that learns from user behavior will learn to recommend content that produces the behavior the model was optimized for, which may not be the behavior the organization intended to encourage. Feedback loop governance is a deployment-time risk that development testing does not address.
How Different Teams See This: Where They All Miss
The deployment handoff is where AI governance most often stops being someone's job. Model development teams hand off to operations. Operations manages availability, not behavior. AI governance reviews at milestones. Continuous post-deployment governance falls in the gap between all three.
Framework Control Reference
The specific control obligations most relevant to this topic across primary frameworks. Use these references in governance discussions, vendor assessments, and audit responses.
These controls share a common requirement: the obligation is active, not declarative. Documenting alignment is not the same as demonstrating it.
The Enterprise Reality Gap
The enterprise reality gap in AI deployment governance is the space between the governance discipline applied during model development and the governance capability applied to the deployed model in production. Most organizations can demonstrate comprehensive pre-deployment governance. Fewer can demonstrate equivalent post-deployment monitoring, configuration change governance, and distribution shift detection.
The gap is largest in organizations that deployed AI systems before post-deployment governance programs were established. These systems are operating in production under governance frameworks designed for new deployments, applied retrospectively to mature systems with years of operational history and accumulated configuration changes that were never specifically reviewed.
Every AI system that has been in production for more than twelve months has accumulated post-deployment changes that may not have received governance review. The older the deployment, the larger the gap between development-time governance and current operational reality.
Enterprise Scenario: The Configuration Change That Changed Everything
The change was technically minor from a data engineering perspective. Its effect on model behavior was significant. Because the change was processed as a data pipeline change rather than a model governance event, no governance review was triggered. The behavioral shift was identified three months later through a routine bias audit that was not specifically designed to detect it.
Industry Signal
Financial services model risk management examinations have focused increasingly on the robustness of post-deployment monitoring programs, including the completeness of monitoring coverage, the triggers for model revalidation, and the governance processes for operational changes that affect model behavior without constituting model changes in the technical sense. Regulators have found that many organizations have strong initial validation processes and inadequate ongoing monitoring programs, creating a governance gap that accumulates over the model's operational life.
The examination finding that has emerged most consistently is not that models were poorly validated before deployment. It is that well-validated models were inadequately monitored after deployment, creating undetected behavioral drift that the organization could not demonstrate it had governed.
Enabling Capabilities
- Production model monitoring: Continuous monitoring of model behavior in deployment including distribution shift detection, performance disaggregation, and behavioral stability tracking.
- Deployment governance integration: Change management processes that route operational changes affecting model inputs or configuration through AI governance review before implementation.
- Model performance alerting: Automated alerts triggered by behavioral signals that indicate potential model degradation or unintended behavioral change.
- Champion-challenger frameworks: Production architectures that allow model versions to be compared in operation, enabling controlled assessment of behavioral changes between model versions.
- AI governance platforms: Tools that connect model registry, monitoring infrastructure, and governance workflows to produce integrated post-deployment governance coverage.
A Practical Starting Point
Identify your highest-risk deployed AI systems and audit the post-deployment governance gap. For each system, document all configuration changes made since deployment, all integration changes affecting model inputs, and all data source changes. Assess whether any of these changes received AI governance review. The proportion that did not is the post-deployment governance gap for that system.
Then establish governance triggers for post-deployment changes: what categories of operational change require AI governance review before implementation? Build those triggers into existing change management workflows so future changes are captured.
You cannot retroactively govern changes already made. You can stop the gap from growing by building governance triggers into the operational change processes that currently bypass AI governance review.
Questions Leaders Should Be Asking
- What changes have been made to our highest-risk AI systems since their initial deployment, and which of those changes received AI governance review?
- How do we detect distribution shift in the inputs our production AI systems receive, and what is the process when distribution shift is detected?
- What operational changes to data pipelines, configurations, and integrations affecting our AI systems require AI governance review before implementation?
- When did we last perform a substantive revalidation of our deployed AI systems against current input distributions rather than historical test sets?
- Who is accountable for post-deployment AI governance, and is that accountability distinct from the teams responsible for operational system management?
What to Require From Vendors
Ask directly:
"What post-deployment monitoring capabilities does your platform provide for detecting behavioral change in deployed models, and what is your process for notifying customers of platform updates or data changes that may affect deployed model behavior?"
Expect as evidence:
- Specific monitoring capabilities for distribution shift detection in production
- A defined notification process for platform changes that may affect customer model behavior
- Documentation of how configuration and integration changes are governed in your platform
- Post-deployment monitoring coverage that addresses governance requirements, not just operational performance
A vendor whose post-deployment monitoring addresses system availability and latency without addressing behavioral stability and distribution shift has built operational monitoring. Governance monitoring requires a different design.
Demonstrating Diligence
- Documentation: Post-deployment governance program documentation; change management integration records; revalidation history for deployed models.
- Process: Defined triggers for post-deployment governance review; distribution shift detection with response procedures; regular behavioral revalidation against current input distributions.
- Technical evidence: Production monitoring outputs including distribution shift metrics; configuration change audit logs with governance review records; revalidation study results.
Post-deployment governance diligence requires showing that your monitoring program covers behavioral stability, not just operational performance. The EU AI Act's post-market monitoring requirement is not met by uptime dashboards.
Closing Perspective
The best-governed phase of most AI systems' lives is the period before deployment. The riskiest phase, because it is the period when the system is making actual decisions affecting actual people, is after deployment. That inversion is the central governance challenge in AI lifecycle management.
Closing the gap requires extending the governance discipline of the development phase into the operational phase. This means building monitoring programs that detect behavioral change, governance processes that capture operational changes that affect model behavior, and accountability structures that maintain active governance over deployed systems rather than treating deployment as the completion of governance.
The investment is significant. It is also the investment that determines whether an AI governance program governs AI systems or merely governs the process of building them.
The model you govern before deployment and the model you govern in production are both necessary. Most organizations have built the first. The second is where the risk lives.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.