AWS skladá data mesh pre agentov s kontrolou prístupu od nástroja po odpoveď

AWS v novom technickom texte pomenúva problém, ktorý sa pri firemných AI agentoch často skrýva za jednoduchou ukážkou. Agent, ktorý má odpovedať zákazníkovi alebo analytikovi, už nepracuje iba s jedným vektorovým indexom. Môže objavovať schémy databáz, vyberať nástroje, skladať SQL dotazy, čítať pravidlá z rôznych systémov a následne z týchto údajov vytvoriť odpoveď. Takýto tok je už bližšie k dátovej aplikácii než ku klasickému chatbotovi, a preto nestačí jedna kontrola oprávnení na začiatku.

Text nadväzuje na skorší prístup k bezpečným RAG aplikáciám nad serverless dátovými jazerami, kde sa prístup riadil metadátami pri vyhľadávaní dokumentových úryvkov. Pri agentoch je situácia zložitejšia. RAG často znamená: nájdi relevantné časti, odfiltruj ich podľa pravidiel a vlož do promptu. Agentická aplikácia však môže najprv zistiť, aké dátové zdroje existujú, potom vytvoriť dotaz, spustiť ho cez analytický nástroj a až potom výsledky vysvetliť používateľovi. Každý z týchto krokov je samostatné miesto, kde môže dôjsť k úniku alebo obídeniu politiky.

Navrhovaná architektúra preto používa moderný data mesh, teda usporiadanie dát podľa domén s jasným vlastníctvom a riadeným zdieľaním, nie ako jeden centrálne otvorený sklad. AWS do skladby zapája služby ako AWS Lake Formation, AWS Glue Data Catalog, Amazon Athena, Amazon Bedrock Knowledge Bases a Amazon Bedrock AgentCore. Cieľom nie je iba poskytnúť agentovi viac dát, ale dať mu iba tie nástroje a tabuľky, ktoré používateľ alebo jeho rola skutočne smie použiť.

Zaujímavý je dôraz na AgentCore Gateway a interceptory. Brána pre nástroje môže fungovať ako miesto, kde sa kontroluje, či agent vôbec smie daný nástroj vidieť a volať. Interceptor potom vie vložiť dodatočné overenie alebo upraviť správanie pred vykonaním akcie. V praxi to znamená, že bezpečnostná politika nemusí byť ukrytá v jednom obrovskom systémovom prompte. Dá sa presunúť bližšie k infraštruktúre, kde je auditovateľná, opakovateľná a menej závislá od toho, či model správne pochopí pravidlá.

Ďalšou vrstvou sú analytické služby a riadenie dát. Lake Formation umožňuje jemné oprávnenia nad dátami, Glue Data Catalog popisuje schémy a Athena slúži ako vrstva pre dotazovanie. Ak agent generuje SQL, nestačí dúfať, že nevytvorí nevhodný dotaz. Dotaz musí prejsť cez pracovnú skupinu, politiky a filtre, ktoré zohľadnia používateľa, doménu a citlivosť dát. Až potom má zmysel riešiť, ako model výsledky preformuluje do odpovede.

Pre firmy je praktický dopad jasný: produkčný agent nad dátami potrebuje rovnakú disciplínu ako iné podnikové systémy. Musí existovať záznam o tom, aké dáta použil, aké nástroje volal, prečo mal prístup k danej tabuľke a či odpoveď neprekročila oprávnenia používateľa. Bez týchto vrstiev môže agent pôsobiť užitočne v demo prostredí, ale v reálnej organizácii narazí na právne, bezpečnostné a compliance limity skôr, než prinesie produktivitu.

AWS tým zároveň posúva diskusiu o agentoch od modelových schopností k dátovej architektúre. Mnohé tímy dnes riešia, ktorý model použiť a ako napísať prompt, no menej času venujú otázke, či majú pripravené doménové katalógy, politiku zdieľania a kontrolu na úrovni nástrojov. Pri agentoch, ktorí majú autonómne skladať dotazy, je však dátový základ často rozhodujúci. Slabý data mesh sa nedá plne zachrániť lepším modelom.

Takto postavená architektúra má aj organizačný rozmer. Dátové tímy musia popísať domény a klasifikácie, bezpečnostné tímy musia nastaviť politiky a aplikačné tímy musia rozhodnúť, ktoré agentické nástroje budú dostupné pre ktoré roly. Agent sa tým stáva spotrebiteľom podnikového dátového produktu, nie výnimkou, ktorej sa do promptu ručne vloží priveľa oprávnení len preto, aby demo fungovalo.

Dôležité je aj to, že ide o technický návod, nie o hotový univerzálny produkt. Organizácie si budú musieť prispôsobiť domény, oprávnenia, audity aj rozhodovanie o tom, ktoré nástroje agent dostane. Hodnota článku je skôr v tom, že pomenúva viacbodový bezpečnostný reťazec: objavenie nástroja, autorizácia volania, vykonanie dotazu, filtrovanie dát a syntéza odpovede. Práve tento reťazec bude pri podnikových agentoch čoraz dôležitejší než samotná otázka, či model vie napísať SQL.