An organization with multiple locations rarely has a single place where decisions about software are made. One location signs a license, another uses a free version of the same tool, and a third has a local IT partner who set something up without consultation. An AI inventory that wants to capture this must therefore not start from a single source file, but from multiple sources that complement and contradict each other.
Each location has its own history of procurement, its own suppliers, and often its own degree of independence in IT choices. What is an exception at head office may have become the standard at another location without anyone recording it. A central inventory that only questions head office therefore misses part of the picture by definition. Why the IT list is wrong explains why a central register rarely matches what is actually being used, and that problem grows larger as the number of locations increases.
The basis is the same for every location: which application is used, by whom, for which task, and based on which data. It is also relevant whether the application was procured locally or made available centrally, and whether there is a provider behind it that already documents how the system works, or whether the location assembled or adapted the system itself. That distinction determines who bears responsibility for exactly what happens. What you record per application describes this in detail, and the same recording applies regardless of location: only the way you retrieve the information differs per location.
With one location, it is manageable to simply ask around. With multiple locations, that is no longer workable without structure. Two sources are then usable side by side. The first is what the IT environment itself already shows: procurement records, license files and technical signals that point to AI use, even if no one has explicitly reported that use. What procurement and license data reveal shows which indications can be found there, and which IT signals are usable addresses the technical side of this: which traffic, which subscriptions and which integrations point to AI use that is nowhere formally recorded.
The second source is the employee. No technical scan captures why someone uses a tool, for exactly which task, or how often. Only the person doing the work knows that. With multiple locations, this means you need a way to ask that question in the same way everywhere, without one location feeling more controlled than another. How to ask without repercussions describes why that condition is decisive for the reliability of what you retrieve: whoever fears a consequence answers incompletely or not at all, and that effect is not necessarily distributed equally across locations with different cultures or management styles.
An application that was procured at location A and informally adopted at location B remains the same application with the same role and the same risk level. The inventory should therefore not be classified separately per location, but per application, with a note of where and by whom it is used. This prevents the same tool from being assessed differently in two places, and prevents a risk that has already been flagged at one location from going unnoticed at another. It is also relevant whether the location itself built or configured something based on an AI model, or whether it merely purchases a ready-made product. Are you a provider or a user helps make that distinction, and that distinction can differ per location, even when using the same underlying technology.
Once the data from the locations is in, the next step is to combine it into a single list without duplicates, with a clear role, a risk assessment and an indication of where it is used for each application. That overview forms the basis for determining which governance measures are needed and where they require attention first. Exactly how that overview is built and maintained depends on the size and structure of the organization; there is no fixed blueprint for every situation.
An inventory of AI use provides a picture of what is being done and with what. A follow-up question that often connects to this is what portion of that work can actually be taken over by AI, and what portion remains human work. That question is answered by the work scan from FTE TO AI, which calculates per task which portion qualifies for takeover.
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.