AI Lifecycle Management: Stages, Duties and Evidence

Most AI governance programmes look at a system while it runs. AI lifecycle management looks at the whole arc: the first idea, the data, the build, the release, every change and the day the system is switched off. The EU AI Act attaches a duty to almost every one of those stages, and an auditor will ask for the evidence of each. This guide sets out the stages, maps the duties, proposes six stage gates, and covers the two moments most programmes miss: change control and retirement.

Key takeaways

• AI lifecycle management decides who may move an AI system to its next stage and what evidence is kept; MLOps automates the pipeline but makes none of those decisions.
• The EU AI Act uses the word “lifecycle” only 11 times, yet its high-risk duties map onto eight stages, from intended purpose to retirement.
• A substantial modification restarts the conformity assessment and can turn a deployer into a provider; since the Digital Omnibus it is also what pulls legacy systems into scope.
• Retirement is the stage nobody plans, although withdrawal, database status, 10-year retention and deletion all happen there.
• Six stage gates, each with an owner and a record, turn the lifecycle into something you can show an authority.

What AI lifecycle management means, and what MLOps leaves out

AI lifecycle management is the discipline of governing an AI system through every stage of its existence: who owns it, which decision moves it forward, what proof is kept, how changes are handled and how it ends. The pages that rank for the term mostly describe an engineering pipeline. IBM’s explainer walks from problem definition to model monitoring; the US GSA AI Guide for Government groups the same work into design, develop and deploy. Both are accurate. Neither tells a compliance team who signs what.

MLOps tools version models, run pipelines and raise alerts. They answer how. Lifecycle management answers whether and who: whether this model may go live, who approves a retraining, who decides that a system should be withdrawn. The two meet in the logs, but they are different jobs. An organisation can run mature MLOps and have no lifecycle management at all, which is precisely the gap an audit finds.

The EU AI Act is more lifecycle-minded than its vocabulary suggests. We counted 11 occurrences of “lifecycle” in the Official Journal text of Regulation (EU) 2024/1689: seven in the recitals and four in the enacting terms and annexes. Article 9(2) defines the risk management system as “a continuous iterative process planned and run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic review and updating”. Article 15(1) requires consistent performance “throughout their lifecycle”, Article 40(2) refers to energy consumption during the lifecycle, and Annex IV point 6 asks for “a description of relevant changes made by the provider to the system through its lifecycle”. Two more provisions say “lifetime” instead: Article 12(1) on logs and Article 72(2) on post-market monitoring.

In practice every high-risk duty has a natural home stage, and AI lifecycle management is the map that tells each owner which duties are theirs. The map runs on an AI inventory with one entry per system, and it sits next to, not inside, the AI risk management process that identifies and treats risks at each stage.

The stages: four reference models compared

There is no single official list of stages for AI lifecycle management. Four references are used in Europe, and they agree more than they differ. We use an eight-stage working model and map the others to it.

The nine phases used by the European Data Protection Supervisor in its guidance of 11 November 2025 take their detail from ISO/IEC 22989, the AI vocabulary standard. The NIST AI RMF 1.0 figure is adapted from the OECD classification framework and stresses test, evaluation, verification and validation across every stage; our NIST AI RMF guide covers its four functions. The OECD treats its phases as iterative and places the decision to retire inside operation and monitoring. ISO/IEC 42001 turns the stages into auditable controls in Annex A.6.2, including a requirement to decide at which phases event logging is enabled.

ISO/IEC 5338:2023, published in December 2023 by JTC 1/SC 42, goes one step further and describes the stages as processes. It builds on ISO/IEC/IEEE 15288 and 12207 and adds AI-specific processes drawn from ISO/IEC 22989 and ISO/IEC 23053, and it applies whether you develop or acquire the system. Our recommendation is simple: pick one working model, map the others to it, and never run three in parallel.

AI lifecycle management under the EU AI Act, stage by stage

For a high-risk AI system the stage map is also a duty map. The table is our reading of the Regulation; the article references are the ones a notified body or market surveillance authority will work from.

The dates moved this summer. Under the Digital Omnibus on AI, Regulation (EU) 2026/1744, the Annex III high-risk obligations apply from 2 December 2027 and Annex I product obligations from 2 August 2028. The Omnibus also made the post-market monitoring plan part of the Annex IV technical documentation, with Commission guidance including a template due by 2 September 2027, and made the quality management system proportionate to the size of SMEs and small mid-caps (Article 17(2)). Our pages on high-risk classification and technical documentation go deeper on the first four rows.

Stage gates in AI lifecycle management: who decides on what evidence

A stage only exists in governance if someone has to approve leaving it. Six gates are enough for most AI lifecycle management programmes.

