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

# 03 AIGO AI Risk Assessment Procedure v0.1

# AIGO — AI Governance Operating Framework

## AI Risk Assessment Procedure

**Version:** 0.1\
**Status:** Draft\
**Working Name:** AIGO\
**Full Name:** AI Governance Operating Framework\
**Document Identifier:** AIGO-PROC-003

***

### 1. Purpose

This procedure defines the process for identifying, assessing, documenting, treating, accepting, monitoring, and reviewing risks associated with AI systems.

The procedure establishes a consistent risk assessment process aligned with the AIGO AI Risk Management framework.

***

### 2. Scope

This procedure applies to AI systems and AI-related activities within the organization's AIGO governance scope.

It may apply to:

* new AI systems;
* existing AI systems;
* material system changes;
* AI models;
* generative AI;
* AI agents;
* third-party AI services;
* AI-enabled business processes; and
* AI systems undergoing periodic reassessment.

***

### 3. Objectives

The objectives of AI risk assessment are to:

* identify AI-related risks;
* understand potential impacts;
* assess likelihood and severity;
* determine inherent risk;
* identify applicable controls;
* determine residual risk;
* support risk treatment;
* establish risk ownership;
* support governance decisions; and
* provide evidence for monitoring and assurance.

***

### 4. Risk Assessment Principles

AI risk assessments should be:

* risk-based;
* proportionate;
* evidence-based;
* multidisciplinary;
* lifecycle-oriented;
* documented;
* traceable; and
* periodically reviewed.

***

### 5. Risk Assessment Responsibility

The AI system owner is responsible for ensuring that required risk assessments are completed.

Specialist functions should participate where appropriate.

These may include:

* AI governance;
* risk management;
* security;
* privacy;
* legal;
* compliance;
* technical specialists;
* domain experts; and
* assurance functions.

***

### 6. Risk Assessment Triggers

A risk assessment should be initiated or refreshed when:

* a new AI system is proposed;
* an existing system changes materially;
* the intended purpose changes;
* new data is introduced;
* the model changes;
* autonomy increases;
* a significant incident occurs;
* a new risk is identified;
* regulations change;
* a provider changes; or
* periodic reassessment is due.

***

### 7. Risk Assessment Preparation

Before beginning the assessment, the responsible team should gather relevant information.

Information may include:

* system description;
* intended purpose;
* AI System Profile;
* users;
* data;
* model;
* architecture;
* deployment environment;
* dependencies;
* existing controls;
* monitoring information; and
* previous assessments.

***

### 8. Assessment Team

The assessment team should include appropriate expertise for the AI system.

Depending on risk, the team may include:

* system owner;
* technical owner;
* risk specialist;
* security specialist;
* privacy specialist;
* legal or compliance specialist;
* business subject matter expert; and
* AI governance representative.

***

### 9. Intended Purpose

The intended purpose should be clearly documented before assessing risk.

The assessment should consider:

* intended use;
* intended users;
* expected outputs;
* supported decisions;
* supported actions;
* operating environment;
* known limitations; and
* prohibited uses where applicable.

***

### 10. Context Assessment

The assessment should establish the context in which the AI system operates.

Context may include:

* organizational environment;
* business process;
* affected individuals;
* geographic scope;
* regulatory environment;
* technical environment;
* operational dependencies; and
* criticality.

***

### 11. Stakeholder Identification

Relevant stakeholders should be identified.

Stakeholders may include:

* users;
* customers;
* employees;
* affected individuals;
* business owners;
* regulators;
* suppliers;
* operators;
* security personnel; and
* governance authorities.

***

### 12. Risk Identification

Risks should be identified systematically.

Potential risk categories include:

* safety;
* security;
* privacy;
* fairness;
* discrimination;
* accuracy;
* reliability;
* transparency;
* explainability;
* accountability;
* human oversight;
* legal and regulatory compliance;
* operational resilience;
* third-party dependency;
* financial impact;
* reputational impact; and
* societal impact.

***

### 13. AI-Specific Risk Factors

The assessment should consider AI-specific characteristics.

These may include:

* probabilistic behavior;
* model uncertainty;
* training data limitations;
* data drift;
* model drift;
* hallucination;
* emergent behavior;
* automation bias;
* adversarial manipulation;
* prompt injection;
* model misuse;
* unintended generalization; and
* autonomous actions.

***

### 14. Risk Scenarios

Each material risk should be expressed as a meaningful risk scenario.

A risk scenario should identify:

* source or cause;
* event;
* affected asset or stakeholder;
* potential consequence; and
* existing safeguards.

