Shadow AI detecteren vraagt eerst instemming van de OR

Zet eerst de goedgekeurde tool neer, daarna de detectie. In een Nederlandse organisatie met een ondernemingsraad is de discovery-stap die elk leveranciersdraaiboek vooropzet juist de stap die instemming vraagt op grond van artikel 27 van de Wet op de ondernemingsraden, terwijl het alternatief dat u morgen kunt aanbieden geen instemming nodig heeft. De technische volgorde en de juridische volgorde lopen tegen elkaar in.

Dit stuk is geschreven voor de IT-manager, IT-directeur, informatiemanager of security officer bij een Nederlandse organisatie van ongeveer 250 tot 5.000 medewerkers. U heeft al een ICT-partner of een eigen infrastructuurteam, een ISMS met een auditkalender, en een ondernemingsraad, want de WOR verplicht die vanaf vijftig medewerkers. Wat er dit kwartaal van u wordt gevraagd is een maatregel tegen shadow AI. Wat u op het punt staat te kopen is een instrument om medewerkers te observeren. Dat is dezelfde aanschaf.

Waarom verplaatst blokkeren shadow AI naar een plek die u niet ziet?

De reflex is een proxyblokkade op de bekende AI-domeinen. Dat is goedkoop, het is zichtbaar voor de auditcommissie en het levert een schermafbeelding van een dichte deur op. Het doet niets aan de telefoon in de broekzak, en dat is precies het oppervlak waar dit gedrag naartoe schuift. Blokkeren verandert de plek van het werk, niet het werk.

Het faalt ook op eigen voorwaarden. Er komen wekelijks nieuwe tools bij, de interessantste verschijnen inmiddels als functie binnen iets dat al is goedgekeurd, en een groeiend deel loopt op dezelfde hyperscaler-infrastructuur die u niet in één keer kunt dichtzetten zonder uw productie mee te nemen. Een domeinlijst is een momentopname van de tools van vorig kwartaal.

Er zit een tweede rekening aan vast, en die komt bij u terecht. Is uw maatregel een muur, dan arriveert elk verzoek om AI in een echt proces te gebruiken als een verzoek om een uitzondering. Dus op uw bureau, ongedocumenteerd, onder tijdsdruk, van iemand die de keuze al heeft gemaakt. Dat is de wachtrij die u erft.

Wat ziet elke laag in uw omgeving werkelijk?

Wees hier precies in voordat u iets aanschaft, want de lagen verschillen enorm in wat ze observeren en daarmee in hun juridische behandeling. Van buiten naar binnen:

• DNS- en proxylogs: welk domein, welk intern IP-adres, wanneer, hoeveel verkeer. Onder TLS is de prompt zelf niet zichtbaar, dus u weet dat iemand een tool gebruikte en niet wat hij erin zette. De uitzondering telt: een inspecterende proxy die TLS ontsleutelt leest de prompt wel, en die hoort daarmee lager in deze lijst thuis in plaats van bovenaan.
• Een cloud access broker zoals Microsoft Defender for Cloud Apps: hetzelfde verkeer, verrijkt met een appcatalogus en een risicoscore per gevonden app, zodat u kunt goedkeuren of afwijzen. Nog steeds een beeld op appniveau.
• Browser data security, in Edge ingebouwd en in andere browsers een extensie, precies wat het shadow AI-implementatiemodel van Microsoft in stap één neerzet: die leest de inhoud van de prompt in de browser en classificeert gevoelige gegevens daarin, toegerekend aan een persoon met naam.
• Endpoint DLP: wat er vanaf een beheerd toestel is geplakt of geüpload naar een AI-site, ook per gebruiker.
• Insider risk-tooling: een gedragsscore per medewerker, opgebouwd uit de lagen hierboven.
• Een privételefoon op een mobiel netwerk: niets. Geen laag in uw omgeving ziet het, en geen inkoopbeslissing verandert dat.

Let op dat zichtbaarheid en juridisch gewicht samen oplopen. De laag die u iets bruikbaars vertelt over data die de organisatie verlaat, is de laag die leest wat een herleidbare medewerker heeft getypt. Dat is geen bijwerking van het ontwerp. Dat is het product.

Welke maatregel vraagt instemming van de OR en welke niet?

