AAIR lesson 5: AI life cycle and design

The AI life cycle is the path an AI system follows from the first idea to retirement: design or procurement, development and training, testing and validation, deployment, operation and maintenance, and decommissioning. It matters for risk because each stage introduces different risks, and decisions made early are the cheapest to change. Domain 2 of the AAIR outline is worth 21% and begins with subtopic 2A, design, development or procurement, and documentation. This lesson covers the shape of the life cycle and the first stage; lessons 6 and 7 cover the rest.

The stages, and why the order matters

The figure above shows the stages as a row with data and asset management beneath all of them. That bar is a reminder that data and assets are present throughout, which lesson 7 explores.

Two properties make the AI life cycle different from a typical software one. First, it is not a straight line. Monitoring in operation can send a system back to retraining or redesign, so the “end” of one pass is the start of another. Second, behaviour comes from data, so a change in data is a change in the system, even if no code changed. A risk professional therefore asks at every stage: what could change here, who would know, and who approves it?

Risks introduced at design

Design is where purpose and boundaries are set. The key questions concern the use case:

• Suitability. Is AI the right tool? A rule that a person can state in one sentence may not need a model at all, and a model adds uncertainty.
• Intended use and limits. What is the system for, for whom, and what must it never do? Misuse often starts as an undocumented extension of intended use.
• Impact classification. Does the output feed a decision about people, money, health or safety? Higher impact calls for stronger testing, oversight and approval.
• Requirements. Were accuracy, fairness, explainability, privacy and security requirements written down before building? If not, nothing exists to test against later.

Early involvement of the risk function is itself a control: it is far cheaper to reject or reshape a poor use case at design than after deployment.

Build or buy: procurement risk

Organisations rarely build everything. A team may train its own model, fine-tune an existing one, call a vendor’s API, or switch on an AI feature inside software already owned. Each option moves where the risk sits, but accountability stays with the organisation using the system.

For bought AI, due diligence replaces direct inspection: ask for model documentation, testing evidence, data handling terms and change notification commitments. Lesson 11 returns to third-party risk in more depth.

Documentation as a risk control

Documentation is what lets anyone other than the builder assess a system. The kinds a risk professional looks for at this stage are:

• Purpose and scope: intended use, users, out-of-scope uses.
• Data: sources, collection basis, known gaps, how labels were produced.
• Model description: type, version, key design choices, known limitations.
• Risk and impact assessment: who could be affected and how, with owner and approval.
• Test plans and acceptance criteria: written before testing, so results can be judged.
• Roles: use-case owner, model owner, approver.

Published practice in the field often calls the model-focused version a model card or similar; the name is less important than the content. An undocumented system cannot be properly assessed, so missing documentation is itself a finding. See also the AI governance and risk topic page.

Worked example: a claims summariser at a 200-person insurer

A 200-person insurer wants a tool that summarises claim files for handlers. A vendor offers an API, and the IT team has a trial running before anyone has asked the risk function.

The risk analyst first records the use case: summaries are read by handlers who then decide on claims, so the AI influences decisions about customers. Next the analyst asks procurement questions. Do claim files, which include health details, leave the insurer’s environment? Can the vendor use the files for its own training? What happens if the vendor changes the model? Is there a written limit that the summary supports a handler and never makes the decision?

The analyst’s recommendation is to pause the trial, classify the use case as moderate-to-high impact, require a short impact assessment, obtain the vendor’s documentation and terms, and name a use-case owner in claims. Nothing was blocked permanently; the order of work was fixed.

Easy to confuse

• Design vs development. Design sets purpose, requirements and constraints; development builds against them.
• Procurement vs ownership of risk. Buying a model transfers some tasks, not accountability for outcomes.
• Documentation vs policy. Policy says what must be done; documentation records what was done for this system.
• Linear vs cyclical life cycle. Monitoring findings can send a system back to an earlier stage.

Key points

• The life cycle stages are design or procurement, development and training, testing and validation, deployment, operation and maintenance, and decommissioning.
• Early stages are the cheapest place to prevent risk, so the risk function should join at design.
• Design risks include poor suitability, vague intended use, missing impact classification and unwritten requirements.
• Building, fine-tuning, buying and embedded features each shift where risk sits, but accountability remains with the user organisation.
• Missing documentation is a finding, because it blocks assessment.
• Data and assets are managed across the whole life cycle, not at one stage.

Check yourself

This lesson covers the start of Domain 2 (AI Life Cycle Risk Management, 21%): subtopic 2A, with the stages overview. The life cycle risk recap condenses the whole domain.