RAG oprávnění pro webové chatboty: Jak bezpečně řídit přístup k dokumentům

Webový chatbot dokáže propojit odpovědi ze stránek FAQ, produktové dokumentace i interních znalostních zdrojů. To je velmi užitečné – dokud stejná znalostní báze neobsahuje obsah, který není určen pro každého. O bezpečné odpovědi pak nerozhoduje pouhá kvalita jazykového modelu, ale předcházející krok načítání (retrieval): Které dokumenty smí tento konkrétní dotaz vůbec vidět?

RAG oprávnění propojují ověřené identity, role nebo skupiny s metadaty uloženými u dokumentů. Chatbot tak získává pouze předem vyfiltrované zdroje. Cíl je záměrně úzký: Model nemá na základě promptu rozhodovat o tom, zda je něco důvěrné. Aplikace omezí povolený kontext, toto rozhodnutí zaznamená a v případě nejistoty zvolí bezpečný záložní postup (fallback).

Proč pravidla v promptu nenahradí řízení přístupu

Systémová instrukce typu „Neposkytuj interní informace“ má svůj smysl, ale nepředstavuje přístupovou vrstvu. Pokud se nepovolený dokument dostane do kontextu, odpověď jej může shrnout, nepřímo prozradit nebo na vyžádání zrekonstruovat. Také následná kontrola výstupního textu přichází příliš pozdě a je náchylná k chybám. Bezpečnost proto začíná ještě před generováním a ideálně před řazením výsledků podle priority.

Azure AI Search popisuje Security Trimming jako filtrovací vzor: Dokumenty obsahují hodnoty identity nebo skupin; dotaz obsahuje pouze principály žádající osoby. Amazon Bedrock podobně upozorňuje, že retrieval filtry s podporou ACL nenahrazují autentizaci. Vaše aplikace musí nejprve sama spolehlivě ověřit identitu a předat pouze ověřený kontext.

Čtyři stavební kameny spolehlivého řešení

1. Ověření identity a relace na straně serveru

Veřejné chatovací okno obvykle nemá žádná práva k dokumentům. Smí přistupovat pouze k veřejným zdrojům. V klientském portálu nebo zaměstnanecké sekci se naopak osoba identifikuje prostřednictvím stávajícího přihlášení. Roli, organizaci a relevantní skupiny načtěte na straně serveru z relace (session) nebo podepsaného tokenu. Nikdy se nespoléhejte na pole volně odeslané prohlížečem, jako je role=admin, ani na chatovací zprávu tvrdící příslušnost k nějaké skupině.

2. Správa metadat oprávnění u každého zdroje

Každý úsek textu (chunk) vyžaduje vedle textu, URL a data aktualizace také dohledatelnou informaci o přístupu: například audience=public, ID tenanta, seznam povolených skupin nebo klasifikaci. Tato metadata musí pocházet ze stejného věcného zdroje jako oprávnění k dokumentům. Samostatná tabulka, která se udržuje jen příležitostně, vytváří nebezpečnou odchylku. Při vytváření nových dokumentů a změnách skupinových práv proto synchronizace metadat patří přímo do publikačního nebo crawl postupu.

3. Filtrování před řazením výsledků (ranking)

Dotaz vytvoří filtr z ověřeného kontextu. Teprve poté se vyhodnocují sémantické nebo hybridní shody. Důvěrná příručka se tak nemůže prosadit jako obzvláště vhodná shoda, aby byla následně opět odstraněna. Při existenci více tenantů je ID tenanta povinným filtrem, nikoli pouze signálem pro ranking. Pro osobní nebo zvláště chráněná data se navíc doporučuje vyhrazená datová oblast namísto společné, pouze logicky filtrované kolekce.

4. Protokolování zdrojů a rozhodnutí

Pro zákaznickou podporu a analýzu incidentů pouhé přepisy chatů nestačí. U každého dotazu by mělo být dohledatelné, které necitlivé atributy identity byly použity k vytvoření filtru, jaká třída filtru platila, kolik shod po filtraci zůstalo a které zdroje se skutečně dostaly do promptu. Neukládejte zbytečný úplný obsah ani tokeny. Datově úsporná auditní událost umožní dohledat chyby, aniž by se z monitoringu stal druhý únik informací.

Praktický postup pro webové týmy

1. Přiřaďte každý znalostní zdroj jasné cílové skupině: veřejný, zákazník, partner, interní tým nebo konkrétní tenant.
2. Definujte, které session claims tuto cílovou skupinu prokazují. Skupiny z identitního systému jsou robustnější než volně zadávané formulářové vstupy.
3. Přeneste tyto claims na straně serveru do retrieval filtru a povolte pouze malou, známou množinu filtrovacích polí.
4. Při každém crawl procesu proveďte porovnání: nové, změněné a odstraněné dokumenty vyžadují také aktualizovaná metadata oprávnění.
5. Předávejte modelu pouze vyfiltrované shody spolu s jasným pokynem, aby si chybějící informace nevymýšlel.
6. Pokud nenaleznete žádnou shodu, narazíte na rozporuplné zdroje nebo nejasná oprávnění, přesměrujte uživatele na bezpečný kontakt.

