AIGO — NIST AI RMF Risk 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-005 Mapping Standard: NIST AI RMF 1.0 Mapping Type: Risk Mapping

1. Purpose

This document defines the relationship between the NIST AI Risk Management Framework (AI RMF) and the AIGO AI risk-management architecture. The purpose of this mapping is to establish traceability between NIST AI RMF risk-management concepts and the AIGO mechanisms used to identify, assess, treat, accept, monitor, communicate and continually improve AI-related risks. This document complements the AIGO-NIST AI RMF Lifecycle Mapping. The lifecycle mapping explains where NIST activities occur in the AIGO lifecycle. This document explains how AI risk is managed within that lifecycle.

2. Mapping Objectives

The mapping establishes relationships between:

NIST AI RMF Functions;
NIST AI RMF Categories;
NIST AI RMF Subcategories;
AIGO risk-management concepts;
AI risk identification;
AI risk analysis;
AI risk evaluation;
risk treatment;
residual risk;
risk acceptance;
risk escalation;
controls;
evidence;
monitoring;
assurance;
governance decisions;
continual improvement.

3. Risk Management Principle

AIGO treats AI risk management as a continuous governance process.

AI Context
   ↓
Risk Identification
   ↓
Risk Analysis
   ↓
Risk Evaluation
   ↓
Risk Treatment
   ↓
Residual Risk
   ↓
Risk Decision
   ↓
Monitoring
   ↓
Reassessment
   ↺

Risk management does not end when an AI system is approved. Risks must remain subject to monitoring and reassessment throughout the system lifecycle.

4. NIST AI RMF Risk Management Functions

The NIST AI RMF organizes AI risk management around four core Functions:

NIST Function	Risk Management Role
GOVERN	Establishes organizational risk-management structures
MAP	Establishes context and identifies risks
MEASURE	Measures and evaluates AI risks
MANAGE	Prioritizes and responds to AI risks

These Functions are complementary and iterative.

5. AIGO Risk Management Architecture

AIGO organizes AI risk management into the following major activities:

Govern
   ↓
Identify
   ↓
Classify
   ↓
Assess
   ↓
Treat
   ↓
Accept / Escalate
   ↓
Approve
   ↓
Operate
   ↓
Monitor
   ↓
Reassess
   ↓
Improve

The AIGO model provides operational mechanisms through which NIST AI RMF risk-management outcomes may be implemented.

6. Risk Governance

6.1 Objective

Risk governance establishes the authority, accountability and decision-making framework for AI risk. It defines:

risk ownership;
risk authority;
risk criteria;
risk appetite;
risk tolerance;
escalation thresholds;
approval authority;
reporting requirements;
documentation requirements.

6.2 NIST Mapping

Primary Function: GOVERN Supporting Functions:

MAP;
MEASURE;
MANAGE.

7. Risk Governance Model

Governance Authority
        ↓
Risk Policy
        ↓
Risk Criteria
        ↓
Risk Appetite
        ↓
Risk Thresholds
        ↓
Risk Ownership
        ↓
Risk Decisions
        ↓
Oversight

8. Risk Context

AI risk cannot be assessed independently of context. The AIGO risk assessment should consider:

intended purpose;
users;
affected persons;
stakeholders;
deployment environment;
system capabilities;
system limitations;
data;
dependencies;
third parties;
legal requirements;
organizational objectives.

9. NIST MAP Relationship

The MAP Function establishes context for AI risk management. AIGO operationalizes this through:

AI system registration;
system classification;
stakeholder identification;
intended-use analysis;
impact analysis;
dependency identification;
initial risk identification.

10. Risk Identification

Risk identification determines what could cause harm, failure, non-compliance or loss of governance control. Potential risk areas include:

safety;
security;
privacy;
fairness;
reliability;
resilience;
transparency;
explainability;
accountability;
legal compliance;
operational continuity;
reputational impact;
financial impact;
human impact.

11. Risk Identification Model

AI System
   ↓
Purpose
   ↓
Context
   ↓
Stakeholders
   ↓
Potential Harm
   ↓
Risk Scenario
   ↓
Risk Statement

12. Risk Statement

AIGO should express material risks in a structured form. A risk statement should identify: Cause → Event → Consequence Example structure:

Cause
  ↓
Risk Event
  ↓
Potential Impact

The exact risk statement should be system-specific.

13. Risk Taxonomy

AIGO may classify AI risks using multiple dimensions.

