Kontrola AI generovaného kódu v týmu – review, závislosti, vymyšlené balíčky a odpovědnost

AI programovací asistenti dnes dokážou během minut napsat funkci, test nebo celou aplikaci. Kód ale nemusí být správný, bezpečný ani smysluplný, i když vypadá přesvědčivě. Právě tahle důvěryhodnost bez záruky je hlavní riziko: lidé mají sklon věřit výstupu, který je plynulý a sebejistý. Tento článek ukazuje, jak v týmu kontrolovat kód od AI, na co si dát pozor u závislostí a kdo za výsledek odpovídá.

Informace vycházejí z projektu OWASP Top 10 pro LLM aplikace, riziko LLM09:2025 Misinformation, z rizika LLM05:2025 Improper Output Handling a z dokumentace nástrojů, například Claude Code – Security (stav k 14. 11. 2026). Nejde o právní poradenství. Související: AI programovací asistent – oprávnění a sandbox a Nesprávné zacházení s výstupy LLM.

Aktualizováno: listopad 2026.

Proč je kontrola nutná

OWASP definuje riziko dezinformace (LLM09) takto: model vytváří nepravdivé nebo zavádějící informace, které působí věrohodně. Hlavní příčinou jsou halucinace, tedy obsah, který vypadá správně, ale je vymyšlený. Dopad zhoršuje přílišná důvěra (overreliance), kdy uživatel výstup nekontroluje. U kódu to znamená: funkce, která kompiluje, nemusí dělat to, co má, a knihovna, kterou model doporučí, nemusí existovat nebo nemusí být bezpečná.

Postup kontroly kódu vytvořeného AI v týmu – vlastní infografika

Vymyšlené balíčky a „slopsquatting“

OWASP v kapitole o nebezpečném generování kódu uvádí, že model může navrhovat nebezpečné nebo neexistující knihovny. V jednom z popsaných scénářů útočníci zjistí často halucinované názvy balíčků a pod těmito názvy zveřejní škodlivé balíčky; vývojáři, kteří je nainstalují, tak neúmyslně vnesou malware nebo zadní vrátka. Praxe z toho plyne jednoduchá: každý nový balíček navržený AI ověřte dřív, než jej přidáte do projektu.

Kontrola závislosti:

1. Existuje balíček v oficiálním registru a odpovídá tomu, co model popisuje?
2. Je známý a udržovaný? Stáří, počet verzí, aktivita, autor.
3. Nejde o překlep v názvu populárního balíčku?
4. Licence odpovídá vašim pravidlům?
5. Je opravdu potřeba? Často stačí standardní knihovna.
6. Zafixujte verzi a projděte skenerem zranitelností.

Co hledat při review

• Logika: dělá kód skutečně to, co zadání požaduje, včetně okrajových případů?
• Bezpečnost: vstupy, autentizace, oprávnění, práce s tajemstvími, SQL a příkazy. Viz Nesprávné zacházení s výstupy LLM.
• Zbytečná složitost: AI často přidává kód, který nikdo nepotřebuje.
• Skryté chování: síťová volání, zápis souborů, telemetrie.
• Styl a údržba: odpovídá konvencím týmu? Rozumí mu někdo kromě autora promptu?
• Testy: pokrývají důležité scénáře, nebo jen potvrzují vlastní implementaci?

Mitigace podle OWASP

OWASP u rizika dezinformace doporučuje mimo jiné: zakotvení odpovědí v důvěryhodných zdrojích (RAG), křížové ověřování a lidský dohled, automatickou validaci klíčových výstupů a zavedení postupů bezpečného programování, aby chybné návrhy nevedly ke zranitelnostem. Přenos do praxe: ověřujte proti dokumentaci, používejte statickou analýzu a testy a nenechte AI schvalovat vlastní kód.

Nástroje pomáhají, ale nenahrazují review

Některé nástroje nabízejí kontrolu zabezpečení změn přímo v práci. Dokumentace Claude Code například uvádí příkaz `/security-review`, který spustí bezpečnostní kontrolu změn na aktuální větvi, a plugin, který nechá model zkontrolovat a opravit zranitelnosti ve vlastních změnách. Takové funkce jsou užitečné jako první síto, ale stále platí, že za kód odpovídá člověk a tým; model, který kód napsal, může stejný omyl zopakovat i při kontrole.

Odpovědnost a pravidla v týmu

Tým by měl mít krátká a jasná pravidla:

1. Autor odpovídá za kód, ať jej psal ručně, nebo s AI.
2. AI kód projde stejným review jako lidský; u citlivých částí přísněji.
3. Označujte použití AI v pull requestu, aby recenzent věděl, kde být ostražitý.
4. Nové závislosti schvaluje člověk podle kontrolního seznamu.
5. Tajemství a osobní údaje se do AI nástrojů nevkládají; viz GitHub Copilot content exclusion.
6. Měřte kvalitu: počet chyb, vrácených změn, bezpečnostních nálezů.
7. Školte tým: halucinace, prompt injection, bezpečné závislosti.

Autorská práva a licence

Kód od AI může být podobný existujícímu kódu s licenčními omezeními. Dokumentace některých produktů uvádí detekci chráněného materiálu, ale není k dispozici ve všech scénářích; viz Microsoft Copilot – autorská práva a filtry. U komerčního kódu proto ověřujte licence a v případě pochybností se obraťte na právníka.

Kde najít další informace

Kromě projektu OWASP se vyplatí sledovat NIST AI Risk Management Framework pro řízení rizik a pokyny britského NCSC k bezpečnému používání AI. Konkrétní bezpečnostní nastavení pro svůj nástroj vždy ověřte v aktuální dokumentaci výrobce.

Testování kódu od AI

Testy jsou nejlevnější způsob, jak odhalit chybu. U kódu od AI platí několik zásad. Za prvé, testy pište nebo alespoň důkladně přečtěte sami: pokud model napíše funkci i testy k ní, testy často jen potvrzují jeho vlastní (třeba chybný) výklad zadání. Za druhé, přidejte okrajové případy: prázdné vstupy, příliš velké hodnoty, speciální znaky, časová pásma, souběžný přístup. Za třetí, zkuste záměrně špatné vstupy, protože právě tam se nejčastěji ukáže chybějící validace. Za čtvrté, spouštějte nástroje statické analýzy a skenery zranitelností jako součást průběžné integrace, aby kontrola neprobíhala jen podle chuti jednotlivce. Výsledky testů uložte spolu se změnou, aby bylo později zřejmé, co bylo ověřeno.

Jak zadávat práci asistentovi

Kvalita výstupu závisí i na zadání. Pomáhá, když asistentovi sdělíte jazyk, verzi a omezení projektu, požadavek na ošetření chyb a vstupů a výslovně uvedete, že nemá přidávat nové závislosti bez schválení. Požadujte malé, ověřitelné změny místo rozsáhlých přepisů: čím větší změna, tím hůř se kontroluje a tím víc skrytých chyb se do ní vejde. U delších úkolů si nechte vysvětlit zvolený postup a porovnejte jej s dokumentací. Do promptů nikdy nevkládejte tajné klíče, hesla ani osobní údaje zákazníků.

Zavedení pravidel do týmu postupně

Nové pravidlo funguje, když je jednoduché. Začněte krátkým dokumentem o jedné stránce a šablonou pull requestu s několika otázkami: byla použita AI, byly přidány nové závislosti, jaké testy byly spuštěny, co bylo ručně zkontrolováno. Po několika týdnech vyhodnoťte, co se osvědčilo, a pravidla upravte. Zapojte zkušenější vývojáře jako mentory, kteří nováčkům ukážou, jak číst a zpochybňovat návrhy AI. Hlavním cílem není AI zakázat, ale zajistit, že rychlost, kterou přináší, nebude vykoupena skrytými chybami a bezpečnostními dluhy.

Praktický příklad (smyšlený)

Vývojářka požádá asistenta o knihovnu pro zpracování souborů a ten navrhne balíček s věrohodným názvem. Při kontrole zjistí, že balíček byl zveřejněn teprve před několika dny, nemá dokumentaci a má jediného autora. Použije místo něj standardní knihovnu a v pull requestu označí, že kód vznikl s pomocí AI. Kolega při review nalezne chybějící kontrolu vstupu. Příklad je smyšlený.

Kontrolní seznam – vlastní infografika

Kontrola AI kódu v kostce

Základní údaje – vlastní infografika

Výhody a nevýhody

Souhrn – vlastní infografika

Související články

V kategorii AI v práci, byznysu a programování najdete také Vibe coding a AI programování.

Shrnutí

Kód od AI může být věrohodný, ale chybný. OWASP varuje před dezinformací a před navrhovanými neexistujícími či škodlivými knihovnami, které mohou útočníci zneužít. Každý nový balíček ověřte, kód otestujte a nechte jej projít stejným review jako lidský. Nástroje pro kontrolu zabezpečení jsou pomocníci, ne náhrada. Odpovědnost nese autor a tým. Nejde o právní poradenství.

Často kladené otázky ke kontrole AI kódu