1. <b>Intake.</b> The system enters the inventory with a named business owner, an intended purpose and a first classification. Nothing is built or bought before this record exists.
2. <b>Design approval.</b> Classification is confirmed, an AI impact assessment is done where needed and the risk register is opened. The governance committee gives a go, a conditional go or a no.
3. <b>Release.</b> Validation results meet the metrics set at design, documentation is complete, human oversight is assigned to named people, and for high-risk systems the conformity assessment and registration are done.
4. <b>Change triage.</b> Every change to the model, the data or the use is logged and sorted into routine, pre-determined or substantial. Only the last returns the system to gate 3.
5. <b>Periodic re-evaluation.</b> At least yearly and after any serious incident, live results are compared with the risks identified at design, and the risk register is updated.
6. <b>Retirement.</b> The decision is recorded with its reason, users are notified, artefacts are archived or deleted, and the inventory and database entries are closed.

Roles follow the gates. The business owner proposes; the AI governance committee decides at gates 2, 3 and 6; legal and the DPO review purpose, data and deletion; a model validation or second-line function owns the evidence at gates 3 and 5; security signs off releases and changes that touch the attack surface. In AI Sigil, a process is a sequence of stages with the forms, approvals and evidence attached to each one, so the gate record is produced while the work is done (AI registry).

Change control: when an update becomes a substantial modification

Change is where AI lifecycle management becomes law. Article 3(23) defines a substantial modification as a change after placing on the market or putting into service that was not foreseen or planned in the initial conformity assessment and that affects compliance with the Chapter III, Section 2 requirements or modifies the intended purpose. Article 43(4) then requires a new conformity assessment “regardless of whether the modified system is intended to be further distributed or continues to be used by the current deployer”. For systems that keep learning, changes pre-determined at the initial assessment and described in Annex IV point 2(f) are not substantial. Under Article 25(1), whoever makes a substantial modification, or changes the intended purpose so that a system becomes high-risk, takes on the provider’s obligations.

The Omnibus raised the stakes for older systems. Article 111(2), as amended, brings high-risk systems placed on the market before the Chapter III application date into scope only if, from that date, they undergo significant changes in their design; the recitals treat “significant change” as equivalent in substance to substantial modification. Change control is therefore the trigger that pulls a legacy system into the Regulation.

Official guidance is still coming. The Commission published draft guidelines on high-risk classification on 19 May 2026, extended the consultation to 23 July 2026 and plans final guidelines by the end of 2026; guidelines on substantial modification remain on the AI Office’s list of guidance in preparation. The CERRE issue paper of June 2026 argues that routine lifecycle changes should as a rule stay outside the regime and uses the case of a vendor swapping the underlying general-purpose model for a newer version. For the Annex IV 2(f) plan, the US FDA’s final guidance on predetermined change control plans (4 December 2024) offers a usable structure: description of modifications, modification protocol, impact assessment.

Triage questions

• Does the change alter the intended purpose or the population the system serves?
• Does it affect a Chapter III requirement such as accuracy, data quality or human oversight?
• Was it pre-determined and described in the technical documentation?
• Who made it: the provider, the deployer or a vendor upstream?
• Does it touch a legacy system after the Chapter III application date?

Operation and monitoring: logs, drift and incidents

Operation is the longest stage of AI lifecycle management and the one with the most recurring duties. Providers must run a post-market monitoring system that “actively and systematically” collects and analyses performance data “throughout their lifetime” (Article 72). Deployers monitor the system on the basis of the instructions for use, inform the provider and suspend use when they see a risk (Article 26(5)). Both keep automatically generated logs for at least six months unless other Union or national law requires otherwise (Articles 19(1) and 26(6)).

Performance decays quietly. Input data shifts, user behaviour changes and the relationship the model learned stops holding; our guide to model drift covers detection thresholds. The EDPS adds a distinct “continuous validation” phase for systems that keep learning in production, with test data refreshed so that evaluation reflects current inputs.

When something goes wrong, the clock starts. Article 73 requires providers to report a serious incident immediately after establishing a causal link or its reasonable likelihood, and no later than 15 days after becoming aware of it; two days for a widespread infringement or a serious disruption of critical infrastructure; ten days in the event of a death. An incomplete initial report followed by a complete one is allowed. The Commission has already published a reporting template, and our page on AI incident reporting sets out the internal workflow. The operational point for AI lifecycle management is that the monitoring stage needs named owners for each of these streams, not a shared dashboard nobody is accountable for.

Retirement: the stage nobody plans

Retirement gets the least attention in every AI lifecycle management reference we reviewed. In the EDPS guidance, the risk checklist per phase (Annex 3) maps no risk at all to Deployment or to Retirement; the Retirement phase only says that a system “should be responsibly and efficiently decommissioned when it is no longer needed or is replaced by a more advanced solution”. The OECD has no separate retirement phase. In our review of the ten readable pages ranking for this keyword, two mention retirement.

