„Firmy často podceňují bezpečnost AI aplikací,“ říká expert na penetrační testování Petr Svoboda

S tím, jak nástroje využívající umělou inteligenci stále více pronikají do podnikového IT, vyvstává řada otázek ohledně jejich bezpečnosti. Jaká rizika s sebou využívání LLM modelů nese? Co vše testování odolnosti AI aplikací obnáší? A je využití „velkého“ modelu zárukou bezpečnosti? To popisuje Petr Svoboda z české společnosti TNS, která se věnuje organizační bezpečnosti a penetračnímu testování.

Vaše firma TNS se věnuje primárně penetračnímu testování a outsourcingu bezpečnosti. Co vás přivedlo k testování AI aplikací?

K testování AI nás přivedly dva faktory, osobní zájem a zároveň nevyhnutelnost začlenění této oblasti do našeho portfolia. Zajímalo nás, jak můžeme umělou inteligenci sami využít v práci i mimo ni, což přirozeně vedlo k potřebě porozumět jejím principům. Od toho pak byl už jen krůček k testování souvisejících kyberbezpečnostních rizik. 

AI má potenciál být další průmyslovou revolucí a osobně bych se necítil komfortně s představou, že něco bude mít velký vliv na naše životy a já nebudu vědět, jak to funguje.

Co vlastně znamená „testovat“ umělou inteligenci?

AI se postupně stává součástí informačních systémů i prostředí našich zákazníků. Přirozeně tak vzniká potřeba tyto systémy testovat, ať už jde o nějaký vlastní produkt využívající AI, u kterého chcete zajistit bezpečnost, nebo o řešení třetí strany, jehož rizika potřebujete vyhodnotit.

V souvislosti s AI obvykle testujeme dvě hlavní oblasti. První je testování samotného „jádra AI“, tedy ML modelu, nejčastěji LLM. To lze s nadsázkou přirovnat k sociálnímu inženýrství. Jen se místo přesvědčování člověka k otevření škodlivé přílohy snažíte přimět jazykový model, aby udělal něco, co nemá. Druhou oblastí je testování okolní aplikace. Představte si například chatbota, helpdesk nebo generátor smluv. Tady typicky testujeme webové rozhraní, API nebo CLI. Zde se už uplatňují stejné principy jako při testování tradičních aplikací, včetně hledání klasických zranitelností.

LLM systémy, jako jsou ChatGPT nebo Claude, se stávají součástí mnoha firemních aplikací. V čem vidíte hlavní bezpečnostní riziko jejich využívání?

Bezesporu je to únik citlivých dat, možnost manipulace s modelem a v neposlední řadě integrace s dalšími systémy. LLM často zpracovávají citlivé informace, což přináší riziko ztráty důvěry, finančních škod i právních dopadů. S rostoucími schopnostmi modelů jim firmy svěřují více pravomocí, například rozhodování o prvotním posouzení uchazečů o zaměstnání nebo vyřízení reklamace. Model může být napojen na interní databáze znalostí (např. přes RAG) nebo komunikovat s dalšími systémy přes MCP server, například pro přístup k firemnímu kalendáři. Špatně navržený MCP, tedy v podstatě program poskytující jazykovým modelům přístup k externím systémům a datům, může útočníkovi v krajním případě umožnit i vzdálené spuštění kódu na firemním serveru.

Představuje využití „prověřeného“ modelu záruku bezpečnosti?

Ani použití velkého, prověřeného modelu od renomované firmy nezaručuje bezpečnost. Jailbreak pro GPT-5 byl zveřejněn už den po oficiálním představení modelu. Je proto nezbytné testovat vždy celý systém, včetně všech propojení a rozhraní. S rostoucí mírou integrace AI do různých firemních procesů se zvyšuje nejen počet potenciálně zranitelných míst, ale i závažnost důsledků jejich kompromitace. V IT přitom panuje silný tlak na rychlé nasazení nových řešení, což často vede k podcenění bezpečnostních opatření.

Jak vypadá útok na AI v praxi?

Slabiny se často nenacházejí v samotném modelu, ale hlavně v jeho implementaci. Z praxe jsou známy případy, kdy nedostatečné zabezpečení aplikace s LLM umožnilo vážné útoky. Například do CLI rozhraní Google Gemini mohli útočníci vložit skryté příkazy, které se na počítači vývojáře spustily bez jeho vědomí. V open-source projektu Ollama chyběla validace cest, což útočníkovi umožňovalo přepsat soubory a spustit libovolný kód na serveru. U ChatGPT byla odhalena zranitelnost SSRF, umožňující chatbotu provádět nechtěné síťové požadavky, a také útoky, kdy model přebíral skryté instrukce ze zobrazených webových stránek.

