A record of models, copilots and agents that shows what the organisation intends the system to do, who owns it, and how it is classified. On its own, it is governance evidence, not an enforcement mechanism, because it cannot stop an agent from changing behaviour at runtime.
What an AI Register Is For
An AI register is a governance record of the models, copilots, and agents an organisation knows about, with basic metadata such as ownership, intended use, and classification. It creates visibility and accountability, but it does not itself enforce runtime behaviour or access.
That distinction matters: a register can tell you what exists and who is responsible, but it cannot by itself stop a model from changing outputs, a copilot from being repurposed, or an agent from taking new actions at runtime.
What the Register Should Capture
A useful AI register is more than an inventory name list. It should identify the system, its owner, the business purpose, the deployment context, the risk or sensitivity classification, and any operational boundaries that define how it is allowed to be used.
For AI systems, the record should also help separate ordinary software from systems that make decisions, generate content, or act through tools. That classification is important because the same model can behave very differently depending on where it is deployed, what data it sees, and whether it can initiate actions.
Used well, the register becomes a source of truth for review, approval, exception handling, and lifecycle tracking. It supports governance decisions, but it does not replace them.
Why an AI Register Is Not a Control
The register is evidence of governance intent, not enforcement. A system can be listed as low risk, approved for a narrow purpose, or assigned an owner, yet still be modified, connected to new tools, or given broader autonomy outside the register’s view.
That is why the register should be treated as a control-plane artefact, not a control itself. It helps people understand what should exist and who is accountable, while the actual restrictions must live in policy, architecture, access controls, approvals, and monitoring.
This is especially important when an AI system can call external services, generate actions, or interact with data beyond its original design. In those cases, the register tells you what was approved, but the live system tells you what is actually happening.
How AI Registers Support Governance and Assurance
An AI register helps organisations answer basic assurance questions: What AI systems do we have? Who owns them? Which ones are production systems? Which ones touch sensitive data or affect decisions? Which ones are experimental, vendor-managed, or customer-facing?
Those questions matter because AI risk is often hidden in fragmentation. Teams may deploy copilots, embedded assistants, or agentic workflows faster than central governance can track them. A register gives governance teams a place to reconcile policy with reality and identify systems that need review, restrictions, or retirement.
It also helps create consistency across the lifecycle. If the register is updated when a system is introduced, changed, or decommissioned, it becomes a durable record for audits, risk review, and accountability. Without that discipline, an organisation may know that AI exists somewhere, but not where it is, who runs it, or whether the classification is still accurate.
Risk and Threat Considerations
An AI register reduces blind spots, but it can also create a false sense of control if organisations treat it as the security boundary. The main risk is governance drift: the recorded purpose, owner, or classification no longer matches how the system is actually used.
Failure mechanism: Shadow deployment, unreviewed model updates, new tool connections, and privilege expansion can all move a system beyond the assumptions captured in the register. Once that happens, the record remains useful as documentation, but it no longer reflects the live risk posture.
Impact: Mismatched records can lead to missed approvals, weak oversight, inaccurate risk acceptance, and delayed response when a model, copilot, or agent behaves outside its intended scope.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF and NIST CSF 2.0 set the technical controls, while ISO/IEC 42001:2023, EU AI Act and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 42001:2023 | 4.4 — AI management system | AI registers support AI management system governance and documented accountability. |
| Recommendation — Maintain an AI register as part of the AI management system and keep system scope and ownership current. | ||
| NIST AI RMF | GOVERN — Governance | An AI register is a governance artefact for inventory, accountability, and oversight of AI systems. |
| Recommendation — Use governance records to track AI system ownership, intended use, and risk classification. | ||
| EU AI Act | Article 12 — Record-keeping | Record-keeping obligations align with documenting AI system purpose, classification, and traceability. |
| Recommendation — Retain records that show how each AI system is classified, owned, and monitored over time. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | An AI register documents organizational AI use and the context needed for governance decisions. |
| Recommendation — Document AI systems in a register so governance decisions reflect current organisational context. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | AI registers function as an inventory of systems and associated governance assets. |
| Recommendation — Keep an accurate inventory of AI systems, owners, and classifications and review it regularly. | ||
Practitioner Guidance
Why practitioners should care: An AI register works best as the anchor for ownership and inventory discipline, not as a substitute for technical enforcement. If the register is the only place where scope and classification exist, governance can become stale the moment the system changes.
Practitioner takeaway: Keep the register aligned to the live system, and assume the real control boundary sits in configuration, policy, and operational oversight rather than the record itself.
Related resources from NHI Mgmt Group
- Should organisations allow AI agents to register clients dynamically?
- What should governance teams do with AI assets that exist outside the register?
- How should security teams build an AI agent risk register that survives changing behaviour?
- How do you know if an AI agent risk register is actually working?