Risk Dimension	Example
Technical	Model failure
Data	Data quality or provenance issue
Security	Adversarial manipulation
Privacy	Unauthorized disclosure
Fairness	Disparate impact
Safety	Unsafe system behavior
Operational	Service failure
Governance	Unclear accountability
Legal	Regulatory non-compliance
Third Party	Supplier dependency
Human	Inappropriate reliance
Societal	Broader adverse impact

14. Risk Classification

Risks should be classified according to organizational criteria. Classification may consider:

severity;
likelihood;
exposure;
affected population;
reversibility;
detectability;
duration;
control strength;
regulatory significance.

15. Likelihood

Likelihood represents the assessed possibility that a risk event may occur. AIGO may use an organizational scale such as:

Level	Description
1	Rare
2	Unlikely
3	Possible
4	Likely
5	Almost Certain

The actual scale should be approved by the organization.

16. Impact

Impact represents the potential consequence of a risk event. Potential dimensions include:

individual harm;
organizational harm;
financial impact;
operational impact;
legal impact;
regulatory impact;
security impact;
privacy impact;
societal impact.

17. Impact Scale

AIGO may use:

Level	Description
1	Insignificant
2	Minor
3	Moderate
4	Major
5	Severe

The applicable impact model should be determined by organizational context.

18. Inherent Risk

Inherent risk represents risk before considering the effectiveness of implemented controls. AIGO may represent inherent risk as a combination of:

likelihood;
impact;
exposure;
contextual modifiers.

Conceptually:

Threat / Hazard
      ↓
Likelihood
      +
Impact
      ↓
Inherent Risk

19. Risk Analysis

Risk analysis evaluates identified risks. The analysis should consider:

causes;
consequences;
likelihood;
impact;
existing safeguards;
vulnerabilities;
affected stakeholders;
uncertainty.

20. NIST MEASURE Relationship

The MEASURE Function provides the basis for evaluating AI risk through:

testing;
assessment;
measurement;
evaluation;
monitoring;
evidence.

AIGO implements these activities through its risk and control assessment processes.

21. Risk Evaluation

Risk evaluation compares assessed risk against organizational criteria.

Risk Assessment
      ↓
Risk Score / Rating
      ↓
Risk Criteria
      ↓
Risk Appetite
      ↓
Risk Threshold
      ↓
Risk Decision

22. Risk Rating

AIGO may use a qualitative or quantitative risk rating. A simple model may use: Risk = Likelihood × Impact Where appropriate, additional factors may be applied. The selected methodology should be documented and consistently applied.

23. Risk Matrix

A representative risk matrix is:

Likelihood / Impact	1	2	3	4	5
1	Low	Low	Low	Low	Medium
2	Low	Low	Medium	Medium	High
3	Low	Medium	Medium	High	High
4	Low	Medium	High	High	Critical
5	Medium	High	High	Critical	Critical

This matrix is illustrative and should not be treated as a mandatory AIGO scoring model.

24. Risk Prioritization

Risks should be prioritized according to:

risk rating;
potential harm;
regulatory significance;
affected population;
organizational objectives;
urgency;
uncertainty;
control weakness.

25. NIST MANAGE Relationship

The MANAGE Function establishes how risks are prioritized and addressed. AIGO operationalizes this through:

risk treatment;
risk acceptance;
risk escalation;
control implementation;
remediation;
monitoring;
reassessment.

26. Risk Treatment

Risk treatment determines the appropriate response. Possible responses include:

avoid;
mitigate;
reduce;
transfer;
restrict;
accept;
suspend;
retire.

27. Risk Treatment Model

Identified Risk
      ↓
Risk Evaluation
      ↓
Treatment Decision
   ↙    ↓     ↘
Avoid  Mitigate  Accept
        ↓
      Control
        ↓
  Residual Risk

28. Risk Avoidance

Risk avoidance removes the activity, system, use case or condition that creates unacceptable risk. Examples may include:

cancelling deployment;
removing a use case;
restricting functionality;
discontinuing an unsafe capability.

29. Risk Mitigation

Risk mitigation reduces likelihood and/or impact. Possible measures include:

technical controls;
process controls;
human oversight;
access controls;
monitoring;
testing;
data controls;
security controls;
operational restrictions.

30. Risk Transfer

Risk transfer shifts a defined portion of risk responsibility to another party. Examples may include:

contractual controls;
supplier obligations;
insurance;
managed services.

Transfer does not necessarily eliminate organizational accountability.