Pokud bych to měl nějak shrnout, útok na AI systémy často necílí přímo na model, ale na slabou ochranu okolní aplikace, tedy typicky na špatně navržené rozhraní, neověřené vstupy nebo nevalidovaný kód. Ochrana proto musí zahrnovat nejen úpravu a filtrování samotného modelu, ale i standardní bezpečnostní opatření pro aplikace a infrastrukturu, na které je model nasazen.

LLM systémy jsou často přirovnávány k „černé skříňce“, kdy nelze přesně říct, proč odpověděly tak, jak odpověděly. Dá se v takovém prostředí vůbec důvěryhodně testovat jejich bezpečnost?

Pro účely penetračního testování musíme přijmout, že LLM je do značné míry ona „černá skříňka“. Porozumět vnitřnímu fungování neuronových sítí, tedy ve smyslu vlivu jednotlivých parametrů na výstup, bylo reálné naposledy u jednoduchých modelů, jako byl LeNet-5 publikovaný před více než čtvrt stoletím. Současné jazykové modely mají řádově milionkrát více parametrů, takže plné pochopení jejich chování není v lidských silách.

Obecná znalost principů neuronových sítí ale umožňuje odhadovat typy chování, které lze od modelu očekávat, a využívat je při snaze o vyvolání nežádoucích reakcí. Například postupným, nepřímým naváděním k zakázanému obsahu během několika promptů. Existuje řada technik, které se vyvíjejí spolu s modely a je nutné je průběžně sledovat.

Nedeterministická povaha LLM nám ale může při testování hrát do karet. Úspěch útoku může být částečně dílem náhody, zejména pokud náhodě pomůžete tím, že model vhodně navedete kontextem. I když útok nelze vždy přesně zopakovat, pro uživatele modelu je klíčové vědět, že riziko reálně existuje a jaké může mít následky. Protiopatření je pak vhodné doplnit determinističtějšími kontrolami, například nasazením tradičního programu, který ověří, že výstup modelu, který má být ve formátu JSON, má správnou strukturu a je validní.

Jaké nástroje nebo techniky používáte při testování LLM aplikací? Spoléháte na klasické penetrační testy, nebo jste museli vyvinout úplně nové přístupy?

Jak už jsem zmínil, při testování AI systémů se zaměřujeme jak na samotný model, tak i celé řešení, do kterého je začleněn. U druhé části lze využít osvědčené postupy a standardy známé z klasického penetračního testování. Pro testování LLM začínají vznikat i specifické standardy, například GenAI Security Project od organizace OWASP Foundation, která má dlouhou tradici v tvorbě metodik pro testování bezpečnosti. Tyto standardy sice nelze brát jako jediné vodítko, ale poskytují jistotu minimálního rozsahu oblastí, které mají být pokryty.

Objevují se také specializované nástroje. Zmínil bych například Garak od NVIDIA nebo Deepeval od Confident AI, které pomáhají s fuzzováním, tedy automatizovaným generováním, testováním a vyhodnocováním výstupů modelu. Vzhledem k tomu, že jde o velmi rychle se rozvíjející oblast, je i tady nutné neustále sledovat nové techniky i nástroje a přizpůsobovat jim testovací postupy.

Zajímalo by mě, jak si klient představuje „bezpečnou AI aplikaci“. Má vůbec jasnou představu? 

Část klientů nemá jasnou představu o cílech testování, což je ale běžné i mimo testování AI aplikací. Často jde o organizace, které nemají předchozí zkušenosti s penetračními testy, nebo je pro ně AI nové téma. V takových případech je na nás, abychom pomohli správně nastavit cíle testů tak, aby odpovídaly potřebám klienta a povaze testované aplikace.

Na druhou stranu k nám ale  přicházejí i klienti s dobrou znalostí AI a jasnou vizí toho, co chtějí testovat. Jsou si vědomi možných rizik a často znají i konkrétní metody útoků. To bývá typické u firem, které samy AI aplikace vyvíjejí.

