AI Register and AI Inventory Template

Most organisations cannot say how many AI systems they run, who owns each one, what data it touches or which identity it acts under, so every AI policy they write rests on an inventory that does not exist. This template gives you a policy for an AI register: a single, maintained record of every AI system, model, AI feature and AI agent that [Organisation] builds, buys or uses. It sets out the fields to record, who keeps them current, how entries are triggered and retired, and how the register feeds risk tiering, regulatory registration and audit. It is written for AI governance leads, CISOs, risk teams and their executive sponsors.

How to use this template

Replace text in square brackets, such as [Organisation], [AI governance body] and [register tool], with your own terms.
"Must" marks a mandatory requirement; "should" marks a recommended practice where a documented exception may be justified.
Start with the minimum fields in section 4.2; add extended fields only for high-risk systems.
Decide early whether the register lives in an existing CMDB or GRC tool or an AI governance platform. See the AI Governance Platform Buyer's Guide.
Have legal, privacy and risk teams review the final wording.

1. Purpose

This policy requires [Organisation] to maintain a complete and accurate register of the AI systems it develops, procures, deploys or uses. The register exists so that [Organisation] can:

Know what AI it runs, where, for what purpose and under whose accountability.
Apply proportionate risk assessment and controls, based on a risk tier recorded for every entry.
Meet regulatory duties that assume an inventory, including deployer obligations under the EU AI Act, public-sector transparency duties and data protection records.
Give security operations the identities, credentials and data flows of each AI system so that misuse can be detected and contained.

The policy implements the NIST AI Risk Management Framework outcome GOVERN 1.6, which calls for mechanisms to inventory AI systems, resourced according to organisational risk priorities, and GOVERN 1.7, which covers safe decommissioning.

2. Scope

This policy applies to every AI system that processes [Organisation] data, supports [Organisation] decisions or acts on behalf of [Organisation], its staff or its customers, wherever it runs. In scope:

Built in house: models trained, fine-tuned or hosted by [Organisation], and applications that call a model through an API.
Bought: AI products and SaaS services, and AI features switched on inside existing SaaS (for example copilots and summarisation features in productivity, CRM or ticketing tools).
AI agents: software that uses a model to choose and take actions through tools or APIs, including agents built on low-code platforms and coding agents used by developers.
Components: foundation models, model endpoints, vector stores, MCP servers and plugins that an in-scope system depends on, recorded as linked components.
Pilots and proofs of concept that use production or personal data.

Out of scope: personal, non-work use of AI, and research experiments on synthetic data that never connect to production systems. Use of public AI tools by individual staff is governed by the [AI Acceptable Use Policy]; tools approved under that policy are registered as one entry per tool, not per user. See the AI Acceptable Use Policy Template.

3. Roles and responsibilities

Role	Responsibility for the register
[AI governance body]	Approves this policy, the risk tiering method and the field set. Receives quarterly register metrics. Decides on high-risk entries.
[Register owner], for example the Head of AI Governance	Owns the register as a system of record, runs discovery reconciliation, chases overdue reviews and reports metrics.
AI system owner	A named, current employee accountable for each entry: creates it, keeps it accurate, completes reviews and requests retirement.
[CISO] and security operations	Maintain the identity, credential and logging fields; use the register in detection and incident response.
[Data Protection Officer]	Links entries that process personal data to the record of processing and to any DPIA.
[Procurement and third-party risk]	Ensure no AI product, or AI feature in an existing contract, is bought or switched on without a register entry.
[Internal audit]	Tests completeness and accuracy of the register at least annually.

4. Policy statements

4.1 Registration triggers

An AI system must be registered before it processes production data, is made available to users or customers, or is given credentials to any [Organisation] system.
A new entry or an update must be made when a system changes purpose, model or model version, data categories, user population, autonomy level, hosting location or vendor.
Procurement must not issue a purchase order or approve a contract renewal for a product with AI features until the register reference is supplied.
AI systems found by discovery that are not registered must be registered by their owner within [10] working days or be blocked. See the Shadow AI Discovery Guide.

4.2 Minimum fields for every entry

