AIGO-ORG-001
AIGO-RSK-001
AIGO-SEC-001
AIGO-DAT-001
AIGO-AUT-001

The final identifier convention will be defined separately and
should support long-term framework versioning and traceability.

### 14.4 Control Objective

Each control should have a clearly defined objective describing
the governance outcome the control is intended to achieve.

The objective should focus on the desired governance result rather
than unnecessarily prescribing a specific technical implementation.

### 14.5 Control Requirement

The control requirement defines the expected organizational
practice or condition.

Controls should be written clearly enough to allow organizations
to determine whether the control has been implemented.

Where appropriate, requirements should be technology-neutral.

### 14.6 Control Applicability

Controls may not apply equally to every AI system.

Applicability may depend on:

- AI system type;
- risk level;
- autonomy;
- intended purpose;
- data sensitivity;
- business criticality;
- deployment environment;
- organizational context;
- applicable regulations; and
- other relevant factors.

Organizations should document control applicability decisions
where appropriate.

### 14.7 Control Ownership

Each applicable control should have an identified control owner
or responsible organizational function.

The control owner is responsible for ensuring that the control is
appropriately implemented, maintained, reviewed, and supported by
evidence where required.

### 14.8 Control Implementation

Organizations may implement controls through:

- policies;
- procedures;
- technical mechanisms;
- organizational processes;
- contractual requirements;
- training;
- approvals;
- monitoring;
- documentation; or
- combinations of these mechanisms.

AIGO does not require a specific implementation method unless a
specific control explicitly requires one.

### 14.9 Control Evidence

Organizations should maintain appropriate evidence demonstrating
control implementation and operation.

Evidence may include:

- policies;
- procedures;
- approvals;
- assessments;
- risk records;
- system documentation;
- configuration records;
- test results;
- logs;
- monitoring reports;
- training records;
- contracts;
- review records;
- incident records; and
- other appropriate organizational records.

Evidence requirements should be proportionate to the control and
associated risk.

### 14.10 Control Effectiveness

Organizations should periodically determine whether applicable
controls are operating as intended.

Control effectiveness may consider:

- implementation status;
- operating effectiveness;
- evidence quality;
- identified exceptions;
- incidents;
- audit findings;
- monitoring results; and
- changes in risk.

### 14.11 Control Status

Organizations may maintain a status for each applicable control.

A conceptual status model may include:

- **Not Applicable**
- **Not Implemented**
- **Planned**
- **Partially Implemented**
- **Implemented**
- **Operating Effectively**
- **Needs Improvement**
- **Retired**

Organizations may adapt the status model according to their
governance requirements.

### 14.12 Control Exceptions

Organizations may permit documented exceptions where a control
cannot reasonably be implemented or where an alternative control
provides an equivalent or appropriate governance outcome.

Exceptions should be:

- documented;
- justified;
- risk assessed;
- approved by an authorized individual or function;
- time-bound where appropriate; and
- periodically reviewed.

Exceptions should not be used to bypass governance requirements
without appropriate authorization.

### 14.13 Compensating Controls

Where a prescribed control cannot be implemented, an organization
may use an alternative or compensating control where appropriate.

The organization should evaluate whether the alternative provides
a sufficiently appropriate governance outcome for the relevant
risk.

The rationale and approval should be documented.

### 14.14 Control Relationships

Controls may have relationships with:

- governance domains;
- risks;
- lifecycle stages;
- organizational roles;
- AI system profiles;
- policies;
- procedures;
- evidence;
- maturity levels; and
- external standards or requirements.

These relationships should enable traceability across the AIGO
framework.

### 14.15 Control Traceability

AIGO should support traceability between:

Governance Objective → Risk → Control → Implementation → Evidence → Assessment → Improvement

This traceability is intended to help organizations understand
why a control exists, what risk or objective it addresses, how it
is implemented, and how its effectiveness can be evaluated.

### 14.16 Control Testing

Where appropriate, organizations should test controls to determine
whether they have been implemented and operate as intended.

Testing methods may include:

- document review;
- interviews;
- observation;
- configuration review;
- technical testing;
- sampling;
- automated checks;
- evidence review; and
- independent assessment.

### 14.17 Control Automation

Where practical, organizations may automate control monitoring,
validation, evidence collection, or reporting.

Automation should not remove the need for appropriate human
oversight where human judgment is required.

### 14.18 Control Lifecycle

AIGO controls should themselves be governed throughout a lifecycle.

The control lifecycle may include:

1. identification;
2. definition;
3. approval;
4. implementation;
5. operation;
6. monitoring;
7. assessment;
8. review;
9. modification; and
10. retirement.

### 14.19 Control Framework Extensibility

Organizations may create additional controls to address:

- industry-specific requirements;
- jurisdiction-specific requirements;
- organizational policies;
- contractual obligations;
- technology-specific risks;
- business-specific risks; or
- emerging AI risks.

Organization-specific controls should maintain clear relationships
with the AIGO framework where practical.

---

## 15. Maturity Model

AIGO provides a maturity model to help organizations understand
the current state of their AI governance capabilities and establish
a structured path for improvement.

The maturity model is intended to measure governance capability,
consistency, effectiveness, and organizational adoption.

A maturity level should not be interpreted as a legal compliance
status or certification unless an independent assessment or
certification program explicitly establishes such a determination.

### 15.1 Purpose of the Maturity Model

The AIGO maturity model is intended to help organizations:

- understand their current AI governance capability;
- identify governance gaps;
- prioritize improvement activities;
- establish measurable objectives;
- communicate governance maturity to management;
- compare progress over time;
- support investment decisions; and
- establish a continuous improvement roadmap.

### 15.2 Maturity Principles

Maturity should be evaluated based on the organization's actual
governance capability rather than the existence of documentation
alone.

An organization should consider whether governance practices are:

- defined;
- implemented;
- consistently applied;
- measured;
- monitored;
- reviewed; and
- continuously improved.

### 15.3 AIGO Maturity Levels

AIGO defines five conceptual maturity levels:

1. **Level 1 — Initial**
2. **Level 2 — Defined**
3. **Level 3 — Managed**
4. **Level 4 — Measured**
5. **Level 5 — Optimized**

Organizations may use these levels to assess their overall AI
governance capability or individual governance domains.

### 15.4 Level 1 — Initial

At the Initial level, AI governance activities are generally
informal, inconsistent, or reactive.

Characteristics may include:

- limited formal governance;
- unclear responsibilities;
- limited AI inventory;
- inconsistent documentation;
- ad-hoc risk assessment;
- limited control definition;
- reactive incident management;
- inconsistent approval processes; and
- dependence on individual knowledge.

AI systems may be implemented without a consistent governance
process.

### 15.5 Level 2 — Defined

At the Defined level, the organization has established basic AI
governance structures and documented processes.

Characteristics may include:

- defined AI governance policies;
- identified roles;
- basic AI inventory;
- documented procedures;
- defined risk assessment processes;
- basic control requirements;
- documented approval processes;
- initial training;
- established incident procedures; and
- defined governance responsibilities.

Governance exists but may not yet be consistently applied across
the organization.

### 15.6 Level 3 — Managed

At the Managed level, AI governance processes are implemented
consistently across relevant areas of the organization.

Characteristics may include:

- maintained AI inventories;
- consistent lifecycle processes;
- established risk management;
- defined control ownership;
- documented evidence;
- standardized assessments;
- operational monitoring;
- change management;
- incident management;
- vendor governance; and
- regular management oversight.

Governance activities are integrated into normal organizational
operations.

### 15.7 Level 4 — Measured

At the Measured level, the organization uses metrics, monitoring,
assurance, and evidence to evaluate governance effectiveness.

Characteristics may include:

- governance performance metrics;
- control effectiveness measurement;
- risk trend analysis;
- continuous monitoring;
- formal assurance activities;
- governance dashboards;
- evidence-based management decisions;
- systematic issue remediation;
- maturity assessments; and
- measurable improvement objectives.

The organization can demonstrate not only that governance
processes exist, but also how effectively they operate.

### 15.8 Level 5 — Optimized

At the Optimized level, AI governance is continuously improved
using organizational data, lessons learned, emerging risks,
technology developments, and governance performance information.

Characteristics may include:

- continuous improvement;
- advanced governance automation;
- proactive risk management;
- predictive monitoring;
- integrated governance systems;
- automated evidence collection;
- advanced assurance capabilities;
- continuous control improvement;
- proactive emerging-risk management; and
- governance integration across the AI ecosystem.

Governance becomes an adaptive organizational capability rather
than a static set of procedures.

### 15.9 Maturity Progression

The maturity model should be treated as a progression of
organizational capability:

Level 1 → Level 2 → Level 3 → Level 4 → Level 5

Organizations should not necessarily attempt to achieve the
highest maturity level for every AI system or governance domain.

The appropriate maturity target should depend on:

- organizational context;
- AI usage;
- risk exposure;
- regulatory environment;
- business objectives;
- available resources; and
- complexity of the AI ecosystem.

### 15.10 Domain-Level Maturity

Maturity may be evaluated separately for each AIGO governance
domain.

For example, an organization may have:

- Governance: Level 3;
- AI Risk Management: Level 2;
- Security: Level 4;
- Data Governance: Level 3;
- Agent Governance: Level 1;
- Assurance: Level 2.

This allows organizations to identify specific areas requiring
improvement instead of relying only on a single organization-wide
maturity score.

### 15.11 System-Level Maturity

Where appropriate, organizations may also assess governance
maturity for an individual AI system.

System-level assessment may consider:

- lifecycle governance;
- risk management;
- controls;
- documentation;
- security;
- privacy;
- human oversight;
- monitoring;
- incident management;
- change management; and
- evidence.

System maturity should not be confused with the technical
performance or intelligence of the AI system.

### 15.12 Maturity Assessment

A maturity assessment should be based on defined assessment
criteria and available evidence.

Assessment activities may include:

- documentation review;
- interviews;
- control assessment;
- evidence review;
- process observation;
- technical verification;
- sampling;
- metrics analysis; and
- independent assessment.

Organizations should document the assessment methodology used.

### 15.13 Maturity Evidence

Maturity claims should be supported by appropriate evidence.

