Bezpečnost aplikací psaných s AI: nejčastější chyby a jak je najít

Krátká odpověď: Aplikace psané s AI selhávají v bezpečnosti na stejných místech jako aplikace psané lidmi, jen s tím rozdílem, že je při rychlém psaní nikdo nevidí. Nejčastější chyby jsou chybějící řízení přístupu, klíče v kódu, nekontrolované vstupy, zastaralé závislosti a chybějící logování. Všechny popisuje veřejný seznam OWASP Top 10 a všechny se dají najít kombinací automatického skenu, kontroly kódu a penetračního testu podle rizik aplikace.

Proč na tom záleží

AI napíše funkční kód rychle, ale bezpečnou variantu zvolí jen v části případů, i když se to zlepšuje. Veracode v říjnu 2026 otestoval 18 jazykových modelů na úlohách ve čtyřech programovacích jazycích a čtyřech typech zranitelností. Modely napsaly bezpečný kód v průměru v 62 % případů, v předchozím měření to bylo 56 %. Nejlepší, Claude Opus 5.5 a GPT-6-Sol, dosáhly 73 %, takže i ty selhaly zhruba v jedné úloze ze čtyř. U vkládání cizího kódu do stránky (cross-site scripting) prošlo jen 18 % řešení a u podvržení záznamů v logu (log injection) 13 %. Pro srovnání, první studie Veracode z roku 2025 (přes 100 modelů, 80 úloh) našla zranitelnost v 45 % případů.

Pro člověka, který za aplikaci odpovídá, z toho plyne jedna věc. Nezáleží na tom, jestli kód napsal Claude Code, Cursor, Lovable nebo kolega. Záleží na tom, jestli ho před spuštěním někdo prověřil stejně, jako by prověřoval kód od nového dodavatele. Tento článek je pilíř našeho clusteru o bezpečnosti a legislativě: dává přehled, odkud chyby přicházejí, jak vypadají v řeči byznysu a jak je najít. Na detaily navážeme samostatnými články o prompt injection u AI agentů, o penetračním testu aplikace postavené s AI a o povinnostech podle NIS2 a zákona o kybernetické bezpečnosti.

Chcete vědět, kde má vaše aplikace psaná s AI slabá místa? Rezervujte si 30 minut online s námi. Řekneme vám, co bychom prověřili jako první. Domluvit online call

Proč kód od AI selhává v bezpečnosti

Model píše kód, který funguje, ne kód, který odolá. Jazykový model se učil z veřejného kódu a v něm je bezpečná varianta často menšinová. Když mu zadáte „udělej přihlášení“, dostanete přihlášení. Když neřeknete „a hlídej, aby uživatel viděl jen svoje záznamy“, model to v mnoha případech neudělá, protože to zadání neobsahovalo. Zlepšení je zatím nerovnoměrné. V roce 2025 Veracode nenašel mezi novějšími a většími modely znatelný posun v bezpečnosti. V říjnu 2026 poprvé uvedl znatelné zlepšení: velké modely dosahují v průměru 55 %, malé 51 %. Táhne ho ale hlavně XSS, u log injection se nezměnilo nic, a v Javě zůstává bezpečných jen 31 % řešení.

Druhý důvod je tempo. Vibe coding, tedy programování popisem v přirozeném jazyce bez čtení výsledného kódu, umožňuje postavit aplikaci za víkend. Bezpečnostní kontrola, která by dřív proběhla přirozeně při psaní a code review, v tomhle tempu vypadne. Výsledek je aplikace, kterou nikdo z lidí celou nečetl.

Třetí důvod je nový: aplikace, které samy používají AI. Chatbot nad firemními dokumenty nebo agent, který vyřizuje objednávky, má další vstup, který může být zneužit. Pokyn schovaný v dokumentu nebo v e-mailu může změnit chování modelu. Tomu se říká prompt injection a budeme se mu věnovat v samostatném článku. Tady stačí vědět, že klasické zranitelnosti webových aplikací a zranitelnosti AI se v jedné appce sčítají.

OWASP Top 10 v řeči ředitele

OWASP Top 10 je veřejný seznam deseti nejčastějších kategorií zranitelností webových aplikací, který vydává nezisková organizace OWASP. Aktuální je vydání 2025, osmé v pořadí. Není to norma ani certifikace, ale společný jazyk, kterému rozumí vývojáři, testeři i auditoři. Když vám dodavatel řekne, že aplikace „prošla OWASP Top 10“, myslí tím, že byla prověřena proti těmto deseti kategoriím. Níže je překlad do otázek, které můžete položit vy.

