---
title: "AI register: how to inventory every AI system your firm builds, buys or switches on"
canonical: https://www.grcmana.io/vault/ai-governance/ai-inventory
published: 2026-10-23
updated: 2026-10-23
author: "Harry West"
framework: "AI Governance"
control: "Guide AI register: how to inventory every AI system your firm builds, buys or switches on"
journeyStage: intermediate
---

# AI register: how to inventory every AI system your firm builds, buys or switches on

## Key takeaways

An AI register is a firm's own record of every AI system it builds, buys or uses, including AI switched on inside approved SaaS. We recommend one row per system per business purpose, built as an extension of the ISO 27001 asset inventory. Each entry records an owner, purpose, data, EU AI Act role, high-risk screen and review date, so one record serves regulation, risk and customer questionnaires.

- **AI system** — Under EU AI Act Article 3(1), a machine-based system that operates with some autonomy and infers from its inputs how to generate outputs such as predictions, content or decisions.
- **High-risk screen** — Annex III systems are high-risk under Article 6(2). A provider that concludes one poses no significant risk must document that assessment. Annex III obligations apply from 2 December 2027.
- **NIST AI RMF GOVERN 1.6** — The voluntary NIST AI RMF outcome that mechanisms are in place to inventory AI systems, resourced according to organisational risk priorities. The Playbook suggests naming an owner for the inventory.
- **EU database** — Article 49 requires providers of most Annex III high-risk systems, and public-authority deployers, to register in the EU database. It is separate from a firm's internal AI register.

A customer's security questionnaire has a new section: list every AI system and AI sub-processor that touches our data. Nobody in the firm can answer it with confidence. An AI register is how you answer it once and keep answering it.

An AI register, also called an AI inventory, is your firm's own record of every AI system it develops, buys or uses, including AI features switched on inside approved SaaS. Each entry names an owner, a purpose, the data involved, the EU AI Act role and a risk tier. It is internal, not the public EU database, and it is the first step of AI governance.

This guide is for CTOs, COOs and security leads at UK tech firms of 25 to 250 people who sell into regulated customers. It covers what to include, what to record, where entries come from and how to keep the register current.

## What is an AI register?

An AI register is a structured record of the AI systems an organisation builds, buys and uses, kept so that each one has an owner, a stated purpose and a known risk position. It works as the single source that classification, risk assessment, contracts and customer answers all draw on, rather than a list compiled afresh for each request.

The term causes confusion because public bodies also publish registers of their AI use. Those registers are about transparency to citizens. Yours is a management record, and the customers who ask about it want to see that it exists and is current.

