AI Life Cycle Stages and Risk Touchpoints

Why This Topic Matters

AI risk does not appear all at once at the moment a system goes live. It accumulates, stage by stage, from the first business idea through data collection, model development, deployment, ongoing operation and eventual retirement. The ISACA Advanced in AI Risk (AAIR) body of knowledge treats the AI life cycle as the organizing backbone for risk management because where a risk is introduced determines who owns it, how it is detected and what control is appropriate. A bias problem rooted in training data cannot be fixed by a post-deployment dashboard; a drift problem cannot be prevented at the design stage alone. Understanding the life cycle lets a risk professional place controls at the right 'touchpoints' - the moments where risk is created, amplified, transferred or can be mitigated.

For the exam, this domain underpins many scenario questions. ISACA expects you to recognise the stage a scenario describes, identify the dominant risks at that stage, select the most appropriate control or governance action, and understand how decisions made upstream create consequences downstream. If you can mentally walk the life cycle and attach risks and controls to each stage, you will answer a large share of AI Life Cycle Risk Management questions correctly.

What the AI Life Cycle Is

The AI life cycle is a structured sequence of phases through which an AI system passes from conception to decommissioning. Different frameworks label the stages slightly differently (NIST AI RMF, ISO/IEC 5338, ISO/IEC 42001, the OECD framework, and ISACA's own materials), but the stages converge on a common pattern. For AAIR study purposes, use the following consolidated model:

1. Plan and Design (Inception / Problem Framing) - defining the business problem, intended purpose, success criteria, stakeholders, constraints and whether AI is even the right solution.
2. Data Collection and Preparation - sourcing, acquiring, labelling, cleaning, transforming and documenting the data used for training, validation and testing.
3. Model Development (Build and Train) - selecting algorithms or foundation models, engineering features, training, tuning hyperparameters, and potentially fine-tuning or prompt-engineering third-party models.
4. Verification and Validation (Test and Evaluate) - assessing accuracy, robustness, fairness, safety, security and explainability against the requirements set in design; red-teaming and independent review.
5. Deployment (Release and Integration) - moving the system into production, integrating with business processes, APIs and human workflows, and configuring access and change controls.
6. Operation and Monitoring (Use and Maintain) - running the system in production, monitoring performance, drift, incidents, misuse and feedback, applying updates and retraining.
7. Retirement and Decommissioning - withdrawing the system, archiving or deleting data and models, handling dependencies and preserving records for accountability.

Two framing points matter. First, the life cycle is iterative, not strictly linear: retraining loops back to data and development, and monitoring findings can trigger redesign. Second, governance and oversight run across every stage - roles, accountability, documentation, risk assessment and stakeholder engagement are cross-cutting rather than confined to one phase. ISACA frequently tests this cross-cutting nature.

What a Risk Touchpoint Is

A risk touchpoint is a specific point in the life cycle where a risk is introduced, becomes observable, can be measured, or can be controlled. Touchpoints are where risk management activities (identification, assessment, treatment, monitoring) should be anchored. Think of them as control gates and checkpoints. A mature AI risk program defines, for each stage, what risks are expected, what evidence must be produced, who must approve progression, and what triggers escalation or rollback.

How It Works: Stage-by-Stage Risks and Controls

Stage 1 - Plan and Design
Key risks: poorly defined purpose or success criteria; use cases that are unlawful, unethical or prohibited (for example under the EU AI Act's banned practices); misalignment with organisational risk appetite; unrealistic expectations; failure to consider impacted stakeholders; missing accountability; choosing AI where a simpler solution would suffice; inadequate budgeting for ongoing monitoring.
Touchpoint controls: AI use-case intake and approval; initial risk classification and tiering (high, limited, minimal impact); AI impact assessment or algorithmic impact assessment; privacy impact assessment triggered early; definition of acceptance criteria and key risk indicators; assignment of an accountable owner; go/no-go decision gate; documentation of intended use and foreseeable misuse.
Exam insight: Decisions here are the cheapest to change and the most consequential. When a question asks for the 'most effective' or 'earliest' point to address a fundamental problem (purpose, legality, proportionality, accountability), the answer is usually the design stage.

Stage 2 - Data Collection and Preparation
Key risks: data that is unrepresentative, incomplete, outdated or biased; unlawful collection or lack of consent and legal basis; use of personal or sensitive data without minimisation; poor data lineage and provenance; labelling errors and annotator bias; data poisoning from untrusted sources; intellectual property and licensing violations; data leakage between training and test sets; inadequate data quality documentation.
Touchpoint controls: data governance policies and data ownership; provenance and lineage tracking; data quality assessment and profiling; bias and representativeness analysis; privacy-enhancing techniques (anonymisation, pseudonymisation, synthetic data, differential privacy); legal review of data rights; data cards or datasheets for datasets; access controls and integrity checks on data pipelines; retention schedules.
Exam insight: Most fairness and bias questions trace back to data. If the scenario describes disparate outcomes and asks for the root cause, look first to training data representativeness and labelling.

Stage 3 - Model Development
Key risks: inappropriate algorithm or model selection; overfitting or underfitting; proxy variables that encode protected attributes; opaque models deployed where explainability is required; insecure development environments; dependence on third-party or open-source foundation models with unknown training data, licences or vulnerabilities; inadequate version control of code, data and models; undocumented assumptions; reproducibility failures.
Touchpoint controls: secure development life cycle practices adapted for ML (MLSecOps); experiment tracking and model versioning; model cards and documentation of design choices; feature review for proxies and leakage; explainability methods selected to match the use-case risk tier; third-party model due diligence and supply-chain controls (model bills of materials); peer review; segregation of duties between developers and validators.
Exam insight: When a scenario involves a vendor or foundation model, the development stage risk is about inherited and unknown risk; the control answer typically involves due diligence, contractual assurances, testing in your own context, and not relying solely on vendor claims.

Stage 4 - Verification and Validation
Key risks: testing only for accuracy and ignoring fairness, robustness, safety and security; evaluation on data that does not reflect production conditions; absence of independent validation; unaddressed adversarial vulnerabilities (evasion, prompt injection, model extraction, membership inference); hallucination and unsafe outputs in generative systems; metrics that do not map to acceptance criteria set at design; validation evidence not retained.
Touchpoint controls: a documented test plan tied to design requirements; multi-dimensional evaluation (performance, fairness across subgroups, robustness, security, privacy, explainability); adversarial testing and red-teaming; independent or second-line validation for higher-risk systems; human-in-the-loop evaluation; pre-deployment risk acceptance signed by the accountable owner; defined thresholds and conditions for release.
Exam insight: This is the primary 'gate' before production. Questions about whether a system should be released, or who should sign off, point here. Independence of the validator is a recurring theme.

Stage 5 - Deployment
Key risks: integration errors; configuration drift between test and production environments; inadequate access control to models, APIs and prompts; insufficient logging; lack of fallback or kill-switch; users not trained on limitations; missing transparency notices to affected individuals; deploying beyond the validated scope (scope creep); inadequate change management; over-automation without meaningful human oversight where required.
Touchpoint controls: formal change and release management; staged or canary rollouts and A/B testing; production readiness checklist; access management and secrets handling; logging and audit trails enabled from day one; rollback plans and circuit breakers; user training and guidance; transparency and disclosure to users and affected parties; defined human oversight mechanisms (human-in-the-loop, on-the-loop, in-command); registration in the AI inventory.
Exam insight: A classic trap is a system validated for one context and deployed in another. The deployment touchpoint control is to confirm the deployed use matches the validated and approved use.

Stage 6 - Operation and Monitoring
Key risks: data drift and concept drift degrading performance; emerging bias as populations change; model decay; new adversarial attacks; misuse by users or automation bias (over-reliance on outputs); unmanaged retraining introducing regressions; feedback loops that reinforce errors; incident response not adapted for AI failures; regulatory changes rendering the system non-compliant; third-party model updates changing behaviour without notice.
Touchpoint controls: continuous monitoring of performance, drift, fairness and security metrics with thresholds and alerts; key risk indicators reported to governance bodies; periodic re-validation and re-assessment on a schedule and on triggers; incident management and reporting procedures specific to AI; user feedback and complaint channels; retraining governance (treat retraining as a change requiring validation); vendor change notifications; periodic independent audit; ongoing documentation updates.
Exam insight: The most common exam distinction is between drift types and between monitoring and revalidation. Monitoring detects; revalidation confirms the system still meets requirements. Retraining is itself a change that must pass back through validation.

Stage 7 - Retirement and Decommissioning
Key risks: orphaned systems that keep running without an owner; data retained beyond legal limits or deleted when it should be preserved for audit or litigation; dependencies on the retired model that break downstream processes; loss of accountability records; residual model artefacts leaking sensitive information; incomplete removal of access rights.
Touchpoint controls: formal decommissioning procedure and approval; dependency mapping; secure deletion or archival in line with retention policy; preservation of documentation, decision logs and validation evidence; communication to users and stakeholders; update of the AI inventory; lessons-learned review feeding back into design standards.
Exam insight: Candidates often overlook this stage. If an answer option addresses retirement when the scenario mentions replacing or sunsetting a model, do not dismiss it.

Cross-Cutting Touchpoints

Several activities apply at every stage and are frequently the 'best' answer when a question is about overall program design rather than a single phase:
- Governance and accountability: defined roles (owner, developer, validator, risk, compliance, audit), committees and escalation paths.
- Documentation: impact assessments, data cards, model cards, test reports, decision logs - the evidence trail that enables audit and regulatory response.
- Risk assessment and tiering: performed initially and refreshed at each gate as understanding improves.
- Stakeholder engagement: including affected individuals, domain experts and legal, privacy and security functions.
- Security and privacy by design: embedded rather than bolted on.
- Third-party risk management: applied wherever external data, models, platforms or services enter the life cycle.
- Human oversight: designed in, tested, and maintained in operation.

Mapping to Reference Frameworks

The exam does not require memorising every framework's labels, but recognising equivalences helps. NIST AI RMF's four functions - Govern, Map, Measure, Manage - overlay the life cycle: Govern is cross-cutting; Map aligns most strongly with planning and design and context setting; Measure aligns with validation and monitoring; Manage aligns with treatment decisions, deployment and operation. ISO/IEC 42001 expects an AI management system that covers the full life cycle with documented processes and continual improvement. The EU AI Act imposes obligations that are stage-specific for high-risk systems (data governance, technical documentation, logging, human oversight, accuracy and robustness, post-market monitoring, incident reporting). When a question references a framework, translate it back to the life cycle stage it is addressing.

Exam Tips: Answering Questions on AI Life Cycle Stages and Risk Touchpoints

1. Identify the stage first. Read the scenario and ask: where in the life cycle is this organisation? Clues include words like 'proposal' or 'business case' (design), 'training set' or 'labelling' (data), 'hyperparameters' or 'fine-tuning' (development), 'test results' or 'red team' (validation), 'go-live' or 'integration' (deployment), 'in production' or 'performance has declined' (operation), and 'replacing' or 'sunsetting' (retirement). The correct answer is almost always the control that belongs to that stage.

2. Prefer the earliest effective touchpoint. ISACA favours preventive controls over detective and corrective ones. If a question asks for the best or most effective way to avoid a risk, the answer tends to sit earlier in the life cycle than the point where the problem became visible. Bias is best prevented at data and design; scope creep at design and deployment approval; drift is detected in operation but its handling should have been planned in design.

3. Distinguish root cause from symptom. When a question asks what most likely caused a problem observed in production, trace upstream. Disparate outcomes point to data; unexplained behaviour changes point to drift or an unmanaged retraining or vendor update; security breaches point to deployment access controls or development supply chain.

4. Know the key gate: validation before deployment. Questions about release decisions, sign-off, and independence of review are testing the verification and validation touchpoint. Remember that the accountable business owner accepts residual risk, while the validator should be independent of the developer.

5. Treat retraining and vendor updates as changes. A frequent distractor suggests that retraining is routine maintenance requiring no review. The correct view is that any change to data, model or configuration re-enters the life cycle and must be validated proportionate to risk.

6. Watch for scope and context shifts. If a system validated for one population, geography or purpose is used for another, the risk is a deployment touchpoint failure. The control is to reassess and revalidate for the new context, not to rely on the original validation.

7. Recognise cross-cutting answers. When a question is about the overall program, 'establish governance and accountability across the life cycle', 'maintain an AI inventory' or 'perform risk assessment at each stage gate' are typically stronger than any single technical control.

8. Match the control to the risk tier. ISACA emphasises proportionality. A minimal-risk internal tool does not need the same depth of independent validation as a high-impact decision system. If answer options differ in intensity, choose the one proportionate to the stated impact.

9. Do not confuse monitoring with revalidation. Monitoring is continuous and detective; revalidation is periodic or trigger-based and confirms continued fitness for purpose. If a scenario describes a threshold breach, the next step is investigation and potentially revalidation or rollback, not simply 'continue monitoring'.

10. Remember the human element. Automation bias, lack of user training and absent human oversight are life cycle risks too. Questions describing users blindly accepting outputs are pointing to deployment and operation controls around training, oversight design and transparency.

11. Eliminate answers that are out of sequence. Options such as 'deploy and then perform the impact assessment' or 'collect data before defining the purpose' violate life cycle logic and can be discarded quickly.

12. Think like a risk practitioner, not a data scientist. The exam tests judgement about risk ownership, governance and control placement. When torn between a technical fix and a governance action, ask which one addresses accountability and repeatability - that is usually what ISACA is looking for.

Quick Revision Summary

- The AI life cycle: Plan and Design, Data, Development, Validation, Deployment, Operation and Monitoring, Retirement - iterative, with governance cutting across all stages.
- A risk touchpoint is where risk is introduced, observable or controllable; controls and decision gates are anchored there.
- Design sets purpose, tier and accountability; Data drives bias and privacy risk; Development drives model and supply-chain risk; Validation is the release gate; Deployment manages integration, access and scope; Operation manages drift, incidents and change; Retirement manages orphaned systems and records.
- For exam questions: identify the stage, prefer early preventive touchpoints, trace symptoms to upstream root causes, treat every change as re-entering the life cycle, and apply controls proportionate to risk tier.