De eerste week na de livegang van een AI-assistent over de bedrijfsdocumenten levert bijna altijd hetzelfde incident op. Iemand vraagt naar "de beloningsstructuur" en krijgt een samenvatting van de salarislijst van de hele afdeling.
Een interne AI-zoekfunctie is een taalmodel dat vragen van medewerkers beantwoordt op basis van de eigen documenten van het bedrijf: SharePoint, netwerkschijven, het DMS, de wiki. Het model zoekt eerst de relevante passages op en schrijft daar een antwoord mee. Daardoor maakt het alles vindbaar waar een medewerker technisch bij kan, ook als die medewerker het nooit had kunnen vinden. Rechten die jarenlang te ruim stonden, zonder dat iemand het merkte, worden op die dag zichtbaar.
Waarom maakt een interne AI-zoekfunctie oversharing zichtbaar?
Oversharing ontstaat niet door AI. Het ontstaat door jaren van "deel even met iedereen", mappen die rechten erven van een te ruime bovenliggende map, en teamsites zonder eigenaar. Zolang zoeken handwerk was, bleef dat onzichtbaar: niemand bladert door 40.000 bestanden op zoek naar een salarisoverzicht.
Een AI-zoekfunctie bladert wel. Microsoft schrijft het zelf zonder omwegen in de documentatie over privacy en beveiliging van Microsoft Copilot (voorheen Microsoft 365 Copilot): Copilot toont alleen organisatiedata waarvoor de gebruiker "at least view permissions" heeft. Google zegt hetzelfde over Gemini in Workspace: als je geen toegang hebt tot een document, haalt Gemini het niet op. Dat klinkt geruststellend, maar het is precies het probleem. De assistent respecteert de rechten, en de rechten zijn fout.
Microsoft heeft er een aparte rapportage voor gebouwd. De data access governance reports zoeken naar sites, mappen en bestanden die "effectively public" zijn omdat ze gedeeld zijn met de ingebouwde groep "Everyone except external users". Die groep bevat automatisch elke interne gebruiker. Een HR-map die ooit met die groep is gedeeld, staat open voor de stagiair van vorige week.
Is het een datalek als een collega via AI een HR-dossier ziet?
Een collega die via AI een HR-dossier ziet, is volgens de definitie van de AVG een datalek. Artikel 4, punt 12 van de AVG noemt een inbreuk in verband met persoonsgegevens onder meer "de ongeoorloofde toegang" tot verwerkte gegevens. De Autoriteit Persoonsgegevens schrijft op de pagina wat is een datalek dat het gaat om toegang "zonder dat dit mag of zonder dat dit de bedoeling is", en noemt als voorbeeld letterlijk "inzage in een medisch dossier door een onbevoegde medewerker".
Of je het datalek binnen 72 uur bij de AP moet melden, is een tweede vraag. De AP noemt op de pagina datalek: wel of niet melden "een verkeerde collega of afdeling binnen uw eigen organisatie" als betrouwbare ontvanger, wat de ernst kan verminderen. Op dezelfde pagina staan gezondheidsgegevens en informatie over beroepsprestaties als categorieën met een hoog risico. Een verzuimdossier of een beoordelingsgesprek dat bij de verkeerde collega belandt, is daarom geen randgeval.
Twee dingen gelden altijd. Je legt elk datalek vast in je eigen register, ook als je het niet meldt. En de te ruime rechten zelf zijn een probleem onder artikel 32 AVG, dat passende beveiliging eist tegen "unauthorised disclosure of, or access to" persoonsgegevens. De AP en de EDPB hebben zich nog niet specifiek uitgesproken over AI-assistenten die overgedeelde inhoud tonen. De redenering hierboven is de onze, gebaseerd op de definitie.
Wat lost de standaardoplossing van Microsoft wel en niet op?
Het implementatieadvies van Microsoft begint met "Remediate oversharing": een assessment van sites met te grote doelgroepen, gebroken overerving en sites zonder eigenaar, gevolgd door toegangsreviews per site. Dat is goed advies, en het is ook gewoon werk. Iemand moet per site beslissen wie erbij mag.
Omdat dat tijd kost, biedt Microsoft een tussenoplossing: Restricted Content Discovery. Die haalt gevoelige sites uit de zoekresultaten van Copilot. De documentatie is eerlijk over de grenzen: de functie "doesn't change existing permissions", is bedoeld als "temporary governance control", en bij sites met meer dan 500.000 items kan een wijziging meer dan een week duren voordat die in Copilot zichtbaar is. Je verbergt de inhoud voor de assistent. De medewerker die het bestand rechtstreeks opent, ziet het nog steeds.
| Maatregel | Wat het doet | Wat het niet doet |
|---|---|---|
| Restricted Content Discovery (Microsoft) | haalt sites uit Copilot-resultaten | rechten herstellen; het is tijdelijk |
| Toegangsreview per site | herstelt de rechten zelf | schaalt niet zonder site-eigenaren |
| Labels en DLP (Purview) | sluit gelabelde inhoud uit van Copilot | ongelabelde oude bestanden vinden |
| Eigen zoeklaag met toelatingslijst | indexeert alleen bronnen die je expliciet aanzet | oversharing binnen die bronnen oplossen |
Hoe dwingt een zoeklaag toegangsrechten technisch af?
Een zoekfunctie met retrieval-augmented generation, kortweg RAG, knipt documenten in stukken en slaat die op in een zoekindex. Toegangsrechten afdwingen betekent: bij elk stuk bewaar je welke groepen het mogen zien, en bij elke vraag filter je op de groepen van de vrager. Microsoft beschrijft dat patroon voor Azure AI Search als een filter dat "to every query" wordt toegepast. Elastic, OpenSearch en Qdrant hebben elk hun eigen variant. De OWASP Top 10 voor LLM-toepassingen noemt het ontbreken ervan als risico onder LLM08, Vector and Embedding Weaknesses, en adviseert "permission-aware vector and embedding stores".
Dat klinkt eenvoudig. In projecten gaat het op drie plekken mis.
Rechten in de index verouderen
De rechten worden bij het indexeren gekopieerd. Wijzigt iemand daarna de rechten van een map, dan weet de index dat pas bij de volgende synchronisatie. Microsoft schrijft in de documentatie over toegangscontrole op documentniveau dat wijzigingen pas zichtbaar worden "after that metadata is synchronized to the index", en dat wijzigingen die van een bovenliggende map erven "require an explicit refresh". Een rekenvoorbeeld: synchroniseer je de rechten één keer per nacht en haal je om 9.00 uur een vertrekkende manager uit de groep Directie, dan kan die tot de volgende ochtend directiestukken terugvinden. Dat is 21 tot 24 uur. Voor de meeste documenten is dat aanvaardbaar, voor een reorganisatiedossier niet.
Stukken erven de rechten van hun document niet vanzelf
Een document van 60 pagina's wordt al snel 150 stukken. Als de rechteninformatie alleen op documentniveau staat en niet naar elk stuk wordt gekopieerd, filtert de zoeklaag niets. Microsoft waarschuwt er zelf voor: zonder die projectie worden "chunk-level references" niet gefilterd. Deze fout blijft in zelfgebouwde prototypes makkelijk zitten, omdat hij in een demo met één gebruiker niet opvalt.
De groepen van de vrager
Haal de groepslidmaatschappen van de gebruiker op het moment van de vraag live op uit Entra ID of Active Directory, niet uit een kopie van gisteren. Dan is één van de twee kanten altijd actueel. De andere kant, de rechten op de documenten, blijft afhankelijk van de synchronisatiefrequentie.
Waarom een lokale zoeklaag?
Een eigen zoeklaag lost oversharing niet op. Hij erft dezelfde rechten als de bronsystemen, en een fout gedeelde map blijft fout gedeeld. Het verschil zit in drie ontwerpkeuzes die je bij een standaardassistent niet hebt.
Je begint met een toelatingslijst in plaats van alles. Een standaardassistent indexeert standaard de hele tenant en jij werkt daarna uitzonderingen weg. Een eigen zoeklaag indexeert alleen de bronnen die je expliciet aanzet: eerst de kwaliteitshandboeken en procedures, pas later de projectmappen, en de HR- en financiële mappen nooit, of alleen voor de groepen die er al bij horen.
Je logt elke opgehaalde passage. Welke gebruiker kreeg welk stuk uit welk document te zien, met welke rechten op dat moment. Dat is het bewijs dat je nodig hebt als iemand vraagt of een datalek heeft plaatsgevonden, en hoe je dat inricht staat in onze gids over audit trail en logging voor AI.
En de vragen zelf verlaten je netwerk niet. Medewerkers typen in een interne zoekfunctie precies wat ze nergens anders opschrijven: namen van collega's, klantproblemen, vragen over ontslagprocedures. Met een open-weight model op eigen hardware of in een Europese private cloud blijven zowel de documenten als de vragen binnen. Hoe zo'n opzet technisch in elkaar zit, staat in on-premise LLM implementeren.
Wanneer is Copilot met SharePoint Advanced Management de betere keuze?
Copilot met SharePoint Advanced Management is soms gewoon de betere keuze. Werkt je organisatie volledig in Microsoft 365, heb je al Copilot-licenties en zitten de gevoelige documenten op een klein aantal goed afgebakende sites, dan is de route van Microsoft sneller: SharePoint Advanced Management zit volgens Microsoft bij de Copilot-licentie inbegrepen, en de assessment wijst je de probleemsites aan. Een eigen zoeklaag bouwen loont daar niet.
De balans slaat om bij documenten buiten Microsoft 365, zoals een DMS, netwerkschijven, een ERP of een klantdossiersysteem. Of wanneer de vragen zelf gevoelig zijn. Of wanneer je moet kunnen aantonen welke passage aan wie is getoond. Begin in beide gevallen met dezelfde stap: draai een rapport van alles wat met "iedereen" is gedeeld, en ruim dat op vóór de livegang, niet erna. Hoe je de bredere beveiliging van AI-systemen aanpakt, staat in AI en databeveiliging. Voor de keuze tussen een kant-en-klare tool en maatwerk helpt een AI-kennisbank opzetten, en de bredere afweging staat in onze gids over lokale AI voor bedrijven.