Artikel 27 WOR geeft de ondernemingsraad instemmingsrecht bij een besluit tot vaststelling, wijziging of intrekking van een regeling over het verwerken van persoonsgegevens van medewerkers (sub k) en van een personeelsvolgsysteem, in de wettekst voorzieningen die gericht zijn op of geschikt zijn voor waarneming van of controle op aanwezigheid, gedrag of prestaties (sub l). Onthoud die formulering, gericht op of geschikt voor, want daar rust het hele volgorde-argument op. Over hoe artikel 27 een AI-regel raakt hebben we eerder geschreven, dus neem die bepaling als gegeven aan. Het punt hier is smaller, en het bepaalt uw projectplanning.

Sorteer uw maatregelen op de vraag of ze een persoon observeren:

• Eén tool goedkeuren met een verwerkersovereenkomst en mensen zeggen die te gebruiken: een inkoop- en informatiebesluit. Geen personeelsvolgsysteem.
• Een proxyblokkade op een domeinlijst, zonder rapportage per gebruiker: een technische voorziening, waarbij het adviesrecht van artikel 25 lid 1 sub k in beeld komt en niet een instemmingsrecht.
• Rapportage per gebruiker over welke AI-apps iedere medewerker gebruikte: gericht op het observeren van gedrag. Sub l.
• Browser data security die promptinhoud per gebruiker classificeert: sub l, en onmiskenbaar.
• Een insider risk-score per medewerker: sub l, en de variant die een ondernemingsraad het scherpst zal lezen.

De enige maatregel die u volgende week kunt uitrollen zonder medezeggenschapstraject is dus de maatregel die het risico echt verkleint, en de maatregelen die maanden kosten zijn juist de maatregelen die het risico alleen meten. Dat is een ongebruikelijke en nuttige asymmetrie, en het is de omgekeerde volgorde van wat de leveranciersdocumentatie voorstelt.

Blijft u met een audit-only modus buiten een personeelsvolgsysteem?

Dit is de vraag die elke projectleider stelt zodra de kalender gaat schuren, en het antwoord is nee. De Autoriteit Persoonsgegevens zegt het onomwonden: gebruikt een werkgever een systeem niet om medewerkers te volgen maar zou dat wel kunnen, dan is het tóch een personeelsvolgsysteem. Geschiktheid is de toets, niet gebruik, en dat is het woord van de wet zelf en niet een uitleg van de toezichthouder daarbovenop. In de uitgewerkte voorbeelden van de AP staan software die internetgebruik registreert en logging van inzage in dossiers allebei expliciet.

Leg dat naast browser data security in audit-only modus. Die staat aan, de gegevens zijn herleidbaar, de rapporten bestaan, en tussen u en monitoring per medewerker staat alleen nog een schakelaar. Op de tekst van sub l valt dat eronder op de dag van installatie, niet op de dag dat iemand het dashboard opent. Van plan zijn de handhaving later aan te zetten stelt de instemmingsstap niet uit, het verplaatst alleen het moment waarop u er tegenaan loopt naar een slechter moment.

De verwerkingsgrondslag is een aparte kwestie met een eigen valkuil. Toestemming van een medewerker is een zwakke grondslag in een arbeidsrelatie, omdat de ongelijke verhouding weigeren moeilijk maakt. U zult dus leunen op gerechtvaardigd belang, en daarmee komen proportionaliteit en subsidiariteit in beeld: had u zicht op promptniveau nodig, of had appniveau de vraag ook beantwoord? Bij systematische controle van internetgebruik op schaal staat een DPIA op het kritieke pad vóór uitrol, niet erna.

Wat vraagt het gewijzigde artikel 4 nu van u?

De verplichting rond AI-geletterdheid is deze zomer gewijzigd, en de wijziging valt uw kant op. De Digital Omnibus over AI, Verordening (EU) 2026/1744, in werking sinds 27 juli 2026, heeft artikel 4 van de AI-verordening herschreven. Waar de oorspronkelijke tekst aanbieders en gebruiksverantwoordelijken vroeg een voldoende niveau van AI-geletterdheid te waarborgen, vraagt de gewijzigde tekst maatregelen te nemen die de ontwikkeling daarvan ondersteunen, met de toevoeging dat niets verplicht tot het garanderen van een bepaald niveau bij een individu. Het is een inspanningsverplichting geworden, en een tweede lid zet de Commissie en de lidstaten erachter.

