What Is the AI Lifecycle? 7 Stages and Who Owns Each

• 4 to 7 stages, depending on the model: the OECD uses four phases (2019, updated 2024), NIST’s AI RMF 1.0 uses six (2023), and ISO/IEC 22989 reaches seven with re-evaluation and retirement (2022).
• 8 steps and 3 automation levels in the MLOps loop, from data extraction to model monitoring, per Google Cloud’s MLOps architecture guide (updated August 2024).
• 2 December 2027 is when EU AI Act high-risk rules apply to stand-alone systems, and 2 August 2028 for systems embedded in products, following the Council’s final approval of 29 June 2026. Both replaced 2 August 2026.
• 5 stages in the generative AI lifecycle (data preparation, pre-training, post-training, deployment, commercialization), per the 2025 full-stack LLM safety survey.
• 2 September 2027 is the deadline for the European Commission’s post-market monitoring template under Article 72 of Regulation (EU) 2024/1689.

What the AI Lifecycle Is and Why It Differs From Traditional Software Development

The AI lifecycle is the repeating set of stages an AI system passes through: planning and design, data work, model building, testing, deployment, operation and monitoring, and finally retirement. There is no single official version of it. The OECD describes four phases, NIST’s AI Risk Management Framework (2023) uses six stages, and ISO/IEC 22989 (2022) adds explicit re-evaluation and retirement steps at the end. Line the models up and the differences come down to naming and how finely each one slices the work. The shape is the same.

That shape is what separates an AI system from an ordinary application, and the separation is larger than most engineering teams expect going in.

Three things make the AI development life cycle unlike the classic SDLC:

• Behaviour comes from data as well as code. Change the training data and the system changes, even if nobody edits a line of logic.
• Performance decays when the world moves. The 2015 Google paper on hidden technical debt in machine learning systems made the case that ML systems are cheap to build and expensive to maintain, because the environment a model learned from keeps shifting underneath it.
• The loop never closes at deployment. In conventional software, release is the finish line. For AI, release is the moment the system starts generating the evidence that tells you whether it works at all.

The OECD’s own wording captures the practical consequence: the phases often run iteratively and are “not necessarily sequential.” A monitoring finding in month eight can send a team back to data collection. A validation failure can reopen the problem statement. And the decision to retire a system can arrive at any point during operation.

Here is the thing I’d push back on in most explainers. They draw the lifecycle as a neat circle, which suggests every stage gets equal time. In practice the weight sits almost entirely at the back end. Building the first model is the short part. Keeping it accurate, documented and safe for three years is the lifecycle.

That emphasis is also where the term has moved between 2023 and 2026. Earlier material treated monitoring as a final box to tick. The newer regulatory and vendor positions treat it as the stage that never ends, with governance running continuously alongside it.

The Stages of the AI Project Life Cycle, From Problem Framing to Retirement

The AI project life cycle runs through seven stages: problem framing, data collection and processing, model building or adaptation, testing and validation, deployment, operation and monitoring, and re-evaluation and retirement. Every major framework covers this ground. They just group it differently.

At the project level, the stages look like this:

1. Problem framing and business and data understanding. Decide what decision the system supports, what “good” means in numbers, and whether the data to learn it even exists.
2. Data collection and processing. Gather, clean, label and document the data. Record where it came from and what it leaves out.
3. Model building or adaptation. Train a model from scratch, or (far more often in 2026) adapt an existing one.
4. Testing, evaluation, verification and validation. Check that the model does what the framing stage asked for, on data it has never seen.
5. Deployment. Put the model behind a product, an API or a workflow, with the infrastructure to serve it.
6. Operation and monitoring. Watch performance, inputs and outputs in the live environment and collect the evidence that triggers the next iteration.
7. Re-evaluation and retirement. Decide whether the system still earns its place, and switch it off cleanly when it doesn’t.

How the main reference models label those stages:

The table paraphrases the stage names. If you need exact wording for an audit file, go to Figure 2 of NIST AI 100-1 and the standard’s own text rather than lifting labels from a summary. The OECD’s four-phase version is the parent of most government definitions, including the OECD framework for classifying AI systems published in 2022, which Australia’s pilot AI assurance framework adapts directly.

