Vybaví najčastejšie otázky zákazníkov, poradí s výberom produktu, skontroluje objednávku a odbremení ľudí na podpore. AI ChatBot výrazne znižuje tlak na zákaznícku podporu a tieto riešenia ponúka stále viac developerských firiem. Čo vám však ich obchodný zástupca pri predaji možno nespomenie, je, že chatbot prináša do firemnej infraštruktúry vážne bezpečnostné riziká, ktoré by ste mali eliminovať ešte pred nasadením.
Fungujúca ukážka sa dá vytvoriť pomerne rýchlo. Funkčný chatbot však nie je to isté ako bezpečný. Ak vám ide o druhé, nestačí iba na jazykový model napojiť firemné dáta. Každý podnikateľ tým v skutočnosti otvára nové verejné rozhranie do svojho prostredia. Ak napríklad dodávateľ zle uloží prístupové údaje, udelí riešeniu priveľké oprávnenia alebo nemonitoruje jeho správanie, útočník sa môže dostať oveľa ďalej ako k odpovediam na otázky o otváracích hodinách.
„Pri výbere dodávateľa by som si dal veľký pozor na jeho kredibilitu, históriu a preukázateľnú odbornosť. To, že riešenie na prvý pohľad funguje, ešte neznamená, že je aj bezpečné,“ upozorňuje Michal Korchaník z Binary Confidence. Zároveň dopĺňa, že na trhu vidieť masívny nárast rôznych subjektov, ktoré ponúkajú a integrujú takéto riešenia. Bez kvalitného zabezpečenia môže mať pritom ich využitie pre firmu likvidačný charakter. Chatbot je iba vstupné rozhranie. Dopad útoku závisí od systémov a oprávnení, ktoré sú k nemu pripojené.
Útok cez AI chatbot otvorí aj cestu do AWS
Predstavte si, že útočník si vyberie vašu firmu a nezačne hľadaním exotickej zraniteľnosti, ale rozhovorom s verejne dostupným firemným chatbotom. Pomocou vhodne zostavených požiadaviek ho postupne zmanipuluje, aby prezradil svoje skryté systémové inštrukcie. Ide o pravidlá, ktoré opisujú, čo má chatbot robiť, s akými zdrojmi pracuje a ako má odpovedať. Niekde medzi nimi sa nachádza aj prístupový kľúč.
Kľúč má oveľa širšie oprávnenia ako chatbot na svoju prácu potrebuje. Útočník ho preto dokáže použiť na vstup do firemného cloudového prostredia AWS. Vytvorí si nový administrátorský účet a zablokuje pôvodného správcu. Z obyčajného rozhovoru s chatbotom je zrazu plný prístup k infraštruktúre. Firma stráca kľúče od vlastnej digitálnej serverovne.
Aj keď hovoríme o tréningovom scenári finále súťaže Guardians 2026, ide o učebnicový príklad z reálneho života. Reťazec takýchto chýb je v praxi úplne bežný: citlivý údaj na nesprávnom mieste, zbytočne vysoké oprávnenia a chýbajúce kontrolné vrstvy.
Prompt injection: útočníci manipulujú AI chatboty
Technika, pri ktorej sa útočník pokúša zmeniť správanie modelu vlastnými inštrukciami, sa nazýva prompt injection. Môže chatbotovi prikázať, aby ignoroval pôvodné pravidlá, zahral inú rolu, vypísal interné pokyny alebo použil pripojený nástroj spôsobom, s ktorým tvorca nepočítal. Škodlivá inštrukcia pritom nemusí prísť iba priamo od človeka. Môže byť ukrytá aj v dokumente, e-maile či webovej stránke, ktorú má AI spracovať.
Organizácia OWASP zaradila prompt injection na prvé miesto svojho rebríčka najvážnejších rizík pre aplikácie využívajúce veľké jazykové modely. Medzi ďalšie patria únik citlivých informácií, vyzradenie systémových inštrukcií, priveľká autonómia a nekontrolovaná spotreba platených zdrojov.
Dôležitý detail je, že skrytý systémový prompt nemožno považovať za trezor. Môže usmerniť správanie modelu, ale nesmie nahrádzať autorizáciu ani obsahovať heslá, API kľúče či prístupové tokeny. Ak chatbot takýto údaj vôbec „vidí“, treba počítať s tým, že sa ho niekto pokúsi získať.
„Prístupové tokeny majú pre útočníkov reálnu hodnotu. Ukradnuté kľúče ďalej predávajú alebo ich používajú na vlastné aktivity, pričom účet za spotrebované ‘AI kredity‘, často v stovkách až tisícoch eur, zostáva napadnutej firme,“ vysvetľuje Michal Korchaník.
Riziko rastie s každým systémom, ku ktorému chatbota pripojíme. Ak iba odpovedá z verejného katalógu produktov, možný dopad je obmedzený. Ak číta CRM, pracuje s objednávkami, posiela e-maily, vytvára používateľov alebo ovláda cloudové služby, každé jeho oprávnenie sa môže stať oprávnením útočníka.
Samotný prompt injection pritom útočníkovi zázračne neodomkne AWS ani firemnú databázu. Odhalí však chyby v architektúre, ktoré tam už sú. Ak model nemá prístup k tajomstvám, nemôže ich prezradiť. Ak má jeho účet iba právo čítať verejné údaje, zmanipulovaný chatbot nedokáže vytvoriť administrátora. O veľkosti incidentu preto nerozhoduje iba to, či sa podarí umelú inteligenciu oklamať, ale najmä to, čo jej firma dovolila vidieť a urobiť.
Prečo funkčný AI chatbot ešte nemusí byť bezpečný
AI výrazne znížila technickú bariéru pri vývoji podobných riešení. To je dobrá správa pre inovácie, no nie automaticky pre bezpečnosť.
„Funkčnú ukážku dnes dokáže za krátky čas pripraviť aj menej skúsený tím. Schopnosť postaviť presvedčivé demo však ešte nie je dôkazom, že vie bezpečne navrhnúť celé riešenie,“ dodáva Michal Korchaník.
Chatbot totiž nie je iba okno na webe. Za ním je jazykový model, aplikačný kód, databáza, cloud, používateľské identity, firemné dokumenty a rozhrania tretích strán. Bezpečnosť výsledku závisí od najslabšieho článku v celom tomto reťazci.
Finančná škoda pritom nie je jediným možným následkom. Zle ohraničený chatbot môže zákazníkovi ukázať cudziu objednávku, vykonať nepovolenú zmenu alebo s veľkou istotou podať nesprávnu informáciu. Pri napojení na kritický proces ide o bezpečnostný incident.
Navyše nejde o produkt, ktorý zostane navždy rovnaký. Dodávateľ mení model, systémové inštrukcie, zdroje dát aj pripojené nástroje. Aj zdanlivo malá úprava môže zmeniť správanie riešenia alebo otvoriť nový spôsob zneužitia. Bezpečnostné testovanie a monitoring preto musia pokračovať počas celej prevádzky.
Päť otázok pred nasadením AI chatbota vo firme
1. Čo má dodávateľ za sebou?
Dôležité sú referencie, mená ľudí zodpovedných za bezpečnosť aj dôkaz, že riešenie nebolo otestované iba na funkčnosť. Pôsobivé demo nie je bezpečnostný audit.
2. K akým dátam a systémom bude chatbot pristupovať?
Dodávateľ má vedieť presne pomenovať, čo riešenie číta, čo môže meniť, kde sa dáta spracúvajú a či sa používajú na ďalšie trénovanie modelu.
3. Aké oprávnenia dostane?
Chatbot má podľa princípu najmenších oprávnení dostať prístup nevyhnutný na konkrétnu úlohu. Ak potrebuje čítať stav objednávky, nesmie mať účet, ktorý dokáže meniť používateľov alebo spravovať celý cloud. Citlivé operácie majú navyše vyžadovať schválenie mimo samotného modelu.
4. Kde sú uložené kľúče a kto sleduje ich použitie?
Tajomstvá nepatria do promptu ani priamo do kódu. Majú byť bezpečne uložené, pravidelne menené a ich použitie musí byť monitorované. Firma potrebuje limity spotreby, upozornenia na anomálie a spôsob, ako kompromitovaný prístup okamžite zrušiť.
5. Skúsil už niekto chatbota zlomiť?
Pred nasadením aj po významných zmenách potrebuje riešenie penetračný test. Tester má preveriť celý reťazec od vstupu používateľa cez model až po databázy, API a cloudové oprávnenia.
Implementácia AI chatbota bezpečne: problémom je slepá dôvera
Firmy by sa chatbotom nemali vyhýbať. Dokážu zrýchliť podporu, zlepšiť dostupnosť služieb a odbremeniť ľudí od opakujúcich sa úloh. Na druhej strane je potrebné nakupovať ich rovnako zodpovedne ako akúkoľvek inú aplikáciu, ktorá je dostupná na internete a pracuje s firemnými systémami.
„Bezpečnosť je vždy o vrstvách. Nestačí, že dodávateľ vyhlási chatbot za bezpečný. Potrebujete obmedziť jeho prístupy, nezávisle overovať citlivé operácie, monitorovať správanie a potom sa celé riešenie pokúsiť reálne zlomiť,“ zdôrazňuje Michal Korchaník.
Na Guardians vytvárame podobné scenáre preto, aby si obrancovia mohli nové útoky vyskúšať skôr, než ich stretnú vo vlastnej infraštruktúre. Rovnaký princíp platí aj pri reálnom nasadení AI. Cieľom je preveriť architektúru, minimalizovať oprávnenia, chrániť prístupové údaje, monitorovať prevádzku a testovať hranice riešenia ešte predtým, než ich začne hľadať útočník.
Chatbot má byť pomocník pri dverách vašej firmy. Pred jeho nasadením využite pomoc odborníkov na kyberbezpečnosť, aby sa z neho nestal vrátnik do najstráženejších zákutí vašej spoločnosti.
Táto aktivita je podporovaná European Cybersecurity Competence Centre (ECCC) ako súčasť projektu s grantovým kódom: 101145856 a Ministerstvom investícií, regionálneho rozvoja a informatizácie ako súčasť projektu Plán obnovy pod grantovým kódom: 17I04-04-V02-00001.