***

### 15. Inherent Risk

Inherent risk should be assessed before considering the effectiveness of controls.

The assessment should consider:

* likelihood;
* impact;
* severity;
* exposure;
* affected stakeholders;
* duration; and
* reversibility.

***

### 16. Impact Assessment

Potential impact should be assessed across relevant dimensions.

Impact may include:

* physical harm;
* psychological harm;
* financial loss;
* privacy impact;
* security impact;
* discrimination;
* legal consequences;
* operational disruption;
* reputational damage; and
* societal impact.

***

### 17. Severity

Severity should be determined using defined organizational criteria.

A representative scale may include:

1. Negligible.
2. Minor.
3. Moderate.
4. Major.
5. Severe.

Organizations should define the criteria applicable to each level.

***

### 18. Likelihood

Likelihood should be assessed using defined criteria.

A representative scale may include:

1. Rare.
2. Unlikely.
3. Possible.
4. Likely.
5. Almost certain.

Likelihood assessments should consider relevant evidence and system characteristics.

***

### 19. Risk Rating

Risk rating should be determined using the organization's approved methodology.

A risk rating may be derived from:

* likelihood;
* impact;
* severity;
* exposure;
* control effectiveness; and
* other organization-defined factors.

***

### 20. Risk Matrix

Where a matrix is used, the organization should define how likelihood and impact combine.

The resulting categories may include:

* low;
* moderate;
* high; and
* critical.

The matrix should be applied consistently.

***

### 21. Control Assessment

Existing controls should be identified for each material risk.

Controls may address:

* prevention;
* detection;
* mitigation;
* response;
* recovery; and
* accountability.

***

### 22. Control Effectiveness

The effectiveness of existing controls should be assessed.

A control may be classified as:

* effective;
* partially effective;
* ineffective;
* not implemented; or
* not yet assessed.

***

### 23. Residual Risk

Residual risk should be assessed after considering implemented controls.

The assessment should identify:

* remaining likelihood;
* remaining impact;
* residual risk rating;
* uncertainty;
* control limitations; and
* required treatment.

***

### 24. Risk Treatment

Where residual risk exceeds organizational tolerance, treatment should be defined.

Treatment options may include:

1. Avoid.
2. Reduce.
3. Transfer or share.
4. Accept.
5. Suspend or discontinue.

***

### 25. Risk Avoidance

Risk may be avoided by changing or eliminating the activity that creates the risk.

Examples may include:

* not deploying the AI system;
* removing a high-risk use case;
* replacing the AI capability; or
* restricting a prohibited function.

***

### 26. Risk Reduction

Risk may be reduced by implementing additional safeguards.

Measures may include:

* technical controls;
* human oversight;
* access restrictions;
* testing;
* monitoring;
* data controls;
* security controls;
* privacy controls; and
* operational procedures.

***

### 27. Risk Transfer or Sharing

Where appropriate, some risks may be transferred or shared through:

* contractual arrangements;
* insurance;
* service agreements;
* third-party responsibilities; or
* other formal arrangements.

Transfer does not remove the organization's responsibility to manage risks that remain within its control.

***

### 28. Risk Acceptance

Residual risk may be accepted only by an authorized risk owner.

Risk acceptance should document:

* risk;
* rationale;
* residual rating;
* applicable controls;
* acceptance authority;
* acceptance date;
* review date; and
* conditions.

***

### 29. Risk Rejection

Where risk exceeds acceptable tolerance and cannot be adequately treated, the organization should reject, suspend, or discontinue the relevant activity.

***

### 30. Risk Owner

Each material risk should have an accountable risk owner.

The risk owner should:

* understand the risk;
* approve treatment;
* monitor residual risk;
* accept risk where authorized;
* escalate material changes; and
* ensure appropriate review.

***

### 31. Risk Treatment Plan

Material risk treatment should be documented in a treatment plan.

The plan should include:

* risk;
* treatment;
* action;
* owner;
* priority;
* target date;
* expected outcome;
* dependencies; and
* evidence.

***

### 32. Risk Acceptance Conditions

Risk acceptance may include conditions such as:

* additional monitoring;
* time limitation;
* additional controls;
* periodic review;
* restricted use;
* user training; and
* escalation requirements.

***

### 33. Risk Escalation

Risk should be escalated when:

* risk exceeds tolerance;
* controls fail;
* risk increases materially;
* treatment is delayed;
* a critical incident occurs;
* risk acceptance authority is exceeded; or
* new information changes the assessment.

***

### 34. Uncertainty

