AI System Records
An AI System Record is the stable identity for the system Gamut governs. Intake describes a particular use and determines routing; the system record identifies the product, service, model or agentic workflow to which that work belongs. Keeping those responsibilities separate prevents an assessment result from becoming detached from its owner, version or operating context.
What to record
Section titled “What to record”Complete enough detail for another reviewer to identify the same system without relying on local knowledge:
| Area | Record |
|---|---|
| Identity | Name, unique identifier, version and lifecycle state. |
| Accountability | Business owner, technical owner, responsible-AI contact and operating department. |
| Purpose | Intended use, users, affected people and decisions or actions supported. |
| Technology | Model or AI type, supplier, deployment arrangement, environment and agentic capability. |
| Data | Sources, classifications, personal-data involvement and geographic exposure. |
| Operation | Autonomy, human oversight, integrations, access and dependency. |
| Governance | Registration status, risk information, review dates and linked assurance records. |
Do not use a marketing product name alone where several deployments, versions or purposes have different risks. Create boundaries that match how change, ownership, access and evidence are managed.
Lifecycle
Section titled “Lifecycle”- Create the record as soon as a proposed or discovered system enters governance.
- Complete identity, ownership and operating context before relying on routing.
- Open or link intake for the use case being approved.
- Assess the system through the routed framework modules.
- Maintain version, supplier, data, purpose, access and deployment changes.
- Reassess when a material change invalidates prior scope or evidence.
- Retire the record without deleting the history needed for accountability.
Relationship to intake
Section titled “Relationship to intake”The system record and intake are connected but are not interchangeable. The record supplies durable facts such as system identity and ownership. Intake supplies the decision context used for risk, legal routing, framework applicability and assurance depth. Where the two disagree, investigate and correct the source record rather than selecting whichever result is more convenient.
Use Sync system record when the intake screen identifies that the linked record needs updating. Confirm the saved state before leaving the page. A system with incomplete intake can remain in the inventory, but its routing should be treated as provisional or incomplete.
Downstream effects
Section titled “Downstream effects”The selected system scopes framework assessments, AI-assisted assessment outputs, risks, model cards, evidence, findings, reports and reassessment history. Renaming a system should not create a new governance identity. A genuinely different product, materially different deployment or independently governed use may require a separate record.
Review checklist
Section titled “Review checklist”- The record identifies one defensible system boundary.
- Named owners are current and able to act.
- Purpose, users and affected people are specific.
- Data, geography, supplier and deployment facts are current.
- Autonomy and human oversight describe actual operation.
- The correct intake and assessments are linked.
- Material changes have triggered reassessment.
- Retired systems retain the required audit history.