| Planning & Design |
Problem framing, requirements definition, AI appropriateness, and success metrics. |
- Define the use case, intended outcomes, and feasibility.
- Identify data and model needs.
- Shape the high-level system approach.
|
- Define business-process fit and workflow integration.
- Set ownership and KPIs.
- Clarify operating context.
|
- Provide domain constraints and edge cases.
- Describe the real decision context.
- Clarify acceptable-use boundaries.
|
- Review fit with law, policy, and risk appetite.
- Set approval expectations.
- Require documentation and accountability.
|
- AI use-case intake.
- AI impact assessment.
- Stakeholder map.
- Initial risk register.
- RACI and approval memo.
|
- NIST AI RMF Govern and Map.
- AIGP organizational accountability and AI Owner designation.
- EU AI Act initial risk categorization and prohibited-practice screening.
- OECD and UNESCO principle-level anchors.
|
- Mis-scoped use case.
- Inappropriate automation.
- Failure to identify affected groups.
- Weak accountability or no human oversight concept.
|
- Formal AI impact assessment.
- Early governance review.
- Accountable owner assignment.
- Human-in-the-loop design.
- Purpose limitation.
|
- AI governance council.
- Privacy and data governance review.
- Legal and security consultation.
- Executive sponsor decision point.
|
NIST Govern 1.1–1.3 and Map 2.1–2.2; EU AI Act Chapter II risk classification; AIGP organizational accountability themes. | Should AI be used at all, who approves it, and what assessment must happen before build? |
| Data Collection & Preparation |
Data sourcing, cleaning, labeling, feature engineering, representativeness, provenance, and privacy or security controls. |
- Source and preprocess data.
- Document quality, bias, lineage, and suitability.
- Handle labeling and feature preparation.
|
- Provide secure infrastructure and permissions.
- Manage logging and retention settings.
- Control the pipeline environment.
|
- Validate whether the data reflects the operational reality.
- Flag gaps, misleading proxies, or skew.
|
- Confirm lawful basis and contractual authority.
- Enforce minimization and sensitive-data rules.
|
- Data inventory.
- Lineage record.
- Consent or contract record.
- Dataset card.
- Preprocessing log.
|
- GDPR, FERPA, HIPAA-style constraints where relevant.
- NIST data and input considerations.
- ISO-aligned data governance expectations.
|
- Representational bias.
- Privacy violations.
- Unauthorized data use.
- Poor quality data.
- Re-identification risk.
- Incomplete data lineage or provenance.
|
- Data minimization.
- Access control.
- Sensitive-data review.
- Bias checks.
- Lineage documentation.
- De-identification where appropriate.
|
- Data governance committee.
- Privacy office.
- Information security.
- Vendor management where third-party data is involved.
|
NIST Map 2.3–2.4 and Measure 3.1–3.2; EU AI Act data governance and quality obligations; GDPR principles. | Is the dataset appropriate, lawful, representative, and documented before training starts? |
| Model Development & Training |
Model selection, architecture, algorithm choice, training runs, hyperparameter tuning, feature use, and performance baselines. |
- Design and train the model.
- Select metrics.
- Record assumptions and experiments.
- Tune the model.
|
- Define production constraints like latency, resiliency, and scalability.
- Prepare build choices that will survive production.
|
- Offer domain interpretation of outputs and metrics.
- Help ensure optimization maps to operational usefulness.
|
- Ensure development follows the approved purpose and policy controls.
- Watch for high-risk obligations taking shape.
|
- Training logs.
- Experiment records.
- Model card draft.
- Design documentation.
- Approved metrics.
|
- NIST Measure and Manage concepts.
- EU AI Act provider obligations for high-risk systems shaping documentation expectations.
|
- Overfitting.
- Hidden bias.
- Undocumented design choices.
- Misaligned objective functions.
- Opaque model behavior.
|
- Change control in development.
- Traceable training history.
- Documented evaluation criteria.
- Separation of duties where appropriate.
- Reproducibility and version control of data, code, and models.
|
- Technical review board.
- Model risk review.
- Architecture review.
- AI governance checkpoint.
|
NIST Measure 3.3–3.5; EU AI Act provider obligations and Annex IV technical documentation expectations. | What should developers document during build, and what evidence is already governance-relevant? |
| Validation & Testing |
Performance, fairness, robustness, stress testing, red-teaming, threshold comparison, and usability review. |
- Run holdout and scenario-based tests.
- Assess fairness, robustness, explainability, and failure modes.
|
- Prepare deployment gates based on validation outcomes.
- Define operational acceptance thresholds.
|
- Participate in reasonableness checks.
- Support acceptance testing on real scenarios.
|
- Review whether results satisfy policy, assurance, and risk tolerance.
|
- Validation report.
- Fairness assessment.
- Robustness testing results.
- User acceptance notes.
- Threshold approval record.
|
- NIST Measure and Manage.
- EU AI Act testing, risk management, and human oversight design expectations.
|
- False confidence.
- Performance disparities.
- Weak edge-case testing.
- Poor explainability.
|
- Bias testing.
- Robustness checks.
- Red-teaming.
- Representative validation datasets.
- Remediation loops before deployment.
- Independent validation and stress testing.
|
- AI risk review committee.
- Quality assurance.
- Business owner signoff.
- Escalation on material harm.
|
NIST Measure 3.6–3.7 and Manage 4.1; EU AI Act Article 9 risk management and Article 15 testing and validation. | Which testing activity belongs here, and what should happen if fairness or robustness thresholds are not met? |
| Verification & Release |
Confirmation that the model and system meet requirements, constraints, documentation standards, and release conditions. |
- Verify the system against requirements, policy conditions, and technical specifications.
- Finalize documentation.
|
- Confirm the system can safely move into production.
- Check operational readiness.
|
- Confirm limitations and decision-support expectations are understandable to end users.
|
- Decide whether pre-deployment evidence is sufficient.
- Determine whether release conditions are satisfied.
|
- Final model card.
- Verification checklist.
- Release recommendation.
- Risk acceptance or exception record.
- Technical documentation package.
- Conformity assessment documentation for high-risk systems.
|
- EU AI Act technical documentation, logging, and risk management duties.
- NIST Manage concepts for release readiness.
|
- Releasing a system that does not meet stated requirements.
- Incomplete documentation.
- Ambiguous accountability.
|
- Formal pre-deployment gate.
- Evidence review.
- Exception handling.
- Signoff workflow.
- Logging readiness.
|
- Governance board or accountable executive signoff.
- Escalation where residual risk is accepted instead of remediated.
|
NIST Manage 4.2; EU AI Act conformity assessment, CE marking, EU declaration of conformity, and technical documentation requirements. | Is this a validation problem or a verification problem, and what signoff or artifact is missing before go-live? |
| Deployment & Integration |
Production configuration, system integration, access control, human oversight workflow, and operational enablement. |
- Support production handoff.
- Implement technical guardrails.
- Explain limitations and failure modes.
|
- Integrate into systems and workflows.
- Configure runtime settings, authentication, logging, and change management.
|
- Use outputs within approved workflows.
- Apply required review.
- Identify unexpected behavior.
|
- Approve go-live.
- Ensure transparency and training duties are met.
- Confirm operational accountability.
|
- Go-live decision record.
- Deployment checklist.
- User guidance.
- Transparency notice.
- SOP updates.
- Monitoring plan.
|
- EU AI Act deployer obligations.
- NIST Manage implementation, logging, oversight, and traceability.
|
- Unsafe integration.
- Access misuse.
- Automation bias.
- Over-reliance.
- Missing transparency.
- Untrained users.
|
- User training.
- Human-in-the-loop enforcement.
- Monitoring hooks.
- Least-privilege access.
- Runtime guardrails.
- Configuration management and change control.
|
- Change advisory board.
- AI governance council.
- Business owner.
- IT operations.
- Privacy and legal.
|
NIST Manage 4.3; EU AI Act deployer obligations including Articles 26 and 29, plus human oversight implementation. | What must the deployer do at launch around oversight, user enablement, and logging? |
| Operation, Monitoring & Incident Response |
Monitoring, drift detection, feedback loops, auditability, retraining triggers, rollback, and incident handling. |
- Investigate drift and incidents.
- Propose retraining or remediation.
- Update documentation after significant changes.
|
- Monitor uptime, logs, security events, and rollback or kill-switch capabilities.
- Implement approved changes.
|
- Report anomalies and harms.
- Provide outcome feedback.
- Avoid use outside approved boundaries.
|
- Conduct audits.
- Track key risk indicators.
- Oversee incident response, accountability, and communications.
|
- Monitoring dashboard.
- Incident log.
- Audit record.
- Retraining trigger criteria.
- Change ticket.
- Periodic review report.
|
- NIST Manage.
- EU AI Act post-market monitoring, logging, and serious-incident expectations.
|
- Drift.
- Degraded performance.
- Misuse.
- Unauthorized changes.
- Silent failures.
- Unreported harms.
- Model drift or performance degradation without detection.
|
- Continuous monitoring.
- Incident playbooks.
- Rollback or suspension.
- Audit logging.
- Retraining governance.
- Redress channels.
|
- Incident response team.
- Audit and risk.
- AI council.
- Security operations.
- Privacy and legal.
- Executive escalation.
|
NIST Manage 4.4–4.6; EU AI Act post-market monitoring, logging, serious-incident reporting, and deployer oversight in practice. | What should happen after deployment when drift, harm, or complaints appear, and who should act first? |
| Decommissioning / Retirement |
End-of-life planning, archival, deletion, transition, dependency cleanup, and records closure. |
- Document final state.
- Support shutdown.
- Advise on archive, deletion, or controlled reuse.
|
- Remove the system from production.
- Revoke access.
- Update dependencies.
- Handle retention or disposal correctly.
|
- Transition to replacement or manual processes.
- Communicate changes to stakeholders.
|
- Verify retention, deletion, and closure obligations.
- Capture lessons learned.
|
- Retirement decision memo.
- Decommissioning checklist.
- Disposal record.
- Archival log.
- Lessons-learned report.
|
- Data retention and deletion rules.
- Accountability record closure.
- Audit-trail preservation where required.
|
- Orphaned models.
- Residual access.
- Retained sensitive data without purpose.
- Undocumented dependencies.
|
- Formal retirement plan.
- Access revocation.
- Deletion or archival controls.
- Dependency review.
- Post-mortem governance review.
|
- Records management.
- Privacy.
- Security.
- System owners.
- Governance council.
|
NIST Govern and Manage closure activities; record retention and deletion obligations. | What obligations remain after operational use ends, and what records or controls must remain? |
| Cross-Cutting Overlay |
Governance applies horizontally across all phases, not as a single checkpoint. |
- Maintain traceability and documentation.
- Stay aligned to approved purpose across the lifecycle.
|
- Operate within approved conditions.
- Maintain controls and avoid unauthorized scope creep.
|
- Understand limitations, escalation paths, and conditions for relying on outputs.
|
- Maintain policies, charters, accountability, risk appetite, incident governance, and assurance structures.
|
- Policies and standards.
- Charters.
- Risk taxonomy.
- Control library.
- Training materials.
- Vendor due diligence records.
|
- NIST AI RMF Govern as the foundation.
- ISO/IEC 42001-style management system thinking.
- EU AI Act role-based obligations.
|
- Governance fragmentation.
- Unclear role boundaries.
- Lack of evidence.
- Poor culture.
- Third-party risk.
- Ad hoc AI use.
|
- Governance charter.
- RACI.
- Training.
- Risk register.
- Committee cadence.
- Vendor review.
- Auditability and redress mechanisms.
- Periodic governance effectiveness review.
|
- AI governance council.
- Enterprise risk.
- Privacy.
- Security.
- Procurement.
- Legal.
- Executive leadership.
|
NIST Govern function across the lifecycle; ISO/IEC 42001 AI management system thinking; role-based obligations and governance accountability. | Which control, artifact, or accountable role is missing in the scenario, rather than only what the technical issue is? |