The CISO of a municipality wants to know whether the AI policy is working. Copilot is the preferred route, decided a year ago, and he wants to see whether people take it. The DPO hears the plan and says one thing: not per person. The same week the chair of the works council asks the question every works council asks: will you see what I do?
All three are right, and they are not in each other's way. The CISO's question is about tools and about the organisation: which are opened, how often, and whether use runs through the designated route. That question can be answered with counts, without anyone appearing in the data. That is what AI governance without monitoring employees means: you measure the use, not the people, and you set it up so that the line does not depend on good intentions.
What is the difference between insight into use and watching people?
Insight into use says: this service was opened three hundred times in the organisation this month, and no decision exists for it yet. Watching people says: this employee opened this service at these moments. The two can come from the same observation. The difference is one field, and that field decides whether you are processing employee data, which retention period makes sense, whether the works council has a right of consent, and whether people will start working around the measurement. How that one field works is set out in AI monitoring versus employee monitoring.
Watching people is not forbidden. An employer may check under conditions: a purpose, no further than necessary, explained beforehand, as can my employer monitor whether I use AI sets out. The point here is different: the governance question does not need that oversight, so you do not have to carry its conditions either.
Why are aggregated figures enough?
Because a decision about a tool does not get better with a name attached. Walk through the questions of governing everyday AI use, as what is AI governance lists them.
Which tools are in use? A list of domains and a count. Which have no decision yet? That same list next to the register. Which sensitive data comes through? Counts per data type and per app, without the text itself. Do people know what was decided? The number of notices and what happened next. Does use run through the designated route? The share through allowed tools, with its trend. Can you show it? Those same figures, tied to a measure.
None of the six needs a person. Whether the transcription tool needs a decision depends on what it processes and how widely it is used, not on who opened it. Which of those figures tell a board something real is in measuring AI adoption; which fields you need at minimum is in which data do you really need to measure AI use.
One question does ask for a person: who did this, in a concrete incident. That is an investigation question with its own procedure and legal basis, and it does not belong in the measurement. Build the measurement to carry that investigation and every count becomes a potential file.
What do you write down before you measure?
The purpose. Article 5 of the GDPR requires personal data to be collected for a specified, explicit purpose and not further processed in a way incompatible with it. A count without a user id largely falls outside that on the server, but the principle is sound even without the law: a measurement with its purpose on paper cannot quietly become something else later.
Write the purpose in one sentence that contains no means. "Knowing which AI tools are in use and whether use runs through allowed tools, so we can decide per tool" is a purpose. "Visibility into what employees do" is not. Add what the figures may not become: a way to confront someone, or a source for an appraisal.
A legal basis belongs with it, and for most organisations a short three-step assessment. How that goes, and why employee consent rarely is the basis, is in AI governance, the GDPR and legitimate interest.
Where does aggregation stop protecting?
At small groups. A count without an id can still point at someone if the group is small enough. "One person opens a transcription tool daily" is an anonymous figure in an organisation of four hundred and a name in a team of three. The id is absent in both cases; what differs is the group being counted.
That is the reason to do two things. Figures at organisation level as the default, and a floor on every breakdown, in number of people and in number of days. The days matter as much as the people: a department of twenty where one person happened to work on a given day is, on that day, also a person.
It is also the reason to be honest about what aggregation promises. No user id in the data is a structural safeguard: there is nothing an export, a changed setting or a support request could show per person, because the field does not exist. But "never traceable" is a promise no count can keep, because traceability also comes from context. So tell employees and the works council what is structurally not recorded and which floor applies, and say no more than that.
This is how the five choices sit side by side, with where each one lives:
| Design choice | What it prevents | Where it lives |
|---|---|---|
| The purpose first, in one sentence without a means | The figures acquiring a different purpose later | Agreement, on paper |
| Only domain, day, count and category | The measurement saying more than the question | Design of the measurement |
| No user id, no content, no path | An export or a setting showing it per person after all | Technology, in the data stream |
| A floor on breakdowns, off by default | A small group becoming a person | Setting, recorded in the arrangement |
| Putting the design to the works council | The line depending on whoever happens to be admin | Consultation, with the settings attached |
The third row is the only one that cannot be undone with a click. That is no accident: the choices that sit in the technology are the ones you do not have to guard every quarter.
What is the role of the works council?
Article 27 of the Dutch Works Councils Act gives the works council a right of consent over arrangements on processing employees' personal data and over facilities aimed at or suitable for observing behaviour or performance. A measurement per person falls under it without debate. A count without an id is less clear-cut, and the sensible route is to put it forward as an arrangement anyway. When that is and is not required, and what such an arrangement should contain, is in when must the works council be involved in AI.
For this article one thing matters: what the works council gets to see. Not a promise that privacy is respected, but the design. Which fields, whether an id is attached, who sees the dashboard, and which settings are fixed. A works council that has seen that becomes the best guardian of the line, because every change to those settings goes back to the table.
What does this look like in practice?
The municipality sets the measurement up on domain, day and count, leaves department insight off, writes the purpose down and puts the whole thing to the works council. After six weeks the picture looks like this. Copilot is opened most, as hoped. ChatGPT and Perplexity show up daily. And there are three tools that appeared in no overview at all: a tool that summarises council papers, a translation tool and a transcription tool for meetings. Two of them have no decision yet, because nobody knew they existed.
That is not an incident. It is what a one-off inventory always misses, and it is work for the CISO and the DPO together: the summarising tool sees council papers that are sometimes not yet public, so a decision follows; the transcription tool processes voices and names, so there too. Nobody had to know who opened them.
Then comes the question that always comes, after the first board report: can we see this per team, so we know where the explanation should go? The answer is not no. The answer is: that is a change to the arrangement, with a floor of five people and seven days, and it goes past the works council first. That keeps the line a decision of the organisation rather than a setting someone flips on a Tuesday afternoon.
How does BeeSensible's design enforce this?
By putting the choices from the table into the technology wherever possible. 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. If someone opens a tool a decision exists for, that decision appears in the browser, with the approved alternative as the first button, and continuing is always possible; what happened next is counted per tool, without an id. Markings of sensitive data are counted with their outcome, also without an id; at most a department is stamped on server-side.
The dashboard reads that as figures about the organisation, and has no per-employee breakdown anywhere. Department insight is off by default; whoever switches it on sees a department only from five people and seven days, and smaller departments fold into "Other". The accountability view ties those same figures to measures per framework, with an honest "Not substantiated" status where the figures do not carry a measure.