Two details get lost when people read the table as a checklist. First, the stages loop. A monitoring alert is an instruction to go back to stage two or three. Second, retirement has no fixed position. The OECD places that decision inside operation and monitoring, and ISO gives it its own named step, which is the more honest framing: a model can be retired in month two if validation never clears, or in year four when the business process it served no longer exists.

How the AI Model Lifecycle Works in Each Stage: Data, Training, Evaluation, Deployment and Monitoring

Inside each project stage, the AI model lifecycle works as a closed engineering loop: data is extracted, analysed and prepared, a model is trained, evaluated and validated, then served, and monitoring of the served model decides when the loop starts again. That is the MLOps view, and it is where the day-to-day work happens.

Google’s MLOps guide to continuous delivery and automation pipelines, last updated in August 2024, breaks the loop into eight steps:

1. Data extraction
2. Data analysis
3. Data preparation
4. Model training
5. Model evaluation
6. Model validation
7. Model serving
8. Model monitoring

Step eight feeds step one. Monitoring is what tells the team that the data distribution has drifted, that accuracy on live traffic has slipped, or that a new segment of users is getting worse answers. Any of those signals opens a new iteration.

How much of that loop runs by hand is the real maturity question. The same guide defines three automation levels:

• Level 0, manual. Every step is a person running scripts. Retraining happens when someone remembers to do it.
• Level 1, ML pipeline automation. The training-to-serving path is a pipeline that can rerun on new data without manual intervention. Continuous training becomes possible.
• Level 2, CI/CD pipeline automation. The pipeline itself is versioned, tested and deployed like any other software, so changes to the pipeline ship reliably as well as changes to the model.

What the diagram hides is where testing lives. NIST’s framework rejects the idea that validation is a single gate between training and serving:

NIST’s modification “highlights the importance of test, evaluation, verification, and validation (TEVV) processes throughout an AI lifecycle.” (NIST AI Risk Management Framework, 2023)

In practice that means data checks at extraction, evaluation during training, validation before serving, and ongoing measurement in production. Four kinds of testing, four different places.

A friction point worth knowing before you start: monitoring is the step that gets cut when the deadline arrives, and it is the only step that can tell you the other seven still hold. A level 0 team that skips it has a model with no feedback at all. It will keep answering confidently long after the answers stopped being right.

What Does Managing the AI Lifecycle Actually Cost in Time, People and Infrastructure?

Managing the AI lifecycle costs far more in maintenance than in building, and the spend concentrates in data pipelines, monitoring and documentation rather than in model training. No reliable public benchmark splits that bill into percentages. What exists is a thesis, and it has held for over a decade.

The thesis is Google’s 2015 argument about hidden technical debt in machine learning: the model is quick to produce and slow to pay for, because everything around it (data feeds, serving infrastructure, configuration, checks) keeps needing work after the model is done. Anyone who has kept a model alive for a year recognises the shape of that bill.

Where the hours and the infrastructure go shifts with automation level:

Level 0 looks cheap on the invoice. It is the most expensive in people, because every retrain is a person’s week.

Compliance adds a line that never closes. For high-risk systems, the EU AI Act’s Article 72 requires providers to document a post-market monitoring plan, sized to the system’s risks, that collects and analyses performance data throughout the system’s lifetime. That plan becomes part of the technical documentation. Someone has to write it, keep it current and act on what it finds, for as long as the system runs.

The practical way to estimate your own number is to count what already runs. An AI integration audit that lists each system by lifecycle stage, automation level and monitoring status will tell you where the hidden maintenance is before the budget cycle does.

How the Generative AI Lifecycle Differs From the Classic Machine Learning Lifecycle

The generative AI lifecycle differs from the classic machine learning lifecycle in who trains the model: a handful of labs build foundation models through data preparation, pre-training and post-training, and nearly everyone else enters the lifecycle at adaptation and deployment. The loop still exists. The entry point moved.