Pro rozhodování je důležité, že seznam se mezi vydáními 2021 a 2025 příliš nezměnil. Narušení řízení přístupu zůstává na prvním místě a dodavatelský řetězec posílil. To jsou přesně oblasti, ve kterých AI-built aplikace selhávají nejčastěji, protože model tyto hranice sám od sebe nestaví.

Sedm nejčastějších chyb v aplikacích psaných s AI

Následující seznam vychází z OWASP Top 10 a z toho, co u AI-built aplikací bývá nejčastější. Není to statistika, ale praktický pořadník toho, co prověřit jako první. Když ho projdete s lidmi, kteří aplikaci přebírají do App as a Service, nebo s vlastním týmem, ušetříte si většinu překvapení.

• Chybějící řízení přístupu. Aplikace ověří, že jste přihlášený, ale už neověří, jestli smíte otevřít právě tento záznam. Praktický test zvládne i člověk bez technického vzdělání: dva účty, jeden záznam, pokus otevřít ho z druhého účtu změnou čísla v adrese.
• Klíče a hesla v kódu. API klíče k platbám, mapám nebo AI službám model často vloží přímo do kódu nebo do části aplikace, která běží v prohlížeči. Odtud si je může přečíst kdokoli a účet za jejich zneužití přijde vám.
• Nekontrolované vstupy a injekce. Formulář, vyhledávání nebo nahrání souboru jsou místa, kudy do aplikace přichází cizí obsah. Pokud se dostane přímo do databáze nebo do stránky, útočník přes něj čte nebo maže data. U aplikací s AI k tomu přibývá prompt injection, tedy pokyn schovaný v obsahu, který model čte.
• Zastaralé a neznámé závislosti. Model sáhne po knihovně, která byla populární v době jeho trénování. Nikdo nekontroluje, jestli má známé zranitelnosti nebo jestli ji ještě někdo udržuje. Dodavatelský řetězec je v OWASP Top 10:2025 na třetím místě.
• Chybějící logování a upozornění. Aplikace funguje, ale nikdo neví, co se v ní děje. Když někdo zkouší tisíc hesel za minutu nebo stahuje celou databázi, nikdo se to nedozví. Bez logů se navíc nedá incident ani vyšetřit, ani nahlásit tam, kde to zákon vyžaduje.
• Slabá autentizace. Přihlášení bez limitu pokusů, obnova hesla přes uhodnutelný odkaz, tokeny bez expirace. Model vygeneruje přihlášení, které funguje, ne přihlášení, které odolá.
• Výchozí konfigurace v produkci. Testovací účty, ladicí režim, otevřená administrace, databáze přístupná z internetu. Prototyp to nepotřebuje řešit, produkce ano.

Část z těchto chyb najde automatický sken. Chyby spojené s oprávněními a obchodní logikou, třeba chybějící řízení přístupu, ale obvykle odhalí až člověk nebo test na běžící aplikaci. To je dobrá zpráva: většinu rizika snížíte rutinou, ne hrdinstvím.

Jak chyby najít: sken, kontrola kódu a penetrační test

Tři vrstvy kontroly se nenahrazují, ale doplňují. Každá najde jiný typ chyby a každá stojí jiné úsilí. Pro rozhodnutí, kolik kontroly aplikace potřebuje, pomáhá tabulka.

Automatický sken je nejlevnější a měl by běžet při každé změně. Kromě klasických skenerů dnes dává smysl i AI code review, které projde celý kód a najde možné chyby. Nástroje pro vývoj s AI často nabízejí vlastní bezpečnostní skeny a jejich výrobci sami uvádějí, že odpovědnost za bezpečnost zůstává na autorovi aplikace. Sken je dobrý začátek, ne konec.

Kontrola člověkem je ta vrstva, která u AI-built aplikací nejčastěji chybí. Nemusí to být kompletní audit. AI kódu bývá tolik, že ho člověk ručně celý efektivně neprojde, proto ho nejdřív projde automatika a člověk se soustředí na podstatná rizika a stabilitu základu. Zkušený vývojář za pár hodin pozná, jestli aplikace má řízení přístupu, kde jsou klíče a jestli je kód postavený na stabilním základu, nebo na sérii oprav. Veracode v tomto směru shrnuje svá měření stejně: ani nejlepší model nenahrazuje nezávislé ověření.

Penetrační test je pokus aplikaci záměrně rozbít z pozice útočníka. Dává smysl ve chvíli, kdy je co ztratit: platící zákazníci, osobní údaje, platby. Jestli ho potřebujete a v jakém rozsahu, záleží na typu aplikace, architektuře, citlivosti dat a dopadu případného incidentu. U běžné webové aplikace se obvykle soustředí na backend, API, přihlašování a přístupová práva. Jak ho zadat, co od něj čekat a jak vybrat dodavatele, rozebereme v samostatném článku o penetračním testu aplikace postavené s AI. Příklad z naší praxe: Android aplikace Photo Creation Guide pro dokumentaci crash testů v automotive má šifrované offline úložiště a prošla bezpečnostním posouzením a penetračním testem bez nálezu. Bylo to možné proto, že se bezpečnost řešila od začátku, ne po dokončení.

