An organization with multiple locations rarely has one IT environment. There is often a central contract for the major productivity software, but alongside that there are local purchasing budgets, regional IT administrators, and locations that take out their own subscriptions. Anyone looking for AI use within such a structure needs to know which signals actually mean something and which signals only give the impression of completeness.
The central IT department usually provides a license overview: which tools have been purchased, for which departments, and with which functions enabled. That overview is a starting point, not an end point. It shows what has been approved, not what is being used, and certainly not what has been added on top of that central offering at each location. One reason why the IT list is wrong is precisely this: approval and use are two different questions, and with multiple locations the gap between them grows with every additional site.
Within an organization with multiple locations, a number of signals diverge that would still coincide at a single location.
Billing is one. A credit card payment for an AI subscription may sit on the location's cost center rather than on the central IT budget. Anyone who only looks at the central procurement system misses this spending entirely.
Network traffic is another signal, and it does not behave the same way everywhere. A location with its own internet connection generates traffic that stays outside the central firewall logs. Traffic to known AI domains is then only visible if that location is connected to the same monitoring point as head office, and that is not always the case.
Browser extensions and standalone accounts form a third category. These are usually installed locally, on equipment managed by a regional IT staff member or sometimes by the user themselves. A centrally managed fleet of devices with uniform software rollout does reveal installations of this kind; a location with its own management does not, unless specifically asked about.
Finally, there is the question of who has access to what. A tool purchased centrally for one department can end up at other locations too, via shared login credentials, without this being recorded anywhere. Access management per location, to the extent it exists, gives an indication here, but not certainty.
None of these sources is complete on its own. Billing data shows spending, not use. Network logs show traffic, not intent or context. Access management shows who can log in, not who actually does so and for what. At a single location it is still manageable to lay these sources side by side; with multiple locations there is a risk that each site holds part of the picture and no one holds the whole.
Then there is the human source: asking employees and local managers directly. That signal is often the richest, because it shows not only what is being used but also for what purpose and how often. At the same time it is the most vulnerable signal, because it only works if people dare to answer honestly. How to approach that is described in how to ask without it leading to consequences.
The signals are useful, but without consistent recording they remain isolated observations. For every application found, it is worthwhile to note at least: which location or department uses the tool, who manages or purchased the application, what type of data is entered into it, and whether the application makes decisions independently or only provides support. This structure is worked out further in what you record per application, and the build-up of the full overview, from first signal to a coherent inventory, is described in how you build an AI inventory.
With multiple locations, the distinction between provider and user of an AI application is especially relevant, because a location sometimes adds AI functionality to a product or service itself, thereby taking on a different role than a location that only uses a ready-made tool. What that distinction entails is explained on are you a provider or a user, and when that role can shift, for example due to modifications a location makes itself, you can read on when does your role change.
The goal of this inventory is not completeness in one go, but a starting point that can be repeated. Locations change, subscriptions are renewed or discontinued, and new tools appear faster than an annual audit can track. An overview that combines the key signals and can be repeated per location provides more grip than a one-off snapshot.
Once it becomes visible which AI applications are being used within the organization, another question naturally follows: what those applications actually do to the work itself. The FTE TO AI work scan calculates, per task, what portion of the work can be taken over by AI, thereby building on the overview that the Responsible AI Scan produces.
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.