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

# 02 AIGO AI System Registration Procedure v0.1

# AIGO — AI Governance Operating Framework

## AI System Registration Procedure

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

***

### 1. Purpose

This procedure defines the process for identifying, registering, maintaining, and reviewing AI systems within the organization's AI inventory.

The procedure establishes a consistent method for ensuring that AI systems subject to AIGO governance are identified and assigned sufficient information for effective governance.

***

### 2. Scope

This procedure applies to AI systems and AI-related capabilities that fall within the organization's defined governance scope.

It may apply to:

* internally developed AI systems;
* externally acquired AI systems;
* third-party AI services;
* generative AI applications;
* AI agents;
* machine learning models;
* AI components embedded in products;
* AI-enabled business processes; and
* material changes to registered AI systems.

***

### 3. Objectives

The objectives of AI system registration are to ensure that:

* AI systems within scope are identified;
* ownership is established;
* AI systems are uniquely identifiable;
* relevant system information is recorded;
* governance requirements can be determined;
* lifecycle status is visible;
* risks can be tracked;
* controls can be associated with systems; and
* governance evidence remains traceable.

***

### 4. Registration Authority

The organization should designate a function responsible for maintaining the AI inventory.

The responsible function may be:

* AI governance;
* enterprise architecture;
* technology governance;
* risk management;
* compliance; or
* another authorized function.

System owners remain responsible for providing accurate information about their AI systems.

***

### 5. Registration Triggers

An AI system should be considered for registration when:

* a new AI initiative is proposed;
* an AI system is procured;
* an AI service is introduced;
* an existing application gains material AI functionality;
* an AI model is deployed;
* an AI agent is introduced;
* an existing AI system changes materially; or
* previously unmanaged AI use is discovered.

***

### 6. Registration Intake

The registration process should begin with an appropriate intake request.

The request should capture sufficient information to determine:

* whether the capability uses AI;
* whether it falls within governance scope;
* who owns it;
* what it is intended to do;
* where it will operate; and
* what information is required for further assessment.

***

### 7. Initial Registration Information

The initial registration should capture, where applicable:

* proposed system name;
* business purpose;
* business owner;
* technical owner;
* AI provider;
* system description;
* intended users;
* intended outputs;
* data categories;
* deployment environment; and
* expected lifecycle stage.

***

### 8. AI System Identifier

Each registered AI system should receive a unique identifier.

The identifier should be:

* unique;
* persistent;
* traceable;
* suitable for reporting; and
* retained throughout the system lifecycle.

The identifier should not be reused for another AI system.

***

### 9. AI System Name

The registered system should have a clear and recognizable name.

Where appropriate, the registered name should correspond with:

* the production system;
* the business service;
* the application;
* the AI model;
* the product; or
* the externally provided AI service.

***

### 10. System Description

The registration record should contain a concise description of the AI system.

The description should explain:

* what the system does;
* how AI is used;
* the primary purpose;
* major components; and
* the operational context.

***

### 11. Intended Purpose

The intended purpose should be documented.

The description should identify:

* intended use;
* expected outputs;
* intended users;
* decisions or actions supported;
* expected benefits;
* known limitations; and
* prohibited or unintended uses where relevant.

***

### 12. Ownership

The registration record should identify appropriate owners.

At minimum, ownership should identify:

* business owner; and
* technical owner where applicable.

Additional owners may include:

* risk owner;
* control owner;
* security owner;
* privacy owner; and
* service owner.

***

### 13. Provider Information

Where an AI system relies on a third party, the registration should identify the provider.

Provider information may include:

* provider name;
* service name;
* service type;
* contract reference;
* service version;
* hosting arrangement; and
* relevant dependencies.

***

### 14. AI Capability

The registration should describe the primary AI capability.

Examples include:

* prediction;
* classification;
* recommendation;
* natural language processing;
* computer vision;
* generative AI;
* speech processing;
* decision support;
* autonomous action; and
* agentic behavior.

***

### 15. Model Information

Where applicable, the registration should identify relevant model information.

Information may include:

* model name;
* model version;
* model provider;
* model type;
* deployment version;
* training status; and
* update mechanism.

***

### 16. Data Information

The registration should identify relevant data categories.

Data information may include:

* personal data;
* sensitive data;
* confidential data;
* public data;
* proprietary data;
* operational data;
* customer data; and
* synthetic data.

The registration should not unnecessarily duplicate sensitive information where a reference to an authoritative data record is sufficient.

***

### 17. Deployment Information

The registration should identify where the AI system operates.

Deployment information may include:

* production;
* development;
* testing;
* cloud;
* on-premises;
* hybrid;
* embedded;
* external service; and
* edge environment.

***

### 18. User Information

