Programujeme s AI každý den. Vlastní fakturační a provozní systém InvoAIM bychom ve dvou lidech jinak nepostavili — a nemá smysl předstírat, že to jde bez ní. Právě proto ale víme, kde to drhne. A nedrhne to tam, kde se čeká.
Co AI v kódu doopravdy kazí
Očekává se, že AI bude dělat překlepy a nesmysly. Jenže to nedělá. Kód, který napíše, se přeloží, testy projdou a demo funguje. Chyby, které dělá, jsou jiného druhu:
- Chybějící kontrola oprávnění. Funkce vrátí objednávku podle ID. Že to má být objednávka přihlášeného uživatele, nikdo nenapsal — a AI to sama od sebe nedoplní.
- Otevřená rozhraní. Administrační endpoint vznikl při ladění a zůstal dostupný bez přihlášení.
- Klíče v repozitáři. API token se při zkoušení napsal natvrdo do souboru. Později se vytáhl do proměnné prostředí, ale v historii commitů zůstal.
- Staré závislosti. Model navrhne knihovnu, kterou zná z trénovacích dat — tedy takovou, která byla populární před dvěma lety.
Všechno jsou to věci, které se při čtení „vypadá to dobře” nepoznají. Musí se hledat cíleně.
Čísla, ne dojmy
Nejde o pocit, že „AI kód je horší”. Měření z roku 2025 říkají tohle:
- Ve 45 % úloh obsahoval AI vygenerovaný kód bezpečnostní zranitelnost. Testovalo se přes 100 modelů na 80 úlohách — Veracode.
- Repozitáře psané s asistencí AI vykazují až desetkrát více bezpečnostních nálezů než ostatní — Apiiro.
Druhá polovina rovnice je objem. Google i Microsoft veřejně uvádějí, že AI dnes generuje zhruba čtvrtinu až třetinu nového kódu, u části mladých firem je to většina. Vynásobte si to.
Zajímavé je, že chybovost na úlohu se proti dřívějším modelům výrazně nezlepšila. Modely umí víc, píší lépe čitelný kód — ale bezpečnostní kontroly doplňují jen tehdy, když se o ně řekne. Zlepšení schopností tenhle problém samo nevyřeší.
Proč to nechytí testy
Testy ověřují, že aplikace dělá, co má. Bezpečnost je o opaku — co se stane, když ji někdo použije jinak, než jste zamýšleli:
| Co testujeme | Co netestujeme |
|---|---|
| uživatel si zobrazí svou objednávku | uživatel si zobrazí cizí objednávku |
| přihlášený admin otevře administraci | administraci otevře nepřihlášený |
| nahraje se obrázek | nahraje se skript přejmenovaný na obrázek |
| formulář uloží jméno | formulář uloží kus SQL dotazu |
Zelené testy a otevřená administrace vedle sebe existují úplně bez problému. Jedno o druhém nic neříká.
Od 11. září 2026 se to změní i papírově
Dosud bylo prověření kódu dobrovolná péče. Cyber Resilience Act z toho dělá povinnost s termínem.
Nařízení EU 2024/2847 platí pro produkty s digitálními prvky uváděné na trh EU. Rozhodující je, jestli dodáváte software dál, ne jak jste velcí:
- 11. 9. 2026 — začínají ohlašovací povinnosti. Aktivně zneužívanou zranitelnost nebo závažný incident musíte hlásit: první varování do 24 hodin, úplné oznámení do 72 hodin, závěrečnou zprávu do měsíce.
- 11. 12. 2027 — platí zbytek: bezpečnost po celý životní cyklus, technická dokumentace, posouzení shody a označení CE.
Aby se dala zranitelnost ohlásit do 24 hodin, musí ji někdo umět najít a popsat. To není věc, kterou vyřešíte až ve chvíli, kdy nastane.
K tomu se přidává NIS2, který v Česku platí jako zákon č. 264/2025 Sb. a dotýká se zhruba šesti tisíc firem. Ten tlačí na dodavatelský řetězec — když dodáváte software regulované firmě, kontrola přijde od ní, ať se vás nařízení týká přímo, nebo ne.
Co s tím prakticky
Pokud nechcete nic kupovat, tohle zvládnete sami a má to největší poměr přínosu k času:
- Projděte historii commitů na klíče a hesla. Ne jen aktuální stav — historii. Nalezený token je potřeba zneplatnit, ne smazat.
- Vypište si všechny endpointy a u každého odpovězte: kdo se k němu dostane bez přihlášení?
- U každého čtení dat z databáze ověřte, že filtruje podle přihlášeného uživatele, ne jen podle ID z požadavku.
- Aktualizujte závislosti a projděte známé zranitelnosti.
- Vypněte debug a chybové hlášky, které vypisují vnitřnosti aplikace.
Až budete hotoví, zbývá druhá polovina: doložit to. Poznámka v hlavě není podklad pro objednatele ani pro dokumentaci podle CRA.
Kdy zavolat někomu zvenčí
Vlastní kód se čte špatně — víte, jak měl fungovat, a čtete to, co jste zamýšleli, ne to, co tam je. Externí pohled dává smysl hlavně tehdy, když aplikace pracuje s osobními údaji nebo platbami, když ji předáváte objednateli, nebo když po vás někdo chce doložit, že je prověřená.
Děláme prověrku aplikace před spuštěním: strojový sken, ruční ověření nálezů a písemný protokol s verdiktem. Kód zpracováváme lokálně v Česku, ne v cloudu třetí strany — u zdrojového kódu to bývá podmínka, ne rozmar.
Často se ptáte
Znamená to, že se s AI nemá programovat?
Ne. Sami s ní programujeme denně a bez ní bychom vlastní systém nepostavili v tomhle tempu. Problém není nástroj, ale poměr mezi tím, kolik kódu vznikne, a kolik ho někdo přečte. Dřív tenhle poměr držela rychlost psaní. Dneska ho nedrží nic — musí se doplnit vědomě.
Nechytí to testy?
Většinou ne. Testy ověřují, že aplikace dělá, co má, když ji používá slušný uživatel. Bezpečnostní chyby jsou o tom, co se stane, když ji někdo použije jinak: zavolá cizí endpoint, pošle jiné ID, zkusí nahrát soubor jiného typu. Zelené testy a otevřená administrace vedle sebe existují bez problému.
Týká se Cyber Resilience Act i malé firmy?
Rozhoduje, jestli dodáváte na trh EU produkt se software, ne jak jste velcí. Ohlašovací povinnosti u aktivně zneužívaných zranitelností a závažných incidentů platí od 11. září 2026, zbytek od 11. prosince 2027. Ohlašovací lhůty jsou 24 hodin na první varování a 72 hodin na úplné oznámení.