Vývojář většinou neotevírá AI asistenta kvůli rebelii proti firemní politice. Chce rychle pochopit cizí funkci, vysvětlit výpis chyby, rozepsat test nebo si nechat načrtnout refaktoring. Když schválený nástroj chybí, zdržuje nebo dává horší odpovědi než osobní účet, část práce se přesune mimo firemní identitu, pravidla a logy.

Riziko začíná u změny v pull requestu, u které tým neví, co model viděl a co z jeho výstupu autor převzal. U běžného vývoje hlídáme commity, soubor se zamčenými verzemi balíčků, CI logy, pravidla pro vlastníky kódu, skeny a historii kontroly. U soukromého AI účtu často zůstane jen změna vložená do editoru.

Zákaz ChatGPT tenhle problém sám nevyřeší. Pokud tým nemá použitelný schválený nástroj a jasná pravidla pro pull requesty, zákaz přesune dotazy z prostředí firmy do soukromých účtů, mobilních aplikací a domácích prohlížečů. Riziko tím zůstane, jen bude hůř vidět.

Zákaz přesune práci jinam

Ve vývoji má shadow AI jasnou podobu. Do neřízeného nástroje může odejít část neveřejného repozitáře, výpis chyby, wiki z firmy, koncový bod API, kus testu nebo popis incidentu z produkce. Firma takový nástroj neřídí, neloguje a nedokáže jej zpětně spojit s commitem, pull requestem nebo incidentem v produkci.

Vývojáři přitom často nesahají po soukromém účtu proto, že chtějí obcházet pravidla. Sahají po něm i tehdy, když schválený postup práci zpomalí a neschválený nástroj dá použitelnou odpověď za minutu.

SonarSource v lednu 2026 uvedl, že napříč deseti nejpoužívanějšími AI nástroji ve vývoji používá 35 % respondentů soukromé účty místo firemních kanálů. U ChatGPT má jít o 52 %. GitLab v červnu 2026 zase uvádí, že 80 % respondentů souhlasí s tím, že jejich organizace nasadila AI nástroje rychleji, než pro ně vytvořila pravidla, a 92 % hlásí problém se správou kódu vytvořeného AI.

Obě čísla je potřeba číst opatrně. SonarSource i GitLab prodávají nástroje pro vývoj a správu kódu, takže nejde o nezávislý obraz provozu ve firemních sítích nebo repozitářích. Přesto dobře ukazují, kam se práce v týmech posunula: AI už přestala být okrajovým doplňkem editoru a část práce s ní probíhá mimo dohled firmy.

Soukromý účet má jiná pravidla pro data

Rozdíl mezi soukromým a podnikovým účtem netvoří jen cena licence. Vývojář může na obrazovce vidět podobné chatovací okno nebo stejný model, ale za ním platí jiná pravidla pro data, práva, správu uživatelů, dobu, po kterou se obsah drží, i audit.

OpenAI u služeb pro jednotlivce uvádí, že obsah může použít k úpravám modelů, pokud si uživatel tuto možnost nevypne v účtu. U podnikových produktů a API naopak deklaruje, že na zákaznických vstupech a výstupech modely ve výchozím režimu netrénuje. Anthropic podobně u komerčních produktů uvádí, že vstupy a výstupy nepoužívá k tréninku modelů, pokud k tomu zákazník nedá souhlas; dokumentace Claude Code navíc rozlišuje, jak dlouho se data drží u spotřebitelských a komerčních účtů.

U Copilotu lze v podnikových plánech nastavit společné zásady a funkce, které soukromý účet obchází. Soukromý účet proto neznamená levnější cestu ke stejnému nástroji. Firma nad ním ztrácí identitu, práva, dobu, po kterou se drží data, audit, seznam povolených funkcí i hranici toho, jaký kód nebo kontext smí model dostat.

Kód musí mít dohledatelný původ

U shadow AI se často mluví hlavně o úniku dat. Pro vývoj je stejně důležitá ztráta původu změny. U kódu vytvořeného nebo upraveného AI musí tým umět odpovědět na několik prostých otázek: odkud návrh přišel, jaký problém měl řešit, jaký kontext model dostal, kdo návrh zkontroloval a kdo za změnu odpovídá v produkci.

