Is het ophalen van een document door AI een registreerbare gegevens-toegangsactie? De compliance-vraag die RAG oproept
Wanneer een medewerker een document opent in SharePoint, wordt die toegang gelogd. Wanneer een databasequery financiële gegevens ophaalt, wordt die handeling geregistreerd.
Dit zijn geen optionele governancekeuzes — het zijn de basisvereisten voor audittrail die HIPAA, GDPR en SOX al decennialang stellen aan systemen voor gegevenstoegang.
Denk nu eens aan wat er gebeurt wanneer een RAG-pijplijn veertig documenten ophaalt om één enkele medewerkervraag te beantwoorden uit een repository met PHI, persoonlijke gegevens en vertrouwelijke financiële gegevens. Dezelfde documenten werden benaderd. Dezelfde informatie werd naar een applicatie verzonden voor verwerking. Dezelfde compliancekaders zijn van toepassing. Maar in de meeste enterprise AI-inzetten vandaag wordt geen van die veertig ophaalacties individueel gelogd, toegewezen aan een verantwoordelijke persoon, of geëvalueerd aan de hand van een toegangscontrolebeleid.
De compliancevraag die RAG oproept is niet nieuw: het is de oudste vraag binnen gegevensbeheer, toegepast op een systeem dat complianceverplichtingen genereert op een schaal en snelheid waar bestaande logginginfrastructuur niet op is ingericht.
Samenvatting voor het management
Belangrijkste idee: Een AI-systeem dat een document ophaalt uit een bedrijfsrepository voert een data-accessevent uit dat onder dezelfde registratieverplichtingen valt als elk ander data-accessevent onder HIPAA, GDPR en SOX. Het feit dat de retrieval geautomatiseerd is, onzichtbaar voor de eindgebruiker, en met hoge hoeveelheden per query plaatsvindt, verandert niets aan de wettelijke verplichting — het versterkt die juist. Organisaties die RAG-pijplijnen inzetten op gereguleerde data zonder logging per document en per query, creëren niet-geregistreerde complianceverplichtingen op machineschaal.
Waarom dit relevant is: Het compliancegat dat ontstaat door niet-gelogde RAG-retrieval is geen theoretisch risico — het is een actueel probleem. Elke dag dat een RAG-pijplijn draait op een repository met PHI, persoonlijke gegevens of financiële gegevens zonder logging per query, genereert de organisatie toegangsevents die ze niet kan verantwoorden, niet kan toewijzen en niet kan overleggen bij een regulatoire controle of meldplicht na een datalek. Het gat wordt met elke query groter. De oplossing is architectonisch, niet administratief.
5 Belangrijkste Inzichten
- RAG-retrieval is een data-accessevent onder elk belangrijk compliancekader. HIPAA §164.312(b) vereist registratie van activiteiten bij elke toegang tot ePHI, inclusief geautomatiseerde retrieval. GDPR definieert verwerking als inclusief ophalen en raadplegen van persoonsgegevens. SOX ITGC vereist logging van toegang tot financiële data, ongeacht of de toegang door mensen of systemen gebeurt. Automatisering van de retrieval biedt geen uitzondering.
- AI-logging op sessieniveau voldoet niet aan de registratieverplichting per toegang. Een log die vastlegt “AI-sessie heeft HR-repository bevraagd” is geen HIPAA-conforme audittrail voor de PHI-accessevents binnen die sessie. De registratieplicht geldt per document, per retrieval — niet per sessie of per query. Een medewerker die veertig bestanden opent, genereert veertig toegangrecords; een RAG-query die veertig documenten ophaalt, moet hetzelfde doen.
- Schaal is de compliancevermenigvuldiger. Eén RAG-query kan 10 tot 50 documenten ophalen. Een organisatie met 500 medewerkers die elk 5 AI-queries per dag uitvoeren op een PHI-repository, genereert potentieel 12.500 tot 62.500 PHI-accessevents per dag — elk daarvan is een registreerbaar event onder HIPAA §164.312(b). Organisaties zonder logging per query stapelen niet-geregistreerde complianceverplichtingen op dit tempo op.
- Integratie van Microsoft Information Protection (MIP)-labels op het retrievalniveau lost de vereiste voor gevoeligheidsclassificatie op die logging per query moet ondersteunen. Wanneer een opgehaald document een MIP-gevoeligheidslabel draagt, moet dat label worden geëvalueerd voordat het document de AI-context binnenkomt en geregistreerd worden in de toeganglog — waarmee het bewijs van dataclassificatie wordt geleverd dat GDPR Artikel 30 en FedRAMP vereisen.
- De oplossing voor niet-gelogde RAG-retrieval is architectonisch, niet administratief. Geen beleidsupdate, geen wijziging van Artikel 30, en geen herziening van risicobeoordeling kan achteraf toegangrecords creëren die niet zijn gegenereerd. De oplossing is een gecontroleerde retrievallaag die voor elke retrievaloperatie, per document en per query, een auditlog-entry aanmaakt, in realtime, met individuele gebruikersattributie via OAuth 2.0 user-delegated authenticatie.
Wat ‘Toegang’ Betekent in Compliancekaders — en Waarom RAG Daaronder Valt
De vraag of AI-retrieval een data-accessevent is, is niet interpretatief lastig. Elk belangrijk compliancekader definieert toegang breed genoeg om geautomatiseerde retrieval te omvatten, en die definities zijn niet veranderd met de komst van AI. Wat wel veranderd is, is de schaal waarop geautomatiseerde retrieval plaatsvindt en de onzichtbaarheid van die retrieval voor medewerkers en systemen die het anders zouden opmerken.
Onder HIPAA vereist de Security Rule in 45 CFR §164.312(b) dat organisaties auditcontroles implementeren die activiteiten in informatiesystemen met ePHI registreren en onderzoeken. Het woord “activiteit” omvat elke toegang tot ePHI — menselijk of geautomatiseerd, interactief of programmatisch, opzettelijk of incidenteel.
Wanneer een RAG-pijplijn een document met een patiëntendossier ophaalt, is dat een activiteit in een systeem met ePHI. De verplichting onder §164.312(b) om die activiteit te registreren maakt geen onderscheid tussen een verpleegkundige die een dossier opent en een AI-systeem dat hetzelfde dossier ophaalt om een klinische vraag te beantwoorden. Beide zijn activiteiten. Beide zijn registreerbaar.
Onder GDPR wordt “verwerking” in Artikel 4(2) gedefinieerd als elke bewerking op persoonsgegevens, waaronder verzamelen, registreren, ophalen, raadplegen, gebruiken en verstrekken. Retrieval wordt expliciet genoemd. Een RAG-pijplijn die een document met persoonsgegevens ophaalt, voert een retrievaloperatie uit op die data — het is verwerking van persoonsgegevens onder de eigen definitie van GDPR, zonder ambiguïteit.
Die verwerking moet een wettelijke grondslag hebben, onderworpen zijn aan dataminimalisatie en worden vastgelegd in Artikel 30-verwerkingenregisters. Het feit dat de retrieval geautomatiseerd is en met hoge hoeveelheden per gebruikersquery plaatsvindt, vermindert de verplichting niet; het vermenigvuldigt het aantal verwerkingen dat moet worden gedocumenteerd.
Onder SOX stellen IT General Controls dat toegang tot financiële data gelogd en toewijsbaar moet zijn aan een geautoriseerd individu. De ITGC-loggingverplichting geldt voor systemen, niet voor gebruikerscategorieën — en een RAG-pijplijn die financiële gegevens ophaalt, is een systeem dat financiële data benadert, onderworpen aan dezelfde loggingverplichtingen als een menselijke gebruiker die een rapport draait.
De automatisering van de toegang is geen uitzondering; het is een ontwerpkeuze van de organisatie, en de complianceverplichting volgt de data, ongeacht hoe de toegang is geïmplementeerd.
Welke Data Compliance-standaarden zijn relevant?
Lees nu
RAG-retrieval als Registreerbaar Event: Analyse per Framework
| Framework | Is RAG-retrieval een registreerbaar event? | Wat het record moet bevatten | Het gat in de meeste huidige AI-inzetten |
|---|---|---|---|
| HIPAA Security Rule | Ja. 45 CFR §164.312(b) vereist dat organisaties hardware-, software- en procedurele mechanismen implementeren die activiteiten in informatiesystemen met elektronische PHI registreren en onderzoeken. “Activiteit” omvat elke toegang tot ePHI, inclusief geautomatiseerde retrieval. | RAG-retrieval van documenten met PHI is een toegangsevent onder §164.312(b). De organisatie moet een auditrecord van die retrieval kunnen overleggen — de specifieke PHI die is benaderd, de identiteit van de gebruiker wiens sessie de toegang aanstuurde, en de timestamp. | De meeste RAG-pijplijnen loggen AI-activiteit op sessieniveau, niet per-document PHI-retrieval. De vereiste onder §164.312(b) geldt per toegang, niet per sessie. Een log die “AI-sessie heeft HR-queries verwerkt” registreert, is geen §164.312(b)-conforme audittrail voor de PHI-accessevents binnen die sessie. |
| GDPR | Ja. Verwerking omvat elke bewerking op persoonsgegevens, waaronder verzamelen, ophalen, raadplegen, gebruiken en verstrekken. Artikel 5(2) vereist dat de verwerkingsverantwoordelijke verantwoordelijk is voor, en kan aantonen dat wordt voldaan aan, de gegevensbeschermingsprincipes voor elke verwerkingshandeling. | RAG-retrieval van documenten met persoonsgegevens is een verwerkingshandeling onder GDPR. Het moet een wettelijke grondslag hebben, onderworpen zijn aan dataminimalisatie op het retrievalniveau, en worden vastgelegd in Artikel 30-verwerkingenregisters. De verwerkingsverantwoordelijke moet kunnen aantonen dat elke retrieval rechtmatig en geminimaliseerd was. | De meeste organisaties nemen RAG-retrieval niet op als verwerkingsactiviteit in hun Artikel 30-registers. Elke retrievalquery die persoonsgegevens raakt, is een afzonderlijk verwerkingsevent waarvoor geen bewijs van wettelijke grondslag bestaat in het Artikel 30-register — een directe schending van het verantwoordingsprincipe. |
| SOX (IT General Controls) | Ja. SOX ITGC-toegangscontroles vereisen dat toegang tot financiële data wordt gelogd en toewijsbaar is aan een geautoriseerd individu. “Toegang” is niet beperkt tot menselijke toegang — elke systeemoperatie die financiële data leest, verwerkt of ophaalt, valt onder de loggingverplichting. | RAG-retrieval van documenten met financiële data is een registreerbaar toegangsevent voor SOX ITGC-doeleinden. De audittrail moet de retrieval toewijzen aan een specifiek geautoriseerd individu — niet aan een AI-serviceaccount — en moet de specifieke financiële gegevens die zijn benaderd registreren. | AI-systemen die financiële data benaderen via een serviceaccount genereren auditlogs die niet voldoen aan de SOX ITGC-verplichting voor individuele toewijzing. De retrieval vond plaats; de verantwoordelijke persoon is onbekend. Dit is een tekortkoming in toegangscontrole en audittrail onder SOX, geen beleidsprobleem. |
| FedRAMP (AU Control Family) | Ja. AU-2 vereist dat het systeem de typen events identificeert die gelogd kunnen worden ter ondersteuning van auditvereisten. AU-3 vereist dat auditrecords voldoende informatie bevatten om vast te stellen wat er gebeurde, wanneer en wie verantwoordelijk was. Geautomatiseerde AI-retrieval valt binnen de AU-scope. | Elke AI-retrieval binnen de FedRAMP-autorisatiegrens is een auditeerbaar event onder AU-2. Het AU-3-record moet de gebruiker, de actie, het benaderde object en de uitkomst identificeren. Een AI-serviceaccount voldoet niet aan het “wie was verantwoordelijk”-element van AU-3. | AI-systemen binnen FedRAMP-autorisatiegrenzen die authenticeren via gedeelde serviceaccounts of API-keys genereren auditrecords die niet voldoen aan de AU-3-vereisten voor individuele verantwoordelijkheid. Dit is een control deficiency finding bij jaarlijkse beoordelingen. |
| SOC 2 (CC6 / CC7) | Ja. CC6.1 vereist dat logische toegangsbeveiligingsmaatregelen worden geïmplementeerd om te beschermen tegen bedreigingen van buiten het systeem. CC7.2 vereist monitoring van systeemcomponenten en activiteiten om potentiële cyberbeveiligingsbedreigingen te detecteren. AI-retrieval valt binnen beide controlfamilies. | AI-retrievals zijn systeemactiviteiten die onder CC7.2 moeten worden gemonitord. Bewijs van toegangscontrole voor CC6.1 moet aantonen dat AI-data-acces wordt beheerst zoals menselijke toegang — dus toegangscontrole per operatie, niet op sessieniveau. | SOC 2 Type II-audits over een periode van 12 maanden testen of AI-activiteitsmonitoring continu was en of AI-toegangscontroles consistent werkten. Organisaties die AI halverwege de periode zonder toegangscontrole of monitoring hebben ingezet, hebben een gat voor de gehele inzetperiode. |
Waarom Logging op Sessieniveau Niet Gelijk Is aan Registratie per Toegang
De meest voorkomende AI-governance logging-implementatie is op sessieniveau: het AI-platform registreert dat er een gebruikerssessie was, dat er queries zijn ingediend en dat er antwoorden zijn gegenereerd. Dit is nuttige operationele data. Het is geen compliance-grade toeganglog onder een van de bovenstaande kaders.
Het onderscheid is belangrijk omdat de wettelijke verplichting per toegang geldt, niet per sessie. Een medewerker die twaalf patiëntendossiers opent tijdens een werksessie, genereert twaalf HIPAA §164.312(b)-toegangrecords — één per bestand, elk met het specifieke document, de timestamp en de gebruikersidentiteit.
Het feit dat alle twaalf bestandopeningen binnen dezelfde loginsessie plaatsvonden, voegt ze niet samen tot één toegangrecord. Hetzelfde geldt voor AI. Een RAG-query die twaalf documenten ophaalt om één vraag te beantwoorden, genereert twaalf toegangsevents — elk een onafhankelijke §164.312(b)-verplichting, ongeacht de sessiecontext.
Logging op sessieniveau voldoet ook niet aan de specificiteit die vereist is bij meldplicht na een datalek of een regulatoire controle. Wanneer HHS OCR een mogelijk PHI-datalek onderzoekt waarbij een AI-systeem betrokken is, zal men vragen welke specifieke patiëntendossiers zijn benaderd, door welke gebruiker, op welke data. Een sessielog die “AI-platform heeft klinische repository benaderd” registreert, kan deze vraag niet beantwoorden.
Het onderzoek gaat dan uit van het worstcasescenario: alle records in de repository zijn mogelijk getroffen, alle patiënten moeten worden geïnformeerd. Logging per document kan de vraag precies beantwoorden — waardoor de meldingsscope wordt beperkt tot de daadwerkelijk benaderde dossiers en reputatie- en operationele schade door overrapportage wordt voorkomen.
Voor CDO’s die verantwoordelijk zijn voor gegevensbeheerarchitectuur is de praktische vraag of de AI-infrastructuur van de organisatie dezelfde granulariteit van toegangrecords genereert voor AI-gemedieerde data-acces als voor menselijke toegang. Als een medewerker die een bestand opent een logentry genereert, moet een AI die hetzelfde bestand ophaalt een gelijkwaardige logentry genereren. Als dat niet gebeurt, heeft de organisatie een tweedeling in data-acces governance: streng voor menselijke toegang, onzichtbaar voor AI-toegang. Dat is geen governancepositie die een regulatoire toets doorstaat.
Queryschaal: De Compliancevermenigvuldiger Die het Risicobeheer Verandert
De compliancegevolgen van niet-gelogde RAG-retrieval zijn een functie van zowel de verplichting per event als de hoeveelheid events die worden gegenereerd. Voor menselijke data-acces is de hoeveelheid van nature begrensd door de snelheid waarmee iemand bestanden kan openen. Een gebruiker die vijftig patiëntendossiers op een dag opent, is een uitzondering die een anomalie-alarm kan triggeren. Een RAG-pijplijn die vijftig documenten ophaalt om één query te beantwoorden, is standaard — en doet dat opnieuw bij elke volgende query.
| Toegangsscenario | Hoeveelheid gegenereerde events | Compliancegevolg |
|---|---|---|
| Individuele gebruiker opent een bestand in SharePoint | 1 toegangsevent gelogd met gebruikersidentiteit, bestandspad, timestamp | Dit event wordt routinematig gelogd, toegewezen en is te controleren. Complianceprogramma’s hebben hier volwassen workflows voor. |
| Individuele gebruiker voert een rapportquery uit op een financiële database | 1 toegangsevent gelogd met gebruikersidentiteit, query, geretourneerde records | Dit event valt onder SOX ITGC-loggingvereisten en wordt doorgaans vastgelegd door database-activiteitsmonitoringtools. |
| AI-assistent beantwoordt één medewerkervraag via RAG op een repository met 50.000 documenten | Potentieel 10–50 documentretrievals, elk met andere inhoud, meestal niet individueel gelogd in de meeste inzetten | De complianceverplichting is identiek aan rij 1 en 2: elke documentretrieval is een afzonderlijk registreerbaar toegangsevent. Maar de hoeveelheid events per gebruikersquery — en het ontbreken van logging per document in de meeste RAG-inzetten — creëert een compliancegat op machineschaal. |
| 500 medewerkers voeren elk 5 AI-queries per dag uit op een PHI-repository | Potentieel 12.500–62.500 PHI-accessevents per dag, organisatiebreed | Onder HIPAA §164.312(b) is elk van deze een registreerbaar event. Een organisatie die deze workload draait zonder logging per document voor PHI-retrieval, genereert dagelijks tienduizenden niet-geregistreerde §164.312(b)-toegangsevents — een compliancegat dat met de tijd groeit. |
| AI-pijplijn verwerkt due diligence-documenten voor een M&A-dealteam | Honderden tot duizenden documentretrievals op vertrouwelijke financiële en juridische dossiers, gedurende een lang project | Onder SOX ITGC en GDPR is elke retrieval van een document met financiële of persoonlijke data een registreerbaar event dat moet worden toegewezen aan een verantwoordelijke persoon. Projectlogs op sessieniveau voldoen niet aan de vereisten voor toewijzing per event voor beide kaders. |
De bovenstaande aantallen zijn representatief voor typische enterprise RAG-inzetten in gereguleerde sectoren. Een zorgorganisatie die een AI-assistent inzet voor klinisch personeel zonder logging per document voor PHI-retrieval, creëert geen statisch compliancegat. Het wordt een groeiend gat, waarbij elke query de hoeveelheid niet-geregistreerde toegangsevents vergroot.
Zes maanden na inzet kan de niet-geregistreerde eventachterstand miljoenen individuele PHI-accessevents omvatten die de organisatie niet kan verantwoorden, niet kan toewijzen en niet kan overleggen bij een regulatoire controle.
De schaal verandert ook de risicobeheercalculatie voor detectie van data-exfiltratie. In scenario’s met menselijke toegang zijn afwijkende toegangspatronen — een gebruiker die een ongebruikelijke hoeveelheid records opent, of buiten zijn normale scope — te detecteren met baseline monitoring.
In AI-toegangsscenario’s zonder logging per query is er geen baseline om mee te vergelijken, geen gebruikersspecifieke volumemaatstaf om te monitoren, en geen signaal dat legitieme AI-operatie onderscheidt van systematische data-extractie. Het ontbreken van logging per query is tegelijk een compliancegat en een detectiegat.
MIP-labelintegratie: Het Oplossen van het Classificatiegat op het Retrievalniveau
Logging per query voldoet aan de registratieverplichting voor toegang. Het voldoet op zichzelf niet aan de vereiste voor gevoeligheidsclassificatie die GDPR Artikel 30 en FedRAMP stellen aan datahandling. Weten dat een AI document-ID 47832 heeft opgehaald is minder waardevol voor compliancedocumentatie dan weten dat document-ID 47832 een Confidential-gevoeligheidslabel draagt, persoonsgegevens van EU-betrokkenen bevat, en is benaderd door een gebruiker wiens autorisatieniveau toegang tot Standard maar niet tot Confidential materiaal toestaat.
Microsoft Information Protection (MIP)-labels leveren de classificatiemetadata die logging per query compliance-compleet maken. Wanneer een document in een MIP-gelabelde repository wordt opgehaald door een RAG-pijplijn, is het label van dat document op het moment van toegang beschikbaar.
Integratie van MIP-labelbeoordeling in de retrievallaag levert drie compliance-relevante uitkomsten: ten eerste, gevoeligheidsbewuste toegangscontrole — het retrievalsysteem kan beleid afdwingen dat voorkomt dat documenten boven een bepaalde gevoeligheidsdrempel in de AI-context terechtkomen voor gebruikers zonder de juiste classificatie; ten tweede, toeganglogs met gevoeligheidslabel — de logentry voor elke retrieval bevat het MIP-label van het opgehaalde document, waarmee het bewijs van classificatie wordt geleverd dat Artikel 30 en FedRAMP vereisen; en ten derde, bewijs van beleidshandhaving — wanneer een retrieval wordt geweigerd omdat het MIP-label van het document de autorisatie van de gebruiker overschrijdt, wordt de weigering gelogd met de beleidsgrondslag, waarmee het ABAC-beslissingsrecord ontstaat dat auditors verlangen.
Voor CDO’s die hebben geïnvesteerd in MIP-labeling van het documentcorpus van de organisatie, betekent RAG-pijplijnen zonder MIP-labelbeoordeling op het retrievalniveau feitelijk dat die investering wordt omzeild. De labels staan op de documenten; het retrievalsysteem negeert ze. Het resultaat is een dataclassificatieprogramma dat menselijke toegang tot het gelabelde corpus reguleert, maar niet AI-toegang — dezelfde tweedeling in governance als bij toeganglogging, nu ook op het classificatieniveau.
De Records Die Niet Meer Bestaan: Waarom Achteraf Logging Onmogelijk Is
Een vraag die compliancefunctionarissen vaak stellen bij AI-toeganglogginggaten is of historische records kunnen worden gereconstrueerd. Het antwoord is nee, en de onmogelijkheid is architectonisch, niet operationeel. Toegangrecords documenteren welke data op een specifiek moment door een specifieke geauthenticeerde sessie uit een repository is opgehaald.
Die informatie bestaat alleen als die op het moment van retrieval is vastgelegd. De repository is sinds die retrievals gewijzigd. De documenten kunnen zijn aangepast, verplaatst of verwijderd. De sessies die die retrievals aanstuurden zijn gesloten. De AI-contextwindows van die sessies bestaan niet meer. Het toegangsevent is niet te herstellen.
Dit is het compliancegevolg van de groeiende niet-geregistreerde eventachterstand: die events zijn permanent onoplosbaar. Als er een regulatoire controle komt waarbij de organisatie moet verantwoorden welke AI-toegang tot gereguleerde data in een historische periode heeft plaatsgevonden, is het standpunt van de organisatie dat ze de records niet kan leveren — niet dat de toegang niet heeft plaatsgevonden, maar dat deze niet is geregistreerd.
Onder HIPAA is het niet bijhouden van auditrecords voor systemen met ePHI op zichzelf al een overtreding van de Security Rule, los van een datalek. Onder GDPR is het onvermogen om te voldoen aan het verantwoordingsprincipe een directe Artikel 5(2)-schending. Het ontbreken van records is geen neutrale positie; het is een compliancefout met eigen regulatoire gevolgen.
De implicatie voor compliancefunctionarissen en CDO’s is dat de urgentie van herstel evenredig is aan de duur van het gat. Een organisatie die zes weken geleden een RAG-pijplijn zonder logging per query heeft ingezet, heeft een gat van zes weken. Een organisatie die achttien maanden geleden is gestart, heeft een gat van achttien maanden — een veel grotere blootstelling bij een regulatoire controle.
Het herstel is het direct implementeren van een gecontroleerde retrievalarchitectuur, accepteren dat het historische gat bestaat en niet achteraf kan worden gedicht, en de hersteltijdlijn nauwkeurig documenteren zodat de huidige positie verdedigbaar is voor de toekomst.
Hoe Kiteworks Logging per Query en Realtime Toegangstracking Implementeert
Het dichten van het logginggat per query vereist een architectuur die elk AI-retrievalevent behandelt als een volwaardige complianceverplichting — niet als een infrastructuurdetail dat alleen wordt vastgelegd als het uitkomt. De architectuur moet voor elk opgehaald document een logentry genereren met de velden die vereist zijn voor registratie onder diverse kaders: geauthenticeerde gebruikersidentiteit, AI-systeemidentiteit, document-ID, gevoeligheidsclassificatie, autorisatiebeslissing en timestamp. Dit moet realtime gebeuren, zonder batching, en integreren met monitoringinfrastructuur zodat de records niet alleen worden gegenereerd maar ook actief worden beoordeeld.
Kiteworks implementeert dit op het retrievalniveau van het Private Data Network. Elke documentretrieval via de AI Data Gateway genereert een individuele toeganglogentry. De entry bevat dubbele toewijzing — de AI-systeemidentiteit en de OAuth 2.0-geauthenticeerde gebruikersidentiteit — de document-ID en het pad, het MIP-gevoeligheidslabel van het opgehaalde document geëvalueerd op het moment van retrieval, de ABAC-beleidsbeslissing (toegestaan of geweigerd) die de retrieval regelde, en de timestamp. Documenten waarvan het MIP-label de autorisatie van de aanvragende gebruiker overschrijdt, worden op het retrievalniveau geweigerd — ze komen nooit in de AI-context — en de weigering wordt gelogd met de beleidsgrondslag.
MIP-labelintegratie betekent dat het Kiteworks-toegangrecord gevoeligheidsbewust is vanaf het moment van retrieval: de investering die de organisatie heeft gedaan in labeling van het documentcorpus wordt op het retrievalniveau afgedwongen en geregistreerd in de auditlog, niet omzeild door AI-workflows die daar nooit voor zijn ontworpen. Voor GDPR Artikel 30-records levert de toeganglog de details van de verwerkingsactiviteit — welke categorieën persoonsgegevens zijn benaderd, door welk systeem, op welke wettelijke grondslag — die Artikel 30-documentatie vereist. Voor HIPAA §164.312(b) voldoet het PHI-retrievalrecord per document exact aan de registratieverplichting.
Alle retrievallogs worden realtime gevoed aan de Kiteworks SIEM-integratie — niet periodiek geëxporteerd, maar direct verwerkt zodra de retrieval plaatsvindt. Dit betekent dat de monitoringbaseline voor AI-retrieval altijd actueel is, anomaliedetectieregels werken op live data, en dat het bewijs van continue monitoring dat FedRAMP en SOC 2 Type II vereisen gedurende de hele auditperiode wordt gegenereerd in plaats van pas bij controle. Hetzelfde gegevensbeheerframework dat secure file sharing, beheerde bestandsoverdracht en beveiligde e-mail reguleert, genereert een gelijkwaardig toegangrecord voor elke AI-retrieval. Er is geen aparte AI-logginginfrastructuur om te implementeren, onderhouden of integreren — en geen tweedeling in governance tussen menselijke en AI-toegang tot de gevoelige data van de organisatie.
Voor compliancefunctionarissen en CDO’s die het logginggat per query moeten dichten voordat het een regulatoire bevinding wordt, biedt Kiteworks de retrievallaag-architectuur die de records genereert. Wilt u logging per query, MIP-labelintegratie en realtime toegangstracking in detail zien? Plan vandaag nog een demo op maat.
Veelgestelde vragen
HIPAA §164.312(b) vereist dat organisaties auditcontroles implementeren die activiteiten in systemen met ePHI registreren en onderzoeken. De registratieverplichting geldt per activiteit — per documenttoegang — niet per sessie. Een sessielog die registreert dat een AI-platform een klinische repository heeft bevraagd, is geen §164.312(b)-conform auditrecord voor de individuele PHI-documenten die binnen die sessie zijn opgehaald. Elke documentretrieval is een afzonderlijke activiteit en vereist een apart record met de specifieke PHI, de verantwoordelijke gebruikersidentiteit en de timestamp. De HIPAA-complianceverplichting voor AI-retrieval is identiek aan die voor menselijke bestandstoegang — per document, per event, met individuele gebruikersattributie.
Ja. GDPR Artikel 4(2) definieert verwerking als elke bewerking op persoonsgegevens, waaronder ophalen en raadplegen. Retrieval wordt expliciet genoemd in de definitie. Een RAG-pijplijn die een document met persoonsgegevens ophaalt, voert een retrievaloperatie uit — verwerking van persoonsgegevens onder de eigen definitie van GDPR, zonder ambiguïteit. Elke dergelijke retrieval moet een wettelijke grondslag hebben onder Artikel 6, onderworpen zijn aan dataminimalisatie onder Artikel 5(1)(c), en worden vastgelegd in Artikel 30-verwerkingenregisters. De automatisering van de retrieval vermenigvuldigt het aantal verwerkingen dat moet worden gedocumenteerd; het vermindert of elimineert de verplichting niet. GDPR-compliance voor AI-inzetten die persoonsgegevens verwerken vereist dezelfde documentatiediscipline als voor elk ander verwerkingssysteem.
Integratie van Microsoft Information Protection (MIP)-labels op het retrievalniveau realiseert drie compliance-doelstellingen tegelijk. Ten eerste maakt het gevoeligheidsbewuste toegangscontrole mogelijk: documenten waarvan het MIP-label de autorisatie van de aanvrager overschrijdt, worden bij retrieval geweigerd en komen nooit in de AI-context — waarmee wordt voldaan aan de eisen voor dataclassificatie onder zowel GDPR-dataminimalisatie als FedRAMP-informatiehandling. Ten tweede levert het toeganglogs met gevoeligheidslabel: elke retrievallog bevat het MIP-label van het benaderde document, waarmee het bewijs van classificatie wordt geleverd dat Artikel 30 en FedRAMP AU-3 vereisen. Ten derde genereert het bewijs van ABAC-beleidshandhaving: wanneer een retrieval wordt geweigerd omdat het MIP-label de autorisatie overschrijdt, wordt de weigering gelogd met de beleidsgrondslag, waarmee het governancebesluit per verzoek wordt vastgelegd dat auditors verlangen.
Nee. Toegangrecords documenteren welke specifieke data op een specifiek moment door een specifieke geauthenticeerde sessie uit een repository is opgehaald. Die informatie bestaat alleen als die op het moment van retrieval is vastgelegd. Achteraf kan de repository zijn gewijzigd, kunnen de benaderde documenten zijn aangepast of verwijderd, zijn de sessies gesloten en bestaan de AI-contextwindows van die sessies niet meer. De events zijn niet te reconstrueren. Voor compliancefunctionarissen betekent dit dat de duur van het logginggat gelijk is aan de duur van de niet-oplosbare complianceblootstelling. Onder HIPAA is het niet bijhouden van §164.312(b)-auditrecords op zichzelf een overtreding van de Security Rule. Onder GDPR is het onvermogen om te voldoen aan het verantwoordingsprincipe een directe Artikel 5(2)-schending. De compliancereactie is om direct logging per query te implementeren, de hersteltijdlijn te documenteren en te accepteren dat het historische gat een eindige blootstelling is met een duidelijke einddatum — geen voortdurende.
GDPR Artikel 15 geeft betrokkenen het recht om bevestiging te krijgen of hun persoonsgegevens worden verwerkt en, zo ja, welke verwerking plaatsvindt en met welk doel. Een betrokkene van wie persoonsgegevens voorkomen in documenten die door AI-queries zijn opgehaald, heeft recht op inzage in die retrievals. Zonder logging per query die vastlegt welke specifieke documenten — en dus welke persoonsgegevens — zijn opgehaald, kan een organisatie niet accuraat reageren op een inzageverzoek over AI-verwerking van hun data. De organisatie kan alleen aangeven dat er AI-verwerking heeft plaatsgevonden op enig niveau, zonder details. Logging per query met documentniveau-specificiteit maakt accurate, volledige antwoorden op inzageverzoeken mogelijk — waarmee aan toezichthouders wordt aangetoond dat het gegevensbeheerprogramma ook AI-verwerking dekt en dat het verantwoordingsprincipe daadwerkelijk wordt toegepast.
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 bestaat geen “–dangerously-skip-permissions” voor uw data - Blog Post
Toezichthouders zijn klaar met vragen naar uw AI-beleid. Ze willen bewijs dat het werkt.