Skip to main content

​
AIGO — AI Governance Operating Framework

​
AI Governance Procedure

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

​
1. Purpose

This procedure defines the operational process for establishing, operating, maintaining, and reviewing AI governance within an organization. The procedure translates AIGO governance requirements into repeatable operational activities and establishes how AI governance decisions, responsibilities, controls, records, and escalation are managed.

​
2. Scope

This procedure applies to AI systems and AI-related activities that fall within the organization’s defined AIGO governance scope. The procedure may apply to:
  • internally developed AI systems;
  • externally acquired AI systems;
  • third-party AI services;
  • generative AI systems;
  • AI-enabled business processes;
  • AI agents;
  • AI models;
  • AI components embedded in products or services; and
  • material changes to existing AI systems.

​
3. Objectives

The objectives of this procedure are to ensure that:
  • AI governance responsibilities are clearly assigned;
  • AI systems are identified and registered;
  • applicable governance requirements are determined;
  • risks are assessed;
  • controls are implemented;
  • required decisions are approved;
  • governance evidence is maintained;
  • issues are escalated;
  • AI systems are monitored; and
  • governance activities are periodically reviewed.

​
4. Governance Authority

The organization should establish an appropriate authority for AI governance. The authority may be:
  • an AI governance committee;
  • an existing risk committee;
  • an executive governance body;
  • a designated AI governance function; or
  • another authorized organizational body.
The authority should have sufficient mandate to make or approve AI governance decisions within its defined responsibilities.

​
5. Governance Roles

AI governance responsibilities should be assigned in accordance with the AIGO Governance Roles framework. Relevant responsibilities may include:
  • executive sponsorship;
  • AI governance;
  • AI system ownership;
  • business ownership;
  • technical ownership;
  • risk management;
  • security;
  • privacy;
  • compliance;
  • assurance;
  • control ownership; and
  • user responsibilities.

​
6. Governance Lifecycle

AI governance should operate throughout the AI system lifecycle. The governance process should generally include:
  1. Identification.
  2. Registration.
  3. Classification.
  4. Risk assessment.
  5. Control determination.
  6. Implementation.
  7. Validation.
  8. Approval.
  9. Deployment.
  10. Monitoring.
  11. Change management.
  12. Reassessment.
  13. Retirement.
  14. Review and improvement.

​
7. AI Governance Intake

AI-related initiatives should enter the governance process through an appropriate intake mechanism. The intake process should capture sufficient information to determine whether the initiative falls within governance scope. Information may include:
  • proposed system name;
  • business purpose;
  • owner;
  • users;
  • AI capabilities;
  • data;
  • provider;
  • intended deployment;
  • expected impact; and
  • proposed timeline.

​
8. AI System Registration

AI systems within scope should be registered in the organization’s AI inventory or equivalent governance record. The registration record should include, where applicable:
  • unique identifier;
  • system name;
  • business owner;
  • technical owner;
  • purpose;
  • provider;
  • lifecycle stage;
  • classification;
  • risk status;
  • control status;
  • approval status; and
  • monitoring status.

​
9. AI Inventory

The organization should maintain an inventory of material AI systems. The inventory should be sufficiently accurate to support:
  • risk management;
  • governance oversight;
  • reporting;
  • assurance;
  • incident response;
  • regulatory obligations; and
  • lifecycle management.

​
10. Initial Review

Each newly identified AI system should receive an initial governance review. The review should determine:
  • whether the system is within scope;
  • applicable AI System Profile;
  • initial classification;
  • initial risk;
  • required controls;
  • required assessments;
  • responsible owners; and
  • required approval path.

​
11. AI System Classification

AI systems should be classified according to organizational criteria. Classification may consider:
  • business criticality;
  • potential impact;
  • autonomy;
  • data sensitivity;
  • external exposure;
  • decision significance;
  • affected stakeholders;
  • regulatory requirements; and
  • security considerations.

​
12. Risk Assessment Trigger

A risk assessment should be initiated when required by:
  • system classification;
  • risk level;
  • applicable regulation;
  • organizational policy;
  • material system change;
  • incident;
  • reassessment trigger; or
  • governance authority decision.

​
13. Control Determination

Applicable controls should be determined based on:
  • AI system profile;
  • risk assessment;
  • classification;
  • applicable requirements;
  • intended use;
  • system architecture; and
  • organizational policies.
Controls should be assigned to responsible owners.

​
14. Governance Decision