GitLab pro tuto schopnost používá výraz AI accountability, tedy odpovědnost za AI v kódu. V jeho průzkumu 43 % respondentů říká, že nedokáže spolehlivě odlišit kód vytvořený AI od lidského, 40 % naráží na roztříštěnou sadu nástrojů a 39 % na systémy, které nesledují původ kódu. Po incidentu se z toho nestane filozofická debata o autorech. Bude to otázka, kdo dostal danou logiku do commitu a podle čeho prošla do produkce.

Soukromé účty selhávají právě tady. Vývojář může vložit výpis chyby, část neveřejného repozitáře nebo neveřejný kontrakt API do svého Claude či ChatGPT účtu, dostat návrh opravy, ručně jej upravit a odeslat do repozitáře. V historii pak zůstane změna. Chybí vstup pro model, odpověď, nástroj i kontext. Často chybí také jistota, zda návrh nevycházel z veřejného kódu s problematickou licencí.

GitHub Copilot má pro část podobných situací kontrolu shod s veřejným kódem a odkazy na zdroje. Pokud Copilot najde podobný veřejný kód, může zobrazit odkaz a informaci o licenci. Taková funkce ale pomáhá jen tam, kde se používá řízený nástroj a kde je příslušná kontrola dostupná a zapnutá. Jakmile návrh vznikne mimo něj, firmě zůstane hlavně kontrola výsledku.

Pull request vrací odpovědnost člověku

AI asistent může rychleji najít varianty, napsat šablonový kód, připravit testy i přečíst cizí kód. Odpovědnost za změnu se tím ale nepřesouvá na nástroj. V repozitáři ji pořád nese autor PR a člověk, který změnu schválí.

Tým nemusí v každém pull requestu zveřejňovat celý dotaz pro model. U citlivějších změn by ale měl umět doložit alespoň tři věci: jaký typ asistence autor použil, jaké vstupy do nástroje šly a co po AI ověřil sám. Krátká poznámka často stačí víc než dlouhý formulář.

AI asistence:
- Použito pro návrh validačních testů a hrubou verzi refaktoringu obslužné funkce.
- Do nástroje nešly zákaznické údaje, logy z produkce ani tajné hodnoty.
- Autor ručně upravil autorizaci a ověřil izolaci tenantů testem.
- Kontroly: jednotkové testy, test integrace s cizím tenant ID, pravidla Semgrepu pro autorizaci.

Taková poznámka neřeší všechno, ale posune průběh kontroly. Schvalující vývojář ví, kde má být opatrnější. Tým pro bezpečnost vidí, že do citlivé části vstoupil generovaný návrh. Autor si musí položit otázku, co vlastně ověřil. A za půl roku, až se kód rozbije, nebude jediným vysvětlením „nějak mi to tehdy vyšlo“.

U běžných změn může být zmínka o AI stručná. Nemá smysl zatěžovat každý PR s doplněným komentářem nebo přejmenovanou proměnnou. Hranice by ale měla být jasná: autorizace, kryptografie, platby, údaje o lidech, incidenty z produkce, migrace dat, SQL generované modelem, změny závislostí a infrastruktura si zaslouží přísnější režim.

Agenti dostávají širší práva

Dokud šlo hlavně o chat v prohlížeči, riziko se dalo popsat jako přenos textu tam a zpět. S programovacími agenty, nástroji v příkazové řádce a přístupem k repozitářům dostává širší práva i samotný AI nástroj. Soukromý asistent už nemusí jen odpovídat na otázky. Může číst soubory, upravovat kód, spouštět příkazy a pracovat s kontextem z firmy, který by do veřejného chatbotu nikdo vědomě neposlal.

Tím se vrací i prompt injection. Britské NCSC v textu Prompt injection is not SQL injection upozorňuje, že u velkého jazykového modelu chybí pevná hranice mezi instrukcí a daty. Model zpracovává obojí jako text, a proto se tenhle problém nedá brát jako obyčejná obdoba SQL injection s jasnou technickou opravou.

Kontroly proto nemají stát na víře v dokonalý filtr. Tým má omezit dopad chyby: logovat vstupy, výstupy i běh nástrojů, navrhovat systém s přijatelným zbytkovým rizikem a nepouštět model k citlivým datům nebo akcím bez dalších hranic. Agent se soukromým tokenem je pro bezpečnostní tým typicky horší než schválený agent s omezenými právy a logy, i kdyby používal stejný model.