For the wider rules behind the register, see our guides to the [EU AI Act](https://www.grcmana.io/vault/eu-ai-act) and [ISO/IEC 42001](https://www.grcmana.io/vault/iso-42001). This page sticks to the register itself.

## What counts as an AI system for your AI register?

An AI system, in EU AI Act Article 3(1), is a machine-based system that operates with some autonomy and infers from its inputs how to generate outputs such as predictions, content, recommendations or decisions. If a tool you build or use does that, it belongs in the register. When in doubt, add the entry and record why.

The full Article 3 definition also says the system "may exhibit adaptiveness after deployment". The European Commission published [guidelines on the AI system definition](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-guidelines-ai-system-definition-facilitate-first-ai-acts-rules-application) on 6 February 2025 to help firms decide whether software counts. The Commission states that "the guidelines on the AI system definition are not binding", so the judgement stays with you.

In practice, three kinds of software reach the register:

- **Built.** Models, features and agents your own engineers develop, including features built on a third-party model and sold under your name.
- **Bought.** AI products you license for internal use, such as an AI assistant for sales or a screening tool in recruitment.
- **Embedded.** AI features that arrive inside software you already approved, often switched on by a vendor release rather than a purchase.

If your register lists only the tools you bought, it describes your procurement, not your AI.

## Should each entry be a system or a use case?

We recommend one row per AI system per business purpose, grouped under the system it uses. The EU AI Act classifies AI by intended purpose, so the same model can be minimal risk in one use and high-risk in another. A row per system hides that difference; a row per use case shows it.

Take a general-purpose language model licensed once. Drafting marketing copy and screening job applicants are two rows under the same system. Recruitment and selection fall within Annex III point 4, and Article 6(2) says Annex III systems "shall be considered to be high-risk". The copywriting row does not.

Keep each row small enough to have one owner. If two teams would argue over who answers for an entry, split it.

## Where do AI register entries come from?

AI register entries come from records your firm already keeps: procurement and finance, your identity provider, data processing agreements, the product roadmap and vendor release notes. Working through these five sources finds most built, bought and embedded AI without a survey. Tools staff adopted without approval need a separate discovery and triage process.

Work through the sources in this order:

1. **Procurement and finance records.** Search purchase orders, card spend and renewals for AI products and AI add-on licences.
2. **Identity provider and single sign-on records.** List every application connected to your identity provider and flag those with AI features.
3. **Data processing agreements and sub-processor notices.** Vendors often add AI model providers as new sub-processors. Each notice is a likely new entry.
4. **Product roadmap and engineering backlog.** Every customer-facing feature that uses a model, including those in beta, is a built entry.
5. **Vendor release notes.** Read the release notes for your core SaaS each quarter. This is where embedded AI arrives.

Unsanctioned tools are a different problem with a different process. Our guide to [shadow AI governance](https://www.grcmana.io/blog/shadow-ai-governance) covers how to find and triage them; once a tool is approved, it joins the register like any other entry.

## What should each entry in an AI register record?

Each entry in an AI register should record who owns it, what it is for, what data it uses, the firm's EU AI Act role, its high-risk screen and transparency flag, the supplier and sub-processor chain, how humans oversee it, and when it is next reviewed. Those fields let one entry serve regulation, risk and customer questions together.

| Field | What to record | Why it matters |
| --- | --- | --- |
| Owner | A named person accountable for the entry | Without a name, no one updates or answers for it |
| Purpose | What the system is used for, in one sentence | EU AI Act classification follows intended purpose |
| Data categories | Personal, customer, special category or none | Links the entry to UK GDPR records and contracts |
| EU AI Act role | Provider, deployer or both, from Article 3 | Sets which obligations apply to you |
| High-risk screen | Whether the use falls in Annex III, and any Article 6(3) assessment | Decides the heaviest obligations and documentation |
| Transparency flag | Whether Article 50 applies, such as a chatbot or generated content | Triggers disclosure and marking duties |
| Supplier and sub-processor | The vendor, the model provider and where data goes | Answers customers' sub-processor questions |
| Human oversight | Who reviews outputs, and how | Required for high-risk deployers under Article 26 |
| Risk assessment | Whether one is needed, and a link to it | Sends the right entries to deeper review |
| Review date | When the entry is next checked | Keeps the register from going stale |

Three fields deserve a closer look.

**EU AI Act role.** Article 3 defines a provider as the body that develops an AI system, or has one developed, and places it on the market "under its own name or trademark". A deployer is anyone "using an AI system under its authority". A SaaS firm that ships an AI feature to customers is usually a provider of that feature and a deployer of the AI it uses internally.

**High-risk screen.** Record whether each use falls in an Annex III area. Under Article 6(3), an Annex III system is not high-risk where it "does not pose a significant risk of harm", but Article 6(4) says the provider "shall document its assessment" first. The register is where that conclusion lives. Under Regulation (EU) 2026/1744, the Annex III high-risk obligations apply from 2 December 2027.

**Data categories.** Where an entry processes personal data, link it to your UK GDPR record of processing. The [ICO's guidance on AI and data protection](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/what-are-the-accountability-and-governance-implications-of-ai/) says that "in the vast majority of cases, the use of AI will involve a type of processing likely to result in a high risk", which triggers a data protection impact assessment.

## How do you build an AI register from your ISO 27001 asset inventory?

Build the AI register by extending the asset inventory you already keep under ISO 27001 Annex A 5.9, not by starting a new spreadsheet. Add a flag for AI and the AI-specific columns from the table above. Entries then share owners, review cycles and evidence with the rest of your information security management system.

A separate AI spreadsheet looks faster in week one. By the next audit it has drifted from the asset inventory, and two owners hold two versions of the same system.

A working sequence:

1. Add an "AI system" flag and the AI fields to your existing [Annex A 5.9 asset inventory](https://www.grcmana.io/vault/iso-27001/annex-a-5-9-inventory-of-information-and-other-associated-assets).
2. Flag existing assets that already contain AI, starting with your core SaaS.
3. Add new rows for each built feature and each AI use case found in the discovery sources.
4. Assign owners and review dates, using the same cadence the asset inventory follows.
5. Complete the EU AI Act fields and mark which entries need a risk assessment.

If you do not hold ISO 27001, the same fields work in any controlled list. The point is one record with owners, not the tool that holds it.

## How does an AI register map to ISO/IEC 42001 and the NIST AI RMF?

The AI register is the backbone of both frameworks' inventory expectations. ISO/IEC 42001:2023 asks you to define the scope of your AI management system and to document the resources behind each AI system; the register supplies both. The NIST AI RMF GOVERN 1.6 outcome asks for mechanisms to inventory AI systems.

The [NIST AI RMF Playbook](https://airc.nist.gov/airmf-resources/playbook/govern/) states GOVERN 1.6 as "mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities". The Playbook describes an AI system inventory as "an organized database of artifacts relating to an AI system or model". It also suggests naming "a specific individual or team that is responsible for maintaining the inventory". Our [NIST AI RMF guide](https://www.grcmana.io/vault/nist-ai-rmf) covers the framework itself.

For ISO/IEC 42001:2023, the register does two jobs. It shows which AI systems sit inside the management system's scope. It also gives a home for the documentation Annex A expects about the data, tools, computing and people each AI system relies on.

## Is your AI register the same as the EU database or a public-sector register?

No. Your AI register is a private management record that covers every AI system you use. The EU database under Article 49 of the EU AI Act is a public registration for specific high-risk cases. Public-sector registers such as the UK's Algorithmic Transparency Recording Standard and the Scottish AI Register publish how government bodies use algorithms.

| Record | Who keeps it | What it covers | Public? |
| --- | --- | --- | --- |
| Your AI register | Your firm | Every AI system you build, buy or use | No |
| EU database (Article 49) | Providers of Annex III high-risk systems, and certain public-sector deployers | Registered high-risk systems, and systems a provider has concluded are not high-risk under Article 6(3) | Yes, with exceptions |
| Algorithmic Transparency Recording Standard | UK public sector bodies | Algorithmic tools used in public services | Yes |
| Scottish AI Register | Scottish public sector | AI used or planned for public services | Yes |

[Article 49(1)](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-49) requires providers of Annex III high-risk systems to "register themselves and their system in the EU database" before placing them on the market, except for critical infrastructure systems under Annex III point 2, which register at national level. Article 49(3) applies to deployers that are public authorities or act on their behalf. A private firm deploying AI for its own business does not register its use there.

The UK government describes the Algorithmic Transparency Recording Standard as a standardised way "for public sector organisations to publish information" and says "the ATRS is mandatory for all government departments". Neither applies to a private tech firm, but both show what a mature register entry looks like.

## How does an AI register answer customer questionnaires?

An AI register answers a customer questionnaire's AI section in minutes, because the questions map onto its fields. Which AI systems touch our data, which model providers act as sub-processors, whether outputs are reviewed by a person, and how you classify risk under the EU AI Act all come straight from the register.

Filter the register to entries that process customer data. That view is your answer to "list every AI system and sub-processor", and it should match your public sub-processor list.

The questionnaire is not the reason to build the register. It is the first test of it.

## How do you keep an AI register current?

Keep an AI register current with event triggers and a fixed review cycle. Update entries when a new tool is approved, a feature ships, a vendor adds an AI sub-processor or a use changes purpose. Then review every entry on a set cadence, at least yearly and more often for high-risk or customer-facing uses.

The triggers that matter most:

- a new AI product or add-on passes procurement;
- an AI feature moves from beta to general release;
- a vendor sub-processor notice names a new model provider;
- a team starts using an existing system for a new purpose;
- a customer contract adds AI-specific terms.

Tie the triggers to processes that already exist, such as procurement approval, release sign-off and supplier review. A register kept up to date from memory falls behind with the next vendor release.

A register nobody owns is a snapshot, not a control.

## Common mistakes

The mistakes that undermine an AI register are about scope and ownership, not format. These are the patterns to avoid:

- **Listing tools, not uses.** One row per product hides the purpose that drives EU AI Act classification.
- **Missing embedded AI.** Vendor features switched on by a release never pass procurement, so a procurement-only register misses them.
- **Recording the vendor, not the model provider.** Customers ask where their data goes, and the answer is often the model provider behind the vendor.
- **Treating it as a compliance artefact.** A register built only for an audit is out of date by the time the customer asks.
- **No owner per entry.** "IT" is not an owner.

The fix for each is the same: tie the register to the processes that change it, and give every entry one name.

For assessing an individual entry flagged as needing deeper review, the next step is an AI risk assessment.

## Frequently asked questions

### Is an AI register a legal requirement?

UK law does not require a private firm to keep an AI register by that name. The EU AI Act requires providers to document Article 6(3) assessments and register high-risk Annex III systems, and the voluntary NIST AI RMF asks for an inventory under GOVERN 1.6. In practice, you cannot meet those duties or answer customers without one.

### What is the difference between an AI inventory and an AI register?

None in practice. Both describe a firm's record of the AI systems it builds, buys and uses. "Inventory" is the term the NIST AI RMF Playbook uses. Choose one name and use it consistently in your policies and customer answers.

### Do staff tools like AI chat assistants belong in the AI register?

Yes, once approved. An AI assistant licensed for staff is a bought system, and each significant use, such as drafting customer emails, is an entry. Unapproved tools belong in your shadow AI process until they are approved or blocked.

### Is an AI register the same as an AI bill of materials?

No. An AI bill of materials, or AI BOM, lists the components inside one AI system, such as models, datasets and libraries. An AI register lists every AI system and use across the firm. For systems you build, the register entry can link to that system's AI BOM.