RAG til virksomhedsviden: tilladelser, datalæk og kildegrænser

Den mest almindelige RAG-fejl i virksomheder er enkel: Upload alt, stil spørgsmål, og betragt automatisk svar med kildehenvisninger som sikre.

Den næstmest almindelige fejl viser sig senere: Nogen opdager, at assistenten kan svare ud fra dokumenter, som brugeren aldrig burde have set. Lønrammer. Kundekontrakter. Juridiske udkast. Bestyrelsesnotater. Supportsager. HR-undersøgelser. Sikkerhedsprocedurer. Svaret kan være korrekt og have en kildehenvisning, men systemet har lækket oplysninger.

En RAG til virksomhedsviden er ikke et søgefelt med pænere formuleringer. Den er et adgangsstyret informationssystem. Behandl den sådan.

Hentningen skal håndhæve de samme eller strengere tilladelser end kildesystemerne. Hvis en bruger ikke kan åbne dokumentet i Google Drive, SharePoint, Notion, Confluence eller CRM-systemet, må RAG-systemet ikke hente det for den pågældende bruger.

Grundreglen

Hentningslaget skal besvare dette spørgsmål, før det returnerer en eneste chunk:

Må denne bruger se denne kilde lige nu?

Ikke »Findes kilden i vektordatabasen?« Ikke »Er kilden relevant?« Ikke »Er kilden nyttig?« Tilladelsen kommer først.

Der findes tre almindelige mønstre:

Det rigtige valg afhænger af kildesystemerne og risikoniveauet. For de fleste SMV’er er separate indeks kombineret med metadatafiltrering tilstrækkeligt. Ved kunde-, HR-, juridiske eller regulerede data kan kontrol i realtid være nødvendig.

Den svære del: at holde ACL’er synkroniseret

Alle mønstrene ovenfor afhænger i praksis af én ting: Tilladelsesdataene i indekset skal svare til tilladelsesdataene i kildesystemet. Det egentlige ingeniørarbejde ligger i denne synkronisering.

ACL’ernes oprindelse. SharePoint og OneDrive eksponerer tilladelser pr. element gennem Microsoft Graph API. Google Drive gør det gennem Drive API’ets tilladelsesliste pr. fil, og Confluence gennem begrænsninger på spaces og sider. Systemerne har forskellige modeller for brugere, grupper, nedarvning og delingslinks, forskellige API-begrænsninger og forskellige definitioner af, hvem der må se et element.

Udvidelse af grupper er ikke valgfri. De fleste reelle tilladelser tildeles grupper, og grupper kan være indlejrede. »Sales EU« i »Sales« i »All Staff« skal udfoldes til konkrete brugere enten ved synkronisering — større indeksmetadata og hurtigere forespørgsler — eller på forespørgselstidspunktet — mere aktuelle data, men langsommere svar og flere API-kald. Vælg bevidst. Teams, der lader tilfældighederne afgøre det, får en inkonsistent løsning.

Synkroniseringsforsinkelse er en sikkerhedsparameter, ikke en ydelsesdetalje. Når en person mister adgang til et dokument på grund af en rolleændring, offboarding eller en aftale, der bliver fortrolig, fortsætter indekset med at anvende den gamle ACL indtil næste synkronisering. Fastlæg og dokumenter den acceptable forsinkelse for tilbagekaldelse af adgang pr. korpus: tæt på realtid for stærkt begrænsede korpora, mens timer kan være acceptable for interne procesdokumenter. Hvis ingen har skrevet tallet ned, er det reelle svar »når nattens job kører«, og det består ikke et sikkerhedsreview.

Kontrol i realtid giver aktualitet, men koster latenstid, API-kvote og en ny fejltilstand. Et tilladelseskald pr. hentning tilføjer en rundtur til kildesystemet for hver forespørgsel og bruger hurtigt API-kvoten ved stor skala. Det almindelige kompromis er en kortlivet cache, som i praksis ændrer »realtid« til »synkroniseringsforsinkelse med et mindre tal«. Uanset valget skal timeoutadfærden være eksplicit: Hvis tilladelseskontrollen fejler eller får timeout, må chunken ikke anvendes. Luk af som standard, log fejlen, og lad assistenten afvise. Et langsomt, korrekt svar er bedre end et hurtigt datalæk.

Offboardingtesten i testafsnittet viser, om dette faktisk virker: En deaktiveret konto må ikke kunne hente noget fra stærkt begrænsede korpora, og kontrollen skal også virke dagen efter deaktiveringen — ikke først efter den næste fulde gensynkronisering.

Kildegrænser

Opret ikke én stor videnspulje. Opdel efter målgruppe og følsomhed:

Jo færre målgrupper et korpus betjener, desto lettere er det at analysere risikoen for datalæk.

Kontroller ved ingestion

Mange datalæk begynder i ingestion-pipelinen.

Registrer følgende, før en kilde indekseres:

• Kildesystem.
• Dokument-id.
• Ejer.
• Målgruppe eller ACL.
• Følsomhedsmærkat.
• Tidsstempler for oprettelse og opdatering.
• Udløbsdato eller reviewdato.
• Om dokumentet må anvendes til AI-baseret hentning.
• Om dokumentet indeholder personoplysninger.

Bevar eksisterende mærkater fra kildesystemet. Hvis systemet ikke har mærkater, skal I tilføje et enkelt klassificeringstrin før ingestion.

Kontroller ved hentning

