RAG-rettigheder til hjemmeside-chatbots: Kontroller dokumentadgang sikkert

En hjemmeside-chatbot kan samle svar fra FAQ-sider, dokumentation og interne videnkilder. Det er nyttigt – indtil den samme vidensbase indeholder indhold, der ikke er beregnet til alle. Så er det ikke kun sprogmodellens kvalitet, der afgør et sikkert svar, men retrieval-trinnet forinden: Hvilke dokumenter må denne konkrete forespørgsel overhovedet se?

RAG-rettigheder forbinder verificerede identiteter, roller eller grupper med metadata på dokumenter. Chatbotten modtager kun kilder, der allerede er filtreret. Målet er bevidst snævert: En model skal ikke ud fra sin prompt vurdere, om noget er fortroligt. Applikationen begrænser den tilladte kontekst, dokumenterer denne beslutning og vælger en sikker fallback i tilfælde af usikkerhed.

Hvorfor prompt-regler ikke erstatter adgangskontrol

En systeminstruktion som "Giv ikke interne oplysninger" er fornuftig, men udgør ikke et rettighedslag. Hvis et uautoriseret dokument allerede er nået ind i konteksten, kan svaret opsummere det, indirekte afsløre det eller rekonstruere det ved opfølgende spørgsmål. En efterfølgende tekstkontrol er ligeledes for sent og fejlbehæftet. Sikkerhed starter derfor før genereringen og ideelt set før rangeringen af søgeresultaterne.

Azure AI Search beskriver Security Trimming som et filtermønster: Dokumenter indeholder identitets- eller gruppeværdier; forespørgslen indeholder kun den anmodende persons principals. Amazon Bedrock påpeger på lignende vis, at ACL-bevidste retrieval-filtre ikke erstatter autentificering. Din applikation skal først selv verificere identiteten pålideligt og kun videregive en verificeret kontekst.

De fire byggestene i en robust løsning

1. Verificer identitet og session på serversiden

Et offentligt chatvindue har normalt ingen dokumentrettigheder. Det må kun tilgå offentlige kilder. For en kundeportal eller et medarbejderområde identificeres personen derimod via det eksisterende login. Udlæs rolle, organisation og relevante grupper på serversiden fra sessionen eller et signeret token. Stol aldrig på et felt, der sendes frit fra browseren som role=admin, eller på en chatbesked, der påstår et tilhørsforhold.

2. Vedligehold rettighedsmetadata ved hver kilde

Hver chunk skal ud over tekst, URL og opdateringsdato indeholde gennemskuelige adgangsoplysninger: f.eks. audience=public, et tenant-ID, en liste over tilladte grupper eller en klassifikation. Disse metadata skal stamme fra den samme faglige kilde som dokumentrettigheden. Et separat regneark, der kun vedligeholdes lejlighedsvis, skaber farlig drift. Ved nye dokumenter og ændringer i grupperettigheder hører metadata-synkroniseringen derfor hjemme i publishing- eller crawl-workflowet.

3. Filtrer før rangering

Forespørgslen konstruerer et filter ud fra den verificerede kontekst. Først derefter vurderes semantiske eller hybride match. På den måde kan en fortrolig manual ikke vinde som et særligt relevant match blot for at blive fjernet bagefter. Ved flere tenants er tenant-ID et obligatorisk filter, ikke blot et rangeringssignal. Til personhenførbare eller særligt beskyttede data anbefales desuden et selvstændigt datadomæne frem for en fælles, kun logisk filtreret samling.

4. Logfør kilder og beslutninger

Til support og hændelsesanalyse er chat-udskrifter alene ikke nok. For hver forespørgsel bør det være muligt at spore, hvilke ikke-følsomme identitetsattributter der blev brugt til filterdannelsen, hvilken filterklasse der var gældende, hvor mange match der var tilbage efter filteret, og hvilke kilder der reelt nåede med i prompten. Gem ikke unødige fulde tekster eller tokens. En dataminimeret audit-hændelse gør det muligt at opspore fejl uden at gøre overvågningen til endnu et datalæk.

En praktisk proces for hjemmeside-teams

1. Knyt hver videnskilde til en klar målgruppe: offentlig, kunde, partner, internt team eller en konkret tenant.
2. Definer, hvilke session-claims der beviser denne målgruppe. Grupper fra identitetssystemet er mere robuste end valgfrie formularfelter.
3. Overfør disse claims på serversiden til retrieval-filteret, og tillad kun en lille, kendt mængde af filterfelter.
4. Udfør en afstemning ved hvert crawl: Nye, ændrede og fjernede dokumenter har også brug for opdaterede rettighedsmetadata.
5. Giv kun modellen de filtrerede match samt en klar instruktion om ikke at gætte manglende oplysninger.
6. Omdiriger til en sikker kontaktkanal i tilfælde af manglende match, modstridende kilder eller uklare rettigheder.

Denne proces supplerer den strukturering, der er beskrevet i vores artikel om RAG-chunking: Gode afsnit forbedrer søgeresultater, men erstatter ikke adgangskontrol. Ligeledes forbliver opdaterede kilder vigtige; en forældet rettighedsstatus er både et kvalitets- og et sikkerhedsproblem.

