An overview of approved software tells you what has been purchased, not what is being used. Between those two lies a gap that grows as AI tools become more accessible: a browser extension, a free account, a chatbot that someone adopted on their own initiative to get a task done faster. What procurement and licensing data reveal is a starting point, not an endpoint. The rest of the answer lies with the people doing the work.
If you ask "do you use AI tools that have not been approved", you generally will not get a complete answer. Not because people want to hide something, but because the question implies a risk. Anyone who admits to using a tool that is not on the list expects a consequence: a warning, a conversation with a manager, a note in a file. That prospect is enough to make someone stay silent, even when the use is harmless and even useful.
The result is a skewed picture. Not because nothing is happening, but because what happens goes unreported. An inventory that relies solely on disclosures mostly records what was already known.
The question itself changes nothing if the context stays the same. What does work is a combination of elements: the question is decoupled from an individual performance review moment, the answers are not traced back to a name in a report that goes up the chain, and the purpose is explained beforehand — this is about an overview of the organisation, not a judgment of a person.
That does not mean no survey or conversation takes place. It means the question is asked within a framework in which "yes, I use this" does not trigger a correction. Only then does the answer shift from what someone thinks you want to hear to what is actually happening.
The output of a well-conducted conversation is not a list of tool names. It is a set of data that, per application, can be traced back to a task or process: which application, for which part of the work, with which data, and who else is involved with it. That is the same structure as what you need to record per application when an application comes into view via procurement or IT — only here the source is the user, not the contract.
Concretely, this means: an application name, a brief description of what it is used for, an estimate of how often, and an indication of the type of data entered into it. No technical specifications, no supplier assessment at this stage — that comes later, at the classification stage. At this point, it is about gaining visibility, not about passing judgment.
These conversations are one of the channels alongside the technical signals you consult separately. What you gather from users, you place next to which IT signals are usable as a separate track, and only when combined do they produce a more complete picture than either source delivers on its own. An application that shows up in the network logs but is not explained by anyone remains a question mark. An application that is mentioned in a conversation but leaves no digital trace is just as real — and perhaps for that very reason easier to overlook.
The order and repetition of this type of questioning depends on the organisation: how many departments, how many layers in the reporting lines, how much prior experience with this type of inventory. For an organisation with multiple locations or a layered structure, how you ask employees without it becoming a reckoning works slightly differently than for a single location with a flat structure, simply because there are more intermediate layers in which the "no repercussions" principle has to hold up.
An honest answer from employees is the raw material for the rest of the inventory. Without that raw material, you are classifying a list you already knew, and that is not an inventory but a confirmation. With that raw material, you can move on to how you build an AI inventory on a scale that extends beyond a single department or location, with input from multiple directions at once.
The tone of the question therefore partly determines the quality of the answer. That is not a matter of a cleverer phrasing, but of a structure in which answering carries no risk.
Once it is clear which applications are actually in use and for which tasks, the question shifts from "what are we using" to "what does that mean for the work itself". That is a different question, requiring a different instrument. The FTE TO AI work scan calculates, per task, what portion of the work can be taken over by AI, based on the tasks you have already mapped through this inventory. Where the Responsible AI Scan maps out usage and risks, the work scan looks at the content of the work: which tasks lend themselves to takeover, and to what extent. Those two questions are closely related, but they are not interchangeable.
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.