> ## 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 AI Governance Controls v0.1

# AIGO — AI Governance Operating Framework

## AI Governance Controls

**Version:** 0.1\
**Status:** Draft\
**Working Name:** AIGO\
**Full Name:** AI Governance Operating Framework

***

### 1. Purpose

The AIGO AI Governance Controls model defines a structured set of governance controls that organizations may use to manage risks associated with artificial intelligence.

Controls translate governance requirements, risk treatments, principles, and organizational expectations into defined activities that can be implemented, operated, monitored, and evidenced.

The AIGO control model is designed to remain technology-neutral and adaptable to different organizational environments, AI system types, risk profiles, and implementation approaches.

***

### 2. Control Principles

AIGO controls should be designed and operated according to the following principles:

* controls should address identified risks or governance requirements;
* controls should have clearly defined ownership;
* controls should be appropriately designed for their intended purpose;
* controls should be implemented before they are considered operational;
* control operation should produce appropriate evidence;
* control effectiveness should be periodically evaluated;
* controls should be proportionate to risk;
* controls should be traceable to applicable requirements;
* material control deficiencies should be addressed; and
* controls should be continuously improved where appropriate.

***

### 3. Control Model

The AIGO control model provides a common structure for defining and managing AI governance controls.

Each control should identify, where applicable:

* control identifier;
* control name;
* control objective;
* control description;
* control type;
* applicability;
* responsible role;
* accountable role;
* implementation guidance;
* evidence requirements;
* monitoring requirements;
* related risks;
* related lifecycle stages;
* related governance domains; and
* related AI System Profiles.

***

### 4. Control Objectives

Control objectives define the governance outcome that a control is intended to achieve.

A control objective should describe the desired state without unnecessarily prescribing a particular technical implementation.

Control objectives should be:

* clear;
* understandable;
* relevant;
* measurable where practical;
* risk-informed; and
* sufficiently stable to support long-term framework use.

***

### 5. Control Types

AIGO controls may be categorized according to their primary purpose.

Control types may include:

1. Preventive controls
2. Detective controls
3. Corrective controls
4. Directive controls
5. Compensating controls
6. Monitoring controls
7. Assurance controls

A control may have characteristics of more than one type.

***

### 6. Preventive Controls

Preventive controls are designed to reduce the likelihood that an undesirable event, condition, or behavior will occur.

Examples may include:

* access restrictions;
* approval requirements;
* segregation of duties;
* data restrictions;
* deployment gates;
* authorization requirements;
* system configuration controls; and
* prohibited-use restrictions.

Preventive controls should be implemented where prevention is practical and proportionate to risk.

***

### 7. Detective Controls

Detective controls are designed to identify events, conditions, failures, or deviations after or while they occur.

Examples may include:

* monitoring;
* logging;
* alerts;
* periodic reviews;
* anomaly detection;
* output sampling;
* control testing; and
* audit activities.

Detective controls should provide sufficient information to support timely response where appropriate.

***

### 8. Corrective Controls

Corrective controls are designed to address identified failures, incidents, deficiencies, or deviations.

Examples may include:

* remediation;
* system rollback;
* configuration changes;
* access removal;
* corrective training;
* incident response;
* model replacement; and
* process improvement.

Corrective controls should be linked to appropriate escalation and incident-management processes.

***

### 9. Directive Controls

Directive controls establish required behavior, expectations, policies, standards, or procedures.

Examples may include:

* AI governance policies;
* acceptable-use requirements;
* development standards;
* governance procedures;
* mandatory training;
* approval requirements; and
* organizational rules.

Directive controls establish expectations that other controls may support.

***

### 10. Compensating Controls

Compensating controls may be used when a primary control cannot be implemented or is insufficient.

A compensating control should provide a reasonable alternative means of achieving the intended governance objective.

The organization should document:

* the original control;
* the reason it cannot be fully applied;
* the compensating control;
* associated risks;
* control owner;
* approval; and
* review requirements.

***

### 11. Control Lifecycle

AIGO controls should be managed through a defined lifecycle.

The control lifecycle may include:

1. Control identification
2. Control design
3. Control approval
4. Control implementation
5. Control operation
6. Control monitoring
7. Control testing
8. Control remediation
9. Control review
10. Control retirement

Controls should remain subject to governance throughout their lifecycle.

***

### 12. Control Identification

Control identification determines whether a governance requirement or risk requires a defined control.

Controls may be derived from:

* AIGO principles;
* governance domains;
* identified risks;
* lifecycle requirements;
* organizational policies;
* legal or regulatory requirements;
* contractual requirements;
* industry standards;
* incidents;
* audit findings; and
* organizational objectives.

***

### 13. Control Design

Control design should define how the control is intended to achieve its objective.

Control design should consider:

* risk addressed;
* objective;
* applicability;
* responsible role;
* frequency;
* execution method;
* dependencies;
* evidence;
* monitoring;
* exceptions; and
* escalation.

Controls should be designed so that their effectiveness can reasonably be evaluated.

***

### 14. Control Implementation

A control should not be considered implemented merely because it has been documented.

Implementation should establish the people, processes, technologies, procedures, or other mechanisms necessary for the control to operate.

Implementation evidence may include:

* approved procedures;
* system configurations;
* assigned responsibilities;
* training records;
* workflow configuration;
* technical implementation;
* operational records; and
* other appropriate evidence.

***

### 15. Control Operation

A control is operational when it is being performed or enforced according to its defined requirements.

Control operation may be:

* manual;
* automated;
* semi-automated;
* preventive;
* detective;
* continuous; or
* periodic.

The operating method should be appropriate to the control objective and associated risk.

***

### 16. Control Evidence

Controls should generate sufficient evidence to demonstrate that they are operating as intended.

Evidence may include:

* approvals;
* logs;
* reports;
* assessment records;
* test results;
* configuration records;
* monitoring records;
* meeting records;
* training records;
* tickets;
* workflow records; and
* audit records.

Evidence requirements should be proportionate to risk and control importance.

***

### 17. Control Ownership

Each material control should have an identified control owner.

The control owner should be responsible for ensuring that:

* the control remains appropriately designed;
* implementation remains effective;
* required activities are performed;
* evidence is maintained;
* deficiencies are addressed; and
* the control is reviewed when circumstances change.

Control ownership should be clearly distinguished from overall AI system ownership where appropriate.

***

### 18. Control Accountability

Control accountability establishes who is ultimately accountable for the effectiveness of a control.

Accountability should be assigned to an appropriately authorized organizational role.

A control may have:

* one accountable role;
* one or more responsible roles;
* consulted stakeholders; and
* informed stakeholders.

Organizations may use a RACI or equivalent accountability model.

***

### 19. Control Applicability

Not every control will apply equally to every AI system.

Control applicability should be determined according to:

* AI system type;
* intended purpose;
* risk;
* governance classification;
* lifecycle stage;
* regulatory requirements;
* organizational context;
* AI System Profile; and
* other relevant factors.

Where a control is determined not to apply, the decision should be documented where appropriate.

***

### 20. Control Baselines

Organizations may establish control baselines for different categories of AI systems.

A control baseline may define a minimum set of controls applicable to:

* all AI systems;
* standard-risk systems;
* elevated-risk systems;
* high-risk systems;
* critical systems;
* specific AI System Profiles; or
* particular business environments.

Baselines may be supplemented with additional controls according to risk.

***

### 21. Control Selection

Control selection should be risk-based.

Organizations should consider:

* identified risks;
* risk severity;
* risk tolerance;
* governance requirements;
* system characteristics;
* existing controls;
* control effectiveness;
* implementation feasibility; and
* potential unintended consequences.

Control selection should avoid unnecessary duplication where equivalent controls already exist.

***

### 22. Control Mapping

AIGO controls should be capable of being mapped to other AIGO framework components.

Mappings may include:

* principles;
* governance domains;
* lifecycle stages;
* risks;
* roles;
* AI System Profiles;
* maturity requirements;
* evidence requirements; and
* external standards or regulations.

Control mapping supports traceability and framework interoperability.

***

### 23. Control and Risk Traceability

Organizations should maintain traceability between material risks and applicable controls.

A representative relationship is:

**Risk → Control Objective → Control → Evidence → Control Result → Residual Risk**

Traceability should support:

* risk treatment;
* accountability;
* assurance;
* auditability;
* control testing; and
* continuous improvement.

***

### 24. Control and Lifecycle Traceability

Controls may apply at one or more AI lifecycle stages.

Relevant lifecycle stages may include:

* initiation;
* assessment;
* concept definition;
* classification;
* risk assessment;
* design;
* development;
* testing;
* approval;
* deployment;
* operation;
* monitoring;
* change;
* incident management;
* periodic review; and
* retirement.

Organizations should identify lifecycle applicability for material controls.

***

### 25. Control and Governance Domain Traceability

Controls should be associated with the governance domains they support.

A control may support:

* one governance domain;
* multiple governance domains; or
* cross-domain governance objectives.

Domain relationships should be documented where they provide useful traceability.

***

### 26. Control and Role Traceability

Controls should identify the roles responsible for their implementation and operation.

Role relationships may include:

* accountable role;
* control owner;
* responsible role;
* reviewer;
* approver;
* specialist advisor; and
* assurance role.

Roles should be defined consistently with the AIGO Governance Roles model.

***

### 27. Control Frequency

Control frequency should be defined according to the control objective and associated risk.

Frequency may be:

* continuous;
* real-time;
* event-driven;
* daily;
* weekly;
* monthly;
* quarterly;
* annually; or
* as required.

Higher-risk controls may require more frequent operation or monitoring.

***

### 28. Control Automation

Controls may be implemented using:

* manual processes;
* automated processes;
* semi-automated processes;
* technical enforcement;
* workflow systems; or
* combinations of these approaches.

Automation should not be assumed to guarantee control effectiveness.

Automated controls should themselves be appropriately tested, monitored, and maintained.

***

### 29. Control Testing

Controls should be tested where appropriate to determine whether they are designed and operating effectively.

Testing may evaluate:

* design effectiveness;
* implementation;
* operating effectiveness;
* evidence;
* frequency;
* consistency;
* exceptions; and
* deficiencies.

Testing frequency should be proportionate to risk and control importance.

***

### 30. Control Effectiveness

Control effectiveness should consider whether the control:

* is appropriately designed;
* is implemented;
* operates as intended;
* addresses the relevant risk;
* produces appropriate evidence; and
* remains effective over time.

Organizations may define control effectiveness ratings such as:

1. Effective
2. Partially Effective
3. Ineffective
4. Not Tested

Alternative rating models may be used where appropriate.

***

### 31. Control Deficiencies

A control deficiency exists when a control is:

* absent;
* inadequately designed;
* not implemented;
* not operating;
* inconsistently applied;
* insufficiently evidenced; or
* otherwise unable to achieve its intended objective.

Material deficiencies should be risk assessed and addressed according to organizational requirements.

***

### 32. Control Remediation

Control remediation should address identified deficiencies.

Remediation activities may include:

* redesign;
* implementation;
* configuration changes;
* additional procedures;
* additional training;
* ownership clarification;
* increased monitoring;
* technical improvements; or
* replacement of the control.

Remediation should have appropriate ownership and target dates.

***

### 33. Control Exceptions

Organizations may permit controlled exceptions to specific control requirements.

An exception should:

* identify the affected control;
* document the reason;
* assess associated risk;
* identify compensating controls where appropriate;
* identify an authorized approver;
* define applicable conditions; and
* establish a review or expiration date where appropriate.

Exceptions should be monitored and should not become permanent substitutes for required controls without appropriate authorization.

***

### 34. Control Escalation

Control deficiencies or failures should be escalated when they exceed defined thresholds.

Escalation may be required when:

* a material control fails;
* residual risk exceeds tolerance;
* remediation is overdue;
* repeated failures occur;
* evidence is unavailable;
* control ownership is unclear; or
* significant impact may result.

Escalation should follow applicable organizational governance procedures.

***

### 35. Control Monitoring

Organizations should monitor control operation and effectiveness.

Monitoring may include:

* control performance indicators;
* exception rates;
* testing results;
* failed controls;
* overdue remediation;
* evidence completeness;
* incident correlation; and
* trend analysis.