Když aplikace používá jazykový model od třetí strany, třeba OpenAI nebo Mistral, kde končí odpovědnost vývojáře a začíná odpovědnost provozovatele?

Větší část odpovědnosti leží na vývojáři. Ten musí zajistit správné nastavení modelu (např. systémový prompt, limity), bezpečný způsob komunikace s API a zabezpečení všech ostatních částí aplikace, od webového rozhraní po integrace s dalšími systémy. Poskytovatelé modelů mohou nabízet tzv. copyright indemnity, tedy převzetí právní a finanční odpovědnosti za vybrané autorskoprávní spory při autorizovaném použití jejich služeb či výstupů. Nijak ale negarantují bezchybnost ani přesnost modelu.

Uvedu příklad z praxe. AI agent v systému pro tvorbu aplikací omylem smazal celou produkční databázi zákazníka. Technicky šlo o selhání výrobce agenta, nikoliv poskytovatele modelu. Právní dopady závisely na konkrétních smlouvách mezi stranami, které neznáme (výrobce – zákazník, výrobce – poskytovatel modelu), ale poskytovatel modelu pravděpodobně nepřebere odpovědnost za provozní škody způsobené agentem. Jeho smluvní ochrana se typicky vztahuje jen na spory o duševní vlastnictví. A i tam, kde smlouva obsahuje ustanovení o odpovědnosti za škody, bývá jejich maximální výše smluvně limitovaná.

AI může být nejen zneužita, ale i nechtěně diskriminovat, šířit dezinformace nebo „halucinovat“ nesmysly. Testujete i etickou nebo reputační stránku chování modelu? Dá se vůbec AI auditovat lidsky?

Ano, testování „správnosti“ odpovědí je součástí práce s jazykovými modely. Při trénování probíhá tzv. model alignment, kdy nastavujete pravidla chování, ladíte preference a implementujete  bezpečnostní filtry. Tyto oblasti se ověřují v rámci model evaluation a jsou zahrnuty i v metodikách, například od již zmíněné OWASP Foundation.

Protože model alignment probíhá při tréninku nebo fine-tuningu a většina uživatelů pracuje s hotovými modely třetích stran, nebývá kompletní testování alignmentu součástí našich testů. Vývojář AI aplikace může chování modelu částečně ovlivnit například systémovým promptem. V praxi je pro zákazníky obvykle důležitější ověřit, zda se model skutečně chová v souladu s tímto promptem, než provádět obecné hodnocení například etických aspektů jeho chování.

Evropský AI Act zavádí nové povinnosti pro firmy využívající AI. Myslíte si, že zákonodárci mají reálnou šanci držet krok s vývojem technologií? 

Technologický vývoj postupuje rychleji, než na něj dokáží zákonodárci reagovat. Evropský AI Act nastavuje spíše obecná pravidla, která mají své opodstatnění, zejména v oblasti zakázaného použití (např. sociální kreditní hodnocení občanů) a u vysoce rizikových nasazení (např. ve zdravotnictví). Každá regulace sice do určité míry zpomaluje vývoj a klade zvýšené nároky na konkurenceschopnost evropských firem, ale zároveň poskytuje jasný rámec pro bezpečné a etické využití AI, což považuji za důležité

Jak se s legislativními rámci v oblasti AI vypořádávají menší firmy?

Pro malé firmy je klíčové nejprve zjistit, do jaké kategorie rizikovosti jejich řešení spadá. Podle toho potom identifikují své povinnosti. U aplikací s minimálním rizikem jsou požadavky nízké a implementace dalších pravidel je hudba budoucnosti. Nejlepším postupem je začít se připravovat včas, i s pomocí externího konzultanta typu TNS, aby přechod na nový režim proběhl hladce.

Kdybyste měl varovat před jednou věcí všechny firmy, které začínají experimentovat s AI, co by to bylo? A co naopak považujete za největší příležitost?

Mé doporučení je poměrně jasné. Neposílejte citlivá ani proprietární data do AI modelů třetích stran nebo do nezabezpečených systémů. Vystavíte se tím riziku porušení předpisů, ztráty duševního vlastnictví a úniku dat.

Pokud ale AI modely budete využívat s jistou mírou obezřetnosti, přinesou vám na oplátku vyšší efektivitu práce, která se může přímo promítnout do vaší konkurenceschopnosti.. Vhodně použitá AI vám dokáže ušetřit mnoho času, který pak můžete věnovat dalšímu rozvoji.