A data protection officer (DPO) reads the guidance on AI literacy from the Dutch Data Protection Authority (Autoriteit Persoonsgegevens, AP). Step one: map which AI systems you use. She opens the application inventory and finds Copilot, the model customer service had built last year and a contract management system with an AI summary. Three entries. She knows there are more; she just does not know where to look.
That question comes first for a reason. In its guide Aan de slag met AI-geletterdheid (Getting started with AI literacy, January 2025), the AP starts its cycle with identification: which AI systems do you use, who works with them, for what and with what 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 (Algoritmekader) opens its organisational measures with an overview of the algorithms you use (org-00).
Three frameworks, coming from different directions, with one starting point. The reason is simple. 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 DPO's inventory is not wrong. It was built from sources that can only find one kind of AI. Getting 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 been summarising calls since the last update, your CRM drafts emails, your PDF reader has acquired an assistant. Nobody made a new purchasing decision; the AI came with a new version.
AI employees start using on their own. A free ChatGPT account, a translation service, a note-taking tool, a browser extension with a writing assistant. Nobody asked for it, so there is no paper trail. 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 out of an employee's own pocket, is not.
Compare the application inventory with 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. It helps to ask vendors directly when a contract comes up for renewal.
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. By definition, shadow AI 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 per cent 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. Observing which AI services are opened there also turns up the tools nobody reported. The question is how much you record. For an inventory, the service's domain is enough; recording who opened it and what was on the page would turn a count of tools into a record of people.
A longer comparison of these methods, and what each misses, is in our article on finding out which AI tools employees actually use.
Why a one-off inventory falls short
The AP calls its approach a cycle, and rightly so. Say the DPO works through all six sources in October and counts 23 systems. By December, the meeting tool has a new AI feature, the secretariat is using 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 up to date is to keep track, continuously, of what is opened. Our article on moving from shadow AI to an up-to-date AI register goes into this in more detail.
And a list on its own is not a policy. Only when each system has the organisation's position next to it will employees know what is allowed, and the DPO know where the risk lies.
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 asked for. 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 over 1,000 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 DPO does not have to research an unknown domain herself.
