> ## 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.

# 01 AIGO Basic AI System Example v0.1

# AIGO — Basic AI System Example

## AIGO — AI Governance Operating Framework

**Version:** 0.1
**Status:** Draft
**Working Name:** AIGO
**Full Name:** AI Governance Operating Framework
**Document Identifier:** `AIGO-EXAMPLE-001`
**Document Type:** Implementation Example
**Example Type:** Basic AI System
**Related Framework:** AIGO AI Governance Operating Framework

***

## 1. Purpose

This document provides a complete example of how a basic AI system can be governed using the AIGO AI Governance Operating Framework.

The example is intended to demonstrate the practical application of:

* AI system registration;
* AI system identification;
* classification;
* risk assessment;
* control selection;
* approval;
* deployment;
* operation;
* monitoring;
* assurance;
* improvement;
* change management;
* continuation or retirement.

The example is illustrative and does not represent a mandatory implementation for every organization or AI system.

***

## 2. Example Organization

For this example, the organization is a fictional company named **ExampleCorp**.

ExampleCorp is a medium-sized organization that uses AI to improve internal business operations.

The organization has established an AIGO-based AI governance program covering AI systems used within the organization.

***

## 3. Example AI System

The example AI system is called **ExampleCorp Internal Knowledge Assistant**.

The system provides employees with an AI-powered interface for searching and summarizing internal organizational information.

### 3.1 System Purpose

The system is intended to:

* help employees locate internal information;
* summarize approved internal documents;
* answer questions about organizational procedures;
* provide references to source documents.

### 3.2 Intended Users

The intended users are:

* employees;
* approved contractors;
* authorized internal support personnel.

### 3.3 Intended Environment

The system operates within ExampleCorp's internal technology environment.

***

## 4. Example System Profile

| Field                  | Example                                    |
| ---------------------- | ------------------------------------------ |
| AI System ID           | `AI-EX-001`                                |
| System Name            | ExampleCorp Internal Knowledge Assistant   |
| Owner                  | Head of Internal Technology                |
| Business Owner         | Corporate Operations                       |
| Technical Owner        | AI Platform Team                           |
| Purpose                | Internal knowledge assistance              |
| Users                  | Employees and authorized contractors       |
| Lifecycle Stage        | Operational                                |
| Classification         | Standard                                   |
| Risk Level             | Moderate                                   |
| Status                 | Active                                     |
| Review Frequency       | Periodic                                   |
| Third-Party Components | AI model provider and cloud infrastructure |

***

## 5. Governance Context

The system is subject to AIGO governance because it:

* uses AI;
* processes organizational information;
* produces outputs used by employees;
* introduces potential reliability and confidentiality risks;
* depends on external technology components.

***

## 6. Governance Objective

The governance objective is to ensure that the AI system:

1. has an accountable owner;
2. has a documented purpose;
3. is appropriately classified;
4. has undergone risk assessment;
5. has appropriate controls;
6. is approved before operational use;
7. is monitored;
8. produces appropriate evidence;
9. is periodically assured;
10. is changed or retired through controlled processes.

***

# 7. AIGO Lifecycle Application

The system follows the AIGO lifecycle:

```text theme={null}
Govern
   ↓
Identify
   ↓
Classify
   ↓
Assess
   ↓
Treat
   ↓
Approve
   ↓
Deploy
   ↓
Operate
   ↓
Monitor
   ↓
Assure
   ↓
Improve
   ↓
Change / Continue / Retire
```

***

# 8. Stage 1 — Governance

The organization first establishes governance responsibility for the system.

### 8.1 Governance Decisions

ExampleCorp assigns:

* an executive sponsor;
* an AI system owner;
* a technical owner;
* a risk owner;
* control owners.

### 8.2 Governance Outcome

The system has a defined governance structure before implementation proceeds.

***

## 9. Governance Roles

