Shadow AI Detection Needs Works Council Consent First

Deploy the approved tool before you deploy the detector. In a Dutch organisation with a works council, the discovery step that every vendor playbook puts first is the step that needs instemming under article 27 of the Wet op de ondernemingsraden, while the sanctioned alternative you can offer staff tomorrow needs none. The technical order and the legal order run in opposite directions.

This is written for the IT manager, IT director, informatiemanager or security officer at a Dutch organisation of roughly 250 to 5,000 employees. You already have an ICT partner or an internal infrastructure team, an ISMS with an audit calendar, and a works council, because the WOR obliges one from fifty employees. What you are being asked for this quarter is a shadow AI control. What you are about to buy is an employee monitoring instrument, and the two are the same purchase.

Why does blocking shadow AI push it somewhere you cannot see?

The reflex is a proxy block on the known generative AI domains. It costs little, it is visible to the audit committee, and it produces a screenshot of a closed door. It also does nothing about the phone in the pocket, which is the surface most of this behaviour moves to. Blocking changes the location of the work, not the work.

It also fails on its own terms. New tools appear weekly, most of the interesting ones now ship as a feature inside something already sanctioned, and a growing share run on the same hyperscaler infrastructure you cannot blanket-block without taking production with it. A domain list is a snapshot of last quarter's tools.

There is a second cost that lands on you specifically. If your control is a wall, every request to put an AI tool into a real process arrives as a request for an exception, which means it arrives at your desk, undocumented, under time pressure, from someone who has already decided. That is the queue you inherit.

What can each layer of your stack actually see?

Be precise about this before you buy anything, because the layers differ enormously in what they observe and therefore in how they are treated in law. Working inward from the network:

• DNS and proxy logs: which domain, which internal IP, when, how much traffic. Under TLS the prompt itself is not visible, so you learn that someone used a tool and not what they put into it. The exception matters: an inspecting proxy that decrypts TLS does read the prompt, and that moves it down this list rather than keeping it at the top.
• A cloud access broker such as Microsoft Defender for Cloud Apps: the same traffic, enriched with an app catalogue and a risk score per discovered app, so you can sanction or unsanction. Still an app-level view.
• Browser data security, native in Edge and an extension in other browsers, which is what Microsoft's own shadow AI deployment model puts in step one: it reads prompt content in the browser and can classify sensitive information inside it, attributed to a named user.
• Endpoint DLP: what was pasted or uploaded to an AI site from a managed device, again per user.
• Insider risk tooling: a behavioural score per employee, built from the layers above.
• A personal phone on a mobile network: nothing. No layer of your estate sees it, and no procurement decision changes that.

Notice that visibility and legal weight climb together. The layer that tells you something useful about data leaving the organisation is the layer that reads what an identifiable employee typed. That is not a side effect of the product design. It is the product.

Which control needs works council consent, and which does not?

Article 27 of the WOR gives the works council a consent right over an employer's decision to introduce, change or withdraw a regulation on the processing of personal data of staff (sub k) and a personeelsvolgsysteem, which the statute defines as facilities aimed at, or suitable for, observing or checking the presence, behaviour or performance of staff (sub l). Hold on to that phrase, aimed at or suitable for, because the whole sequencing argument sits on it. We have written elsewhere about how article 27 catches an AI rule, so take the provision as read. The point here is narrower and it is the one that decides your project plan.

Sort your intended controls by whether they observe a person:

• Offering a sanctioned tool with a processing agreement, and telling people to use it: a procurement and information decision. No personeelsvolgsysteem.
• A proxy block on a domain list, with no per-user reporting: a technical facility, and the advice right under article 25 paragraph 1 sub k is the provision in view rather than a consent right.
• Per-user reporting of which AI apps each employee used: aimed at observing behaviour. Sub l.
• Browser data security that classifies prompt content per user: sub l, and squarely.
• An insider risk score per employee: sub l, and the version of it a works council will read most carefully.

So the one control you can ship next week without a medezeggenschap trajectory is the one that actually reduces the risk, and the controls that need months are the ones that only measure it. That is an unusual and useful asymmetry, and it is the opposite of the order the tooling documentation suggests.

Does audit-only mode keep you outside a personeelsvolgsysteem?