Fejlmønster: Filtrering efter retrieval

En hyppig fejlkonstruktion er: Systemet henter de ti bedste match, kontrollerer derefter deres labels og fjerner uønskede dokumenter. Det virker umiddelbart tilstrækkeligt, men fejler på grund af bivirkninger. Det ulovlige match kan allerede optræde i logfiler, caches eller en debug-visning. Desuden ændrer dets score udvælgelsen af de øvrige match. Det er bedre med et filter i selve retrieval-anmodningen, der kun tillader berettigede dokumenter som kandidater.

Et andet fejlmønster er en blind tillid til en udbyders ACL-funktion. Producentdokumentation kan klart anføre, at en tjeneste tager højde for ACL'er ved søgning, men ikke selv kontrollerer ægtheden af den overførte brugerkontekst. Tjek derfor præcist: Hvem autentificerer personen? Hvorfra stammer grupperne? Hvornår synkroniseres rettigheder til retrieval-systemet? Hvad sker der, hvis metadata mangler?

Fail closed: Hvad der skal ske ved usikkerhed

Ved et manglende claim, en usynkroniseret kilde eller en retrieval-fejl bør chatbotten ikke forsøge en bredere søgning. Brug et neutralt svar: Det forespurgte indhold er ikke tilgængeligt i den aktuelle adgangskontekst; en menneskelig kontaktperson kan kontrollere adgangen. Dette er ikke en svaghed ved Conversational UX, men en ærlig grænse. Artiklen om Human Handoff viser, hvordan en sådan overdragelse kan udformes konkret og uden blindgyder.

For offentligt indhold gælder den samme idé i mindre skala: Hvis kildegrundlaget ikke rækker, bør botten oplyse om usikkerheden, tilbyde verificerede links eller angive en kontaktmulighed – i stedet for at opfinde plausible detaljer. Dette reducerer hallucinationer og forhindrer, at et tilsyneladende nyttigt svar opfordrer til en forkert godkendelse.

Testcases der skal køre før udrulning

En rettighedstest er ikke blot et engangs-tjek for administratorer. Opret et lille Golden Set med identiske spørgsmål til flere roller: gæst, registreret kunde, berettiget partner, spærret bruger og administrator. Definer de forventede kilder for hver kombination, ikke kun den forventede svartekst. Test desuden skift af grupper, udløbne sessioner, slettede dokumenter, manglende ACL-metadata og nedbrud i retrieval-tjenesten.

Kontroller mindst fire ting i resultaterne: Ingen ulovlig URL eller dokument-ID når ind i konteksten; tilladte kilder forbliver tilgængelige; svaret nævner intet indhold fra filtrerede dokumenter; og fallback'en forbliver forståelig. Tilføj disse kontroller til dine svarkvalitetstests, så sikkerhed og faglig kvalitet måles sammen.

Udfør databeskyttelse og gennemsigtighed pragmatisk

Rettighedsdata er i sig selv beskyttelsesværdige. Brug så vidt muligt stabile tekniske ID'er i stedet for navne i klartekst i retrieval-metadata. Begræns audit-logs til formål, tidsrum og nødvendige attributter. Informer brugerne letforståeligt, når en chatbot tilgår et logget ind-område, og tilbyd en menneskelig vej til adgangsspørgsmål. Denne artikel erstatter ikke individuel juridisk rådgivning; konkrete opbevaringsperioder og retsgrundlag afhænger af brugskonteksten.

Teknisk set kan det betale sig med en klar ansvarsfordeling: Indholdsejere vedligeholder målgrupper, identity-teamet er ansvarligt for claims og session-kontrol, og produktteamet holder filtre og fallbacks testet. På den måde bliver vidensbasen ikke til en ukontrolleret datapool, men til en kilde, hvis rækkevidde forbliver gennemskuelig.

Tjekliste før idriftsættelse

• Er enhver ikke-offentlig kilde knyttet til en rolle, gruppe eller tenant-ID?
• Stammer forespørgselskonteksten fra en identitet, der er verificeret på serversiden?
• Træder filteret i kraft før retrieval og rangering?
• Synkroniseres rettighedsændringer og crawls sammen?
• Findes der rollebaserede regressionstests med forventede kilder?
• Fører enhver ukendt eller fejlbehæftet tilstand til en sikker handoff?
• Er logfilerne dataminimerede og tilstrækkelige til fejlanalyse?

Konklusion

En god hjemmeside-chatbot besvarer ikke ethvert spørgsmål for enhver person. Den viser kun kilder, der passer til den verificerede adgangskontekst, og tøver bevidst ved usikkerhed. Start med en lille kildematrix, et server-side filter og få klare testroller. Derefter kan du gradvist udbygge rettighedsmetadata, audits og synkronisering – uden at uddelegere sikkerheden til prompt-formuleringer.

Kilder

• Microsoft Learn: Security Filter Pattern in Azure AI Search
• Microsoft Learn: Document-level access control in Azure AI Search
• Amazon Bedrock: ACL awareness enablement
• Amazon Bedrock: Document-level access controls