| Role                    | Example Assignment                 |
| ----------------------- | ---------------------------------- |
| Executive Sponsor       | Chief Operating Officer            |
| AI Governance Authority | AI Governance Committee            |
| AI System Owner         | Head of Internal Technology        |
| Business Owner          | Corporate Operations               |
| Technical Owner         | AI Platform Team                   |
| Risk Owner              | Enterprise Risk Manager            |
| Security Owner          | Chief Information Security Officer |
| Privacy Owner           | Data Protection Officer            |
| Control Owners          | Relevant functional owners         |
| Assurance               | Internal Assurance Function        |

***

# 10. Stage 2 — Identify

The organization identifies the AI system and establishes its system profile.

### 10.1 Identification Activities

The organization records:

* system name;
* purpose;
* owner;
* users;
* technology;
* dependencies;
* data;
* lifecycle stage;
* third parties.

### 10.2 Identification Outcome

The system is entered into the organizational AI inventory.

***

# 11. Example AI Inventory Record

| Field             | Value                         |
| ----------------- | ----------------------------- |
| AI ID             | `AI-EX-001`                   |
| Name              | Internal Knowledge Assistant  |
| Owner             | Head of Internal Technology   |
| Purpose           | Internal knowledge assistance |
| Status            | Proposed                      |
| Lifecycle         | Development                   |
| Business Function | Corporate Operations          |
| AI Capability     | Generative AI / Retrieval     |
| External Provider | Yes                           |
| Data Sensitivity  | Internal                      |
| Initial Risk      | Moderate                      |

***

# 12. Stage 3 — Classify

ExampleCorp applies its AI classification procedure.

The classification considers:

* intended purpose;
* affected persons;
* business criticality;
* data sensitivity;
* autonomy;
* potential harm;
* regulatory exposure;
* operational impact.

***

# 13. Example Classification

The system is classified as:

**AIGO Classification: Standard AI System**

The classification is based on the system being:

* internally used;
* decision-supporting rather than decision-making;
* not directly determining employee rights;
* subject to human review;
* limited to internal organizational information.

***

# 14. Classification Decision

| Criterion             | Assessment |
| --------------------- | ---------- |
| External public use   | No         |
| Autonomous decisions  | No         |
| High-impact decisions | No         |
| Human oversight       | Yes        |
| Sensitive information | Limited    |
| Business criticality  | Moderate   |
| Potential harm        | Moderate   |
| Classification        | Standard   |

***

# 15. Stage 4 — Assess Risk

ExampleCorp performs an AI risk assessment.

The assessment identifies risks related to:

* inaccurate information;
* inappropriate recommendations;
* confidentiality;
* unauthorized access;
* hallucination;
* model dependency;
* supplier dependency;
* data leakage;
* inadequate monitoring.

***

# 16. Example Risk Register

| Risk ID | Risk                                | Likelihood | Impact | Rating |
| ------- | ----------------------------------- | ---------- | ------ | ------ |
| R-001   | Inaccurate response                 | Medium     | Medium | Medium |
| R-002   | Confidential information disclosure | Low        | High   | Medium |
| R-003   | Unauthorized access                 | Low        | High   | Medium |
| R-004   | Outdated information                | Medium     | Medium | Medium |
| R-005   | Supplier outage                     | Medium     | Medium | Medium |
| R-006   | Inappropriate user reliance         | Medium     | Medium | Medium |

***

# 17. Risk Treatment

ExampleCorp selects proportionate controls.

Treatment measures include:

* source citation;
* access control;
* data restrictions;
* human oversight;
* user guidance;
* monitoring;
* incident escalation;
* supplier management.

***

# 18. Risk Treatment Record

| Risk                 | Treatment                              | Owner           | Status      |
| -------------------- | -------------------------------------- | --------------- | ----------- |
| Inaccurate response  | Source citations and user verification | System Owner    | Open        |
| Data disclosure      | Access controls                        | Security Owner  | Implemented |
| Unauthorized access  | Identity controls                      | Security Owner  | Implemented |
| Outdated information | Content refresh process                | Business Owner  | Implemented |
| Supplier outage      | Service continuity plan                | Technical Owner | Implemented |
| User reliance        | User guidance                          | Business Owner  | Implemented |

