Asking about AI use without it feeling like accountability

At a single location you can still walk around and have the conversation. At multiple locations, with different managers and different cultures around what does and doesn't get reported, that no longer works. Then you need to find a way to ask the same question everywhere in the same manner, and that is exactly where it usually goes wrong: the question is asked as an inspection, and then no usable answer comes back.

Why the question itself is the problem

If you ask "do you use AI tools that have not been approved", you are asking someone to admit that he is breaking the rules. The answer you get then is almost always no, even when that isn't true. Not because people lie for the sake of lying, but because the question is phrased in such a way that an honest answer becomes a confession. That applies to the employee who uses a chatbot to draft emails, and it applies even more strongly to the branch manager who purchased a tool outside of IT, because it was faster than submitting a request.

The question that does work is not about permission but about use: what work do you do, and what helps you with it. Not a question about violation, a question about practice. That changes not only the tone, it also changes what people dare to report.

What you record, per report

A usable overview does not consist of impressions but of a limited set of data, collected consistently:

Name of the application. Not the category ("a chatbot"), but the specific product or service.
Who uses it. A team, a role, a location — enough to be able to follow up later without it becoming an interrogation.
For what. The type of task: drafting text, analyzing data, answering customer questions, writing code. This partly determines the risk level later on.
What data goes into it. Only internal notes, or also customer data, personal data, financial information. This is often the most important item in the entire inventory.
How it was acquired. Through IT, through a departmental budget, a free account, or bundled with another software package.

You shape these five points into a fixed questionnaire that is the same everywhere, so that location A and location B produce comparable data. What exactly you record per application and why is set out on the page about what you need to record per application.

Where you get it from besides the employee

The question to employees is one source, not the only one. Invoices and license overviews often show which AI subscriptions are running somewhere, even without anyone reporting it; what purchasing and license data reveal at an organization with multiple locations is that each location has its own purchasing pattern, and that deviations in it often stand out sooner than in a conversation. In addition, IT signals that are useful at an organization with multiple locations provide a second line: network traffic to known AI services, new browser extensions, requests for API access. None of these sources is complete on its own. Together they provide a picture that is more reliable than what a single channel can produce, and that also makes it easier not to burden the employee as the sole checkpoint.

The promise you must make in advance

Without a clear agreement that reporting does not lead to a sanction, shadow AI remains shadow. This does not mean that there are never consequences — if an application turns out to be a risk, something must be done about it — but that the reporting itself is never the starting point of a problem. That separation between reporting and assessing must be communicated in advance, not explained afterward. How you build up that inventory step by step, including the order of questions and sources, is described on the page about building an AI inventory.

Role and risk level, not immediately judgment

Once an application is in view, the next question is not "is this allowed" but "what is this". Is the organization a user of an external system here, or in certain cases actually a provider — for example because a team trained its own model or substantially modified an existing system. That distinction determines which obligations apply and who is responsible for them; it is set out on the page that distinguishes provider and user roles. Even within the role of user, the position can change — a modification, a new application of existing data — which can be read on the page about the moment your role changes. Both questions belong to classification, not to the first conversation with employees. First the overview, then the classification.

From overview to impact estimate

An inventory of what is being used does not yet tell you how much work is tied to it or what changes if an application falls away or is expanded. For that question — what part of the work in a task is taken over by AI, and what part is not — the work scan from FTE TO AI is intended. It calculates per task how the division between human and AI looks, based on the tasks as they are currently carried out, not based on an estimate made in advance.