Euforie je do určité míry pochopitelná. Jenže ve stejnou dobu, kdy se AI stává standardní součástí vývojového workflow, zůstávají v platnosti pravidla, která podnikové IT dobře zná: řízení přístupů, trasovatelnost změn, auditovatelnost, správa zranitelností, bezpečnost dodavatelského řetězce a odpovědnost za provozní dopad změn.

DORA se začala uplatňovat od ledna 2025, NIS2 měla být transponována do národních právních řádů do října 2024 a Cyber Resilience Act postupně zavádí nové povinnosti pro produkty s digitálními prvky. CRA vstoupil v platnost v prosinci 2024, reportingové povinnosti začnou platit od září 2026 a hlavní povinnosti od prosince 2027.

Tyto předpisy nejsou napsány jako regulace vývoje AI. Přesto dopadají na prostředí, ve kterém AI začne zasahovat do tvorby, testování, nasazování a provozu softwaru. A právě tady vzniká nový problém: AI může výrazně zrychlit vývoj, ale nezbavuje firmu odpovědnosti za to, jak software vznikl a jak se dostal do produkce.

Jedna z častých mylných představ je, že compliance se týká především výsledného kódu. Ve skutečnosti jde často o celý proces: kdo měl ke změně přístup, jaké kontroly proběhly, jak bylo schváleno nasazení, jak se řídí privilegované přístupy a zda je možné celý postup zpětně doložit.

Auditor se nebude spokojovat s tvrzením, že „kód prošel týmem“. Bude chtít vidět trasovatelnost změny od požadavku přes commit, review, testy, bezpečnostní kontroly až po nasazení. U kritických nebo regulovaných systémů bude důležité i to, kdo mohl deployovat do produkce, podle jakých pravidel, s jakým schválením a jak byla změna zaznamenána.

CRA do toho přidává důraz na bezpečnostní proces v celém životním cyklu produktu, včetně práce se zranitelnostmi a komponentami softwarového dodavatelského řetězce. Evropská komise k CRA výslovně uvádí, že požadavky se týkají plánování, návrhu, vývoje i údržby produktů s digitálními prvky.

Otázka tedy nezní jen: „Je výsledek bezpečný?“

Stejně důležitá je otázka: „Umíme doložit, jak vznikl?“

Problém není v AI samotné. Problém je v tom, jak se dnes často používá.

Ve firmách se opakuje podobný vzorec. Vývojáři začnou používat nástroje jako GitHub Copilot, Cursor nebo různé LLM asistenty mimo standardizovaný vývojový proces. Kód vzniká rychleji, ale někdy mimo jasně řízený kontext: mimo jednotné šablony, mimo standardní kontrolu závislostí, mimo bezpečnostní pravidla nebo bez dostatečné vazby na původní požadavek.

Výsledek může být funkční. Zároveň ale může být těžší zpětně vysvětlit, proč bylo zvoleno konkrétní řešení, kdo ho fakticky navrhl, kdo ho ověřil a zda prošlo stejnou úrovní kontroly jako kód psaný tradičním způsobem. To není problém, který vyřeší lepší jazykový model. Je to problém governance.

Gartner v roce 2025 uvedl, že přes 70 % IT lídrů řadí regulatorní compliance mezi tři největší výzvy při zavádění GenAI nástrojů a jen 23 % si je velmi jistých svou schopností řídit bezpečnostní a governance aspekty jejich nasazení. To odpovídá realitě, kterou v podnicích vidíme: AI nástroje se zavádějí rychleji než pravidla, která mají jejich použití řídit.

 

Prvním rizikem je ztráta trasovatelnosti. Pokud změny vznikají mimo řízený proces, je obtížné spolehlivě doložit, odkud přišly, kdo je schválil a jaké kontroly proběhly. To je problém zejména v prostředích, kde se očekává auditovatelný change management.

Druhým rizikem je nekontrolovaný vstup zranitelností. AI může navrhnout kód, knihovny nebo konfigurační změny, které působí správně, ale obsahují zastaralé vzory, nevhodné závislosti nebo bezpečnostní slabiny. Pokud výstup neprochází automatickou kontrolou, vzniká riziko ve chvíli, kdy se rychle vygenerovaný kód stane součástí produkčního systému.