The 2025 full-stack survey of LLM and agent safety, first published in April 2025 and revised in June 2025, defines the LLM lifecycle in five stages: data preparation, pre-training, post-training, deployment and commercialization. Its authors point out that earlier surveys mostly covered one stage each. That alone shows how new the whole-lifecycle view of generative AI is.

Set those five stages against the classic supervised loop and three differences stand out:

• Who owns the build. In classic ML your team trains on your data. With generative AI, pre-training happened elsewhere, on data you never saw, and your build stage becomes adaptation: prompt design, retrieval over your own documents, or fine-tuning for a narrow task.
• What evaluation measures. A classifier has a held-out test set and an accuracy figure. An LLM feature has prompts, retrieved context and open-ended output, so evaluation turns behavioural. Does it refuse what it should? Does it cite what it retrieved? Does it stay inside the task?
• Where risk arrives. With a classic model the risk mostly lived in your data. With a foundation model, whatever happened in pre-training and post-training ships inside the weights, and you inherit it without being able to inspect it.

That inheritance is why governance frameworks grew a generative branch. NIST’s Generative AI Profile (AI 600-1, July 2024) extends the risk management framework under four functions, Govern, Map, Measure and Manage, so that the stages you don’t control still get mapped and measured in the stages you do.

Frontier developers publish lifecycle-gated policies of their own, such as Anthropic’s Responsible Scaling Policy, which ties decisions about training and deploying larger models to evaluations at set points. Those policies govern the top of the lifecycle. Everything from adaptation onward is still yours.

Where AI Projects Fail Across the Development Life Cycle and How to Spot the Warning Signs

AI projects fail at every stage of the development life cycle, and the costliest failures are the silent ones: a model that keeps serving answers after the world it learned from has moved on. CRISP-ML(Q), published in 2021, built quality assurance into every phase for this reason. Its authors gave monitoring and maintenance special weight because deployed models in changing environments degrade, and that decay shows up nowhere unless someone is looking.

Each stage has a characteristic failure and a sign you can check for:

The leakage row is the one I’ve watched catch experienced teams. The feature looked harmless, a status field. It turned out the field was only written after the outcome the model was predicting. Offline, the model was close to perfect. Live, it had nothing to go on.

Two patterns connect the rows. First, failures cluster where maintenance was skipped, which is exactly what the 2015 hidden technical debt argument predicts: the cheap part (building) gets done and the expensive part (keeping it right) gets deferred. Second, the warning signs are almost all absences. No number for success. No monitoring. No retirement owner. You diagnose an AI lifecycle by asking what should exist and doesn’t.

One more sign that rarely makes the lists: the gap between how the sponsor describes the goal and how the data scientist describes it. If those two descriptions differ in week one, the evaluation stage will be measuring the wrong thing by week ten.

Which Roles Own Each Phase of AI Lifecycle Management

Each phase of AI lifecycle management has a natural owner: product or business leads own problem framing, data engineers own the pipelines, data scientists and ML engineers own build and evaluation, platform or MLOps engineers own deployment and monitoring, and security and compliance work alongside every phase. The reference frameworks don’t hand out job titles. They describe the work clearly enough that ownership follows from it.

A workable mapping, which I’ll call the phase-owner grid, looks like this:

Security has the clearest published playbook. The UK NCSC guidelines for secure AI system development, issued in November 2023 with CISA and other national agencies, split the work into four stages: secure design (threat modelling and design trade-offs), secure development (supply chain, documentation, technical debt), secure deployment (protecting infrastructure and models, incident management, responsible release) and secure operation and maintenance (logging, monitoring, update management, information sharing). Each stage lands on a lifecycle phase. That is why security sits in the contributors column all the way down.

Risk and compliance have the same reach. NIST’s framework starts risk management at the plan and design stage and runs it to the end, and the EU AI Act makes the provider of a high-risk system answerable for monitoring over the system’s whole lifetime. Those duties belong to the organisation. They cannot be delegated to whoever trained the model.

Monitoring is where single ownership breaks down. The platform team sees latency and error rates. The ML engineer sees drift. Product sees complaints. Risk sees the incidents that need reporting. Name one of them “the owner” and the other three “informed”, and those four signals never get combined.

