RAG dozvole za web chat-botove: Sigurno upravljanje pristupom dokumentima

Web chat-bot može spajati odgovore sa stranica s čestim pitanjima (FAQ), dokumentacije o proizvodima i internih izvora znanja. To je korisno - sve dok ta ista baza znanja ne sadrži sadržaje koji nisu namijenjeni svakoj osobi. Tada o sigurnom odgovoru ne odlučuje samo kvaliteta jezičnog modela, već korak dohvaćanja (retrieval) prije toga: Koje dokumente ovaj konkretan upit uopće smije vidjeti?

RAG dozvole povezuju verificirane identitete, uloge ili grupe s metapodacima na dokumentima. Chat-bot prima samo već filtrirane izvore. Cilj je namjerno usko definiran: Ne bi model trebao na temelju prompta odlučivati je li nešto povjerljivo. Aplikacija ograničava dopušteni kontekst, dokumentira tu odluku i u slučaju nesigurnosti odabire sigurno alternativno rješenje (fallback).

Zašto pravila u promptu ne zamjenjuju kontrolu pristupa

Sustavska uputa poput „Ne odaj interne informacije“ ima smisla, ali nije sloj dozvola. Ako nedopušteni dokument već dospije u kontekst, odgovor ga može sažeti, neizravno otkriti ili rekonstruirati na dodatno pitanje. Također, naknadna provjera teksta dolazi prekasno i podložna je pogreškama. Sigurnost stoga počinje prije generiranja i, idealno, prije rangiranja pogodaka.

Azure AI Search opisuje Security Trimming kao uzorak filtriranja: Dokumenti nose vrijednosti identiteta ili grupa; upit sadrži samo nalogodavce (principals) osobe koja šalje upit. Amazon Bedrock slično ističe da filteri dohvaćanja koji uzimaju u obzir ACL ne zamjenjuju autentifikaciju. Vaša aplikacija mora najprije sama pouzdano provjeriti identitet i proslijediti samo verificirani kontekst.

Četiri gradivna bloka pouzdanog rješenja

1. Verifikacija identiteta i sesije na strani poslužitelja

Javni prozor za chat obično nema nikakva prava na dokumente. Smije pristupati samo javnim izvorima. Za korisnički portal ili dio za zaposlenike osoba se, s druge strane, identificira putem postojeće prijave. Očitajte ulogu, organizaciju i relevantne grupe na strani poslužitelja iz sesije ili potpisanog tokena. Nikada se nemojte oslanjati na polje koje preglednik slobodno šalje poput role=admin ili na chat poruku koja tvrdi da pripada nekoj grupi.

2. Održavanje metapodataka o dozvolama uz svaki izvor

Svakom segmentu (chunk) uz tekst, URL i datum ažuriranja potrebna je i razumljiva informacija o pristupu: npr. audience=public, ID korisnika (tenant ID), popis dopuštenih grupa ili klasifikacija. Ti metapodaci moraju dolaziti iz istog poslovnog izvora kao i dozvola za dokument. Zasebna tablica koja se održava samo povremeno stvara opasna odstupanja. Kod novih dokumenata i kod promjena prava grupa, sinkronizacija metapodataka stoga pripada u radni tijek objavljivanja ili indeksiranja (crawl workflow).

3. Filtriranje prije rangiranja

Upit konstruira filter iz verificiranog konteksta. Tek se nakon toga procjenjuju semantički ili hibridni pogoci. Tako povjerljivi priručnik ne može pobijediti kao posebno prikladan pogodak da bi se kasnije ponovno uklonio. Kod više korisnika (multi-tenancy), ID korisnika je obvezan filter, a ne samo signal za rangiranje. Za osobne ili posebno zaštićene podatke dodatno se preporučuje vlastito područje podataka umjesto zajedničke, samo logički filtrirane zbirke.

4. Bilježenje izvora i odluka u dnevnik (log)

Za podršku i analizu incidenata samo transkripti chata nisu dovoljni. Po upitu bi trebalo biti moguće pratiti koji su neosjetljivi atributi identiteta upotrijebljeni za izradu filtera, koja je klasa filtera vrijedila, koliko je pogodaka preostalo nakon filtera i koji su izvori stvarno dospjeli u prompt. Nemojte spremati nepotrebne pune sadržaje ili tokene. Događaj revizije (audit event) s minimalnom količinom podataka omogućuje pronalaženje pogrešaka, a da se nadzor ne pretvori u drugo curenje informacija.

Praktičan postupak za timove koji održavaju web stranice

1. Dodijelite svaki izvor znanja jasnoj ciljnoj skupini: javno, kupac, partner, interni tim ili konkretan korisnik.
2. Definirajte koje tvrdnje iz sesije (session claims) dokazuju tu ciljnu skupinu. Grupe iz sustava identiteta robusnije su od slobodno odabranih unosnih polja u obrascima.
3. Preuzmite te tvrdnje na strani poslužitelja u filter dohvaćanja i dopustite samo malu, poznatu količinu polja za filtriranje.
4. Pri svakom indeksiranju (crawl) provedite usklađivanje: novi, izmijenjeni i uklonjeni dokumenti trebaju i ažurirane metapodatke o dozvolama.
5. Dajte modelu samo filtrirane pogotke uz jasnu uputu da ne nagađa informacije koje nedostaju.
6. Ako nema pogodaka, ako su izvori kontradiktorni ili je dozvola nejasna, preusmjerite na siguran kanal za kontakt.