Evidence may include:

- approved policies;
- procedures;
- AI inventories;
- risk registers;
- control records;
- assessment reports;
- training records;
- monitoring results;
- audit results;
- incident records;
- management reviews;
- metrics; and
- improvement plans.

The amount and type of evidence should be proportionate to the
maturity claim and organizational context.

### 15.14 Maturity Gaps

Organizations should identify gaps between their current
maturity level and their desired target state.

A maturity gap assessment may identify:

- missing governance capabilities;
- incomplete processes;
- ineffective controls;
- unclear responsibilities;
- insufficient evidence;
- training gaps;
- technology limitations;
- process weaknesses; and
- assurance weaknesses.

### 15.15 Maturity Improvement Roadmap

Organizations may establish a roadmap for improving AI governance
maturity.

A roadmap may define:

- current maturity;
- target maturity;
- identified gaps;
- improvement initiatives;
- responsible owners;
- priorities;
- dependencies;
- target dates;
- required resources; and
- success measures.

### 15.16 Maturity Review

Maturity should be reviewed periodically and when significant
changes occur.

Triggers for reassessment may include:

- significant expansion of AI usage;
- introduction of autonomous systems;
- major regulatory changes;
- significant AI incidents;
- organizational restructuring;
- major technology changes;
- acquisition or merger;
- material changes in risk; and
- completion of major governance initiatives.

### 15.17 Maturity and Risk

Maturity should not be treated as a substitute for risk
management.

A high-maturity organization may still operate high-risk AI
systems.

Similarly, a lower-maturity organization may operate low-risk AI
systems with limited governance requirements.

Maturity describes the capability of the governance system, while
risk describes the potential impact and uncertainty associated
with AI activities.

### 15.18 Maturity and External Assessments

AIGO maturity assessments may be used alongside external
standards, regulatory assessments, audits, certifications, or
other assurance activities.

AIGO maturity levels should not automatically be represented as
equivalent to certification levels or compliance classifications
under another framework.

Organizations should maintain clear distinctions between:

- AIGO maturity;
- legal compliance;
- regulatory conformity;
- certification;
- audit results; and
- organizational risk acceptance.

### 15.19 Maturity Model Evolution

The AIGO maturity model may evolve as the framework develops and
as organizational AI governance practices mature.

Changes to the maturity model should be documented through the
AIGO versioning and change-management process.

---

## 16. AI System Profiles

AIGO recognizes that AI systems can differ significantly in their
purpose, architecture, capabilities, autonomy, data usage, risk,
and operational impact.

A single governance approach should therefore not be applied
identically to every AI system.

AI System Profiles provide a structured method for describing the
characteristics of an AI system and determining which governance
requirements, controls, assessments, and procedures may be
applicable.

### 16.1 Purpose of AI System Profiles

AI System Profiles are intended to help organizations:

- classify AI systems;
- identify applicable governance requirements;
- determine relevant risks;
- select appropriate controls;
- define lifecycle requirements;
- establish accountability;
- determine assurance needs;
- support consistent documentation; and
- enable proportional governance.

### 16.2 Profile-Based Governance

An AI system may be associated with one or more profiles.

For example, an organization may have a system that is both:

- a Generative AI system; and
- a RAG system.

Another system may be:

- an AI Agent;
- an Agentic Workflow;
- a Decision-Support System; and
- a system processing sensitive organizational data.

Profiles should therefore be composable where appropriate.

### 16.3 Core System Profile

Every AI system governed under AIGO should have a basic system
profile.

The core profile may include:

- system identifier;
- system name;
- system owner;
- business owner;
- intended purpose;
- system description;
- organizational context;
- users;
- affected stakeholders;
- AI capabilities;
- data types;
- model types;
- external dependencies;
- autonomy level;
- deployment environment;
- lifecycle status;
- risk classification; and
- governance status.

### 16.4 Generative AI Profile

The Generative AI Profile applies to systems that generate content
such as:

- text;
- images;
- audio;
- video;
- code; or
- other generated outputs.

Governance considerations may include:

- model provider;
- model version;
- prompts and instructions;
- generated content;
- output validation;
- content risks;
- intellectual property considerations;
- user disclosure;
- model limitations;
- monitoring; and
- provider changes.

### 16.5 Large Language Model Application Profile

The Large Language Model Application Profile applies to
applications that use large language models as a primary
capability.

Governance considerations may include:

- model selection;
- model provider;
- model version;
- prompts;
- context management;
- output evaluation;
- token or usage management;
- data handling;
- model limitations;
- monitoring; and
- model change management.

### 16.6 RAG Profile

The Retrieval-Augmented Generation Profile applies to systems that
retrieve information from knowledge sources before generating
responses or outputs.

Governance considerations may include:

- knowledge sources;
- source ownership;
- source authorization;
- data classification;
- ingestion;
- indexing;
- retrieval;
- access controls;
- provenance;
- source freshness;
- retrieval quality;
- knowledge-base changes; and
- output traceability.

### 16.7 Chatbot and Conversational AI Profile

The Chatbot and Conversational AI Profile applies to systems that
interact with users through conversational interfaces.

Governance considerations may include:

- user identification;
- intended audience;
- conversation handling;
- escalation;
- human handoff;
- inappropriate requests;
- sensitive information;
- conversation logging;
- user disclosure;
- response quality; and
- incident reporting.

### 16.8 AI Agent Profile

The AI Agent Profile applies to systems that can independently
perform defined tasks based on goals, instructions, tools, or
environmental information.

Governance considerations may include:

- agent purpose;
- authorized actions;
- tools;
- permissions;
- execution boundaries;
- decision authority;
- human oversight;
- monitoring;
- intervention;
- action logging;
- failure handling; and
- emergency controls.

### 16.9 Agentic Workflow Profile

The Agentic Workflow Profile applies to workflows in which one or
more AI agents or AI components perform coordinated tasks.

Governance considerations may include:

- workflow definition;
- agent responsibilities;
- task boundaries;
- agent-to-agent interactions;
- orchestration;
- state management;
- tool access;
- permissions;
- escalation;
- human checkpoints;
- workflow monitoring; and
- failure containment.

### 16.10 Decision-Support Profile

The Decision-Support Profile applies to systems that provide
information, recommendations, predictions, rankings, or analysis
intended to support human decision-making.

Governance considerations may include:

- decision context;
- human decision authority;
- recommendation limitations;
- output validation;
- explainability requirements;
- review mechanisms;
- potential impact;
- user training; and
- monitoring for inappropriate reliance.

### 16.11 Automated Decision Profile

The Automated Decision Profile applies to AI systems that make or
execute decisions with limited or no direct human intervention.

These systems may require stronger governance depending on their
purpose, impact, and applicable requirements.

Governance considerations may include:

- decision authority;
- decision criteria;
- human oversight;
- intervention;
- appeal or review mechanisms;
- testing;
- monitoring;
- auditability;
- accountability;
- incident handling; and
- regulatory requirements.

### 16.12 AI Automation Profile

The AI Automation Profile applies to systems that use AI to
initiate, execute, or coordinate business or technical actions.

Examples may include:

- automated document processing;
- automated workflow execution;
- automated communications;
- automated ticket handling;
- automated data processing; and
- AI-controlled operational tasks.

Governance considerations may include:

- authorized actions;
- execution limits;
- permissions;
- transaction controls;
- monitoring;
- rollback;
- human intervention; and
- failure handling.

### 16.13 AI API and External Service Profile

The AI API and External Service Profile applies where an
organization consumes AI capabilities through an external API,
platform, hosted model, or other service.

Governance considerations may include:

- provider;
- service description;
- data transmission;
- contractual requirements;
- security;
- privacy;
- service availability;
- model changes;
- provider dependencies;
- usage limitations; and
- exit strategy.

### 16.14 Embedded AI Profile

The Embedded AI Profile applies where AI functionality is embedded
within another product, application, service, device, or business
process.

Governance should consider both the AI functionality and the
larger system in which it operates.

### 16.15 High-Autonomy Profile

The High-Autonomy Profile applies to systems capable of performing
multiple actions with limited human intervention.

Governance considerations may include:

- autonomy boundaries;
- action permissions;
- tool access;
- decision authority;
- monitoring;
- intervention;
- escalation;
- transaction limits;
- containment;
- emergency shutdown; and
- continuous evaluation.

### 16.16 Sensitive Data Profile

The Sensitive Data Profile applies where an AI system processes
data subject to heightened organizational, contractual, privacy,
security, or regulatory requirements.

The organization should determine the applicable data
classification and corresponding governance requirements.

Considerations may include:

- data classification;
- access control;
- data minimization;
- retention;
- encryption;
- processing restrictions;
- data transfer;
- monitoring; and
- incident management.

### 16.17 Business-Critical AI Profile

The Business-Critical AI Profile applies to AI systems whose
failure, compromise, unavailability, or inappropriate behavior
could materially affect important organizational operations.

Governance considerations may include:

- availability;
- resilience;
- recovery;
- operational continuity;
- monitoring;
- incident response;
- fallback procedures;
- human intervention; and
- disaster recovery.

### 16.18 Safety-Impacting AI Profile

The Safety-Impacting AI Profile applies to AI systems where
incorrect behavior may create significant physical or operational
safety consequences.

Such systems may require additional controls, testing,
validation, human oversight, monitoring, and specialized
assurance.

Applicable sector-specific requirements should also be considered.

### 16.19 Third-Party AI Profile

The Third-Party AI Profile applies where the organization does not
fully control the development or operation of the underlying AI
technology.

This profile may apply to:

- external AI providers;
- hosted models;
- AI SaaS platforms;
- third-party agents;
- external APIs;
- embedded AI services; and
- externally supplied AI components.

### 16.20 Profile Combination

Multiple profiles may be assigned to a single AI system.

For example, an AI customer assistant may include the following
profiles:

- Generative AI;
- LLM Application;
- RAG;
- Chatbot; and
- Third-Party AI Service.

An autonomous business automation system may include:

- AI Agent;
- Agentic Workflow;
- AI Automation;
- High Autonomy; and
- Business-Critical AI.

Profile combinations should be used to determine which governance
requirements and controls are applicable.

