> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aigoframework.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 05 AIGO NIST AI RMF Risk Mapping v0.1

# 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.

```text theme={null}
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:

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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.

```text theme={null}
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:

1. avoid;
2. mitigate;
3. reduce;
4. transfer;
5. restrict;
6. accept;
7. suspend;
8. retire.

***

# 27. Risk Treatment Model

```text theme={null}
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

```text theme={null}
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.

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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.

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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.

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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.

```text theme={null}
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.

```text theme={null}
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

```text theme={null}
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.

```text theme={null}
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.

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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.

```text theme={null}
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:

```text theme={null}
                  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:

```text theme={null}
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:

1. change classification;
2. impact assessment;
3. risk reassessment;
4. control reassessment;
5. testing;
6. approval;
7. 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

```text theme={null}
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

```text theme={null}
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:

```text theme={null}
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**