31. Risk Restriction

Where complete mitigation is not practical, the organization may restrict:

users;
locations;
use cases;
system functionality;
decision authority;
operating conditions.

32. Risk Acceptance

Risk acceptance is a formal governance decision to tolerate residual risk. Acceptance should include:

identified risk;
risk rating;
residual risk;
rationale;
acceptance authority;
validity period;
review date;
conditions.

33. Risk Acceptance Model

Residual Risk
      ↓
Compare Against
Risk Appetite
      ↓
Within Tolerance?
   ↙           ↘
 Yes            No
 ↓              ↓
Accept       Escalate
                ↓
          Treat / Restrict /
          Suspend / Retire

34. Residual Risk

Residual risk is the risk remaining after controls and treatment measures are applied.

Inherent Risk
      ↓
Controls
      ↓
Treatment
      ↓
Residual Risk

Residual risk should be reassessed after material control implementation.

35. Control Effectiveness

Control effectiveness influences residual risk. AIGO should distinguish between:

control designed;
control implemented;
control operating;
control effective.

36. Residual Risk Model

Risk
 ↓
Control Design
 ↓
Implementation
 ↓
Operating Effectiveness
 ↓
Residual Risk
 ↓
Acceptance / Further Treatment

37. Risk Escalation

Risks should be escalated when:

risk exceeds tolerance;
controls are ineffective;
required treatment is delayed;
material harm occurs;
significant uncertainty exists;
risk ownership is unclear;
regulatory significance increases.

38. Escalation Model

Risk Identified
      ↓
Risk Evaluation
      ↓
Within Authority?
   ↙          ↘
 Yes           No
 ↓              ↓
Manage       Escalate
                ↓
        Higher Authority

39. Risk Ownership

Every material AI risk should have an accountable owner. The risk owner is responsible for ensuring that the risk is:

understood;
assessed;
treated;
monitored;
reported;
accepted or escalated where appropriate.

40. Risk Roles

Role	Risk Responsibility
Governance Authority	Risk governance and oversight
Risk Owner	Accountability for specific risk
AI System Owner	System-level risk coordination
Control Owner	Control implementation
Assessor	Independent or designated assessment
Assurance Function	Objective evaluation
Approval Authority	Formal risk decision
Operational Owner	Operational risk management

41. Risk Register

The AIGO risk register should provide traceability for material AI risks. Recommended fields include:

Field	Description
Risk ID	Unique identifier
AI System ID	Associated system
Risk Statement	Defined risk
Risk Category	Risk taxonomy
Cause	Risk cause
Consequence	Potential impact
Likelihood	Likelihood rating
Impact	Impact rating
Inherent Risk	Pre-control rating
Controls	Applicable controls
Residual Risk	Post-control rating
Treatment	Response
Risk Owner	Accountable owner
Status	Current status
Evidence	Supporting evidence
Review Date	Next review

42. Risk Traceability

Every material risk should be traceable across the governance architecture.

Risk ID
   ↓
AI System
   ↓
Lifecycle Stage
   ↓
Risk Assessment
   ↓
Control
   ↓
Procedure
   ↓
Evidence
   ↓
Decision
   ↓
Monitoring

43. Risk-to-Control Mapping

Risk treatment should be connected to controls.

Risk	Control Objective	Control	Evidence
Risk 001	Reduce identified risk	Control 001	Evidence
Risk 002	Prevent adverse outcome	Control 002	Evidence
Risk 003	Detect deviation	Control 003	Evidence

The exact relationship should be documented within the AIGO control architecture.

44. Risk-to-Lifecycle Mapping

Risks may arise at any lifecycle stage.

Lifecycle Stage	Typical Risk Activity
Govern	Risk governance
Identify	Initial risk identification
Classify	Risk categorization
Assess	Detailed risk assessment
Treat	Risk treatment
Approve	Risk decision
Deploy	Deployment risk verification
Operate	Operational risk management
Monitor	Continuous risk monitoring
Assure	Risk assurance
Improve	Risk-based improvement
Change	Change risk assessment
Continue	Continued-risk decision
Retire	Residual-risk closure

45. Risk-to-Evidence Mapping

Risk decisions should be supported by evidence. Representative evidence includes:

risk assessments;
test results;
control assessments;
monitoring records;
incident reports;
assurance reports;
stakeholder feedback;
management reviews;
approval records.

46. Risk Evidence Chain

Risk
 ↓