This is the question every project lead asks at the point the calendar hurts, and the answer is no. The Autoriteit Persoonsgegevens states it plainly: where an employer does not use a system to track staff but could do so, it is a staff tracking system anyway. Suitability is the test, not use, and that is the statute's own word rather than a regulator's gloss on it. The regulator's list of worked examples names software that registers internet use, and logging of who opened which file, both explicitly.

Read that against a browser data security control deployed in audit mode. It is installed, it is attributed, the reports exist, and the only thing standing between you and per-employee monitoring is a toggle. On the statutory wording that is inside sub l on the day it is installed, not on the day someone opens the dashboard. Planning to switch enforcement on later does not defer the consent step, it just moves the discovery of it to a worse moment.

The processing basis is a separate matter and it has its own trap. Consent from an employee is a weak basis in an employment relationship because the power imbalance makes it hard to refuse, so legitimate interest is what you will be relying on, which puts proportionality and subsidiarity in scope: did you need prompt-level visibility, or would app-level have answered the question. Systematic monitoring of employee internet use at scale also puts a DPIA on the critical path before deployment, not after.

What does the amended Article 4 now ask of you?

The AI literacy duty changed this summer and the change runs in your favour. The Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026, rewrote Article 4 of the AI Act. Where the original text asked providers and deployers to ensure a sufficient level of AI literacy, the amended text asks them to take measures to support the development of it, and adds that nothing requires a deployer to guarantee any specific level of literacy in any individual. It is an obligation of effort, and a second paragraph puts the Commission and Member States behind it.

A duty to support development is not discharged by a wall. It is discharged by a route: a sanctioned tool, a short rule people can recall, and training that reaches the roles actually using it. If your quarterly AI item is a blocklist, you have bought the control that scores worst against the amended text while attracting the most medezeggenschap friction. That is a bad trade and it is now demonstrably one.

In what order should an IT manager actually deploy this?

A sequence that respects both constraints, with the slow items started early rather than first:

• Week one: sanction one tool with a processing agreement and a no-training-on-inputs term, publish the one rule that says what must never be pasted anywhere, and name who to ask. No consent trajectory needed, as long as the rule addresses data classes rather than employee conduct or usage logging. Write it about the data and it stays outside article 27; write it about what staff may do and how you will check, and it does not.
• Week one, in parallel: open the works council conversation on the detection layer, and start the DPIA. These are the long poles. Starting them in month four is what pushes the programme into next year.
• Weeks two to six: aggregate app-level discovery, reported without user attribution, to size the problem and find the tools worth sanctioning next. Agree the aggregation with the works council in writing rather than assuming it.
• After consent: per-user visibility, if the DPIA still supports needing it. In our experience the aggregate view plus one good sanctioned tool removes most of what the per-user view was bought to find.
• Continuous: treat every exception request as a candidate for sanctioning rather than a breach. A queue of exceptions is a roadmap written by your users.

One honest note on the evidence base, because the number you will see in every deck this autumn is the PagerDuty Shadow AI Survey of June 2026: 66 per cent of office professionals said they had used AI at work believing policy did not allow it, and 34 per cent had put customer data into a public tool. It is a real survey with published methodology, 1,250 respondents at companies above 500 million dollars in revenue, run by Wakefield Research. It was fielded in the United States, the United Kingdom, Australia and Japan. There are no Dutch respondents in it, and it excludes IT and technology roles, which is to say it excludes you. Use it as a direction of travel and not as a measurement of your own organisation, which is what an aggregate discovery run is for.

Where we sit in this

Crux Digits is an AI partner that works alongside your ICT partner. We do not run your service desk, your endpoints or your identity platform, and the detection stack described above is your ICT partner's or your own team's to operate. What we do is build and put into production the sanctioned system that makes the detection question smaller, which is why the order in this post matters to us as well: an AI implementation partner who ignores your medezeggenschap calendar will hand you a system you cannot switch on. If you want the regulatory side sorted before the tooling side, start with the AI Act risk check and the policy you will have to show the works council.

None of this is legal advice and we are not lawyers. The provisions cited are checkable and linked; the moment your shadow AI programme touches monitoring or personnel data, put an employment lawyer next to the project.

Frequently asked questions