Schválený nástroj nestačí bez kontrol v repozitáři

Tým, který chce shadow AI dostat pod kontrolu, potřebuje tři vrstvy. Začněte pravidlem, které vývojář použije při běžné práci: co se do AI nesmí posílat, kdy musí sáhnout po nástroji schváleném firmou a kdy má být AI vidět v pull requestu nebo při incidentu.

Druhá vrstva je schválený nástroj, který lidem pomáhá. Pokud je podniková varianta pomalá, ořezaná nebo hůř dostupná než soukromý účet, část práce uteče jinam. Schválený nástroj má řešit identity, práva, audit, metriky, dobu, po kterou se data drží, a pravidla z jednoho místa. Tyto prvky rozhodují, zda AI patří do řízeného vývoje, nebo zůstane dalším nástrojem vedle editoru, o kterém firma neví.

Vrstva v repozitáři a CI/CD je stejně důležitá. Ani nejlepší podnikový účet nezaručí, že výstup je správný, bezpečný nebo licenčně čistý. NIST v profilu Secure Software Development Practices for Generative AI připomíná, že postupy bezpečného vývoje nemají rozlišovat mezi kódem napsaným člověkem a kódem vytvořeným AI. Veškerý zdrojový kód má před nasazením projít kontrolou kvůli zranitelnostem a dalším problémům. NIST zároveň pracuje s dohledatelným původem jako s údajem, který má být sledován, pokud je známý, a výslovně říká, že vždy známý být nemusí.

V repozitáři se to projeví několika obyčejnými kontrolami. Šablona pull requestu může u netriviálních změn chtít, aby autor napsal, který AI nástroj použil, pokud návrh sáhl do logiky, bezpečnosti, práce s daty nebo běhu produkce. Pravidla firmy mají obsahovat zákaz posílat tajné klíče, zákaznická data, neveřejné kontrakty API a licenčně citlivé části kódu do neschválených služeb. CI má dál spouštět testy, SAST, kontrolu balíčků, kontrolu tajných hodnot a další kontroly kvality bez ohledu na to, zda změnu napsal člověk, Copilot nebo agent. U agentů je nutné samostatně řešit, jaké soubory smějí číst, jaké příkazy smějí spouštět a zda jejich akce zůstávají v auditu.

Co má tým zavést hned

Minimum pro menší tým nemusí být dlouhá politika. Stačí sada pravidel, která se dá použít při běžné kontrole:

• seznam schválených AI nástrojů a režimů, včetně toho, zda smí pracovat s neveřejným kódem;
• klasifikace dat s příklady z vlastního vývoje;
• zákaz posílat tajné hodnoty, tokeny, výpisy z produkce a neanonymizovaná zákaznická data;
• PR pravidlo pro citlivé změny: uvést AI asistenci, rozsah vstupů a co autor sám ověřil;
• kontroly v CI pro bezpečnost, licence, kód i balíčky;
• samostatná pravidla pro agenty: povolené soubory, povolené příkazy, práva tokenů a audit akcí;
• postup pro omylem vložená data, aby se incident netajil ze strachu z trestu.

U větší firmy se přidá SSO, správa účtů, DLP, audit logy, pravidla pro mazání dat, smlouva pro práci s daty, proces pro konektory, metriky z jednoho místa a vazba na SIEM. Ani tam ale nesmí pravidla skončit u nákupu licence. Pokud se AI výstup dostává do pull requestů, musí se objevit i v kontrole kódu.

Firma, která zakáže ChatGPT a dál se tváří, že vývojáři AI nepoužívají, získá hlavně papírovou kontrolu. Reálný pohyb kódu a kontextu jí může dál unikat. Firma, která dá týmům použitelný schválený nástroj, nastaví hranice pro data a přidá kontrolu do vývojového procesu, problém skutečně řeší.

Každé chatovací okno uhlídat nejde. Kód v produkci se ale nesmí dostat do stavu, kdy jeho původ, kontrola a odpovědnost existují jen v paměti člověka, který zrovna odeslal opravu.