RAG práva pre webové chatboty: Ako bezpečne riadiť prístup k dokumentom

Webový chatbot dokáže spájať odpovede zo stránok FAQ, produktovej dokumentácie a interných zdrojov znalostí. To je užitočné – až kým tá istá znalostná báza neobsahuje obsah, ktorý nie je určený pre každého. Vtedy o bezpečnej odpovedi nerozhoduje len kvalita jazykového modelu, ale krok vyhľadávania (retrieval) pred ním: Ktoré dokumenty smie táto konkrétna požiadavka vôbec vidieť?

RAG práva spájajú overené identity, roly alebo skupiny s metadátami na dokumentoch. Chatbot tak dostane iba vopred vyfiltrované zdroje. Cieľ je zámerne úzky: O tom, či je niečo dôverné, nemá rozhodovať model na základe promptu. Aplikácia obmedzí povolený kontext, toto rozhodnutie zdokumentuje a v prípade neistoty zvolí bezpečné záložné riešenie (fallback).

Prečo pravidlá v prompte nenahrádzajú riadenie prístupu

Systémový pokyn typu „Neuvádzaj žiadne interné informácie“ je síce užitočný, ale nepredstavuje bezpečnostnú vrstvu oprávnení. Ak sa nepovolený dokument už dostane do kontextu, odpoveď ho môže zhrnúť, nepriamo prezradiť alebo pri doplňujúcej otázke rekonštruovať. Ani dodatočná kontrola textu neprichádza včas a je náchylná na chyby. Bezpečnosť sa preto začína pred generovaním a ideálne ešte pred určovaním poradia výsledkov.

Azure AI Search opisuje Security Trimming ako vzor filtrovania: Dokumenty obsahujú hodnoty identity alebo skupiny; požiadavka obsahuje iba identitné údaje (principals) dopytujúcej sa osoby. Amazon Bedrock podobne upozorňuje, že filtre vyhľadávania rešpektujúce ACL nenahrádzajú autentifikáciu. Vaša aplikácia musí najprv sama spoľahlivo overiť identitu a odovzdať iba overený kontext.

Štyri stavebné kamene robustného riešenia

1. Overenie identity a relácie (session) na strane servera

Verejné okno chatu zvyčajne nemá žiadne prístupové práva k dokumentom. Smie pristupovať iba k verejným zdrojom. Pre zákaznícky portál alebo zamestnaneckú zónu sa však osoba identifikuje prostredníctvom existujúceho prihlásenia. Rolu, organizáciu a relevantné skupiny načítajte na strane servera z relácie alebo podpísaného tokenu. Nikdy sa nespoliehajte na pole voľne odoslané z prehliadača, ako napríklad role=admin, ani na správu v chate, ktorá tvrdí určitú príslušnosť.

2. Spravovanie metadát o oprávneniach pri každom zdroji

Každý textový blok (chunk) potrebuje okrem textu, URL a dátumu aktualizácie aj sledovateľnú informáciu o prístupe: napríklad audience=public, ID nájomcu (tenant ID), zoznam povolených skupín alebo klasifikáciu. Tieto metadáta musia pochádzať z rovnakého odborného zdroja ako oprávnenia k dokumentom. Samostatný tabuľkový archív, ktorý sa udržiava len príležitostne, vytvára nebezpečné odchýlky (drift). Pri nových dokumentoch a pri zmenách skupinových práv preto synchronizácia metadát patrí do publikačného alebo crawlingového procesu.

3. Filtrovanie pred zoradením (rankingom)

Dopyt vytvorí filter z overeného kontextu. Až potom sa vyhodnocujú sémantické alebo hybridné výsledky. Dôverná príručka tak nemôže vyhrať ako obzvlášť vhodný výsledok len preto, aby bola neskôr opäť odstránená. Pri viacerých nájomcoch je ID nájomcu povinným filtrom, nie iba signálom pre ranking. Pre osobné alebo obzvlášť chránené údaje sa navyše odporúča vlastná dátová oblasť namiesto spoločnej, len logicky filtrovanej kolekcie.

4. Protokolovanie zdrojov a rozhodnutí

Pre zákaznícku podporu a analýzu incidentov samotné prepisy chatov nestačia. Pri každej požiadavke by malo byť možné spätne dohľadať, ktoré nesenzitívne atribúty identity boli použité na vytvorenie filtra, aká trieda filtra platila, koľko výsledkov po filtrovaní zostalo a ktoré zdroje sa skutočne dostali do promptu. Neukladajte nepotrebný úplný obsah ani tokeny. Auditovacia udalosť úsporná na dáta umožní odhaliť chyby bez toho, aby sa z monitorovania stala druhá medzera v úniku znalostí.

Praktický postup pre webové tímy

1. Priraďte každý znalostný zdroj jasnej cieľovej skupine: verejnosť, zákazník, partner, interný tím alebo konkrétny nájomca.
2. Definujte, ktoré nároky z relácie (session claims) túto cieľovú skupinu preukazujú. Skupiny zo systému identity sú robustnejšie ako voľne voliteľné vstupy z formulára.
3. Prevezmite tieto claims na strane servera do filtra vyhľadávania a povoľte len malú, známu množinu polí filtra.
4. Pri každom crawlovaní vykonajte porovnanie: nové, zmenené a odstránené dokumenty potrebujú aj aktualizované metadáta o oprávneniach.
5. Modelu poskytnite iba vyfiltrované výsledky spolu s jasným pokynom, aby si chýbajúce informácie nevymýšľal.
6. Ak sa nenájde žiadny výsledok, zdroje si odporujú alebo je oprávnenie nejasné, presmerujte používateľa na bezpečný kontaktný kanál.