Monitoring should be proportionate to control importance and risk.

***

### 36. Control Metrics

Organizations may establish metrics for control performance.

Metrics may include:

* control completion rate;
* control failure rate;
* overdue control activities;
* remediation duration;
* evidence completeness;
* testing coverage;
* exception frequency; and
* repeated control deficiencies.

Metrics should be interpreted within the relevant organizational and risk context.

***

### 37. Control Evidence Retention

Control evidence should be retained according to applicable requirements.

Retention should consider:

* control importance;
* risk;
* legal requirements;
* regulatory requirements;
* contractual requirements;
* audit requirements;
* privacy; and
* security.

Evidence should be protected against unauthorized alteration, loss, or disclosure.

***

### 38. Control Review

Controls should be reviewed periodically and when material changes occur.

Review triggers may include:

* changes in AI system characteristics;
* new risks;
* incidents;
* changes in regulations;
* changes in organizational policy;
* control failures;
* changes in technology;
* changes in lifecycle requirements; and
* audit findings.

The review should determine whether the control remains necessary, appropriate, and effective.

***

### 39. Control Retirement

Controls may be retired when they are no longer necessary or have been replaced by equivalent or more effective mechanisms.

Control retirement should consider:

* associated risks;
* replacement controls;
* dependencies;
* evidence;
* historical requirements;
* ongoing obligations; and
* impact on the control environment.

Retirement decisions should be documented where material.

***

### 40. Control Change Management

Changes to material controls should be governed through an appropriate change process.

Changes may include:

* control objective changes;
* control description changes;
* ownership changes;
* frequency changes;
* applicability changes;
* implementation changes;
* evidence changes; and
* retirement.

Material control changes should be assessed for their potential impact on risk.

***

### 41. Control Documentation

Each material control should have sufficient documentation to allow authorized stakeholders to understand:

* why the control exists;
* what risk or requirement it addresses;
* what the control requires;
* who is responsible;
* how often it operates;
* what evidence is produced;
* how effectiveness is assessed; and
* what happens when the control fails.

***

### 42. Control Identifiers

AIGO controls should use stable, unique identifiers.

A representative identifier structure is:

`AIGO-CTL-001`

Identifiers should remain stable across framework versions where the underlying control remains substantively the same.

New controls should receive new identifiers where appropriate.

Retired identifiers should not be casually reassigned to unrelated controls.

***

### 43. Control Versioning

Control definitions should be versioned when material changes are made.

Version changes may reflect:

* clarification;
* expansion;
* restriction;
* ownership changes;
* applicability changes;
* evidence changes;
* control objective changes; or
* substantive redesign.

Versioning should support historical traceability.

***

### 44. Control Status

Controls may have statuses such as:

* Draft;
* Proposed;
* Approved;
* Active;
* Under Review;
* Suspended;
* Deprecated; or
* Retired.

The status should clearly indicate whether a control is currently applicable within the framework.

***

### 45. Control Catalog

AIGO may maintain a structured control catalog containing all defined controls.

The catalog should support:

* control identification;
* control descriptions;
* objectives;
* applicability;
* ownership;
* risk mapping;
* lifecycle mapping;
* domain mapping;
* evidence requirements;
* testing requirements; and
* status.

The control catalog may be maintained in Markdown, structured data, or another appropriate format.

***

### 46. Control Families

Controls may be grouped into control families according to common governance objectives.

Potential control families may include:

* governance and accountability;
* AI inventory;
* risk management;
* data governance;
* security;
* privacy;
* human oversight;
* transparency;
* model governance;
* testing and validation;
* monitoring;
* incident management;
* third-party governance;
* change management; and
* assurance.

Control families may be expanded as the framework develops.

***

### 47. Minimum Control Set

AIGO may define a minimum set of controls applicable to AI systems within its governance scope.

The minimum control set should establish foundational governance expectations.

Depending on system characteristics, additional controls may be required.

The minimum control set should not be interpreted as sufficient for every AI system or risk scenario.

***

### 48. Enhanced Control Sets

Organizations may establish enhanced control sets for systems with increased risk or complexity.

