AI Lifecycle Governance

In 2022 a research team led by Daniel Vela and Oleg Pianykh set out to measure something most organizations assume away: what happens to a machine learning model after it is deployed and left alone. They took 32 datasets from four industries, healthcare operations, transportation, finance and weather, and trained four standard types of model on each. Then they watched the 128 model and dataset pairs age¹.

Before reading on, make a guess. Of those 128 pairs, how many lost quality over time? A quarter? Half? Nine in ten?

The answer was 91 percent. Many of the models that degraded had been highly accurate right after training, which is exactly the moment at which an approval is usually signed¹. Nobody touched these models. The world they were describing moved, and the models did not move with it.

In a real organization, the world is not the only thing that moves. Teams swap in a newer model, connect a new data source, open the system to more users and give it permission to act. Each change is sensible on its own. Together they can turn an approved system into one that nobody has ever assessed.

The core idea

Many organizations still govern AI with a stamp. A committee reviews the system, signs, and the file closes. That governs the system as it was approved. Lifecycle governance follows the system from the first idea to the day it is switched off, and so governs the system as it actually runs. It is the set of policies, decisions, controls, reviews and accountability applied across the whole life of an AI system.

None of this replaces the earlier building blocks of this module. The principles from AI Governance Principles, the owners from AI Roles, Ownership and Accountability and the routes from The AI Governance Operating Model all still apply. Lifecycle governance adds the dimension of time: it decides when each of them is needed again.

Nine stages, one path, depth set by risk

The international vocabulary standard for AI, ISO/IEC 22989, describes an AI system’s life in eight stages that run from inception through design and development, verification and validation, deployment, operation and monitoring, and continuous validation, to re-evaluation and retirement². Re-evaluation and retirement are the two that governance programs most easily leave out. For executives, a plainer version of the same path works well, with nine stages: discover, design, build or buy, evaluate, approve, deploy, operate, change and retire. The figure groups them into six steps.

Discovery asks the plain questions. What problem are we solving? Why AI, and could something simpler work? Who benefits, and who could be affected? Design then fixes the data, the users, the human role and what the system may do. This is where governance is cheapest. Logging, access control, a human approval step and data minimization cost little to design in and a great deal to retrofit, and a system built without a way to roll back cannot be rolled back later when it matters.

The path is the same for every system; the depth is not. As AI Inventory and Risk Classification set out, the risk level of a use decides how heavy each stage is. A low-risk drafting aid might pass every stage on standard, largely automated checks. A system that affects customers’ money or workers’ jobs needs specialist review and a formal decision at the gates. Lifecycle governance does not create nine committees. It makes sure that nine questions get asked at the depth the risk deserves.

Govern the whole system, however it arrived

At the evaluate and approve stages there is a common mistake: teams test the foundation model and call the system tested. Engineers at Google pointed out a decade ago that the model code is a small fraction of a real machine learning system; most of it is data collection, configuration, serving and monitoring around the model³. With generative AI the surrounding layers have grown, not shrunk.

The same holds however the system arrived. An organization may build it, buy it, call a provider’s model through an interface, or find it switched on inside a software product it already uses. The vendor does not take over the organization’s governance responsibility, and procurement is a stage on the path rather than the end of it: review, contract, deployment, vendor monitoring, then renewal or exit. The risks that a provider adds were covered in Model and Third-Party Risk; the lifecycle point is simpler. Whoever supplies a layer, the organization that deploys the system governs all six.

In production, the system is still governed

For most systems, the longest part of life comes after go-live, and that is where the study in the opening applies. The NIST AI Risk Management Framework asks organizations to implement post-deployment monitoring plans that include capturing input from users, appeal and override, incident response, recovery, change management and decommissioning⁴. ISO/IEC 42001, the AI management system standard, asks organizations to define what each system needs to keep operating well, at least its monitoring, repairs, updates and support⁵.

Monitoring has two halves. The technical half watches accuracy, response time, cost and drift. The business half watches what those numbers do to people: complaints next to accuracy, escalations next to response time, value delivered next to cost. A model can be technically healthy while the outcome it serves gets worse. User feedback adds what neither half was designed to see: unexpected uses, new failure modes and requirements nobody wrote down. How to design meaningful human oversight and run an incident were covered in Human Oversight and AI Incidents. The lifecycle question is what happens afterwards: every serious signal should feed a decision about the system.

When Apple paused its AI news summaries in January 2025 after one produced a false headline, it paused one category, added warnings and promised a return after refinement⁶. That is the loop in small: a signal, a contained pause, a change and conditions for return.

Material change sends the system back

Change is the stage governance most often leaves out, and it is where the gap between the approved system and the running system opens fastest. AI systems change often, and not every change matters equally. A wording fix to a prompt is not a new provider. The discipline is to decide in advance which changes are material: changes that alter the system’s risk, impact, data, users, autonomy or the consequences of its decisions.

A new model version can shift behavior, quality, bias, cost and speed even when the swap looks simple, and providers retire versions on their own timetable, so some model changes are not optional. New data can move a system from public information to personal or regulated data. New users, especially a move from staff to customers, change who is affected when the system is wrong. A new provider brings new data flows, contracts and jurisdictions. More autonomy and more permissions, from suggesting to acting and from reading records to changing them, change what a single error can do.

