Waarom RAG-implementaties vaak niet door de beveiligingsreview komen — en hoe je er wél een bouwt die dat doet
De demo werkte. De pilot was overtuigend. De businesscase was sterk. En toen begon de security review.
Voor veel enterprise AI-teams is dit het punt waar Retrieval Augmented Generation (RAG)-projecten vastlopen — niet omdat de technologie faalde, maar omdat de architectuur die een geweldige demo opleverde niet de architectuur was die kon voldoen aan de vereisten van het securityteam voor een productie data access-systeem.
Het faalpatroon is zo consistent dat het voorspelbaar is: het AI-team bouwde een systeem geoptimaliseerd voor retrievalkwaliteit en ontwikkelsnelheid; het securityteam beoordeelde het als een systeem dat gevoelige bedrijfsdata op schaal benadert; de twee perspectieven leidden tot verschillende conclusies over gereedheid.
Deze post is voor VP AI/ML Engineering en CISO’s die het patroon willen begrijpen, het gat willen dichten en RAG in productie willen krijgen zonder opnieuw te moeten beginnen met de security review.
Samenvatting voor Executives
Belangrijkste idee: RAG-implementaties falen de security review om zes voorspelbare redenen, die allemaal terug te voeren zijn op dezelfde oorzaak: de retrievallaag werd behandeld als infrastructuur in plaats van als een gereguleerd data access-systeem. Securityteams blokkeren RAG niet omdat ze tegen AI zijn — ze blokkeren het omdat het retrievalonderdeel het data access-profiel heeft van een bevoorrecht systeem en de governance-positie van een ontwikkeltool. Het oplossen van de zes faalmodi vereist het toevoegen van een governance-laag aan de retrievalarchitectuur vóór de security review, niet tijdens.
Waarom dit belangrijk is: Elke cyclus die een RAG-project in herstel van de security review doorbrengt, is een cyclus waarin het geen businesswaarde levert. De kosten zijn niet alleen vertraging — het is het verlies van geloofwaardigheid van het AI-programma bij zakelijke stakeholders die het initiatief hebben goedgekeurd, en de relatie tussen het AI-team en de securityfunctie die elk volgend AI-project zal reguleren. RAG vanaf het begin goed bouwen is geen compliance-oefening; het is hoe AI-teams het vertrouwen opbouwen dat toekomstige projecten sneller laat verlopen.
5 Belangrijkste Inzichten
- Securityteams beoordelen RAG-pijplijnen als data access-systemen, niet als AI-tools. De beoordelingscriteria zijn hetzelfde als voor elk systeem dat gevoelige bedrijfsdata op schaal benadert: authenticatie, toegangscontrole, audittrail, monitoring en incident response. AI-teams die RAG presenteren als een productiviteitstoepassing beantwoorden vragen die het securityteam niet stelt.
- De zes meest voorkomende faalmodi bij security reviews zijn allemaal architectonisch, niet configuratiegebonden. Ze kunnen niet worden opgelost door documentatie toe te voegen of beleid aan te passen. Ze vereisen wijzigingen in authenticatiearchitectuur, autorisatie van de retrievallaag, logginginfrastructuur en monitoringintegratie — wijzigingen die aanzienlijk eenvoudiger zijn aan te brengen vóórdat de retrievallaag is gebouwd dan nadat deze in pilot is.
- Het gat tussen wat security vraagt en wat AI-teams bouwen is geen communicatieprobleem — het is een prioriteitenprobleem. Retrievalkwaliteit, ontwikkelaarservaring en time-to-demo worden geoptimaliseerd in de bouwfase; toegangscontrole, audittrail en monitoring niet. Het resultaat is een systeem dat goed presteert op de dimensies die het AI-team meet en faalt op de dimensies die het securityteam meet.
- Pre-retrieval autorisatiescoping is de enige architectonische beslissing die de meeste security review-vragen tegelijk oplost. Wanneer de retrievallaag per-request RBAC en ABAC afdwingt en retrieval beperkt tot wat de geauthenticeerde gebruiker mag benaderen, wordt de overgeautoriseerde retrieval-faalmodus gesloten, de vraag over handhaving van dataclassificatie beantwoord en de autorisatie-equivalentietest voldaan.
- Een gereguleerde retrievallaag is geen beperking op RAG-capaciteit — het is het verschil tussen een RAG-project dat productie haalt en een project dat blijft hangen in security review. Het AI Data Gateway-patroon biedt de governance-laag als een inzetbaar component in plaats van een maatwerkoplossing, waardoor AI-teams aan securityvereisten kunnen voldoen zonder de retrievalarchitectuur vanaf nul te moeten herbouwen.
Waarom Security Reviews RAG-projecten Stoppen: De Structurele Mismatch
De mismatch tussen AI-teams en securityteams bij RAG is structureel, niet persoonlijk. AI-teams bouwen RAG-pijplijnen met frameworks — LangChain, LlamaIndex, Haystack — die geoptimaliseerd zijn voor retrievalkwaliteit en ontwikkelsnelheid. Deze frameworks verzorgen vectorindexering, embedding, semantisch zoeken en contextopbouw goed. Ze verzorgen geen per-gebruiker autorisatie, per-document logging, handhaving van gevoeligheidslabels of SIEM-integratie — want dat zijn geen retrievalkwaliteitsproblemen. Het zijn governance-problemen, en de frameworks zijn gebouwd door mensen die retrievalkwaliteitsproblemen oplossen.
Wanneer een securityteam het resulterende systeem beoordeelt, passen ze hetzelfde beoordelingskader toe als bij elk nieuw data access-systeem. Ze vragen: wie kan welke data benaderen, hoe wordt die toegang gecontroleerd, hoe wordt het gelogd, hoe wordt het gemonitord en wat gebeurt er als er iets misgaat?
De RAG-pijplijn beantwoordt deze vragen slecht, niet omdat het AI-team slordig was, maar omdat het gebruikte framework standaard geen goede antwoorden genereert. Het serviceaccount bestaat omdat dat de makkelijkste manier was om retrieval te laten werken. Logging op sessieniveau bestaat omdat dat is wat het framework bood. Het ontbreken van handhaving van gevoeligheidslabels bestaat omdat het framework niets weet van MIP-labels.
Het resultaat is een cyclus die zich in organisaties herhaalt: AI-team presenteert demo, securityteam beoordeelt, securityteam vindt zes problemen, AI-team is twee maanden bezig met herstel terwijl zakelijke stakeholders vragen wanneer het project live gaat, AI-team presenteert opnieuw, securityteam vindt drie resterende problemen, cyclus herhaalt zich. De projecten die deze cyclus doorbreken zijn die waarbij de retrievalarchitectuur vanaf het begin is ontworpen met de security-eisen in gedachten — waar gegevensbeheer een ontwerpinput was, niet een drempel aan het eind.
Je vertrouwt erop dat je organisatie veilig is. Maar kun je het verifiëren?
Lees nu
De Zes Faalmodi: Wat Security Vindt en Waarom Goedkeuring Wordt Geblokkeerd
De volgende zes faalmodi komen voor in de meerderheid van enterprise RAG security reviews in gereguleerde sectoren. Elk vertegenwoordigt een vraag die het securityteam zal stellen, een antwoord dat het AI-team niet kan geven met standaard RAG-architectuur, en de architectonische wijziging die nodig is om het op te lossen.
| Faalmodus | Wat het AI-team bouwde | Waarom security het blokkeert | Wat het oplost |
|---|---|---|---|
| Overgeautoriseerde retrieval | RAG-pijplijn gebruikt een serviceaccount met brede repositorytoegang; retrieval is relevantie-gebaseerd zonder per-gebruiker autorisatiescoping | Securityteam vraagt: wat voorkomt dat een gebruiker documenten ophaalt buiten zijn autorisatieniveau? AI-team heeft geen antwoord zonder architectonische aanpassing. | Per-request RBAC/ABAC-handhaving op de retrievallaag; retrieval beperkt tot wat de geauthenticeerde gebruiker mag benaderen, niet wat semantisch relevant is in het volledige corpus |
| Serviceaccount-authenticatie | AI-systeem authenticeert bij databronnen via een gedeeld serviceaccount of statische API-sleutel; geen per-gebruiker identiteit behouden | Securityteam vraagt: welke individu is verantwoordelijk voor elk data access-event? AI-team kan geen individuele toewijzing geven — de enige identiteit in de log is het serviceaccount. | OAuth 2.0 met PKCE en door de gebruiker gedelegeerde autorisatie; individuele gebruikersidentiteit behouden door de authenticatiestroom tot aan de retrievallaag en gelogd bij elk access-event |
| Geen audittrail op de retrievallaag | Logging geïmplementeerd op de AI-applicatielaag (sessielogs, querylogs) maar niet op de datalaag; individuele documentretrievals worden niet geregistreerd | Securityteam vraagt: kun je een overzicht geven van elk opgehaald document, door welke gebruiker, op welke datum? AI-team kan sessielogs tonen die niet voldoen aan de vereisten voor per-document, per-gebruiker registratie. | Per-document retrievallogging op de datalaag, met document-ID, gebruikersidentiteit, autorisatiebeslissing, gevoeligheidsclassificatie en timestamp voor elk retrieval-event |
| Geen handhaving van gevoeligheidslabels | RAG-pijplijn negeert bestaande MIP- of dataclassificatielabels op geïndexeerde documenten; retrieval is gebaseerd op semantische relevantie ongeacht documentclassificatie | Securityteam vraagt: wat voorkomt dat de AI een document ophaalt dat als Restricted of Confidential is gemarkeerd voor een gebruiker zonder de juiste clearance? AI-team heeft geen technische controle om te tonen. | MIP-labelevaluatie op de retrievallaag; documenten boven het autorisatieniveau van de aanvragende gebruiker worden geweigerd vóór ze in de AI-context komen; weigering gelogd met beleidsgrondslag |
| Geen dataresidentie– of datasoevereiniteitscontroles | RAG-pijplijn indexeert documenten uit repositories in diverse rechtsbevoegdheden; retrieval en verwerking kunnen plaatsvinden in infrastructuur buiten de wettelijk vereiste residentiegrenzen van de data | Securityteam of juridische afdeling vraagt: waar wordt deze data verwerkt, en voldoet dat aan onze GDPR/sovereign cloud-verplichtingen voor EU/UK-data? AI-team kan dit niet beantwoorden zonder infrastructuurdocumentatie te raadplegen. | Dataresidentiecontroles die afdwingen waar retrieval, verwerking en opslag plaatsvinden; tenantisolatie die ervoor zorgt dat data uit verschillende rechtsbevoegdheden niet wordt samengevoegd in retrievaloperaties |
| Geen incident response-integratie | RAG-pijplijn heeft geen gedocumenteerde procedure voor het detecteren, indammen of herstellen van een data access-incident; geen SIEM-integratie; geen anomaliedetectie voor retrievalhoeveelheid of -patroon | Securityteam vraagt: als de AI-pijplijn wordt gebruikt voor bulkdata-extractie, hoe zou je dat detecteren? Wat is de responseprocedure? AI-team heeft geen gedocumenteerd antwoord. | Realtime SIEM-integratie met retrievalactiviteit; per-gebruiker retrievalhoeveelheid-baselines en anomalie-alerting; gedocumenteerde AI-specifieke incident response-procedures geïntegreerd met het bredere IR-programma |
Wat Securityteams Eigenlijk Vragen
Het vertalen van security review-vereisten naar architectonische specificaties is een terugkerend frictiepunt tussen AI-teams en securityfuncties. De vragen die security stelt zijn niet willekeurig. Ze komen direct voort uit de securitycontroles die bedrijfsbrede securityprogramma’s toepassen op alle bevoorrechte data access-systemen, afgeleid van dezelfde frameworkvereisten die EHR-toegang, financiële rapportagesystemen en gereguleerde bestandsoverdrachtinfrastructuur reguleren. Begrijpen wat de vragen daadwerkelijk betekenen maakt de benodigde architectuur inzichtelijk.
Wanneer security vraagt “wat voorkomt dat een gebruiker data benadert buiten zijn autorisatie”…
…vragen ze om bewijs dat het retrievalsysteem het toegangscontrolebeleid van de organisatie per-request afdwingt, niet per sessie. Het antwoord dat ze zoeken is: “retrieval is beperkt door het RBAC- en ABAC-profiel van de geauthenticeerde gebruiker op het moment van elke query, en documenten buiten dat bereik worden uitgesloten van retrieval vóór ze in de AI-context komen.” Het antwoord dat ze niet zoeken is: “het AI-model krijgt de instructie geen documenten te gebruiken die de gebruiker niet mag zien.”
Wanneer security vraagt “wie is verantwoordelijk voor elk data access-event”…
…vragen ze om individuele gebruikersherkomst in de audittrail, niet een serviceaccount-identiteit. Het antwoord dat ze zoeken is: “OAuth 2.0 met door de gebruiker gedelegeerde autorisatie behoudt de identiteit van de geauthenticeerde gebruiker tot aan de retrievallaag, en elke logregel bevat zowel de AI-systeemidentiteit als de individuele gebruikersidentiteit.” Het antwoord dat ze niet zoeken is: “het AI-platform logt de sessie, en we kunnen dat koppelen aan gebruikersactiviteit.”
Wanneer security vraagt “hoe zou je bulkdata-extractie detecteren”…
…vragen ze om een monitoringarchitectuur, niet een theoretische beschrijving van hoe afwijkend gedrag eruit zou zien. Het antwoord dat ze zoeken is: “retrievalactiviteit wordt realtime naar SIEM gestuurd; per-gebruiker retrievalhoeveelheid-baselines zijn vastgesteld; afwijkingen boven de drempel genereren automatische alerts.” Het antwoord dat ze niet zoeken is: “als iemand dat zou doen, zouden we het waarschijnlijk in de logs zien.”
Wanneer security vraagt “wat gebeurt er als dit systeem wordt gecompromitteerd”…
…vragen ze om gedocumenteerde incident response-procedures specifiek voor de AI-pijplijn, niet een verwijzing naar het algemene IR-beleid. Het antwoord dat ze zoeken is: “het IR-plan heeft een AI-specifieke bijlage met detectie-indicatoren, indamprocedures voor het retrievalonderdeel, forensische bewaarstappen en de notificatieworkflow als PHI of persoonsgegevens betrokken zijn.”
Security Review Gereedheid: Tien Vereisten en Wat Elk Nodig Heeft
De volgende checklist koppelt de tien meest consistente security review-vereisten voor enterprise RAG-implementaties aan de specifieke architectonische capaciteiten die nodig zijn om aan elk te voldoen. AI-teams moeten deze lijst gebruiken vóórdat ze indienen voor security review — elke vereiste waar het antwoord “nog niet” is, is een bevinding die goedkeuring vertraagt.
| Security review-vereiste | Categorie | Wat nodig is om eraan te voldoen |
|---|---|---|
| Kunt u aantonen dat retrieval beperkt is tot wat de aanvragende gebruiker mag benaderen, niet het volledige corpus? | Authenticatie / Toegang | Vereist per-request RBAC/ABAC-handhaving op de retrievallaag met gelogde autorisatiebeslissingen; retrieval op alleen relevantie zonder gebruikersscoping voldoet niet aan deze vereiste |
| Kunt u aantonen dat er geen gedeelde serviceaccounts of statische API-sleutels worden gebruikt voor AI data access? | Authenticatie | Vereist OAuth 2.0 met door de gebruiker gedelegeerde autorisatie; individuele gebruikersidentiteit moet behouden blijven tot aan de retrievallaag en aanwezig zijn in elke auditlogregel |
| Kunt u een voorbeeld van een logregel tonen met de individuele gebruiker, specifiek opgehaald document, autorisatiebeslissing en timestamp voor een RAG-retrievalevent? | Audit / Logging | Vereist per-document retrievallogging op de datalaag; sessielogs of applicatielogs voldoen niet aan deze vereiste; het voorbeeld van een logregel is het meest voorkomende bewijsverzoek bij security review |
| Kunt u aantonen dat MIP-gevoeligheidslabels op geïndexeerde documenten worden geëvalueerd bij retrieval? | Dataclassificatie | Vereist MIP-labelintegratie op de retrievallaag; documenten boven het autorisatieniveau van de gebruiker moeten worden geweigerd vóór ze in de AI-context komen; weigering moet gelogd worden met beleidsgrondslag |
| Kunt u aantonen dat AI data access-events realtime naar SIEM worden gestuurd? | Monitoring / Detectie | Vereist realtime SIEM-integratie op de retrievallaag; periodieke logexports voldoen niet aan de continue monitoringvereisten voor FedRAMP, SOC 2 of bedrijfssecuritybeleid |
| Kunt u de anomaliedetectieregels voor AI-retrievalactiviteit beschrijven en een voorbeeldalert tonen? | Monitoring / Detectie | Vereist gedocumenteerde basisregels voor retrievalhoeveelheid en querypatronen, en ten minste één voorbeeldalert om aan te tonen dat de monitoring operationeel is en niet alleen geconfigureerd maar inactief |
| Kunt u aantonen dat retrieval en verwerking van data die onder residentievereisten valt, plaatsvindt binnen de vereiste rechtsbevoegdheid? | Dataresidentie | Vereist infrastructuurdocumentatie die retrieval-, verwerkings- en opslaglocaties toont; voor GDPR-gebonden data moet EU/UK-residentie of een wettig overdrachtsmechanisme worden aangetoond |
| Heeft u een gedocumenteerde incident response-procedure specifiek voor AI data access-incidenten? | Incident Response | Vereist een AI-specifieke bijlage bij het bestaande IR-plan, met detectie-indicatoren, indamprocedures en forensische bewaarstappen specifiek voor RAG-pijplijnincidenten |
| Kunt u aantonen dat de toegangscontroles voor AI data access gelijkwaardig zijn aan die voor menselijke toegang tot dezelfde data? | Toegangscontrole-equivalentie | Vereist dat de RBAC/ABAC-beleidsregels voor menselijke toegang tot de repository ook gelden voor AI-retrieval uit dezelfde repository; aparte, zwakkere AI-toegangscontroles falen deze test |
| Kunt u aantonen dat het AI-systeem geen data kan ophalen of verwerken die de aansturende gebruiker via een ander kanaal niet mag benaderen? | Autorisatiebereik | Vereist pre-retrieval autorisatiescoping, niet post-retrieval filtering; de test is of ongeautoriseerde data ooit in de AI-context komt, niet of het uit de respons wordt verwijderd |
Architectuur die Slaagt: De Governance-laag Bouwen vóór de Security Review
De meest effectieve manier om een RAG security review te doorstaan is om vooraf een pre-build versie ervan uit te voeren. Voordat de retrievalarchitectuur wordt afgerond, moet het AI-team de tien bovenstaande vereisten doorlopen en bepalen welke architectonische beslissingen vereisen in plaats van configuratiekeuzes.
Dit zijn de beslissingen die duur zijn om achteraf te corrigeren als de pijplijn eenmaal is gebouwd. De zaken die later eenvoudig toe te voegen zijn — documentatie, beleidsupdates, IR-planbijlagen — kunnen wachten. De zaken die het herontwerpen van het authenticatiemodel, het herbouwen van de retrievalautorisatielaag of het vervangen van serviceaccount-credentials vereisen, zijn niet goedkoop om later toe te voegen.
De beslissing over de authenticatiearchitectuur is de meest bepalende en de minst omkeerbare. Kiezen voor OAuth 2.0 met door de gebruiker gedelegeerde autorisatie in plaats van een serviceaccount als retrieval-authenticatiemechanisme bepaalt of individuele gebruikersherkomst beschikbaar is in elke volgende logregel, elke audittrail en elke scopebepaling bij een datalekmelding.
Het is architectonisch eenvoudig om deze keuze vooraf te maken; het is architectonisch kostbaar om het te retrofitten in een uitgerolde pijplijn waarbij sessiebeheer is ontworpen rond serviceaccount-identiteit.
De beslissing over retrievalautorisatiearchitectuur is de tweede meest bepalende. Pre-retrieval autorisatiescoping — RBAC- en ABAC-beperkingen afdwingen vóór de retrievaloperatie, niet als post-retrieval filter — vereist dat het retrievalsysteem het autorisatieprofiel van de aanvragende gebruiker kent.
Dit is niet beschikbaar in standaard RAG-frameworkconfiguraties; het vereist een gereguleerde retrievallaag die tussen de gebruikersquery en de vectorzoekopdracht zit. Deze laag als onderdeel van de initiële architectuur bouwen is eenvoudig; het retrofitten in een pijplijn waar de vectorzoekopdracht direct op het volledige corpus werkt vereist het herbouwen van het retrievalonderdeel vanaf nul.
De beslissing over loggingarchitectuur volgt uit de retrievalautorisatiearchitectuur. Per-document retrievallogging vereist dat de retrievallaag een logevent genereert voor elk document dat het retourneert, met het document-ID, de gebruikersidentiteit, de autorisatiebeslissing en de gevoeligheidsclassificatie.
Dit logevent moet worden gegenereerd op de retrievallaag, niet gereconstrueerd uit applicatielogs. Als de retrievallaag dit event niet standaard genereert, vereist het toevoegen ervan later instrumentatie van het retrievalonderdeel — wat eenvoudiger is als het onderdeel doelbewust voor governance is gebouwd dan wanneer het een framework-standaard vectorzoekopdracht is.
De Governance-laag: Waarom het AI Data Gateway-patroon het Security Review-probleem Oplost
Het architectonische inzicht dat RAG security review vereenvoudigt is dat alle zes faalmodi kunnen worden opgelost door een enkele governance-laag die tussen het retrievalverzoek van de RAG-pijplijn en de data repositories die het indexeert zit.
Deze governance-laag verzorgt authenticatie (OAuth 2.0 met PKCE), per-request autorisatie (RBAC en ABAC geëvalueerd tegen het gebruikersprofiel), handhaving van gevoeligheidslabels (MIP-labelevaluatie bij retrieval), per-document logging (elke retrievalactie gelogd met volledige herkomst) en SIEM-integratie (realtime forwarding).
De RAG-pijplijn zelf — de vectorindexering, de embedding, de contextopbouw, het model — blijft ongewijzigd. De governance-laag is geen beperking op retrievalkwaliteit; het is een wrapper rond de retrievaloperatie die compliant toegang oplevert in plaats van ongecontroleerde toegang.
Dit is het AI Data Gateway-patroon. In plaats van governance-capaciteiten direct in het RAG-framework te bouwen — wat maatwerkontwikkeling vereist op frameworks die daar niet voor ontworpen zijn — is de governance-laag een apart component waar de retrievaloperatie doorheen loopt.
De RAG-pijplijn vraagt om retrieval; de governance-laag evalueert het verzoek tegen het autorisatieprofiel van de geauthenticeerde gebruiker, handhaaft gevoeligheidsbeleid, voert de retrieval uit op het geautoriseerde deel van het corpus, logt het resultaat en retourneert de opgehaalde documenten aan de pijplijn.
Vanuit het perspectief van de RAG-pijplijn ontvangt deze de documenten die zijn aangevraagd. Vanuit het perspectief van het securityteam is aan elke security review-vereiste voldaan vóórdat de documenten zijn teruggegeven.
De build-versus-buy-afweging voor dit patroon is voor de meeste organisaties eenvoudig. Zelf een gereguleerde retrievallaag bouwen vereist: implementatie van OAuth 2.0 met PKCE en integratie met het enterprise identity & access management-systeem; een per-request autorisatie-engine die RBAC- en ABAC-beleidsregels uit het beleidsarchief van de organisatie evalueert; integratie van MIP-labelevaluatie in het retrievalpad; opbouw van een per-document logginginfrastructuur met SIEM-forwarding; en onderhoud van dit alles als productiesysteem.
Het alternatief is het inzetten van een doelgericht gebouwde AI Data Gateway die al deze capaciteiten als managed component biedt, zodat het AI-team zich kan richten op het bouwen van de AI-applicatie terwijl de governance-laag regelt wat het securityteam nodig heeft.
Hoe Kiteworks RAG in Productie Krijgt
Het uitgangspunt achter de Kiteworks AI Data Gateway is dat RAG security review-falen een architectonisch probleem is met een architectonische oplossing — en dat de oplossing niet vereist dat de RAG-pijplijn wordt herbouwd, alleen dat de ontbrekende governance-laag wordt toegevoegd. De AI Data Gateway biedt die laag als inzetbaar component geïntegreerd met het Kiteworks Private Data Network, waarmee elk van de zes security review-faalmodi wordt opgelost zonder maatwerkontwikkeling.
Authenticatie wordt afgehandeld via OAuth 2.0 met PKCE, waardoor de identiteit van de geauthenticeerde medewerker van de AI-assistent tot aan de retrievallaag behouden blijft. Geen serviceaccount bemiddelt de toegangsketen; elke retrieval wordt geautoriseerd onder de identiteit van de individuele gebruiker en elke auditlogregel bevat die identiteit naast de AI-systeemidentiteit.
Per-request RBAC- en ABAC-autorisatie wordt afgedwongen op de retrievallaag door de Kiteworks Data Policy Engine, die het autorisatieprofiel van de gebruiker evalueert tegen het aangevraagde document vóórdat het document in de AI-context komt. MIP-gevoeligheidslabels worden geëvalueerd bij retrieval; documenten boven het clearance-niveau van de gebruiker worden geweigerd vóór retrieval, en de weigering wordt gelogd met de beleidsgrondslag.
Per-document retrievallogging genereert een volledige auditlogregel voor elk retrievalevent: gebruikersidentiteit, AI-systeemidentiteit, document-ID, gevoeligheidsclassificatie, autorisatiebeslissing en timestamp. Elke regel wordt realtime naar de Kiteworks SIEM-integratie gestuurd, waarmee het continue monitoringrecord wordt opgebouwd dat securityteams en compliance-frameworks vereisen.
Per-gebruiker retrievalhoeveelheid-baselines zijn standaard actief, en anomaliealerts worden gegenereerd wanneer retrievalpatronen afwijken — waarmee de detectiecapaciteit wordt geboden waar securityteams naar vragen en AI-teams zelden een goed antwoord op hebben.
De zero trust gegevensuitwisselingsarchitectuur die beveiligd delen van bestanden, beheerde bestandsoverdracht en beveiligde e-mail in de hele organisatie reguleert, strekt zich uit tot elke RAG-retrieval — zodat de datagovernance-positie die aan security is aangetoond voor traditionele datakanalen dezelfde positie is die wordt aangetoond voor de AI-pijplijn.
Er is geen aparte security review voor een nieuwe data access-architectuur; er is een uitbreiding van een al goedgekeurd governance-framework naar een nieuw consumptiepatroon. Voor AI-teams die RAG van pilot naar productie willen brengen, is dat het verschil tussen een security review-cyclus van zes maanden en een behapbare cyclus.
Voor VP AI/ML Engineering en CISO’s die willen stoppen met het verliezen van RAG-projecten bij de securitypoort, biedt Kiteworks de governance-laag die het gat dicht. Ontdek hoe de AI Data Gateway aan elk van de tien security review-vereisten voldoet, plan vandaag nog een aangepaste demo.
Veelgestelde Vragen
RAG-frameworks zijn gebouwd om retrievalkwaliteitsproblemen op te lossen: semantisch zoeken, embeddingkwaliteit, contextopbouw en responsnauwkeurigheid. Ze zijn niet gebouwd om governance-problemen op te lossen: per-gebruiker autorisatie, per-document audittrail, handhaving van gevoeligheidslabels en SIEM-integratie. Wanneer een AI-team een RAG-pijplijn bouwt met standaard frameworks die geoptimaliseerd zijn voor retrievalkwaliteit, produceren ze een systeem dat goed presteert op retrievaldimensies en slecht op governancedimensies. Securityteams beoordelen de governancedimensies, vinden ze onvoldoende en blokkeren goedkeuring. Het falen is voorspelbaar omdat de frameworks standaard geen governance-capaciteiten bieden en de meeste AI-teams ze pas toevoegen als security erom vraagt. De governance-laag in de retrievalarchitectuur bouwen vóór de security review is de enige betrouwbare manier om deze cyclus te doorbreken.
Pre-retrieval autorisatiescoping dwingt het RBAC- en ABAC-autorisatieprofiel van de aanvragende gebruiker af als beperking op de retrievaloperatie zelf, zodat de vectorzoekopdracht alleen documenten retourneert die de gebruiker mag benaderen. Post-retrieval filtering haalt eerst alle semantisch relevante documenten op en verwijdert daarna de documenten die de gebruiker niet mag zien. Het securityverschil is fundamenteel: post-retrieval filtering betekent dat ongeautoriseerde documenten zijn opgehaald en in de AI-context zijn geplaatst vóórdat ze zijn verwijderd — de ongeautoriseerde toegang heeft dus al plaatsgevonden. Pre-retrieval autorisatiescoping betekent dat ongeautoriseerde documenten helemaal niet worden opgehaald. Securityteams eisen het laatste, omdat het eerste de data access niet voorkomt; het filtert alleen de respons.
Enterprise security review voor RAG-authenticatie vereist drie zaken: individuele gebruikersidentiteit behouden tot aan de retrievallaag (geen gedeeld serviceaccount), kortlevende tokens in plaats van statische API-sleutels (om het credential-exposure-venster te beperken), en authenticatie die voldoet aan het bestaande enterprise identity & access management-framework. OAuth 2.0 met PKCE voldoet aan alle drie: door de gebruiker gedelegeerde autorisatie behoudt de identiteit van de individuele gebruiker door de authenticatiestroom tot aan de retrievallaag; tokens zijn kortlevend en PKCE voorkomt onderschepping van de autorisatiecode; en OAuth 2.0 integreert met enterprise identity providers. Serviceaccounts en statische API-sleutels falen op de eerste vereiste en worden als bevindingen aangemerkt in vrijwel elke gereguleerde RAG-evaluatie.
Het is technisch mogelijk maar in de praktijk lastig. Standaard RAG-frameworks bieden geen per-request ABAC-autorisatie, per-document retrievallogging, MIP-labelintegratie of SIEM-forwarding als ingebouwde capaciteiten. Het implementeren van deze capaciteiten bovenop standaard frameworks vereist maatwerkontwikkeling van een OAuth 2.0-integratielaag, een per-request autorisatie-engine, een retrieval-instrumentatielaag voor per-document logging, een MIP-labelevaluatie-integratie en een log-forwarding-integratie — elk een onderhoudbaar productiesysteem. Organisaties die dit op maat bouwen, bouwen in feite een AI Data Gateway vanaf nul. Het inzetten van een doelgericht component is sneller, betrouwbaarder en levert een security review-bewijspakket op dat direct aansluit bij de beoordelingscriteria, in plaats van dat het AI-team moet documenteren hoe elke maatwerkimplementatie aan elke vereiste voldoet.
Een correct geïmplementeerde governance-laag vermindert de retrievalkwaliteit of responsnauwkeurigheid niet; het verandert de scope van de retrievaloperatie. Pre-retrieval autorisatiescoping betekent dat de vectorzoekopdracht wordt uitgevoerd op het deel van het corpus dat de gebruiker mag benaderen, in plaats van het volledige corpus. Voor de meeste gebruikers is dit het corpus waarvan ze verwachten dat de AI het doorzoekt — hun geautoriseerde datagovernancedomein. De responsnauwkeurigheid voor hun geautoriseerde scope blijft onveranderd. De enige kwaliteitsverandering is dat de AI geen documenten zal gebruiken buiten het autorisatieniveau van de gebruiker — wat het beoogde gedrag is, geen verslechtering. Het zero trust gegevensuitwisselingsprincipe van elke aanvraag verifiëren in plaats van brede toegang vertrouwen geldt hier: een gereguleerde retrieval die nauwkeurige resultaten binnen geautoriseerde scope oplevert is een beter productiesysteem dan een ongereguleerde retrieval die soms resultaten buiten geautoriseerde scope retourneert.
Aanvullende Bronnen
- Blog Post
Zero‑Trust Strategieën voor Betaalbare AI-privacybescherming - Blog Post
Hoe 77% van de organisaties faalt op 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 je data - Blog Post
Toezichthouders zijn klaar met vragen of je een AI-beleid hebt. Ze willen bewijs dat het werkt.