Enhanced controls may address:

* high-impact use;
* autonomous behavior;
* sensitive data;
* critical business processes;
* external-facing systems;
* safety considerations;
* regulatory requirements; or
* significant stakeholder impact.

Enhanced requirements should be selected according to risk rather than applied solely because a system uses a particular technology.

***

### 49. Control Tailoring

Organizations may tailor controls according to:

* risk;
* system type;
* lifecycle stage;
* organizational context;
* regulatory requirements;
* AI System Profile;
* implementation environment; and
* available safeguards.

Tailoring should preserve the intended governance outcome of the control.

Where a control is modified or replaced, the organization should document the rationale and resulting risk where appropriate.

***

### 50. Control Equivalence

Organizations may use existing organizational controls where those controls achieve equivalent governance outcomes.

Examples may include controls from:

* information security;
* privacy;
* enterprise risk management;
* software development;
* procurement;
* internal audit;
* business continuity; or
* quality management.

AIGO does not require duplicate controls where equivalent controls already exist.

***

### 51. Control Integration

AIGO controls should integrate with existing organizational processes where practical.

Integration may include:

* policy management;
* risk management;
* change management;
* software development;
* procurement;
* security operations;
* privacy management;
* audit;
* compliance; and
* business operations.

Integration should reduce unnecessary duplication while preserving governance effectiveness.

***

### 52. Control Assurance

Organizations should establish appropriate assurance activities for material controls.

Assurance may include:

* self-assessment;
* management review;
* independent review;
* internal audit;
* external assessment;
* technical testing; and
* automated assurance mechanisms.

The level of assurance should be proportionate to risk.

***

### 53. Control Continuous Improvement

The control environment should be continuously improved using information from:

* incidents;
* risk assessments;
* control testing;
* audits;
* monitoring;
* stakeholder feedback;
* regulatory developments;
* technology changes;
* lessons learned; and
* governance reviews.

Control improvements should be documented and incorporated into relevant framework processes.

***

### 54. Control Traceability Model

AIGO controls should support traceability across the framework.

A representative relationship is:

**Principle → Domain → Risk → Control Objective → Control → Role → Lifecycle Stage → Evidence → Assurance Result**

This relationship supports:

* governance transparency;
* accountability;
* auditability;
* risk management;
* assurance; and
* framework maintenance.

***

### 55. Control and External Requirements

AIGO controls may be mapped to applicable external requirements.

Mappings may include:

* laws;
* regulations;
* standards;
* contractual requirements;
* customer requirements; and
* industry frameworks.

External mappings should be maintained separately from the core control definition where practical.

***

### 56. Control and AI System Profiles

AI System Profiles may identify controls that are particularly relevant to specific AI system types.

Profiles may specify:

* required controls;
* recommended controls;
* conditional controls;
* prohibited configurations;
* additional evidence;
* additional monitoring; and
* enhanced assurance.

The applicability of a control should ultimately be determined according to the actual characteristics and risk of the AI system.

***

### 57. Control and Maturity Model

The AIGO maturity model may evaluate the organization's capability to establish, operate, monitor, and improve controls.

Maturity considerations may include:

* control definition;
* ownership;
* implementation;
* consistency;
* automation;
* evidence;
* monitoring;
* testing;
* assurance; and
* continuous improvement.

Maturity should reflect actual capability rather than documentation alone.

***

### 58. Control Implementation Guidance

Implementation guidance may be provided separately from the normative control definition.

Guidance may describe:

* practical implementation approaches;
* examples;
* recommended procedures;
* technical considerations;
* evidence examples;
* implementation patterns; and
* common pitfalls.

Guidance should remain adaptable and should not unnecessarily constrain implementation technology.

***

### 59. Control Evidence Requirements

Each control should define evidence requirements appropriate to its importance and risk.

Evidence may demonstrate:

* implementation;
* operation;
* review;
* testing;
* approval;
* exception handling; and
* remediation.

Evidence requirements should avoid unnecessary administrative burden while supporting meaningful assurance.

***

### 60. Control Governance

The AIGO control catalog should be governed through defined processes for:

* control creation;
* review;
* approval;
* modification;
* versioning;
* mapping;
* deprecation; and
* retirement.

Changes to foundational controls should be subject to appropriate framework governance.

***

### 61. Control Change Proposals

Organizations or framework contributors may propose new or modified controls.

A control change proposal should provide sufficient information to evaluate:

* purpose;
* risk addressed;
* control objective;
* proposed control;
* applicability;
* implementation considerations;
* evidence;
* related controls;
* potential duplication; and
* impact on existing mappings.

***

### 62. Control Duplication

Before introducing a new control, organizations should determine whether an existing control already addresses the same or substantially similar governance objective.

Where equivalent coverage exists, organizations should prefer:

* reuse;
* clarification;
* extension; or
* mapping

rather than unnecessary duplication.

***

### 63. Control Dependencies

Some controls may depend on other controls or organizational capabilities.

Dependencies may include:

* identity management;
* asset inventory;
* data governance;
* risk assessment;
* logging;
* monitoring;
* incident management; or
* organizational approval processes.

Material dependencies should be identified where they affect control effectiveness.

***

### 64. Control Conflicts

Controls should be reviewed for potential conflicts or contradictory requirements.

Where controls conflict, the organization should determine:

* applicable priority;
* governing requirement;
* risk implications;
* compensating measures; and
* appropriate approval.

Conflicts should be resolved through documented governance processes.

***

### 65. Control Applicability Decisions

Where applicability is conditional, organizations should document the basis for the decision where appropriate.

An applicability decision may identify:

* control identifier;
* AI system;
* applicability determination;
* rationale;
* assessor;
* date;
* evidence; and
* review date.

Applicability decisions should be revisited when relevant system characteristics change.

***

### 66. Control Exceptions and Compensating Measures

Where a required control cannot be implemented as designed, organizations should determine whether an alternative control or compensating measure can achieve an equivalent governance outcome.

The decision should consider:

* original control objective;
* residual risk;
* compensating control;
* effectiveness;
* approval;
* monitoring; and
* expiration or review.

***

### 67. Control Failure Management

Control failures should be recorded and managed according to their significance.

Failure management may include:

1. Identify the failure.
2. Assess its significance.
3. Determine affected risks.
4. Implement immediate containment where necessary.
5. Define remediation.
6. Assign ownership.
7. Establish a target date.
8. Verify remediation.
9. Update risk information where necessary.

Material repeated failures should trigger review of control design and effectiveness.

***

### 68. Control Reporting

Organizations may establish control reporting appropriate to their governance needs.

Reporting may include:

* control status;
* control effectiveness;
* deficiencies;
* exceptions;
* remediation;
* overdue actions;
* testing coverage;
* evidence completeness; and
* trends.

Reports should provide useful information for governance decision-making.

***

### 69. Control Review Frequency

Control review frequency should be determined according to:

* control importance;
* risk;
* rate of change;
* regulatory requirements;
* incident history;
* control performance; and
* organizational policy.

Higher-risk controls may require more frequent review.

***

### 70. Control Retirement and Historical Traceability

Retired controls should remain identifiable in historical records where appropriate.

Retirement should not remove the ability to determine:

* what the control required;
* when it was active;
* why it was retired;
* what replaced it; and
* what risks or requirements it previously addressed.

Historical traceability supports assurance and framework evolution.

***

### 71. Control Catalog Maintenance

The AIGO control catalog should be maintained so that users can determine the current status and definition of each control.

Catalog maintenance should include:

* identifier management;
* version management;
* status management;
* ownership;
* mappings;
* applicability;
* change history; and
* retirement information.

***

### 72. Document Status

**Document:** AIGO AI Governance Controls

**Version:** 0.1

**Status:** Draft

**Working Name:** AIGO

**Full Name:** AI Governance Operating Framework

**Document Type:** AI Governance Controls

**Identifier Prefix:** `AIGO-CTL`

This document defines the foundational AI governance control model for the AIGO framework.

Organizations may adapt the control model according to their organizational structure, AI systems, risk profile, regulatory environment, and governance maturity while maintaining appropriate accountability, risk treatment, control ownership, evidence, testing, monitoring, and assurance.