AI Inventory Template: How to Record Every AI System

An AI inventory is a register of every AI system your organisation uses or builds, with one entry per use case: what the system does, who owns it, which provider supplies it, what data goes in, how it is classified under the EU AI Act and which controls apply. You build it in four steps: find what is in use, record each use case with a fixed set of fields, classify it, and keep it current. A shared spreadsheet is enough to start.

This guide gives you the fields to record, three example entries and a routine for keeping the register up to date. It is general information, not legal advice. For decisions with legal consequences, read the official text of the AI Act (Regulation (EU) 2024/1689, as amended) and consult qualified counsel.

Why an AI inventory is worth the effort

The EU AI Act does not require every business to keep an inventory in so many words. But almost every obligation in it depends on knowing which AI systems you use and for what purpose:

• AI literacy measures should target the people who actually work with AI systems.
• Transparency duties apply in specific situations, such as chatbots, deepfakes or emotion recognition.
• High-risk obligations depend on the purpose, for example recruitment or credit decisions.
• Becoming a provider can happen when you change the purpose of a system or put your name on it.

Without an inventory, each of these questions has to be answered from scratch, usually under time pressure. There are other benefits too: data protection teams need to know where personal data flows, IT security needs to know which external services receive company data, and finance wants to know what all the subscriptions cost.

What belongs in the inventory

Scope it broadly at first and narrow it later. Typical entries include:

• general AI assistants used by staff, whether licensed by the company or not,
• AI features inside existing software, such as HR, CRM, helpdesk, accounting or office tools,
• automations and workflows that call an AI model,
• chatbots and assistants you built or commissioned,
• AI components in products you sell,
• browser extensions and plug-ins with AI features.

The AI Act has its own legal definition of an AI system, and not every tool marketed as "AI" meets it. For the inventory, it is safer to record a borderline tool and note the doubt than to leave it out.

Step 1: Find out what is actually in use

Official lists rarely tell the whole story. Combine several sources:

1. Procurement and invoices: subscriptions, licences and API accounts paid by the company or reimbursed as expenses.
2. IT records: software lists, single sign-on logs, approved browser extensions.
3. Vendors: ask the providers of your main business software which AI features are active or planned.
4. Teams: a short survey per department: which AI tools do you use, for which tasks, with which data?
5. Development and IT projects: anything that calls a model's API.

The team survey works best without blame. If people expect to be punished for using an unapproved tool, they will not mention it, and the inventory stays incomplete. Make it clear that the aim is to find safe ways to keep useful tools, then follow up with your AI acceptable use policy.

Step 2: Record each use case

Create one row per use case, not per tool. These fields cover what most organisations need:

Field	What to record
ID and name	A short name such as "Email reply drafts, customer service"
Purpose	What the system is used for, in one or two sentences
Tool and provider	Product name, vendor, model if known
Type	General assistant, AI feature in software, own build, workflow
Department and owner	Who is accountable for this use
Users	Roles and approximate number of people using it
Affected persons	Customers, applicants, employees, the public
Data	Categories of input data, whether personal or confidential data is involved
Decision impact	Does the output inform or make decisions about people?
Human oversight	Who checks the output and how
Role under the AI Act	Deployer, provider or both
Risk classification	Prohibited, high-risk, transparency duty, minimal risk, or "to be assessed"
Controls	Policies, training, review steps, contracts, data processing agreement
Status	Proposed, pilot, approved, restricted, retired
Dates	Start of use, last review, next review

Keep the free text short. An inventory that takes an hour per entry will not be maintained.

Step 3: Classify each use case

For each row, answer three questions:

1. Which role do you have? Using a vendor's tool usually makes you a deployer. Building your own system, or putting your name on one, can make you a provider. The article on EU AI Act obligations for deployers explains the difference.
2. Which risk category applies? The purpose decides, not the technology. EU AI Act risk categories explained walks through each tier with examples.
3. Which obligations follow? Note them in the controls field and assign an owner.

The free EU AI Act risk checker gives a first orientation per use case and lists the obligations to look into for your role. Record the result and the date, and mark anything that looks high-risk for legal review.

Example entries

Three hypothetical rows, shortened:

Field	Email reply drafts	CV pre-screening	Website chatbot
Purpose	Draft replies to customer emails	Rank incoming applications	Answer product questions on the website
Type	General assistant, company licence	AI feature in HR software	Own build on an LLM API
Personal data	Yes, customer names and orders	Yes, applicant data	Possibly, if users type it
Decision impact	None, agent sends the reply	Influences who is invited	None, information only
Role	Deployer	Deployer	Likely provider of the chatbot
Classification	Likely minimal risk	Likely high-risk (employment)	Transparency duty
Controls	Policy, training, agent reviews every draft	Paused pending legal review	Users told they are talking to AI, handover to a person
Status	Approved	Restricted	Pilot

The CV example shows why classification matters. The feature might have been switched on by a software update without anyone deciding to use it. An inventory with vendor questions catches this.

Step 4: Assign owners and controls

Every row needs one accountable owner, usually the head of the department that uses the system, not IT. The owner makes sure:

• the people using it have had suitable AI literacy measures (see AI literacy under the EU AI Act),
• the review steps described in the row actually happen,
• changes in purpose or vendor features are reported,
• the entry is reviewed on its due date.

Central coordination, often by compliance, data protection or an AI lead, keeps the template consistent and tracks open reviews.

Step 5: Keep it current

An inventory decays quickly. Build updates into existing processes instead of relying on memory:

• Procurement: no new software with AI features without an inventory entry.
• IT approval: new API keys, extensions and integrations trigger an entry.
• Vendor updates: when a provider announces new AI features, the owner checks whether the classification changes.
• New purposes: using an approved tool for a new task means a new row, not an edit.
• Annual review: every entry is confirmed, updated or retired.

Link the inventory to your other records

Many organisations already keep a record of processing activities under Article 30 of the GDPR. Cross-reference the two instead of duplicating data: the AI inventory entry points to the processing record, and the processing record notes that an AI system is involved.

The inventory also helps you plan around the AI Act timeline. According to the European Commission's AI Act page, the prohibitions and AI literacy obligations have applied since 2 February 2025 and the transparency rules from August 2026. After the AI Omnibus amendments, which entered into force on 27 July 2026, rules for high-risk systems in the listed areas such as employment apply from 2 December 2027, and for AI in products such as lifts or toys from 2 August 2028. Dates can change again, so check the current official sources.

Spreadsheet or dedicated tool?

Start with a spreadsheet or a list in your existing collaboration tool. It is enough for dozens of entries, and the fields matter more than the software. Consider a dedicated governance tool when you have many entries, several reviewers, or need workflows and audit trails. Whatever you choose, restrict who can edit classifications and keep a change history.

Common mistakes

• Listing tools instead of uses. One tool can appear in several rows with different classifications.
• Only counting what IT approved. Unofficial tools are where the risk usually sits.
• Forgetting AI features in existing software. Updates can add AI to tools you have used for years.
• No owner per entry. Without accountability, entries go stale.
• Building it once. An inventory that is not tied to procurement and approvals is outdated within months.
• Too many fields. Start with the essentials and add fields only when someone needs them.

Summary checklist

• Collect AI tools from invoices, IT records, vendors, teams and projects.
• Create one row per use case with the fields above.
• Determine your role and the risk category for each row, starting with the EU AI Act risk checker.
• Send anything that looks high-risk or prohibited for legal review.
• Assign an owner and controls to every row.
• Tie updates to procurement, IT approval and vendor changes.
• Review every entry at least once a year.