Governance decisions should be made by an authorized decision-maker. Possible decisions include:
  1. Approve.
  2. Approve with conditions.
  3. Request remediation.
  4. Escalate.
  5. Suspend.
  6. Reject.
  7. Retire.
The decision should be recorded for material AI systems.

​
15. Approval Requirements

Approval requirements should be proportionate to risk. Higher-risk AI systems may require approval from:
  • senior management;
  • an AI governance committee;
  • risk management;
  • legal or compliance;
  • security;
  • privacy; or
  • another designated authority.

​
16. Conditional Approval

Conditional approval may be used when an AI system may proceed subject to defined conditions. Conditions should identify:
  • required action;
  • owner;
  • deadline;
  • risk;
  • verification method; and
  • consequences of non-compliance.

​
17. Governance Exceptions

Exceptions to AIGO governance requirements should be formally documented. An exception request should include:
  • requirement;
  • reason;
  • affected system;
  • risk;
  • compensating controls;
  • duration;
  • responsible owner; and
  • approval authority.

​
18. Risk Acceptance

Where residual risk remains after controls are implemented, the organization should determine whether the risk may be accepted. Risk acceptance should be performed by an authorized risk owner. The decision should document:
  • risk;
  • impact;
  • likelihood;
  • existing controls;
  • residual risk;
  • rationale;
  • acceptance period; and
  • review requirements.

​
19. Governance Escalation

Issues should be escalated when they exceed defined authority, risk tolerance, or operational thresholds. Escalation triggers may include:
  • critical risk;
  • material control failure;
  • significant incident;
  • unresolved compliance issue;
  • repeated findings;
  • unauthorized AI use;
  • significant stakeholder impact; and
  • inability to meet required governance conditions.

​
20. Governance Meetings

The responsible governance body should meet at an appropriate frequency. Meetings may address:
  • new AI systems;
  • risk;
  • approvals;
  • incidents;
  • control status;
  • monitoring;
  • assurance;
  • changes;
  • exceptions; and
  • improvement activities.

​
21. Governance Agenda

A governance meeting agenda may include:
  1. Previous actions.
  2. New AI systems.
  3. Risk changes.
  4. Material incidents.
  5. Control status.
  6. Assurance findings.
  7. Exceptions.
  8. Regulatory developments.
  9. Material changes.
  10. Continuous improvement.

​
22. Governance Records

Governance decisions and material discussions should be recorded. Records may include:
  • meeting agendas;
  • minutes;
  • decisions;
  • action items;
  • approvals;
  • escalations;
  • risk acceptances; and
  • exception decisions.

​
23. Action Management

Governance actions should be assigned to accountable owners. Each material action should identify:
  • action;
  • owner;
  • priority;
  • due date;
  • status;
  • evidence; and
  • closure criteria.

​
24. Governance Reporting

AI governance status should be reported to appropriate management and governance authorities. Reporting may include:
  • AI inventory;
  • risk profile;
  • control status;
  • approvals;
  • incidents;
  • exceptions;
  • assurance findings;
  • overdue actions; and
  • material changes.

​
25. Incident Escalation

AI incidents should be managed according to the organization’s incident management requirements. Material incidents should be escalated to appropriate functions based on:
  • severity;
  • impact;
  • affected stakeholders;
  • security;
  • privacy;
  • regulatory requirements; and
  • operational consequences.

​
26. Regulatory Escalation

Potential regulatory issues should be escalated to the appropriate legal, compliance, or governance function. The assessment should consider:
  • applicable requirements;
  • potential breach;
  • reporting obligations;
  • affected systems;
  • affected stakeholders; and
  • required remediation.

​
27. Security Escalation

Security-related AI events should be handled according to applicable security incident procedures. Examples include:
  • unauthorized access;
  • credential compromise;
  • data exfiltration;
  • prompt injection;
  • malicious model manipulation;
  • unauthorized tool use; and
  • security control failure.

​
28. Privacy Escalation

Privacy-related AI events should be escalated according to applicable privacy requirements. Examples include:
  • unauthorized processing;
  • unauthorized disclosure;
  • sensitive data exposure;
  • inappropriate retention;
  • privacy control failure; and
  • data subject impact.

​
29. Monitoring Oversight

The governance function should receive appropriate information from AI system monitoring. Monitoring information may include:
  • performance;
  • risk indicators;
  • control indicators;
  • incidents;
  • model drift;
  • security events;
  • privacy events; and
  • material threshold breaches.

​
30. Assurance Oversight