Aan een plicht om ontwikkeling te ondersteunen voldoet u niet met een muur. U voldoet eraan met een route: een goedgekeurde tool, één korte regel die mensen kunnen navertellen, en training die de rollen bereikt die het daadwerkelijk gebruiken. Is uw AI-punt van dit kwartaal een blokkeerlijst, dan heeft u de maatregel gekocht die het slechtst scoort tegen de gewijzigde tekst en die de meeste medezeggenschapswrijving oplevert. Dat is een slechte ruil, en dat is nu ook aantoonbaar.

In welke volgorde zet een IT-manager dit neer?

Een volgorde die beide beperkingen respecteert, waarbij de langzame onderdelen vroeg beginnen in plaats van eerst klaar te zijn:

• Week één: keur één tool goed met een verwerkersovereenkomst en een beding dat inputs niet voor training worden gebruikt, publiceer de ene regel die zegt wat nooit ergens geplakt mag worden, en benoem bij wie men terecht kan. Geen instemmingstraject nodig, zolang de regel over dataklassen gaat en niet over gedrag van medewerkers of het loggen van gebruik. Schrijf hem over de data en hij blijft buiten artikel 27; schrijf hem over wat medewerkers mogen en hoe u dat controleert, en dat is niet meer zo.
• Week één, parallel: open het gesprek met de ondernemingsraad over de detectielaag en start de DPIA. Dit zijn de lange palen. Beginnen in maand vier is wat het programma over de jaargrens duwt.
• Week twee tot zes: discovery op appniveau, geaggregeerd gerapporteerd zonder toerekening aan personen, om de omvang te meten en te zien welke tools u vervolgens goedkeurt. Leg die aggregatie schriftelijk met de OR vast in plaats van er iets over aan te nemen.
• Na instemming: zicht per gebruiker, als de DPIA de noodzaak dan nog steeds draagt. In onze ervaring haalt het geaggregeerde beeld plus één goede goedgekeurde tool het grootste deel weg van wat het beeld per gebruiker moest vinden.
• Doorlopend: behandel elk verzoek om een uitzondering als kandidaat voor goedkeuring in plaats van als overtreding. Een wachtrij met uitzonderingen is een roadmap die uw gebruikers voor u schrijven.

Eén eerlijke opmerking over het bewijsmateriaal, want het getal dat u deze herfst in elke presentatie ziet is de PagerDuty Shadow AI Survey van juni 2026: 66 procent van de kantoorprofessionals zei AI op het werk te hebben gebruikt in de veronderstelling dat het beleid dat niet toestond, en 34 procent had klantgegevens in een publieke tool gezet. Het is een echt onderzoek met gepubliceerde methodologie, 1.250 respondenten bij bedrijven boven 500 miljoen dollar omzet, uitgevoerd door Wakefield Research. Het is uitgezet in de Verenigde Staten, het Verenigd Koninkrijk, Australië en Japan. Er zit geen enkele Nederlandse respondent in, en IT- en technologiefuncties zijn uitgesloten, dus u bent er zelf niet in vertegenwoordigd. Gebruik het als richting en niet als meting van uw eigen organisatie, want daar is die geaggregeerde discovery-ronde voor.

Waar wij hierin staan

Crux Digits is een AI-partner die naast uw ICT-partner werkt. Wij draaien uw servicedesk niet, uw endpoints niet en uw identiteitsplatform niet, en de detectiestack hierboven is van uw ICT-partner of van uw eigen team om te beheren. Wat wij doen is het goedgekeurde systeem bouwen en in productie zetten dat de detectievraag kleiner maakt. Daarom raakt deze volgorde ons net zo goed: een AI-implementatiepartner die uw medezeggenschapskalender negeert, levert u een systeem dat u niet mag aanzetten. Wilt u de regelkant eerder rond hebben dan de toolkant, begin dan bij de AI Act-risicocheck en het beleid dat u aan de OR moet laten zien.

Dit is geen juridisch advies en wij zijn geen juristen. De genoemde bepalingen zijn controleerbaar en gelinkt. Zodra uw shadow AI-programma monitoring of personeelsgegevens raakt, zet er een arbeidsrechtjurist naast.

Veelgestelde vragen