### 16.21 Profile Attributes

AIGO may define common attributes that can be used across profiles.

Possible attributes include:

- purpose;
- autonomy;
- decision authority;
- data sensitivity;
- affected parties;
- business criticality;
- external dependency;
- human oversight;
- tool access;
- integration level;
- operational impact;
- safety impact;
- security impact; and
- regulatory sensitivity.

### 16.22 Profile-Based Control Selection

AI System Profiles should support automated or structured
determination of applicable controls.

The conceptual relationship is:

**AI System → System Profile → Risk Classification → Applicable
Domains → Applicable Controls → Required Evidence → Assessment**

The final AIGO control-selection methodology will be defined in
the dedicated controls and implementation documentation.

### 16.23 Profile Review

An AI System Profile should be reviewed when material changes
occur.

Review triggers may include:

- change of purpose;
- change of users;
- new data sources;
- new model;
- new tools;
- increased autonomy;
- new integrations;
- new external provider;
- change in business criticality;
- change in regulatory context; or
- significant change in risk.

### 16.24 Profile Extensibility

Organizations may define additional AI System Profiles where
existing profiles do not adequately describe a particular AI
system or use case.

Additional profiles should document:

- profile purpose;
- applicability criteria;
- relevant risks;
- governance requirements;
- applicable controls; and
- required evidence.

Organization-specific profiles should maintain traceability to the
AIGO framework where practical.

---

## 17. Evidence and Assurance

AIGO recognizes that effective AI governance requires organizations to demonstrate not only that governance requirements have been defined, but also that they have been implemented and are operating as intended.

Evidence and assurance provide the foundation for demonstrating governance activities, evaluating control effectiveness, identifying gaps, and supporting continuous improvement.

### 17.1 Purpose of Evidence and Assurance

Evidence and assurance activities are intended to help organizations:

- demonstrate implementation of governance requirements;
- demonstrate operation of applicable controls;
- support internal reviews;
- support management oversight;
- identify governance weaknesses;
- support risk-based decision-making;
- provide traceability;
- support audits and assessments;
- demonstrate accountability; and
- enable continuous improvement.

### 17.2 Evidence-Based Governance

AIGO promotes evidence-based governance.

Organizations should be able to demonstrate, where appropriate:

- what AI systems exist;
- who owns them;
- what they are intended to do;
- what risks have been identified;
- what controls apply;
- how controls are implemented;
- who approved relevant activities;
- what evidence exists;
- how systems are monitored;
- what incidents have occurred; and
- what improvements have been made.

### 17.3 Evidence Categories

Evidence may be categorized according to its purpose.

Possible evidence categories include:

- governance evidence;
- organizational evidence;
- risk evidence;
- control evidence;
- technical evidence;
- operational evidence;
- security evidence;
- privacy evidence;
- data governance evidence;
- lifecycle evidence;
- monitoring evidence;
- incident evidence;
- training evidence;
- supplier evidence;
- assessment evidence; and
- assurance evidence.

### 17.4 Governance Evidence

Governance evidence may include:

- approved AI policies;
- governance charters;
- committee records;
- organizational responsibilities;
- decision records;
- governance meeting records;
- management approvals;
- AI governance objectives; and
- governance reviews.

### 17.5 Risk Evidence

Risk-related evidence may include:

- AI risk assessments;
- risk registers;
- risk classifications;
- impact assessments;
- threat assessments;
- risk acceptance records;
- mitigation plans;
- residual risk assessments; and
- risk review records.

### 17.6 Control Evidence

Control evidence may demonstrate that an applicable AIGO control has been implemented and is operating.

Examples may include:

- procedures;
- configuration records;
- approval records;
- test results;
- review records;
- monitoring reports;
- access records;
- system documentation;
- technical validation;
- control assessments; and
- exception records.

### 17.7 Technical Evidence

Technical evidence may include:

- system architecture;
- model information;
- configuration;
- source code references;
- deployment information;
- dependency information;
- model versions;
- API configurations;
- access controls;
- security configurations;
- evaluation results;
- testing results; and
- system logs.

AIGO does not require organizations to expose confidential source code or proprietary technical information solely for governance purposes.

### 17.8 Operational Evidence

Operational evidence may demonstrate how an AI system operates in practice.

Examples may include:

- operational procedures;
- monitoring records;
- maintenance records;
- change records;
- incident records;
- service reports;
- performance reports;
- review records; and
- operational approvals.

### 17.9 Evidence Quality

Evidence should be appropriate for the governance requirement it is intended to support.

Evidence quality may consider:

- relevance;
- accuracy;
- completeness;
- authenticity;
- reliability;
- timeliness;
- traceability; and
- accessibility.

The level of evidence required should be proportionate to the risk and importance of the relevant AI activity.

### 17.10 Evidence Ownership

Organizations should define responsibility for maintaining important governance evidence.

Evidence ownership may belong to:

- AI system owners;
- business owners;
- control owners;
- risk owners;
- security teams;
- privacy teams;
- governance teams;
- platform teams; or
- other responsible organizational functions.

### 17.11 Evidence Retention

Organizations should establish appropriate retention requirements for governance evidence.

Retention may depend on:

- organizational policies;
- contractual requirements;
- legal requirements;
- regulatory requirements;
- risk;
- business requirements;
- evidence type; and
- lifecycle stage.

AIGO does not prescribe a universal retention period.

### 17.12 Evidence Protection

Governance evidence may contain sensitive information.

Organizations should apply appropriate protections to evidence, including where applicable:

- access controls;
- confidentiality requirements;
- integrity protection;
- encryption;
- retention controls;
- secure storage;
- access monitoring; and
- appropriate disposal.

### 17.13 Evidence Traceability

Evidence should be traceable to the governance requirement, control, assessment, or decision that it supports where practical.

A conceptual relationship is:

**Requirement → Control → Implementation → Evidence → Assessment**

This traceability helps organizations demonstrate how governance requirements are translated into operational practices.

### 17.14 Assurance

Assurance activities provide confidence that governance processes and controls are appropriately designed, implemented, and operating as intended.

Assurance may be performed by:

- management;
- control owners;
- governance teams;
- internal audit;
- security teams;
- risk functions;
- independent assessors;
- external auditors; or
- other appropriately qualified parties.

### 17.15 Assurance Levels

Organizations may use different levels of assurance depending on risk and organizational requirements.

A conceptual assurance model may include:

- self-assessment;
- management review;
- internal assessment;
- independent assessment; and
- external assurance.

The appropriate assurance level should be determined according to risk, importance, applicable requirements, and organizational context.

### 17.16 Self-Assessment

Organizations may conduct self-assessments to evaluate their implementation of AIGO requirements.

Self-assessments may be used for:

- initial implementation;
- periodic reviews;
- maturity assessment;
- gap analysis;
- preparation for independent assessment; and
- continuous improvement.

Self-assessment results should clearly distinguish between self-declared status and independently verified results.

### 17.17 Independent Assessment

Organizations may engage an independent assessor to evaluate specific aspects of their AI governance implementation.

Independent assessments may provide additional confidence where the organization requires greater objectivity.

The scope, methodology, qualifications, and independence of the assessor should be appropriately defined.

### 17.18 Audit

Organizations may include AI governance within existing internal or external audit programs.

AI governance audits may examine:

- policies;
- procedures;
- controls;
- risk management;
- system documentation;
- evidence;
- operational practices;
- governance responsibilities; and
- control effectiveness.

AIGO does not itself constitute an audit standard.

### 17.19 Assurance Findings

Assurance activities may identify:

- conforming practices;
- control weaknesses;
- evidence gaps;
- process gaps;
- documentation gaps;
- control failures;
- exceptions;
- risks; and
- opportunities for improvement.

Findings should be documented and assigned appropriate ownership.

### 17.20 Corrective Actions

Organizations should establish appropriate corrective actions for identified governance weaknesses.

Corrective actions may include:

- process changes;
- control improvements;
- additional training;
- technical changes;
- documentation updates;
- risk treatment;
- additional monitoring;
- changes to responsibilities; or
- other appropriate measures.

Corrective actions should have appropriate ownership and tracking.

### 17.21 Assurance Independence

Where independent assurance is required, the organization should consider whether the assessor has sufficient independence from the activities being assessed.

The degree of independence should be proportionate to the purpose, risk, and significance of the assessment.

### 17.22 Assurance Scope

Assurance may be performed at different levels.

Possible scopes include:

- individual AI system;
- AI project;
- AI workflow;
- governance domain;
- business unit;
- AI portfolio; or
- organization-wide AI governance.

### 17.23 Continuous Assurance

Organizations with mature AI governance capabilities may implement continuous or automated assurance activities.

Examples may include:

- automated control monitoring;
- automated evidence collection;
- configuration validation;
- policy checks;
- access monitoring;
- model monitoring;
- workflow monitoring;
- automated risk indicators; and
- governance dashboards.

Automated assurance should be appropriately validated and should not be assumed to replace human judgment in situations requiring professional or organizational decision-making.

### 17.24 Evidence and Assurance for AI Agents

AI agents and agentic workflows may require additional evidence because they can perform actions rather than simply generate information.

Evidence may include:

- authorized tools;
- permissions;
- executed actions;
- decisions;
- workflow states;
- human interventions;
- approvals;
- exceptions;
- failures;
- escalations;
- tool calls;
- transaction records; and
- execution logs.

The level of evidence should be proportionate to the autonomy, impact, and risk of the system.

### 17.25 Evidence and Assurance for RAG Systems

RAG systems may require evidence demonstrating the governance of their knowledge sources and retrieval processes.

Relevant evidence may include:

- source inventory;
- source ownership;
- source authorization;
- ingestion records;
- indexing information;
- retrieval configuration;
- access controls;
- source versions;
- update history;
- provenance information; and
- evaluation results.

### 17.26 Evidence and Assurance for Generative AI

Generative AI systems may require evidence relating to:

- model selection;
- model version;
- prompts;
- system instructions;
- evaluations;
- output testing;
- safety controls;
- usage policies;
- monitoring;
- incidents; and
- material model changes.

Organizations should determine the appropriate evidence based on the system's risk and intended use.

### 17.27 Evidence and Assurance for Third-Party AI

