How to build an AI inventory: a step-by-step guide for 2026

Most organisations cannot answer a simple question: which AI tools are employees using right now?

That question is the starting point for every serious AI governance programme. Without an accurate AI inventory, policies are theoretical, risk assessments are guesswork, and audit preparation becomes a scramble. Under the EU AI Act and ISO 42001, inventory is no longer optional — it is the foundation regulators expect you to have in place before anything else.

This guide walks through how to build an AI inventory from scratch: what to include, how to discover tools you do not yet know about, how to classify risk, and how to keep the inventory current as AI adoption accelerates across your organisation.

What is an AI inventory?

An AI inventory is a continuously maintained record of every AI tool, model, and system in use across your organisation. It includes sanctioned tools that IT has approved, unsanctioned shadow AI that employees have adopted independently, and embedded AI features inside platforms your teams already use daily.

A good AI inventory is more than a list of tool names. For each entry it captures the vendor, the type of data the tool processes, where that data is hosted, which employees have access, the business purpose, and the level of regulatory risk under frameworks like the EU AI Act and ISO 42001.

An AI inventory is not a spreadsheet you build once and forget. It is a living operational record that reflects the real AI landscape inside your company on any given day.

Why an AI inventory matters now

Three forces are making AI inventory a board-level priority for European organisations.

Regulation. The EU AI Act requires organisations to document AI systems, classify them by risk, and maintain records that can be produced during an audit. Without an inventory, you cannot demonstrate compliance — and the burden of proof sits with you, not the regulator.

Shadow AI. Employees are adopting AI tools faster than IT can approve them. Research consistently shows that the number of AI tools actually in use inside a typical enterprise is three to five times higher than the number IT knows about. That gap is a governance liability.

Security. Every AI tool is a potential data exit point. Without knowing which tools are processing your company data, you cannot assess breach exposure, subprocessor risk, or training data leakage.

What to include in your AI inventory

A complete inventory entry answers the questions a regulator, auditor, or security team would ask about a given AI tool. The minimum set of fields:

• Tool name and vendor — the product and the legal entity behind it
• Category — LLM, coding assistant, image generation, embedded AI feature, autonomous agent
• Business purpose — what the tool is actually used for inside the organisation
• Users and departments — who has access and who is actively using it
• Data processed — the categories of data the tool can access: PII, financial, IP, health
• Data hosting and subprocessors — where data physically sits and who else touches it
• Training data usage — whether the vendor uses customer data to train models, and opt-out status
• Certifications — SOC 2, ISO 27001, ISO 42001, HIPAA, and any sector-specific attestations
• EU AI Act classification — minimal, limited, high, or unacceptable risk
• Approval status — approved, pending review, restricted, or prohibited
• Contract and renewal dates — for procurement and lifecycle management
• Owner — the internal person or team accountable for the tool

Sample AI inventory entry

The fields above only become useful when you see how they populate in practice. Below is an example of a completed inventory entry for a single tool. This is the format to replicate across every AI tool in your environment.

Step 1: start with discovery

You cannot inventory what you cannot see. Discovery is where every AI inventory programme begins, and it is almost always the step that produces the biggest surprises.

Survey employees directly

Send a short, anonymous survey to every team asking which AI tools they use for work. Keep it simple: tool name, what they use it for, and whether company data is involved. Anonymous responses produce more honest answers than formal procurement records ever will.

Analyse network and endpoint traffic

Work with your security team to pull DNS logs, firewall records, and endpoint monitoring data for the last 30 days. Filter for traffic to known AI providers: OpenAI, Anthropic, Google AI, Perplexity, Mistral, and the hundreds of smaller vendors that have emerged over the last two years.

Review procurement and expense data

Pull all SaaS purchases, expense reports, and credit card statements for the last twelve months. Look for AI vendors, but also for productivity tools that have quietly added AI features. A shadow IT discovery tool will surface a large share of this automatically by matching spend data against a known vendor catalogue.

