AI-gebruik in jouw organisatie dat je niet ziet

Shadow AI is generatieve-AI-tooling die medewerkers gebruiken buiten formele goedkeuring en buiten het zicht van IT en security. Een consumer-LLM in de browser, een AI-extensie in de mailclient, een plugin-stack op een persoonlijk account dat bedrijfsdocumenten leest. Geen aanvraag, geen contract, geen logging, geen data-classificatie. Het is geen incident, het is een patroon. En de meeste CIO's onderschatten hoe diep het al in de organisatie zit.

Waarom medewerkers buiten de governance om werken

Het is verleidelijk om shadow AI te framen als een handhavingsprobleem. Een gebruiker die de regels overtreedt, een afdeling die zich onttrekt aan beleid. In de praktijk zie ik iets anders. Shadow AI ontstaat vrijwel altijd op plekken waar de formele route te traag, te beperkt of te onduidelijk is. De jurist die een contract wil samenvatten. De marketeer die een eerste tekstversie wil. De analist die een dataset wil verkennen. Ze vragen niets aan IT omdat ze het antwoord al kennen, of denken te kennen: dat duurt weken, het wordt waarschijnlijk afgewezen, ik los het zelf wel op.

Dat is geen disciplineprobleem. Dat is een symptoom van een ontbrekende sanctioned route. Als de officiële weg trager is dan de schaduwweg, kiest de organisatie de schaduwweg. Niet uit kwade wil, maar uit productiviteitsdruk. Een verbod bovenop diezelfde situatie verschuift het gedrag alleen verder uit het zicht. Browser-tools en consumer-accounts laten geen sporen achter in de gangbare IT-monitoring. Het werk gebeurt op privé-apparaten, in privé-tabs, met privé-mail als hub. Je ziet de output verschijnen in een Teams-bericht of een document, maar de route ernaartoe blijft onzichtbaar.

Het tweede gevolg van een verbod is juridisch onaangenaam. Onder de EU AI Act (Verordening (EU) 2024/1689) ben je als organisatie verantwoordelijk voor het AI-gebruik in je processen, ook als dat gebruik niet door jou is gesanctioneerd. De Autoriteit Persoonsgegevens heeft meermaals duidelijk gemaakt dat het invoeren van persoonsgegevens in een consumer-LLM als een doorgifte gezien wordt, met alle AVG-verplichtingen die daarbij horen. Een verbod-op-papier dat in de praktijk genegeerd wordt, is geen verdediging. Het is een verzwarende omstandigheid.

Waarom verbieden niet werkt

Drie redenen waarom het verbodsmodel structureel faalt. Eén: handhaving vereist zicht, en juist dat zicht ontbreekt. Een DNS-blokkade van bekende AI-domeinen vangt de grote namen, maar de markt groeit sneller dan je blocklist. Twee: het verbod raakt niet de oorzaak. Zolang de behoefte aan AI-ondersteuning reëel is en de officiële route ontbreekt, blijft het gedrag. Drie: het beschadigt het vertrouwen tussen security en de business. Een team dat een verbod krijgt op iets dat aantoonbaar werk specifiek meetbaar effect beschrijven, gaat security zien als blokkade in plaats van partner. Die positie kom je niet eenvoudig uit.

De NIST AI Risk Management Framework formuleert het scherp: AI-risico beheers je door governance te bouwen rond gebruik, niet door gebruik tegen te houden. Het uitgangspunt is dat AI-tooling onderdeel wordt van de organisatie, met dezelfde discipline die je hanteert voor andere data-verwerkende systemen. Wie wat mag gebruiken, op welke data, met welke logging, met welke escalatieroute bij twijfel. Het Britse NCSC schreef in zijn richtlijnen voor secure AI system development hetzelfde principe op een andere manier: secure-by-design betekent dat de veilige route ook de makkelijke route is.

Welke governance-laag werkt wel

De governance-laag die bij organisaties werkt, bestaat uit vijf onderdelen. In deze volgorde, want elk onderdeel bouwt op de vorige.

Acceptable-use policy met categorieën, niet met productnamen. Niet "tool X is verboden, tool Y is toegestaan", maar een classificatie naar gebruikstype. Welke data mag in welk type AI-systeem. Publieke informatie in een consumer-LLM is iets anders dan klantdata in een sanctioned enterprise-omgeving. Categorieën zijn houdbaar, productnamen verouderen binnen een kwartaal.