A material change should travel the same route the organization already uses for significant changes elsewhere: a change request, an impact assessment, a fresh look at the risk level, the review that level requires, a decision, and a monitored release. AI Inventory and Risk Classification set the tier that the fresh look revisits, and the next chapter covers how the gate is run and the written triggers attached to each approval. This chapter’s point is that the route must exist and be triggered by written criteria, not by someone’s sense that a change feels big.

Retire deliberately

Every AI system eventually ends, and the ending needs governing as much as the launch did. The NIST framework devotes a subcategory to it: processes for decommissioning and phasing out AI systems safely and in a manner that does not increase risks or decrease the organization’s trustworthiness⁴. ISO/IEC 22989 lists retirement as a stage in its own right².

An unused system left running is not harmless. It still reaches data, still holds credentials, still costs money and depends on components that nobody updates. Retirement also has a business side: the people who relied on the system need to know what replaces it, and the records an auditor or regulator may ask for must survive the shutdown. Seen across the portfolio, retirement is also a value decision. Which systems are no longer used, and which cost more to govern than they return? An organization that never retires anything is likely to end up governing far more than it uses.

The owner stays: run AI as a product, not a project

Across all nine stages one thing must not vanish: the accountable owner. AI Roles, Ownership and Accountability set out who that owner should be. The lifecycle adds the hardest test of that choice, which is time. Owners get promoted, launch teams disband and budgets move to the next initiative. The simplest way to see the risk is to compare two ways of thinking about a launch.

Treat an AI launch as a project and governance looks finished when the steering committee signs. Treat it as a product and the system keeps running after the launch team leaves, with an owner who approves changes, watches outcomes and plans the end. The evidence follows the same logic. Each stage should leave a record proportionate to the risk, and the cheapest way to keep it is inside tools teams already use, such as release management, testing, monitoring and the model registry, rather than in a parallel set of forms.

Story: the maintenance assistant that grew

The following is an illustrative composite, built from patterns common in industrial manufacturing rather than from one company. The plants, people, results and order limit are invented to show the mechanics.

A global manufacturer of industrial pumps approves an AI maintenance assistant for one plant after a three-month pilot. The assistant reads machine alerts and technicians’ written notes and drafts work orders, and a maintenance planner approves every order before anything happens. Because it only drafts, and a human signs, it goes through the lighter review path. The plant’s maintenance manager is named as owner.

Nine months later, four things have changed. The provider retired the model version the pilot used, so the team moved to its successor. Technicians found typing slow, so the assistant now transcribes voice notes recorded on the shop floor, which capture names and the voices of colleagues nearby. Downtime fell, so the system was rolled out to eleven plants in six countries, four of them in the EU. And to cut delays, it may now release spare-parts orders up to 20,000 in value without a planner’s signature. The original approval is still on file, unchanged. The team calls the changes implementation details. When the governance office finally notices, through an expense audit, the vice president of operations asks to keep everything running: the results are excellent.

You decide. There are three options. Keep running on the approval on file. Switch the assistant off at every plant until it is re-approved. Or pull the system back to what was approved where that is possible, and reassess the rest. Choose before reading on.

The first option governs a system that no longer exists. The approval covered one plant, a tested model, written notes and a human signature on every order, and every one of those has changed. The second treats the approved core as if it were the problem and throws away real value; the original use was sound. The third is the proportionate answer. Planner sign-off returns on every order and voice capture is paused, while drafting continues at the eleven plants under the controls the pilot proved. The model cannot be rolled back, because its version was retired, so the successor is evaluated quickly on the plant’s own work orders.

The reassessment then covers what changed. Personal data from voice recordings needs a lawful basis and probably a data protection impact assessment, and works councils in some countries will expect to be consulted. If anyone proposes using the transcripts to judge technicians’ performance, the use would move toward the EU AI Act’s high-risk category for worker management, and the risk level would be set again. Ordering authority needs a limit and a check. And the system needs one owner for eleven plants, because the maintenance manager at the first plant cannot answer for the other ten.

The team was not careless. Each change looked small and was made for a good reason. What was missing was a written definition of material change, and someone whose job was to notice.

What this means for leaders

Lifecycle governance asks less of executives than it might seem, but it asks it every quarter rather than once. Three disciplines carry most of the weight. Define material change before the first one arrives, so that a model swap or a new data source triggers the route automatically. Keep one named owner per system for its whole life, and treat a live system without one as a finding. And look at the portfolio, not only the queue of new requests: which systems have changed since approval, which are degrading, and which should be retired.

Check yourself

1. AI governance is mainly an approval process.MythFact
2. A model that nobody changes keeps its quality over time.MythFact
3. Every change to an AI system needs a full governance review.MythFact
4. Monitoring means checking that the model is technically healthy.MythFact
5. Under the EU AI Act, substantially modifying a high-risk system can make the deployer a provider.MythFact
6. Retirement is a governance activity, not only an IT cleanup.MythFact

Reflection: the system you actually run

What comes next

Lifecycle governance places decision points along the path: before build, before launch, and every time a material change sends the system back. What evidence should those decisions rest on, and how can gates stay rigorous without becoming bureaucratic? The next chapter, AI Evaluation and Approval Gates, answers both.