En RAG-løsning er kun så sikker som det svageste rettighedstjek i
En RAG-løsning er kun så sikker som det svageste rettighedstjek i kæden. Når en medarbejder stiller et spørgsmål, må svaret aldrig bygge på et dokument, som vedkommende ikke må åbne i kildesystemet. Amazon Quick og Amazon Bedrock Knowledge Bases løser det ved at spørge kilden om rettighederne i det øjeblik, forespørgslen kommer, i stedet for at stole på en kopi af dem.
Hvorfor rettigheder er det svageste led i enterprise RAG
De fleste RAG-projekter starter med det sjove: indeksering, embeddings og et chatinterface, der svarer overraskende godt. Rettighederne kommer senere, og det er her, mange projekter går galt. Et vektorindeks har ingen indbygget forståelse for, hvem der må se hvad. Det returnerer de tekststykker, der ligner spørgsmålet mest, uanset hvor følsomme de er.
En sprogmodel kan ikke bede om skånsel. Hvis et fortroligt uddrag når frem til modellens kontekst, kan det også dukke op i svaret. Derfor mener jeg, at adgangskontrol ikke hører hjemme i prompten ("vis kun det, brugeren må se"), men i søgningen, før modellen overhovedet ser noget.
Hvor rettighederne faktisk ligger: SharePoint, Google Drive og Confluence
I en typisk virksomhed ligger videnskilderne spredt over flere systemer, og hvert system har sin egen rettighedsmodel. SharePoint arbejder med sites, biblioteker, grupper og nedarvede tilladelser. Google Drive har delte drev, mapper og deling på enkeltfilniveau. Confluence styrer adgang via spaces og sidebegrænsninger.
Det gør et centralt rettighedsregister svært at bygge. Rettighederne ændrer sig løbende: Folk skifter afdeling, forlader virksomheden, og en fil bliver delt eller trukket tilbage. Hver gang noget ændres, skal kopien i RAG-indekset ændres med. Det er her, den traditionelle tilgang knækker.
Fra kopierede rettigheder til tjek hos kilden
Den klassiske løsning er at kopiere adgangslisterne (ACL'er) ind i indekset sammen med indholdet og filtrere søgeresultaterne efter dem. Det virker, men kun så længe kopien er aktuel. Mellem to synkroniseringer findes et vindue, hvor en bruger, der netop har mistet adgang, stadig kan få indholdet serveret. Og ved store datamængder bliver synkroniseringen en driftsopgave i sig selv.
Amazon beskriver en anden vej. Rettighederne bliver i kildesystemet, som fortsat er den autoritative sandhed, og brugerens tilladelser bliver verificeret direkte hos kilden, når spørgsmålet stilles. Der er ingen kopi, der kan blive forældet. Det er den arkitektur, jeg selv ville vælge, hvis jeg skulle forsvare løsningen over for en sikkerhedschef.
Sådan fungerer realtidsverifikationen ved en forespørgsel
Forløbet følger en enkel rækkefølge. Brugeren stiller et spørgsmål og er identificeret via virksomhedens identitetsløsning. Søgningen returnerer en række kandidater fra de tilsluttede kilder. For hvert kandidatdokument kontrolleres det så, om netop denne bruger har læseadgang i kildesystemet. Kun de dokumenter, der består tjekket, sendes videre som kontekst til modellen.
Den vigtige designbeslutning er rækkefølgen: Filtreringen sker før generering. Et dokument, der er frasorteret, når aldrig modellen, og kan derfor heller ikke lække gennem en omskrivning, et resumé eller en ufuldstændig afvisning. Afvejningen er latenstid, fordi hvert svar kræver ekstra opslag. Det er prisen for, at svaret altid afspejler rettighederne i dette sekund og ikke fra i går.
Et dokument, der er frasorteret, når aldrig modellen, og kan derfor heller ikke lække.
Hvad det betyder for kontrol, sporbarhed og compliance
For en it- eller sikkerhedschef er gevinsten først og fremmest, at der kun er ét sted at administrere adgang. Når en medarbejder fratages rettigheder i SharePoint, gælder det også i RAG-assistenten, uden at nogen skal huske at opdatere et andet system.
Det gør også revision enklere, så længe du kan se, hvad assistenten har gjort. Jeg ville kræve, at spørgsmålet "hvem så hvad, og hvornår" kan besvares ud fra logs, før noget går i produktion. Det er en fordel i forhold til GDPR, hvor dataminimering og kontrol med, hvem der behandler personoplysninger, er centrale krav. En assistent, der ikke kan nå længere end brugeren selv, er langt nemmere at forsvare over for en tilsynsmyndighed end en, der kigger i en samlet kopi af alt.
Kontrollen er dog ikke bedre end det, der ligger i kilden. Hvis SharePoint-sites i årevis har været delt for bredt, vil realtidstjekket loyalt bekræfte, at alle må se dem. Rettighedsoprydning er derfor en forudsætning, ikke en bivirkning.
Det bør du teste, før RAG går i produktion
Start med at oprette testbrugere med bevidst forskellige roller og stil dem de samme spørgsmål. Svarene skal afvige præcis dér, hvor rettighederne afviger. Kontrollér både direkte spørgsmål ("hvad er direktionens løn?") og indirekte, hvor følsomt indhold kunne snige sig ind i et opsummerende svar.
Test dernæst ændringer undervejs: Fjern en brugers adgang til en mappe, og stil spørgsmålet igen med det samme. Svaret skal ændre sig uden ventetid. Prøv også forladte medarbejdere, gæstebrugere og dokumenter, der er flyttet mellem mapper.
Mål til sidst latenstiden under realistisk belastning og tjek, at kildernes logs viser de forventede opslag. Hvis du kan svare på, hvem der fik hvilket dokument i en testkørsel, har du fundamentet til at forsvare løsningen over for revisor, dataansvarlig og ledelse.