The board of an engineering firm asks its IT admin 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 reveals far more than anyone asked for.
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 more than surplus: it changes the nature of the measurement.
Which question are you actually answering?
Before choosing the data, pin down the question. In practice there are three. Which AI services are being opened across 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 no accident of wording; it is why measuring and tracking are two different things, as AI monitoring versus employee monitoring explains. Which of the resulting figures deserve a board's attention is covered in measuring AI adoption.
There is one question that does involve 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 from then on the measurement carries all the requirements of an investigation.
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 it needs and record only those.
There is a welcome side effect. 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 only briefly or justify it as a record of behaviour. What you do not record cannot leak, and nobody can ask to see it.
What do you need, and what can you leave out?
| Data item | Needed? | Why |
|---|---|---|
| Registrable domain of the service | Yes | Identifies the tool and links the observation to a decision in the register |
| Day of the observation | Yes | Lets you see a trend: this week, last month, since a decision |
| Count | Yes | Shows how widely a tool is used and whether that is growing |
| Category: use case or frequency bucket | Yes, as a count | Shows where AI fits into the work and whether it is experimentation or routine |
| Status of the tool in the register | Yes | Comes from the decision, not the measurement; together they give the share of use through allowed tools |
| User ID or email address | No | Adds nothing to the three questions and 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 people in a small group identifiable |
| Department | Only above a minimum size | Useful for targeted support, but a department of three might as well be a name |
The right-hand column is what matters. For every field you add, you should be able to say which of the three governance questions it helps answer. If the answer is none, drop the field.
Why is the path worse than it looks?
The domain chatgpt.com tells you someone opened ChatGPT. In many AI tools the full address also contains a conversation ID, and in search-style tools sometimes the question itself. Log "just the URL" and you are logging which conversation someone had, and occasionally what it was about.
That is the difference between a count and a file on someone, packed into one harmless-looking field. 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 is this: Copilot is the most frequently opened tool, but not the only one. ChatGPT and Perplexity show up every day, 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 anyone's list.
Nobody needs to know who opened them. The drawings tool handles client drawings, so a decision will follow. So will one for the transcription tool, which processes voices and names. The rest can wait. In three months' time the admin will check whether use has shifted towards the designated tools. None of it needs a single name in the file.
It also shows why a one-off inventory soon goes out of date: none of the three unknown tools was in a 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 worked out on the device itself and reported once a month as an anonymous count per category. To show what AI is used for, cloud mode classifies only the first prompt of a conversation into one of seven categories; the text is then discarded and only the category is counted.
In the dashboard this appears as figures about the organisation: which tools, how many, what share goes through allowed tools and what happened after a notice. There is no breakdown per employee anywhere.
