Ještě před několika lety byla odpověď na otázku "kdo napsal tenhle kód?" poměrně jednoduchá. Dalo se ukázat na programátora, tým nebo software house, který odpovídal za konkrétní modul.
Dnes vypadá situace úplně jinak.
Část kódu může vzniknout ručně. Část může vygenerovat Copilot. Další úsek vytvoří programátorský agent. Jiný bude stažen z open source knihovny. Ještě jiný bude externí závislostí balíčku třetí strany. K tomu přibývají API, cloudové služby, hotové komponenty, frameworky a nástroje dodávané dalšími firmami.
Systém funguje. Ale opravdu víte, z čeho byl sestaven?
Kód generovaný AI se neobjevuje ve vakuu
Rozvoj AI nástrojů pro programování nemění jen způsob psaní softwaru. Mění také strukturu odpovědnosti za kód.
Programátor může dnes agentovi zadat úkol a následně získat hotovou funkci, modul, testy, konfiguraci nebo i návrh architektonických změn. Je to obrovské zrychlení práce.
Problém začíná ve chvíli, kdy generovaný kód bereme jako "kód odnikud".
AI totiž nevytváří kód odděleně od celého programátorského ekosystému. Modely jsou trénovány na obrovských souborech dat a vygenerovaný fragment může být podobný existujícím řešením, vzorům nebo veřejně dostupnému kódu. Právě proto je otázka původu kódu, licencí a odpovědnosti čím dál důležitější.
To automaticky neznamená, že každý fragment kódu vygenerovaný AI porušuje něčí licenci. Znamená to však, že organizace využívající AI v procesu vývoje softwaru by měla brát původ a ověřování kódu jako součást inženýrského procesu, nikoli jako právní zajímavost.
To už není jen teorie
16. září 2026 rozhodl Odvolací soud 9. okruhu o části případu Doe v. GitHub, v němž programátoři obviňovali GitHub, Microsoft a subjekty OpenAI mimo jiné z využití veřejně dostupného kódu z GitHubu při tvorbě a trénování nástrojů jako Copilot a Codex.
Jeden z nároků se týkal DMCA a informací o autorských právech. Soud potvrdil zamítnutí této konkrétní námitky. Zároveň však případ zahrnuje i další otázky související s autorskými právy a open source licencemi.
Důležité to není proto, že by jeden rozsudek dával jednoduchou odpověď na otázku "může se používat kód z AI".
Nedává.
Důležitější je, že spor ukazuje širší problém: ve světě AI se hranice mezi kódem napsaným člověkem, kódem vygenerovaným modelem a kódem pocházejícím z existujícího softwarového ekosystému stává čím dál hůře dohledatelnou.
A pro firmy vyvíjející software to znamená nutnost tento proces lépe řídit.
Software supply chain, tedy váš systém má mnohem více "autorů"
V bezpečnosti softwaru se už léta používá pojem software supply chain - dodavatelský řetězec softwaru.
To jsou všechny komponenty, nástroje, knihovny, závislosti a procesy, které se podílejí na vzniku finálního produktu.
NIST v této souvislosti uvádí mimo jiné potřebu řízení původu komponent, kontroly open source závislostí, monitorování zranitelností a používání SBOM, tedy Software Bill of Materials.
SBOM lze ve zjednodušení přirovnat k seznamu ingrediencí produktu.
Neříká jen "máme aplikaci". Ukazuje, jaké komponenty jsou uvnitř.
Například:
- aplikační framework,
- externí knihovny,
- verze jednotlivých balíčků,
- open source komponenty,
- nepřímé závislosti,
- prvky dodávané externími dodavateli.
Díky tomu lze při výskytu zranitelnosti v konkrétní knihovně rychleji zjistit, které systémy ji používají.
NIST také upozorňuje na provenance, tedy možnost dohledat původ softwarových prvků.
A právě tady AI přidává další úroveň složitosti.
Protože do existujícího řetězce přibývá další způsob vzniku kódu.
Představte si typický byznysový systém
40 % kódu napsal tým.
20 % vzniklo s podporou AI.
Další části vygeneroval agent.
Několik knihoven pochází z open source.
Část závislostí přidal framework.
Systém využívá API externího dodavatele.
Jeden komponent pochází z balíčku, který nikdo neaktualizoval dva roky.
A dokumentace závislostí?
Je někde v repozitáři.
Nebo neexistuje.
Systém funguje...
A právě proto je problém neviditelný. Dokud se něco nestane.
A pak se objeví zranitelnost
Předpokládejme, že v jedné z knihoven bude odhalena závažná bezpečnostní chyba.
Otázka zní: Víte, zda váš systém tuto knihovnu používá?
Pokud máte přehledný registr závislostí, může být odpověď otázkou několika minut.
Pokud ne, začne ruční prohledávání repozitářů, kontaktování programátorů, kontrola prostředí, verzí balíčků a nepřímých závislostí.
A teď k tomu přidejme kód vygenerovaný AI.
Je známo, který fragment vznikl pomocí kterého nástroje?
Proběhl code review?
Byl kód pokryt testy?
Byly zkontrolovány závislosti?
Ověřil někdo licenci komponenty?
Je možné zrekonstruovat proces, jehož výsledkem byl konkrétní úsek?
To už nejsou otázky jen pro programátora.
Jsou to otázky týkající se řízení technologického rizika firmy.
Největším problémem není AI. Je jím absence procesu
Bylo by snadné udělat z tohoto článku varování před umělou inteligencí.
Byl by to ale příliš jednoduchý závěr.
AI může výrazně zvýšit produktivitu vývojového týmu.
Problém nastává ve chvíli, kdy firma zvýší tempo produkce kódu, ale současně nezvýší kontrolu nad tímto kódem.
Je to trochu jako kdyby továrna náhle vyráběla desetkrát více součástek, ale nezvýšila kontrolu kvality, evidenci materiálu ani kontrolu dodavatelů.
V software house je ekvivalentem takového kontrolního systému mimo jiné:
- code review
- automatické testy
- scanování závislostí
- SBOM
- monitorování zranitelností
- kontrola open source licencí
- CI/CD s bezpečnostními kontrolami
- správa repozitářů
- dokumentování architektury
- sledování původu komponent
- jasná pravidla pro využívání AI ve vývoji
NIST rovněž upozorňuje na možnost integrovat mechanismy zabezpečení dodavatelského řetězce přímo do CI/CD pipeline.
To je důležitá změna způsobu myšlení.
Bezpečnost by neměla být kontrolou prováděnou až těsně před nasazením.
Měla by být součástí procesu vývoje softwaru.
"Kdo napsal ten kód?" přestává být správnou otázkou
Ve světě tradičního vývoje bylo možné ptát se na autora.
Ve světě AI-assisted development se mnohem důležitějšími stávají otázky:
- Odkud tento komponent pochází?
- Jakou má licenci?
- Kdo ho ověřil?
- Jakou verzi používáme?
- Jaké má závislosti?
- Je stále udržovaný?
- Známe jeho zranitelnosti?
- Dokážeme zrekonstruovat historii změn?
- Ví se, kde se AI podílela na jeho vzniku?
A především:
- Je firma schopna dokázat, že má nad tím vším kontrolu?
Protože zákazník přece nekupuje „kód od AI". Kupuje funkční systém. A odpovědnost za ten systém stále nese organizace, která jej dodává a udržuje.
Kód může být automatický. Odpovědnost ne
To je pravděpodobně jedna z nejdůležitějších změn, které AI přináší do software housů.
Programátor nezaniká. Jeho role se mění.
Stále častěji už nejde jen o napsání určitého počtu řádků kódu. Jde o návrh řešení, kontrolu vygenerovaných částí, hodnocení rizik, testování, integraci, bezpečnost a údržbu celého systému.
Stejně tak se firma nemůže omezit na otázku, zda její programátoři používají AI.
Měla by vědět jak ji používají, v jakém procesu, s jakými kontrolami a jak to ovlivňuje celý životní cyklus softwaru.
Protože za pár let může otázka znít ne: "Kdo napsal ten systém?"
ale: "Dokážeš zrekonstruovat, z čeho a jak byl vytvořen?"
Pokud odpověď zní "ne úplně", problémem není nedostatek dalšího AI nástroje.
Problémem je nedostatek kontroly nad software supply chain.
