AWS overuje oprávnenia pre podnikový RAG priamo pri každej požiadavke

Podnikový asistent môže odpovedať vecne správne a napriek tomu spôsobiť bezpečnostný incident. Stačí, aby do odpovede vložil informáciu z dokumentu, ku ktorému používateľ medzičasom stratil prístup. AWS preto v službách Amazon Quick a Amazon Bedrock Knowledge Bases zavádza dvojstupňové presadzovanie zoznamov prístupových práv, teda ACL. Systém najprv zúži výsledky pomocou oprávnení uložených vo vyhľadávacom indexe a následne preverí vybrané dokumenty priamo v autoritatívnom zdroji. Až úryvky, ktoré prejdú oboma kontrolami, sa môžu dostať do kontextu jazykového modelu.

Zmena rieši slabé miesto bežnej architektúry retrieval-augmented generation, skrátene RAG. Pri indexovaní firemných dokumentov sa často kopíruje nielen obsah, ale aj vtedajší stav oprávnení. Synchronizácia však prebieha v intervaloch. Ak administrátor používateľovi odoberie členstvo v skupine alebo prístup k priečinku, vektorový index môže ešte určitý čas pracovať so starým stavom. Nejde pritom iba o otvorenie súboru: model dokáže citlivý úryvok zhrnúť, skombinovať s ďalšími údajmi a vložiť do zdanlivo neškodnej odpovede.

Dve kontroly namiesto jednej kópie oprávnení

V prvej fáze vykoná Amazon Quick s pripojenou znalostnou databázou sémantické vyhľadávanie a aplikuje ACL uložené v indexe. Ide o rýchly predbežný filter, ktorý z veľkého korpusu vyberie malú množinu relevantných dokumentov. AWS vysvetľuje, že overovať cez externé API každý dokument v celom indexe by bolo pri väčšom nasadení príliš nákladné. Indexovaná kópia oprávnení teda nezaniká; zostáva výkonnostnou vrstvou, nie konečným rozhodovacím miestom.

Druhá fáza sa odohrá tesne pred zostavením kontextu pre model. Pri príklade s Google Drive služba zavolá rozhranie zdrojového systému a preverí aktuálne oprávnenia ku kandidátskym dokumentom. Použije poverenia servisného účtu nastavené správcom a používateľsky špecifický prístup. Neoprávnené dokumenty vyradí a model dostane iba povolené pasáže. Dôležitý je práve okamih kontroly: rozhoduje stav v pôvodnom úložisku pri požiadavke, nie posledná úspešná synchronizácia indexu.

Oficiálna dokumentácia Google Drive potvrdzuje, prečo jednoduchá kópia ACL nemusí stačiť. Oprávnenia sa viažu na používateľov, skupiny, domény či verejný prístup, šíria sa z nadradených priečinkov a po presunutí položky sa znovu vyhodnocujú. Pri odobratí zdedeného oprávnenia navyše môže pretrvať priamy prístup udelený konkrétnemu súboru. SharePoint pracuje s vlastnou hierarchiou, dedičnosťou a výnimkami na úrovni knižnice, priečinka alebo jednotlivého dokumentu. Microsoft upozorňuje, že zdieľanie konkrétnej položky môže dedičnosť automaticky prerušiť. Jednotný index preto musí reprezentovať meniace sa pravidlá viacerých platforiem, čo zvyšuje priestor na oneskorenie alebo chybný preklad.

Bezpečnejší RAG nie je iba kvalitnejšie vyhľadávanie

Praktický význam novinky spočíva v oddelení relevancie od autorizácie. Vektorová podobnosť odpovedá na otázku, ktorý text sa najviac hodí k dopytu. Nemala by však rozhodovať, či ho konkrétna osoba smie vidieť. Kontrola priamo v úložisku posúva autorizačné rozhodnutie späť k systému, ktorý spravuje používateľov, skupiny, dedičnosť a odoberanie prístupu. RAG vrstva tak nemusí dokonale napodobniť každý detail cudzieho modelu oprávnení.