Where AI capabilities are provided by a third party, organizations should maintain appropriate evidence regarding the external service.

Evidence may include:

- supplier assessments;
- contracts;
- security assessments;
- privacy documentation;
- service documentation;
- provider assurances;
- service-level information;
- model information;
- change notifications; and
- risk assessments.

Organizations should avoid assuming that third-party assurance automatically demonstrates compliance with the organization's own governance requirements.

### 17.28 Assurance Limitations

AIGO assurance activities should clearly state their scope and limitations.

An assessment of selected controls should not automatically be interpreted as an assessment of the entire organization's AI governance capability.

Similarly, evidence demonstrating the implementation of a control does not necessarily demonstrate that all associated risks have been eliminated.

### 17.29 Evidence and Assurance Lifecycle

Evidence and assurance should be managed throughout the AI governance lifecycle.

The lifecycle may include:

1. evidence requirements;
2. evidence collection;
3. evidence validation;
4. evidence storage;
5. control assessment;
6. assurance activity;
7. finding identification;
8. corrective action;
9. management review; and
10. continuous improvement.

### 17.30 Evidence and Assurance Evolution

AIGO evidence and assurance practices should evolve as AI technologies, organizational practices, regulatory expectations, and assurance methodologies develop.

Future versions of AIGO may define standardized evidence categories, assessment methodologies, assurance profiles, and machine-readable evidence structures.

---

## 18. Implementation Guidance

AIGO is intended to be implemented as an operational governance framework rather than treated solely as a documentation or policy framework.

Organizations should translate AIGO principles, domains, controls, roles, and lifecycle requirements into practical organizational processes.

Implementation should be proportional to the organization's size, complexity, AI usage, risk exposure, regulatory environment, and governance maturity.

### 18.1 Purpose of Implementation Guidance

Implementation guidance is intended to help organizations:

- establish an AI governance program;
- define organizational responsibilities;
- identify and register AI systems;
- assess AI-related risks;
- determine applicable controls;
- establish procedures;
- create required documentation;
- collect governance evidence;
- monitor AI systems;
- perform assessments;
- manage incidents and exceptions; and
- continuously improve AI governance.

### 18.2 Implementation Principles

Organizations implementing AIGO should consider the following principles:

- start with organizational context;
- establish accountability;
- identify AI systems and use cases;
- apply risk-based governance;
- implement proportionate controls;
- document important decisions;
- maintain appropriate evidence;
- integrate governance into existing business processes;
- monitor effectiveness; and
- continuously improve the governance system.

### 18.3 Implementation Does Not Require a Single Technology

AIGO is technology-neutral.

Organizations may implement AIGO using:

- existing governance platforms;
- document management systems;
- GRC platforms;
- ticketing systems;
- internal applications;
- spreadsheets;
- databases;
- workflow platforms;
- specialized AI governance platforms; or
- other appropriate technologies.

AIGO does not require the use of BindAI, BindBrain, or any specific software framework or technology provider.

### 18.4 Implementation Scope

Organizations should determine the appropriate scope of implementation.

Implementation may begin with:

- a single AI system;
- a specific business unit;
- a specific AI use case;
- an AI project;
- a portfolio of AI systems; or
- organization-wide AI governance.

Organizations may expand the scope as governance capabilities mature.

### 18.5 Initial Governance Assessment

Organizations should establish an initial understanding of their current AI environment.

The initial assessment may identify:

- existing AI systems;
- AI projects;
- AI applications;
- third-party AI services;
- AI users;
- existing policies;
- existing controls;
- existing risk processes;
- existing security processes;
- existing privacy processes;
- existing documentation; and
- existing governance gaps.

### 18.6 AI System Inventory

Organizations should establish and maintain an inventory of relevant AI systems.

The inventory may include:

- system identifier;
- system name;
- owner;
- business owner;
- purpose;
- AI capabilities;
- system profile;
- risk classification;
- lifecycle status;
- data categories;
- model information;
- third-party dependencies;
- deployment environment; and
- governance status.

### 18.7 Governance Intake

Organizations should establish an appropriate process for identifying new AI initiatives.

An AI governance intake process may be triggered when an organization:

- proposes a new AI system;
- introduces a new AI capability;
- adopts a third-party AI service;
- introduces an AI agent;
- creates an agentic workflow;
- introduces a new model;
- materially changes an existing AI system; or
- expands an AI system into a new business purpose.

### 18.8 AI System Registration

Relevant AI systems should be formally registered according to the organization's governance requirements.

Registration may include:

- system identification;
- ownership;
- purpose;
- intended users;
- affected stakeholders;
- system profile;
- risk classification;
- applicable controls;
- required approvals; and
- lifecycle status.

### 18.9 Risk Assessment

Organizations should assess relevant risks before significant deployment or use of an AI system.

Risk assessment should consider the characteristics of the system, its intended purpose, the context in which it operates, and potential impacts.

Risk assessment may consider:

- organizational impact;
- business impact;
- security risk;
- privacy risk;
- data risk;
- operational risk;
- financial risk;
- legal and regulatory considerations;
- safety impact;
- reputational impact;
- human impact;
- autonomy; and
- third-party dependency.

### 18.10 Control Applicability

Organizations should determine which AIGO controls apply to each AI system or governance scope.

Control applicability should be based on:

- system profile;
- risk classification;
- lifecycle stage;
- organizational context;
- applicable requirements;
- business criticality;
- data sensitivity;
- autonomy; and
- other relevant characteristics.

### 18.11 Governance Approval

Organizations should define appropriate approval requirements before an AI system enters a relevant lifecycle stage.

Approval requirements may apply to:

- initial registration;
- risk acceptance;
- development;
- testing;
- deployment;
- production use;
- material changes;
- exceptions; and
- retirement.

Approval authority should be clearly assigned.

### 18.12 Implementation Procedures

AIGO implementation should be supported by documented procedures where appropriate.

Procedures may address:

- AI intake;
- AI system registration;
- risk assessment;
- control assessment;
- development;
- testing;
- deployment;
- monitoring;
- incident management;
- change management;
- third-party assessment;
- evidence management; and
- retirement.

### 18.13 Integration With Existing Governance

Organizations should integrate AIGO with existing governance processes where practical.

Relevant processes may include:

- enterprise risk management;
- information security;
- privacy;
- data governance;
- software development;
- change management;
- procurement;
- vendor management;
- business continuity;
- internal audit;
- compliance; and
- records management.

AIGO should complement existing governance rather than unnecessarily duplicate established organizational processes.

### 18.14 AI Lifecycle Integration

AIGO requirements should be integrated into the AI system lifecycle.

A conceptual lifecycle may include:

1. idea and intake;
2. initial assessment;
3. classification;
4. design;
5. development or acquisition;
6. testing and validation;
7. approval;
8. deployment;
9. operation;
10. monitoring;
11. change management; and
12. retirement.

### 18.15 Implementation Evidence

Organizations should maintain evidence demonstrating the implementation of applicable AIGO requirements.

Evidence may include:

- completed assessments;
- approvals;
- procedures;
- test results;
- configuration records;
- monitoring records;
- training records;
- risk decisions;
- incident records; and
- review results.

### 18.16 Human Oversight

Organizations should determine appropriate levels of human oversight based on the characteristics and risks of an AI system.

Human oversight may include:

- human review;
- approval checkpoints;
- escalation;
- intervention;
- override;
- exception handling; and
- post-action review.

The required level of human oversight should be proportionate to system autonomy and potential impact.

### 18.17 Implementation of AI Agents

Organizations implementing AI agents should establish additional governance requirements where appropriate.

These may include:

- authorized objectives;
- permitted tools;
- permission boundaries;
- action limits;
- human approval requirements;
- monitoring;
- logging;
- escalation;
- failure handling; and
- emergency intervention.

### 18.18 Implementation of Agentic Workflows

Agentic workflows should have clearly defined governance boundaries.

Organizations should identify:

- participating agents;
- responsibilities;
- workflow objectives;
- task boundaries;
- data flows;
- tool access;
- decision points;
- human checkpoints;
- failure conditions; and
- escalation mechanisms.

### 18.19 Implementation of RAG Systems

Organizations implementing RAG systems should govern both the AI application and its underlying knowledge sources.

Governance may include:

- source authorization;
- source ownership;
- data classification;
- ingestion;
- indexing;
- retrieval;
- access control;
- provenance;
- source updates;
- evaluation; and
- monitoring.

### 18.20 Implementation of Third-Party AI

Organizations using third-party AI services should evaluate the service according to its risk and intended use.

Evaluation may consider:

- provider;
- service capabilities;
- data processing;
- security;
- privacy;
- contractual requirements;
- service availability;
- model changes;
- provider dependencies; and
- exit considerations.

### 18.21 Monitoring

Organizations should establish appropriate monitoring for AI systems according to their risk and operational importance.

Monitoring may include:

- system performance;
- availability;
- output quality;
- security;
- privacy;
- usage;
- incidents;
- model behavior;
- workflow behavior; and
- control effectiveness.

### 18.22 Incident Management

Organizations should establish processes for identifying, reporting, assessing, responding to, and learning from AI-related incidents.

AI incidents may include:

- harmful outputs;
- unauthorized actions;
- data exposure;
- security events;
- privacy events;
- system failures;
- inappropriate decisions;
- model failures;
- agent failures; and
- significant control failures.

### 18.23 Change Management

Material changes to an AI system should be evaluated according to organizational change management requirements.

Changes may include:

- model changes;
- prompt changes;
- system architecture changes;
- data source changes;
- tool changes;
- permission changes;
- workflow changes;
- provider changes; and
- changes in intended purpose.

### 18.24 Exception Management

Organizations may allow controlled exceptions from specific governance requirements where justified.

Exceptions should be:

- documented;
- justified;
- risk assessed;
- approved by appropriate authority;
- time-bound where appropriate; and
- reviewed periodically.

### 18.25 Training and Awareness

Organizations should provide appropriate AI governance awareness, training, or guidance to relevant personnel.

Training requirements should reflect the individual's responsibilities and the risks associated with the AI systems they use or govern.

Training may cover:

