Srozumitelný přehled toho, co dvě evropské regulace znamenají pro týmy dodávající AI-asistovaný kód podnikovým klientům — a proč se prokazování, že byl kód zkontrolován, stává součástí obchodu.
Toto je obecný přehled, ne právní poradenství — pro své konkrétní povinnosti podle CRA/NIS2 se poraďte s kvalifikovaným právníkem.
Kódovací agenti dnes generují významnou část kódu, který softwarové agentury dodávají. Výzkum porovnávající AI-asistovaný a lidmi psaný kód zjistil, že kód generovaný AI má přibližně 1,9–2,7× vyšší pravděpodobnost obsahovat zranitelnost. Část tohoto rizika je strukturální: AI modely někdy vymyslí věrohodně vypadající názvy balíčků, které neexistují — a útočníci začali registrovat přesně tyto názvy, což je útok na dodavatelský řetězec známý jako slopsquatting. Zároveň přicházejí dvě evropské regulace, které vkládají povinnosti zabezpečení dodavatelského řetězce přímo do obchodních smluv.
Evropský Cyber Resilience Act zavádí povinnosti hlášení zranitelností postupně od 11. září 2026, s plnou účinností od 11. prosince 2027.
Software vytvořený výhradně pro jednoho konkrétního zákazníka se obecně nepovažuje za „uvedený na trh“ — takže spadá mimo přímé povinnosti výrobce podle CRA (CE značení atd.) pro agenturu, která ho vytvořila. Jakmile je ale tento kód integrován do produktu klienta, klient zůstává odpovědný za všechny integrované komponenty a musí konsolidovat SBOM a technickou dokumentaci dodavatelů. V praxi se povinnost k agentuře dostává smluvně, přes klientův program shody — ne jako vlastní povinnost CE značení agentury.
Článek 21 NIS2 vyžaduje, aby organizace v působnosti směrnice řídily kybernetické riziko ve svém dodavatelském řetězci — a aby tento požadavek promítly do svých přímých dodavatelů prostřednictvím smluvních doložek. Pro softwarovou agenturu to znamená, že klienti, kteří sami spadají pod NIS2 (jak jejich stát směrnici transponuje do zákona), začínají požadovat smluvní doložky pokrývající bezpečnostní opatření, hlášení incidentů a auditní práva. To se k dodavatelům dostává už teď, před vlastními termíny CRA.
Dodavatel dnes obvykle prokazuje bezpečnost jedním ze dvou způsobů. Organizační certifikace — ISO 27001, SOC 2 — potvrzují, že firma má proces; neříkají nic o tom, zda byla zkontrolována konkrétní dodávka. Vlastní vytvořené artefakty — export PDF ze SonarQube nebo Snyk, zpráva z penetračního testu — jsou platné k jednomu okamžiku a lze je dodatečně upravit stranou, která má něco dokazovat. Nástroje pro provenance buildů (SLSA, in-toto, Sigstore) řeší problém kryptografické neporušitelnosti, ale jde o bezplatné nástroje určené vývojářům, podepsané samotným build systémem — nejsou zabalené jako důkaz, který si netechnický zástupce klienta otevře a uvěří mu.
Mezeru, kterou tyto tři přístupy nechávají otevřenou, vyplňuje doklad k jednotlivé dodávce — odolný proti manipulaci, nezávisle ověřitelný a vázaný na konkrétní okamžik, kdy byl (často AI napsaný) kód zkontrolován. Něco, co klient otevře bez účtu, ověří bez nutnosti věřit slovu dodavatele, a založí vedle SBOM, který jeho vlastní program shody už stejně vyžaduje.
Bezplatný, bezúčtový nástroj Graneth pro MCP (pre_flight_check) kontroluje kód generovaný AI na halucinované/slopsquattované balíčky a natvrdo zapsané tajné klíče ve chvíli, kdy je váš agent píše. Každý dokončený sken může vytvořit podepsaný, veřejný doklad o skenu — odkaz, který klient otevře a uvidí, že konkrétní dodávka byla zkontrolována, aniž by musel věřit vašemu slovu.
Důležité: doklad o skenu prokazuje, že kód byl zkontrolován — neprokazuje, že je kód bezpečný, a není certifikací shody s CRA ani NIS2. Shoda je právní posouzení pro vás a vašeho právníka; Graneth poskytuje jeden díl technického důkazu, který do té diskuze můžete přinést.
Toto je obecný přehled, ne právní poradenství — pro své konkrétní povinnosti podle CRA/NIS2 se poraďte s kvalifikovaným právníkem.