Assessment
 ↓
Control
 ↓
Measurement
 ↓
Evidence
 ↓
Evaluation
 ↓
Decision

47. Measurement and Risk

Risk measurement should be based on appropriate evidence. Measurements may include:

performance metrics;
error rates;
incident frequency;
control effectiveness;
drift indicators;
security findings;
fairness metrics;
privacy indicators;
reliability indicators.

The applicable measures depend on system context.

48. Uncertainty

AI risk management should account for uncertainty. Sources of uncertainty may include:

incomplete data;
unknown operating conditions;
model limitations;
emergent behavior;
limited testing;
uncertain stakeholder impacts;
incomplete documentation.

49. Uncertainty Management

Where uncertainty is material, the organization may apply:

additional testing;
conservative assumptions;
additional monitoring;
restricted deployment;
human oversight;
additional controls;
staged deployment;
escalation.

50. Third-Party Risk

AI systems may depend on:

foundation-model providers;
cloud providers;
data suppliers;
software vendors;
infrastructure providers;
external service providers.

Third-party risks should be incorporated into the AI risk assessment.

51. Third-Party Risk Model

Third Party
   ↓
Dependency
   ↓
Risk
   ↓
Contract / Control
   ↓
Monitoring
   ↓
Assurance

52. Data Risk

Data-related risks may include:

quality;
completeness;
accuracy;
provenance;
representativeness;
integrity;
privacy;
unauthorized use;
inappropriate retention.

Data risks should be linked to the affected AI system and lifecycle stage.

53. Model Risk

Model-related risks may include:

performance degradation;
unexpected behavior;
overfitting;
underperformance;
robustness weaknesses;
inappropriate generalization;
model drift.

Model risk should be measured according to the system’s intended purpose.

54. Human Oversight Risk

AI systems may create risk when humans:

over-rely on outputs;
misunderstand limitations;
fail to review outputs;
lack required competence;
cannot override the system;
are presented with insufficient information.

Human oversight should therefore be incorporated into relevant risk assessments.

55. Security Risk

Security-related AI risks may include:

unauthorized access;
prompt manipulation;
data poisoning;
model extraction;
adversarial attacks;
credential compromise;
malicious use.

Security risks should be integrated into the overall AI risk-management process.

56. Privacy Risk

Privacy risk assessment should consider:

personal data;
sensitive data;
data minimization;
purpose limitation;
access;
retention;
disclosure;
re-identification.

57. Fairness Risk

Where relevant, risk assessment should consider:

disparate impact;
demographic performance differences;
unequal error rates;
exclusion;
discriminatory outcomes.

Fairness assessment should be context-specific.

58. Safety Risk

Safety-related AI risks should consider:

foreseeable misuse;
system failure;
unsafe outputs;
human harm;
environmental impact;
failure modes;
safeguards.

59. Transparency and Explainability Risk

Where transparency or explainability is relevant, risks may arise from:

insufficient documentation;
unclear system limitations;
opaque decisions;
inadequate user information;
inability to understand important outputs.

60. Accountability Risk

Accountability risks may arise where:

ownership is unclear;
decisions are undocumented;
authority is ambiguous;
responsibilities overlap;
escalation mechanisms are absent.

AIGO should maintain clear role and decision traceability.

61. Incident-Driven Risk Reassessment

Material incidents should trigger risk reassessment.

Incident
   ↓
Containment
   ↓
Investigation
   ↓
Root Cause
   ↓
Risk Reassessment
   ↓
Control Reassessment
   ↓
Treatment
   ↓
Approval
   ↓
Monitoring

62. Change-Driven Risk Reassessment

Material changes should trigger risk reassessment. Examples include:

model changes;
data changes;
use-case changes;
provider changes;
architecture changes;
deployment changes;
regulatory changes.

63. Change Risk Model

Change
  ↓
Impact Analysis
  ↓
Risk Assessment
  ↓
Control Assessment
  ↓
Testing
  ↓
Approval
  ↓
Implementation
  ↓
Monitoring

64. Continuous Monitoring

Risk management continues during operation. Monitoring should identify:

emerging risks;
threshold breaches;
new incidents;
control failures;
performance changes;
changes in context.

65. Emerging Risk

Emerging risks may arise from:

new technology;
new threats;
new regulations;
new use cases;
changes in societal expectations;
unexpected system behavior.

Emerging-risk processes should connect monitoring with governance.

66. Risk Monitoring Model

Operational Data
      ↓
