Claude en Copilot zitten in je bestandssysteem. Wie bepaalt wat ze mogen zien?
In de afgelopen twaalf maanden zijn AI-assistenten op enig moment in de bestandsystemen van jouw organisatie verschenen. Misschien heeft IT dit goedgekeurd. Misschien heeft een businessunit Microsoft Copilot uitgerold als onderdeel van een M365-implementatie. Misschien hebben medewerkers zelf Claude of een andere AI-tool gekoppeld aan hun werkdrives.
Hoe het ook is gebeurd, het resultaat is hetzelfde: AI-systemen halen nu bedrijfsbestanden op namens medewerkers, en in de meeste organisaties heeft niemand expliciet bepaald wat die AI-systemen mogen zien. De toegangscontroles die het menselijk gebruik van bestanden reguleren, zijn niet ontworpen voor AI-actoren. De auditlogs die menselijke bestandsacties volgen, zijn niet geconfigureerd om AI-opvragingen vast te leggen met de detailnauwkeurigheid die compliance vereist. Het beleid dat bepaalt wie toegang heeft tot wat, is geschreven voor medewerkers, niet voor AI-systemen die namens medewerkers handelen.
Deze post is bedoeld voor CISO’s en compliance officers die antwoord moeten geven op een vraag die nu operationeel urgent is: wie bepaalt eigenlijk wat AI-assistenten mogen zien in jouw bestandsysteem?
Samenvatting voor het management
Belangrijkste punt: AI-assistenten krijgen toegang tot bedrijfsbestandsystemen onder autorisatiemodellen die zijn ontworpen voor menselijke gebruikers — met toegangsrechten, sessiegrenzen en audittrails die structureel ontoereikend zijn voor AI-actoren. De kloof tussen wat organisaties denken dat hun AI-toegangscontroles afdekken en wat ze daadwerkelijk afdekken is aanzienlijk, grotendeels onzichtbaar en brengt directe compliance-risico’s met zich mee.
Waarom dit belangrijk is: Wanneer een toezichthouder of auditor vraagt welke bestanden jouw AI heeft geraadpleegd, wie elke opvraging heeft geautoriseerd en hoe je kunt aantonen dat gevoeligheidsclassificaties zijn gehandhaafd — dan zijn die vragen alleen te beantwoorden als jouw AI-integratie daarop is ingericht. Bij de meeste is dat niet het geval. Het moment om deze kloof te ontdekken is vóór het onderzoek, niet tijdens.
5 Belangrijkste Inzichten
- AI-assistenten die toegang hebben tot bedrijfsbestandsystemen draaien doorgaans onder serviceaccounts met rechten die verder gaan dan de autorisatie van individuele gebruikers — wat betekent dat de AI documenten kan ophalen die de medewerker die de vraag stelt via geen enkel ander kanaal mag zien.
- Sessie-autorisatie is niet gelijk aan per-verzoek RBAC- en ABAC-handhaving. Het is één controlepunt gevolgd door ongemonitorde toegang op machinesnelheid.
- De meeste auditlogs van AI-bestandstoegang registreren de identiteit van het serviceaccount, niet de menselijke gebruiker wiens vraag de opvraging triggerde. Dit is niet alleen een loggingprobleem — het is een HIPAA-complianceprobleem, een GDPR-complianceprobleem en een forensisch onderzoeksprobleem.
- Data-classificatie en gevoeligheidslabels die op bestanden zijn toegepast, hebben geen effect op AI-opvragingen tenzij de AI-integratie ze expliciet evalueert op het retrieval-niveau. Een AI-assistent kan een document met het label Vertrouwelijk of Beperkt net zo gemakkelijk tonen als een niet-geclassificeerd document.
- De governancevraag is niet of je AI-bestandstoegang moet toestaan — medewerkers zijn productiever met AI, en blokkeren leidt tot shadow AI. De vraag is of AI-bestandstoegang wordt gereguleerd door hetzelfde beleid, met dezelfde handhaving en dezelfde audittrail, als elke andere vorm van data access binnen de organisatie.
Het Toegangsmodel Dat Niemand Heeft Goedgekeurd
Wanneer een organisatie een AI-assistent inzet met toegang tot het bestandsysteem, wordt doorgaans een serviceaccount geconfigureerd om de AI te authenticeren bij de bestandsrepository. Dat serviceaccount krijgt rechten die breed genoeg zijn om de volledige gebruikerspopulatie te bedienen — omdat de AI elk bestand moet kunnen ophalen dat een gebruiker legitiem nodig kan hebben. Het resultaat is één enkele inlog waarmee alles binnen scope toegankelijk is, gedeeld door elke gebruiker die met de AI werkt.
Geen enkele organisatie zou bewust een menselijk gebruikersaccount aanmaken met dit rechtenprofiel. Een gedeeld account met toegang tot elk gevoelig bestand in de repository, bruikbaar door iedere medewerker, zonder toegangsbeperkingen per gebruiker — dat zou geen enkele identity & access management review, risicobeoordeling of compliance-audit doorstaan.
Maar wanneer dezelfde rechtenstructuur wordt toegepast op een AI-serviceaccount, komt het vaak wel door de review omdat het eruitziet als infrastructuur, niet als toegangsbeleid. De AI wordt behandeld als systeem, niet als actor die namens gebruikers beslissingen neemt over data access. Dat onderscheid houdt geen stand bij nadere inspectie — en zeker niet bij een regulatoir onderzoek.
Het praktische gevolg is dat een AI-assistent die via een serviceaccount is verbonden met een bedrijfsbestandsysteem documenten kan ophalen die de medewerker die de vraag stelt nooit had mogen zien. Een junior analist die Claude vraagt om het concurrentielandschap samen te vatten, kan een antwoord krijgen gebaseerd op documenten die boven zijn of haar autorisatieniveau zijn geclassificeerd. Een klantenservicemedewerker die Copilot vraagt om accountgeschiedenis op te halen, kan per ongeluk bestanden van andere accounts tonen. De AI functioneert niet verkeerd — hij doet precies waarvoor hij is geconfigureerd. Het toegangsmodel is simpelweg nooit ontworpen om dit te voorkomen.
Je vertrouwt erop dat jouw organisatie veilig is. Maar kun je het bewijzen?
Lees nu
Sessie-autorisatie Is Geen Zero-Trust. Het Is Een Perimeter Met Slechts Eén Poort.
De meest voorkomende governance-reactie op zorgen over AI-bestandstoegang is wijzen op authenticatie: de AI wordt geauthenticeerd voordat hij verbinding maakt, toegang wordt geverifieerd, de sessie wordt opgezet binnen de zero-trust-architectuur van de organisatie. Dit klopt tot op zekere hoogte — maar het gaat niet ver genoeg.
Sessie-authenticatie verifieert dat het AI-systeem verbinding mag maken met de bestandsrepository op het moment dat de sessie wordt opgezet. Het verifieert niet of de specifieke gebruiker die de AI aanstuurt voor een specifieke query, bevoegd is om het specifieke bestand op te halen dat de AI gaat opvragen. Zodra de sessie open is, erven alle volgende handelingen de autorisatie die bij het opzetten van de verbinding is vastgesteld — de AI kan alles ophalen waartoe het serviceaccount toegang heeft, voor elke gebruiker, voor elk doel, zonder een enkele extra autorisatiecontrole.
Dit is vergelijkbaar met het controleren van de identiteit van een bezoeker bij de ingang van een gebouw en hem vervolgens onbeperkte toegang geven tot elk kantoor, serverruimte en directiekamer gedurende het gehele bezoek. De initiële verificatie heeft plaatsgevonden. Alles daarna is impliciet vertrouwen — precies wat zero trust gegevensuitwisseling wil elimineren.
Voor menselijke gebruikers zijn sessiecontroles een redelijke benadering van continue verificatie omdat menselijk sessiegedrag wordt begrensd door het operationele tempo van mensen. Voor een AI-systeem dat duizenden bestandsacties binnen één sessie kan uitvoeren, is sessie-autorisatie één controlepunt gevolgd door een periode van ongemonitorde toegang op machinesnelheid. Dat is een perimeter-model. Het is geen zero-trust.
Per-verzoek RBAC- en ABAC-handhaving betekent dat elke individuele bestandsactie — elke retrieval, elke zoekopdracht, elke download — wordt geëvalueerd aan de hand van de daadwerkelijke toegangsrechten van de aanvragende gebruiker op het moment dat deze plaatsvindt. De AI erft niet de sessie-autorisatie; hij erft de specifieke rechten van de specifieke gebruiker wiens query hij uitvoert, alleen voor die query. Als die gebruiker geen toegang heeft tot een document, kan de AI het niet ophalen — ongeacht wat het serviceaccount kan bereiken, ongeacht de sessiestatus, ongeacht hoe de vraag is geformuleerd.
Je Gevoeligheidslabels Beschermen Je Niet Tegen AI — Tenzij De AI Ze Controleert
De meeste organisaties met volwassen gegevensbeheerprogramma’s hebben geïnvesteerd in data-classificatiekaders — gevoeligheidslabels op bestanden die bepalen hoe ze moeten worden behandeld, wie ze mag inzien en wat ermee mag gebeuren. Microsoft Information Protection, native bestandsclassificatiesystemen, handmatige classificatieworkflows — dit zijn echte investeringen in governance en ze werken goed voor het reguleren van menselijke toegang tot bestanden.
Ze hebben echter geen effect op AI-opvragingen tenzij de AI-integratie ze expliciet evalueert. Een document met het label Vertrouwelijk is niet moeilijker voor een AI om op te halen dan een niet-geclassificeerd document. Het gevoeligheidslabel is metadata die aan het bestand is gekoppeld. Of die metadata wordt geëvalueerd voordat het bestand aan een AI wordt teruggegeven — of volledig wordt genegeerd — hangt volledig af van hoe de AI-integratie is ontworpen. In de meeste AI-bestandssysteemintegraties worden gevoeligheidslabels niet geëvalueerd op het retrieval-niveau. De AI haalt de meest relevante documenten op basis van de query, en relevantiescores houden geen rekening met gevoeligheidsclassificatie.
De implicatie voor compliance officers is direct: de gegevensbeheercontroles waarin je hebt geïnvesteerd, gelden niet voor AI-toegang tenzij je AI-integratie expliciet is ontworpen om ze af te dwingen. Elke classificatiebeslissing, elk gevoeligheidslabel, elke toegangsbeperking die op een bestand in je repository is toegepast — niets daarvan beperkt AI-opvragingen tenzij de AI-integratie het op retrieval-niveau evalueert. Een organisatie die denkt dat haar classificatiekader gevoelige bestanden beschermt tegen ongeautoriseerde AI-blootstelling, heeft een vals gevoel van zekerheid dat niet standhoudt bij een audit.
Vijf Falen van Toegangscontrole — en Hoe Ze Er In De Praktijk Uitzien
| Falen van toegangscontrole | Wat ontbreekt | Wat er daadwerkelijk gebeurt |
|---|---|---|
| Overgeprivilegieerd serviceaccount | AI-assistent draait onder een serviceaccount met toegang tot alle bestandsdelen; elke gebruiker kan elk bestand opvragen dat het account kan bereiken | Een junior analist vraagt Claude om de M&A-pijplijn samen te vatten. Claude haalt bestuursdocumenten op die de analist niet mag inzien. |
| Alleen sessie-autorisatie | AI-autorisatie wordt geverifieerd bij het opzetten van de verbinding; alle volgende acties erven die autorisatie, ongeacht wat wordt opgevraagd | Een externe medewerker wordt tijdens kantooruren geauthenticeerd; de AI-sessie blijft actief. Na werktijd blijft de AI documenten ophalen zonder herverificatie. |
| Geen handhaving van gevoeligheidslabels | AI haalt documenten op op basis van inhoudsrelevantie zonder classificatielabels te evalueren | Een medewerker vraagt Copilot om concurrentieanalyse. Er worden documenten met het label Vertrouwelijk opgehaald — waaronder een concept-overnamevoorstel. |
| Ontbrekende gebruikersattributie | Alle AI-bestandstoegang wordt gelogd onder het serviceaccount; geen registratie van welke gebruiker welke opvraging heeft getriggerd | Een onderzoek naar een datalek onthult duizenden bestandsopvragingen door “AI-service-account.” Geen enkele audittrail kan achterhalen wie de queries heeft gestart. |
| Geen limiet op aantal opvragingen | AI kan onbeperkt bestanden ophalen binnen een sessie; geen hoeveelheidsbeperkingen op dataniveau | Een gecompromitteerde AI-sessie haalt 40.000 documenten op in 90 minuten voordat het SIEM-alarm wordt opgepakt. |
De Vragen Die Je Niet Kunt Beantwoorden — Totdat Je Het Wel Kunt
Voor compliance officers kristalliseert het governanceprobleem rond AI-bestandstoegang uit tot een specifieke en ongemakkelijke vraag: als een toezichthouder of auditor vraagt wat jouw AI-assistenten hebben geraadpleegd, wie elke opvraging heeft geautoriseerd en hoe je kunt aantonen dat je verplichtingen rond gegevensbescherming zijn nagekomen — kun je dan antwoord geven?
Het antwoord hangt volledig af van wat jouw AI-integratie logt en afdwingt. De meeste audittrails van AI-bestandstoegang registreren dat een serviceaccount een bestand heeft opgehaald. Ze registreren niet welke medewerker de opvraging heeft getriggerd, of de opvraging overeenkwam met de toegangsrechten van die medewerker, of de gevoeligheidsclassificatie van het bestand is geëvalueerd, of wat er met de inhoud is gedaan.
Dit is geen loggingconfiguratieprobleem — het is een architectuurprobleem. De attributiedetails die nodig zijn om compliance-vragen te beantwoorden, moeten op het moment van opvraging worden vastgelegd; ze kunnen niet achteraf worden gereconstrueerd.
De HIPAA Minimum Necessary Rule vereist dat toegang tot beschermde gezondheidsinformatie wordt beperkt tot het minimum dat nodig is voor het doel. Wanneer een AI PHI ophaalt om een vraag te beantwoorden, vereist aantoonbare minimale compliance dat je precies weet wat is opgehaald, in reactie op welke vraag, door welke gebruiker.
GDPR vereist dat verwerking van persoonsgegevens een gedocumenteerde wettelijke grondslag heeft — wat voor AI-opvragingen betekent dat je weet welke gebruiker de opvraging heeft aangestuurd en met welk doel. SOX vereist volledige registratie van toegang tot financiële data.
FedRAMP-naleving vereist auditlogging voor alle handelingen binnen geautoriseerde informatiesystemen, inclusief AI-operaties, op een attributieniveau dat de verantwoordelijke menselijke actor identificeert.
Wat Auditors Zullen Vragen — en Wat Nodig Is Om Te Antwoorden
| Vraag van een auditor of toezichthouder | Toepasselijk framework | Wat nodig is om te antwoorden |
|---|---|---|
| Welke medewerkers hebben in de afgelopen 90 dagen een AI-assistent gebruikt om bestanden met PHI of PII te openen? | HIPAA, GDPR | Vereist gebruikersattributie in AI-auditlogs — alleen serviceaccount-logging is hiervoor onvoldoende |
| Welke specifieke documenten heeft de AI opgehaald als reactie op een bepaalde gebruikersvraag? | HIPAA Minimum Necessary, GDPR dataminimalisatie | Vereist logging op query-niveau die elke opvraging koppelt aan het specifieke verzoek dat deze heeft getriggerd |
| Is de AI verhinderd om documenten te openen die de aanvragende gebruiker niet mocht zien? | Alle gereguleerde frameworks | Vereist per-verzoek RBAC/ABAC-handhaving met gelogde beleidsbeslissingen — niet alleen sessie-authenticatie |
| Kunnen we aantonen dat AI-data access in lijn was met de geldende gevoeligheidsclassificaties? | GDPR, SOX, FedRAMP | Vereist evaluatie van gevoeligheidslabels op retrieval-niveau en documentatie dat labels zijn gehandhaafd |
| Wat is de volledige toegangsgeschiedenis van een specifiek bestand dat mogelijk door AI is opgehaald? | HIPAA, GDPR recht op inzage, eDiscovery | Vereist audittrail op bestandsniveau die AI-opvragingen bevat met dezelfde attributiedetails als menselijke toegang |
AI Blokkeren Is Niet Het Antwoord. Governance Wel.
De reflexmatige reactie op zorgen over AI-bestandstoegang — AI-tools blokkeren, toegang intrekken, wachten tot het governancekader is ingehaald — creëert een ander probleem. Medewerkers die AI echt nuttig vinden voor hun werk, zullen het via andere wegen gebruiken. Persoonlijke accounts, browsergebaseerde AI-tools, consumentenapplicaties die geen enkele link hebben met bedrijfsgovernance en geen toegang tot gezaghebbende bedrijfsdata.
Dit is geen hypothetisch scenario: shadow AI is al aanwezig in de meeste organisaties, en het beperken van goedgekeurde AI-tools versnelt ongecontroleerd AI-gebruik juist in plaats van het te verminderen.
De governancevraag is niet of je AI-bestandstoegang moet toestaan. Het is of AI-bestandstoegang wordt gereguleerd door hetzelfde beleid, met dezelfde handhaving en dezelfde audittrail, als elke andere vorm van data access binnen de organisatie. Een medewerker die een bestand opent via een desktopapplicatie valt onder toegangscontroles, sessiemonitoring en auditlogging.
Diezelfde medewerker die hetzelfde bestand opent via een AI-assistent moet onder identieke controles vallen — per-verzoek autorisatie, handhaving van gevoeligheidslabels, logging met dubbele attributie. Als het AI-pad een van die controles omzeilt, ontstaat er een governancekloof die uiteindelijk zal worden misbruikt, ontdekt of beide.
Hoe Kiteworks Ervoor Zorgt Dat AI Alleen Ziet Wat Het Mag Zien
De organisaties die AI-adoptie beheersen zonder compliance-risico’s te creëren, zijn niet degenen die AI het langst blokkeren — maar degenen die governance het snelst uitbreiden naar AI. Die uitbreiding vereist een architectuur waarbij het antwoord op “wie bepaalt wat AI mag zien” hetzelfde is als voor elke andere actor: de policy engine, geëvalueerd op het moment van elk individueel verzoek, aan de hand van de daadwerkelijke toegangsrechten van de specifieke gebruiker.
Kiteworks handhaaft dit via per-verzoek RBAC en ABAC op AI-operatieniveau — niet bij het opzetten van de sessie. Elke bestandsopvraging, elke zoekopdracht, elke mapactie uitgevoerd door Claude, Copilot of een andere MCP-compatibele AI-assistent via het Kiteworks Private Data Network wordt geëvalueerd aan de hand van de actuele toegangsrechten van de geauthenticeerde gebruiker voordat data wordt teruggegeven.
De AI erft de rechten van de gebruiker — niet de rechten van het serviceaccount — voor elke individuele actie. Als de gebruiker een document niet mag zien, kan de AI het niet ophalen, ongeacht de sessiestatus, ongeacht de query, ongeacht waar het serviceaccount toegang toe heeft.
Handhaving van gevoeligheidslabels vindt plaats op retrieval-niveau: Microsoft Information Protection-classificaties en Kiteworks-data-classificatiebeleid worden geëvalueerd voordat data aan de AI wordt teruggegeven. Vertrouwelijke documenten worden niet getoond als reactie op vragen van gebruikers die ze niet mogen zien — niet omdat de AI wordt geïnstrueerd ze niet te noemen, maar omdat de governance-laag ze niet teruggeeft.
Elke AI-bestandsactie wordt gelogd met dubbele attributie — AI-systeemidentiteit en geauthenticeerde menselijke gebruiker — en voedt de Kiteworks auditlog en integreert realtime met SIEM. De compliance-vragen in de bovenstaande tabel zijn te beantwoorden — omdat de architectuur daarop is ingericht.
Voor CISO’s die moeten aantonen dat AI-bestandstoegang met dezelfde grondigheid wordt gereguleerd als menselijke toegang, en voor compliance officers die auditklare documentatie nodig hebben van wat AI heeft geraadpleegd en wie het heeft geautoriseerd, biedt Kiteworks de gereguleerde datalaag die beide mogelijk maakt. Wil je zien hoe het werkt? Plan vandaag nog een demo op maat.
Veelgestelde Vragen
De meeste AI-assistenten voor bedrijven krijgen toegang tot bestandsystemen via serviceaccounts die zijn geconfigureerd met rechten die breed genoeg zijn om de volledige gebruikerspopulatie te bedienen. Dit betekent dat de AI elk bestand kan ophalen dat het serviceaccount kan bereiken — ongeacht of de individuele medewerker die de AI aanstuurt dat bestand mag zien. In combinatie met sessie-autorisatie die impliciete toegang verleent voor de duur van de sessie, ontstaat een toegangsmodel waarbij AI effectief de toegangscontroles omzeilt die menselijke bestandstoegang reguleren. Het risico is niet hypothetisch: medewerkers kunnen onbedoeld AI-gegenereerde antwoorden ontvangen die gebaseerd zijn op documenten die ze nooit hadden mogen inzien.
Alleen als de AI-integratie daar expliciet op is ingericht. Data-classificatie- en gevoeligheidslabels op bestanden zijn metadata — ze hebben geen effect op AI-opvragingen tenzij de integratie ze op retrieval-niveau evalueert voordat data wordt teruggegeven. In de meeste AI-bestandssysteemintegraties bepaalt relevantie voor de query wat wordt opgehaald; gevoeligheidsclassificatie speelt geen rol. Organisaties die denken dat hun classificatiekader gevoelige bestanden beschermt tegen AI-blootstelling, moeten verifiëren of hun AI-integratie dit daadwerkelijk afdwingt.
Sessie-autorisatie verifieert het AI-systeem bij het opzetten van de verbinding en verleent impliciete toegang voor de duur van de sessie. Per-verzoek RBAC- en ABAC-handhaving evalueert de daadwerkelijke toegangsrechten van de gebruiker voor elke individuele AI-actie — elke bestandsopvraging, elke zoekopdracht, elke mapnavigatie — op het moment dat deze wordt uitgevoerd. Het verschil in de praktijk: met sessie-autorisatie kan elk bestand dat het serviceaccount kan bereiken worden opgehaald voor elke gebruiker; met per-verzoek-handhaving kunnen alleen bestanden die de aanvragende gebruiker specifiek mag openen worden opgehaald, en alleen voor dat verzoek.
Beide frameworks vereisen documentatie op attributieniveau die de verantwoordelijke mens identificeert voor elk data access-event. Voor AI-bestandstoegang betekent dit logging met dubbele attributie: elke opvraging moet zowel de AI-systeemidentiteit als de geauthenticeerde menselijke gebruiker registreren wiens vraag deze heeft getriggerd, samen met het specifieke opgehaalde bestand, de timestamp en de uitgevoerde actie. HIPAA-naleving vereist bovendien dat toegang tot PHI voldoet aan de minimum necessary-standaard, wat betekent dat je precies moet weten wat is opgehaald in reactie op welke vraag. Alleen logging op serviceaccount-niveau — waarbij wordt geregistreerd dat “de AI een bestand heeft geopend” zonder de menselijke aanvrager te identificeren — voldoet niet aan de documentatievereisten van beide frameworks.
Het doel is om bestaande gegevensbeheerbeleid uit te breiden naar AI-actoren — niet om aparte AI-specifieke beleidsregels te maken, en niet om AI-tools te blokkeren die medewerkers echt nuttig vinden. Dit betekent AI-integratie-architectuur inzetten die per-verzoek autorisatie afdwingt met dezelfde RBAC- en ABAC-beleidsregels als voor menselijke toegang, gevoeligheidslabels evalueert op retrieval-niveau en auditlogs met dubbele attributie genereert voor elke AI-actie. Organisaties die dit realiseren, bieden medewerkers gereguleerde AI-toegang die zowel capabeler als veiliger is dan de ongecontroleerde alternatieven die ze anders zouden gebruiken.
Aanvullende bronnen
- Blog Post
Zero‑Trust-strategieën voor betaalbare AI-privacybescherming - Blog Post
Hoe 77% van de organisaties faalt in AI-databeveiliging - eBook
AI Governance Gap: Waarom 91% van de kleine bedrijven Russisch roulette speelt met databeveiliging in 2025 - Blog Post
Er is geen “–dangerously-skip-permissions” voor jouw data - Blog Post
Toezichthouders zijn klaar met vragen of je een AI-beleid hebt. Ze willen bewijs dat het werkt.