The handover I’ve watched fail most often is simpler still: the build team ships, moves to the next project, and nobody inherits the retraining decision. Six months later the model is still running and nobody can say who is allowed to switch it off.

AI Lifecycle Frameworks and Tooling Compared: MLOps, LLMOps and Governance Platforms

AI lifecycle frameworks split into four families by scope: engineering workflow models, risk governance models, security guidelines and generative AI extensions. Pick one from each family and the lifecycle is covered. Pick one in total and you have about a quarter of it.

Two labels from the heading are missing from that table on purpose. LLMOps and governance platforms are tooling categories, and neither has a published reference model behind it. LLMOps tools cluster around the adaptation and deployment end of the generative lifecycle: prompt versioning, retrieval pipelines, evaluation harnesses, output logging. Governance platforms record the evidence that NIST, ISO or the EU AI Act ask for. Both are useful. Both implement a lifecycle definition that someone else wrote, so the definition still has to be chosen first.

The families overlap more than their authors admit. The OECD’s four phases, NIST’s six stages, ISO’s seven steps and CRISP-ML(Q)’s six phases describe the same work at different resolutions. Where they genuinely part ways is narrow: whether testing is one gate or a thread through every stage (NIST says thread), and whether retirement gets its own name (ISO says yes).

Here is the mistake that causes the most confusion in practice. A compliance officer who says “lifecycle” means NIST or OECD stages with controls attached. An ML engineer means Google’s eight steps. The CISO means the NCSC’s four. Same word, three documents, three different review meetings.

So declare the scope. Any internal AI policy should name its reference model in the first line: “this document uses the NIST AI RMF lifecycle for governance and the Google MLOps loop for engineering.” That single sentence saves a surprising number of arguments about whether “validation” happened.

How AI Regulation and Agentic Systems Changed Lifecycle Requirements This Year

In 2026 the lifecycle stopped being a best practice and became an obligation with dates attached: the EU fixed the final timeline for the AI Act’s continuous risk management and post-market monitoring duties, the OECD published lifecycle-wide due diligence guidance, and the largest vendors moved governance from a pre-launch review to continuous observation of agents in operation. As of October 16, 2026, those three shifts define what “managing the lifecycle” now means for a regulated enterprise.

The legal core is two articles of Regulation (EU) 2024/1689. Article 9 frames risk management for high-risk systems as a process that never finishes:

Risk management must be “a continuous iterative process planned and run throughout the entire lifecycle of a high-risk AI system.” (EU AI Act, Article 9(2))

Article 9 also ties that process to the data produced by the monitoring system in Article 72, which requires providers to document post-market monitoring scaled to the system’s risks, collecting and analysing performance data for as long as the system is in use. The monitoring plan forms part of the technical documentation, and the Commission must publish guidance and a template for it by 2 September 2027.

The dates moved this year. The Council of the EU’s final approval of the AI omnibus on 29 June 2026, following a provisional deal on 7 May 2026, reset the high-risk timeline:

• High-risk rules for stand-alone systems apply from 2 December 2027.
• High-risk rules for systems embedded in regulated products apply from 2 August 2028.
• Both dates replace the original 2 August 2026.
• The grace period for watermarking of AI-generated content now runs to 2 December 2026.

Sixteen extra months is time to build the monitoring plan properly. It is also, for teams that read the delay as a reprieve, sixteen months to keep shipping level 0 systems with no feedback loop. The obligation didn’t shrink.

The OECD added a parallel track on 19 February 2026 with its Due Diligence Guidance for Responsible AI, which applies due diligence expectations across every lifecycle phase from planning through operation and monitoring.

Agents changed the vendor side. Microsoft’s Responsible AI update of 1 September 2026 describes a move toward a “more continuous, lifecycle-based approach to AI governance,” and argues that governance has to cover an agent’s memory, tool use, identities and permissions, because risk shifts as the system interacts with its environment. Its practical conclusion: organisations must test and observe systems in operation instead of assessing them once before release. That is a vendor position, and no standards body has yet published a lifecycle model for agentic systems. For anyone building agents for production use today, the working answer is to treat the classic loop as the baseline and add the four agent-specific items Microsoft names to the monitoring stage.