Risk Indicators
      ↓
Thresholds
      ↓
Deviation
      ↓
Risk Evaluation
      ↓
Management Action

67. Risk Thresholds

Organizations should define thresholds for:

escalation;
treatment;
suspension;
additional monitoring;
management review;
approval.

Thresholds should be documented and approved.

68. Risk Decision Model

Risk Evidence
      ↓
Risk Evaluation
      ↓
Decision Criteria
      ↓
Decision Authority
      ↓
Decision
      ↓
Decision Record

69. Decision Outcomes

Possible outcomes include:

approve;
conditionally approve;
require additional treatment;
restrict;
escalate;
suspend;
reject;
retire.

70. Risk Communication

Risk information should be communicated to relevant stakeholders according to:

role;
decision authority;
risk significance;
confidentiality;
legal requirements;
organizational policy.

71. Stakeholder Risk Communication

Risk communication may include:

risk reports;
management dashboards;
approval records;
incident notifications;
assurance findings;
management review outputs.

72. Risk Reporting

Risk reporting should provide decision-useful information. Reports may include:

top risks;
risk trends;
residual risks;
overdue treatments;
control weaknesses;
incidents;
emerging risks;
accepted risks.

73. Risk Trend Analysis

Risk trends should be monitored over time.

Historical Risk
      ↓
Current Risk
      ↓
Trend
      ↓
Forecast
      ↓
Management Action

74. Risk Acceptance Review

Accepted risks should not become permanently invisible. Risk acceptance should be periodically reviewed. Review should consider:

whether assumptions remain valid;
whether risk remains within tolerance;
whether new controls are available;
whether context changed;
whether incidents occurred.

75. Risk Treatment Effectiveness

Treatment effectiveness should be evaluated.

Treatment
   ↓
Implementation
   ↓
Measurement
   ↓
Effectiveness
   ↓
Residual Risk
   ↓
Continue / Adjust

76. Corrective Action

Where risk treatment is ineffective, corrective action should be initiated. Corrective actions should identify:

issue;
root cause;
action;
owner;
target date;
verification;
effectiveness.

77. Risk Assurance

Assurance should evaluate whether:

risks are identified;
assessments are appropriate;
controls address risks;
treatment is implemented;
residual risks are known;
accepted risks are authorized;
monitoring operates effectively.

78. Risk Assurance Model

Risk
 ↓
Assessment
 ↓
Treatment
 ↓
Control
 ↓
Evidence
 ↓
Assurance
 ↓
Finding
 ↓
Corrective Action

79. Risk Management Review

Management review should evaluate the effectiveness of the AI risk-management system. Inputs may include:

risk profile;
significant risks;
risk trends;
incidents;
control performance;
assurance findings;
treatment status;
accepted risks;
emerging risks.

80. Management Review Outputs

Possible outputs include:

revised risk criteria;
additional controls;
changes to risk appetite;
treatment priorities;
escalation;
system changes;
suspension;
retirement;
improvement actions.

81. Risk Maturity

Risk-management capability may mature through stages.

Level	Capability
1	Ad hoc risk identification
2	Defined risk assessment
3	Managed risk treatment
4	Measured and monitored risk
5	Integrated predictive risk management

These maturity levels are indicative and should align with the AIGO maturity model.

82. NIST-to-AIGO Risk Traceability

The following conceptual relationship applies:

NIST AI RMF	AIGO Risk Capability
GOVERN	Risk governance
MAP	Context and risk identification
MEASURE	Risk assessment and measurement
MANAGE	Treatment and risk decisions

83. NIST GOVERN Mapping

GOVERN establishes the organizational conditions required for risk management. AIGO maps GOVERN primarily to:

governance;
roles;
risk policy;
risk appetite;
accountability;
oversight;
documentation;
stakeholder management.

84. NIST MAP Mapping

MAP establishes the context in which AI risks are identified. AIGO maps MAP primarily to:

system registration;
classification;
intended use;
stakeholder analysis;
impact analysis;
risk identification;
lifecycle context.

85. NIST MEASURE Mapping

MEASURE establishes methods for evaluating AI risk. AIGO maps MEASURE primarily to:

risk assessment;
testing;
measurement;
control assessment;
monitoring;
assurance;
evidence evaluation.

86. NIST MANAGE Mapping

MANAGE establishes mechanisms for responding to AI risks. AIGO maps MANAGE primarily to:

risk treatment;
risk acceptance;
escalation;
mitigation;
restriction;
suspension;
change;
retirement;
continual improvement.

87. Risk Function Integration

The four NIST Functions should operate as an integrated risk system.

GOVERN
   ↓
MAP
   ↓
MEASURE
   ↓
MANAGE
   ↓
GOVERN
   ↺

No single Function should be interpreted as sufficient on its own.

88. Risk Lifecycle Integration

The NIST Functions can be positioned across the AIGO risk lifecycle.

AIGO
Govern
   ↓
Identify
   ↓
Assess
   ↓
Treat
   ↓
Accept
   ↓
Monitor
   ↓
Improve
   ↺

NIST
GOVERN
   ↓
MAP
   ↓
MEASURE
   ↓
MANAGE
   ↓
MEASURE
   ↺

89. Risk-to-Control Traceability

The minimum traceability relationship should be:

NIST Risk Outcome
       ↓
AIGO Risk
       ↓
Risk Treatment
       ↓
AIGO Control
       ↓
Procedure
       ↓
Evidence
       ↓
Effectiveness

90. Risk-to-Procedure Traceability

Risk Activity	AIGO Procedure
Governance	AI Governance Procedure
Registration	AI System Registration Procedure
Assessment	AI Risk Assessment Procedure
Classification	AI Classification Procedure
Control Evaluation	AI Control Assessment Procedure
Approval	AI Approval Procedure
Monitoring	AI Monitoring Procedure
Assurance	AI Assurance Procedure
Acceptance	AI Risk Acceptance Procedure
Change	AI Change Management Procedure
Retirement	AI Retirement Procedure
Improvement	Continuous Improvement Procedure

91. Risk-to-Evidence Traceability

Evidence should demonstrate that risk-management activities occurred. Examples:

Risk Activity	Evidence
Identification	Risk record
Assessment	Risk assessment
Treatment	Treatment plan
Control	Control assessment
Acceptance	Acceptance record
Monitoring	Monitoring report
Incident	Incident record
Assurance	Assurance report
Change	Change assessment
Improvement	Corrective-action record

92. Risk Gap Analysis

AIGO should identify gaps where NIST risk-management outcomes are not adequately addressed. A gap may exist when:

no responsible owner exists;
no risk assessment exists;
no treatment exists;
no control exists;
no evidence exists;
no monitoring exists;
no decision authority exists.

93. Risk Gap Record

A gap record should contain:

Field	Description
Gap ID	Unique identifier
NIST Reference	Relevant NIST element
AIGO Reference	Relevant AIGO element
Risk	Associated risk
Gap Description	Identified deficiency
Impact	Consequence
Owner	Responsible person
Action	Remediation
Target Date	Planned completion
Status	Current status
Evidence	Closure evidence

94. Risk Management Effectiveness

Effectiveness should be evaluated based on outcomes, not documentation alone. Relevant indicators may include:

reduction in material risk;
control effectiveness;
incident trends;
treatment completion;
monitoring performance;
assurance findings;
timely escalation;
decision quality.

95. Risk Metrics

Possible risk metrics include:

number of high risks;
number of critical risks;
percentage of risks with owners;
percentage of risks with treatment plans;
overdue treatments;
accepted-risk count;
incidents by risk category;
control failure rate;
reassessment completion rate.

96. Risk Dashboard

A risk dashboard may summarize:

Risk Profile
     ↓
Critical Risks
     ↓
High Risks
     ↓
Emerging Risks
     ↓
Overdue Treatments
     ↓
Control Weaknesses
     ↓
Incidents
     ↓
Management Actions

97. Risk Data Quality

Risk records should be:

complete;
accurate;
current;
traceable;
attributable;
reviewable.

Poor risk-data quality can itself become a governance risk.

98. Risk Documentation

Material risk decisions should be documented sufficiently to demonstrate:

what was known;
what was assessed;
what decision was made;
who made the decision;
why the decision was made;
what evidence supported the decision;
what conditions apply.

99. Risk Record Retention

Risk records should be retained according to:

organizational policy;
legal requirements;
regulatory obligations;
contractual requirements;
evidence requirements.

100. Risk Management and Continual Improvement

Risk-management outputs should feed continual improvement.

Risk Experience
      ↓
Lesson Learned
      ↓
Root Cause
      ↓
Improvement Opportunity
      ↓
Change
      ↓
Implementation
      ↓
Measurement
      ↓
New Risk Information
      ↺