- AI governance principles;
- organizational AI policies;
- acceptable use;
- security;
- privacy;
- risk;
- human oversight;
- incident reporting; and
- responsibilities.

### 18.26 Implementation Review

Organizations should periodically review the effectiveness of their AIGO implementation.

Reviews may consider:

- control effectiveness;
- governance performance;
- risk changes;
- incidents;
- audit findings;
- evidence quality;
- user feedback;
- regulatory changes; and
- technology changes.

### 18.27 Implementation Maturity

Organizations may implement AIGO progressively.

A maturity approach may begin with:

- awareness;
- basic governance;
- defined processes;
- managed implementation;
- measured governance; and
- continuous optimization.

Detailed maturity criteria will be defined separately within the AIGO maturity model.

### 18.28 Implementation Roadmap

Organizations should establish an implementation roadmap appropriate to their context.

A roadmap may define:

- implementation priorities;
- responsible owners;
- timelines;
- dependencies;
- required resources;
- expected outcomes;
- evidence requirements; and
- review points.

### 18.29 Implementation Scaling

AIGO should be capable of scaling from small organizations to large enterprises.

Smaller organizations may implement a simplified governance structure, while larger organizations may establish dedicated governance functions, committees, control owners, assessment programs, and specialized governance platforms.

The level of implementation should remain proportionate to risk and organizational context.

### 18.30 Continuous Improvement

AIGO implementation should be treated as an evolving management capability rather than a one-time project.

Organizations should use:

- assessment results;
- assurance findings;
- incidents;
- lessons learned;
- performance indicators;
- stakeholder feedback;
- technology changes; and
- changes in applicable requirements

to continuously improve their AI governance practices.

### 18.31 Implementation Guidance Evolution

AIGO implementation guidance will evolve as organizational practices, AI technologies, governance methodologies, and external requirements develop.

Future versions may provide detailed implementation playbooks, procedures, templates, assessment tools, role-specific guidance, and sector-specific implementation profiles.

---

## 19. Relationship to External Standards and Regulations

AIGO is designed to operate alongside existing standards, regulations, laws, contractual requirements, and organizational governance frameworks.

AIGO does not replace external standards or legal requirements.

Organizations should determine which external requirements apply to their specific activities, jurisdictions, industries, AI systems, and use cases.

### 19.1 Purpose of External Alignment

External alignment is intended to help organizations:

- identify relevant external requirements;
- reduce duplicated governance activities;
- establish traceability;
- support compliance activities;
- integrate AI governance with existing management systems;
- identify gaps between AIGO and external requirements; and
- support consistent governance across different organizational functions.

### 19.2 Relationship With Laws and Regulations

AIGO should be implemented with consideration of applicable laws and regulations.

Organizations remain responsible for determining which legal and regulatory requirements apply to their activities.

AIGO does not provide legal advice and does not determine whether an organization is legally compliant.

### 19.3 Relationship With International Standards

AIGO may be used alongside relevant international standards and management system standards.

Relevant standards may include standards addressing:

- AI management;
- information security;
- privacy;
- quality management;
- risk management;
- business continuity;
- data governance; and
- other relevant organizational governance areas.

Organizations should determine which standards are relevant to their context.

### 19.4 Relationship With ISO/IEC 42001

AIGO may be mapped to relevant concepts and requirements contained within ISO/IEC 42001.

Such mapping may help organizations that operate or intend to establish an AI management system.

AIGO should not represent itself as ISO/IEC 42001 certification, compliance, accreditation, or an alternative to the standard.

Any future AIGO mapping should identify the relationship between AIGO requirements and relevant ISO/IEC 42001 concepts without reproducing protected standard content.

### 19.5 Relationship With NIST AI RMF

AIGO may be mapped to relevant concepts within the NIST AI Risk Management Framework.

The mapping may help organizations understand relationships between AIGO governance activities and AI risk management activities.

AIGO may provide its own governance structure while maintaining interoperability with relevant risk management concepts.

### 19.6 Relationship With Other Frameworks

AIGO may be mapped to other recognized frameworks, standards, regulations, and guidance where useful.

Potential mappings may include:

- AI governance frameworks;
- cybersecurity frameworks;
- privacy frameworks;
- risk management frameworks;
- data governance frameworks;
- software lifecycle standards; and
- industry-specific requirements.

Mappings should be maintained independently from the core AIGO requirements where practical.

### 19.7 Regulatory Mapping

AIGO may provide mappings to applicable regulatory requirements where sufficient information is available.

Regulatory mappings should:

- identify the relevant jurisdiction;
- identify the applicable regulation or requirement;
- identify the relevant AIGO requirement;
- describe the relationship;
- identify limitations; and
- include an appropriate version or effective date.

### 19.8 Jurisdictional Differences

AI governance requirements may differ between jurisdictions.

AIGO therefore does not establish a single universal regulatory compliance model.

Organizations should evaluate applicable requirements based on factors including:

- geographic location;
- market;
- industry;
- system purpose;
- affected individuals;
- data processing;
- risk classification; and
- applicable legal obligations.

### 19.9 Sector-Specific Requirements

Organizations operating in regulated or specialized industries may have additional requirements.

Examples may include:

- financial services;
- healthcare;
- insurance;
- education;
- telecommunications;
- critical infrastructure;
- public services; and
- other regulated sectors.

AIGO may support sector-specific profiles or mappings without replacing sector-specific obligations.

### 19.10 Contractual Requirements

Organizations should consider contractual requirements that affect AI systems.

Such requirements may arise from:

- customers;
- suppliers;
- technology providers;
- partners;
- regulators; or
- other contractual relationships.

Contractual requirements should be evaluated alongside applicable organizational and legal requirements.

### 19.11 Internal Policies

AIGO should be integrated with relevant internal organizational policies.

Internal policies may include:

- information security policies;
- privacy policies;
- acceptable use policies;
- data governance policies;
- software development policies;
- procurement policies;
- risk policies;
- records management policies; and
- business continuity policies.

### 19.12 Requirement Hierarchy

Organizations should establish an appropriate hierarchy for managing governance requirements.

A conceptual hierarchy may include:

1. applicable laws and regulations;
2. contractual obligations;
3. organizational policies;
4. external standards and frameworks;
5. AIGO requirements;
6. organizational procedures; and
7. operational practices.

The hierarchy may be adapted according to organizational context.

### 19.13 Traceability

Organizations should maintain traceability between applicable external requirements and internal governance controls where practical.

A conceptual relationship may be:

**External Requirement → Organizational Requirement → AIGO Control → Procedure → Evidence**

This relationship can help organizations demonstrate how external requirements are translated into operational governance.

### 19.14 Avoiding Duplicate Controls

Where organizations already have effective controls addressing a requirement, AIGO implementation should seek to reuse or reference existing controls where practical.

Organizations should avoid unnecessary duplication of:

- policies;
- procedures;
- assessments;
- approvals;
- monitoring activities; and
- evidence.

### 19.15 External Framework Mappings

AIGO mappings should be maintained as separate framework artifacts where practical.

This allows the core AIGO framework to remain technology-neutral and independent from changes to external standards or regulations.

Mappings may be maintained under the AIGO `mappings` directory.

### 19.16 Mapping Status

Each external mapping should clearly identify its status.

Possible statuses include:

- Draft;
- Proposed;
- Reviewed;
- Published;
- Deprecated; and
- Superseded.

Mapping status should be maintained independently from the core AIGO framework status.

### 19.17 Mapping Methodology

AIGO mappings should use a consistent methodology.

A mapping may identify:

- external requirement identifier;
- external requirement title;
- AIGO domain;
- AIGO control;
- relationship type;
- implementation notes;
- evidence considerations; and
- mapping limitations.

### 19.18 Relationship Types

AIGO mappings may use relationship classifications such as:

- Directly related;
- Partially related;
- Indirectly related;
- Supporting;
- Complementary; and
- Not addressed.

The exact mapping terminology may evolve as the AIGO mapping methodology matures.

### 19.19 Mapping Limitations

A mapping between AIGO and an external standard or regulation should not automatically be interpreted as demonstrating compliance.

A mapping identifies relationships between governance concepts or requirements.

Organizations remain responsible for performing their own assessment of applicable requirements.

### 19.20 External Requirement Monitoring

Organizations should monitor relevant changes to external requirements that may affect their AI governance obligations.

Monitoring may include:

- regulatory changes;
- standards updates;
- contractual changes;
- industry guidance;
- supervisory guidance; and
- organizational policy changes.

### 19.21 Framework Independence

AIGO should remain independent from any single external standard, regulation, technology provider, or jurisdiction.

This independence allows AIGO to evolve while maintaining interoperability with external governance requirements.

### 19.22 No Certification Claim

Adoption of AIGO does not by itself provide certification, accreditation, legal compliance, or regulatory approval.

Organizations should not represent AIGO adoption as equivalent to certification against another standard unless an appropriately authorized certification or assessment process has actually been completed.

### 19.23 External Assurance

Organizations may use external assurance providers to evaluate their implementation of AIGO and its relationship with applicable external requirements.

Any such assessment should clearly define:

- scope;
- criteria;
- methodology;
- assessor qualifications;
- limitations; and
- reporting requirements.

### 19.24 Future External Alignment

AIGO may expand its external mappings as new standards, regulations, frameworks, and industry practices develop.

Future versions may include structured mappings, machine-readable relationships, jurisdiction-specific profiles, and sector-specific mappings.

### 19.25 External Standards and Regulations Disclaimer

References to external standards, frameworks, regulations, or legal requirements within AIGO are provided for governance interoperability and informational purposes.

Organizations should consult the authoritative source and obtain appropriate professional advice when determining their specific obligations.

---

## 20. Technology Independence

AIGO is designed to remain independent from specific technologies, software frameworks, model providers, infrastructure platforms, programming languages, and implementation methodologies.

The purpose of technology independence is to ensure that AIGO can govern AI systems regardless of how those systems are technically implemented.

### 20.1 Technology-Neutral Design

AIGO requirements should describe governance outcomes rather than prescribe a specific technical implementation.

Organizations may implement AIGO using different:

- programming languages;
- AI frameworks;
- machine learning frameworks;
- model providers;
- cloud platforms;
- infrastructure platforms;
- databases;
- orchestration systems;
- application architectures; and
- development methodologies.

