A data protection officer reads the Dutch Data Protection Authority's guidance on AI literacy. Step one: map which AI systems you use. She opens the application inventory and finds Copilot, a contract management system with an AI summary, and the model customer service had built last year. Three lines. She knows there are more. She just does not know where to look.
The question sits at the front for a reason. In Aan de slag met AI-geletterdheid (January 2025), the Dutch DPA opens its cycle with identification: which AI systems do you use, who works with them, for what, and with which risks. NIST's AI Risk Management Framework says the same in GOVERN 1.6: mechanisms should be in place to inventory AI systems. And the Dutch government's Algorithm Framework opens its organisational measures with an overview of the algorithms you use (org-00).
Three frameworks from different directions, one starting point. The reason is plain. Without knowing which systems exist, you cannot decide who needs which training, which risk needs attention, or what belongs in the AI register.
Three kinds of AI, three kinds of source
The officer's inventory is not wrong. It was built from sources that can only find one kind of AI. A complete picture means keeping three kinds apart.
AI you build or deliberately buy. A forecasting model for planning, a chatbot on the website, a system that sorts applications. A decision came first, so there is a trail: a purchase order, a contract, a DPIA, a project plan.
AI inside software you already have. Your meeting tool has summarised calls since the last update, your CRM drafts emails, your PDF reader gained an assistant. Nobody made a new purchasing decision. The AI arrived with a version.
AI employees start on their own. A free ChatGPT account, a translation service, a note-taking tool, a browser extension with a writing assistant. Nobody requested it, so there is no trail in the paperwork. This is shadow AI, and in most organisations it is the longest list.
Six ways to find out
Go through procurement, contracts and data processing agreements. The best source for the first kind. What was bought on purpose is on paper somewhere. What is free, or paid for privately, is not.
Put the application inventory next to the release notes. For the second kind you have to check, vendor by vendor, which AI features were added in the past year and whether they are switched on. It is manual work, and it goes stale at the next update. Asking vendors directly, at contract renewal, helps.
Check IT administration and SSO logs. These show which tools run through the organisation's login. That is a good list of what you set up yourself, and so of the approved tools. Shadow AI by definition does not run through that login.
Check network and DNS logs. The proxy log shows chatgpt.com and a string of domains nobody recognises. But only for people in the office, and with no way to tell a free account from a business account on the same domain.
Ask employees. A round of questions per team or a short survey is the only source that tells you why people pick a tool, and what they miss in the one that is allowed. But people report what they are comfortable reporting. In the 2025 study by KPMG and the University of Melbourne, 57 percent of workers hide their AI use from their employer.
Observe where the work happens. Most AI use of the third kind runs through the browser, at the office and at home. Seeing which AI services get opened there also finds the tools nobody reported. The question is how much you record. For an inventory, the service's domain is enough; who opened it and what was on the page turns a count of tools into a record of people.
A longer comparison of these methods, and what each misses, is in how do you find out which AI tools employees actually use.
Why a one-off inventory falls short
The Dutch DPA calls its approach a cycle, and rightly so. Say the officer works through all six sources in October and counts 23 systems. By December the meeting tool has a new AI feature, the secretariat uses a transcription service that did not exist in October, and one tool has changed owner and with it its terms. The list of 23 is not wrong. It describes October.
For the first kind that is manageable: tie the inventory to procurement, and a new system is on the list before it is bought. For the third kind it does not work, because no decision comes first. There, the only way to keep the list current is to see continuously what gets opened. From shadow AI to a current AI register works this out further.
And a list on its own is not a policy. Only once each system has the organisation's position next to it does an employee know what is allowed, and does the officer know where the risk sits.
How it works with BeeSensible
BeeSensible covers the third kind, and the part of the second that becomes visible in the browser.
The extension notices when someone opens an AI tool, including one nobody ever requested. It records only the service's domain, at most once per day per device, with no user id, no path and no page content. This only happens when the organisation has switched on the AI module and the analytics setting.
Each observed domain is matched against a catalogue of 865 AI tools. For each tool it lists the vendor, the country, certifications, whether the tool trains on your data, whether a data processing agreement is available, an EU AI Act classification, documented incidents with a source, and a risk score across six dimensions. The officer does not have to research an unknown domain herself.