Třetím rizikem je rozostření odpovědnosti. Pokud každý tým nebo každý vývojář používá jiný AI nástroj, jiný způsob práce a jinou míru kontroly, bezpečnost přestává být systémovou vlastností. Stává se závislou na individuální disciplíně jednotlivců. To může fungovat u malého týmu, ale v regulovaném enterprise prostředí je to dlouhodobě neudržitelné.

Odpovědí na tato rizika není návrat k ručnímu psaní každého řádku kódu. AI ve vývoji nezmizí. Bude se zlepšovat a bude se používat stále více. Správná otázka tedy nezní, zda AI povolit nebo zakázat. Správná otázka zní, jak ji dostat do standardizovaného workflow, kde pro její výstupy platí stejná pravidla jako pro jakýkoliv jiný kód.

To znamená, že každý commit prochází statickou analýzou, kontrolou závislostí, bezpečnostními pravidly a testy. Nasazení do produkce probíhá přes řízenou pipeline, ne přes ad hoc výjimku. Přístupy jsou řízeny centrálně, ne individuálně. Schválení je zaznamenáno a auditní stopa od požadavku po produkci je dohledatelná bez ruční rekonstrukce ze Slacku, e-mailů a Confluence stránek.

Platformy, které toto umožňují, nedělají nic magického. Standardizují to, co by každý dobře řízený tým měl dělat, ale co se při tlaku na rychlost často rozpadá: jednotné workflow, řízené prostředí, opakovatelné kontroly, auditní stopu a jasnou odpovědnost. S příchodem AI se tento problém jen zrychluje. Pokud byl proces nečitelný před AI, bude po jejím zavedení nečitelný rychleji.

Stále přetrvává představa, že governance vývojáře brzdí. Ve skutečnosti vývojáře brzdí špatně implementovaná governance: manuální schvalovací procesy, ručně vyplňované formuláře, nejasná pravidla a bezpečnostní kontroly závislé na jednom přetíženém člověku.

Dobře nastavený model funguje jinak. Security a platformní týmy definují pravidla jednou. Vývojové týmy se pak pohybují v prostředí, kde jsou tato pravidla automaticky vynucována při buildu, testování, nasazení i změně konfigurace. Vývojář nemusí pokaždé znovu zjišťovat, zda postupuje správně. Pokud změna prošla definovanou pipeline, splnila požadované kontroly. To šetří čas, snižuje počet výjimek a omezuje prostor pro chyby. Výsledkem není pomalejší vývoj. Výsledkem může být vyšší rychlost: méně manuálních kontrol, méně čekání na schválení, méně rozdílů mezi týmy a méně incidentů způsobených tím, že každý pracuje trochu jinak.

A v regulovaných odvětvích se k tomu přidává ještě jedna výhoda: schopnost doložit, že firma má vývojový proces pod kontrolou. To už není jen interní auditní téma. Stává se to součástí obchodního rozhovoru se zákazníky, partnery i regulátory.

AI vývoj zrychluje a tento trend se nezastaví. Firmy budou generovat více kódu, rychleji připravovat změny a postupně zapojovat AI nejen jako asistenta jednotlivce, ale i jako aktivní součást delivery procesu. To je příležitost. Ale pouze tehdy, pokud se rychlost nepotká s chaosem.

Firmy, které AI zasadí do řízeného vývojového procesu, získají dvojí výhodu: rychlost, kterou AI přináší, a důvěryhodnost, kterou regulované prostředí vyžaduje.

Firmy, které to neudělají, budou rychle generovat změny, které později nedokážou jednoduše doložit. A to je přesně typ problému, který se neobjeví hned při prvním demu. Objeví se až při auditu, incidentu nebo zákaznickém due diligence. V tu chvíli už nejde o produktivitu vývojářů. Jde o schopnost firmy prokázat, že ví, co se v jejím software delivery procesu skutečně děje.