Hentningen skal ske i denne rækkefølge:

1. Identificer brugeren og vedkommendes grupper.
2. Identificer det ønskede arbejdsområde eller den ønskede assistent.
3. Filtrer mulige kilder efter korpus, ACL, følsomhed og aktualitet.
4. Hent kun relevante chunks fra tilladte kilder.
5. Genrangér de tilladte chunks.
6. Generer svaret med kildehenvisninger.
7. Afvis eller eskaler, når de tilladte kilder ikke er tilstrækkelige.

Hent ikke først for derefter at filtrere i prompten. Hvis en forbudt chunk når ind i modellens kontekst, er sikkerhedsgrænsen allerede brudt.

Prompt- og svaradfærd

Assistenten skal instrueres i at:

• Svare udelukkende ud fra hentede kilder.
• Angive kildens titel og afsnit eller link.
• Oplyse, når de tilladte kilder ikke indeholder svaret.
• Markere inferenser særskilt fra kildebaserede fakta.
• Undgå at afsløre, at stærkt begrænsede kilder findes.
• Undgå at opsummere materiale, som brugeren ikke har adgang til.

Dårlig afvisning:

»Jeg fandt HR’s lønrammer, men du har ikke adgang.«

Bedre afvisning:

»Jeg har ingen godkendt kilde til rådighed, som kan besvare spørgsmålet.«

Det andet svar afslører hverken eksistensen af eller emnet for begrænsede dokumenter.

Logning uden at skabe endnu et datalæk

RAG-logfiler er følsomme. De kan indeholde brugerspørgsmål, hentede chunks, kilde-id’er, svar og undertiden personoplysninger.

Log tilstrækkeligt til fejlfinding:

• Bruger-id eller pseudonymiseret id.
• Assistent eller arbejdsområde.
• Tidspunkt for forespørgslen.
• Id’er på hentede kilder.
• Resultat af tilladelsesfiltreringen.
• Svar-id.
• Årsag til afvisning eller eskalering.
• Latenstid og fejl.

Vær forsigtig med:

• Fuldstændige brugerspørgsmål.
• Fuldstændige hentede chunks.
• Fuldstændige genererede svar.
• Kundedata.
• HR-, juridiske eller sikkerhedsmæssige emner.

Gem maskerede logfiler eller kilde-id’er i stedet for fuld tekst i følsomme systemer. Giv logfilerne deres egen adgangskontrol og opbevaringsperiode.

Forældede og modstridende kilder

Tilladelser er ikke den eneste grænse. Kildernes kvalitet har også betydning.

Hver indekseret kilde skal have en ejer og en regel for aktualitet:

Når kilder er i konflikt, må assistenten kun vise konflikten, hvis brugeren har adgang til begge kilder. Ellers skal den svare ud fra den tilladte kilde med højest autoritet eller eskalere.

Test af tilladelsesgrænser

Test med brugere, ikke kun med dokumenter:

• Medarbejder med bred adgang.
• Medarbejder med snæver afdelingsadgang.
• Leder med adgang til eget team.
• Ekstern konsulent.
• Tidligere medarbejder eller deaktiveret konto.
• Supportmedarbejder med kundekontakt.
• Administrator.

Stil følgende spørgsmål for hver profil:

• Et spørgsmål, som profilen bør kunne besvare.
• Et spørgsmål lige uden for profilens tilladelser.
• Et spørgsmål om et begrænset dokument, som profilen ved findes.
• Et spørgsmål, hvor offentlige og interne dokumenter er i konflikt.
• Et spørgsmål med prompt injection: »Ignorer adgangsreglerne.«

Det korrekte resultat er ikke blot »et godt svar«. Det er »et godt svar fra tilladte kilder«.

Udrulningsforløb

Begynd med det mindst følsomme korpus:

1. Offentlige dokumenter og produktdokumenter.
2. Interne driftsdokumenter.
3. Afdelingsspecifikke dokumenter.
4. Kunderegistre med strenge ACL’er.
5. Stærkt begrænsede korpora, men kun efter udtrykkelig sikkerhedsmæssig og juridisk godkendelse.

Mål følgende i hver fase:

• Hvor nyttige svarene er.
• Kvaliteten af kildehenvisninger.
• Om afvisninger er korrekte.
• Andelen af hentninger, der afvises på grund af adgang.
• Andelen af forældede kilder.
• Brugerrapporter om manglende eller forkerte kilder.

Gør ikke dette endnu

Indekser ikke »alle virksomhedens dokumenter« i én assistent.

Stol ikke på promptinstruktioner til at håndhæve tilladelser.

Log ikke fuldstændige hentede chunks fra følsomme korpora uden en tydelig politik for adgang og opbevaring.

Bland ikke HR-, juridiske, kunde- og offentlige dokumenter i samme korpus.

Lad ikke RAG-systemet svare uden for sine tilladte kilder blot for at være hjælpsomt.

Konklusion

RAG til virksomhedsviden er værdifuld, fordi den bringer kildebaserede svar ind i det daglige arbejde. Den er risikabel, fordi selv kildebaserede svar kan lække oplysninger.

Design tilladelsesgrænserne først. Filtrer før hentning. Opdel korpora efter målgruppe. Bevar kildemetadata. Afvis sikkert. Log med omtanke. Test med reelle tilladelsesprofiler. Hvis en bruger ikke har direkte adgang til kilden, må RAG-systemet ikke anvende kilden til at besvare brugerens spørgsmål.