Check browser extensions and integrations

Browser-based AI assistants often fly under the radar because they are installed by individual users, not procured centrally. Ask IT to pull a list of installed extensions across the fleet. Also review third-party app integrations in Microsoft 365, Google Workspace, Slack, and GitHub. Embedded AI features are frequently activated through these integration points — and they are just as in-scope as any standalone tool.

Step 2: classify and risk-score each tool

Once discovery is complete, every tool needs to be classified. The goal is to separate high-stakes AI systems that require deep review from low-risk productivity tools that can be fast-tracked through approval.

Use a tiered risk model

The tiered approval model used in mature AI governance programmes maps cleanly onto the EU AI Act risk categories:

Tier 1 — Minimal or limited risk. Productivity tools that do not process sensitive data. Self-service approval with a policy acknowledgement is sufficient.

Tier 2 — Elevated risk. Tools that access company data, customer information, or internal IP. Require IT and security review before approval.

Tier 3 — High risk. AI systems used in hiring, credit scoring, access to essential services, or anything touching regulated data. Require legal, compliance, and executive sign-off. These are the systems the EU AI Act regulates most heavily — and the ones most likely to trigger audit scrutiny.

Document the classification decision

For each tool, record why you assigned the risk level you did. Regulators and auditors want to see the reasoning, not just the label. This is especially important for ISO 42001 certification, where the evidence of your decision process matters as much as the decision itself.

Step 3: map data flows

An inventory that lists tools but not data flows misses half the point. For each tool, answer three questions: which categories of data does it touch, where does that data physically travel, and who else can access it along the way?

This is where subprocessors matter. A tool hosted in the EU may rely on a US-based subprocessor for model inference. A tool with strong certifications may pass data to a second or third vendor with weaker ones. Map the full chain, not just the surface layer.

The hardest risks to govern are the ones you cannot see. Subprocessor transparency is not a nice-to-have — it is the difference between governance on paper and governance that holds up under audit.

For CISOs managing vendor risk programmes, this step connects directly to your existing third-party risk framework. AI subprocessors should be subject to the same scrutiny as any other data processor — not treated as a separate category you will get to later.

Step 4: integrate with IAM and access controls

An AI inventory becomes operational when it connects to your identity and access management system. Once you know which tools are in use, you can enforce who is allowed to use them, which data categories they can share, and whether access should expire after a project ends.

Role-based access control for AI tools is especially important for high-risk categories. A finance team member and a marketing intern should not have identical access to an AI system that can process customer PII. Access recertification — where tool access is reviewed quarterly — turns the inventory from a static list into an active control.

For security and IT leaders building out this layer, the solutions for CISOs page covers how Grasp connects AI inventory directly to your existing IAM and access governance workflows.

Step 5: make the inventory living, not static

An inventory built once and left alone is worse than no inventory at all. It gives false confidence while the real AI landscape drifts further from what the document shows.

Automate discovery

Manual discovery catches tools once. Automated discovery catches them continuously. Modern AI governance platforms connect to network traffic, IAM systems, expense data, and browser telemetry to flag new AI tool usage as it happens — not three months later during the next review cycle.

Build a change-tracking workflow

Every inventory change should be logged: new tools added, access revoked, risk levels updated, contracts renewed. This audit trail is what makes compliance sustainable. It also gives you a clear picture of how your AI landscape is evolving over time — which is exactly what regulators will want to see.

Review on a fixed cadence

At minimum, review high-risk tools quarterly and the full inventory twice a year. Vendors change their data handling terms, add new AI features, and update their certifications. An inventory that is six months out of date is already wrong.

Common mistakes to avoid

A few mistakes come up consistently across AI inventory programmes, regardless of company size or sector.

Treating the inventory as a compliance document, not an operational record. If only the compliance team uses it, the inventory will go stale. It needs to be useful to IT, security, procurement, and the business — otherwise no one has an incentive to keep it current.

