Skip to main content

AIGO — NIST AI RMF Lifecycle Mapping

AIGO — AI Governance Operating Framework

Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-MAP-NIST-AIRMF-004 Mapping Standard: NIST AI RMF 1.0 Mapping Type: Lifecycle Mapping

1. Purpose

This document defines the relationship between the NIST AI Risk Management Framework (AI RMF) and the AIGO AI Governance Lifecycle. The purpose of this mapping is to establish how NIST AI RMF Functions, Categories and Subcategories are operationalized throughout the AIGO lifecycle. The mapping recognizes that NIST AI RMF risk-management activities are continuous and iterative rather than strictly sequential. AIGO therefore provides lifecycle positioning for NIST activities while preserving the continuous nature of AI risk management.

2. Mapping Objective

The mapping establishes traceability between:
  • NIST AI RMF Functions;
  • NIST Categories;
  • NIST Subcategories;
  • AIGO lifecycle stages;
  • AIGO governance domains;
  • AIGO controls;
  • AIGO procedures;
  • AIGO roles;
  • evidence;
  • monitoring;
  • assurance;
  • continual improvement.

3. AIGO Lifecycle

The AIGO lifecycle consists of the following primary stages:
The lifecycle is iterative. A system may return to earlier stages when risk, context, requirements or system characteristics change.

4. NIST AI RMF Functions

The NIST AI RMF Core is organized around four Functions:

5. Lifecycle Mapping Principle

A NIST Function is not assigned to only one AIGO lifecycle stage. Instead:
One NIST category may therefore map to multiple lifecycle stages.

6. Govern

6.1 Lifecycle Objective

The Govern stage establishes the organizational foundation for responsible AI governance. It defines:
  • governance authority;
  • policies;
  • principles;
  • roles;
  • responsibilities;
  • decision rights;
  • risk appetite;
  • control expectations;
  • oversight;
  • regulatory context.

6.2 NIST Mapping

Primary NIST Function: GOVERN Supporting Functions:
  • MAP;
  • MEASURE;
  • MANAGE.

6.3 GOVERN Category Relationship


6.4 Governance Model


7. Identify

7.1 Lifecycle Objective

The Identify stage establishes the existence, purpose and context of the AI system. Activities include:
  • system identification;
  • owner identification;
  • purpose identification;
  • intended-use identification;
  • stakeholder identification;
  • dependency identification;
  • lifecycle initiation.

7.2 NIST Mapping

Primary Function: MAP Supporting Function: GOVERN

7.3 Mapping


8. AI System Registration

The Identify stage initiates formal AI system registration. The registration record should identify:
  • system name;
  • system identifier;
  • owner;
  • purpose;
  • intended use;
  • deployment context;
  • provider;
  • dependencies;
  • affected stakeholders;
  • initial risk information.

9. Classify

9.1 Lifecycle Objective

The Classify stage determines the governance and risk classification of the AI system. Classification should consider:
  • risk;
  • impact;
  • criticality;
  • autonomy;
  • affected stakeholders;
  • legal requirements;
  • data;
  • deployment context.

9.2 NIST Mapping

Primary Function: MAP Supporting Function: GOVERN

9.3 Classification Model


10. Assess

10.1 Lifecycle Objective

The Assess stage performs detailed AI risk assessment and control assessment. Activities include:
  • risk identification;
  • risk analysis;
  • impact assessment;
  • control assessment;
  • testing;
  • measurement;
  • trustworthiness evaluation.

10.2 NIST Mapping

Primary Function: MEASURE Supporting Functions:
  • MAP;
  • GOVERN.

11. Assessment Mapping


12. Measurement Model


13. Assess — Trustworthiness

AIGO assessment may consider relevant characteristics including:
  • validity;
  • reliability;
  • safety;
  • security;
  • resilience;
  • accountability;
  • transparency;
  • explainability;
  • privacy;
  • fairness.
The applicable characteristics should be determined according to system context and risk.

14. Treat

14.1 Lifecycle Objective

The Treat stage establishes and implements responses to identified risks. Possible treatment strategies include:
  • mitigation;
  • avoidance;
  • restriction;
  • redesign;
  • additional controls;
  • transfer;
  • acceptance;
  • suspension.

14.2 NIST Mapping

Primary Function: MANAGE Supporting Functions:
  • MEASURE;
  • GOVERN.

15. Risk Treatment Model


16. Approve