### 20.2 Framework Independence

AIGO does not require the use of a specific AI development framework.

AI systems governed by AIGO may be developed using:

- custom software;
- Python frameworks;
- agent frameworks;
- workflow frameworks;
- enterprise platforms;
- low-code platforms;
- no-code platforms;
- cloud-native services; or
- other appropriate technologies.

### 20.3 Model Provider Independence

AIGO does not require the use of a particular AI model provider.

Organizations may use:

- proprietary models;
- open models;
- internally developed models;
- hosted models;
- third-party APIs;
- locally deployed models; or
- combinations of different model technologies.

Governance requirements should remain applicable regardless of the model provider.

### 20.4 Infrastructure Independence

AIGO may be implemented across different infrastructure environments.

These may include:

- public cloud;
- private cloud;
- hybrid cloud;
- on-premises infrastructure;
- edge environments;
- local environments; and
- other deployment architectures.

### 20.5 Application Architecture Independence

AIGO should apply to different AI application architectures.

These may include:

- traditional machine learning systems;
- generative AI applications;
- RAG systems;
- chatbots;
- AI assistants;
- AI agents;
- multi-agent systems;
- agentic workflows;
- AI automation;
- decision-support systems; and
- AI-enabled business applications.

### 20.6 Governance Outcomes Over Implementation Details

AIGO controls should focus primarily on the governance outcome that an organization is expected to achieve.

For example, a governance requirement may require appropriate access control without prescribing a specific identity provider, authentication technology, or software product.

### 20.7 Technology-Specific Guidance

Technology-specific guidance may be provided where useful, but such guidance should remain separate from the core AIGO requirements where practical.

Technology-specific guidance may address:

- implementation examples;
- integration patterns;
- technical controls;
- monitoring approaches;
- deployment considerations; and
- tooling options.

Such guidance should not make the core framework dependent on a specific technology.

### 20.8 Vendor Neutrality

AIGO should not favor a specific technology vendor, model provider, cloud provider, consulting organization, or software platform.

Vendor-specific implementation guidance may be provided as examples where appropriate, provided that equivalent alternatives remain possible.

### 20.9 Open Implementation

Organizations should be able to implement AIGO using their existing technology environment.

AIGO should therefore avoid requirements that unnecessarily require:

- a particular vendor;
- proprietary software;
- a specific programming language;
- a particular AI model;
- a specific cloud provider; or
- a particular development framework.

### 20.10 Technology Change

AI technologies can change rapidly.

AIGO should therefore be designed so that changes in technology do not require fundamental changes to the governance model.

Organizations should be able to replace or upgrade:

- models;
- frameworks;
- infrastructure;
- APIs;
- databases;
- tools;
- agents; and
- application components

while maintaining appropriate governance requirements.

### 20.11 Technology Lifecycle

Technology changes should be considered within the AI governance lifecycle.

Organizations should evaluate material technology changes for potential effects on:

- risk;
- security;
- privacy;
- performance;
- reliability;
- explainability;
- governance controls;
- data processing; and
- operational behavior.

### 20.12 Technology Abstraction

AIGO should use technology-independent terminology wherever practical.

For example, the framework may refer to:

- AI system;
- model;
- data source;
- tool;
- workflow;
- agent;
- control;
- evidence; and
- governance activity

rather than requiring a particular implementation technology.

### 20.13 Interoperability

AIGO should support interoperability between different AI technologies and governance systems.

Organizations may integrate AIGO with:

- GRC platforms;
- ticketing systems;
- document management systems;
- identity systems;
- security platforms;
- monitoring systems;
- AI platforms;
- data platforms; and
- other enterprise systems.

### 20.14 Technology-Specific Profiles

Where a particular technology introduces unique governance considerations, AIGO may define technology-specific profiles.

Examples may include:

- Generative AI Profile;
- RAG Profile;
- AI Agent Profile;
- Agentic Workflow Profile;
- Machine Learning Profile; and
- Third-Party AI Profile.

Technology-specific profiles should extend the framework without making the core framework dependent on the technology.

### 20.15 Technology Risk

Technology independence does not eliminate technology-specific risk.

Organizations should assess technology-specific risks where appropriate.

Such risks may include:

- vendor dependency;
- model dependency;
- infrastructure dependency;
- technology obsolescence;
- interoperability limitations;
- availability risks;
- security vulnerabilities; and
- migration difficulties.

### 20.16 Open Standards and Interfaces

Organizations should consider the use of open standards and interoperable interfaces where practical.

This may help reduce unnecessary dependency on a single technology provider and support long-term governance and portability.

### 20.17 Technology Documentation

Organizations should maintain sufficient documentation to understand the technology components relevant to the governance of an AI system.

Documentation may include:

- architecture;
- models;
- dependencies;
- providers;
- interfaces;
- data sources;
- tools;
- deployment environments; and
- significant configuration.

### 20.18 Technology Substitution

AIGO should support the substitution of individual technology components without requiring the organization to redesign its entire governance structure.

For example, an organization may replace an AI model provider while retaining the same:

- ownership;
- risk process;
- control structure;
- evidence requirements;
- approval process; and
- monitoring approach.

The organization should reassess relevant risks when the substitution may materially change system behavior or risk.

### 20.19 Technology Independence and BindAI

BindAI may provide one implementation approach for building AI systems governed by AIGO.

However, AIGO is not dependent on BindAI.

Organizations may use BindAI, other AI frameworks, custom applications, enterprise platforms, or other technologies while applying the AIGO governance framework.

This separation allows AIGO to function as an independent governance framework while enabling BindAI and other technologies to serve as implementation tools.

### 20.20 Technology Independence and Enterprise Adoption

Technology independence is intended to support enterprise adoption by allowing organizations to introduce AIGO without requiring replacement of existing AI technologies.

Organizations should be able to apply AIGO to their existing AI environment and progressively improve governance over time.

### 20.21 Future Technology Evolution

AIGO should be reviewed periodically to ensure that its terminology and guidance remain relevant to emerging AI technologies.

Future versions may introduce additional profiles or guidance for new technologies while preserving the technology-independent structure of the core framework.

### 20.22 Technology Independence Principle

AIGO should remain governed by the following principle:

**Govern the AI capability and its organizational impact, not the vendor or implementation technology.**

---

## 21. Open Framework Philosophy

AIGO is intended to be an open, transparent, technology-neutral, and continuously evolving AI governance framework.

The framework should encourage organizations, practitioners, researchers, developers, governance professionals, and other stakeholders to contribute knowledge, identify improvements, and develop practical implementation approaches.

### 21.1 Open Framework Objective

The objective of the open framework philosophy is to:

- make the framework accessible;
- encourage transparency;
- support community participation;
- enable independent review;
- encourage practical implementation;
- support interoperability;
- facilitate continuous improvement; and
- promote responsible AI governance practices.

### 21.2 Public Framework

Where the framework is published publicly, the core AIGO framework should be accessible in a form that allows organizations and individuals to review and understand its governance model.

Public availability may include:

- framework documentation;
- principles;
- governance domains;
- controls;
- implementation guidance;
- templates;
- examples;
- mappings; and
- supporting documentation.

### 21.3 Open Source and Open Content

AIGO may use an open-source or open-content model for selected framework materials.

The licensing model should be clearly defined and should specify how the framework may be:

- used;
- copied;
- modified;
- distributed;
- incorporated into internal processes; and
- referenced by organizations.

The AIGO project should maintain clear separation between framework content and any proprietary commercial software or services built around it.

### 21.4 Community Participation

AIGO may accept contributions from the community.

Contributions may include:

- proposed framework changes;
- implementation examples;
- templates;
- terminology improvements;
- technical guidance;
- industry perspectives;
- research;
- mappings; and
- identified issues.

### 21.5 Contribution Requirements

Contributions should follow documented contribution procedures.

Contributors may be required to:

- describe the proposed change;
- provide justification;
- identify affected framework components;
- provide supporting evidence where appropriate;
- identify potential risks; and
- comply with the project's contribution and licensing requirements.

### 21.6 Review of Contributions

Contributions should be reviewed before becoming part of an official AIGO release.

Review may consider:

- consistency with AIGO principles;
- practical usefulness;
- clarity;
- governance implications;
- compatibility with existing requirements;
- duplication;
- external dependencies; and
- potential unintended consequences.

### 21.7 Maintainer Responsibilities

AIGO maintainers should be responsible for maintaining the integrity and consistency of the framework.

Maintainer responsibilities may include:

- reviewing contributions;
- managing releases;
- maintaining documentation;
- managing issues;
- coordinating framework changes;
- maintaining version history; and
- communicating significant changes.

### 21.8 Governance of the Open Project

The open AIGO project should have defined governance for making changes to the framework.

Governance may define:

- maintainers;
- reviewers;
- decision-making authority;
- contribution procedures;
- release procedures;
- dispute resolution;
- security reporting; and
- conflict-of-interest management.

### 21.9 Transparency

Significant framework changes should be documented transparently.

Where practical, changes should identify:

- what changed;
- why it changed;
- affected sections;
- version impact;
- implementation considerations; and
- migration considerations.

### 21.10 Version Control

The AIGO framework should be maintained using appropriate version control practices.

Version control should support:

- historical traceability;
- change review;
- contributor attribution;
- release management;
- rollback where appropriate; and
- comparison between framework versions.

### 21.11 Change Proposals

Significant changes may be introduced through formal change proposals.

A change proposal should describe:

- proposed change;
- rationale;
- expected benefit;
- affected users;
- affected controls;
- implementation impact;
- compatibility considerations; and
- potential risks.

### 21.12 Community Feedback

AIGO should provide appropriate mechanisms for receiving feedback.

Feedback may identify:

- unclear requirements;
- implementation difficulties;
- missing governance areas;
- emerging risks;
- terminology problems;
- documentation issues; and
- opportunities for improvement.

### 21.13 Independent Review

AIGO may benefit from independent review by qualified practitioners, researchers, governance professionals, auditors, legal professionals, security specialists, and other relevant experts.

Independent review can help identify weaknesses and improve the credibility and practical usefulness of the framework.