***

# 19. Stage 5 — Select Controls

Controls are selected based on:

* identified risks;
* system classification;
* organizational requirements;
* lifecycle stage;
* applicable governance requirements.

***

# 20. Example Control Set

| Control ID | Control                  | Owner              |
| ---------- | ------------------------ | ------------------ |
| C-001      | AI system registration   | AI Governance      |
| C-002      | AI system classification | AI Governance      |
| C-003      | Risk assessment          | Risk Owner         |
| C-004      | Access control           | Security           |
| C-005      | Data protection          | Privacy / Security |
| C-006      | Human oversight          | Business Owner     |
| C-007      | Output monitoring        | System Owner       |
| C-008      | Incident management      | System Owner       |
| C-009      | Change management        | Technical Owner    |
| C-010      | Periodic assurance       | Assurance          |

***

# 21. Control Implementation

Each selected control is implemented through an applicable AIGO procedure.

```text theme={null}
Control
   ↓
Procedure
   ↓
Responsible Role
   ↓
Activity
   ↓
Evidence
   ↓
Assessment
```

***

# 22. Stage 6 — Control Assessment

Before approval, ExampleCorp verifies that required controls are implemented.

| Control           | Status   | Evidence              | Assessment |
| ----------------- | -------- | --------------------- | ---------- |
| Registration      | Complete | Inventory record      | Effective  |
| Classification    | Complete | Classification record | Effective  |
| Risk assessment   | Complete | Risk assessment       | Effective  |
| Access control    | Complete | Access configuration  | Effective  |
| Data protection   | Complete | Data controls         | Effective  |
| Human oversight   | Complete | Operating procedure   | Effective  |
| Monitoring        | Complete | Monitoring design     | Effective  |
| Incident process  | Complete | Incident procedure    | Effective  |
| Change management | Complete | Change procedure      | Effective  |
| Assurance         | Planned  | Assurance plan        | Pending    |

***

# 23. Stage 7 — Approval

The system requires approval before operational deployment.

Approval considers:

* classification;
* risk;
* controls;
* residual risk;
* evidence;
* readiness.

***

# 24. Approval Decision

ExampleCorp determines that:

* required controls are implemented;
* residual risk is acceptable;
* operational ownership is established;
* monitoring is ready;
* users have received appropriate guidance.

The AI Governance Authority approves the system for deployment.

***

# 25. Approval Record

| Field              | Example                      |
| ------------------ | ---------------------------- |
| AI System          | `AI-EX-001`                  |
| Decision           | Approved                     |
| Decision Authority | AI Governance Committee      |
| Decision Date      |                              |
| Residual Risk      | Moderate / Accepted          |
| Conditions         | Periodic monitoring required |
| Review Date        |                              |
| Approver           |                              |

***

# 26. Stage 8 — Deploy

The system is deployed according to the approved deployment plan.

Deployment controls include:

* production access;
* configuration validation;
* security validation;
* user provisioning;
* monitoring activation;
* incident readiness.

***

# 27. Deployment Readiness

```text theme={null}
Approved
   ↓
Technical Validation
   ↓
Security Validation
   ↓
Control Validation
   ↓
Monitoring Enabled
   ↓
User Access
   ↓
Production Deployment
```

***

# 28. Stage 9 — Operate

During operation, the system performs its intended business function.

Operational activities include:

* user support;
* content maintenance;
* access management;
* monitoring;
* issue management;
* supplier management.

***

# 29. Operational Responsibilities

The System Owner is responsible for ensuring that:

* the system remains within approved scope;
* controls remain operational;
* risks are monitored;
* incidents are escalated;
* changes are controlled.

***

# 30. Stage 10 — Monitor

ExampleCorp monitors the system continuously or periodically according to risk.

Monitoring areas include:

* system availability;
* output quality;
* user complaints;
* incidents;
* access violations;
* security events;
* content freshness;
* control effectiveness.

***

# 31. Example Monitoring Metrics