16.1 Lifecycle Objective

The Approve stage establishes whether the AI system may proceed to deployment or continued operation. Approval considers:
  • risk;
  • controls;
  • residual risk;
  • evidence;
  • testing;
  • legal requirements;
  • governance criteria.

16.2 NIST Mapping

Primary Function: GOVERN Supporting Functions:
  • MEASURE;
  • MANAGE.

17. Approval Decision


18. Deploy

18.1 Lifecycle Objective

The Deploy stage introduces the AI system into its approved operational environment. Deployment should confirm:
  • approved configuration;
  • approved purpose;
  • approved controls;
  • required monitoring;
  • required human oversight;
  • operational readiness.

18.2 NIST Mapping

Primary Functions: MANAGE + GOVERN Supporting Function: MEASURE

19. Deployment Control Gate


20. Operate

20.1 Lifecycle Objective

The Operate stage maintains the AI system within its approved governance and risk boundaries. Activities include:
  • operational use;
  • human oversight;
  • incident handling;
  • access management;
  • control operation;
  • operational monitoring.

20.2 NIST Mapping

Primary Functions:
  • GOVERN;
  • MEASURE;
  • MANAGE.

21. Operational Risk Model


22. Monitor

22.1 Lifecycle Objective

The Monitor stage continuously evaluates whether the AI system and its controls remain within acceptable parameters. Monitoring may include:
  • performance;
  • incidents;
  • drift;
  • risk indicators;
  • control effectiveness;
  • stakeholder feedback;
  • changes in context;
  • regulatory developments.

22.2 NIST Mapping

Primary Function: MEASURE Supporting Function: MANAGE

23. Monitoring Model


24. Assure

24.1 Lifecycle Objective

The Assure stage provides objective evaluation of governance, risk and control effectiveness. Assurance may include:
  • control review;
  • evidence review;
  • internal assessment;
  • independent assessment;
  • audit;
  • effectiveness evaluation.

24.2 NIST Mapping

Primary Function: MEASURE Supporting Functions:
  • GOVERN;
  • MANAGE.

25. Assurance Model


26. Improve

26.1 Lifecycle Objective

The Improve stage incorporates lessons learned, findings and performance information into the governance system. Inputs include:
  • monitoring;
  • incidents;
  • assurance;
  • management review;
  • stakeholder feedback;
  • changes in requirements;
  • emerging risks.

26.2 NIST Mapping

Primary Function: MANAGE Supporting Functions:
  • GOVERN;
  • MEASURE.

27. Improvement Model


28. Change

28.1 Lifecycle Objective

The Change stage governs material changes to AI systems, their context, controls or operating environment. Examples include:
  • model changes;
  • data changes;
  • provider changes;
  • purpose changes;
  • deployment changes;
  • integration changes;
  • regulatory changes.

28.2 NIST Mapping

Primary Functions:
  • MANAGE;
  • MEASURE.
Supporting Function:
  • GOVERN.

29. Change Management Model


30. Continue

30.1 Lifecycle Objective

The Continue decision confirms that an AI system remains appropriate for ongoing operation. The decision should consider:
  • current risk;
  • performance;
  • incidents;
  • control effectiveness;
  • monitoring results;
  • assurance findings;
  • stakeholder impacts;
  • regulatory context.

31. Retire

31.1 Lifecycle Objective

The Retire stage ensures that an AI system is appropriately discontinued. Activities include:
  • retirement authorization;
  • system shutdown;
  • dependency closure;
  • data disposition;
  • evidence retention;
  • stakeholder notification;
  • residual-risk closure.

31.2 NIST Mapping

Primary Function: MANAGE Supporting Functions:
  • GOVERN;
  • MAP.

32. Retirement Model


33. Cross-Lifecycle NIST Mapping


34. NIST Function Lifecycle Distribution

34.1 GOVERN

GOVERN is continuous.
Governance provides the decision framework across the lifecycle.

35. MAP

MAP is concentrated in the establishment and reassessment of context.
MAP activities may recur whenever context changes.

36. MEASURE

MEASURE operates throughout assessment and operational monitoring.

37. MANAGE

MANAGE translates identified and measured risk into decisions and actions.

38. Lifecycle Feedback Loop

The AIGO lifecycle is not a one-way process.

39. NIST Function Feedback Loop

The functions operate continuously and may be invoked simultaneously.

40. Lifecycle Risk Decision Model