The legal duties are concrete. Under Article 20, a provider that considers a high-risk system non-conforming must bring it into conformity, withdraw it, disable it or recall it, and inform distributors and deployers. Article 18 keeps the technical documentation, the quality management system documentation and the declaration of conformity at the authorities’ disposal for 10 years after placing on the market, so retirement starts a retention period rather than ending one. Annex VIII Section A point 7 makes the status in the EU database (“no longer placed on the market/in service, recalled”) part of the registration. Personal data used for training and inference falls under the GDPR storage limitation and erasure rules; our page on GDPR-compliant AI covers the overlap.

A retirement record should contain:

• the decision, its date, its reason and who took it;
• notice to deployers and users, with the switch-off date;
• revoked access and archived or deleted model artefacts;
• personal data deleted or anonymised under the retention schedule;
• documentation archived for the remaining retention period;
• inventory and EU database status updated, and any replacement sent back to intake.

Bought, not built: the deployer’s lifecycle

Most organisations buy their AI. For them AI lifecycle management starts with procurement, and the EDPS guidance gives a usable sequence for EU institutions buying under Regulation 2024/2509: publication and transparency, call for tenders, selection and award, then execution. Execution repeats the familiar stages on the buyer’s side: verification and validation, deployment, operation and monitoring, continuous validation, re-evaluation and retirement.

The contract is where a bought system becomes governable. Five clauses matter more than the rest: notice before any model or version change, access to the logs you must keep, cooperation on serious incidents, documentation and instructions for use that match the version in production, and end-of-life terms covering data return, deletion and support. Without the first clause, a vendor’s model swap can change your risk profile overnight, and if you rebrand the system or modify it substantially, Article 25 makes you the provider. Our guide to vendor due diligence for AI has the questionnaire.

National supervision also follows the lifecycle. Germany’s KI-MIG, in force since 29 July 2026, gives the Bundesnetzagentur market surveillance; Spain has set up AESIA; Italy’s legge 132/2025 names AgID and ACN. Whichever authority knocks, it will ask for the same thing: the record of each stage.

FAQ

<b>What is AI lifecycle management?</b>

AI lifecycle management is the governance of an AI system across all its stages, from intake and intended purpose through data, development, validation, deployment, operation and change, to retirement. It assigns an owner to each stage, defines the decision that moves the system forward, and keeps the evidence of that decision. It complements engineering practices such as MLOps, which automate the technical pipeline, by deciding who may approve each step and what proof an auditor or authority will receive.

<b>What are the stages of the AI lifecycle?</b>

Reference models differ in detail but converge on the same arc. ISO/IEC 22989 and the EDPS list nine phases: inception, data acquisition and preparation, development, verification and validation, deployment, operation and monitoring, continuous validation, re-evaluation and retirement. NIST AI RMF uses six stages from Plan and Design to Operate and Monitor. We recommend an eight-stage working model that adds explicit change and retirement stages, mapped to the others.

<b>Does the EU AI Act require AI lifecycle management?</b>

Not by that name, but in substance yes for high-risk systems. Article 9(2) requires risk management “throughout the entire lifecycle”, Article 15(1) consistent performance throughout the lifecycle, Article 12 logging over the lifetime and Article 72 post-market monitoring. Annex IV asks for a description of changes through the lifecycle. Meeting these duties without a lifecycle model, owners and stage records is very hard to demonstrate.

<b>What is the difference between AI lifecycle management and MLOps?</b>

MLOps is the engineering practice of building, deploying and monitoring models with automation: versioning, pipelines, registries, alerts. AI lifecycle management is the governance layer above it: who approves a release, how a change is triaged, when a system is re-evaluated or retired, and which records are kept. MLOps produces much of the evidence; lifecycle management decides what that evidence must show and who is accountable for it.

<b>When does a change count as a substantial modification?</b>

Under Article 3(23), a change counts when it was not foreseen or planned in the initial conformity assessment and it affects compliance with the high-risk requirements or modifies the intended purpose. Changes pre-determined in the technical documentation for systems that keep learning are excluded by Article 43(4). A substantial modification triggers a new conformity assessment, and the party that makes it can become the provider under Article 25(1).

<b>What happens when an AI system is retired?</b>

The provider or deployer records the decision, informs users, revokes access and archives or deletes the model artefacts. For a high-risk system, Article 20 may require withdrawal or recall, the database status must show the system is no longer on the market or in service, and Article 18 keeps the documentation available for 10 years. Personal data follows the GDPR retention and erasure rules. Any replacement system starts again at intake.

Conclusion

AI lifecycle management is less about drawing a circle of stages than about deciding who may leave each one and on what evidence. The EU AI Act rarely says “lifecycle”, but its duties land on every stage, and the two that organisations neglect, change and retirement, are the ones that create new obligations: a substantial modification restarts the conformity assessment, and a retirement starts a 10-year retention period. Start with one working model, six gates and a named owner for each, then let the records accumulate as the work is done. If you want to see how stages, forms and approvals fit together in practice, the AI registry is the place to begin.