Putting an AI system into production does not bring governance to an end. It introduces a new set of operational risks – changing data, deteriorating performance, updated models and configurations, unexpected user behaviour and production incidents.
MLOps provides the engineering and operational practices needed to build, deploy, monitor and manage AI systems reliably throughout their working lives. In regulated environments, it turns monitoring, change control, traceability and governance requirements into controlled, repeatable operational processes.
Deployment is an event. Governance is a lifecycle.
What is MLOps?
Machine Learning Operations, or MLOps, brings together the people, processes and technology needed to move machine learning models from development into production and operate them reliably over time.
It extends well beyond deployment. MLOps can include automated training and testing, model, data and configuration versioning, controlled releases, production monitoring, human intervention, rollback and eventual decommissioning. For wider AI systems, it may also need to control prompts, knowledge sources, guardrails, third-party models and connected applications.
Academic research into MLOps describes it as a combination of practices, organisational roles, development culture and technical architecture for automating and operationalising machine learning products.
Effective MLOps for dependable production must therefore support the entire operating lifecycle, not simply the release pipeline.
Deployment is a milestone, not the end of governance
Pre-deployment testing tells you how an AI system performed under controlled conditions.
Production introduces reality.
Live inputs and user behaviour change. Integrations, dependencies and knowledge sources evolve. New exceptions emerge. Models, prompts, configurations and guardrails are updated. Performance that was acceptable during evaluation may not remain acceptable indefinitely, or across every population and use case.
The UK’s guidance for regulators defines the AI lifecycle as extending from inception, design and training through to deployment, operation, maintenance, governance and eventual decommissioning. It states that safety, security and robustness risks should be continually identified, assessed and managed throughout that lifecycle.
NIST’s 2026 research into deployed AI systems similarly distinguishes controlled pre-deployment evaluation from monitoring under real operating conditions. Post-deployment monitoring can reveal unexpected outputs, changing behaviour and consequences that were not visible before release. However, NIST also warns that current monitoring methods remain immature and fragmented.
This makes production governance a different challenge from simply moving an AI pilot into production.
A pilot asks; Can this work?
Production governance must keep asking; Is it still working as intended, for its approved purpose and within the limits we have agreed?
AI monitoring is necessary. But it isn’t AI governance
Monitoring and governance are closely connected, but they are not the same thing.
Monitoring provides information about how an AI system is behaving in production. It may reveal that:
- model performance has changed
- input data or user populations have shifted
- errors, exceptions or harmful outputs are increasing
- results vary materially between relevant groups
- latency or service availability has deteriorated
- human overrides or appeals are increasing
- a model, knowledge source or production dependency is behaving differently
The ICO warns that statistical accuracy is not static. An AI system tested against one population may perform differently when that population or its underlying behaviour changes. The ICO describes this as concept or model drift and recommends that organisations determine their monitoring and retraining approaches according to their particular circumstances and risks.
But detecting a change does not tell the organisation what to do about it.
That is a governance decision.
Governance determines:
- what constitutes an unacceptable change
- whether the system remains suitable for its approved purpose
- who owns the decision and has authority to act
- whether the system can continue operating
- whether a new model or configuration requires validation and approval
- when human intervention, rollback, restriction or suspension is necessary
- what evidence must be retained
MLOps connects monitoring and governance by turning those decisions into controlled, repeatable operational processes.
| Monitoring tells you | Governance decides | MLOps makes repeatable |
|---|---|---|
| Performance or behaviour has changed | Whether it exceeds agreed tolerances | Metrics, alerts and defined thresholds |
| Input data or the user population has shifted | Whether the system remains suitable for its approved purpose | Data, model and outcome monitoring |
| A new model or system configuration exists | Whether it can enter production | Versioning, testing and release gates |
| A production issue has occurred | What intervention is required | Incident, override and rollback workflows |
| A model or system component has changed | What evidence must be retained | Registries, logs and change histories |
This is the principle behind operational AI governance. Policy establishes what should happen. The operating model must make it happen consistently.
Weak production controls also create operational drag. Teams are forced to reconstruct what changed, repeat validation and chase approvals because evidence and accountability are scattered across different systems and people.
What MLOps needs to control in regulated environments
There is no single set of MLOps controls appropriate for every AI system.
Controls should reflect the system’s purpose, the decision or process it supports, the people it affects, the consequences of failure and the regulatory environment in which it operates.
The level of control should scale with risk and complexity. However, clear ownership, appropriate monitoring and end-to-end traceability become essential as soon as an AI system is operationally important.
Six areas deserve particular attention.
1. Performance, outcomes and drift
Teams need to define acceptable performance before deterioration occurs.
That means agreeing relevant metrics, tolerances and intervention triggers rather than simply collecting data in dashboards. Depending on the system, monitoring may need to cover technical performance, statistical accuracy, harmful outputs, differences between relevant populations, human overrides and the effect on customers or services.
The appropriate measures will vary significantly between an internal recommendation tool and a system influencing a material customer decision.
2. Data and input changes
An AI system does not have to be updated for its behaviour to become less dependable.
Data quality may deteriorate, input populations and user behaviour can change and relationships learned during training may become less relevant. Knowledge sources used by generative AI systems can also become outdated, incomplete or unreliable.
Monitoring must therefore consider the data and inputs entering the system, the outputs it produces and the outcomes that follow.
3. Model, data and system versions
When an issue appears, one of the first questions should be; what exactly is running?
Answering it requires traceability across the model, relevant data, prompts, configurations, knowledge sources, guardrails, dependencies and deployment history, where applicable.
Without that visibility, teams may be unable to reproduce an output, identify what changed or determine which version requires intervention.
4. Release approval, rollback and retirement
A technically deployable AI system is not automatically an approved one.
The release process should establish which tests, validation and approvals are required for the level of risk involved. It should also define what happens when those conditions are not met or when a material change requires the system to be reassessed.
Rollback must be practical rather than theoretical. The ICO’s AI audit guidance recommends saving models separately so organisations can revert to an earlier version where significant drift occurs.
Controls should also cover safe retirement – how a system will be decommissioned, how its dependencies will be managed and which data and records must be preserved.
5. Incidents, exceptions and human intervention
Not every unexpected result requires an AI system to be shut down. Equally, not every problem should be left to an engineering team to interpret while an incident is unfolding.
NIST’s AI Risk Management Framework places post-deployment monitoring alongside appeal and override mechanisms, incident response, recovery, change management and decommissioning.
Organisations should define these routes in advance – who can intervene, what authority they have and when a system should be overridden, restricted, rolled back or suspended.
6. Evidence and traceability
Governance is difficult to demonstrate when evidence must be reconstructed manually.
For every material change or incident, the organisation should be able to establish what triggered it, which version and system components were affected, what assessment took place, who made the decision and what happened afterwards.
The objective is not documentation for its own sake. It is evidence that the control process operated as intended.
How MLOps supports model risk management
MLOps and model risk management are connected, but they are not interchangeable.
Model risk management determines how risks created by models should be identified, assessed, governed and mitigated. MLOps provides the engineering and operational mechanisms that can put some of those controls into practice consistently.
The PRA’s SS1/23 provides a useful example from UK banking. Its five principles cover model identification and classification, governance, development and implementation, independent validation and model risk mitigants.
The supervisory statement applies to a defined group of UK-incorporated banks, building societies and PRA-designated investment firms with specified internal model approvals. It should therefore not be presented as a requirement for every organisation deploying AI. However, it illustrates the operating disciplines required when models influence important decisions or expose an organisation to material risk.
The PRA’s work also highlights the particular challenges created by AI and machine learning, including dynamic recalibration, model complexity and the need for effective performance monitoring.
MLOps can support this operating environment through:
- model and system inventories
- versioning and traceability
- automated testing and validation
- production monitoring
- controlled approval and release gates
- repeatable deployment, intervention and rollback
- evidence capture throughout the lifecycle
But MLOps does not determine the organisation’s risk appetite. It does not decide which systems require independent validation or whether a particular use of AI should be permitted. And it does not replace an AI governance framework.
Governance establishes the rules, responsibilities and accountability.
MLOps helps make the resulting controls operational.
A practical MLOps governance loop
Governed production AI can be understood as a repeating operating cycle:
Monitor. Assess. Approve. Change. Evidence. Repeat.
This is an operating pattern, not a regulatory framework.
Monitor
Collect the model, data, system and operational signals needed to understand how the AI system is behaving.
The objective is not to collect every available signal. It is to monitor the factors that could materially affect performance, reliability, compliance or risk.
Assess
Compare live behaviour and outcomes against agreed expectations.
Has a threshold been exceeded? Is the change normal variation or evidence of a wider problem? Does it affect particular users or populations? What are the implications for customers, compliance and the wider service?
Approve
Determine whether intervention is required and who has the authority to act.
The level of governance should reflect the significance of the change. A low-risk technical adjustment should not necessarily require the same validation and approval as a material change to system behaviour or purpose.
Change
Retrain, reconfigure, redeploy, restore an earlier approved version, restrict, suspend or retire the system as appropriate.
Automation can make these processes faster and more consistent without removing human accountability where review or approval is required.
Evidence
Capture what triggered the intervention, what was assessed, which model and system components were affected, who approved the action and what happened afterwards.
Then monitor again.
This continuous feedback loop is where MLOps becomes considerably more valuable than deployment automation.
Turning AI governance into an operating capability
Effective MLOps starts with more than the technology stack. Catapult CX connects an organisation’s governance requirements, risk tolerances and accountabilities to the engineering controls used to build, release and operate AI systems.
We can translate those requirements into automated testing and validation, version control across models and system components, controlled release and approval workflows, production monitoring, rollback and intervention processes and the evidence needed to show that those controls operated in practice.
The same engineering foundations can also improve the speed, efficiency and reliability of AI delivery.
For one identity-verification platform, Catapult CX implemented automated pipelines for more than 100TB of training-image data alongside real-time feedback loops. Following the wider re-engineering programme, verification accuracy increased from 50% to 97%, training time fell from two days to 1.5 hours, infrastructure costs reduced by more than 96% and platform throughput increased by 3,100%.
Read the MLOps identity-verification case study.
These results are not evidence of regulatory compliance. They demonstrate what becomes possible when model development, production operation and continuous improvement are treated as a repeatable engineering capability rather than a collection of disconnected manual processes.
What should you be able to prove after deployment?
For CTOs, CDOs, Heads of Data and AI and Transformation Directors, the most useful MLOps test is not a technology inventory.
It is whether the organisation can answer fundamental operational questions without first having to launch an investigation.
You should be able to establish:
- Which model and system configuration are live?
- Which data, prompts, knowledge sources and dependencies does the system rely on?
- Is it still being used for the purpose and population for which it was approved?
- What does acceptable performance and behaviour look like?
- How will you know when the system moves outside those limits?
- Who can approve a material change?
- What happens if the system needs to be overridden, restricted, restored to an earlier approved version or suspended?
- What evidence exists for changes, incidents, approvals and interventions?
- Who remains accountable after the original delivery team moves on?
- How will the system be safely retired and which data and records must be retained?
If you cannot answer several of these questions quickly, the priority is not another AI model. It is strengthening the production operating model around the systems you already have.
Strong MLOps closes that gap by making testing, deployment, monitoring, versioning, change control, intervention and evidence part of the normal AI lifecycle.
For regulated organisations, that is the important shift.
The goal is not simply to deploy more models. It is to create an AI delivery capability in which systems can move into production under control, remain dependable as conditions change and produce the evidence needed to demonstrate that governance is operating in practice.
FAQs about MLOps and regulated AI
What is MLOps?
MLOps, or Machine Learning Operations, brings together the people, processes and technology needed to develop, test, deploy, monitor and manage machine learning systems reliably in production.
It extends beyond deployment to include version control, automated testing, release approval, production monitoring, intervention, restoring an earlier approved version and lifecycle management.
Why is MLOps important in regulated industries?
AI systems used in regulated environments may require stronger control, accountability, traceability and evidence, particularly where they influence important processes, services or decisions.
MLOps can help put those requirements into practice through repeatable testing, monitoring, versioning, approval, deployment, intervention and rollback processes.
MLOps does not, by itself, make an AI system compliant.
What is AI model monitoring?
AI model monitoring is the process of observing how a model behaves in production. It can identify changes in performance, input data, user populations, errors, outputs and other indicators that could affect reliability or risk.
Monitoring may also need to cover the wider AI system, including prompts, knowledge sources, guardrails, third-party models, dependencies and human overrides.
The appropriate measures and monitoring frequency depend on the system’s purpose, the people it affects and the consequences of it behaving incorrectly.
What is the difference between AI monitoring and AI governance?
Monitoring tells an organisation what is happening.
Governance determines what is acceptable, who has authority to decide and what action must be taken when agreed limits are exceeded.
MLOps can connect the two by turning monitoring signals, governance rules and response processes into controlled, repeatable production workflows.
What is the difference between MLOps and model risk management?
Model risk management is the wider discipline used to identify, assess, govern and mitigate risks created by models.
MLOps is an engineering and operating discipline. It can support model risk management through inventories, testing, monitoring, version control, release controls, rollback and traceability. However, it does not replace governance, independent validation or accountable risk ownership.
Does MLOps apply to generative AI?
Yes, although the controls may extend beyond the underlying model.
For generative AI systems, MLOps may need to cover prompts, retrieval sources, knowledge bases, guardrails, evaluation methods, third-party foundation models and application logic. This broader discipline is sometimes described as LLMOps or GenAIOps, but the core requirement remains the same – the complete production system must be controlled and monitored throughout its lifecycle.
Who is responsible for governing AI systems in production?
Governing production AI usually requires input from data science, engineering, technology operations, security, risk, compliance and the business area using the system.
However, shared involvement should not mean unclear accountability. Organisations need named owners for system performance, risk decisions, production changes, incidents and eventual decommissioning.
Is MLOps required for regulated AI?
There is no general UK rule requiring organisations to adopt a methodology specifically called MLOps.
However, regulation, regulatory guidance and risk frameworks increasingly address lifecycle governance, ongoing monitoring, accountability, model risk, change management and evidence. Appropriate MLOps practices can provide the technical and operational mechanisms needed to implement many of those controls consistently.
When should an organisation introduce MLOps controls?
MLOps should be considered before an AI system reaches production, not added after problems emerge.
The level of control should reflect the system’s risk and complexity, but ownership, versioning, monitoring, intervention routes and traceability should be established before an operationally important system goes live.
How can an organisation improve its existing MLOps capability?
Start by identifying the AI systems already in production and testing whether the organisation can establish what is running, how it is performing, who owns it, how changes are approved and what happens when intervention is required.
The priority gaps will usually become clear across monitoring, versioning, release control, accountability, incident response and evidence capture.
