AI governance, the GDPR and legitimate interest

The data protection officer (DPO) at an engineering firm gets a short question from the board: we want to see which AI tools are in use and show staff a notice when they open a tool we have made a decision about, so what is our lawful basis? Her answer fits in two sentences. Then the real work starts.

For a private organisation the basis is usually legitimate interest. For a public authority it is public task. Employee consent, almost never. But the basis alone does not tell you whether the measurement is lawful as configured; that is for the balancing test to decide.

#Why isn't consent a good basis here?

Because consent under the GDPR must be freely given, and in an employment relationship it rarely is. Someone who depends on their employer cannot easily say no without wondering what it will cost them. European regulators have said so consistently.

There is a practical reason too: consent can be withdrawn, and a security measure that stops the moment one employee withdraws is not a measure but an offer.

#Which basis does fit?

The GDPR's recitals explicitly name network and information security as an interest that can be legitimate; keeping customer data out of an unassessed tool is close to that. But "can be" is not "is", and that is what the three steps test.

#Is a count without a user ID personal data at all?

What reaches the server from a measurement of AI use is a domain, a day and a device, with no user ID, no path and no content. That record does not by itself identify anyone. On the device, though, the observation starts in someone's browser, and in a team of four, "one person opens a transcription tool daily" can still point to somebody. How that one field, the user ID, separates measuring from tracking is explained in AI monitoring versus employee monitoring.

The sensible approach: treat the measurement as processing of personal data, document the basis and let the absence of an ID and of content count in the balance.

The same goes for notices. A notice in the browser for a tool the organisation has decided about is shown locally, based on the domain. What is counted afterwards is the outcome (shown, alternative opened, continued anyway), without an ID.

Highlighting sensitive data as you type does process text: in memory on servers in Europe, after which it is discarded. That is processing of personal data, usually customers', and its basis has to be recorded in any case.

#How does the three-step balancing test work?

The EDPB has published guidelines on it; at their core are three cumulative steps.

Step 1: is the interest legitimate? Lawful, present rather than hypothetical and specific enough to write down. "Knowing which AI tools are used, so we can decide per tool and keep customer data out of an unassessed tool" meets that. "Visibility of what employees do" does not: that is not an interest but a means without a purpose.

Step 2: is the processing necessary? Could the purpose reasonably be met with less? You do not need a per-person measurement to know which tools are in use; a count per tool is enough. You do not need to store content to show a highlight; processing in memory is enough. Every field you cannot justify weakens the case for necessity.

Step 3: does the interest outweigh the employee's? Here you look at what employees reasonably expect, how intrusive the processing is and which safeguards come with it. No user ID, no content, no per-person breakdown, a minimum group size, explanation in advance, a right to object that actually works: each of these safeguards shifts the balance. A notice that lets someone make a deliberate choice to continue weighs differently from a system that takes the action out of their hands.

All three must pass. If step 2 fails because the data contains an ID that serves no purpose, a good interest will not rescue it.

#Why does the outcome differ from one organisation and deployment to the next?

Because three things vary: who you are, what you switch on and why.

A municipality measures under public task and has no balancing test in the sense of point (f), but faces the same questions of necessity and proportionality; what that assessment looks like for a public body is set out in a DPIA for workplace AI. A healthcare organisation where health data can turn up in prompts also has to identify an Article 9 exception for whatever ends up in typed text incidentally. An engineering firm that only handles project data does not have that extra layer.

What you switch on matters just as much. Department insights off or on, notices only for not-allowed tools or also for tools without a decision, classification of the first prompt into a use-case category on or off: each setting changes what is processed, and so the balance. An assessment made for the default settings does not cover the extended ones.

The engineering firm therefore writes the assessment as three short paragraphs, with the settings it has chosen attached: count per tool, department insights off, notices on for not-allowed tools, highlights on in the supported apps. The DPO checks the text, an external lawyer reads it through once and the works council receives it along with the design. When the works council formally has a say is covered in when the works council must be involved in AI.

BeeSensible's own DPIA documentation states that the customer chooses and documents the basis; the usual routes are legitimate interest with a written assessment, and public task for public bodies. The usage data carries no user ID, the dashboard has no per-employee breakdown and department insights are off by default. That makes steps 2 and 3 easier; it does not make them unnecessary.

These are the figures the balance is about: counts and outcomes, with no individuals in them.