| Metric                       | Target                        |
| ---------------------------- | ----------------------------- |
| System availability          | Defined organizational target |
| Critical incidents           | 0                             |
| Unauthorized access          | 0                             |
| Material data incidents      | 0                             |
| Content review completion    | 100%                          |
| Required control assessments | 100%                          |
| Open critical findings       | 0                             |

***

# 32. Monitoring Thresholds

Thresholds should trigger defined responses.

```text theme={null}
Metric
   ↓
Threshold
   ↓
Normal
   or
Exception
   ↓
Investigation
   ↓
Corrective Action
```

***

# 33. Stage 11 — Incident Management

Suppose ExampleCorp identifies an incident in which the system provides an outdated internal procedure to an employee.

The incident is recorded.

***

# 34. Example Incident

| Field             | Example                              |
| ----------------- | ------------------------------------ |
| Incident ID       | `INC-EX-001`                         |
| AI System         | `AI-EX-001`                          |
| Description       | Outdated procedure provided          |
| Detection         | User report                          |
| Impact            | Low                                  |
| Severity          | Low                                  |
| Immediate Action  | Correct information supplied         |
| Root Cause        | Source content not refreshed         |
| Corrective Action | Content refresh control strengthened |
| Status            | Closed                               |

***

# 35. Incident Response

```text theme={null}
Detect
   ↓
Record
   ↓
Classify
   ↓
Contain
   ↓
Investigate
   ↓
Correct
   ↓
Verify
   ↓
Close
   ↓
Learn
```

***

# 36. Stage 12 — Assurance

Periodic assurance evaluates whether the governance system continues to operate effectively.

Assurance considers:

* controls;
* evidence;
* risk;
* monitoring;
* incidents;
* changes;
* compliance;
* governance decisions.

***

# 37. Example Assurance Review

The assurance function reviews:

1. AI inventory record;
2. classification;
3. risk assessment;
4. control implementation;
5. evidence;
6. monitoring records;
7. incidents;
8. change records;
9. approval;
10. management review.

***

# 38. Assurance Result

Example assurance conclusion:

**Generally Effective — Improvement Required**

A minor weakness is identified in the frequency of content-source reviews.

***

# 39. Corrective Action

ExampleCorp establishes a corrective action:

| Field        | Example                              |
| ------------ | ------------------------------------ |
| Action ID    | `CA-EX-001`                          |
| Finding      | Source review frequency insufficient |
| Root Cause   | No automated review reminder         |
| Action       | Establish automated review schedule  |
| Owner        | Business Owner                       |
| Target       |                                      |
| Evidence     | Updated review record                |
| Verification | Assurance Function                   |

***

# 40. Stage 13 — Improve

The corrective action is implemented.

ExampleCorp updates:

* procedure;
* monitoring;
* control frequency;
* evidence requirements.

***

# 41. Improvement Cycle

```text theme={null}
Finding
   ↓
Root Cause
   ↓
Corrective Action
   ↓
Implementation
   ↓
Verification
   ↓
Improved Control
```

***

# 42. Stage 14 — Change Management

Later, ExampleCorp decides to expand the system so that it can provide information from a new sensitive business repository.

This is a material change.

The change must therefore follow the AIGO change-management procedure.

***

# 43. Change Assessment

The organization assesses:

* changed purpose;
* new data;
* new stakeholders;
* increased risk;
* changed classification;
* changed controls;
* new security requirements.

***

# 44. Example Change Record

| Field                 | Example                  |
| --------------------- | ------------------------ |
| Change ID             | `CHG-EX-001`             |
| AI System             | `AI-EX-001`              |
| Change                | Add sensitive repository |
| Reason                | Business expansion       |
| Risk Impact           | Increased                |
| Classification Impact | Reassessment required    |
| Control Impact        | Additional controls      |
| Approval              | Required                 |
| Status                | Under Assessment         |

***

# 45. Change Decision

The change may result in:

```text theme={null}
Change Request
      ↓
Impact Assessment
      ↓
Risk Reassessment
      ↓
Control Reassessment
      ↓
Approval
   ↙       ↘
Approved   Rejected
```