101. Risk Management Operating Model

The overall AIGO-NIST risk relationship can be represented as:

                  GOVERN
                     ↓
              Risk Governance
                     ↓
                    MAP
                     ↓
              Risk Context
                     ↓
              Risk Identification
                     ↓
                 MEASURE
                     ↓
              Risk Assessment
                     ↓
              Risk Evaluation
                     ↓
                 MANAGE
                     ↓
              Risk Treatment
                     ↓
             Residual Risk
                     ↓
            Accept / Escalate
                     ↓
                  Monitor
                     ↓
                 Reassess
                     ↓
                 Improve
                     ↺

102. Risk Decision Traceability

Every significant risk decision should be traceable to:

Decision
   ↓
Authority
   ↓
Risk
   ↓
Assessment
   ↓
Evidence
   ↓
Controls
   ↓
Residual Risk
   ↓
Rationale

103. Risk and AI System Approval

AI system approval should consider whether:

material risks are identified;
risks are assessed;
controls are implemented;
residual risk is known;
required evidence exists;
risk acceptance is authorized where necessary.

Approval should not be interpreted as elimination of risk.

104. Risk and AI System Operation

Operational approval should remain conditional on continued compliance with:

approved purpose;
risk limits;
controls;
monitoring requirements;
human oversight;
applicable requirements.

105. Risk and AI System Change

Changes should be risk-based. A material change should trigger:

change classification;
impact assessment;
risk reassessment;
control reassessment;
testing;
approval;
post-change monitoring.

106. Risk and AI System Retirement

Before retirement, the organization should consider:

residual risk;
dependencies;
data;
security;
operational continuity;
stakeholder impacts;
evidence retention.

107. Risk Closure

A risk may be closed when:

the associated activity ends;
the system is retired;
the risk is eliminated;
the risk is transferred according to approved criteria;
the risk is otherwise formally resolved.

Risk closure should be documented.

108. Risk Management Controls

The AIGO control framework should provide controls for:

risk identification;
risk assessment;
risk treatment;
risk acceptance;
risk monitoring;
risk escalation;
risk reporting;
risk assurance.

109. Risk Control Effectiveness

Risk controls should be evaluated for:

design adequacy;
implementation;
operation;
effectiveness;
evidence;
residual risk impact.

110. Risk Monitoring Triggers

Risk reassessment should be triggered by material:

incidents;
changes;
performance deviations;
control failures;
stakeholder concerns;
regulatory changes;
threat changes;
system drift.

111. Risk Reassessment Model

Existing Risk
      ↓
New Information
      ↓
Context Review
      ↓
Risk Reassessment
      ↓
Control Review
      ↓
Residual Risk
      ↓
Decision

112. Risk Communication and Escalation

Material risks should be communicated to the appropriate governance level. Communication should be proportionate to:

severity;
urgency;
uncertainty;
affected stakeholders;
decision authority.

113. Risk Governance Escalation Levels

An organization may establish levels such as:

Level	Governance Response
Low	Operational management
Moderate	Risk owner review
High	Governance escalation
Critical	Senior authority / suspension consideration

These levels are illustrative.

114. Risk Acceptance Authority

Risk acceptance authority should correspond to risk significance. Higher risks should require higher approval authority. The authority matrix should be formally defined within AIGO governance documentation.

115. Risk Appetite

Risk appetite defines the level and type of risk the organization is willing to pursue or retain. AI risk appetite should consider:

strategic objectives;
regulatory requirements;
stakeholder expectations;
safety;
security;
privacy;
fairness;
organizational capability.

116. Risk Tolerance

Risk tolerance establishes acceptable variation around risk objectives or thresholds. Tolerance levels should be documented where meaningful.

117. Risk Appetite and Treatment

Risk
 ↓
Risk Rating
 ↓
Risk Appetite
 ↓
Risk Tolerance
 ↓
Treatment / Acceptance

118. NIST Risk Management Alignment Summary

NIST Function	AIGO Risk Mechanism
GOVERN	Governance and accountability
MAP	Context and identification
MEASURE	Assessment and measurement
MANAGE	Treatment and decision-making

119. End-to-End Risk Traceability

The complete traceability chain is:

NIST AI RMF
      ↓
NIST Risk Outcome
      ↓
AIGO Risk Domain
      ↓
AI Risk
      ↓
Risk Assessment
      ↓
Risk Treatment
      ↓
Control
      ↓
Procedure
      ↓
Evidence
      ↓
