AIGO — AI Governance Operating Framework
AI Risk Acceptance Procedure
Version: 0.1Status: Draft
Working Name: AIGO
Full Name: AI Governance Operating Framework
Document Identifier: AIGO-PROC-011
1. Purpose
This procedure defines the process for identifying, evaluating, authorizing, documenting, monitoring, and reviewing the acceptance of residual risk associated with AI systems. The procedure ensures that AI-related risks are accepted only by appropriately authorized parties and within established risk tolerance and governance requirements.2. Scope
This procedure applies to residual risks associated with AI systems within the organization’s AIGO governance scope. It may apply to:- AI models;
- AI applications;
- generative AI systems;
- AI agents;
- AI-enabled business processes;
- third-party AI services;
- AI data;
- AI infrastructure; and
- AI governance controls.
3. Objectives
The objectives of AI risk acceptance are to:- establish when risk acceptance is appropriate;
- ensure residual risks are explicitly understood;
- ensure acceptance authority is appropriate;
- prevent unauthorized risk acceptance;
- document acceptance decisions;
- establish conditions for acceptance;
- monitor accepted risks; and
- ensure acceptance is periodically reviewed.
4. Risk Acceptance Principles
Risk acceptance should be:- explicit;
- informed;
- authorized;
- documented;
- risk-based;
- proportionate;
- time-bound where appropriate;
- monitored; and
- subject to review.
5. Risk Treatment Hierarchy
Before accepting residual risk, available treatment options should be considered. Options may include:- Avoid the risk.
- Reduce the risk.
- Transfer or share the risk.
- Modify the system or process.
- Accept the residual risk.
6. Residual Risk
Residual risk is the remaining risk after applicable controls and risk treatments have been implemented. Residual risk should be evaluated against:- risk appetite;
- risk tolerance;
- applicable requirements;
- control effectiveness;
- business objectives; and
- potential impact.
7. Risk Acceptance Eligibility
A risk may be considered for acceptance when:- the risk has been assessed;
- reasonable treatments have been considered;
- applicable controls are implemented or planned;
- residual risk is understood;
- acceptance is within authorized tolerance; and
- the acceptance decision is documented.
8. Non-Acceptable Risk
Risk should not be accepted where acceptance would:- violate applicable law;
- violate mandatory regulatory requirements;
- knowingly bypass mandatory controls;
- exceed authorized risk tolerance;
- create unacceptable safety risk;
- create prohibited outcomes; or
- exceed the authority of the decision-maker.
9. Risk Acceptance Request
A risk acceptance request should identify:- AI system;
- risk identifier;
- risk description;
- cause;
- potential impact;
- likelihood;
- existing controls;
- residual risk;
- treatment options considered;
- proposed acceptance period;
- responsible owner; and
- requested approval authority.
10. Risk Description
The risk should be described clearly enough for the decision-maker to understand:- what may happen;
- why it may happen;
- who or what may be affected;
- potential consequences;
- existing safeguards; and
- remaining exposure.
11. Risk Assessment
The risk should be assessed according to the organization’s approved risk methodology. Assessment may consider:- likelihood;
- impact;
- severity;
- affected stakeholders;
- duration;
- reversibility;
- detectability;
- control effectiveness; and
- uncertainty.
12. Residual Risk Assessment
Residual risk should reflect the condition after existing and committed controls are considered. The assessment should identify:- inherent risk;
- controls;
- control effectiveness;
- residual risk;
- remaining uncertainty; and
- required monitoring.
13. Risk Treatment Review
Before acceptance, the responsible owner should consider whether additional treatment is reasonably practicable. Treatment options may include:- additional controls;
- system modification;
- restricted deployment;
- additional human oversight;
- reduced permissions;
- enhanced monitoring;
- additional testing;
- reduced scope; or
- delayed deployment.
14. Cost and Feasibility
Where relevant, treatment decisions may consider:- technical feasibility;
- operational feasibility;
- financial impact;
- time;
- resource availability;
- business impact; and
- effectiveness of proposed controls.
15. Acceptance Conditions
Risk acceptance may include conditions. Conditions may specify:- additional controls;
- monitoring requirements;
- review frequency;
- implementation deadlines;
- restricted use;
- user requirements;
- escalation thresholds; and
- expiry dates.
16. Time-Bound Acceptance
Risk acceptance should be time-bound where the risk is expected to change or where treatment is planned. The acceptance record should specify:- start date;
- expiry date;
- review date;
- conditions; and
- renewal requirements.
17. Permanent Acceptance
Permanent acceptance may be allowed only where consistent with organizational risk governance. Permanent acceptance should still be subject to:- monitoring;
- periodic review;
- changes in risk;
- changes in requirements; and
- reassessment when material conditions change.
18. Acceptance Authority
Risk acceptance must be approved by a person or body with sufficient authority. Authority should be based on:- risk level;
- AI system classification;
- business impact;
- regulatory significance;
- organizational policy; and
- delegated authority.
19. Separation of Responsibilities
Where appropriate, the person requesting acceptance should not be the sole authority approving the acceptance. Higher-risk acceptance should receive appropriate independent or governance review.20. Escalated Acceptance
Risk acceptance should be escalated when:- residual risk is high;
- risk exceeds normal tolerance;
- multiple stakeholders are affected;
- regulatory exposure exists;
- safety concerns exist;
- controls are incomplete;
- incidents have occurred; or
- the requested acceptance period is extended.
21. AI Governance Review
The AI governance function should review material risk acceptance requests where required. The review may consider:- consistency with AIGO;
- classification;
- risk;
- controls;
- monitoring;
- assurance;
- acceptance authority; and
- applicable requirements.
22. Specialist Review
Specialist review may be required from:- security;
- privacy;
- legal;
- compliance;
- safety;
- risk management;
- technical functions; or
- other relevant functions.
23. Risk Acceptance Decision
The decision should clearly state:- approved;
- approved with conditions;
- rejected;
- deferred; or
- escalated.
24. Acceptance Record
Approved risk acceptance should be recorded. The record should include:- acceptance identifier;
- AI system;
- risk identifier;
- risk description;
- residual risk;
- controls;
- conditions;
- authority;
- approval date;
- expiry date;
- review date; and
- status.
25. Acceptance Evidence
Evidence supporting acceptance may include:- risk assessment;
- control assessment;
- testing results;
- monitoring information;
- assurance findings;
- business justification;
- specialist reviews; and
- approval records.
26. Monitoring Accepted Risk
Accepted risks should be monitored according to their significance. Monitoring may include:- risk indicators;
- control effectiveness;
- incidents;
- changes;
- threshold breaches;
- assurance findings; and
- changes in operating conditions.
27. Risk Acceptance Review
Accepted risks should be reviewed periodically. Review should determine whether:- the risk remains unchanged;
- controls remain effective;
- risk tolerance remains appropriate;
- conditions remain satisfied;
- additional treatment is required; or
- acceptance should be withdrawn.
28. Change Trigger
Risk acceptance should be reviewed when material changes occur. Triggers may include:- AI model changes;
- new data;
- new users;
- increased autonomy;
- new use cases;
- changes in law;
- incidents;
- control failures;
- material performance changes; or
- changes in risk appetite.
29. Incident Trigger
A material incident related to an accepted risk should trigger reassessment. The organization should determine whether:- acceptance remains valid;
- additional treatment is required;
- risk level has increased;
- controls are insufficient; or
- the AI system should be restricted or suspended.
30. Control Failure
Where a control supporting an accepted risk fails, the risk acceptance should be reviewed. The review should consider:- duration of failure;
- exposure;
- compensating controls;
- risk increase;
- incident implications; and
- corrective actions.
31. Expiry
Risk acceptance should expire when:- the defined acceptance period ends;
- conditions are no longer satisfied;
- the AI system changes materially;
- risk exceeds tolerance;
- the risk is treated;
- the system is retired; or
- acceptance is withdrawn.
32. Renewal
Renewal should require a new or updated assessment. Renewal should not be treated as automatic. The decision-maker should confirm that:- risk remains understood;
- conditions remain appropriate;
- controls remain effective;
- requirements have not changed; and
- continued acceptance remains justified.
33. Withdrawal
Risk acceptance may be withdrawn when:- risk increases;
- conditions are violated;
- controls fail;
- new requirements apply;
- incidents occur;
- the risk becomes unacceptable; or
- the acceptance authority determines that continued acceptance is inappropriate.
34. Risk Acceptance Register
The organization should maintain a risk acceptance register for material accepted risks. The register may contain:- acceptance identifier;
- AI system;
- risk;
- residual risk;
- owner;
- approver;
- conditions;
- approval date;
- expiry date;
- review date;
- status; and
- related actions.
35. Risk Acceptance Reporting
The AI governance function should report material accepted risks to appropriate governance bodies. Reporting may include:- number of accepted risks;
- risk levels;
- expired acceptances;
- overdue reviews;
- conditional acceptances;
- repeated acceptances;
- high-risk acceptances; and
- emerging trends.
36. Risk Acceptance Metrics
Organizations may establish metrics such as:- accepted risks by severity;
- acceptance duration;
- overdue reviews;
- expired acceptances;
- conditional acceptances;
- withdrawn acceptances;
- repeat acceptance requests; and
- accepted risks associated with incidents.
37. Risk Acceptance and Change Management
Material changes to an AI system should trigger review of related risk acceptance decisions. Change management should identify affected risk acceptances where appropriate.38. Risk Acceptance and Incident Management
Incident records should identify whether an incident relates to an accepted risk. Where applicable, incident findings should trigger review or withdrawal of the relevant acceptance.39. Risk Acceptance and Monitoring
Monitoring should provide evidence about whether accepted risk remains within approved conditions. Threshold breaches should trigger reassessment or escalation where required.40. Risk Acceptance and Assurance
Assurance activities may review:- acceptance decisions;
- approval authority;
- supporting evidence;
- monitoring;
- conditions;
- expiry management; and
- compliance with this procedure.
41. Risk Acceptance Responsibilities
Risk Owner- identify residual risk;
- evaluate treatment options;
- request acceptance;
- monitor accepted risk; and
- initiate reassessment.
- provide system information;
- assess operational impact;
- implement required controls;
- monitor system behavior; and
- support risk reassessment.
- maintain risk methodology;
- advise on risk assessment;
- review material acceptance decisions; and
- monitor risk governance.
- oversee AI-specific risk acceptance;
- review material requests;
- monitor acceptance compliance;
- coordinate escalation; and
- maintain governance records.
- review the risk;
- assess supporting evidence;
- consider treatment options;
- approve, reject, condition, or escalate the request; and
- ensure the decision is within delegated authority.
42. Risk Acceptance Workflow
The standard workflow should be:- Identify residual risk.
- Assess risk.
- Identify existing controls.
- Evaluate treatment options.
- Determine whether acceptance is appropriate.
- Prepare risk acceptance request.
- Obtain specialist review where required.
- Confirm acceptance authority.
- Review supporting evidence.
- Approve, reject, condition, or escalate.
- Record decision.
- Implement acceptance conditions.
- Monitor accepted risk.
- Conduct periodic review.
- Renew, modify, withdraw, or close acceptance.
- Maintain evidence.
43. Continuous Improvement
The risk acceptance process should be improved based on:- incidents;
- assurance findings;
- audit findings;
- recurring acceptance requests;
- changes in risk appetite;
- regulatory developments;
- changes in AI technology; and
- operational experience.
44. Procedure Review
This procedure should be reviewed periodically and when material changes occur. Review triggers may include:- significant incidents;
- changes to AIGO requirements;
- regulatory developments;
- changes in risk methodology;
- assurance findings;
- changes in organizational risk appetite; and
- implementation experience.
45. Procedure Status
Document: AIGO AI Risk Acceptance Procedure Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier:AIGO-PROC-011
Document Type: Operational Procedure
This procedure establishes the operational process for formally accepting, monitoring, reviewing, and withdrawing residual AI-related risks within the AIGO governance framework.