← terug

10 juni 2026

Bedrijfskennis veilig aan AI koppelen: wie wat mag zien geldt ook voor de assistent

Een medewerker van een gemeente vraagt aan de nieuwe interne AI-assistent: "Wat speelt er rond de herindeling van team vergunningen?" De assistent antwoordt keurig. Met daarin een samenvatting van een conceptnotitie van het managementteam, inclusief welke functies waarschijnlijk verdwijnen. Die notitie stond in een afgeschermde map. De medewerker had er nooit bij gekund via de verkenner of het zaaksysteem. Maar de assistent wel. En de assistent deelt graag wat hij weet.

Dit is geen hack. Er is geen wachtwoord gekraakt en geen firewall omzeild. Dit is wat er gebeurt als je bedrijfskennis aan AI koppelt en alleen nadenkt over de vraag of de antwoorden kloppen, niet over de vraag wie welke antwoorden mag krijgen.

Ik heb eerder geschreven over hoe RAG werkt en wat embeddings en vector databases technisch zijn. Die basis sla ik hier over. Deze blog gaat over de laag die in bijna elke pilot wordt overgeslagen en in bijna elk productiesysteem het echte werk blijkt: rechten, verwijdering, scheiding en logging.

De zoekmachine die alle schuttingen omver trekt

Eerst de kern van het probleem.

Elke organisatie heeft schuttingen in haar informatie. Soms bewust ontworpen: rechten op mappen, rollen in het DMS, afgeschermde dossiers. Maar minstens zo vaak onbewust: informatie was veilig omdat niemand wist dat het bestand bestond, omdat de bestandsnaam nietszeggend was, of omdat je tien keer moest doorklikken om er te komen. Beveiliging door onvindbaarheid. Het is nooit echte beveiliging geweest, maar het werkte wel, jarenlang.

Een AI-assistent met semantisch zoeken maakt daar in één klap een einde aan. Wie vroeger het exacte document moest kennen, stelt nu gewoon een vraag. "Wat verdient een teamleider bij ons?" vindt het salarisoverzicht dat per ongeluk in een algemene map stond, ook als het bestand "overzicht_v3_def_DEF.xlsx" heet. De assistent is de beste zoekmachine die je organisatie ooit heeft gehad. Dat is precies de bedoeling, en precies het risico. Alles wat ooit ergens verkeerd is opgeslagen, wordt vindbaar. Niet voor een aanvaller, maar voor iedere collega met toegang tot het chatvenster.

De misvatting die ik wil corrigeren is deze: veel organisaties behandelen "kennis koppelen aan AI" als een functionaliteitsvraag. Werkt het, zijn de antwoorden goed, is het snel genoeg. Maar het is in de eerste plaats een toegangsvraag. Je bouwt geen slimme assistent. Je bouwt een nieuwe toegangslaag tot al je informatie, en die laag moet minstens zo streng zijn als de oude.

Rechten gelden ook voor de AI

Het denkmodel dat ik organisaties meegeef is simpel om te onthouden: de assistent erft de rechten van de vrager. Niet andersom.

Technisch gaat het op dit punt vaak mis. Een RAG-systeem doorzoekt de kennisbank meestal met een eigen technisch account, een service account met een API-sleutel. Om alle documenten te kunnen indexeren heeft dat account brede leesrechten nodig, vaak op alles. Tot zover logisch. Maar als datzelfde brede account ook bij elke gebruikersvraag de zoekopdracht uitvoert, dan zoekt elke gebruiker in de praktijk met de rechten van het systeem. De stagiair zoekt dan met dezelfde reikwijdte als de directeur. Het indexeren mag breed. Het ophalen moet smal, namelijk zo smal als de rechten van degene die de vraag stelt.

Hoe doe je dat? Bij het indexeren sla je naast elke documentchunk metadata op: uit welk document komt dit, van welke afdeling, en wie mag het zien. Bij elke vraag weet het systeem wie er vraagt, en filtert het de zoekresultaten op die rechten voordat er ook maar iets richting het taalmodel gaat. Dit heet document-level permissions in retrieval, en het filteren moet op het moment van de zoekopdracht gebeuren, bij elke zoekopdracht opnieuw.

Die volgorde luistert nauw. Eerst filteren, dan pas naar het model. Een veelgemaakte fout is het omdraaien: alles ophalen, alles in de prompt stoppen, en het taalmodel instrueren om bepaalde informatie niet te noemen. Dat is geen beveiliging, dat is een verzoek. Taalmodellen zijn te overtuigen, te verwarren en te omzeilen. Informatie die een gebruiker niet mag zien, hoort de prompt nooit te bereiken. De grens trek je in de retrieval-laag, niet in de instructies aan het model.

En dan de vraag die elke implementatie lastig maakt: waar komen die rechten vandaan? Het eerlijke antwoord is dat ze uit je bronsystemen moeten komen, en dat die rechten daar lang niet altijd op orde zijn. Mappen waar half de organisatie per ongeluk bij kan, oud-medewerkers die nog in groepen staan, rechten die ooit "tijdelijk" zijn verruimd. Een AI-project legt dat genadeloos bloot. Ik zie het inmiddels als een wet: de assistent is zo veilig als het slechtst beheerde rechtenmodel eronder. Vaak is het opschonen van de bronrechten het grootste deel van het project, en dat is geen vertraging maar de eigenlijke klus.

Verwijderde en verlopen documenten

Tweede onderwerp waar pilots zelden over nadenken: wat gebeurt er als een document weggaat?