41. Lifecycle Evidence Model

Every significant lifecycle stage should generate appropriate evidence.

42. Lifecycle Role Model


43. Lifecycle Control Model

Controls should be assigned according to lifecycle risk.
Controls may apply to multiple stages.

44. Lifecycle and NIST Subcategories

NIST Subcategories should be traced to lifecycle activities at the lowest practical level. A detailed record should identify:

45. Lifecycle Mapping Strength

The following codes may be used: A lifecycle mapping is not evidence of implementation.

46. Lifecycle Gap Assessment

Where a NIST element does not have an adequate lifecycle placement, the gap should be recorded. A gap record should contain:
  • NIST reference;
  • AIGO lifecycle stage;
  • missing capability;
  • risk;
  • owner;
  • remediation;
  • target date;
  • status;
  • evidence.

47. Lifecycle Change Trigger

The following events should trigger lifecycle reassessment where material:
  • change in intended purpose;
  • change in deployment context;
  • material model update;
  • material data change;
  • new provider;
  • new integration;
  • new stakeholder population;
  • new legal requirement;
  • significant incident;
  • material monitoring deviation;
  • significant assurance finding.

48. Lifecycle Incident Feedback

Incidents may force movement backward through the lifecycle.
Where the system cannot safely continue, suspension or retirement may be required.

49. Lifecycle Assurance Feedback

Assurance findings should feed into improvement.

50. Lifecycle Management Review

Management review should consider lifecycle performance as a whole. Inputs may include:
  • risk status;
  • monitoring;
  • incidents;
  • assurance findings;
  • control effectiveness;
  • stakeholder feedback;
  • regulatory developments;
  • changes;
  • improvement actions.
Outputs may include:
  • continued operation;
  • additional controls;
  • reassessment;
  • change;
  • suspension;
  • retirement.

51. Lifecycle-to-Procedure Traceability


52. Lifecycle-to-Mapping Architecture

The lifecycle mapping connects the NIST mapping suite.
Each mapping document addresses a different traceability dimension.

53. Lifecycle Integration with Risk

The AIGO risk lifecycle operates within the broader AI lifecycle.

54. Lifecycle Integration with Controls

Controls are lifecycle-dependent. A control may operate:
  • before deployment;
  • during deployment;
  • during operation;
  • during monitoring;
  • after change;
  • during retirement.
Therefore, control effectiveness should be evaluated in lifecycle context.

55. Lifecycle Integration with Evidence

Evidence should demonstrate actual lifecycle execution.

56. Lifecycle Integration with Assurance

Assurance should evaluate both:
  1. whether required lifecycle activities exist; and
  2. whether those activities operate effectively.

57. Continuous Lifecycle Model

The complete AIGO-NIST relationship can be represented as:

58. Governance Interpretation

The lifecycle mapping should be interpreted as an operationalization model. NIST AI RMF provides a flexible risk-management framework. AIGO provides the organizational lifecycle mechanisms through which those activities can be implemented, governed, evidenced and assured.

59. Mapping Limitations

This document does not:
  • reproduce the NIST AI RMF;
  • create NIST requirements;
  • constitute NIST certification;
  • constitute legal compliance;
  • replace organizational risk management;
  • replace technical validation;
  • guarantee AI system trustworthiness;
  • constitute NIST endorsement.

60. Maintenance Requirements

This document should be reviewed when:
  • NIST AI RMF changes;
  • AIGO lifecycle changes;
  • AIGO procedures change;
  • AIGO controls change;
  • risk methodology changes;
  • governance roles change;
  • material regulatory requirements change;
  • material lifecycle gaps are identified.

61. Document Change Record


62. Document Control

62.1 Controlled Information


63. Final Control Statement

This document establishes the lifecycle relationship between NIST AI RMF and the AIGO AI Governance Operating Framework. The mapping demonstrates how NIST AI RMF Functions, Categories and Subcategories may be operationalized throughout the AIGO lifecycle. The lifecycle should be treated as iterative and risk-driven rather than as a strictly linear sequence.
These functions operate continuously across the AIGO lifecycle.

64. End of Mapping Document

AIGO — NIST AI RMF Lifecycle Mapping Document ID: AIGO-MAP-NIST-AIRMF-004 Version: 0.1 Status: Draft Mapping Standard: NIST AI RMF 1.0 Mapping Type: Lifecycle Mapping End of Document