Ovaj postupak nadopunjuje strukturiranje opisano u našem članku o RAG segmentaciji (chunking): Dobri odlomci poboljšavaju pogotke, ali ne zamjenjuju kontrolu pristupa. Jednako tako, svježi izvori ostaju važni; zastarjelo stanje dozvola ujedno je problem kvalitete i sigurnosti.

Uobičajena pogreška: Filtriranje nakon dohvaćanja

Često pogrešno projektiranje glasi: Sustav dohvaća deset najboljih pogodaka, nakon toga provjerava njihove oznake i uklanja problematične dokumente. To na prvi pogled djeluje dovoljno, ali ne uspijeva zbog nuspojava. Nedopušteni pogodak može se već pojaviti u dnevnicima, predmemorijama (caches) ili izlazu za otklanjanje pogrešaka (debug). Osim toga, njegov rezultat (score) mijenja odabir ostalih pogodaka. Bolji je filter u samom zahtjevu za dohvaćanje (retrieval request) koji kao kandidate dopušta samo dokumente s pravom pristupa.

Druga pogreška je općenito povjerenje u ACL funkciju nekog pružatelja usluga. Dokumentacija proizvođača može jasno navoditi da usluga uzima u obzir ACL-ove pri dohvaćanju, ali ne provjerava sama autentičnost proslijeđenog korisničkog konteksta. Zato precizno provjerite: Tko autentificira osobu? Odakle dolaze grupe? Kada se prava sinkroniziraju u sustav za dohvaćanje? Što se događa ako nedostaju metapodaci?

Fail closed: Što bi se trebalo dogoditi u slučaju nesigurnosti

U slučaju nedostajuće tvrdnje (claim), nesinkroniziranog izvora ili pogreške pri dohvaćanju, chat-bot ne bi trebao pokušavati širu pretragu. Upotrijebite neutralan odgovor: Zatraženi sadržaj nije dostupan u trenutnom kontekstu pristupa; ljudska osoba za kontakt može provjeriti pristup. To nije slabost konverzacijskog korisničkog iskustva (UX), već iskrena granica. Članak o preusmjeravanju na čovjeka (Human Handoff) pokazuje kako se takva predaja može oblikovati konkretno i bez slijepe ulice.

Za javne sadržaje vrijedi ista ideja u manjem opsegu: Ako stanje izvora nije dovoljno, bot bi trebao navesti nesigurnost, ponuditi verificirane poveznice ili navesti način kontakta - umjesto izmišljanja uvjerljivih detalja. To smanjuje halucinacije i sprječava da navodno koristan odgovor pozove na pogrešno odobrenje.

Testni slučajevi koje treba provesti prije uvođenja

Testiranje dozvola nije jednokratna provjera administratora. Stvorite mali skup zlatnih standarda (Golden Set) s identičnim pitanjima za više uloga: gost, registrirani kupac, ovlašteni partner, blokirani korisnik i administrator. Za svaku kombinaciju definirajte očekivane izvore, a ne samo očekivani tekst odgovora. Osim toga, testirajte promjene grupa, istekle sesije, izbrisane dokumente, metapodatke ACL-a koji nedostaju i ispad usluge dohvaćanja.

U rezultatima kontrolirajte najmanje četiri stvari: Nijedan nedopušteni URL ili ID dokumenta ne dospijeva u kontekst; dopušteni izvori ostaju dostupni; odgovor ne spominje sadržaje iz filtriranih dokumenata; i sigurna alternativa ostaje razumljiva. Dodajte ove provjere svojim testovima kvalitete odgovora kako bi se sigurnost i stručna kvaliteta mjerile zajedno.

Pragmatična provedba zaštite podataka i transparentnosti

Podaci o dozvolama i sami su vrijedni zaštite. Koristite što stabilnije tehničke ID-eve umjesto imena u čistom tekstu u metapodacima za dohvaćanje. Ograničite dnevnike revizije na svrhu, vremenski period i potrebne atribute. Jasno informirajte korisnike kada chat-bot pristupa prijavljenom području i ponudite ljudski put za pitanja o pristupu. Ovaj članak ne zamjenjuje individualno pravno savjetovanje; konkretni rokovi čuvanja i pravne osnove ovise o kontekstu primjene.

Tehnički se isplati jasna odgovornost: Vlasnici sadržaja održavaju ciljne skupine, tim za identitet odgovoran je za tvrdnje i provjeru sesije, a tim za proizvod održava filtere i alternative testiranima. Tako baza znanja ne postaje nekontrolirani skup podataka, već izvor čiji doseg ostaje razumljiv.

Kontrolni popis prije puštanja u rad

• Je li svaki nejavni izvor dodijeljen ulozi, grupi ili ID-u korisnika?
• Potječe li kontekst upita iz identiteta verificiranog na strani poslužitelja?
• Djeluje li filter prije dohvaćanja i rangiranja?
• Sinkroniziraju li se promjene prava i indeksiranja zajedno?
• Postoje li testovi regresije temeljeni na ulogama s očekivanim izvorima?
• Vodi li svako nepoznato ili pogrešno stanje do sigurnog preusmjeravanja?
• Jesu li dnevnici štedljivi s podacima i dovoljni za analizu pogrešaka?

Zaključak

Dobar web chat-bot ne odgovara na svako pitanje za svaku osobu. Prikazuje samo izvore koji odgovaraju verificiranom kontekstu pristupa i u slučaju nesigurnosti namjerno ostaje suzdržan. Započnite s malom matricom izvora, filterom na strani poslužitelja i nekoliko jasnih testnih uloga. Nakon toga možete postupno proširivati metapodatke o dozvolama, revizije i sinkronizaciju - bez prenošenja sigurnosti na formulacije u promptu.

Izvori

• 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