AIGO — AI Governance Operating Framework
AI Risk Assessment Procedure
Version: 0.1Status: 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:- Negligible.
- Minor.
- Moderate.
- Major.
- Severe.
18. Likelihood
Likelihood should be assessed using defined criteria. A representative scale may include:- Rare.
- Unlikely.
- Possible.
- Likely.
- Almost certain.
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.
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:- Avoid.
- Reduce.
- Transfer or share.
- Accept.
- 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.
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.
- own material risks;
- approve treatment;
- accept residual risk where authorized;
- monitor risk; and
- escalate material changes.
- maintain the risk methodology;
- provide governance oversight;
- review material assessments;
- coordinate escalation; and
- support reporting.
- provide relevant expertise;
- identify domain-specific risks;
- review controls; and
- support risk treatment.
63. Risk Assessment Workflow
The standard workflow should be:- Identify assessment trigger.
- Define scope.
- Gather system information.
- Identify stakeholders.
- Identify risk scenarios.
- Assess inherent risk.
- Identify existing controls.
- Assess control effectiveness.
- Determine residual risk.
- Define treatment.
- Assign risk ownership.
- Obtain required approval.
- Record the assessment.
- Monitor risk.
- 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.
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.
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.