The governance authority should oversee relevant AI assurance activities. Oversight may include:
  • assurance planning;
  • findings;
  • remediation;
  • repeat findings;
  • control effectiveness;
  • audit results; and
  • independent assessments.

​
31. Change Governance

Material changes to AI systems should be governed through the organization’s change management process. Changes may include:
  • model changes;
  • data changes;
  • configuration;
  • architecture;
  • provider;
  • integrations;
  • users;
  • permissions;
  • autonomy; and
  • intended purpose.

​
32. Reassessment

The governance authority should require reassessment when material circumstances change. Triggers may include:
  • significant incidents;
  • material changes;
  • new risks;
  • new use cases;
  • new providers;
  • regulatory changes;
  • increased autonomy; and
  • significant performance changes.

​
33. Suspension

The organization should have authority to suspend an AI system where continued operation creates unacceptable risk. Suspension may be triggered by:
  • critical incidents;
  • severe control failure;
  • unacceptable outputs;
  • security events;
  • privacy events;
  • regulatory concerns; or
  • loss of required oversight.

​
34. Retirement Governance

AI system retirement should be governed to ensure appropriate closure. Retirement governance should consider:
  • business dependencies;
  • data;
  • contracts;
  • users;
  • integrations;
  • evidence;
  • security;
  • privacy; and
  • residual risks.

​
35. Documentation Requirements

Material AI governance activities should be documented. Documentation may include:
  • governance decisions;
  • risk assessments;
  • approvals;
  • controls;
  • exceptions;
  • incidents;
  • monitoring;
  • assurance;
  • changes; and
  • retirement.

​
36. Evidence Management

Governance evidence should be:
  • accurate;
  • traceable;
  • protected;
  • retrievable;
  • appropriately retained; and
  • linked to the relevant AI system or governance decision.

​
37. Governance Traceability

Governance activities should maintain traceability across the governance lifecycle. Traceability should connect: AI System → Risk → Control → Decision → Evidence → Owner → Outcome

​
38. Training and Awareness

Relevant personnel should receive AI governance training appropriate to their responsibilities. Training may cover:
  • AIGO requirements;
  • AI risks;
  • roles;
  • controls;
  • escalation;
  • responsible AI use;
  • incident management; and
  • governance procedures.

​
39. Policy Alignment

AI governance procedures should align with relevant organizational policies. Relevant policies may include:
  • information security;
  • privacy;
  • data governance;
  • risk management;
  • procurement;
  • change management;
  • incident management;
  • business continuity; and
  • records management.

​
40. Third-Party Governance

Third-party AI systems and services should remain subject to appropriate governance. Third-party governance may include:
  • due diligence;
  • contractual requirements;
  • risk assessment;
  • security;
  • privacy;
  • performance;
  • monitoring;
  • provider changes; and
  • termination.

​
41. Governance Metrics

Organizations may establish metrics for AI governance effectiveness. Metrics may include:
  • number of registered AI systems;
  • percentage assessed;
  • approval completion;
  • control implementation;
  • overdue actions;
  • incidents;
  • exceptions;
  • assurance findings; and
  • remediation performance.

​
42. Governance Effectiveness Review

The organization should periodically evaluate whether AI governance is operating effectively. The review should consider:
  • role clarity;
  • process effectiveness;
  • decision quality;
  • control effectiveness;
  • monitoring;
  • assurance;
  • stakeholder feedback; and
  • governance outcomes.

​
43. Continuous Improvement

Governance processes should be improved based on:
  • incidents;
  • assurance findings;
  • audit results;
  • monitoring;
  • regulatory developments;
  • stakeholder feedback;
  • emerging risks; and
  • lessons learned.
Improvements should be incorporated into relevant policies, procedures, controls, and guidance.

​
44. Procedure Exceptions

Any exception to this procedure should be:
  • documented;
  • risk assessed;
  • approved by the appropriate authority;
  • time limited where appropriate; and
  • reviewed before expiry.

​
45. Procedure Review

This procedure should be reviewed periodically and when material changes occur. Review triggers may include:
  • changes to the AIGO framework;
  • organizational governance changes;
  • regulatory developments;
  • significant incidents;
  • assurance findings;
  • changes in AI technology; and
  • implementation experience.

​
46. Procedure Status

Document: AIGO AI Governance Procedure Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-PROC-001 Document Type: Operational Procedure This procedure defines the operational governance process for AI systems and AI-related activities within the organization’s AIGO governance scope.