Kodex transparentnosti AI: co ověřit u podpisu dodavatele

Proč podpis kodexu sám o sobě nestačí

Při výběru dodavatele se často objeví věta, že dodavatel podepsal kodex transparentnosti. V praxi to může znamenat různé dokumenty, různé signatáře i různý rozsah pokrytých systémů. Pro první posouzení proto podpis chápe jen jako vstupní signál, nikoli jako důkaz, že konkrétní nasazovaný systém plní informační opatření vůči uživatelům. Podle Q&A Evropské komise k transparentnosti platí doložený fakt, že kodex transparentnosti je dobrovolný nástroj a není totožný s kodexem pro GPAI; samotné nepřihlášení neznamená porušení a soulad lze prokazovat i jinými prostředky.

Z toho plyne pracovní závěr pro nákup: ptejte se vždy na přesný kodex, nikoli na kodex obecně. Ověřte datum verze, identitu signatáře, seznam systémů a způsob, jak dodavatel dokládá opatření v reálném provozu. Pokud chcete nejprve ukotvit informační povinnosti v širším kontextu označování výstupů, projděte si výklad k označování obsahu podle článku 50. Teprve potom má smysl hodnotit samotný podpis.

Poskytovatel a provozovatel: koho se podpis týká

Rozlišení rolí je pro kontrolu podpisu zásadní. Při pracovním posouzení určete poskytovatele podle toho, zda systém vyvinul či objednal jeho vývoj a uvedl jej pod vlastní značkou či jménem. Provozovatele posuzuje podle toho, kdo systém používá v rámci své pravomoci; konkrétní odpovědnost za informační opatření je třeba ověřit samostatně. Smluvní označení dodavatele ani pouhá změna promptu samy o sobě právní roli neurčují.

V dotazníku proto trvejte na odpovědi, zda signatář kodexu je totožný s vaším smluvním dodavatelem a zda kryje právě tu verzi systému, kterou budete provozovat. Častou možnou chybou je situace, kdy kodex podepsala mateřská společnost, ale český dodavatel dodává upravenou integraci s vlastním označením. V takovém případě žádejte písemné vysvětlení, kdo odpovídá za informační prvky v uživatelském rozhraní, v nápovědě a v exportech.

Dotazník přesného kodexu v šesti bodech

Tento postup je doporučenou praxí CIAD, nikoli popisem zákonné povinnosti. Použijte jej jako součást před-smluvního prověření a odpovědi si nechte potvrdit e-mailem nebo přílohou nabídky. Nepřebírejte tvrzení o souladu bez důkazu a neuvádějte neověřená jména signatářů z veřejných seznamů.

1. Přesná identifikace: název kodexu, verze, datum podpisu a odkaz na text, ke kterému se signatář hlásí.
2. Signatář: právnická osoba, IČO nebo zahraniční identifikátor a vztah k vašemu dodavateli.
3. Pokryté systémy: obchodní název, verze modelu nebo aplikace, způsob nasazení a výjimky.
4. Opatření: jak je uživatel informován o interakci se systémem AI, kde se informace zobrazuje a v jakém jazyce.
5. Důkazy: snímky rozhraní, ukázka označení výstupu, popis logování a kontaktní osoba za transparentnost.
6. Změny: jak dodavatel oznamuje změnu systému, která může ovlivnit informační opatření, a jak se změna promítne do smlouvy.

Pokud dodavatel odkáže na alternativní prostředky místo kodexu, žádejte stejných šest bodů. Pro přípravu smluvních požadavků využijte návod pro zadání pro nákup firemní AI.

Vyplnitelná karta důkazů pro konkrétní systém

Kartu zkopírujte do e-mailu dodavateli nebo do hodnoticího archu. Každý řádek vyžaduje stručnou odpověď a odkaz na důkaz. Prázdné pole berte jako nedoložené tvrzení, nikoli jako formální nedostatek.

Doporučujeme vyplněnou kartu archivovat k nabídce. Usnadní pozdější kontrolu, zda dodaná verze odpovídá verzi hodnocené. Při porovnání více nástrojů ji spojte s širšími kritérii v postupu jak vybrat AI nástroj pro firmu, aby transparentnost nebyla hodnocena odděleně od podpory, bezpečnosti a správy.

Hypotetický příklad vyhodnocení jedné nabídky

Následující příklad je zcela ilustrativní a hypotetický, neslouží jako popis reálného dodavatele. Firma poptává asistenta pro přípravu odpovědí klientům. Dodavatel A uvádí podpis kodexu transparentnosti, dodavatel B podpis neuvádí, ale dokládá vlastní opatření.

Dodavatel A doloží kodex ve verzi 1.0, signatářem je zahraniční mateřská společnost. Pokrytý systém je obecný model, nikoli konkrétní česká integrace verze 2.4, kterou nabízí. Screenshoty ukazují anglické oznámení v administrátorském režimu, nikoli v klientském chatu. Výsledek karty: 2 ze 6 bodů doloženy, pokrytí systému neprokázáno.

Dodavatel B předloží popis informační lišty v češtině, ukázkový export s označením návrhu AI a závazek hlásit změny rozhraní do 10 pracovních dnů jako smluvní ujednání. Výsledek karty: 3 ze 6 bodů doloženy alternativními prostředky. Závěr příkladu: přesný výsledek je, že vítězem hypotetického hodnocení je dodavatel B, přestože kodex nepodepsal.

Omezení kontroly a navazující krok

Tato karta ověřuje pouze tvrzení o kodexu a doložená opatření, nikoli celkový soulad systému s právem. Neprokazuje funkčnost v budoucích verzích, nezaručuje soulad a nenahrazuje právní posouzení. Možnou chybou zůstává neúplný testovací přístup, zastaralý screenshot nebo změna rozhraní po podpisu smlouvy.

Navazující krok doporučené praxe CIAD je proto věcný: přeneste identifikaci systému, popis informačního prvku a oznamování změn do přílohy smlouvy a stanovte vlastníka kontroly na své straně. Při aktualizaci systému vyžádejte nové potvrzení pokrytí a novou ukázku označení. Tak zůstane podpis kodexu užitečným kontextem, ale rozhodovat budou konkrétní důkazy pro vaši verzi a vaše uživatele.