### 21.14 Industry Participation

AIGO may encourage participation from organizations across different industries and sectors.

Industry participation may help identify:

- sector-specific challenges;
- emerging governance practices;
- implementation patterns;
- common risks; and
- opportunities for sector-specific profiles.

### 21.15 Academic and Research Participation

Academic and research communities may contribute research and evidence relevant to AI governance.

Research contributions may address:

- AI risk;
- governance methodologies;
- assurance;
- evaluation;
- human oversight;
- AI safety;
- security;
- privacy;
- agentic systems; and
- emerging AI technologies.

### 21.16 Commercial Use

Organizations may use AIGO as part of their internal AI governance activities and, subject to the applicable license, may incorporate AIGO into commercial governance services.

Commercial implementation may include:

- consulting;
- assessments;
- implementation services;
- training;
- governance platforms;
- managed services; and
- other professional services.

The applicable AIGO license should define permitted commercial use.

### 21.17 Commercial Platforms

AIGO may be implemented through commercial software platforms.

Such platforms may provide functionality including:

- AI system inventories;
- assessments;
- risk management;
- control management;
- evidence management;
- workflows;
- dashboards;
- training;
- reporting;
- governance documentation; and
- AI governance assistants.

The availability of commercial platforms should not make the core framework dependent on a specific platform.

### 21.18 Separation of Framework and Products

AIGO framework content should remain conceptually separate from products and services built around it.

A commercial product may provide additional functionality while the framework defines the underlying governance concepts and requirements.

This separation helps preserve framework neutrality and allows organizations to implement AIGO using different tools.

### 21.19 Community Implementations

Organizations and individuals may create their own implementations of AIGO.

Implementations may include:

- internal governance programs;
- software platforms;
- templates;
- assessment tools;
- training programs;
- consulting methodologies; and
- integration solutions.

Implementations should clearly distinguish between official AIGO framework content and organization-specific extensions.

### 21.20 Use of the AIGO Name

The use of the AIGO name, logo, trademarks, certification claims, or other project identifiers should be governed by appropriate policies.

Organizations should not imply endorsement, certification, approval, or official affiliation unless such a relationship has been formally established.

### 21.21 Certification and Conformity

AIGO may define future conformity assessment concepts.

However, adoption of the framework should not automatically be described as certification.

Any future AIGO certification, assessment, or conformity program should have clearly defined:

- criteria;
- assessment methodology;
- assessor requirements;
- evidence requirements;
- decision rules;
- reporting requirements; and
- governance arrangements.

### 21.22 Responsible Community Conduct

Participation in the AIGO project should support respectful, professional, and constructive collaboration.

Community governance may include appropriate policies for:

- code of conduct;
- responsible disclosure;
- conflict resolution;
- harassment prevention;
- contributor safety; and
- professional behavior.

### 21.23 Security and Responsible Disclosure

Where the AIGO project includes software, schemas, tools, or online services, appropriate mechanisms should be established for reporting security vulnerabilities.

Security reports should be handled according to documented responsible disclosure procedures.

### 21.24 Intellectual Property

AIGO project materials should have clearly defined intellectual property and licensing arrangements.

Contributors and users should be able to understand:

- ownership;
- licensing;
- contribution rights;
- trademark rights;
- permitted reuse; and
- attribution requirements.

### 21.25 Open Framework Evolution

The AIGO framework should evolve based on practical experience, community feedback, research, technology changes, and emerging governance requirements.

Changes should preserve the core principles of:

- transparency;
- accountability;
- technology independence;
- practical implementation;
- risk-based governance; and
- continuous improvement.

### 21.26 Open Framework Philosophy

AIGO should remain guided by the principle:

**An AI governance framework should be accessible enough to learn from, practical enough to implement, transparent enough to review, and adaptable enough to evolve.**

---

## 22. Framework Governance

AIGO requires a defined governance model to ensure that the framework itself remains consistent, transparent, accountable, and continuously maintained.

Framework governance is separate from the governance of AI systems implemented by organizations using AIGO.

### 22.1 Purpose of Framework Governance

Framework governance is intended to ensure that:

- the framework remains consistent;
- changes are appropriately reviewed;
- framework integrity is maintained;
- responsibilities are clearly defined;
- releases are controlled;
- community contributions are managed;
- conflicts are appropriately addressed; and
- the framework continues to meet its intended objectives.

### 22.2 Framework Ownership

AIGO should have clearly defined ownership for the framework and its associated intellectual property, governance processes, documentation, and official releases.

Ownership arrangements should be documented separately from operational responsibilities.

### 22.3 Framework Maintainers

Maintainers are responsible for the ongoing maintenance of AIGO.

Maintainer responsibilities may include:

- reviewing proposed changes;
- maintaining framework documentation;
- managing issues;
- coordinating releases;
- maintaining version history;
- reviewing community contributions;
- identifying outdated content; and
- coordinating framework improvements.

### 22.4 Governance Roles

AIGO governance may include roles such as:

- Framework Owner;
- Lead Maintainer;
- Framework Maintainers;
- Domain Maintainers;
- Reviewers;
- Contributors;
- Subject Matter Experts; and
- Advisory Participants.

The exact organizational structure may evolve as the framework develops.

### 22.5 Framework Owner

The Framework Owner is responsible for ensuring that AIGO remains aligned with its purpose, mission, vision, and governance principles.

Responsibilities may include:

- strategic direction;
- approval of major framework changes;
- governance oversight;
- intellectual property oversight;
- release authority; and
- long-term framework sustainability.

### 22.6 Domain Maintainers

Domain Maintainers may be responsible for specific areas of the framework.

Examples may include:

- risk;
- security;
- privacy;
- data governance;
- lifecycle;
- controls;
- assurance;
- maturity; and
- AI system profiles.

Domain Maintainers should ensure consistency between their assigned areas and the wider framework.

### 22.7 Reviewers

Reviewers may evaluate proposed framework changes for quality, consistency, practical usefulness, and potential impact.

Reviewers may include individuals with expertise in:

- AI governance;
- risk management;
- security;
- privacy;
- compliance;
- software engineering;
- AI engineering;
- audit;
- organizational governance; or
- other relevant disciplines.

### 22.8 Subject Matter Experts

Subject Matter Experts may provide specialist input for specific framework topics.

Their participation may be requested for:

- technical questions;
- regulatory considerations;
- sector-specific requirements;
- risk analysis;
- security;
- privacy;
- assurance; and
- emerging AI technologies.

### 22.9 Governance Decision-Making

AIGO governance decisions should follow defined decision-making principles.

Decisions should consider:

- framework objectives;
- consistency;
- evidence;
- practical implementation;
- user impact;
- risk;
- compatibility;
- external developments; and
- long-term maintainability.

### 22.10 Major Framework Changes

Major changes should receive an appropriate level of review and approval.

Major changes may include:

- changes to core principles;
- changes to the control model;
- changes to the lifecycle;
- changes to governance domains;
- changes to maturity definitions;
- changes to framework architecture; and
- changes that materially affect implementation.

### 22.11 Minor Framework Changes

Minor changes may include:

- editorial corrections;
- clarification;
- formatting improvements;
- examples;
- terminology improvements; and
- non-material documentation changes.

Minor changes may follow a simplified review process.

### 22.12 Change Proposals

Proposed changes should be documented sufficiently for reviewers to understand their purpose and potential impact.

A change proposal may include:

- change description;
- rationale;
- affected sections;
- expected benefits;
- implementation impact;
- compatibility considerations;
- risks; and
- proposed version impact.

### 22.13 Change Review

Proposed changes should be reviewed before inclusion in an official release.

The review should consider:

- technical accuracy;
- governance consistency;
- terminology;
- practical applicability;
- duplication;
- conflicts with existing requirements;
- external dependencies; and
- potential unintended consequences.

### 22.14 Conflict Resolution

Where disagreements occur regarding framework changes, AIGO should have a documented mechanism for resolving them.

Conflict resolution may include:

- discussion between maintainers;
- subject matter review;
- community feedback;
- formal proposal review;
- decision by designated governance authority; and
- documented final decision.

### 22.15 Conflict of Interest

Individuals participating in AIGO governance should disclose relevant conflicts of interest where appropriate.

Conflicts may include:

- commercial interests;
- vendor relationships;
- consulting relationships;
- organizational interests;
- financial interests; or
- other relationships that could reasonably affect impartiality.

### 22.16 Independence

Framework governance should seek to maintain sufficient independence from any single vendor, technology provider, consulting organization, or commercial interest.

This is particularly important where framework decisions could affect commercial implementation or certification activities.

### 22.17 Governance Records

Significant framework governance decisions should be documented.

Governance records may include:

- decisions;
- approvals;
- change proposals;
- review comments;
- release decisions;
- meeting records; and
- governance actions.

### 22.18 Framework Issue Management

The AIGO project should provide an appropriate mechanism for reporting framework issues.

Issues may include:

- errors;
- inconsistencies;
- unclear requirements;
- outdated information;
- missing guidance;
- implementation difficulties; and
- proposed improvements.

### 22.19 Issue Classification

Issues may be classified according to their nature and severity.

Possible classifications include:

- editorial;
- clarification;
- improvement;
- framework defect;
- governance issue;
- security issue;
- legal or regulatory concern; and
- critical framework issue.

### 22.20 Release Governance

Official AIGO releases should follow a controlled release process.

The release process may include:

1. change identification;
2. proposal;
3. review;
4. approval;
5. documentation;
6. version assignment;
7. publication;
8. communication; and
9. post-release review.

### 22.21 Release Approval

Appropriate authority should approve official releases before publication.

The approval process should reflect the significance of the release.

### 22.22 Governance Transparency

AIGO governance should be transparent where practical.

Public information may include:

- governance structure;
- maintainers;
- release history;
- significant changes;
- contribution procedures;
- governance policies; and
- framework status.

### 22.23 Framework Governance and Commercial Services

Commercial services built around AIGO should not have unilateral authority to change the official framework unless such authority has been formally established through the framework governance model.

Commercial implementations may extend AIGO for specific customer or industry requirements, but such extensions should be clearly identified as extensions.

### 22.24 Framework Extensions

