> ## Documentation Index > Fetch the complete documentation index at: https://docs.aigoframework.com/llms.txt > Use this file to discover all available pages before exploring further. # AIGO Framework Charter v0.1 # AIGO — AI Governance Operating Framework ## Framework Charter **Version:** 0.1\ **Status:** Draft\ **Working Name:** AIGO\ **Full Name:** AI Governance Operating Framework *** ## 1. Purpose The AIGO — AI Governance Operating Framework provides a structured, technology-neutral approach for organizations to govern, manage, operate, monitor, and continuously improve their use of artificial intelligence. AIGO is designed to help organizations establish consistent governance practices across the lifecycle of AI systems, from initial idea and assessment through development, deployment, operation, monitoring, change, and retirement. The framework provides a common organizational language for AI governance, including principles, roles, responsibilities, risks, controls, procedures, evidence, assessments, and continuous improvement. *** ## 2. Mission AIGO's mission is to provide organizations with a practical, structured, and adaptable approach for governing artificial intelligence throughout its lifecycle. The framework aims to make AI governance understandable and operational for business leaders, governance teams, risk and compliance functions, security teams, developers, AI practitioners, and other stakeholders involved in the design, implementation, operation, or oversight of AI systems. *** ## 3. Vision AIGO aims to provide organizations with a practical and adaptable operating framework for responsible, secure, transparent, accountable, and sustainable use of artificial intelligence. The long-term vision is to establish a common governance language that can be applied to AI systems regardless of the technology, development framework, model provider, deployment architecture, or implementation methodology used. AIGO seeks to connect organizational governance requirements with the practical implementation and operation of AI systems. *** ## 4. Problem Statement Organizations are increasingly adopting artificial intelligence across business processes, products, services, and internal operations. AI systems may include traditional machine learning systems, generative AI applications, retrieval-augmented generation systems, chatbots, autonomous agents, agentic workflows, AI-powered automation, decision-support systems, and third-party AI services. However, organizations may lack a consistent operational approach for documenting, assessing, approving, monitoring, and governing these systems throughout their lifecycle. AI governance can become fragmented across technology teams, security teams, legal functions, risk functions, business owners, and individual AI projects. AIGO addresses this challenge by providing a structured framework through which organizations can establish consistent governance practices while allowing implementation teams to use different technologies and development approaches. *** ## 5. Scope AIGO may be applied to organizations that develop, acquire, integrate, deploy, operate, or use artificial intelligence systems. The framework may be applied to: * internally developed AI systems; * externally developed or purchased AI systems; * generative AI applications; * large language model applications; * retrieval-augmented generation (RAG) systems; * chatbots and conversational AI; * AI agents; * agentic workflows; * AI-powered automation; * decision-support systems; * AI-enabled business processes; * AI APIs and third-party AI services; * AI systems embedded within products or services; and * other AI-enabled applications and workflows. AIGO is implementation-independent. Organizations may implement AI systems using any appropriate programming language, framework, model provider, infrastructure, application architecture, or development methodology. AIGO does not require the use of a particular AI technology, software framework, model provider, cloud provider, or vendor. ### 5.1 What AIGO Does Not Do AIGO does not prescribe a specific technical implementation for an AI system. AIGO does not replace applicable laws, regulations, contractual requirements, industry standards, organizational policies, security requirements, or professional advice. AIGO does not by itself establish legal compliance with any jurisdiction or regulation. AIGO is intended to provide an organizational governance framework that can be used alongside applicable legal, regulatory, contractual, technical, and industry requirements. *** ## 6. Intended Users AIGO is intended for organizations and individuals involved in the governance, development, acquisition, implementation, operation, oversight, or use of artificial intelligence systems. AIGO may be used by organizations of different sizes, industries, and levels of AI maturity. Intended users include, but are not limited to: * executive leadership; * business owners; * AI governance teams; * AI program managers; * risk and compliance teams; * legal and regulatory functions; * information security teams; * privacy and data protection teams; * internal audit and assurance functions; * AI system owners; * product owners; * project managers; * software developers; * AI engineers; * data scientists; * machine learning engineers; * AI operations and platform teams; * system administrators; * procurement and vendor management teams; * employees using AI systems as part of their work; and * external consultants, assessors, auditors, and implementation partners. AIGO is designed to support collaboration between business, technical, governance, and assurance functions. The framework recognizes that responsibility for AI governance cannot normally be assigned to a single department or individual. Effective AI governance requires defined accountability and cooperation across relevant organizational functions. ### 6.1 Organizational Applicability AIGO may be applied by: * private companies; * public sector organizations; * non-profit organizations; * educational institutions; * research organizations; * technology providers; * AI service providers; * organizations developing internal AI capabilities; and * organizations primarily consuming third-party AI services. The level of implementation may be adapted according to the organization's size, complexity, AI usage, risk exposure, regulatory environment, and organizational maturity. ### 6.2 Individual AI System Applicability AIGO may be applied at different organizational levels. An organization may use AIGO to govern: * an individual AI system; * an AI application; * an AI product; * an AI project; * an AI workflow; * an AI agent; * an agentic workflow; * an AI-enabled business process; * a portfolio of AI systems; or * an organization's overall AI ecosystem. Where appropriate, organizations may apply different AIGO requirements, controls, and assurance activities according to the characteristics and risk of each AI system. *** ## 7. Core Objectives AIGO establishes a set of core objectives that guide the development, implementation, operation, and continuous improvement of AI governance within an organization. The objectives are intended to provide a common foundation for governance activities while allowing organizations to adapt their implementation according to their size, complexity, risk profile, industry, and applicable requirements. AIGO's core objectives are to: ### 7.1 Establish Accountability Ensure that AI systems have clearly defined ownership, responsibilities, authority, and accountability throughout their lifecycle. Organizations should be able to identify who is responsible for business decisions, technical operation, risk management, oversight, and governance of each relevant AI system. ### 7.2 Establish a Consistent AI Governance Structure Provide organizations with a consistent structure for managing AI governance across departments, projects, systems, and business processes. AIGO should enable organizations to establish common terminology, processes, responsibilities, controls, and documentation for AI governance. ### 7.3 Manage AI Risk Enable organizations to identify, assess, prioritize, mitigate, accept, monitor, and review risks associated with AI systems. Risk management should be proportionate to the characteristics, capabilities, intended use, potential impact, and operational context of each AI system. ### 7.4 Support Responsible AI Use Promote responsible development and use of AI through appropriate governance practices relating to accountability, transparency, human oversight, safety, security, privacy, fairness, reliability, and other relevant organizational or contextual considerations. ### 7.5 Govern the AI Lifecycle Establish governance activities across the complete lifecycle of an AI system, from initial concept and assessment through design, development, validation, approval, deployment, operation, monitoring, change, and retirement. ### 7.6 Establish Traceability and Documentation Enable organizations to maintain appropriate records describing AI systems, their purpose, ownership, architecture, data, dependencies, risks, controls, decisions, approvals, changes, incidents, and other relevant governance information. ### 7.7 Establish Human Oversight Ensure that organizations determine appropriate levels of human involvement, review, intervention, and decision authority based on the characteristics and risks of the AI system. Human oversight should be designed according to the context in which an AI system operates rather than applied as a uniform requirement to every AI system. ### 7.8 Protect Information and Data Support appropriate governance of information and data used, processed, generated, stored, or accessed by AI systems. Organizations should consider applicable requirements relating to security, privacy, confidentiality, data quality, data provenance, retention, access, and authorized use. ### 7.9 Establish Verification and Evaluation Enable organizations to evaluate AI systems before and after deployment using appropriate testing, validation, monitoring, and review activities. Evaluation should consider the intended purpose and relevant risks of the AI system. ### 7.10 Enable Continuous Monitoring and Improvement Establish mechanisms for organizations to monitor AI systems, identify changes or emerging risks, manage incidents, review performance, and continuously improve governance practices. AI governance should be treated as an ongoing organizational activity rather than a one-time approval process. ### 7.11 Support Evidence-Based Governance Enable organizations to demonstrate that defined governance activities have been performed through appropriate documentation, records, assessments, approvals, technical evidence, monitoring results, and other forms of evidence. Evidence requirements should be proportionate to the applicable risk and governance objectives. ### 7.12 Enable Technology-Neutral Governance Provide governance requirements that remain applicable regardless of the specific AI technology, model provider, programming language, development framework, infrastructure, or implementation architecture used. AIGO may therefore be applied to systems implemented using different technologies and development methodologies. ### 7.13 Enable Organizational Integration Support integration of AI governance with existing organizational management systems, policies, procedures, risk management, information security, privacy, compliance, quality management, procurement, and other relevant business functions. AIGO is intended to complement existing organizational governance rather than require organizations to create isolated processes for AI. ### 7.14 Support Scalable AI Governance Enable organizations to apply governance proportionately across different AI systems and levels of organizational complexity. A small internal AI assistant and a highly autonomous AI system with significant business impact should not necessarily require identical governance processes. AIGO should therefore support different implementation profiles, risk levels, and maturity levels. *** ## 8. Fundamental Principles The AIGO framework is based on fundamental principles that guide the interpretation, implementation, and continuous development of AI governance practices. These principles establish the foundation for AIGO requirements, controls, procedures, assessments, and organizational practices. The principles are intended to be applied proportionately according to the organization's context, the characteristics of the AI system, and the associated level of risk. ### 8.1 Accountability Organizations shall establish clear accountability for AI systems and their associated governance activities. Every relevant AI system should have identifiable ownership and defined responsibilities appropriate to its lifecycle and risk. Accountability should not be transferred solely to an AI system, automated process, model provider, or technology vendor. ### 8.2 Human Responsibility Organizations and authorized individuals remain responsible for decisions, actions, and outcomes associated with the use of AI within their area of authority. AI systems may support, recommend, automate, or execute activities, but organizational responsibility must remain clearly established. ### 8.3 Risk Proportionality AI governance should be proportionate to the potential risks, impact, capabilities, autonomy, intended use, affected parties, and operational context of an AI system. Higher-risk systems should generally require stronger governance, controls, oversight, testing, evidence, and monitoring than lower-risk systems. ### 8.4 Transparency Organizations should maintain sufficient information about AI systems to enable appropriate understanding, oversight, accountability, and decision-making. The level of transparency should be appropriate to the system's purpose, users, risks, and affected stakeholders. ### 8.5 Traceability Relevant decisions, changes, assessments, approvals, activities, and events associated with AI systems should be traceable through appropriate records and evidence. Traceability should support accountability, investigation, monitoring, review, and continuous improvement. ### 8.6 Human Oversight Organizations should establish appropriate human oversight for AI systems based on their characteristics, risks, autonomy, and operational context. Human oversight should provide meaningful opportunities for intervention, review, escalation, or shutdown where appropriate. ### 8.7 Security AI systems should be protected against unauthorized access, misuse, manipulation, disruption, data compromise, and other relevant security threats. Security considerations should apply throughout the AI lifecycle. ### 8.8 Privacy and Data Protection Organizations should appropriately govern personal information and other sensitive or protected data processed by AI systems. Data collection, use, processing, storage, sharing, retention, and deletion should be managed according to applicable requirements and organizational policies. ### 8.9 Reliability and Robustness AI systems should be designed, evaluated, and operated with appropriate consideration for reliability, robustness, resilience, and predictable behavior within their intended context. Organizations should identify and manage limitations and known failure conditions. ### 8.10 Fairness and Non-Discrimination Where relevant to the intended use and context, organizations should identify and manage risks of unfair outcomes, discrimination, inappropriate bias, or unequal treatment resulting from the use of AI systems. The interpretation and implementation of this principle should consider applicable laws, organizational policies, system purpose, and affected populations. ### 8.11 Safety Organizations should identify and manage risks that could cause physical, psychological, operational, financial, societal, or other significant harm through the use or failure of an AI system. Safety requirements should be proportionate to the potential impact of the system. ### 8.12 Purpose Limitation AI systems should be developed, acquired, configured, and used for defined and legitimate purposes. Organizations should establish appropriate boundaries around the intended use of AI systems and should manage material deviations from the approved purpose. ### 8.13 Least Privilege and Controlled Authority AI systems, agents, automated workflows, and associated tools should receive only the access, permissions, capabilities, and authority necessary to perform their approved functions. Additional authority should require appropriate authorization and governance. ### 8.14 Evidence-Based Governance AI governance decisions should be supported by appropriate information, assessments, testing, records, monitoring results, and other relevant evidence. The amount and type of evidence should be proportionate to the risk and significance of the AI system. ### 8.15 Continuous Improvement AI governance should continuously evolve in response to changes in technology, organizational requirements, risks, incidents, regulations, standards, operational experience, and stakeholder expectations. Organizations should periodically review and improve their AI governance practices. ### 8.16 Technology Neutrality AIGO requirements should remain independent of specific AI vendors, model providers, programming languages, frameworks, cloud platforms, or technical architectures. The framework should describe governance outcomes and controls without unnecessarily prescribing a particular implementation technology. ### 8.17 Proportionality and Practicality AIGO should be practical to implement and should avoid imposing unnecessary governance burdens where risks are limited. Organizations should be able to scale governance activities according to their size, complexity, AI maturity, and risk exposure. ### 8.18 Continuous Human and Organizational Learning Organizations should use experience from AI system operation, incidents, assessments, evaluations, user feedback, and governance reviews to improve organizational knowledge and decision-making. AI governance should contribute to the organization's ability to learn and adapt as AI capabilities and risks evolve. *** ## 9. Framework Architecture AIGO is structured as a layered governance framework. The architecture separates foundational governance concepts from operational requirements, implementation guidance, evidence, and supporting tools. The framework is designed to allow organizations to implement AIGO at different levels of complexity while maintaining a consistent governance structure. ### 9.1 Framework Layers AIGO consists of the following conceptual layers: 1. **Charter** 2. **Principles** 3. **Governance Domains** 4. **Roles and Accountability** 5. **AI Governance Lifecycle** 6. **Risk Management** 7. **Controls** 8. **Maturity** 9. **AI System Profiles** These layers are supported by implementation guidance, procedures, templates, examples, schemas, and tools. ### 9.2 Charter Layer The Charter establishes the purpose, scope, objectives, philosophy, and foundational structure of AIGO. It defines the boundaries within which the remainder of the framework should be interpreted. ### 9.3 Principles Layer The Principles establish the fundamental governance expectations that guide organizational decisions and the interpretation of AIGO requirements. Principles provide the foundation for developing governance domains, controls, procedures, and assessment activities. ### 9.4 Governance Domains Layer Governance Domains organize AIGO requirements into logical areas of responsibility. Domains may include areas such as: * organizational governance; * AI strategy; * risk management; * data governance; * security; * privacy; * AI lifecycle management; * human oversight; * agent governance; * monitoring; * incident management; * third-party AI; * change management; and * continuous improvement. The final set of governance domains will be established as the framework develops. ### 9.5 Roles and Accountability Layer The Roles and Accountability layer defines the organizational responsibilities associated with AI governance. It establishes relationships between organizational roles, decision-making authority, accountability, responsibility, consultation, approval, oversight, and operational activities. ### 9.6 AI Governance Lifecycle Layer The AI Governance Lifecycle defines governance activities across the life of an AI system. The lifecycle is intended to provide a common structure for governance activities from initial conception through retirement. AIGO will define lifecycle stages and the governance activities associated with each stage. ### 9.7 Risk Management Layer The Risk Management layer establishes a structured approach for identifying, assessing, treating, accepting, monitoring, and reviewing AI-related risks. Risk management will be used to determine the appropriate level of governance for an AI system. ### 9.8 Controls Layer The Controls layer contains specific governance requirements that organizations may implement to achieve the objectives of AIGO. Controls will be: * uniquely identified; * categorized by governance domain; * associated with relevant lifecycle stages; * associated with applicable risk considerations; * assigned appropriate responsibility; * supported by implementation guidance; and * associated with appropriate evidence where applicable. Controls may contain different implementation expectations depending on the organization's context, risk level, maturity, and applicable profile. ### 9.9 Maturity Layer The Maturity layer provides a method for organizations to assess the development and effectiveness of their AI governance capabilities. Maturity levels are intended to help organizations: * understand their current governance capability; * identify gaps; * establish improvement priorities; * measure progress; and * plan future governance development. The final maturity model will be defined separately within the AIGO framework. ### 9.10 AI System Profiles Layer AI System Profiles provide contextual guidance for different types of AI systems and implementations. Potential profiles may include: * generative AI; * large language model applications; * RAG systems; * chatbots; * AI agents; * agentic workflows; * AI automation; * decision-support systems; * AI-enabled products; and * third-party AI services. Profiles may identify controls, risks, evidence, and governance activities that are particularly relevant to a specific type of AI system. ### 9.11 Supporting Resources The AIGO framework is supported by additional resources that assist organizations with practical implementation. These resources may include: * implementation guidance; * procedures; * templates; * assessment questionnaires; * examples; * evidence requirements; * machine-readable schemas; * validation tools; * reference implementations; and * other supporting resources. Supporting resources should remain consistent with the normative framework while providing practical implementation assistance. ### 9.12 Relationship Between Framework Components The components of AIGO are intended to operate together. A simplified relationship is: Charter ↓ Principles ↓ Governance Domains ↓ Roles and Accountability ↓ AI Governance Lifecycle ↓ Risk Management ↓ Controls ↓ Evidence and Assessment ↓ Maturity and Continuous Improvement AI System Profiles provide additional contextual information across these layers. ### 9.13 Normative and Informative Content AIGO will distinguish between normative and informative content. **Normative content** defines requirements, expectations, or criteria that form part of the AIGO framework. **Informative content** provides explanations, recommendations, examples, implementation approaches, or other supporting information. This distinction is intended to help organizations understand which parts of AIGO define framework requirements and which parts provide guidance for implementing those requirements. ### 9.14 Framework Extensibility AIGO is designed to be extensible. New governance domains, controls, profiles, implementation guidance, schemas, and tools may be introduced as AI technologies, organizational practices, risks, and governance requirements evolve. Extensions should maintain compatibility with the core principles and architecture of AIGO. *** ## 10. AI Governance Lifecycle AIGO establishes a lifecycle-based approach to AI governance. AI governance should not be treated as a single approval activity performed before deployment. Governance should continue throughout the lifecycle of an AI system and should adapt when the system, purpose, environment, risk, or organizational requirements change. The AIGO lifecycle provides a common structure for identifying the governance activities that should be performed at each stage. ### 10.1 Lifecycle Stages The AIGO AI Governance Lifecycle consists of the following conceptual stages: 1. **Ideation** 2. **Registration** 3. **Assessment** 4. **Design** 5. **Development or Acquisition** 6. **Validation** 7. **Approval** 8. **Deployment** 9. **Operation** 10. **Monitoring** 11. **Change Management** 12. **Incident and Exception Management** 13. **Periodic Review** 14. **Retirement** The final lifecycle requirements and associated controls will be defined in the relevant AIGO framework sections. ### 10.2 Ideation The Ideation stage establishes the initial purpose and intended business or organizational use of an AI system. Activities may include: * defining the business problem; * identifying the intended users; * defining the expected outcomes; * identifying the proposed AI capabilities; * considering alternatives to AI; * identifying initial risks and constraints; and * determining whether further assessment is required. Organizations should avoid introducing AI systems without a sufficiently defined purpose and intended use. ### 10.3 Registration The Registration stage establishes a formal record of the proposed or existing AI system. The AI system record may include: * system name; * system owner; * business purpose; * intended users; * system type; * technical architecture; * AI models; * data sources; * external services; * tools and integrations; * level of autonomy; * deployment environment; and * initial governance status. The registration record should become part of the system's governance documentation. ### 10.4 Assessment The Assessment stage determines the characteristics, risks, requirements, and governance needs of the AI system. Assessment may consider: * intended purpose; * affected users or stakeholders; * data; * model capabilities; * system autonomy; * decision-making authority; * security; * privacy; * safety; * reliability; * fairness; * operational impact; * regulatory considerations; * third-party dependencies; and * potential misuse or failure scenarios. Assessment outcomes should inform the governance controls and assurance activities applied to the system. ### 10.5 Design The Design stage establishes how the AI system will be structured to meet its intended purpose and governance requirements. Design considerations may include: * system architecture; * model selection; * data architecture; * access controls; * human oversight; * security controls; * privacy controls; * monitoring; * logging; * fallback mechanisms; * escalation mechanisms; * agent authority; * tool permissions; and * failure handling. Governance requirements identified during assessment should be incorporated into the system design where applicable. ### 10.6 Development or Acquisition The Development or Acquisition stage covers the creation, configuration, procurement, integration, or customization of an AI system. Organizations should ensure that relevant governance requirements are incorporated into development or acquisition activities. For third-party AI systems, organizations should consider appropriate vendor and service-provider assessments. ### 10.7 Validation The Validation stage determines whether the AI system is suitable for its intended purpose and whether relevant governance requirements have been addressed. Validation may include: * functional testing; * AI evaluation; * security testing; * privacy assessment; * robustness testing; * performance evaluation; * safety evaluation; * adversarial testing; * human review; * data validation; and * verification of governance controls. Validation activities should be proportionate to the system's risk and intended use. ### 10.8 Approval The Approval stage establishes whether the AI system is authorized to proceed to deployment or the next applicable operational stage. Approval should be performed by appropriately authorized individuals or organizational functions. Approval records should identify: * the system being approved; * the intended purpose; * relevant risk classification; * applicable controls; * outstanding issues; * accepted exceptions or risks; * approval authority; and * approval date. Approval should not remove the requirement for ongoing monitoring and review. ### 10.9 Deployment The Deployment stage covers the controlled introduction of an AI system into its intended operational environment. Organizations should ensure that required controls, permissions, monitoring mechanisms, documentation, and operational procedures are established before or during deployment as appropriate. ### 10.10 Operation The Operation stage covers the normal use and management of the AI system. Operational governance may include: * access management; * user management; * system monitoring; * performance monitoring; * usage monitoring; * incident handling; * logging; * operational support; * periodic checks; and * maintenance activities. ### 10.11 Monitoring AI systems should be monitored throughout their operational lifecycle according to their characteristics and risk. Monitoring may consider: * system performance; * model behavior; * output quality; * security events; * abnormal activity; * policy violations; * incidents; * changes in data; * changes in usage; * emerging risks; and * changes in the external environment. Monitoring results should be used to determine whether further action, assessment, or review is required. ### 10.12 Change Management Changes to an AI system should be governed according to their potential impact. Changes may include: * model changes; * prompt or instruction changes; * data source changes; * RAG knowledge-base changes; * tool changes; * permission changes; * workflow changes; * agent behavior changes; * infrastructure changes; * changes to intended use; and * integration with new external systems. Material changes may require reassessment, revalidation, or reapproval before becoming operational. ### 10.13 Incident and Exception Management Organizations should establish processes for managing incidents, failures, unexpected behavior, policy violations, security events, and approved exceptions associated with AI systems. Incident and exception management should support: * identification; * reporting; * classification; * containment; * investigation; * remediation; * escalation; * documentation; and * lessons learned. ### 10.14 Periodic Review AI systems should be periodically reviewed according to their risk, complexity, usage, and organizational requirements. Reviews may consider: * continued suitability for the intended purpose; * changes in risk; * control effectiveness; * incidents; * performance; * user feedback; * regulatory or organizational changes; * technology changes; and * continued business justification. The review frequency should be proportionate to the relevant risk and context. ### 10.15 Retirement The Retirement stage covers the controlled decommissioning of an AI system. Retirement activities may include: * disabling the system; * removing access; * handling retained data; * managing records; * terminating external services; * documenting the retirement decision; * addressing dependencies; and * preserving required governance evidence. Retirement should be managed in a manner consistent with organizational, contractual, security, privacy, legal, and regulatory requirements. ### 10.16 Lifecycle Iteration The AIGO lifecycle is iterative rather than strictly linear. Events occurring during operation may cause an AI system to return to earlier lifecycle stages. For example: Monitoring ↓ Significant Change ↓ Reassessment ↓ Validation ↓ Approval ↓ Operation Similarly, an incident may require reassessment or redesign of an AI system. Organizations should therefore treat the lifecycle as a continuous governance process rather than a one-time sequence. ### 10.17 Proportional Lifecycle Governance Not every AI system requires the same level of governance activity at every lifecycle stage. Organizations should determine the appropriate level of activity based on factors such as: * risk; * autonomy; * intended purpose; * affected parties; * data sensitivity; * system complexity; * operational impact; * scale of deployment; and * applicable organizational or external requirements. AIGO will provide mechanisms for applying governance proportionately while maintaining consistent lifecycle principles. *** ## 11. Governance Domains AIGO organizes AI governance activities into defined governance domains. Governance domains provide a structured way to group related requirements, responsibilities, risks, controls, procedures, and evidence. The domains are intended to cover the major organizational areas required for effective AI governance while remaining adaptable to different industries, organizational structures, and AI use cases. The final domain structure may evolve as the framework develops. ### 11.1 Organizational AI Governance This domain addresses the organization's overall AI governance structure. It may include: * AI governance policies; * governance objectives; * organizational accountability; * decision-making authority; * AI governance committees; * governance responsibilities; * AI strategy; * organizational policies; * management oversight; and * governance reporting. ### 11.2 AI Inventory and Asset Management This domain addresses identification and management of AI systems within the organization. It may include: * AI system inventories; * system ownership; * system classification; * system registration; * AI dependencies; * model inventories; * third-party AI services; * system relationships; and * lifecycle status. ### 11.3 AI Risk Management This domain addresses the identification, assessment, treatment, acceptance, monitoring, and review of AI-related risks. It may include: * risk identification; * risk assessment; * risk classification; * risk treatment; * risk acceptance; * risk monitoring; * risk reporting; and * residual risk management. ### 11.4 AI Lifecycle Governance This domain addresses governance activities throughout the lifecycle of AI systems. It may include: * ideation; * registration; * assessment; * design; * development; * acquisition; * validation; * approval; * deployment; * operation; * monitoring; * change management; and * retirement. ### 11.5 Data Governance This domain addresses governance of data used, processed, stored, generated, or accessed by AI systems. It may include: * data ownership; * data quality; * data provenance; * data classification; * data access; * data usage; * data retention; * data protection; * training data governance; * retrieval data sources; and * data lifecycle management. ### 11.6 AI Security This domain addresses security risks associated with AI systems, models, data, infrastructure, applications, integrations, and users. It may include: * identity and access management; * authentication; * authorization; * secrets management; * infrastructure security; * model security; * prompt security; * adversarial threats; * data security; * application security; * logging; * monitoring; and * incident response. ### 11.7 Privacy and Data Protection This domain addresses privacy and data protection considerations associated with AI systems. It may include: * personal data processing; * privacy assessments; * data minimization; * lawful use; * data subject considerations; * retention; * access; * deletion; * privacy risks; and * privacy-related incidents. Applicable privacy requirements should be determined according to the organization's jurisdiction, activities, and applicable obligations. ### 11.8 AI Quality and Reliability This domain addresses the quality, reliability, robustness, and operational performance of AI systems. It may include: * quality requirements; * evaluation; * testing; * validation; * reliability; * robustness; * performance; * failure handling; * resilience; * monitoring; and * continuous improvement. ### 11.9 Human Oversight and Decision Governance This domain addresses human responsibility and oversight over AI systems. It may include: * human-in-the-loop processes; * human-on-the-loop processes; * human review; * intervention; * escalation; * override mechanisms; * decision authority; * user responsibilities; and * accountability for AI-assisted decisions. ### 11.10 AI Agent and Autonomy Governance This domain addresses AI systems that can independently perform actions, use tools, make decisions, execute workflows, or interact with external systems. It may include: * agent authority; * tool permissions; * action boundaries; * approval requirements; * autonomy levels; * execution limits; * escalation; * human intervention; * transaction controls; * monitoring; * audit trails; and * emergency shutdown mechanisms. This domain is particularly relevant to agentic workflows and autonomous AI systems. ### 11.11 Generative AI and Foundation Model Governance This domain addresses governance considerations associated with generative AI and foundation-model-based systems. It may include: * model selection; * model providers; * model usage restrictions; * prompts and instructions; * generated content; * output evaluation; * model limitations; * content risks; * model updates; * provider dependencies; and * usage monitoring. ### 11.12 RAG and Knowledge Governance This domain addresses AI systems that retrieve information from internal or external knowledge sources before generating outputs. It may include: * knowledge-source approval; * document ownership; * source classification; * ingestion controls; * access controls; * retrieval permissions; * source freshness; * provenance; * indexing; * retrieval evaluation; and * knowledge-base change management. ### 11.13 Third-Party and Vendor AI Governance This domain addresses AI systems, models, APIs, platforms, and services provided by external organizations. It may include: * vendor assessment; * AI service evaluation; * contractual requirements; * security requirements; * privacy requirements; * service dependencies; * provider changes; * model changes; * service availability; * data handling; and * exit or replacement planning. ### 11.14 AI Incident and Issue Management This domain addresses the identification, reporting, investigation, response, remediation, and learning associated with AI-related incidents and issues. It may include: * incident identification; * classification; * reporting; * escalation; * containment; * investigation; * remediation; * root-cause analysis; * evidence preservation; * stakeholder communication; and * lessons learned. ### 11.15 AI Change Management This domain addresses changes that may affect the behavior, capabilities, risk, or governance status of an AI system. Changes may include: * model changes; * prompt changes; * data changes; * knowledge-base changes; * workflow changes; * agent changes; * tool changes; * permission changes; * infrastructure changes; * provider changes; and * changes to intended use. ### 11.16 Compliance and Regulatory Alignment This domain addresses the organization's process for identifying and managing applicable legal, regulatory, contractual, and organizational requirements related to AI. AIGO does not itself determine whether an organization is legally compliant. Instead, this domain provides governance mechanisms for identifying applicable requirements and incorporating them into organizational processes. ### 11.17 Documentation and Records This domain addresses the documentation and records necessary to support AI governance. It may include: * AI system documentation; * policies; * procedures; * assessments; * approvals; * risk records; * control records; * testing results; * monitoring records; * incident records; * change records; and * retirement records. ### 11.18 Training and AI Literacy This domain addresses organizational knowledge and competency required for appropriate use and governance of AI. It may include: * AI awareness; * role-specific training; * governance training; * acceptable-use guidance; * technical competency; * responsible AI education; * security awareness; * privacy awareness; and * ongoing professional development. ### 11.19 Assurance and Internal Review This domain addresses activities used to evaluate whether AI governance processes and controls are operating as intended. It may include: * internal assessments; * control reviews; * independent reviews; * audits; * evidence verification; * maturity assessments; * corrective actions; and * management review. ### 11.20 Continuous Improvement This domain addresses the ongoing improvement of AI governance capabilities. It may include: * governance performance measurement; * lessons learned; * incident analysis; * control improvement; * maturity improvement; * stakeholder feedback; * emerging-risk monitoring; * framework updates; and * governance effectiveness reviews. ### 11.21 Domain Interdependencies Governance domains should not be treated as isolated functions. AI governance activities frequently involve multiple domains. For example: AI System ↓ Risk Assessment ↓ Data Governance ↓ Security and Privacy ↓ Human Oversight ↓ Controls ↓ Validation ↓ Approval ↓ Monitoring ↓ Continuous Improvement AIGO should therefore support cross-domain relationships between risks, controls, responsibilities, lifecycle stages, evidence, and assessments. ### 11.22 Domain Extensibility Organizations may require additional governance domains based on their industry, jurisdiction, business model, technology environment, or AI use cases. AIGO therefore allows organizations to establish additional domains where necessary, provided that those domains remain consistent with the framework's principles and architecture. *** ## 12. Roles and Accountability Effective AI governance requires clearly defined responsibilities and decision-making authority. AIGO establishes a role-based approach to AI governance so that organizations can assign appropriate accountability across business, technical, operational, risk, security, privacy, legal, and assurance functions. Organizations may adapt role names and organizational structures according to their size and operating model. ### 12.1 Executive Leadership Executive leadership provides organizational direction, resources, oversight, and accountability for the organization's AI governance capability. Responsibilities may include: * establishing AI governance expectations; * approving organizational AI strategy; * ensuring appropriate resources; * reviewing significant AI risks; * establishing accountability; * supporting governance culture; and * overseeing significant governance issues. ### 12.2 AI Governance Function The AI Governance Function coordinates and maintains the organization's AI governance framework. Responsibilities may include: * maintaining AI governance policies; * coordinating governance processes; * maintaining the AI governance framework; * coordinating risk and compliance activities; * monitoring governance performance; * maintaining governance records; * coordinating assessments; * supporting training and awareness; and * reporting governance matters to appropriate management. The AI Governance Function may be a dedicated department, committee, distributed responsibility, or another organizational structure appropriate to the organization. ### 12.3 AI System Owner The AI System Owner is accountable for the governance and appropriate operation of an individual AI system or defined group of AI systems. Responsibilities may include: * defining the intended purpose; * maintaining system registration; * ensuring appropriate assessment; * ensuring required controls are implemented; * coordinating lifecycle activities; * managing changes; * monitoring system performance; * coordinating incidents; * maintaining documentation; and * ensuring appropriate review and retirement. ### 12.4 Business Owner The Business Owner is responsible for the business purpose, expected outcomes, and operational context of an AI system. Responsibilities may include: * defining business requirements; * confirming intended use; * identifying affected stakeholders; * evaluating business impact; * approving business use; * participating in risk decisions; and * reviewing whether the system continues to provide appropriate business value. ### 12.5 Technical Owner The Technical Owner is responsible for the technical implementation and operational integrity of an AI system. Responsibilities may include: * architecture; * technical implementation; * integrations; * infrastructure; * configuration; * technical controls; * system performance; * technical testing; * deployment; * maintenance; and * technical change management. ### 12.6 AI Developer or Engineering Team AI developers and engineering teams are responsible for implementing AI systems according to approved requirements, architecture, controls, and organizational procedures. Responsibilities may include: * implementation; * testing; * configuration; * documentation; * secure development; * technical evaluation; * remediation of identified issues; and * implementation of approved changes. ### 12.7 AI Operator The AI Operator is responsible for the day-to-day operation and monitoring of an AI system where such a role is applicable. Responsibilities may include: * operational monitoring; * responding to alerts; * managing operational procedures; * identifying incidents; * escalating issues; * maintaining operational records; and * supporting continuity and recovery activities. ### 12.8 Risk Function The Risk Function provides independent or supporting risk management capabilities according to the organization's governance model. Responsibilities may include: * risk methodology; * risk assessment support; * risk aggregation; * risk reporting; * risk monitoring; * challenge and review; and * support for risk acceptance processes. ### 12.9 Information Security Function The Information Security Function provides security expertise and oversight for AI systems. Responsibilities may include: * security assessment; * security requirements; * threat assessment; * access control requirements; * security monitoring; * incident response; * security testing; and * security risk management. ### 12.10 Privacy and Data Protection Function Where applicable, the Privacy or Data Protection Function provides expertise and oversight relating to privacy and data protection. Responsibilities may include: * privacy assessments; * data protection requirements; * privacy risk assessment; * data handling guidance; * privacy controls; * regulatory coordination; and * privacy incident support. ### 12.11 Legal and Compliance Function The Legal and Compliance Function supports identification and interpretation of applicable legal, regulatory, contractual, and organizational requirements. Responsibilities may include: * legal and regulatory analysis; * contractual requirements; * compliance interpretation; * regulatory monitoring; * compliance guidance; and * escalation of legal or regulatory concerns. AIGO does not replace legal advice or determine legal compliance. ### 12.12 Procurement and Vendor Management Procurement and Vendor Management functions support governance of third-party AI systems, services, models, platforms, and vendors. Responsibilities may include: * vendor assessment; * contractual requirements; * supplier due diligence; * service requirements; * vendor monitoring; * change notification requirements; and * exit or replacement planning. ### 12.13 Internal Audit and Assurance Internal Audit or Assurance functions may provide independent evaluation of AI governance where appropriate. Responsibilities may include: * reviewing governance effectiveness; * evaluating controls; * assessing evidence; * identifying gaps; * reporting findings; and * monitoring remediation. The precise independence requirements should follow the organization's existing audit and assurance model. ### 12.14 AI Users AI Users are individuals who interact with or use AI systems as part of their work or other authorized activities. Responsibilities may include: * following approved procedures; * using AI systems only for authorized purposes; * protecting confidential information; * identifying unexpected or harmful behavior; * reporting incidents; * maintaining appropriate human judgment; and * completing required training. ### 12.15 AI Governance Committee Organizations may establish an AI Governance Committee or equivalent decision-making body. Depending on organizational structure, the committee may include representatives from: * executive leadership; * business; * technology; * AI engineering; * security; * privacy; * legal; * risk; * compliance; * procurement; and * internal audit or assurance. The committee may be responsible for significant governance decisions, risk escalation, policy approval, prioritization, and organizational oversight. ### 12.16 Shared Accountability AI governance should not depend on a single individual or department. Responsibilities may be distributed across multiple roles, but the organization should maintain clear accountability for: * business purpose; * system ownership; * risk decisions; * technical operation; * security; * privacy; * compliance; * human oversight; * incident management; and * governance effectiveness. ### 12.17 Responsibility Assignment Organizations should define responsibility assignments for relevant AI governance activities. AIGO may use responsibility-assignment mechanisms such as RACI or equivalent organizational methods. A responsibility assignment should identify, where applicable: * who performs the activity; * who is accountable for the outcome; * who must be consulted; and * who should be informed. ### 12.18 Role Separation Organizations should consider appropriate separation of duties for activities where independence or conflict-of-interest considerations are relevant. For example, the individual responsible for developing an AI system may not always be the appropriate individual to provide independent approval or assurance of that same system. Role separation should be proportionate to organizational size, risk, and available resources. ### 12.19 Accountability for Autonomous AI Where an AI system can independently perform actions, make decisions, use tools, or execute workflows, organizations should define explicit human and organizational accountability for the system's authority and operation. Autonomy does not remove the need for organizational accountability. Organizations should define: * authorized actions; * authority boundaries; * responsible owners; * escalation mechanisms; * human intervention requirements; * monitoring responsibilities; and * emergency intervention or shutdown procedures where applicable. *** ## 13. Risk-Based Approach AIGO adopts a risk-based approach to AI governance. Organizations should determine the level and type of governance required for an AI system based on its characteristics, intended purpose, potential impact, operating environment, and associated risks. AIGO does not assume that every AI system presents the same level of risk or requires the same governance controls. ### 13.1 Risk-Based Governance Governance activities should be proportionate to the potential risk and impact of an AI system. Organizations should consider factors including: * intended purpose; * type of AI system; * level of autonomy; * decision-making authority; * affected individuals or groups; * sensitivity of processed data; * scale of use; * business criticality; * potential financial impact; * potential security impact; * potential privacy impact; * potential safety impact; * potential societal impact; * regulatory environment; * third-party dependencies; * technical complexity; * integration with external systems; and * ability to intervene or override the system. ### 13.2 Risk Identification Organizations should identify reasonably foreseeable risks associated with an AI system. Risk identification may consider: * technical risks; * operational risks; * security risks; * privacy risks; * data risks; * legal and regulatory risks; * financial risks; * reputational risks; * ethical risks; * safety risks; * human factors; * third-party risks; * model risks; * automation risks; and * misuse or abuse scenarios. Risk identification should be performed during relevant lifecycle stages and updated when material changes occur. ### 13.3 Risk Assessment Identified risks should be assessed using a defined organizational methodology. An assessment may consider: * likelihood; * potential impact; * exposure; * existing controls; * detectability; * affected stakeholders; * duration of impact; and * other relevant organizational factors. Organizations should establish consistent criteria for determining risk levels. ### 13.4 Risk Classification Organizations may classify AI systems according to their overall risk profile. AIGO may support multiple classification approaches, including qualitative or quantitative methods. A conceptual classification may include: * **Low Risk** * **Moderate Risk** * **High Risk** * **Critical Risk** The final AIGO risk classification model will be defined through the dedicated Risk framework. Risk classification should not be interpreted as a universal legal classification. Organizations should separately determine any classifications required by applicable laws or regulations. ### 13.5 Risk Treatment Organizations should determine appropriate actions for identified risks. Risk treatment options may include: * mitigation; * reduction; * avoidance; * transfer or allocation; * acceptance; and * discontinuation of the relevant activity. Risk treatment decisions should consider the organization's risk appetite and applicable requirements. ### 13.6 Risk Acceptance Organizations should define who has authority to accept residual AI risk. Risk acceptance should: * be explicitly documented; * identify the relevant risk; * identify existing controls; * identify residual risk; * identify the authorized decision-maker; * include an appropriate validity period where applicable; and * be reviewed when circumstances materially change. High or critical risks may require higher levels of authorization. ### 13.7 Residual Risk Residual risk is the risk remaining after implemented controls and mitigation activities have been considered. Organizations should determine whether residual risk is acceptable before approving or continuing the operation of an AI system. Residual risk should be monitored throughout the lifecycle. ### 13.8 Risk Ownership Each material AI risk should have an identifiable risk owner or responsible organizational function. Risk ownership should be distinguishable from technical responsibility where appropriate. The risk owner should have sufficient authority to make or escalate relevant risk decisions. ### 13.9 Risk Register Organizations should maintain an appropriate record of identified AI risks. An AI risk register may contain: * risk identifier; * AI system; * risk description; * affected area; * risk category; * likelihood; * impact; * inherent risk; * existing controls; * residual risk; * treatment plan; * risk owner; * acceptance authority; * status; * review date; and * supporting evidence. ### 13.10 Risk Triggers Organizations should define circumstances that may require a new or updated risk assessment. Triggers may include: * significant system changes; * model changes; * changes in intended purpose; * changes in data sources; * changes in users; * increased system autonomy; * new integrations; * new tools or permissions; * security incidents; * privacy incidents; * significant model behavior changes; * regulatory changes; * new identified vulnerabilities; * material performance degradation; and * significant changes in operational context. ### 13.11 AI Agent and Autonomy Risk AI systems capable of independently executing actions require specific consideration of autonomy-related risks. Organizations should evaluate: * actions the system can perform; * tools the system can access; * permissions granted to the system; * systems it can interact with; * financial or operational authority; * ability to create cascading actions; * ability to modify its environment; * human intervention mechanisms; * execution limits; and * emergency controls. Higher levels of autonomy may require stronger governance, testing, monitoring, authorization, and intervention mechanisms. ### 13.12 Risk Across the Lifecycle Risk assessment should not be limited to the initial deployment decision. Risk should be considered throughout: Ideation ↓ Assessment ↓ Design ↓ Development / Acquisition ↓ Validation ↓ Approval ↓ Deployment ↓ Operation ↓ Monitoring ↓ Change / Incident ↓ Reassessment ### 13.13 Risk-Based Control Selection Controls should be selected according to the risks and governance requirements identified for the AI system. Not every control will necessarily apply to every AI system. Organizations should document: * applicable controls; * non-applicable controls where relevant; * rationale for exclusions; * implementation status; * control owner; and * supporting evidence. ### 13.14 Risk Escalation Organizations should define escalation mechanisms for risks that exceed established thresholds or cannot be adequately mitigated. Escalation may involve: * AI governance leadership; * executive management; * risk management; * security; * privacy; * legal; * compliance; * business leadership; or * other authorized governance bodies. ### 13.15 Risk Monitoring AI risks should be monitored throughout the lifecycle. Monitoring should consider changes in: * system behavior; * data; * models; * usage; * users; * threats; * vulnerabilities; * business context; * regulatory requirements; and * organizational risk appetite. ### 13.16 Proportionality The depth and frequency of risk management activities should be proportionate to the characteristics and potential impact of the AI system. A low-impact internal productivity assistant may require a simpler assessment than an autonomous AI system capable of making material business decisions or executing high-impact actions. AIGO should therefore support scalable risk governance rather than a single mandatory process for every AI implementation. *** ## 14. Control Model AIGO uses a control-based approach to translate governance objectives and identified risks into actionable organizational requirements. Controls provide a structured mechanism through which an organization can establish, implement, operate, monitor, and improve AI governance practices. Controls should be applied proportionately according to the organization's context, AI system characteristics, risk profile, and applicable requirements. ### 14.1 Purpose of Controls AIGO controls are intended to help organizations: * address identified AI risks; * achieve governance objectives; * establish consistent practices; * assign responsibilities; * provide measurable governance requirements; * support assessments; * generate appropriate evidence; and * enable continuous improvement. ### 14.2 Control Structure Each AIGO control should have a unique identifier and a defined structure. A control may include: * control identifier; * control title; * control objective; * control requirement; * rationale; * applicable governance domain; * applicable lifecycle stage; * applicable risk categories; * responsible role; * supporting roles; * implementation guidance; * required or recommended evidence; * applicability criteria; * maturity considerations; and * related controls. The final control schema will be defined within the AIGO Controls framework. ### 14.3 Control Identifier Each control should have a stable and unique identifier. A conceptual identifier may follow a structure such as: ```text theme={null} 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.** --- ```