Relying on a single discovery method. Employee surveys miss tools people use quietly. Network monitoring misses mobile and personal-device usage. Combine at least three discovery sources.

Skipping embedded AI features. The AI built into Notion, Slack, Salesforce, and Microsoft 365 is just as relevant as standalone tools. If the feature is enabled for your users, it belongs in the inventory.

Classifying risk based on the vendor, not the use case. The same tool can be low risk in one department and high risk in another, depending on what data is being processed. Classification must follow context, not category.

No clear owner. An inventory without an accountable owner will decay. Assign it to a specific role — usually within IT or security — and tie it to their objectives.

AI inventory and the path to compliance

An AI inventory is the single most important artefact for AI governance. It is what the EU AI Act expects you to produce during an audit, what ISO 42001 builds its entire management system around, and what makes AI adoption faster rather than slower — because you are no longer approving tools blind.

For a broader view of where inventory fits into a full governance programme, see our hub on AI governance frameworks.

Frequently asked questions

How long does it take to build an AI inventory? The first pass usually takes four to six weeks for a mid-sized organisation: two weeks for discovery, two weeks for classification, and one to two weeks to establish ongoing maintenance. Larger organisations with more complex data flows can take three to four months to reach a mature, automated state.

Who should own the AI inventory? In most organisations, the AI inventory sits with IT or security, with a dotted line to compliance and legal. What matters most is that a single person or team is accountable for keeping it current. Shared ownership usually means no ownership.

Do we need a dedicated tool to maintain an AI inventory? Small organisations can start with a well-structured spreadsheet. Beyond 500 employees, manual maintenance breaks down quickly — new AI tools enter the environment faster than anyone can track them by hand. A dedicated discovery and governance platform becomes necessary at that point.

How is an AI inventory different from a SaaS inventory? A SaaS inventory lists software subscriptions. An AI inventory focuses specifically on AI capabilities — including AI features inside non-AI products, AI agents, and embedded models. There is overlap, but an AI inventory requires additional fields around training data, model hosting, and risk classification that a SaaS inventory does not capture.

Does the EU AI Act require an AI inventory? The Act does not use the phrase "AI inventory," but the obligations it places on organisations using high-risk AI systems effectively require one: technical documentation, risk management records, human oversight documentation, and post-market monitoring all depend on knowing what AI systems are in use. In practice, an inventory is the only efficient way to meet these obligations.

How often should the inventory be reviewed? Continuously for discovery, quarterly for high-risk tools, and semi-annually for a full review. The inventory itself should update in near real time — the formal review cadence is about validating classifications and catching vendor changes before they become compliance gaps.

Start with visibility

Every effective AI governance programme starts in the same place: knowing what AI tools are in use inside the organisation today. Once visibility is in place, policy, access control, and continuous compliance become achievable. Without it, every other governance activity is built on guesswork.

See how Grasp helps European organisations build and maintain a complete AI inventory, automatically. Talk to us.

PRE-PUBLISH CHECKLIST

• [x] H1 written — keyword in first 6 words, no pipe, no title case
• [x] Meta title ≤60 chars, keyword first
• [x] Meta description ≤158 chars, keyword + hook + CTA
• [x] Excerpt \= 143 chars
• [x] Subtext activating, problem loop opens before Grasp is named
• [x] Category assigned: Govern
• [x] Cover tone confirmed: Green
• [x] Reading time calculated: 12 min read
• [ ] Internal links confirmed live before publish: /shadow-ai, /eu-ai-act, /ai-governance (x2), /solutions/for-cisos, /contact
• [x] No unverified compliance standard numbers used
• [x] Single CTA on closing — one destination (/contact), placed at close only
• [ ] Pains vs Gains doc consulted for ICP framing — confirm before publish
• [x] British English throughout
• [x] Sample inventory table added (Grasp design system spec)
• [x] Pull quote earns its place — subprocessor transparency line
• [x] No conclusion restating intro — closes with forward action