Pre slovenské firmy je tento rozdiel podstatný najmä pri prepájaní personálnych dokumentov, zmlúv, interných smerníc, finančných údajov a projektových priestorov do jedného asistenta. Používateľ môže mať prístup k všeobecnému priečinku oddelenia, ale nie k podpriečinku s mzdami alebo k dokumentom konkrétneho klienta. Pri tradičnom vyhľadávaní sa chyba prejaví zobrazením nesprávneho výsledku. Generatívny systém môže obsah dokumentu preformulovať bez uvedenia názvu súboru, takže incident sa horšie odhaľuje a spätne vysvetľuje.

Dvojstupňová architektúra zároveň ukazuje rozumný kompromis medzi bezpečnosťou a výkonom. Ak by sa každá otázka overovala voči tisícom položiek v SharePointe alebo Google Drive, narástla by latencia, počet API volaní aj riziko prekročenia limitov poskytovateľa. Predbežný filter zmenší pracovnú množinu a živá kontrola sa sústredí len na dokumenty, ktoré by sa reálne mohli dostať do odpovede. Toto usporiadanie však vyžaduje, aby bol zdroj dostupný práve v čase dopytu a aby integrácia bezpečne spravovala poverenia.

Čo sa mení pre architektov a správcov

Pri návrhu podnikového asistenta už nestačí otestovať, či systém nájde správny dokument. Testovací plán by mal obsahovať aj zmenu členstva v skupine, odobratie prístupu počas synchronizačného okna, presunutie súboru medzi priečinkami a dokument s výnimočným oprávnením. Výsledok treba preverovať na úrovni načítaných pasáží, nie iba vo finálnom texte. Model totiž môže odmietnuť citlivú odpoveď náhodou, hoci neoprávnený obsah už dostal v kontexte. Takýto test by vytvoril falošný pocit ochrany.

Dôležitá zostáva aj obrana vo viacerých vrstvách. Kontrola ACL obmedzuje, ktoré dokumenty smie systém načítať, ale sama nerieši prompt injection ukrytý v povolenom dokumente, nadmerné oprávnenia servisného účtu, nesprávne zdieľanie v zdrojovej službe ani úniky v logoch a telemetrii. Bedrock ponúka samostatné guardrails a kontroly ukotvenia odpovedí, tie však majú inú úlohu. Obsahové filtre nenahrádzajú autorizáciu a aktuálne oprávnenie zase nepotvrdzuje, že obsah je dôveryhodný alebo vhodný ako inštrukcia pre agenta.

Správcovia by mali sledovať aj zlyhania živej kontroly. Bezpečný návrh musí jasne určiť, čo sa stane pri výpadku Google Drive, chybnom tokene, prekročení limitu API alebo nejednoznačnej identite používateľa. Z pohľadu ochrany údajov je vhodnejšie požiadavku odmietnuť než pri chybe automaticky dôverovať indexovanej kópii. AWS v oznámení opisuje úspešný tok, no nezverejňuje podrobné čísla o pridanom oneskorení, nákladoch ani správaní pri každom type zlyhania. Tieto vlastnosti treba pred produkčným nasadením zmerať v konkrétnom prostredí.

Čo zatiaľ nevieme

AWS demonštruje architektúru na Google Drive a uvádza použitie pre podnikové zdroje, ako sú SharePoint a Confluence, ale oznámenie neposkytuje úplnú maticu podporovaných konektorov a rozdielov medzi ich autorizačnými modelmi. Nie je tiež jasné, ako rýchlo sa živá kontrola správa pri veľmi veľkých skupinách, komplikovanom dedení alebo vysokom počte kandidátskych dokumentov. Tvrdenie o aktuálnosti oprávnení pochádza od dodávateľa; v zverejnených podkladoch nie je nezávislý benchmark latencie ani bezpečnostný audit implementácie.

Novinka preto nie je univerzálnou zárukou bezpečného RAG, ale rieši konkrétnu a častú triedu chýb: rozdiel medzi oprávneniami zachytenými pri indexovaní a stavom platným pri otázke. Najdôležitejším posunom je, že vektorová databáza už nemusí byť poslednou autoritou nad prístupom k firemným vedomostiam. Pre produkčné systémy je to správny smer, pokiaľ ho doplnia testy odoberania prístupu, audit načítaných pasáží, minimálne oprávnenia integrácií a bezpečné zlyhanie pri nedostupnosti zdroja.