Monitoring
      ↓
Assurance
      ↓
Management Decision
      ↓
Continual Improvement

120. Mapping Limitations

This document:

does not reproduce the NIST AI RMF;
does not constitute NIST certification;
does not constitute legal advice;
does not establish regulatory compliance by itself;
does not replace organization-specific risk assessment;
does not replace technical testing;
does not eliminate AI risk;
does not constitute NIST endorsement.

The mapping provides a governance traceability structure.

121. Maintenance Requirements

This document should be reviewed when:

NIST AI RMF changes;
AIGO risk methodology changes;
AIGO risk taxonomy changes;
risk criteria change;
risk appetite changes;
AIGO controls change;
procedures change;
material regulatory requirements change;
material gaps are identified.

122. Document Change Record

Version	Date	Change	Author	Reviewer	Approval
0.1		Initial NIST AI RMF Risk Mapping

123. Document Control

123.1 Controlled Information

Field	Value
Document Title	AIGO — NIST AI RMF Risk Mapping
Document ID	`AIGO-MAP-NIST-AIRMF-005`
Version	0.1
Status	Draft
Framework	AIGO AI Governance Operating Framework
Mapping Standard	NIST AI RMF 1.0
Mapping Domain	Risk Management
Primary Owner
Technical Reviewer
Governance Reviewer
Approver
Effective Date
Next Review Date

124. Final Control Statement

This document establishes the risk-management relationship between the NIST AI RMF and the AIGO AI Governance Operating Framework. It provides traceability between NIST AI RMF risk-management Functions and the AIGO mechanisms for:

risk governance;
risk identification;
risk assessment;
risk measurement;
risk treatment;
residual-risk management;
risk acceptance;
escalation;
monitoring;
assurance;
continual improvement.

The mapping should be maintained as a controlled living document and updated when the underlying NIST framework, AIGO architecture, risk methodology, controls, procedures or organizational context materially changes.

125. End of Mapping Document

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

​AIGO — NIST AI RMF Risk Mapping

​AIGO — AI Governance Operating Framework

​1. Purpose

​2. Mapping Objectives

​3. Risk Management Principle

​4. NIST AI RMF Risk Management Functions

​5. AIGO Risk Management Architecture

​6. Risk Governance

​6.1 Objective

​6.2 NIST Mapping

​7. Risk Governance Model

​8. Risk Context

​9. NIST MAP Relationship

​10. Risk Identification

​11. Risk Identification Model

​12. Risk Statement

​13. Risk Taxonomy

​14. Risk Classification

​15. Likelihood

​16. Impact

​17. Impact Scale

​18. Inherent Risk

​19. Risk Analysis

​20. NIST MEASURE Relationship

​21. Risk Evaluation

​22. Risk Rating

​23. Risk Matrix

​24. Risk Prioritization

​25. NIST MANAGE Relationship

​26. Risk Treatment

​27. Risk Treatment Model

​28. Risk Avoidance

​29. Risk Mitigation

​30. Risk Transfer

​31. Risk Restriction

​32. Risk Acceptance

​33. Risk Acceptance Model

​34. Residual Risk

​35. Control Effectiveness

​36. Residual Risk Model

​37. Risk Escalation

​38. Escalation Model

​39. Risk Ownership

​40. Risk Roles

​41. Risk Register

​42. Risk Traceability

​43. Risk-to-Control Mapping

​44. Risk-to-Lifecycle Mapping

​45. Risk-to-Evidence Mapping

​46. Risk Evidence Chain

​47. Measurement and Risk

​48. Uncertainty

​49. Uncertainty Management

​50. Third-Party Risk

​51. Third-Party Risk Model

​52. Data Risk

​53. Model Risk

​54. Human Oversight Risk

​55. Security Risk

​56. Privacy Risk

​57. Fairness Risk

​58. Safety Risk

​59. Transparency and Explainability Risk

​60. Accountability Risk

​61. Incident-Driven Risk Reassessment

​62. Change-Driven Risk Reassessment

​63. Change Risk Model

​64. Continuous Monitoring

​65. Emerging Risk

​66. Risk Monitoring Model

​67. Risk Thresholds

​68. Risk Decision Model

​69. Decision Outcomes

​70. Risk Communication

​71. Stakeholder Risk Communication

​72. Risk Reporting

​73. Risk Trend Analysis

​74. Risk Acceptance Review

​75. Risk Treatment Effectiveness

​76. Corrective Action