The standards will catch up. The agents are already running.

Frequently Asked Questions About the AI Lifecycle

These are the questions people type into a search box about the AI lifecycle, answered briefly enough to quote.

What are the stages of the AI lifecycle?

The AI lifecycle has seven stages: problem framing, data collection and processing, model building or adaptation, testing and validation, deployment, operation and monitoring, and re-evaluation and retirement. Frameworks group them differently. The OECD compresses them into four phases, NIST’s AI Risk Management Framework (2023) uses six, and ISO/IEC 22989 (2022) names re-evaluation and retirement separately. The stages loop rather than run in a straight line.

What is the difference between the AI lifecycle and the ML lifecycle?

The ML lifecycle is the engineering loop inside the AI lifecycle. The AI lifecycle covers the whole system, including planning, governance, security and retirement, and is the view regulators and standards bodies take. The ML lifecycle covers the model-level work: Google’s MLOps guide (updated 2024) lists eight steps from data extraction to model monitoring. One describes the system. The other describes the model inside it.

What is AI lifecycle management?

AI lifecycle management is the practice of running every stage of an AI system deliberately, with named owners, documented decisions and monitoring that continues for as long as the system is in use. Under the EU AI Act, it has a legal form for high-risk systems: Article 9 requires continuous iterative risk management and Article 72 requires a documented post-market monitoring plan. For everyone else it is the difference between a model that gets maintained and one that quietly rots.

How many phases are in the AI development life cycle?

Between four and seven, depending on the reference model. The OECD and the UK NCSC each use four. NIST’s AI RMF and CRISP-ML(Q) each use six. ISO/IEC 22989’s example model reaches seven once re-evaluation and retirement are counted. The number matters less than agreeing which model your organisation uses, since the underlying work is the same.

What is the generative AI lifecycle?

The generative AI lifecycle runs through five stages: data preparation, pre-training, post-training, deployment and commercialization, as defined in a 2025 full-stack survey of LLM safety. The first three stages happen inside a small number of labs. Most organisations enter at adaptation (prompting, retrieval, fine-tuning) and deployment, which is why evaluation for generative systems focuses on behaviour instead of a single accuracy score.

Who is responsible for monitoring an AI model after deployment?

Monitoring is shared between the platform team (latency and errors), ML engineers (drift and accuracy), product owners (user outcomes) and risk or compliance (incidents and reporting). For high-risk systems in the EU, the provider carries the legal responsibility for post-market monitoring throughout the system’s lifetime under Article 72. Inside the organisation, one person should be able to say who can switch the model off. If nobody can, monitoring doesn’t exist yet.

Does the AI lifecycle end at deployment?

No. Deployment is the midpoint. The OECD, NIST, ISO and CRISP-ML(Q) all place operation and monitoring after it, and the 2015 Google paper on hidden technical debt argued that maintenance is where most of the cost of an ML system lands. Retirement, when the system no longer earns its place, is the actual end.

Where to Start Mapping Your Own AI Lifecycle

Start mapping your own AI lifecycle by choosing one reference model, listing every system you run against its stages, and writing down who owns monitoring and retirement before anything else. Five steps, in order:

1. Pick a reference model and declare its scope. NIST’s AI RMF for governance, Google’s MLOps loop for engineering, the NCSC guidelines for security. Name them in the first line of your policy.
2. Inventory existing systems by stage. For each model in production, record its automation level (0, 1 or 2) and whether anyone can say what it did yesterday.
3. Define monitoring and retirement criteria up front. Which metric, which threshold, which person, and what happens when the threshold is crossed.
4. Assign a phase owner for every stage. Monitoring gets a named coordinator across platform, ML, product and risk.
5. Check the EU AI Act timeline if you are in scope. High-risk obligations apply from 2 December 2027 for stand-alone systems and 2 August 2028 for embedded ones, and the Article 72 monitoring plan belongs in your technical documentation before then.

The inventory is the step most teams skip, and it is the one that reveals the real work. Count the models first.

If that count turns up systems with no monitoring and no owner, talk to AlphaCorp AI about putting a working lifecycle around them.