Een AI-gateway of proxy als technische uitvoering van dat beleid. Eén controlepunt waardoor AI-verkeer loopt, met logging op prompt- en responseniveau, met data-loss-prevention voor gevoelige patronen, met versiebeheer op modellen. Dit is geen filter dat alles tegenhoudt, dit is de sanctioned route. Hij moet sneller en bruikbaarder zijn dan de schaduwroute, anders herhaalt het probleem zich.

Data-classificatie als voorwaarde, niet als afterthought. Een AI-gateway zonder duidelijke labels op data is een logbestand zonder betekenis. Welke documenten zijn publiek, welke intern, welke vertrouwelijk, welke gereguleerd. Zonder die laag kan de gateway geen onderscheid maken tussen wat mag en wat niet mag.

Een AI-asset-register dat alle in gebruik zijnde systemen vastlegt. Niet alleen de sanctioned tools, maar ook wat je via discovery aantreft. Een register dat groeit en waarvan de items een eigenaar, een doel, een datacategorie en een risico-classificatie hebben. De EU AI Act vereist dit type registratie voor hoogrisico-systemen, maar als operationeel instrument is het breder bruikbaar.

AI Act-compliance als doorlopend proces. De verordening fase-eert verplichtingen tot in 2027 en verder. Verboden praktijken zijn sinds februari 2025 van kracht, transparantieverplichtingen voor general-purpose AI sinds augustus 2025, conformiteitsverplichtingen voor hoogrisico-systemen volgen daarna. Dit is geen project met een einddatum, dit is een operationele discipline die in je governance moet landen.

De volgorde is belangrijk. Een gateway zonder beleid is een technisch ding zonder besluitvormingskader. Beleid zonder gateway is papier. Beleid en gateway zonder data-classificatie laten beslissingen aan individuele gebruikers over. En zonder asset-register weet je niet wat je beheert.

Hoe je het in zicht krijgt

De eerste praktische stap is geen techniek, maar een gesprek. Met de afdelingen die het hardste roepen om AI-versnelling, en met de afdelingen waar je vermoedt dat het al gebeurt. Niet als audit, maar als verkenning. Welk werk willen ze sneller doen, welke tools hebben ze geprobeerd, waar liepen ze vast. Dit levert binnen twee weken een eerlijker beeld op dan een netwerkscan, en het bouwt mandaat voor de governance-laag die erna komt.

Daarna komt de discovery-laag. Logging op egress-verkeer naar bekende AI-API-endpoints, een browser-inventarisatie op extensies die LLM-functionaliteit bevatten, een check op SaaS-tools die AI-features hebben geactiveerd zonder dat dit in de oorspronkelijke contractscope viel. Veel organisaties ontdekken in deze fase dat hun bestaande SaaS-stack al AI-functionaliteit aan boord heeft die zij niet expliciet hebben goedgekeurd. Dat is ook shadow AI, alleen dan ingebakken.

Pas daarna komt de gateway en het beleid. Niet andersom. Een beleid dat is opgesteld zonder de realiteit te kennen, mist de aansluiting op het werk dat al gebeurt. En een gateway die wordt uitgerold zonder beleid, wordt door gebruikers omzeild zodra hij in de weg zit.

Wat dit betekent voor jou als CIO

Je hebt drie rollen tegelijk. Je bent verantwoordelijk voor het AI-gebruik in je organisatie onder de AI Act en de AVG, ook voor het gebruik dat je niet ziet. Je bent verantwoordelijk voor de productiviteit die AI kan leveren, en het uitblijven daarvan is ook een kostenpost. En je bent verantwoordelijk voor het vertrouwen tussen security en de business, dat fragiel wordt zodra de governance-laag wordt ervaren als rem.

Die drie rollen vragen één antwoord: een sanctioned route die sneller is dan de schaduwroute. Beleid in categorieën, een gateway als uitvoering, data-classificatie als basis, een asset-register als feitelijk overzicht, AI Act-compliance als doorlopende discipline. Niet als project, maar als operationeel ritme. Pas dan verdwijnt shadow AI niet omdat het verboden is, maar omdat de officiële route bruikbaarder is geworden.

Het werk dat je medewerkers willen specifiek meetbaar effect beschrijven met AI gaat door, met of zonder jouw goedkeuring. De vraag is alleen of het binnen of buiten je zicht gebeurt.