An organization with multiple locations rarely has a single procurement process, a single IT department, and a single way of working. Each location has developed its own habits, chosen its own suppliers, and embraced its own tools that turned out to be useful locally. The central IT list registers what has been licensed through the central procurement process. What a location has purchased itself, with a credit card or a local contract, is usually not included in it.
This is not necessarily a sign of poor management. It is a consequence of how organizations with multiple locations function: central control and local autonomy exist side by side, and AI tools are accessible enough to enter outside the central channel. A browser extension, a free account, a tool included in a team subscription — none of this goes through the department that maintains the IT list.
The extent to which the IT list deviates from practice depends on a number of factors that vary per location: how strictly the procurement policy is actually enforced, how much freedom teams have in choosing their own software, and how long a location has already been part of the organization. A recently acquired location often has a completely different toolset than the head office, and that toolset does not automatically disappear after a merger.
The nature of the work also plays a role. A location with a lot of customer contact uses different supporting tools than a location that mainly handles production or logistics. Generic AI assistants pop up everywhere, but specialized tools — for text, for data analysis, for planning — differ significantly per function and per location.
An inventory that does justice to this spread combines multiple sources, because no single source is complete on its own. Which IT signals are useful at an organization with multiple locations shows which technical traces — network traffic, single sign-on logs, device management — tell something different per location and therefore need to be consulted separately rather than assumed centrally.
Procurement and licensing data form a second source, and these too vary per location: some locations book software through central contracts, others through local cost centers that never reach the central administration. What procurement and licensing data reveal at an organization describes how this data, despite its incompleteness, still provides structure.
The third source is the employee, and this source is particularly important at organizations with multiple locations because local habits can often only be uncovered by asking. This only works if the question does not carry a threat of reprisal — people who are afraid of consequences will not mention the tool they use to work faster. How to ask employees without reprisal at an organization discusses how this question is asked so that it produces an honest answer.
The Responsible AI Scan records a limited set of data for each application found: which tool or service it concerns, at which location or department it is used, who manages or purchased the application, and what role the organization takes on in relation to it. This last question is not trivial: the same organization can be a user for one application and, for another, self-developed or heavily customized application, end up in the role of provider. Are you a provider or a user explains why this role is determined separately for each application, and why it can differ per location.
What is not recorded is a judgment about the location or the employee who uses the tool. The purpose of the inventory is a complete picture, not a list of deviations attributed to someone. Without that separation, no complete picture emerges, because no one cooperates with an inventory that can be used against them.
An inventory across multiple locations is never final. Locations change, tools are replaced, and a role that is "user" today can become "provider" tomorrow as soon as a tool is adapted or further developed internally. When does your role change describes which changes give reason to reassess the classification. How to build an AI inventory describes the buildup as a whole: from initial exploration per location to a structure that grows with the organization instead of starting over every year.
Once it is clear which AI applications are actually in use at each location, a follow-up question arises that goes beyond governance: what do these tools mean for the tasks people perform daily? The work scan from FTE TO AI calculates, per task, what portion of the work is eligible to be taken over by AI, offering an additional picture alongside the inventory: not just what is running, but also what that means for the organization of the work itself.
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.