A list of names of AI tools is not an inventory. An inventory only comes into being when you record the same set of data for each application, so that you can compare them side by side, classify them, and demonstrate them later. Without that fixed structure, you end up with a collection of separate facts that no one can compare anymore.
Per application, it comes down to a limited number of fields that keep recurring.
Name and form. Is it a standalone subscription, a function within existing software, an internally built model, or an AI function that came along via a supplier without anyone labeling it as "AI."
Who uses it. A team, a department, an individual employee. This determines not only the scale, but also who you will later need to speak to when questions arise.
What it is used for. Not the supplier's marketing text, but the actual task: drafting text, summarizing data, writing code, answering customer questions, preparing decisions. This field determines the role the application plays and, with that, the risk level.
What data goes into it. Personal data, customer data, financial information, internal documents, or no sensitive data. This determines which governance requirements become relevant.
How it was acquired. Through a formal process, through a subscription someone took out on their own, through a supplier that bundles it with another product. The acquisition route immediately tells you something about how much oversight there already was.
Who is responsible for it. Not who happens to use it, but who can be held accountable if something goes wrong or if you want to know whether it is still in use.
Since when and for how long. An application that has been running unnoticed for three years calls for a different approach than a pilot from last month.
These are not bureaucratic checklists. This is the data you need in order to be able to say, per application: this falls under a higher risk level, this does not, and here is the substantiation.
None of these fields is fully available in a single source. You build the inventory from multiple channels that complement each other.
The IT department provides a starting point, but not a complete picture: why the IT list is not accurate explains that a significant part of AI use falls outside the systems IT manages. Still, the signals IT does have are useful as a filter: which IT signals are usable shows which technical indications are reliable enough to follow up on.
Procurement and finance fill in another part. Invoices, subscriptions and licenses show which tools were actually paid for, even if the user never reported it. What procurement and license data reveal describes which fields from this source fit directly into the inventory.
The last and most decisive part comes from the employees themselves. Whoever performs the task knows which tool is used for it, even if it was never requested or approved. You only get that information if asking the question has no consequences for whoever answers: how you ask without it being held against them describes how that question is asked without it feeling like a check-up.
An inventory that has to be complete all at once will never come about. Applications change, new tools appear, old ones disappear again. What remains is the structure: the same fields, the same questions, the same way of recording. That structure makes it possible to add an application that is missing today tomorrow, without having to start over.
This is also why the order in which you fill in the fields matters less than the consistency with which you fill them in. An organization with multiple locations, departments or subsidiaries runs into an additional layer of complexity here, because the same application is used differently in one location than in another: how you build an AI inventory at an organization with multiple units discusses how you keep those differences visible without losing comparability. Anyone who wants to know specifically, within such a structure, which fields need to be filled in separately per location will find that in what you record per application at an organization with multiple units.
Once the fields per application have been filled in, it becomes possible to classify: what role does this application fulfill, what risk level fits with that, and which governance measures logically follow from it. That step is based on what has been recorded, not on an assessment made afterward.
This inventory describes which AI applications exist and who uses them. It does not describe how much of the underlying work is actually taken over by that application. That is a different question, with a different tool: the work scan from FTE TO AI calculates, per task, which part of the work can be taken over by AI, based on the tasks you record, not on the tool used for it.
The AI scan here is still under construction. Anyone who wants to use one of these instruments as soon as they become available can sign up for the waiting list.
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.