Field	What to record	Why it is needed
Register ID and name	Unique ID, plain-language name	Cross-reference from contracts, DPIAs, tickets
Owner and business unit	Named accountable person and deputy	NIST AI RMF GOVERN 2.1 roles
Purpose and intended use	What it does, decisions it supports, known out-of-scope uses	NIST AI RMF MAP 1.1; EU AI Act deployers must use systems per instructions (Art. 26(1))
Source	Built, bought, embedded SaaS feature, agent; vendor and contract reference	Third-party risk (GOVERN 6.1)
Model and components	Model provider, model name and version, hosting region, linked components	Change tracking and supply chain. See the AI Supply Chain and AI-BOM Guide
Data	Input and output data categories, personal or special category data, training or fine-tuning use	Link to ROPA and DPIA
Affected people	Staff, customers, public; whether outputs affect decisions about individuals	EU AI Act Art. 26(7) worker information and Art. 26(11) informing affected persons
Autonomy and human oversight	Advisory, human-approved, or autonomous; named oversight role	Art. 26(2) oversight by competent persons
Identities and credentials	Service accounts, workload identities, OAuth grants and API keys the system uses, and their owners	Detection, access review, revocation at retirement
Risk tier and status	Tier from the [AI risk tiering method]; lifecycle status (proposed, pilot, live, suspended, retired)	Proportionate control. See the AI Use Case Risk Tiering Guide
Regulatory flags	EU AI Act role (provider or deployer) and category, sector rules, public registration reference	Art. 49 registration, ATRS or OMB inventory where they apply
Review dates	Last review, next review, last risk assessment	Evidence for audit

4.3 Extended fields for high-risk entries

High-risk entries must also record: the risk assessment and impact assessment references, test and evaluation results, monitoring metrics and thresholds, log location and retention period, incident history, and the instructions for use supplied by the provider.
For systems in an EU AI Act high-risk category, log retention must be at least six months unless other EU or national law sets a different period, in line with Article 26(6). The register must record where those logs are held.
Model risk entries in regulated financial services must also link the model inventory record kept under the [model risk management standard]. See the AI Model Risk Management Guide (SR 11-7).

4.4 AI agents and identities

Every AI agent must be registered both as an AI system in this register and as a non-human identity in the [identity inventory], with the same owner and a cross-reference between the two records.
Each agent must run under its own identity. Shared or personal user credentials must not be used by agents.
The entry must list the tools, MCP servers and APIs the agent can call, the scopes it holds and whether it acts as itself or on behalf of a user.
When an entry is retired, all credentials and grants listed in it must be revoked within [5] working days, and the revocation recorded. See the Agentic AI Identity Guide and the Service Account Inventory Template.

4.5 Accuracy, review and retirement

Owners must review high-risk entries at least every [6] months and other entries at least every [12] months, and confirm or update every field.
The register owner must reconcile the register against discovery sources at least [monthly]: SaaS and OAuth grant reports, cloud AI service inventories, network and proxy logs for AI endpoints, expense and procurement records, and code repository scans for model SDKs and API keys.
Entries with no owner, or an owner who has left, must be reassigned within [10] working days or the system suspended.
Retired entries must be kept, not deleted, for [the retention period in the records retention schedule], so that past use can be evidenced.

4.6 External registration and publication

Where [Organisation] is a provider of an Annex III high-risk AI system, or a public authority deploying one, the register must hold the EU database registration reference required by Article 49 of the EU AI Act. Public authority deployers must not use a high-risk system that has not been registered (Article 26(8)).
Where [Organisation] is a UK government department or an in-scope arm's-length body, entries for in-scope algorithmic tools must link to the published Algorithmic Transparency Recording Standard record.
US federal agencies: the register must support the annual OMB AI use case inventory and its public version.

5. Exceptions

An exception to any requirement in this policy must be requested by the AI system owner, risk assessed by [AI governance lead] and [CISO], approved by [approver], recorded in the register with compensating controls and an expiry date of no more than [6] months, and reviewed before expiry. No exception may be granted to the requirement to register a system at all: a system without an entry is a policy breach, not an exception. See the Security Exceptions and Risk Acceptance Guide.