***

# 46. Lifecycle Reassessment

If the change materially increases risk, ExampleCorp may require:

* new risk assessment;
* new controls;
* additional assurance;
* revised approval;
* enhanced monitoring.

***

# 47. Continuation Decision

At periodic review, the organization determines whether the AI system should:

* continue;
* change;
* suspend;
* retire.

***

# 48. Continuation Decision Model

```text theme={null}
Periodic Review
      ↓
Risk Status
      ↓
Control Effectiveness
      ↓
Performance
      ↓
Business Need
      ↓
Decision
  ↙    ↓     ↘
Continue Change Retire
```

***

# 49. Example Continuation Decision

ExampleCorp determines that:

* business need remains;
* risks remain within tolerance;
* controls remain effective;
* monitoring is operating;
* no material incidents remain unresolved.

Decision:

**Continue operation.**

***

# 50. Example Evidence Set

The complete example generates evidence such as:

| Evidence ID | Evidence              |
| ----------- | --------------------- |
| E-001       | AI inventory record   |
| E-002       | System profile        |
| E-003       | Classification record |
| E-004       | Risk assessment       |
| E-005       | Risk treatment record |
| E-006       | Control assessment    |
| E-007       | Approval record       |
| E-008       | Deployment record     |
| E-009       | Monitoring records    |
| E-010       | Incident record       |
| E-011       | Assurance report      |
| E-012       | Corrective action     |
| E-013       | Change assessment     |
| E-014       | Continuation decision |

***

# 51. End-to-End Traceability

```text theme={null}
AI System
   ↓
System Profile
   ↓
Classification
   ↓
Risk
   ↓
Control
   ↓
Procedure
   ↓
Evidence
   ↓
Approval
   ↓
Operation
   ↓
Monitoring
   ↓
Assurance
   ↓
Improvement
   ↓
Change / Continue / Retire
```

***

# 52. Example AIGO Traceability Matrix

| AIGO Element   | Example                          |
| -------------- | -------------------------------- |
| AI System      | Internal Knowledge Assistant     |
| Governance     | AI Governance Committee          |
| Role           | Head of Internal Technology      |
| Lifecycle      | Full AIGO lifecycle              |
| Classification | Standard                         |
| Risk           | Moderate                         |
| Control        | Access control                   |
| Procedure      | AI System Registration Procedure |
| Evidence       | Registration record              |
| Approval       | AI Governance Committee          |
| Monitoring     | Output quality monitoring        |
| Assurance      | Periodic assurance               |
| Improvement    | Corrective action                |
| Change         | New sensitive data repository    |

***

# 53. Example Decision Chain

```text theme={null}
Business Need
   ↓
AI System Proposal
   ↓
Governance Review
   ↓
Registration
   ↓
Classification
   ↓
Risk Assessment
   ↓
Control Selection
   ↓
Control Assessment
   ↓
Approval
   ↓
Deployment
   ↓
Operation
   ↓
Monitoring
   ↓
Assurance
   ↓
Improvement
```

***

# 54. Example NIST AI RMF Relationship

The example can also be viewed through the NIST AI RMF Functions.

| NIST AI RMF | Example Activity                     |
| ----------- | ------------------------------------ |
| GOVERN      | Governance authority and roles       |
| MAP         | System identification and context    |
| MEASURE     | Risk and control assessment          |
| MANAGE      | Risk treatment and corrective action |

***

# 55. Example ISO/IEC 42001 Relationship

The example also provides implementation evidence relevant to an AI management-system approach, including:

* organizational context;
* leadership;
* planning;
* risk management;
* operational controls;
* performance evaluation;
* improvement.

***

# 56. Example Control Lifecycle

```text theme={null}
Control Requirement
   ↓
Control Selection
   ↓
Control Implementation
   ↓
Evidence
   ↓
Assessment
   ↓
Finding
   ↓
Corrective Action
   ↓
Reassessment
```

***

# 57. Example Governance Lifecycle