In de meeste organisaties heeft verwijderen een betekenis. Een dossier wordt afgesloten en geschoond, een oud beleidsstuk wordt vervangen, een document met persoonsgegevens wordt na de bewaartermijn vernietigd. Soms omdat het netjes is, soms omdat het moet vanuit de AVG.

Maar een RAG-systeem werkt op een kopie. De chunks en embeddings van dat document staan in de vector database, los van het origineel. Verwijder je het brondocument en doet je pipeline niets, dan blijft de assistent vrolijk antwoorden op basis van iets dat officieel niet meer bestaat. Het verouderde beleid van drie versies geleden. Het dossier dat vernietigd had moeten zijn. En omdat de assistent zo stellig formuleert, klinkt het verouderde antwoord net zo betrouwbaar als het actuele.

Je hebt dus een verwijderketen nodig: als het origineel weggaat of verloopt, moeten de bijbehorende chunks uit de index, en idealiter weet je ook hoe dat in backups en snapshots van de vector database zit. Dat vraagt om synchronisatie tussen bron en index, en om een test die je af en toe echt uitvoert: verwijder een testdocument en controleer of de assistent het daarna echt niet meer kent.

Hetzelfde geldt voor rechten die veranderen. Een medewerker wisselt van afdeling, een dossier wordt vertrouwelijk verklaard. Als de index niet meebeweegt met de bron, zoekt iemand volgende week nog met de rechten van vorige maand.

Scheiding tussen afdelingen

Derde punt: één assistent voor de hele organisatie klinkt efficiënt, maar dwingt je tot een keuze over scheiding.

Neem een zorginstelling. De behandelteams hebben kennis nodig over protocollen en medicatiebeleid. HR heeft personeelsdossiers. Financiën heeft contracten met leveranciers en zorgverzekeraars. Die werelden liepen nooit door elkaar, simpelweg omdat de systemen gescheiden waren. Stop je alles in één kennisbank, dan heb je die scheiding actief terug te bouwen.

Daar zijn grofweg twee manieren voor. De harde variant: aparte indexen of collecties per domein, zodat de zoekopdracht van een behandelaar technisch niet eens in de HR-collectie kan kijken. De zachte variant: één index met strikte filtering op metadata bij elke zoekopdracht. De harde variant is grover maar moeilijker fout te configureren. De zachte variant is flexibeler maar staat of valt met de kwaliteit van je filters en metadata, want één chunk zonder afdelingslabel valt buiten elke schutting. Welke je kiest hangt af van hoe gevoelig de domeinen zijn. Voor personeelsdossiers en patiëntgerelateerde informatie zou ik altijd voor harde scheiding kiezen. Een configuratiefout mag daar niet het verschil zijn tussen gescheiden en gelekt.

In Klai, de veilige AI-omgeving die ik bouw, is dit een van de redenen waarom kennis in gescheiden bronnen per team leeft en rechten bij elke vraag opnieuw worden gecontroleerd. Niet omdat dat technisch elegant is, maar omdat ik bij organisaties steeds dezelfde vraag op tafel zag komen: kan de assistent van afdeling A bij de stukken van afdeling B? Als het antwoord op die vraag "dat hangt af van een filter" is, slaapt niemand rustig.

Wie vroeg wat: logging als onderdeel van het ontwerp

Vierde punt, en in de praktijk het eerste dat sneuvelt onder tijdsdruk: logging.

Als iemand via de assistent informatie te zien krijgt die niet voor diegene bedoeld was, wil je dat kunnen reconstrueren. Wie stelde welke vraag, welke documentchunks zijn opgehaald, en wat is er geantwoord. Zonder die logging is elk incident een raadsel en elke audit een schatting. Met die logging zie je ook patronen: een account dat opvallend vaak naar salarissen of specifieke personen vraagt, valt op in een log en nergens anders.

Tegelijk is dat log zelf gevoelige data. Vragen van medewerkers verraden veel: wie naar de regels rond ziekmelding vraagt, wie naar een vertrekregeling informeert. En een retrieval-log bevat letterlijke fragmenten uit je documenten. Het log verdient dus dezelfde behandeling als de kennisbank zelf: beperkte toegang, een bewaartermijn, en een afspraak over waarvoor het wel en niet gebruikt wordt. Dit raakt aan de AVG en, afhankelijk van je situatie, aan de documentatiekant van de AI Act. Dit is geen juridisch advies, maar wel een technische realiteit: wat je niet logt, kun je nooit aantonen, en wat je wel logt, moet je ook weer beschermen.

De checklist

Wil je bedrijfskennis aan AI koppelen, loop dan deze vragen langs voordat er iets live gaat:

Geen van deze vragen gaat over het taalmodel. Dat is geen toeval: de modelkeuze is bij dit onderwerp de minst spannende beslissing.

Tot slot

Bedrijfskennis aan AI koppelen is geen kwestie van een kennisbank aansluiten en kijken of de antwoorden bevallen. Je bouwt een nieuwe deur naar al je informatie, en die deur zoekt beter dan alles wat je organisatie tot nu toe had. Dat is de waarde en het risico tegelijk.

De demo is makkelijk: alles indexeren, alles doorzoekbaar, iedereen onder de indruk. Productie is waar het serieus wordt: rechten die meereizen tot in de zoekopdracht, documenten die echt verdwijnen als ze verwijderd worden, afdelingen die gescheiden blijven, en een log waarmee je kunt aantonen wat er gebeurd is. Wie morgen één ding anders wil doen: vraag aan je team niet of de assistent goede antwoorden geeft, maar wat er gebeurt als de stagiair hem naar de reorganisatie vraagt. Het antwoord op die vraag vertelt je of je een assistent hebt gebouwd of een datalek met een chatvenster. 

↘︎ ALLE ARTIKELEN