An AI inventory is not a snapshot of what the IT department has purchased. It is an ongoing overview of what is actually being used in the organization to get work done, regardless of whether that use has been approved, purchased, or is even known to the department that formally decides on software. Anyone who wants to build an inventory that covers that difference must search in more places than most organizations are used to.
The list of approved applications is a logical starting point, but it only covers what has entered through a formal process. AI functionality also arrives through channels that are not recognized as a 'new application': an update to existing software, a browser extension, a feature activated by a supplier without separate notification. Why the IT list is not correct describes the mechanisms by which an inventory relying solely on this list is, by definition, incomplete. That does not mean the list is superfluous — it means it is one source among others, not the only one.
Invoices, subscriptions, and license counts tell a different story than the IT list, because procurement often takes place at the department level and does not always run through a central IT process. A team that takes out a subscription for a tool with an AI feature registers that with procurement or finance, not necessarily with IT. What procurement and licensing data reveal shows which patterns in this data point to AI use that has not yet been noticed elsewhere: recurring small subscriptions, tool naming, growth in data traffic to certain domains. This is not a substitute for direct inquiry, but a way to know where to direct that inquiry first.
Network traffic, DNS logs, and access management can provide clues about which services are accessed from company equipment. Not every signal is equally reliable: traffic to an AI supplier may indicate active use, but it may also indicate a background process that has nothing to do with daily work. Which IT signals are usable sets out which technical indicators offer a solid basis and which produce too much noise to serve as a foundation for an inventory. The outcome of these signals is a list of suspicions, not a confirmed overview — the confirmation comes from the people doing the work.
No technical signal and no procurement entry tells you why someone uses a tool, for which task, and whether the use is incidental or structural. That information only surfaces if employees are willing to share it. That does not happen automatically: anyone who suspects that answering the question 'which AI do you use' leads to a ban or a note in their file will answer evasively or not at all. How to ask employees without repercussions describes how to ask that question in a way that makes an honest answer more likely. This part of the inventory often yields the largest share of the applications that are not visible through any other source.
An inventory that only collects the names of tools is not usable for governance. More is needed per application: who uses the tool and for which task, what type of data is entered into it, whether the outcome plays a role in a decision about a customer, employee, or third party, and which supplier is behind it. What you need to record per application gives the fields needed to later classify an application by role and risk level, without having to repeat the inventory once that classification is requested.
In an organization with multiple locations, business units, or countries, the inventory process itself becomes a coordination problem: who asks, in what order, and how are the outcomes combined without departments correcting or smoothing over each other's answers. How to build an AI inventory in an organization with multiple units addresses that scale: where coordination gets stuck and how the outcomes of different units remain comparable.
An inventory, once built, is a snapshot at a moment in time. To keep it usable for executives, CIOs, and risk managers, it must be repeated and linked to a classification that fits the organization's existing risk structure. That part — inventorying, classifying by role and risk level, and connecting to governance — is what the Responsible AI Scan is working on. The scan is under construction; anyone interested can sign up for the waiting list.
An inventory answers the question of which AI is being used. Another, complementary question is what share of the actual work — task by task — can be taken over by AI. That question is answered by the work scan from FTE TO AI, which calculates, per task, what share of the work can be taken over.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.