AI governance without monitoring employees

A municipal CISO wants to know whether the AI policy is working. Copilot was chosen as the preferred route a year ago, and he wants to see whether people are actually using it. The DPO hears the plan and says one thing: not per person. That same week, the chair of the works council asks the question every works council asks: will you be able to see what I do?

All three are right, and their positions do not conflict. 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 carry out checks under certain conditions: there has to be a purpose, the checks may go no further than necessary and they must be explained in advance, as our article on whether your employer can monitor your AI use sets out. The point here is a different one: the governance question does not need that kind of monitoring, so you do not have to meet its conditions either.

#Why are aggregated figures enough?

Because a decision about a tool does not get any better with a name attached. Walk through the questions involved in governing everyday AI use, as listed in our introduction to AI governance.

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 go through the designated route? The share through allowed tools, and its trend. Can you demonstrate it? The same figures, linked to a measure.

None of the six needs a name. 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 meaningful is covered in measuring AI use; the minimum set of fields is worked out in which data you really need to measure AI use.

One question does need a person: who did this, in a specific incident. That is a question for an investigation, with its own procedure and legal basis, and it does not belong in the measurement. Design the measurement to serve that investigation and every count becomes a potential case 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. On the server side, a count without a user ID largely falls outside that rule, but the principle holds even without the law: a measurement whose purpose is on paper cannot quietly turn into something else later.

Write the purpose as one sentence that names the goal, not the method. "Knowing which AI tools are in use and whether use goes through allowed tools, so we can decide per tool" is a purpose. "Visibility into what employees do" is not. Add what the figures must not become: a way of calling someone to account, or input for a performance review.

It also needs a legal basis and, for most organisations, a short three-step assessment. How that works, and why employee consent is rarely the basis, is explained in AI governance, the GDPR and legitimate interest.

#Where does aggregation stop protecting?

With small groups. A count without an ID can still point to 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 why you do two things: organisation-level figures as the default, and a floor on every breakdown, in both the number of people and the number of days. The days matter as much as the people: a department of twenty in which only one person happened to work on a given day is, on that day, a single person.

It is also why you should be honest about what aggregation promises. Keeping the user ID out of 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 context can identify people too. So tell employees and the works council what is never recorded by design and which floor applies, and say no more than that.

Here are the five choices side by side, with where each one lives:

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 per-person measurement clearly falls under it. A count without an ID is less clear-cut, and the sensible route is to put it to the works council for consent anyway. Our article on when the works council must be involved in AI explains when consent is and is not required, and what the arrangement should contain.

For this article one thing matters: what the works council gets to see. Not a promise that privacy will be 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 bases the measurement 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 it gets a decision; the transcription tool processes voices and names, so that one does too. Nobody needed to know who opened them.

Then, after the first board report, comes the question that always comes: can we see this per team, so we know where to focus the explanation? 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 to 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 worked out on the device itself and reported once a month as an anonymous count per category. If someone opens a tool the organisation has decided on, that decision appears in the browser, with the approved alternative as the first button; whether they can still continue is up to the organisation. What happens next is counted per tool, without an ID. Highlights of sensitive data are counted with their outcome, again without an ID; at most, a department is added on the server.

The dashboard presents all this as figures about the organisation and has no per-employee breakdown anywhere. Department insight is off by default; anyone who switches it on sees a department only once it reaches five people and seven days, and smaller departments are grouped under "Other". Accountability sets those same figures against the provisions of the GDPR, NIS2 and the AI Act, stating for each provision what the figures do not cover.