Co s nálezy: pořadí, odpovědnost a rutina

Nález bez opravy je jen dražší nevědomost. Výstup z každé kontroly je seznam, který je potřeba seřadit podle dopadu na byznys a přiřadit mu majitele a termín. Nejdřív se opravuje to, co umožňuje přístup k cizím datům nebo převzetí účtu. Pak klíče a závislosti. Nakonec konfigurace a logování, které nejsou díra, ale bez nich díru neuvidíte.

Jednorázová kontrola stárne stejně rychle jako kód. Aplikace, kterou dnes prověříte, bude mít za půl roku nové funkce, nové knihovny a nové chyby. Proto doporučujeme bezpečnost brát jako rutinu: sken při každé změně, kontrola člověkem u každé větší změny, penetrační test podle rizik aplikace a po zásadním zásahu. Ve firmách, kde vyvíjí s AI víc lidí najednou, to znamená i centrální správu přístupů a klíčů a nasazení jen do schválených prostředí. To je přesně to, co řešíme v AI Infrastructure. Větší riziko než samotný kód bývá často architektura a oprávnění, třeba AI agent s přímým přístupem do produkce.

Část povinností přestává být dobrovolná. Pokud vaše firma spadá pod nový zákon o kybernetické bezpečnosti, patří řízení rizik, logování a hlášení incidentů mezi požadavky, ne doporučení. A pokud aplikace zpracovává osobní údaje, má bezpečnost dopad i na GDPR a AI. Konkrétní dopad na vaši firmu ověřte s právníkem.

Kdy stačí vlastní kontrola a kdy přizvat tým

Vlastní kontrola a automatický sken stačí, když:

• aplikaci používá jen váš tým nebo pár známých zákazníků a neukládá citlivá data,
• v aplikaci neprobíhají platby ani se nepracuje se zdravotními či finančními údaji,
• máte v týmu někoho, kdo kód přečte a sedm chyb z tohoto článku s vámi projde,
• aplikace nepoužívá AI nad firemními dokumenty ani nevykonává akce za uživatele,
• výpadek nebo únik by nikomu vážně neublížil.

Tým přizvěte a penetrační test zvažte podle rizik, když:

• aplikace jde k platícím zákazníkům nebo veřejnosti,
• ukládá osobní údaje většího počtu lidí nebo zpracovává platby,
• obsahuje chatbota, agenta nebo jinou AI, která čte cizí obsah nebo vykonává akce,
• vaše firma může spadat pod zákon o kybernetické bezpečnosti nebo má zákazníky, kteří to po vás chtějí,
• z tabulky OWASP nevíte u více než tří otázek, jak odpovědět.

Pokud jste se našli v druhém seznamu, napište nám pár vět o své aplikaci. Ozveme se s tím, jak bychom postupovali. Poslat poptávku

Jak k tomu přistupuje MeguMethod

Když k nám přijde aplikace postavená s AI, začínáme stejnými otázkami, jaké jsou v tabulce OWASP výše. Architektura, bezpečnost a kontrola kódu jsou technické mantinely, které v App as a Service nastavujeme před každým spuštěním: první verze vzniká s architekturou, testy a pravidly nasazení a jde rovnou do produkce. Výsledek prvního průchodu je seznam toho, co drží, co je potřeba zpevnit a co může počkat.

Dál každou změnu, kterou v aplikaci uděláte, kontroluje automatika i naši inženýři z hlediska bezpečnosti, architektury a funkčnosti. Kód zůstává váš a dostanete k němu nástroje a návod, abyste ho mohli rozvíjet sami. U firem, kde s AI vyvíjí víc lidí, řešíme totéž na úrovni celé firmy: řízené nasazení jen do schválených prostředí, centrální správu přístupů a klíčů a uzavřené AI smyčky, ve kterých model pracuje jen s daty, která firma výslovně povolí.

Další krok

Máte aplikaci postavenou s AI a chcete vědět, jak na tom je bezpečnostně? Podívejte se, jak funguje App as a Service, nebo si rovnou domluvte 30 minut online a projdeme sedm chyb z tohoto článku na vaší aplikaci. Pokud chcete nejdřív širší kontext, přečtěte si checklist, jestli je vaše AI-built aplikace připravená pro skutečné uživatele, nebo starší text o tom, jestli vyvíjet software s testery, nebo bez nich.