re-ai-gov Join the waiting list

Kennisbank

What you record per application in an organization with multiple locations

An organization with multiple locations usually doesn't have a shortage of AI use, but a shortage of overview. Each location makes its own choices, sets up its own subscriptions, or lets teams figure out for themselves what's useful. The result is a collection of applications that is nowhere written down in its entirety. Before there is anything to classify or report, that collection must first exist as a list — with the same fixed data per application, regardless of which location reports it.

Which data you need per application

For each application, you record in principle: the name and supplier, the location or department where it is used, who manages or purchased the application, what it is used for, what data is entered into it, and whether the application makes decisions independently or only supports them. That last distinction largely determines the risk level: a tool that rewrites text is assessed differently from a system that selects job applicants or evaluates credit applications.

With multiple locations, an additional field is added: whether the application was purchased locally or rolled out centrally. That distinction is needed to see whether the same risk has arisen independently in multiple places, or whether one decision has spread across the entire organization.

Why the IT list is not enough

The first place you would look is the IT department, and that list is a good starting point — but not the end point. Why the IT list doesn't add up at an organization with multiple locations explains that centrally managed licenses only cover part of the usage. Locations that use their own credit card for a subscription, or teams that deploy a free version of a tool, appear nowhere in a central administration. The overview you build must therefore combine multiple sources, not just one.

What purchasing and licensing data adds

Alongside the IT list, financial data gives a different kind of signal. What purchasing and licensing data reveals at an organization describes how invoices, subscriptions, and credit card expenses per location provide clues about applications that were set up outside central purchasing. This is particularly relevant with multiple locations: local purchasing often runs through different channels than central IT, and it is precisely there that the largest part of the incomplete picture arises.

What employees know that systems don't show

No list — technical or financial — tells you what an application is actually used for. Only the people who work with it daily know that. How to ask employees without repercussions at an organization discusses the condition that makes or breaks this step: anyone who feels an answer could have consequences will answer incompletely or not at all. With multiple locations, this is especially important, because local habits can differ significantly and a nationwide survey easily glosses over those differences.

Signals you already have in-house

Besides conversations and invoices, the existing IT environment often already contains clues that no one has recognized as such: network traffic to certain domains, new browser extensions, or API connections that were set up somewhere. Which IT signals are useful at an organization with multiple locations shows which of those signals say something about AI use and which are noise. For an organization with multiple locations, this is a way to see whether the same pattern repeats itself in different places, without each location being questioned separately.

From separate data to one overview

Once the data per application has been gathered — origin, purpose of use, data involved, manager, location — classification can begin. Not every application deserves the same attention: a tool that summarizes internal meeting minutes weighs differently than a system that affects customers or employees. That weighing depends on what the application does, not on how many people use it or when it was purchased.

This inventory is an ongoing process, not a snapshot. Locations add applications, suppliers change features, and what is supportive today may make independent decisions tomorrow. The overview you build must therefore be repeatable: the same questions, the same fields, each time again across the same locations.

The Responsible AI Scan is designed to structure this inventory: the same fixed fields per application, supplemented with IT signals, purchasing data, and conversations with employees, resulting in a classification that aligns with the organization's existing risk structure. The scan is under development. Anyone who wants to work with it as soon as it becomes available can sign up for the waiting list.

From overview to insight into the work itself

Once it is clear which applications are running per location and what they do, the next question naturally follows: what part of the work these applications support can actually be taken over by AI. That is a different question from governance — it is not about risk and demonstrability, but about task content. The work scan from FTE TO AI calculates per task what part of the work can be taken over by AI, and thereby connects to the overview you have built with this inventory.

Andrewde assistent van de Responsible AI Scan

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.