Tento postup dopĺňa štruktúrovanie opísané v našom článku o RAG chunkingu: Dobré úseky zlepšujú výsledky, ale nenahrádzajú prístupovú kontrolu. Rovnako dôležité zostávajú čerstvé zdroje; zastaraný stav oprávnení je zároveň problémom kvality aj bezpečnosti.

Častá chyba: Filtrovanie až po vyhľadaní (retrievale)

Častým chybným návrhom je: Systém načíta desať najlepších výsledkov, potom skontroluje ich označenia a problematické dokumenty odstráni. Na prvý pohľad sa to zdá dostatočné, ale zlyháva na vedľajších účinkoch. Nepovolený výsledok sa už môže objaviť v logoch, vyrovnávacej pamäti (cache) alebo v debugovacom výstupe. Okrem toho jeho skóre mení výber zvyšných výsledkov. Lepší je filter priamo v požiadavke na vyhľadávanie, ktorý ako kandidátov povolí len oprávnené dokumenty.

Druhou častou chybou je paušálna dôvera vo funkciu ACL určitého poskytovateľa. Dokumentácia výrobcu môže jasne uvádzať, že služba zohľadňuje ACL pri načítaní, ale sama neoveruje pravosť odovzdaného používateľského kontextu. Preto presne skontrolujte: Kto autentifikuje osobu? Odkiaľ pochádzajú skupiny? Kedy sa práva synchronizujú do systému vyhľadávania? Čo sa stane, ak metadáta chýbajú?

Fail-closed: Čo sa má stať pri neistote

Pri chýbajúcom claim-e, nesynchronizovanom zdroji alebo chybe vyhľadávania by sa chatbot nemal pokúšať o širšie vyhľadávanie. Použite neutrálnu odpoveď: Požadovaný obsah nie je v aktuálnom prístupovom kontexte k dispozícii; ľudský kontakt môže prístup preveriť. Toto nie je slabosť konverzačného UX, ale poctivá hranica. Článok o Human Handoff ukazuje, ako sa dá takéto odovzdanie navrhnúť konkrétne a bez slepých uličiek.

Pre verejný obsah platí rovnaká myšlienka v menšej mierke: Ak dostupné zdroje nestačia, bot by mal priznať neistotu, ponúknuť overené odkazy alebo uviesť kontaktnú možnosť – namiesto vymýšľania uvěřiteľných detailov. To znižuje halucinácie a zabraňuje tomu, aby údajne užitočná odpoveď navádzala na nesprávne schválenie.

Testovacie prípady, ktoré patria pred nasadenie do prevádzky

Testovanie oprávnení nie je jednorazová kontrola administrátora. Vytvorte si malú sadu testov (Golden Set) s rovnakými otázkami pre viacero rolí: hosť, registrovaný zákazník, oprávnený partner, zablokovaný používateľ a administrátor. Pre každú kombináciu definujte očakávané zdroje, nie len očakávaný text odpovede. Testujte aj zmeny skupín, expirované relácie, zmazané dokumenty, chýbajúce ACL metadáta a výpadok vyhľadávacej služby.

V výsledkoch kontrolujte minimálne štyri veci: Žiadna nepovolená URL ani ID dokumentu sa nedostane do kontextu; povolené zdroje zostávajú dostupné; odpoveď neuvádza žiadny obsah z vyfiltrovaných dokumentov; a záložná odpoveď zostáva zrozumiteľná. Dopĺňajte tieto kontroly k svojim testom kvality odpovedí, aby sa bezpečnosť a odborná kvalita merali spoločne.

Pragmatická realizácia ochrany osobných údajov a transparentnosti

Údaje o oprávneniach sú samy o sebe citlivé. V metadátach vyhľadávania používajte podľa možnosti stabilné technické ID namiesto otvorených názvov. Obmedzte auditovacie logy na účel, časové obdobie a nevyhnutné atribúty. Zrozumiteľne informujte používateľov, keď chatbot pristupuje k prihlásenej zóne, a ponúknite ľudskú cestu pre otázky ohľadom prístupu. Tento článok nenahrádza individuálne právne poradenstvo; konkrétne doby uchovávania a právne základy závisia od kontextu nasadenia.

Z technického hľadiska sa vyplatí jasná zodpovednosť: Vlastníci obsahu spravujú cieľové skupiny, tím pre identitu zodpovedá za claims a kontrolu relácií, produktový tím udržiava otestované filtre a záložné riešenia. Tak sa znalostná báza nestane nekontrolovaným dátovým fondom, ale zdrojom, ktorého dosah zostáva transparentný a sledovateľný.

Kontrolný zoznam pred spustením

• Je každý neverejný zdroj priradený k role, skupine alebo ID nájomcu?
• Pochádza kontext dopytu z overenej identity na strane servera?
• Aplikuje sa filter pred vyhľadávaním a rankingom?
• Synchronizujú sa zmeny práv a crawling spoločne?
• Existujú regresné testy založené na rolách s očakávanými zdrojmi?
• Vedie každý neznámy alebo chybový stav k bezpečnému odovzdaniu človeku (handoff)?
• Sú logy úsporné na dáta a dostatočné pre analýzu chýb?

Záver

Dobrý webový chatbot neodpovedá na každú otázku pre každú osobu. Zobrazuje iba zdroje, ktoré zodpovedajú overenému prístupovému kontextu, a pri neistote zostáva zámerne zdržanlivý. Začnite s malou maticou zdrojov, filtrom na strane servera a niekoľkými jasnými testovacími rolami. Potom môžete postupne rozširovať metadáta oprávnení, audity a synchronizáciu – bez toho, aby ste bezpečnosť prenechávali formuláciám v prompte.

Zdroje

• 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