Retirement, the value chain, and where controls attach
Lesson 5 of 5 in The AI Lifecycle: From Data to Deployment to Retirement.
Stage 7 gets one paragraph in most frameworks and causes outsized trouble in practice. Retiring an AI system means deprecating it on a communicated schedule, migrating everything that quietly grew dependent on it (other systems, business processes, people’s workflows), deleting or returning data on the schedule the law and your own retention policies promised, and keeping decommissioning records — because legal claims about a system’s decisions arrive years after the system is gone, and “we no longer have those logs” is a terrible answer to a court.
Retirement also has a human face: when a provider sunsets a model, every downstream product built on it inherits a forced migration — and the replacement model will not behave identically. Model succession is a change-management event for the whole value chain, which is the last concept this module needs: no AI system is built by one actor.
A typical chain runs: chip makers → cloud compute providers → data suppliers and annotators → foundation model developer → fine-tuner → provider of the finished system → deployer who uses it → end users → affected persons who never chose any of it. Harm can originate at any link — a poisoned dataset, a flawed base model, a reckless deployment configuration — and each actor holds information the others lack. That asymmetry is why frameworks assign different duties to different roles rather than dumping everything on whoever is nearest when harm surfaces.
| Actor | What they uniquely know | What they cannot see | Typical duty pattern |
|---|---|---|---|
Foundation-model developer | Training data, architecture, capability evaluations, known failure modes | Who builds what on the model, and every deployment context | Document the model, disclose capabilities and limits downstream, evaluate systemic risk |
System provider / fine-tuner | The application design, fine-tuning data, test results for the intended purpose | The base model’s full training history; each customer’s operating reality | Risk management, technical documentation, conformity with rules for the use case |
Deployer | The actual context of use, the affected population, live outcomes | Model internals and upstream data choices | Use per instructions, configure oversight, monitor in context, inform affected people |
Affected person | What the decision did to their life | Usually everything else — often not even that AI was involved | Holds rights, not duties: disclosure, explanation, contestation, redress |
Now put the whole module together. Every governance artifact you will meet in the rest of this academy — assessments, audits, cards, logs, plans — has a home stage. Being able to place them instantly is a working skill: it tells you when a control can still change the outcome and who must produce it. Prove it to yourself below.
Interactive sorting exercise: Drag each governance artifact to the lifecycle stage where it is primarily produced or performed.
Tool: Lifecycle Governance Simulator — Now run the gauntlet yourself: ship a résumé-screening AI as product lead, make the governance calls at every stage, and live with the consequences.