Risk assessments should identify material uncertainty.

Uncertainty may result from:

* limited data;
* incomplete testing;
* model opacity;
* changing environments;
* unknown behaviors;
* insufficient historical evidence; or
* emerging threats.

***

### 35. Assumptions

Material assumptions used in the risk assessment should be documented.

Assumptions should be reviewed when relevant circumstances change.

***

### 36. Dependencies

The assessment should identify material dependencies.

Dependencies may include:

* third-party models;
* cloud services;
* data providers;
* APIs;
* infrastructure;
* human operators;
* external datasets; and
* other AI systems.

***

### 37. Third-Party AI Risk

Third-party AI services should be assessed for relevant risks.

Assessment may consider:

* provider reliability;
* security;
* privacy;
* data handling;
* model changes;
* service availability;
* contractual obligations;
* transparency; and
* concentration risk.

***

### 38. Generative AI Risk

Generative AI risk assessments should consider:

* hallucination;
* harmful outputs;
* prompt injection;
* data leakage;
* copyright or intellectual property concerns;
* model misuse;
* output manipulation;
* unsafe automation; and
* inappropriate reliance.

***

### 39. Agentic AI Risk

AI agents should be assessed for risks associated with autonomous actions.

Assessment may consider:

* tool access;
* permissions;
* action scope;
* transaction authority;
* human approval;
* escalation;
* failure handling;
* action reversibility; and
* monitoring.

***

### 40. Human Oversight Risk

The assessment should determine whether human oversight is required.

Where required, it should assess:

* oversight capability;
* competence;
* authority;
* intervention time;
* workload;
* automation bias;
* override capability; and
* escalation.

***

### 41. Security Risk

AI security risks should be assessed where applicable.

These may include:

* unauthorized access;
* adversarial attacks;
* prompt injection;
* model manipulation;
* data poisoning;
* model extraction;
* data exfiltration;
* credential misuse; and
* unauthorized actions.

***

### 42. Privacy Risk

Where personal or sensitive data is involved, privacy risks should be assessed.

Assessment may consider:

* data minimization;
* purpose limitation;
* access;
* retention;
* disclosure;
* profiling;
* data subject impact; and
* privacy controls.

***

### 43. Fairness and Discrimination Risk

Where AI may affect individuals, the assessment should consider relevant fairness risks.

Factors may include:

* biased data;
* unequal performance;
* protected characteristics;
* disparate outcomes;
* accessibility;
* historical bias; and
* inappropriate proxy variables.

***

### 44. Safety Risk

Where AI may affect physical or operational safety, the assessment should consider:

* failure modes;
* unsafe outputs;
* system malfunction;
* human error;
* environmental conditions;
* emergency response;
* fail-safe mechanisms; and
* recovery.

***

### 45. Transparency Risk

The assessment should consider whether stakeholders may need information about:

* AI use;
* system purpose;
* limitations;
* decisions;
* outputs;
* human oversight; and
* relevant accountability.

***

### 46. Explainability Risk

Where decisions or outputs require explanation, the assessment should consider whether sufficient explanation can be provided.

Limitations should be documented where explainability is technically constrained.

***

### 47. Accountability Risk

The assessment should determine whether accountability remains clear.

Responsibilities should be identifiable for:

* system ownership;
* decisions;
* outputs;
* controls;
* incidents;
* monitoring; and
* remediation.

***

### 48. Operational Resilience Risk

The assessment should consider whether AI failure could disrupt critical operations.

Factors may include:

* availability;
* dependencies;
* fallback processes;
* recovery;
* business continuity;
* service providers; and
* single points of failure.

***

### 49. Reputational Risk

Potential reputational impacts should be considered where AI failure or misuse may affect:

* customers;
* employees;
* partners;
* regulators;
* public trust; or
* organizational reputation.

***

### 50. Legal and Regulatory Risk

The assessment should consider applicable legal and regulatory requirements.

The assessment may identify:

* applicable obligations;
* prohibited activities;
* reporting requirements;
* documentation requirements;
* transparency obligations;
* contractual requirements; and
* regulatory uncertainty.

***

### 51. Risk Assessment Evidence

The assessment should maintain sufficient evidence to support conclusions.

Evidence may include:

* assessment records;
* test results;
* data analysis;
* control evidence;
* expert review;
* stakeholder consultation;
* monitoring data; and
* external information.

***

### 52. Risk Assessment Approval

Material risk assessments should be reviewed and approved according to organizational requirements.

Approval should confirm that:

* relevant risks were considered;
* methodology was applied;
* treatment is appropriate;
* residual risk is understood; and
* required escalation has occurred.

***

### 53. Risk Assessment Record

The risk assessment record should contain, as appropriate:

* AI system identifier;
* assessment date;
* assessor;
* intended purpose;
* risk scenarios;
* inherent risk;
* controls;
* residual risk;
* treatment;
* risk owner;
* approval;
* review date; and
* evidence references.

***

### 54. Periodic Reassessment

Risk assessments should be reviewed periodically according to risk.

Higher-risk systems should generally receive more frequent reassessment.

The review should determine whether:

* risks remain valid;
* controls remain effective;
* assumptions remain valid;
* system behavior has changed;
* residual risk has changed; and
* new risks have emerged.

***

### 55. Event-Driven Reassessment

An immediate or expedited reassessment should occur following material events.

Triggers may include:

* serious incidents;
* significant model changes;
* major data changes;
* new deployment contexts;
* increased autonomy;
* significant control failures;
* new regulations; and
* major provider changes.

***

### 56. Risk Register

Material AI risks should be recorded in an appropriate risk register.

The register should support:

* ownership;
* treatment;
* monitoring;
* escalation;
* reporting; and
* reassessment.

***

### 57. Risk Reporting

Risk information should be reported to appropriate governance authorities.

Reporting may include:

* current risk profile;
* high and critical risks;
* risk trends;
* treatment status;
* accepted risks;
* overdue actions;
* emerging risks; and
* material changes.

***

### 58. Risk Metrics

Organizations may establish AI risk indicators.

Examples include:

* number of high-risk systems;
* critical risks;
* overdue treatments;
* control failures;
* incidents;
* accepted residual risks;
* risk trend; and
* reassessment completion.

***

### 59. Risk Communication

Material AI risks should be communicated to stakeholders who need the information to make informed decisions.

Communication should be proportionate to:

* risk;
* role;
* authority;
* impact; and
* confidentiality requirements.

***

### 60. Record Retention

Risk assessment records should be retained according to applicable organizational and legal requirements.

Records should remain available for:

* governance;
* audit;
* assurance;
* incident investigation;
* regulatory review; and
* organizational learning.

***

### 61. Exceptions

Exceptions to this procedure should be:

* documented;
* risk assessed;
* approved by the appropriate authority;
* time limited where appropriate; and
* periodically reviewed.

***

### 62. Responsibilities

**AI System Owner**

* initiate required assessments;
* provide accurate system information;
* ensure risk treatment is implemented;
* monitor changes; and
* support reassessment.

**Risk Owner**

* own material risks;
* approve treatment;
* accept residual risk where authorized;
* monitor risk; and
* escalate material changes.

**AI Governance Function**

* maintain the risk methodology;
* provide governance oversight;
* review material assessments;
* coordinate escalation; and
* support reporting.

**Specialist Functions**

* provide relevant expertise;
* identify domain-specific risks;
* review controls; and
* support risk treatment.

***

### 63. Risk Assessment Workflow

The standard workflow should be:

1. Identify assessment trigger.
2. Define scope.
3. Gather system information.
4. Identify stakeholders.
5. Identify risk scenarios.
6. Assess inherent risk.
7. Identify existing controls.
8. Assess control effectiveness.
9. Determine residual risk.
10. Define treatment.
11. Assign risk ownership.
12. Obtain required approval.
13. Record the assessment.
14. Monitor risk.
15. Reassess when required.

***

### 64. Continuous Improvement

The risk assessment process should be improved based on:

* incidents;
* assurance findings;
* audit results;
* operational experience;
* emerging risks;
* regulatory developments;
* stakeholder feedback; and
* changes in AI technology.

Improvements should be incorporated into the organization's AI risk methodology and related governance procedures.

***

### 65. Procedure Review

This procedure should be reviewed periodically and when material changes occur.

Review triggers may include:

* changes to AIGO requirements;
* changes to organizational risk methodology;
* new AI technologies;
* regulatory developments;
* significant incidents;
* assurance findings; and
* implementation experience.

Material changes should be versioned and approved according to applicable document governance requirements.

***

### 66. Procedure Status

**Document:** AIGO AI Risk Assessment Procedure

**Version:** 0.1

**Status:** Draft

**Working Name:** AIGO

**Full Name:** AI Governance Operating Framework

**Document Identifier:** `AIGO-PROC-003`

**Document Type:** Operational Procedure

This procedure establishes the operational process for assessing and managing risks associated with AI systems throughout their lifecycle under the AIGO framework.

***