RAG (Retrieval Augmented Generation) patrí medzi najčastejšie používané prístupy, ako bezpečne a prakticky napojiť jazykový model na firemné dáta. Namiesto toho, aby model „hádal“, najprv si vytiahne relevantné podklady z internej znalostnej bázy a až potom z nich poskladá odpoveď. Tento prístup znižuje halucinácie a rieši problém s aktuálnosťou informácií.

Zároveň však vytvára nový, často ignorovaný attack surface. Útočník v tomto scenári nemusí útočiť priamo na model. Stačí mu ovplyvniť to, čo model považuje za zdroj pravdy.

Presne to je podstata RAG Poisoning, teda otrávenia knowledge base. Nejde o to „presvedčiť“ model priamo v interakcii v chate. Ide o otrávenie dát, ktoré systém vyhľadáva, aby retrieval algoritmus stabilne podsúval nesprávny, zmanipulovaný alebo škodlivý kontext. V praxi je to často nebezpečnejšie ako priame útoky na prompt, pretože odpoveď sa tvári ako legitímna citácia internej dokumentácie.

Kde presne sa dá RAG otráviť

Typická RAG aplikácia má tri miesta, kde vzniká riziko. Každé z nich sa oplatí hodnotiť a auditovať samostatne:

• Ingestion pipeline: Cesta, ktorou sa dokumenty dostanú do znalostnej bázy a následne do indexu alebo vektorovej databázy (embeddings). Ak je ingestion automatizovaný a málo kontrolovaný (napríklad auto-crawling interných stránok alebo voľné importy z priečinkov), útočník získa priestor na „tiché“ vloženie škodlivého obsahu bez toho, aby musel prelomiť admin práva.
• Knowledge base: Samotné úložisko – Wiki, JIRA (ticketové riešenia), zdieľané disky, interné intranet portály. Tu sa rozhoduje o integrite a vlastníctve obsahu. Často sa zabúda, že write access do wiki / JIRI sa pre AI systém rovná write access do mozgu firmy.
• Retrieval a ranking: Vrstva, ktorá vyberá „najrelevantnejšie“ pasáže. Po otrávení môže retrieval vytiahnuť presne to, čo útočník chce, aj keď zvyšok databázy je v poriadku. Útočníci tu využívajú princíp podobný „Black Hat SEO“ – optimalizujú škodlivý text tak, aby vo vektorovom vyhľadávaní vyzeral najrelevantnejšie.

RAG Poisoning vs. Indirect Prompt Injection

Tieto pojmy sa často zamieňajú, ale majú iný mechanizmus a vyžadujú inú obranu.

• Indirect Prompt Injection: Útočník schová inštrukcie do externého obsahu (napríklad do web stránky), ktorý model spracuje. Model potom interpretuje časť obsahu ako pokyn a zmení svoje správanie.
• RAG Poisoning: Cieľom nie je zmeniť správanie modelu, ale zmeniť fakty, z ktorých vychádza. Útočník manipuluje obsah v knowledge base tak, aby retrieval vyťahoval zmanipulované postupy, odkazy alebo čísla.

Kľúčový rozdiel je v perzistencii. Injection býva často jednorazová záležitosť v rámci konkrétnej interakcie. Otrávený dokument v knowledge base je perzistentný. Môže tam ležať mesiace a ovplyvňovať odpovede pre stovky používateľov, kým si anomáliu niekto všimne.

Ako vyzerá útok v praxi

Scenár A: „RAG SEO“ optimalizácia pre útočníka

Útočník nemusí zmazať správny dokument. Stačí mu vytvoriť nový alebo upraviť existujúci tak, aby obsahoval kľúčové slová a štruktúru „napísanú“ pre vektorové vyhľadávanie.

• V praxi: Znamená to vložiť do dokumentu obsah, ktorý človek pri bežnom čítaní ľahko prehliadne, ale embedding ho spracuje a zvýši relevanciu dokumentu. Výsledok je jednoduchý – pri častej otázke model dostane do kontextu práve tento otrávený zdroj.

Scenár B: Otrávenie dôveryhodného zdroja

Najzradnejšie sú zásahy do dokumentov, ktoré ľudia považujú za autoritatívne (interné smernice, „oficiálne“ postupy).

• V praxi: Typický pattern je zmena jednej vety, ktorá mení rozhodovanie. Napríklad obídenie schvaľovania, presmerovanie komunikácie na neautorizovaný kontakt alebo vloženie „dočasnej výnimky“. Keď sa zamestnanec spýta asistenta na postup, model poradí podvod s istotou a ešte to odcituje ako interný predpis.

Scenár C: Otrávenie štruktúrovaných znalostí