The registration should identify the primary user groups.

Users may include:

* employees;
* contractors;
* customers;
* public users;
* administrators;
* operators; and
* other authorized users.

***

### 19. Autonomy

Where relevant, the registration should describe the level of system autonomy.

The record may identify whether the AI system:

* provides information only;
* recommends actions;
* supports decisions;
* initiates actions;
* executes actions with approval; or
* executes actions autonomously.

***

### 20. External Impact

The registration should identify whether the AI system may materially affect external individuals or organizations.

Potential impacts may include:

* decisions;
* access to services;
* employment;
* financial outcomes;
* safety;
* customer treatment;
* eligibility;
* reputation; and
* other material interests.

***

### 21. Initial Classification

The AI system should receive an initial classification where required.

Classification should consider:

* impact;
* criticality;
* autonomy;
* data sensitivity;
* external exposure;
* security;
* privacy;
* regulatory requirements; and
* organizational risk criteria.

***

### 22. AI System Profile

An applicable AIGO AI System Profile should be assigned where appropriate.

The profile should support determination of:

* relevant risks;
* governance requirements;
* controls;
* evidence;
* monitoring; and
* assurance.

***

### 23. Initial Risk Status

The registration record should contain an initial risk status where required.

The status may be:

* not yet assessed;
* low;
* moderate;
* high;
* critical; or
* another organization-defined category.

The registration status should not replace a formal risk assessment where one is required.

***

### 24. Lifecycle Status

The registration should identify the current lifecycle stage.

Possible stages include:

1. Proposed.
2. Assessment.
3. Design.
4. Development.
5. Validation.
6. Approved.
7. Production.
8. Monitoring.
9. Change.
10. Suspended.
11. Retired.

***

### 25. Governance Status

The registration should identify the current governance status.

Possible statuses include:

* intake;
* under assessment;
* pending approval;
* approved;
* conditionally approved;
* rejected;
* suspended; or
* retired.

***

### 26. Control Status

Where applicable, the registration should provide a summary of control status.

The status may include:

* not assessed;
* planned;
* partially implemented;
* implemented;
* ineffective;
* exception approved; or
* not applicable.

***

### 27. Approval Status

The registration record should identify whether required approvals have been obtained.

Information may include:

* approval authority;
* approval date;
* approval decision;
* conditions;
* expiry or review date; and
* approval evidence.

***

### 28. Monitoring Status

The registration should identify whether required monitoring is operational.

Information may include:

* monitoring owner;
* monitoring frequency;
* key indicators;
* alert status;
* last review; and
* next review.

***

### 29. Registration Review

The responsible function should review registration information for completeness.

The review should verify that:

* required fields are populated;
* owners are assigned;
* the system is uniquely identified;
* classification is available where required;
* lifecycle status is accurate; and
* relevant governance references exist.

***

### 30. Registration Approval

The organization may require registration approval before an AI system progresses to certain lifecycle stages.

Approval should confirm that the registration contains sufficient information for governance.

Registration approval does not necessarily constitute approval to deploy the AI system.

***

### 31. Registration Changes

The registration record should be updated when material information changes.

Changes may include:

* ownership;
* provider;
* model;
* intended purpose;
* users;
* data;
* deployment;
* autonomy;
* classification;
* risk; and
* lifecycle stage.

***

### 32. Change Notification

System owners should notify the responsible governance function when material registration information changes.

Notification should occur within the timeframe defined by organizational requirements.

***

### 33. Periodic Review

Registered AI systems should be reviewed periodically according to risk.

The review should determine whether:

* registration information remains accurate;
* ownership remains valid;
* classification remains appropriate;
* risks have changed;
* controls remain appropriate;
* lifecycle status remains accurate; and
* monitoring remains active.

***

### 34. Event-Driven Review

A registration review should also occur when material events occur.

Triggers may include:

* significant incidents;
* major changes;
* provider changes;
* model changes;
* new use cases;
* increased autonomy;
* regulatory changes; and
* significant risk changes.

***

### 35. Duplicate Registration

The responsible function should identify and resolve duplicate registrations.

Where multiple records represent the same AI system:

* a primary record should be identified;
* duplicate records should be consolidated or retired;
* references should be preserved where required; and
* ownership should be confirmed.

***

### 36. Unregistered AI

The organization should establish a process for handling AI systems discovered outside the formal inventory.

Unregistered AI should be:

1. Identified.
2. Reported.
3. Assessed.
4. Registered where applicable.
5. Risk assessed.
6. Controlled.
7. Approved or restricted as appropriate.

***

### 37. Unauthorized AI

Where AI use violates organizational requirements, the responsible governance function should initiate appropriate escalation.

Potential actions include:

* temporary restriction;
* suspension;
* risk assessment;
* security review;
* privacy review;
* remediation;
* formal approval; or
* discontinuation.

***

### 38. Registration Evidence

Evidence of registration should be maintained.

Evidence may include:

* intake request;
* registration record;
* ownership confirmation;
* classification;
* profile assignment;
* approval;
* review records; and
* change history.

***

### 39. Data Quality

The AI inventory should maintain appropriate data quality.

Data quality requirements may include:

* completeness;
* accuracy;
* consistency;
* timeliness;
* uniqueness;
* traceability; and
* ownership.

***

### 40. Inventory Reconciliation

The AI inventory should be periodically reconciled against relevant organizational sources.

Sources may include:

* application inventories;
* procurement records;
* cloud services;
* model repositories;
* security systems;
* data inventories;
* architecture repositories; and
* vendor records.

***

### 41. Reporting

The responsible governance function should provide AI inventory reporting as required.

Reports may include:

* total registered systems;
* systems by classification;
* systems by lifecycle stage;
* systems by provider;
* high-risk systems;
* unregistered AI;
* overdue reviews; and
* retired systems.

***

### 42. Access Control

Access to AI registration information should be controlled according to organizational requirements.

Access should be based on:

* role;
* business need;
* confidentiality;
* security requirements; and
* applicable privacy requirements.

***

### 43. Record Retention

Registration records should be retained according to applicable records management requirements.

Retention should consider:

* lifecycle duration;
* regulatory requirements;
* audit needs;
* contractual requirements;
* legal requirements; and
* organizational policy.

***

### 44. Retirement of Registration

When an AI system is retired, the registration record should be updated.

The record should identify:

* retirement date;
* retirement reason;
* responsible owner;
* final status;
* evidence;
* data disposition where relevant; and
* remaining dependencies.

***

### 45. Historical Traceability

Historical registration information should be retained where necessary to support:

* audit;
* assurance;
* incident investigation;
* regulatory requirements;
* legal requirements; and
* organizational learning.

***

### 46. Exceptions

Exceptions to this procedure should be:

* documented;
* risk assessed;
* approved by the appropriate authority;
* time limited where appropriate; and
* periodically reviewed.

***

### 47. Responsibilities

The following responsibilities should be assigned as appropriate:

**AI System Owner**

* provide accurate system information;
* maintain registration information;
* notify material changes;
* participate in reviews; and
* support governance activities.

**AI Governance Function**

* maintain registration requirements;
* oversee the AI inventory;
* review registration quality;
* coordinate governance;
* report inventory status; and
* manage escalation.

**Technical Owner**

* provide technical information;
* identify material technical changes;
* support model and deployment records; and
* maintain technical accuracy.

**Risk Function**

* support classification and risk assessment;
* review risk information; and
* provide risk oversight where required.

**Security and Privacy Functions**

* provide specialist review where applicable;
* identify relevant requirements; and
* support risk and control decisions.

***

### 48. Registration Workflow

The standard registration workflow should be:

1. Identify AI capability.
2. Submit registration intake.
3. Determine governance scope.
4. Create unique AI system record.
5. Assign ownership.
6. Record system information.
7. Determine classification.
8. Assign AI System Profile.
9. Determine initial risk status.
10. Record lifecycle status.
11. Determine required governance activities.
12. Confirm registration completeness.
13. Approve registration where required.
14. Monitor and maintain the record.

***

### 49. Registration Quality Review

The responsible function should periodically review the quality of the AI inventory.

The review may evaluate:

* missing records;
* incomplete records;
* outdated information;
* duplicate records;
* incorrect classifications;
* missing owners;
* overdue reviews; and
* inconsistent lifecycle statuses.

***

### 50. Continuous Improvement

The registration process should be improved based on:

* operational experience;
* inventory quality;
* incidents;
* assurance findings;
* audit findings;
* stakeholder feedback;
* technology changes; and
* emerging governance requirements.

***

### 51. Procedure Review

This procedure should be reviewed periodically and when material changes occur.

Review triggers may include:

* changes to AIGO requirements;
* changes to AI governance;
* new AI technologies;
* regulatory developments;
* significant incidents;
* assurance findings; and
* implementation experience.

Material changes should be versioned and approved according to applicable document governance requirements.

***

### 52. Procedure Status

**Document:** AIGO AI System Registration Procedure

**Version:** 0.1

**Status:** Draft

**Working Name:** AIGO

**Full Name:** AI Governance Operating Framework

**Document Identifier:** `AIGO-PROC-002`

**Document Type:** Operational Procedure

This procedure establishes the operational process for identifying and maintaining an accurate inventory of AI systems within the organization's AIGO governance scope.

***