Organizations may create extensions to AIGO for their own requirements.

Extensions may include:

- industry-specific controls;
- organizational policies;
- additional procedures;
- additional evidence requirements;
- technology-specific requirements; and
- jurisdiction-specific requirements.

Extensions should maintain traceability to the relevant AIGO components where practical.

### 22.25 Framework Governance Metrics

AIGO governance may use metrics to evaluate the health of the framework itself.

Metrics may include:

- number of proposed changes;
- review time;
- release frequency;
- unresolved issues;
- contribution activity;
- implementation feedback;
- framework adoption indicators; and
- identified framework gaps.

### 22.26 Periodic Governance Review

The AIGO governance model should be periodically reviewed.

The review may consider:

- framework effectiveness;
- governance effectiveness;
- stakeholder feedback;
- contribution patterns;
- technology developments;
- external standards;
- regulatory developments; and
- future framework requirements.

### 22.27 Governance Continuity

AIGO should maintain processes that support continuity when maintainers or governance participants change.

Appropriate documentation should allow new maintainers to understand:

- framework history;
- governance decisions;
- current priorities;
- open issues;
- release processes; and
- maintenance responsibilities.

### 22.28 Framework Governance Evolution

The governance structure may evolve as AIGO adoption increases.

Future governance models may introduce:

- formal advisory boards;
- technical committees;
- domain working groups;
- regional representatives;
- sector-specific working groups; and
- independent review bodies.

### 22.29 Governance Accountability

AIGO governance participants should be accountable for decisions and responsibilities assigned to them.

Responsibilities should be documented and reviewed periodically.

### 22.30 Framework Governance Principle

AIGO framework governance should follow the principle:

**The framework should be governed with the same principles of accountability, transparency, traceability, and continuous improvement that it expects organizations to apply to AI governance.**

---

## 23. Versioning and Change Management

AIGO uses controlled versioning and change management to maintain the integrity, traceability, stability, and long-term evolution of the framework.

Versioning allows organizations to identify which version of AIGO they have implemented and to understand changes between framework releases.

### 23.1 Purpose of Versioning

AIGO versioning is intended to:

- provide clear framework identification;
- maintain historical traceability;
- distinguish different framework releases;
- support controlled adoption;
- communicate changes;
- support migration between versions; and
- maintain long-term framework integrity.

### 23.2 Version Identification

Each official AIGO release should have a unique version identifier.

Version identifiers should be consistently applied to:

- framework releases;
- major documentation;
- schemas;
- mappings;
- implementation guidance; and
- other controlled framework artifacts where appropriate.

### 23.3 Versioning Model

AIGO may use a structured versioning model consisting of:

- major version;
- minor version; and
- patch version.

A conceptual format is:

`MAJOR.MINOR.PATCH`

For example:

`1.0.0`

The final versioning policy should be formally defined before the first stable release.

### 23.4 Major Versions

A major version may be introduced when significant changes affect the framework structure, governance model, control architecture, terminology, or implementation expectations.

Major versions may introduce:

- new framework architecture;
- significant control changes;
- lifecycle changes;
- new governance domains;
- major terminology changes;
- incompatible structural changes; or
- other material changes.

### 23.5 Minor Versions

A minor version may introduce meaningful improvements that maintain general compatibility with the existing framework structure.

Minor releases may include:

- new controls;
- additional guidance;
- new profiles;
- new examples;
- expanded governance requirements;
- additional mappings; and
- non-breaking framework improvements.

### 23.6 Patch Versions

Patch versions may be used for limited changes that do not materially alter framework requirements.

Examples may include:

- typographical corrections;
- clarification;
- formatting corrections;
- broken references;
- documentation corrections; and
- other non-material changes.

### 23.7 Draft Versions

Draft versions may be used during framework development.

Draft releases should clearly identify their status.

Examples may include:

- Draft;
- Preview;
- Experimental;
- Candidate; and
- Proposed.

Draft versions should not automatically be interpreted as stable requirements.

### 23.8 Stable Versions

A stable version represents an officially released version of AIGO intended for organizational adoption.

Stable releases should have:

- defined scope;
- approved content;
- documented version information;
- change history;
- known dependencies; and
- appropriate release approval.

### 23.9 Version Status

Each framework version should have a clearly defined status.

Possible statuses include:

- Draft;
- Proposed;
- Candidate;
- Current;
- Maintained;
- Deprecated; and
- Retired.

### 23.10 Change Classification

Changes should be classified according to their impact.

Possible classifications include:

- editorial;
- clarification;
- minor enhancement;
- control modification;
- new requirement;
- structural change;
- breaking change; and
- major framework change.

### 23.11 Change Impact Assessment

Significant changes should be assessed before approval.

The assessment may consider:

- affected framework sections;
- affected controls;
- affected profiles;
- implementation impact;
- evidence impact;
- mapping impact;
- organizational impact;
- migration requirements; and
- potential risks.

### 23.12 Change Proposal

Significant framework changes should be documented through an appropriate change proposal.

A change proposal may contain:

- proposal identifier;
- title;
- description;
- rationale;
- affected components;
- expected benefits;
- risks;
- implementation impact;
- compatibility considerations; and
- proposed version impact.

### 23.13 Change Review

Changes should undergo an appropriate review before inclusion in an official release.

Review should consider:

- consistency;
- accuracy;
- clarity;
- governance implications;
- implementation feasibility;
- external alignment;
- compatibility; and
- long-term maintainability.

### 23.14 Change Approval

Changes should be approved by the appropriate framework governance authority.

The level of approval should be proportional to the significance of the change.

### 23.15 Change Records

Significant changes should have a permanent record.

Change records may include:

- change identifier;
- description;
- rationale;
- author;
- reviewers;
- approval;
- affected version;
- implementation considerations; and
- release information.

### 23.16 Changelog

AIGO should maintain a changelog describing relevant changes between releases.

The changelog should help users understand:

- what changed;
- why it changed;
- which version introduced the change;
- whether action is required; and
- whether migration is recommended.

### 23.17 Backward Compatibility

AIGO should seek to maintain backward compatibility where practical.

Where backward compatibility cannot be maintained, the change should be clearly identified.

### 23.18 Breaking Changes

Breaking changes may require organizations to modify existing governance implementations.

Examples may include:

- removal of controls;
- restructuring of control identifiers;
- changes to mandatory requirements;
- major lifecycle changes;
- changes to required evidence; and
- changes to framework terminology that materially affect implementation.

Breaking changes should be clearly communicated.

### 23.19 Migration Guidance

Major framework releases should provide migration guidance where practical.

Migration guidance may identify:

- changed requirements;
- deprecated requirements;
- new requirements;
- affected controls;
- required documentation updates;
- evidence changes;
- mapping changes; and
- recommended migration steps.

### 23.20 Deprecation

AIGO components may be deprecated when they are no longer recommended for new implementations.

Deprecated components should remain documented for an appropriate transition period where practical.

### 23.21 Retirement

A framework component may eventually be retired when it is no longer supported.

Retirement should be documented and should identify:

- retirement date;
- reason;
- replacement component where applicable; and
- migration considerations.

### 23.22 Version Traceability

Organizations implementing AIGO should be able to identify the version against which their governance program, assessment, or implementation was performed.

This may be recorded in:

- governance documentation;
- assessment reports;
- system records;
- evidence repositories;
- implementation records; and
- audit documentation.

### 23.23 Control Versioning

Individual controls should have stable identifiers where practical.

Changes to controls should maintain sufficient history to determine:

- when the control was introduced;
- when it was changed;
- which versions included it; and
- whether the change affects implementation.

### 23.24 Identifier Stability

AIGO should avoid unnecessary changes to identifiers.

Stable identifiers improve:

- traceability;
- mappings;
- automation;
- evidence management;
- reporting;
- assessment history; and
- long-term interoperability.

### 23.25 Mapping Versioning

External mappings should have their own version information.

This is important because external standards, regulations, and guidance may change independently of AIGO.

A mapping should identify, where appropriate:

- AIGO version;
- external source version;
- mapping version;
- publication date; and
- status.

### 23.26 Schema Versioning

Machine-readable schemas should be versioned independently where necessary.

Schema changes should identify compatibility implications for systems using the schemas.

### 23.27 Documentation Versioning

Controlled documentation should include appropriate version information where required.

Documentation versioning may apply to:

- framework documents;
- procedures;
- templates;
- implementation guidance;
- profiles;
- assessment materials; and
- other controlled artifacts.

### 23.28 Release Communication

Significant releases should be communicated to relevant stakeholders.

Release communication may include:

- release notes;
- changelog;
- migration guidance;
- implementation notices;
- deprecated components; and
- significant governance changes.

### 23.29 Emergency Changes

AIGO may require an expedited change process in exceptional circumstances.

Examples may include:

- critical framework errors;
- serious security concerns;
- incorrect governance requirements;
- critical external changes; or
- other circumstances requiring urgent correction.

Emergency changes should still be documented and reviewed retrospectively where appropriate.

### 23.30 Change Management Evidence

AIGO framework governance should maintain evidence of significant change management activities.

Evidence may include:

- change proposals;
- review records;
- approvals;
- decision records;
- release records;
- migration guidance; and
- changelog entries.

### 23.31 Version Lifecycle

AIGO versions may follow a lifecycle such as:

1. Draft;
2. Review;
3. Candidate;
4. Published;
5. Maintained;
6. Deprecated; and
7. Retired.

The exact lifecycle may evolve as the framework governance model matures.

### 23.32 Versioning and Organizational Adoption

Organizations should document the AIGO version adopted for their governance program.

Organizations may choose to remain on a specific version for a defined period based on:

- implementation effort;
- contractual requirements;
- internal governance cycles;
- risk;
- regulatory requirements; and
- organizational policy.

### 23.33 Continuous Change Management

AIGO should be continuously reviewed to identify changes required by:

- emerging AI technologies;
- new AI risks;
- organizational experience;
- external standards;
- regulatory developments;
- security developments;
- community feedback; and
- implementation experience.

### 23.34 Versioning and Change Management Principle

AIGO versioning and change management should follow the principle:

**Changes should be controlled, traceable, reviewable, communicated, and proportionate to their impact.**

---