Tento postup doplňuje strukturování popsané v našem článku o RAG chunkingu: Kvalitní úseky zlepšují shody, ale nenahrazují řízení přístupu. Stejně tak zůstávají důležité čerstvé zdroje; zastaralý stav oprávnění představuje problém pro kvalitu i bezpečnost zároveň.

Chybový vzor: Filtrování až po načtení (retrieval)

Častou chybou v návrhu bývá: Systém načte deset nejlepších výsledků, následně zkontroluje jejich štítky a problematické dokumenty odstraní. To na první pohled vypadá dostatečně, ale selhává na vedlejších účincích. Nepovolený výsledek se již může objevit v logách, mezipaměti (cache) nebo v ladicím výstupu. Jeho skóre navíc ovlivňuje výběr ostatních výsledků. Lepší je filtr přímo v retrieval požadavku, který jako kandidáty připustí pouze oprávněné dokumenty.

Druhou častou chybou je paušální důvěra v funkci ACL daného poskytovatele. Dokumentace výrobce může jasně uvádět, že služba zohledňuje ACL při načítání, ale sama neověřuje pravost předaného uživatelského kontextu. Zkontrolujte proto přesně: Kdo osobu autentizuje? Odkud pocházejí skupiny? Kdy se práva synchronizují do retrieval systému? Co se stane, když metadata chybí?

Fail closed: Co se má stát při nejistotě

Při chybějícím claimu, nesynchronizovaném zdroji nebo chybě načítání by se chatbot neměl pokoušet o širší vyhledávání. Použijte neutrální odpověď: Požadovaný obsah není v aktuálním přístupovém kontextu k dispozici; lidský kontakt může přístup prověřit. Jedná se o poctivou hranici, nikoli o slabinu konverzační UX. Článek o Human Handoffu ukazuje, jak takové předání navrhnout konkrétně a bez slepých uliček.

Pro veřejný obsah platí stejná myšlenka v menším měřítku: Pokud dostupné zdroje nestačí, bot by měl přiznat nejistotu, nabídnout ověřené odkazy nebo uvést kontaktní cestu – namísto vymýšlení uvěřitelných detailů. To snižuje halucinace a zabraňuje tomu, aby domněle užitečná odpověď naváděla k nesprávnému schválení.

Testovací případy, které patří před spuštění (rollout)

Testování oprávnění není jednorázová kontrola administrátorem. Vytvořte malou srovnávací sadu (Golden Set) s identickými otázkami pro více rolí: host, registrovaný zákazník, oprávněný partner, zablokovaný uživatel a administrátor. Pro každou kombinaci definujte očekávané zdroje, nejen očekávaný text odpovědi. Testujte také změny skupin, vypršené relace, smazané dokumenty, chybějící ACL metadata a výpadek retrieval služby.

V výsledcích kontrolujte minimálně čtyři věci: Do kontextu se nedostane žádná nepovolená URL nebo ID dokumentu; povolené zdroje zůstávají dostupné; odpověď neuvádí žádný obsah z odfiltrovaných dokumentů; a záložní postup (fallback) zůstává srozumitelný. Doplňte tyto prověrky do svých testů kvality odpovědí, aby se bezpečnost a odborná kvalita měřily společně.

Pragmatická realizace ochrany osobních údajů a transparentnosti

Údaje o oprávněních samy o sobě vyžadují ochranu. V metadatech pro retrieval používejte pokud možno stabilní technická ID namísto čitelných jmen. Omezte auditní logy na účel, časové období a nezbytné atributy. Srozumitelně informujte uživatele, pokud chatbot přistupuje do přihlášené sekce, a nabídněte lidskou cestu pro dotazy k přístupu. Tento článek nenahrazuje individuální právní poradenství; konkrétní lhůty uchovávání a právní základy závisí na kontextu nasazení.

Z technického hlediska se vyplatí jasná odpovědnost: Vlastníci obsahu (Content Owners) spravují cílové skupiny, tým identity zodpovídá za claims a kontrolu relací, produktový tým udržuje otestované filtry a fallbacks. Znalostní báze se tak nestane nekontrolovaným datovým bazénem, ale zdrojem s jasně dohledatelným dosahům.

Kontrolní seznam před spuštěním do ostrého provozu

• Je každý neveřejný zdroj přiřazen k roli, skupině nebo ID tenanta?
• Pochází kontext dotazu z identity ověřené na straně serveru?
• Funguje filtr ještě před načtením (retrieval) a řazením (ranking)?
• Synchronizují se změny práv a crawl procesy společně?
• Existují regresní testy založené na rolích s očekávanými zdroji?
• Vede každý neznámý nebo chybový stav k bezpečnému předání lidskému operátorovi (handoff)?
• Jsou logy datově úsporné a zároveň dostatečné pro analýzu chyb?

Závěr

Dobrý webový chatbot neodpovídá na každou otázku každému uživateli. Zobrazuje pouze zdroje, které odpovídají ověřenému přístupovému kontextu, a při nejistotě zůstává záměrně zdrženlivý. Začněte s malou maticí zdrojů, filtrem na straně serveru a několika jasnými testovacími rolemi. Poté můžete postupně rozšiřovat metadata oprávnění, audity a synchronizaci – aniž byste bezpečnost přenechávali formulacím v promptu.

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