An IT admin at an engineering firm is asked by the board how much AI is being used in the company. He has the proxy logs: every URL, every user, every timestamp, going back a year. He can answer the question. He just has to do it with a file that says far more than anyone asked.
The question needs four fields: the domain of the service, the day, a count, and a category. The user is not among them. Everything else in the proxy log is not merely surplus; it changes what kind of measurement this is.
Which question are you actually answering?
Before choosing data, it helps to state the question precisely. In practice there are three. Which AI services are opened in the organisation? Has a decision been taken on them? And is use moving towards the tools we have designated, or away from them?
All three are about services and about the organisation as a whole. None of them mentions a person. That is not a lucky turn of phrase; it is the reason measuring and tracking are two different things, as AI monitoring versus employee monitoring sets out. Which of the resulting figures are worth a board's time is covered in measuring AI adoption.
There is one question that does need a person: who did this, in a specific incident. That is an investigation, with its own procedure and its own legal basis. Keep it out of the measurement, or the measurement carries the requirements of the investigation from then on.
What does data minimisation mean for a measurement?
Article 5(1)(c) of the GDPR requires personal data to be adequate, relevant and limited to what is necessary for the purpose. It is usually read as a brake: collect less. For a measurement it works better the other way round. Start from the purpose, work out which fields that purpose needs, and record only those.
Something pleasant follows. A measurement that contains only domain, day, count and category says nothing about a person. You do not have to secure it like a personnel file, keep it short, or justify it as a record of behaviour. What you do not record cannot leak and cannot be requested.
Which data do you need, and which do you not?
| Data item | Needed? | Why |
|---|---|---|
| Registrable domain of the service | Yes | Says which tool it is, and links the observation to a decision in the register |
| Day of the observation | Yes | Makes a trend possible: this week, last month, after a decision |
| Count | Yes | How widely a tool is used, and whether that is growing |
| Category: use case or frequency bucket | Yes, as a count | Says where AI sits in the work and whether it is trial or routine |
| Status of the tool in the register | Yes | Comes from the decision, not the measurement; together they give the share through allowed tools |
| User id or email address | No | Adds nothing to the three questions, turns a count into a behavioural record |
| Content of the prompt | No | Says something about the person and the client, nothing about the tool |
| Path after the domain | No | Often contains a conversation id or part of the question |
| Time to the second | No | A day is enough for the trend; seconds make a small group traceable |
| Department | Only with a floor | Useful for targeted help, but a department of three is a person |
The right-hand column is the point. Every field you add should come with an answer to which of the three governance questions it improves. If the answer is none, the field goes.
Why is the path worse than it looks?
The domain chatgpt.com says someone opened ChatGPT. The full address behind it contains, in many AI tools, a conversation id, and in search-style tools sometimes the question itself. Whoever logs "just the URL" logs which conversation someone had, and occasionally what it was about.
That is the difference between a count and a file, packed into one field that looks harmless. The registrable domain is enough to know whether a service is used. The rest of the address is about the person.
What does this look like in practice?
The engineering firm settles on the four fields. After a month the picture looks like this: Copilot is the most opened tool, but not the only one. ChatGPT and Perplexity show up daily, and three specialised tools appear that nobody knew about: one that summarises drawings, a translation tool and a meeting transcription tool. Two of them have no decision yet, simply because they were never on any list.
Nobody needs to know who opened them. The drawings tool processes client drawings, so a decision is coming. The transcription tool processes voices and names, so there too. The rest can wait. In three months the admin checks whether use has shifted towards the designated tools. All of it without a single name in the file.
It also shows why a one-off inventory falls behind quickly: the three unknown tools were in no questionnaire, because nobody knew to ask about them.
How does this fit the way BeeSensible is built?
The extension notices when someone opens an AI tool and reports only the registrable domain, at most once a day per device, with no user id, no path and no page content. How often someone uses AI (daily, weekly, occasionally) is determined on the device itself and reported once a month as an anonymous count per category. For what AI is used for, in cloud mode only the first prompt of a conversation is classified into one of seven categories, after which the text is discarded and only the category counts.
In the dashboard that reads as figures about the organisation: which tools, how many, what share through allowed tools, and what happened after a notice. Nowhere a breakdown per employee.
