How to Build an AI System Inventory (Template, 2026)

This article provides general informational guidance. See Legal Disclaimer .

Executive Summary

Every AI Act compliance program starts in the same place, whether the company has one AI tool or fifty: a documented inventory of what's actually in use. Skipping this step is why most SME AI Act efforts stall before they start.
The inventory isn't a legal document. It's an operational one. Nine fields, one row per tool, is enough for most SMEs to begin.
Building it once isn't enough. An inventory that isn't revisited quarterly goes out of date within a few months, given how fast teams adopt new AI tools.

Key Takeaways

The foundation of all AI Act duties: You can't run a risk classification, write an Article 4 training plan, or complete a DPIA without first knowing what tools you're assessing.
A discovery exercise as much as documentation: Most SMEs are surprised by what turns up once they ask every team.
A spreadsheet, not a legal filing: The rigor is in the process of keeping it current, not the sophistication of the format.

Why This Is the First Document, Not One of Many

Compliance programs fail for a predictable reason: they try to solve classification, training, and documentation at the same time, before anyone has written down what's actually being classified. An AI system inventory fixes the sequencing problem. It's the single artifact every downstream AI Act task depends on. You can't run the high-risk classification test on a tool you haven't listed, and you can't design an Article 4 literacy program for staff using tools nobody has named.

This mirrors a discipline compliance teams already know from GDPR. Article 30 requires a record of processing activities for exactly the same structural reason: you can't govern data processing you haven't inventoried. The AI Act's Article 26(6) deployer record-keeping obligation runs on the same logic. An AI system inventory is the natural, and largely overlapping, extension of a record-of-processing exercise your GDPR program may already have started.

A logistics company we've talked to found this out the hard way: three separate teams had each quietly adopted a different AI scheduling assistant over eighteen months, none of them the same tool, none of them reviewed by the same person. Nobody had lied about it. Nobody had been asked.

The Template: Nine Fields

Keep this simple enough that a non-lawyer can fill it out and specific enough that it's still useful three months later.

Field	What to capture	Example
Tool name	The product, not just the vendor	"ChatGPT Enterprise," not just "OpenAI"
Business function	What it's used for, in plain language	"Drafting customer support replies"
Department / owner	Who is accountable for this tool's use	"Customer Success, J. Martin"
Account tier	Consumer, enterprise, or API, and whether a DPA exists	"Enterprise, DPA signed 03/2026"
Data types processed	What kinds of data go in	"Customer names, order history, no payment data"
User count	Roughly how many employees use it	"12, customer success team"
AI Act deployer status	Confirmed as in-scope deployer use, yes/no	"Yes, professional use"
Risk classification	Result of the 7-step high-risk test, and date assessed	"Not high-risk, assessed 08/2026"
Review date	When this row was last verified as current	"Next review: 11/2026"

How to Actually Populate It: The Discovery Method

The template is easy. Filling it in accurately is harder, because most of the tools in use aren't the ones anyone remembers to list.

Start with what IT and procurement already know. Any AI tool bought through a formal process: pull the contract, the DPA status, and the user list. This is the easy 30%.
Ask every department head directly. "What AI tools does your team use for work, even informally?" Frame it as fact-finding, not an audit. Teams under-report when they expect blame, and the goal here is completeness, not enforcement.
Audit your existing SaaS stack for embedded AI features. Tools you already pay for regularly add AI capabilities through a feature update, without a new purchase or contract review. Check recent release notes for any SaaS product handling customer or employee data.
Check expense reports. Individually expensed AI subscriptions are a reliable, underused signal of tools that never went through procurement.
Cross-reference against the DPIA-trigger and high-risk classification checks for each row, so the inventory captures not just what exists, but what obligations attach to it.

What to Do with a Row Once It's Populated

An inventory that just sits there isn't useful. Each row should trigger two follow-up actions:

Run the risk classification. For every tool where the business function suggests possible Annex III territory (recruitment, credit or insurance decisions, essential services access), run a structured high-risk classification test and record the outcome and date in the inventory itself.
Confirm the account tier is appropriate. Any row showing consumer-tier use for data involving customers or employees is a flag to migrate that use to an enterprise or API tier with a DPA, or to restrict what data can go into it.

Keeping It Current

An inventory built once and never revisited is a snapshot of a company that no longer exists. AI tool adoption inside SMEs moves fast, and a quarterly review cadence is the realistic minimum. At each review: re-survey departments for new tools, re-verify account tiers and DPA status haven't lapsed, and re-run classification for any tool whose use case has changed since the last check. A tool adopted for drafting emails that has quietly expanded into candidate screening needs re-assessment, not a note in a meeting nobody wrote down.

Frequently Asked Questions

Is an AI system inventory a legal requirement under the AI Act?

The AI Act doesn't mandate a document called "AI system inventory" by name, but it functionally requires the information one contains. Deployers must know what AI systems they use, assess relevant ones for high-risk classification, and, for high-risk systems, meet Article 26 record-keeping obligations. In practice, an inventory is the only workable way to meet these requirements consistently.

How is this different from our GDPR record of processing activities (Article 30)?

They overlap significantly but aren't identical. Article 30 records focus on personal data processing activities. An AI system inventory focuses on AI tools specifically, including risk classification and deployer status that GDPR records don't capture. Many SMEs find it efficient to build the AI inventory as an extension of an existing Article 30 record rather than a separate exercise from scratch.

We're a 15-person company. Do we really need to formalize this?

Company size affects some GDPR record-keeping thresholds, but AI Act deployer obligations, including Article 4 AI literacy, apply regardless of headcount. A 15-person company with three AI tools in active use can build this inventory in an afternoon. The risk isn't the effort required. It's not doing it, and being unable to answer a basic question if ever asked.

How often should we update the inventory?

Quarterly is a reasonable minimum for most SMEs, with an ad hoc update any time a new AI tool is adopted or an existing tool's use case changes materially. Given how quickly AI features get added to existing software, a review cadence longer than a quarter risks the inventory being meaningfully out of date.

Nicolas Pinault

Nicolas Pinault is Co-founder & Product Development at Themio. With over 20 years of SaaS architecture experience, he designs the deterministic rules engines and compliance infrastructure for European enterprises.

Themio.ai automates AI tool discovery, maps your deployer obligations under the European AI Act , and builds your formal inventory and 5-step compliance roadmap in minutes. See how Themio works →

This article provides general information, not legal advice. Businesses should assess their own AI use with qualified counsel or a DPO. Last updated: September 11, 2026.