Představte si tým šikovných programátorů, kteří bez problému dodají funkční systém v termínu a v rozpočtu. Zákazník spokojený, smlouva splněná. Jenže pak vyjde najevo, že značnou část kódu nevymysleli oni, ale nástroj založený na umělé inteligenci – a nikdo se nezeptal, komu ten kód patří, zda v sobě nenese cizí licence, nebo jestli projde bezpečnostním auditem, který regulátor požaduje. Tahle situace se dnes odehrává v desítkách projektů týdně. Zatímco vývojáři ve velkém používají chytré asistenty pro generování kódu, smlouvy o dílo na to většinou ještě vůbec nereagují.
Tichá revoluce v kódu
U projektů, kde programátoři používají nástroje pro automatické doplňování a generování kódu, dnes umělá inteligence vytváří významnou část výsledného softwaru. U rutinní práce – opakující se části kódu, standardní testy, propojovací „lepidlo“ mezi systémy – je to často větší část. Přesto valná většina smluv o dílo či rámcových smluv o vývoji softwaru tuto realitu ignoruje. Text smlouvy popisuje dílo jako výsledek tvůrčí práce vývojáře, hovoří o autorských právech dodavatele a garantuje právní bezvadnost kódu, aniž by kdokoliv zkoumal, co přesně napsal člověk a co vygeneroval nástroj.
Kdo tedy odpovídá, když se u takového projektu objeví bezpečnostní zranitelnost pocházející z automaticky vygenerované části kódu? Nebo když se ukáže, že část kódu obsahuje pasáže z otevřeného softwaru, který je šířený pod licencí vyžadující za určitých podmínek zveřejnění celého zdrojového kódu? Tyto otázky smlouva často nezodpovídá, protože tyto situace ještě před pár měsíci či lety neexistovaly.
Regulace přišla. Smlouvy ne.
Nové evropské nařízení o umělé inteligenci klasifikuje systémy umělé inteligence podle míry rizika a ukládá odlišné povinnosti těm, kdo je vyvíjejí, a těm, kdo je nasazují do svých procesů. V praxi to znamená, že zákazník, který nasadí software s prvky umělé inteligence (ať jde o systém pro hodnocení bonity klientů, náborový nástroj, nebo jiné řešení s automatizovaným rozhodováním) nese jako provozovatel konkrétní regulatorní odpovědnost.
K tomu přistupují požadavky kybernetické bezpečnosti (zákon o kybernetické bezpečnosti, evropská směrnice pro bezpečnost sítí a informací) a ve finančním sektoru i pravidla DORA pro vztahy s dodavateli ICT služeb. Všechny tyto vrstvy se potkávají právě v místě, kde se kód vytvořený s pomocí umělé inteligence dotýká produkčního systému zákazníka. Téma přestává být pouhým obchodním rizikem a stává se otázkou regulatorní povahy s velmi konkrétními následky při kontrole nebo bezpečnostním incidentu. Z problému „mohlo by se něco stát“ se stává otázka „kdy se něco stane a kdo za to zaplatí“.
Kód bez autora a s dvojitým rizikem
Autorský zákon chrání počítačový program jako dílo tehdy, je‑li výsledkem vlastního duševního výtvoru svého tvůrce. Čistě strojově generovaný kód – tedy situace, kdy programátor zadá pokyn (prompt), ale dál výstup nijak tvůrčím způsobem nerozvíjí ani architektonicky nezačlení – tuto podmínku zpravidla nesplňuje. Česká judikatura se k otázce autorství výstupů generovaných umělou inteligencí teprve formuje. Trend je však zřejmý: bez dostatečného lidského tvůrčího příspěvku autorské právo nezasáhne.
Co to znamená pro klasický smluvní model? Dodavatel slibuje převod autorských práv k dílu – ale k čemu přesně? Část kódu možná pod autorský zákon vůbec nespadá. Zákazník pak formálně nezíská práva, o nichž se domnívá, že je kupuje. Z pohledu práva jde u takového kódu často o „bezprizorní“ materiál, který může další osoba bez souhlasu převzít a použít.
Zároveň nástroje pro generování kódu byly trénovány na obrovském množství veřejně dostupného kódu, včetně projektů pod tzv. copyleft licencemi – to jsou licence, které v určitých situacích požadují, aby byl odvozený kód opět šířen jako otevřený. Pokud nástroj takový kód částečně reprodukoval nebo z něj vycházel, může zákazník nevědomky provozovat software porušující práva třetích stran. Dodavatel přitom často ani neví, co přesně generátor kódu „použil“, vidí jen výsledek. Jen malá část dodavatelů nástrojů umělé inteligence dnes nabízí skutečné smluvní odškodnění za případné spory o duševní vlastnictví – většina riziko zcela logicky přenáší na uživatele prostřednictvím výluk a limitů odpovědnosti.
Výsledkem je dvojité riziko. Na jedné straně kód, který možná nikomu autorsky nepatří a může ho kdokoliv kopírovat. Na druhé straně kód, který může náležet někomu jinému a jeho provozováním se porušují cizí práva. Obě varianty navíc mohou existovat současně a smlouva na ně většinou nepamatuje.
Trojúhelník, kde hoří
Největší slepé místo dnešní praxe je z našeho pohledu vztah mezi vývojářem, dodavatelem a odběratelem – přesněji tři vrstvy smluvních vztahů, které nejsou vzájemně sladěné a často si fakticky „nevidí do kuchyně“.
Smlouva mezi dodavatelem a odběratelem o použití nástrojů umělé inteligence zpravidla mlčí. Dodavatel garantuje funkční a právně bezvadný kód, ale neuvádí, jaké nástroje při vývoji používá ani jaká pravidla pro jejich použití dodržuje. Zákazník pak ani neví, co přesně si kupuje.
Interní vztah mezi dodavatelem a jeho programátory – ať už jde o zaměstnance, nebo poddodavatele – tuto oblast často neupravuje vůbec. Vývojáři používají generátory kódu podle vlastního uvážení, bez povinného dvoustupňového code review, bez logování zadání a výstupů, bez systematické kontroly licencí. Podmínky samotného nástroje pro generování kódu navíc obsahují omezení a výluky odpovědnosti, které dodavatel buď nečetl, nebo je ignoroval, nebo je zcela určitě nesladil s tím, co zákazníkovi slibuje v hlavní smlouvě.
Z toho plyne sada otázek, na které jednoduché odpovědi neexistují. Kdo vlastní kód vytvořený s pomocí umělé inteligence a může ho dále rozvíjet? Kdo odpovídá za porušení licencí třetích stran a za bezpečnostní chyby? Má dodavatel povinnost zákazníkovi přiznat, že část kódu vznikla tímto způsobem? Jak realisticky nastavit záruku právní bezvadnosti, když ani poskytovatel nástroje pro generování kódu sám plnou ochranu neposkytuje?
Co zvážit už v příští smlouvě
Čekat na ustálenou judikaturu nebo na to, až trh sám vytvoří jednotný standard, je pohodlná, ale pravděpodobně nákladná strategie. Namísto čekání považujeme za vhodnější řadu věcí minimálně zvážit a ideálně rovnou už dnes:
1. Otevřené přiznání použitých nástrojů
Smlouva by měla výslovně zavázat dodavatele k oznámení, jaké nástroje založené na umělé inteligenci při vývoji používá, včetně základního popisu jejich licenčních podmínek a rozsahu ochrany v oblasti duševního vlastnictví. Zákazník pak alespoň ví, s jakými riziky pracuje, a může na ně reagovat ve vlastní interní politice pro používání umělé inteligence.
2. Povinné procesy – bezpečnost a licence jako součást vývoje
Vedle běžného řízení vývoje by měl existovat i proces zaměřený na bezpečnost (často označovaný jako DevSecOps) a na licence (někdy se používá termín DevLicOps – tedy systematická kontrola licencí u všech součástí kódu, včetně toho generovaného nástrojem). Smlouva by měla tyto procesy popsat a učinit z nich závazek (logování zadání a výstupů, skenování kódu na možné licenční kolize, povinné review u kritických částí systému). Bez auditní stopy je jakékoliv smluvní ujištění v případě sporu jen těžko obhajitelné.
3. Jasné vymezení práv k výstupům
Smlouva by měla výslovně stanovit, komu náleží práva k výslednému kódu bez ohledu na způsob jeho vzniku (zda ho napsal člověk, nebo nástroj) a kdo vůči komu poskytuje odškodnění za nároky třetích osob z porušení práv. Způsob vzniku kódu nesmí být záminkou ke zúžení původně sjednaného rozsahu licence.
4. Sjednocení tří vrstev vztahů
Podmínky nástroje umělé inteligence, smlouva mezi dodavatelem a odběratelem a interní politika odběratele k používání umělé inteligence musí být vzájemně konzistentní. Dodavatel nesmí zákazníkovi slibovat více práv, než mu sám poskytovatel nástroje dovoluje převést; zákazník si musí ověřit, zda jeho interní pravidla odpovídají tomu, co od dodavatele ve smlouvě požaduje.
5. Záruka procesů místo iluze dokonalého výsledku
Absolutní záruka bezchybného a právně bezvadného kódu je v době masového používání nástrojů pro generování kódu nerealistická. Rozumnější přístup je garantovat standardy a postupy (bezpečnostní testování, pravidelné audity, přehledné řízení používání umělé inteligence ve vývoji). Odpovědnost za dodržení procesů je vymahatelná; odpovědnost za dokonalost výstupu nástroje spíše nikoliv.
Pokud se vás toto téma týká – ať jako odběratele připravujícího nové IT smlouvy, jako dodavatele hledajícího rozumné vymezení vlastní odpovědnosti, nebo jako in‑house právníka, jehož firma teprve nastavuje pravidla pro používání umělé inteligence při vývoji – rádi vám s tím pomůžeme. Máme zkušenost s kombinací právního, regulatorního i technického pohledu: od revize smluvní dokumentace a nastavení governance umělé inteligence až po sladění interních politik s požadavky evropské regulace, kybernetické bezpečnosti a sektorových předpisů. Nejlevnější spor je ten, který vůbec nevznikne, přičemž první krok k tomu je podívat se na aktuální smlouvy a procesy dřív, než se stanou důkazním materiálem v soudním řízení.
