AIGO — AI Governance Operating Framework
AI Governance Approval Procedure
Version: 0.1Status: Draft
Working Name: AIGO
Full Name: AI Governance Operating Framework
Document Identifier: AIGO-PROC-006
1. Purpose
This procedure defines the process for obtaining, recording, maintaining, and reviewing governance approval for AI systems and AI-related activities. The procedure establishes how AI governance decisions are made and ensures that AI systems do not progress to defined lifecycle stages without the approvals required by their governance classification, risk, and applicable requirements.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;
- material changes to existing AI systems;
- high-impact AI use cases;
- AI models;
- generative AI systems;
- AI agents;
- third-party AI services;
- AI-enabled business processes; and
- AI systems requiring renewed approval.
3. Objectives
The objectives of the approval process are to ensure that:- approval authority is clearly defined;
- approval requirements are proportionate to risk;
- required assessments are completed;
- required controls are implemented;
- residual risks are understood;
- approval decisions are documented;
- approval conditions are tracked;
- approval evidence is retained; and
- approval remains valid throughout the relevant lifecycle stage.
4. Approval Principles
AI governance approval should be:- risk-based;
- proportionate;
- evidence-based;
- authorized;
- documented;
- traceable;
- time-aware; and
- subject to review.
5. Approval Authority
The organization should define approval authorities for different AI governance classifications and decisions. Approval authorities may include:- business owner;
- AI system owner;
- risk owner;
- AI governance function;
- security;
- privacy;
- legal;
- compliance;
- executive management;
- AI governance committee; and
- other designated authorities.
6. Approval Triggers
Approval should be required when:- a new AI system reaches a defined lifecycle gate;
- a new AI use case is introduced;
- a material change occurs;
- risk increases materially;
- classification changes;
- a major provider changes;
- an exception is requested;
- a risk acceptance is required;
- a system returns from suspension; or
- periodic approval review is due.
7. Approval Gates
The organization should establish appropriate approval gates. Possible gates include:- Intake approval.
- Assessment approval.
- Development approval.
- Validation approval.
- Deployment approval.
- Production approval.
- Material change approval.
- Continued-operation approval.
- Retirement approval.
8. Approval Prerequisites
Before approval is requested, the responsible owner should confirm that required governance activities have been completed. Prerequisites may include:- AI system registration;
- classification;
- risk assessment;
- control assessment;
- security assessment;
- privacy assessment;
- legal or compliance review;
- testing;
- validation;
- monitoring setup; and
- required documentation.
9. Approval Package
The approval request should contain sufficient information for the decision-maker. The package may include:- AI system identifier;
- intended purpose;
- classification;
- risk assessment;
- control status;
- outstanding issues;
- residual risk;
- monitoring arrangements;
- assurance results;
- proposed conditions; and
- recommendation.
10. Approval Decision
The authorized decision-maker should select an appropriate decision. Possible decisions include:- Approve.
- Approve with conditions.
- Defer.
- Request remediation.
- Escalate.
- Reject.
- Suspend.
11. Approval Criteria
The decision-maker should consider:- intended purpose;
- classification;
- material risks;
- control effectiveness;
- residual risk;
- compliance;
- security;
- privacy;
- human oversight;
- monitoring;
- assurance; and
- operational readiness.
12. Approval Conditions
Approval may be granted subject to defined conditions. Conditions should identify:- required action;
- responsible owner;
- due date;
- evidence required;
- verification method; and
- consequence of non-completion.
13. Conditional Approval
Conditional approval should only be used where the remaining issues are understood and appropriately controlled. Conditions should not permit unacceptable risk to remain unmanaged.14. Approval Deferral
Approval may be deferred when insufficient information exists to make an informed decision. Deferral should identify:- missing information;
- required action;
- responsible owner;
- target date; and
- next decision point.
15. Approval Rejection
An AI system may be rejected where:- risk is unacceptable;
- required controls cannot be implemented;
- legal or regulatory requirements cannot be met;
- intended use is prohibited;
- required evidence is unavailable; or
- governance requirements cannot be satisfied.
16. Approval Escalation
Approval should be escalated where:- decision authority is exceeded;
- risk exceeds tolerance;
- stakeholders disagree;
- significant conditions remain unresolved;
- the system is highly consequential; or
- the decision has significant organizational impact.
17. Risk Acceptance
Where residual risk remains, approval should not imply automatic risk acceptance. Risk acceptance should be performed by the authorized risk owner. The approval record should reference the risk acceptance decision where applicable.18. Exception Approval
Exceptions to governance requirements should be separately documented and approved. The approval record should identify:- exception;
- reason;
- risk;
- compensating controls;
- duration;
- owner; and
- approval authority.
19. Approval Authority Matrix
The organization should maintain an approval authority matrix. The matrix should define approval responsibilities according to factors such as:- classification;
- risk;
- lifecycle stage;
- impact;
- data sensitivity;
- autonomy;
- regulatory significance; and
- materiality.
20. Segregation of Duties
Where appropriate, approval should be separated from implementation. A person responsible for implementing a control should not approve the effectiveness of that control where independence is required.21. Independent Review
Higher-risk AI systems may require independent review before approval. Independent review may include:- assurance;
- internal audit;
- security assessment;
- privacy assessment;
- technical validation;
- legal review; or
- external assessment.
22. Approval Evidence
Approval evidence should be retained. Evidence may include:- approval request;
- assessment records;
- decision;
- approval date;
- approver;
- conditions;
- risk acceptance;
- exception approval; and
- supporting evidence.
23. Approval Record
The approval record should contain:- AI system identifier;
- decision;
- decision date;
- decision-maker;
- approval scope;
- conditions;
- linked assessments;
- linked risks;
- linked exceptions;
- review date; and
- evidence references.
24. Approval Validity
Approval should remain valid only for the scope and circumstances for which it was granted. Approval may become invalid when:- intended purpose changes;
- classification changes materially;
- risk changes materially;
- significant controls fail;
- system architecture changes materially;
- provider changes materially; or
- approval conditions expire.
25. Approval Expiry
Where appropriate, approval should have an expiry or review date. The review period should be proportionate to:- classification;
- risk;
- system change rate;
- operational criticality; and
- regulatory requirements.
26. Approval Renewal
Approval should be renewed when required. Renewal should confirm:- system remains within approved scope;
- risks remain acceptable;
- controls remain effective;
- conditions have been satisfied;
- monitoring remains operational; and
- no material changes invalidate the original approval.
27. Material Change Approval
Material changes should be assessed to determine whether new approval is required. Material changes may include:- new intended purpose;
- new users;
- new geography;
- new data;
- model replacement;
- significant model update;
- increased autonomy;
- new tool access;
- new provider;
- new integration; or
- increased business criticality.
28. Emergency Approval
In exceptional circumstances, an AI system may require expedited approval. Emergency approval should:- be authorized;
- document the emergency rationale;
- define limitations;
- establish additional monitoring;
- identify the responsible owner; and
- require subsequent formal review.
29. Approval During Development
Approval requirements during development should be proportionate to the development stage. Development approval may be required before:- sensitive data is introduced;
- external users are involved;
- high-risk testing occurs;
- production integration begins; or
- deployment proceeds.
30. Validation Approval
Where required, validation should confirm that the AI system meets defined requirements. Validation may consider:- performance;
- accuracy;
- robustness;
- security;
- privacy;
- fairness;
- safety;
- human oversight;
- monitoring; and
- control effectiveness.
31. Deployment Approval
Production deployment should require approval where defined by governance requirements. Deployment approval should confirm that:- required assessments are complete;
- required controls are implemented;
- residual risks are understood;
- monitoring is operational;
- ownership is established; and
- required conditions are satisfied.
32. Production Approval
Where a separate production approval is required, it should confirm readiness for operational use. The decision should consider:- operational readiness;
- support;
- monitoring;
- incident response;
- rollback;
- business continuity;
- security;
- privacy; and
- governance evidence.
33. Post-Deployment Review
Following deployment, the AI system should be reviewed where required. The review may consider:- actual performance;
- incidents;
- user feedback;
- unexpected behavior;
- control performance;
- risk changes; and
- whether continued approval remains appropriate.
34. Suspension Approval
Where an AI system has been suspended, authorization should be required before returning it to operation. The return-to-operation decision should confirm:- suspension reason addressed;
- required remediation completed;
- residual risk reassessed;
- controls restored;
- monitoring operational; and
- required authority approval obtained.
35. Retirement Approval
Where required, retirement should receive formal approval. The retirement decision should consider:- dependencies;
- data;
- contracts;
- security;
- privacy;
- records;
- business continuity; and
- residual risks.
36. Approval Conditions Monitoring
The responsible owner should monitor all approval conditions. The organization should track:- condition;
- owner;
- due date;
- status;
- evidence;
- verification; and
- closure.
37. Overdue Conditions
Overdue approval conditions should be escalated according to their significance. Potential actions include:- remediation;
- additional monitoring;
- restriction;
- suspension;
- risk acceptance; or
- escalation.
38. Approval Revocation
Approval may be revoked where:- conditions are violated;
- risk becomes unacceptable;
- controls fail materially;
- significant incidents occur;
- intended use changes without approval; or
- approval was based on materially incorrect information.
39. Approval Communication
Approval decisions should be communicated to relevant stakeholders. Communication should identify:- decision;
- scope;
- conditions;
- restrictions;
- effective date; and
- review requirements.
40. Approval Reporting
The AI governance function should maintain appropriate approval reporting. Reporting may include:- approvals granted;
- conditional approvals;
- rejected requests;
- pending decisions;
- expired approvals;
- revoked approvals;
- overdue conditions; and
- approval trends.
41. Approval Metrics
Organizations may establish approval metrics. Examples include:- approval cycle time;
- approval completion rate;
- conditional approvals;
- overdue conditions;
- rejected systems;
- revoked approvals; and
- approval renewals.
42. Approval Traceability
Approval records should maintain traceability to relevant governance evidence. The organization should be able to demonstrate: AI System → Classification → Risk → Controls → Assessment → Approval → Conditions → Monitoring43. Responsibilities
AI System Owner- prepare approval requests;
- provide accurate information;
- address approval conditions;
- maintain evidence; and
- notify material changes.
- review the approval package;
- make an authorized decision;
- document the rationale;
- establish conditions; and
- monitor significant approval outcomes.
- maintain approval requirements;
- coordinate governance review;
- maintain approval records;
- monitor approval conditions; and
- report approval status.
- provide appropriate risk, security, privacy, legal, compliance, technical, or other specialist input.
44. Approval Workflow
The standard workflow should be:- Identify approval trigger.
- Confirm approval authority.
- Gather required evidence.
- Confirm registration.
- Confirm classification.
- Confirm risk assessment.
- Confirm control assessment.
- Confirm specialist assessments.
- Prepare approval package.
- Conduct governance review.
- Make decision.
- Record decision.
- Communicate decision.
- Track conditions.
- Monitor approval validity.
- Renew, modify, suspend, or revoke approval when required.
45. Continuous Improvement
The approval process should be improved based on:- governance experience;
- approval outcomes;
- incidents;
- assurance findings;
- audit results;
- stakeholder feedback;
- regulatory developments; and
- changes in AI technology.
46. Procedure Review
This procedure should be reviewed periodically and when material changes occur. Review triggers may include:- changes to AIGO requirements;
- governance authority changes;
- regulatory developments;
- significant incidents;
- assurance findings;
- changes in organizational risk tolerance; and
- implementation experience.
47. Procedure Status
Document: AIGO AI Governance Approval Procedure Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier:AIGO-PROC-006
Document Type: Operational Procedure
This procedure establishes the operational process for obtaining and maintaining governance approval for AI systems throughout their lifecycle under the AIGO framework.