6. Compliance and monitoring

Compliance with this policy will be monitored by the register owner and tested by [internal audit]. The [AI governance body] will receive these measures each quarter:

Metric	Target
Discovered AI systems not in the register at month end	[0], with any found registered or blocked within [10] working days
Entries with a current owner	100%
High-risk entries reviewed on schedule	[95]% or more
Agent entries cross-referenced to an identity record	100%
Retired entries with credentials revoked within [5] working days	100%
AI contracts and renewals carrying a register reference	100%

Unregistered systems may be suspended. Staff breaches may be handled under [disciplinary procedure].

7. Review and approval

This policy is owned by [policy owner] and approved by [AI governance body]. It will be reviewed at least annually, and sooner after a significant change in regulation (for example amendments to the EU AI Act application dates) or after an incident in which the register proved incomplete.

Version	Date	Author	Approved by	Summary of changes
[1.0]	[date]	[name]	[AI governance body]	[Initial policy]

Implementation guidance

A register stays current through process gates, not goodwill. A practical rollout:

Seed from what you already have (weeks 1 to 4): export AI vendors from procurement and expense data, OAuth grants to AI apps from your identity provider and SaaS admin consoles, cloud AI services and model endpoints from each cloud account, and AI SDK imports and API keys from code scanning.
Confirm owners and minimum fields (weeks 4 to 8): ask each provisional owner to confirm or reject the entry and complete section 4.2. Unclaimed systems go to the [AI governance body] for a decision to adopt or block.
Tier and link (weeks 6 to 12): apply the risk tiering method, then link high-risk entries to their risk assessment, DPIA and identity records. See the AI Risk Assessment Guide and the DPIA Template.
Wire in the gates (months 3 to 6): make a register ID a mandatory field in procurement, in the change process for production deployments and in the request flow for new service identities or OAuth consents. Pilot the gate with one business unit in warn-only mode first, then enforce.
Automate reconciliation: schedule the discovery comparisons in section 4.5 and route new findings to owners as tickets. If enforcement blocks a legitimate system, roll back to warn-only for that source while the entry is completed, rather than abandoning the gate.

Small and large organisations: a small organisation can run the register as a controlled spreadsheet with the section 4.2 columns and a named owner, reconciled monthly by hand. A large organisation should hold it in a GRC, CMDB or AI governance platform with API feeds from discovery tools, because manual reconciliation does not scale beyond a few hundred entries.

A common gap: AI apps connected through OAuth are the entries most often missing, because no purchase order exists. The Vercel Context.ai OAuth breach shows how a forgotten AI app holding a live token became the route to customer secrets.

Framework mapping

Framework	Where the register fits
NIST AI RMF 1.0	GOVERN 1.6 (inventory), GOVERN 1.7 (decommissioning), GOVERN 6.1 (third parties), MAP 1.1 (purpose and context), MAP 4.1 (component risks)
NIST CSF 2.0	ID.AM-02 (inventories of software, services and systems), ID.AM-07 (data inventories), ID.AM-08 (life cycle management), GV.SC-04 (suppliers known and prioritised)
NIST SP 800-53 Rev. 5	CM-8 System Component Inventory, PM-5 System Inventory, AU-11 Audit Record Retention
ISO/IEC 42001:2023	Requirements for an AI management system; map the register to clauses in your licensed copy
ISO/IEC 27001:2022	Annex A 5.9 Inventory of information and other associated assets
EU AI Act	Art. 4 (AI literacy of staff using listed systems), Art. 26 (deployer duties), Art. 49 and Art. 71 (EU database registration)

Timing note: under the consolidated EU AI Act text as amended by the Digital Omnibus on AI, the high-risk obligations in Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems, while Article 4 on AI literacy has applied since 2 February 2025. See the EU AI Act Compliance Guide.

Standards and references

This template is provided for guidance and must be adapted to your organisation. It summarises regulatory requirements and is not legal advice. Related NHI Mgmt Group resources: AI Governance Guide · Shadow AI Discovery Guide · Data Mapping and ROPA Guide · Risk Register Template

AI Register and AI Inventory Template: Recording Every AI System You Run