IT systems register behavior, not intent. That makes them a useful starting point for an inventory, and at the same time an incomplete source. Anyone who wants to build an overview of the AI that is actually being used must know which signals say something and which give a false sense of completeness.
Traffic to domains of AI providers is usually the most concrete signal available. A firewall or proxy records which domains are accessed, from which device, and with what frequency. This shows usage that nobody had to report. It does not show what happened in that interaction: what data was entered, for what task, with what result. Traffic to a chatbot domain can be a one-time test or a daily work routine. Without additional context, that distinction remains invisible.
Invoices, subscriptions and credit card charges show which tools were formally purchased, often outside official IT procurement. A team that takes out a subscription with a company card leaves a trail that procurement or finance can trace back. This signal is reliable for what has been purchased, but says nothing about free tools, trial versions or personal accounts used for work. More on what this trail concretely reveals is described on the page about procurement and licensing traces as a source for an AI inventory.
Single sign-on platforms and identity providers register which applications have been linked to a company account. This signal captures tools that gained access via OAuth to, for example, an email account or document environment. It is one of the few sources that also shows which permissions a tool has been granted, not just that it was used. The limitation: tools used without a connection, via a browser and a separate account, remain outside this.
Software installed on laptops and workstations is generally visible via the management platform IT uses for patches and updates. This shows installed AI tools, but misses everything that runs via a web browser without installation. For most AI applications used today, that is a substantial part of the total.
In organizations where developers work, the use of AI models via APIs is a separate trail. Management platforms of cloud providers and API gateways register which keys are active and what volume they process. This signal is often the most underestimated: a standalone script that calls a model for an internal task falls outside every conversation about "AI tools" because nobody recognizes it as such.
Each of these sources shows a part of the behavior, recorded by a system that was not designed for this purpose. None of these signals capture why a tool is used, for what task, with what type of data, or who is responsible for it. That is the reason why an inventory that relies only on technology gives a distorted picture. Why the list that IT provides structurally does not match what is actually being used is explained on the page about why the IT list is not correct.
Technical signals are a reason to ask, not a substitute for asking itself. An employee who uses a tool to draft texts, speed up an analysis or check code knows things that no log records: why he chose that tool, what he does with it, and what he would miss if it were shut down. That conversation only yields something if it is conducted without repercussions. How this is approached in practice is described on the page about asking questions without it feeling like accountability.
The value of network data, procurement traces, identity logs and conversations with employees only emerges when they are brought together in a fixed structure: which application, which role, which risk level, which owner. Without that structure, it remains a collection of separate observations. How that build-up proceeds step by step is described on the page about building an AI inventory, and what exactly needs to be recorded per application is on the page about the recording fields per AI application.
A complete overview of which AI is being used answers the question of overview and risk. It does not answer the question of how much of the work itself can be taken over by AI, and where that concretely plays out per task. Once it is clear which tools are deployed in which role, that follow-up question presents itself naturally. The werkscan from FTE TO AI calculates per task which part of the work can be taken over by AI, as a complement to the overview that the Responsible AI Scan provides.
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.