```text theme={null}
Govern
   ↓
Identify
   ↓
Classify
   ↓
Assess
   ↓
Treat
   ↓
Approve
   ↓
Deploy
   ↓
Operate
   ↓
Monitor
   ↓
Assure
   ↓
Improve
   ↓
Continue / Change / Retire
```

***

# 58. Lessons from the Example

The example demonstrates several important AIGO principles:

1. AI governance begins before deployment;
2. ownership must be established early;
3. classification influences governance depth;
4. risk drives control selection;
5. controls require operational procedures;
6. implementation requires evidence;
7. approval should be evidence-based;
8. monitoring continues after deployment;
9. incidents feed improvement;
10. material changes trigger reassessment;
11. lifecycle governance is continuous.

***

# 59. Common Mistakes Demonstrated

Organizations should avoid:

* deploying before approval;
* relying on informal ownership;
* treating classification as permanent;
* conducting risk assessment without treatment;
* implementing controls without evidence;
* monitoring without thresholds;
* closing incidents without lessons learned;
* making material changes without reassessment.

***

# 60. Example Minimum Evidence Package

For a basic AI system, a minimum governance evidence package may include:

* system profile;
* classification;
* risk assessment;
* control assessment;
* approval;
* monitoring evidence;
* incident records;
* periodic review;
* assurance evidence.

***

# 61. Example Operational Status

At the end of this example:

**System:** Active
**Lifecycle Stage:** Operate / Monitor
**Classification:** Standard
**Risk:** Moderate
**Controls:** Operational
**Monitoring:** Active
**Assurance:** Periodic
**Residual Risk:** Accepted within organizational tolerance
**Decision:** Continue

***

# 62. Example Final State

```text theme={null}
Governed
   ↓
Registered
   ↓
Classified
   ↓
Risk Assessed
   ↓
Controlled
   ↓
Approved
   ↓
Deployed
   ↓
Operating
   ↓
Monitored
   ↓
Assured
   ↓
Improved
   ↓
Continued
```

***

# 63. Reusability of This Example

This example can serve as a reference when implementing AIGO for other AI systems.

The exact controls, risks, roles, evidence, and approval requirements should be adapted according to:

* organizational context;
* AI-system purpose;
* risk;
* impact;
* regulatory requirements;
* applicable standards;
* lifecycle stage.

***

# 64. Relationship to Templates

This example should later inform the design of AIGO templates.

Potential template candidates include:

* AI system registration;
* AI system profile;
* classification;
* risk assessment;
* control assessment;
* approval;
* monitoring;
* incident;
* assurance;
* change management;
* continuation decision.

The templates should be developed after the framework and examples have been sufficiently validated.

***

# 65. Relationship to Procedures

This example demonstrates the practical use of the AIGO procedures, including:

* AI Governance Procedure;
* AI System Registration Procedure;
* AI Risk Assessment Procedure;
* AI Classification Procedure;
* AI Control Assessment Procedure;
* AI Approval Procedure;
* AI Change Management Procedure;
* AI Incident Management Procedure;
* AI Monitoring Procedure;
* AI Assurance Procedure;
* AI Risk Acceptance Procedure;
* AI Retirement Procedure;
* Continuous Improvement Procedure.

***

# 66. Example Governance Principle

The central principle demonstrated by this example is:

> **No AI system should move through its lifecycle without appropriate governance, risk evaluation, controls, accountability, evidence, and decision authority.**

***

# 67. Document Status

**Document:** AIGO — Basic AI System Example

**Version:** 0.1

**Status:** Draft

**Working Name:** AIGO

**Full Name:** AI Governance Operating Framework

**Document Identifier:** `AIGO-EXAMPLE-001`

**Document Type:** Implementation Example

**Example Type:** Basic AI System

This document provides an illustrative end-to-end example of applying AIGO to a standard internal AI system.

***

# 68. End of Example Document

**AIGO — Basic AI System Example**

**Document ID:** `AIGO-EXAMPLE-001`

**Version:** 0.1

**Status:** Draft

**End of Document**