Building Your First AI Systems Inventory

Most organizations that believe they have a handle on their AI footprint are wrong by a wide margin — not because anyone's hiding anything, but because AI capability arrives through a dozen different doors at once: procured enterprise tools, internally built models, AI features vendors quietly switched on inside existing SaaS subscriptions, and individual employees signing up for consumer AI tools with a personal or expensed account. An inventory is the exercise of finding all of it and writing it down, and it's worth taking seriously, because it's the input every other governance step depends on.

Why this is the step everything else depends on

Risk tiering can't tier a system nobody's listed. Classification work — under the EU AI Act or any state framework — can't classify a system compliance doesn't know exists. A review gate can't catch a new AI deployment if there's no process feeding new systems into it in the first place. An incomplete inventory doesn't just leave a gap in a spreadsheet; it silently caps how effective every governance process built on top of it can be, because those processes can only act on what's in front of them.

What to capture for each system

The first pass doesn't need to be exhaustive on every field, but it needs enough to support the risk-tiering work that follows. For each system, capture: a named business owner (not "the team," a person), the business purpose it actually serves, the vendor or underlying model if it's not built in-house, the types of data it processes — particularly whether that includes personal, sensitive, or regulated data — its deployment status (pilot, limited rollout, full production), roughly who or what population it affects, and, critically, whether its output materially influences a decision about a person — employment, credit, healthcare, access to a service. That last field is the one that ends up mattering most once risk tiering starts, so it's worth getting a real answer rather than a placeholder.

Finding the officially procured systems

This is the more straightforward half of the exercise. Start with IT asset management records and the procurement or contract database — anything with a signed vendor agreement should already be discoverable there. Cross-reference against SaaS subscription and expense records, since plenty of AI tools get procured at the team level through a credit card rather than a formal IT purchase request. If a vendor security review process exists, its records are often a faster route to "what AI have we approved" than reconstructing the answer from procurement alone, since security review tends to happen closer to when a tool actually gets adopted.

Finding the AI nobody officially procured

This is where a genuinely useful inventory earns its keep, because the officially procured list is rarely the whole picture. A few methods surface what it misses:

SSO/SAML application logs. If your organization uses single sign-on, the list of applications employees have actually authenticated into is one of the most reliable signals of real usage — including tools nobody in IT or procurement ever heard of.

Expense report review. AI subscriptions frequently show up as individual expense line items long before — or instead of — going through procurement. A targeted review of recent expense categories for AI-adjacent vendor names catches a meaningful slice of shadow spend.

Browser extension audits. AI writing assistants, meeting summarizers, and similar tools frequently arrive as browser extensions rather than standalone applications, and they process whatever the employee is working on at the time — often without anyone evaluating what data that includes.

A genuine amnesty period. The single highest-leverage move here is cultural, not technical: a defined window where employees can self-report tools they're already using without facing disciplinary consequences. Framing the inventory exercise as punitive guarantees people hide exactly the usage you most need visibility into. Framing it as "help us understand what's actually happening so we can support it properly" gets you the honest picture.

What this looks like in practice

A mid-size company runs its first inventory sweep expecting to find a handful of approved tools — a customer-support chatbot, an internal document search feature, maybe a coding assistant IT rolled out last quarter. The procurement-based pass turns up exactly that: four systems, all with contracts on file. The SSO log review turns up eleven more — a resume-screening add-on a recruiter started using through a free trial that never expired, a meeting-summarization extension half the sales team installed independently, and a "smart suggestions" feature inside the CRM that got silently enabled in a vendor update six months earlier and has been influencing which leads get flagged as high-priority ever since. None of those eleven were malicious or even particularly risky on their own — but not one of them had been risk-assessed, and the CRM feature in particular was making decisions that mattered without anyone having evaluated it. That gap between four and fifteen is the entire reason this exercise exists.

The inventory is a process, not a one-time snapshot

An inventory built once during a compliance sprint and never touched again is already stale the week it's finished — new tools get adopted, existing SaaS vendors quietly ship new AI features, and employees find new ways around whatever friction the last cycle left in place. The same lesson that applies to a risk management process or a governance program more broadly applies here just as directly: this has to be a maintained process with a real refresh cadence and a genuine intake step for new systems, not a document that gets filed away as evidence the exercise happened once. See our AI governance framework checklist for how the inventory plugs into the rest of a working governance program, and our AI governance committee guide for who should actually own keeping it current.