RAG sa nerobí len nad textom. Narastá používanie knowledge graphov. Tu útok vyzerá ako vloženie falošného vzťahu medzi entitami alebo zmena atribútu. Odhaľovanie je ťažšie, lebo zmena nie je viditeľná ako „podozrivý text“, ale ako zmena dátovej väzby.

Dopad: Prečo je to problém aj pre audit

RAG poisoning má dva rozmery, ktoré firmy často podcenia:

1. Bezpečnostný dopad: Model môže odporučiť postup, ktorý znižuje bezpečnosť, naviesť používateľa na phishing alebo normalizovať riskantné správanie tým, že ho prezentuje ako interný štandard.
2. Auditný dopad: Ak RAG používate v procesoch s dopadom na rozhodovanie, potrebujete traceability. Pri incidente neviete dokázať, či model halucinoval, alebo či bol zdrojový dokument v čase otázky zmanipulovaný.

Kontroly, ktoré reálne fungujú

Toto sú opatrenia realizovateľné aj bez nákupu drahých „AI Security“ nástrojov. V jadre je to klasická informačná bezpečnosť aplikovaná na nové prostredie.

Trust Tiers pre zdroje

Nerozlišujte len „máme dáta“. Rozdeľte zdroje do úrovní dôveryhodnosti:

• Tier 1: Podpísané smernice a schválené postupy (ideálne read-only pre väčšinu firmy).
• Tier 2: Interné Wiki stránky so schvaľovacím workflow.
• Tier 3: Otvorené diskusie, tickety, e-maily, ad-hoc poznámky.

Opatrenie: Pri konfliktných informáciách nech retrieval preferuje vyšší tier. Pri čerpaní z nízkych tierov nech systém odpoveď označí ako menej dôveryhodnú.

Ownership a kontrola publikovania

Poisoning je často dôsledok toho, že do znalostnej bázy môže zapisovať príliš veľa ľudí bez zodpovednosti. Zavedenie minimálnych pravidiel spraví veľa:

• Vlastník obsahu (Data Owner).
• Schvaľovanie pri kritických témach.
• Verzovanie a nemenná história zmien.

Monitoring zmien a detekcia anomálií

Zamerajte sa na signály typické pre „RAG SEO“ a tiché otrávenie:

• Masové úpravy starých dokumentov.
• Nezvyčajné úpravy dokumentov, ktoré sú často citované modelom.
• Nové dokumenty v autoritatívnych priestoroch bez jasného vlastníka.

Retrieval Guardrails

RAG nie je len vyhľadávanie. Je to rozhodovanie, čo pustíte do kontextu.

• RBAC Filter: Filter zdrojov podľa identity používateľa ešte pred retrievalom.
• Multi-source verification: Overovanie kritických informácií z viacerých nezávislých zdrojov (keď ide o peniaze alebo prístupy).

Oddelenie Instructions od Data

Systém musí striktne odlišovať „System Instructions“ a načítané dáta. Dáta z knowledge base majú byť spracované ako podklad na analýzu, nie ako pokyn. Ak sa tento princíp nedodrží, poisoning a injection sa začnú prelínať.

Prevádzková realita: Dostupnosť a náklady

RAG pipeline je závislá od vyhľadávania, indexov a vektorovej databázy. Aj to je útokový povrch. Útočník nemusí meniť fakty, aby spôsobil dopad. Stačí zahltiť systém otázkami, ktoré sú drahé na retrieval alebo vytvoria vysokú záťaž (DoS). Preto sa oplatí mať limity, kvóty a monitoring spotreby.

Záver

RAG je silný prístup, ale presúva dôveru z modelu na dáta. A dáta sú živé, meniteľné a vo firmách často spravované menej prísne, než si bezpečnosť vyžaduje.

Toto je reálny scenár, ktorý využíva slabé miesto mnohých firiem ako nekontrolované znalostné bázy a automatický ingestion. Ak chcete RAG nasadiť bezpečne, nezačínajte modelom. Začnite uprataním knowledge base. Nastavte ownership, trust tiers, audit trail a kontrolu nad tým, čo sa indexuje. Až potom riešte „inteligenciu“.

Rýchly checklist pre manažérov

1. Audit prístupov: Kto môže zapisovať do Wiki/SharePointu, z ktorého čerpá AI?
2. Trust Tiers: Máme oddelené „kľučové“ dáta (smernice) od „vaty“ (tickety)?
3. História: Máme zapnuté verzovanie dokumentov, aby sme vedeli vrátiť zmeny?
4. Monitoring: Upozorní nás systém, ak sa zmení kritická smernica, alebo dokument?