Proč se role poskytovatele a provozovatele ve smlouvách pletou
V praxi jedna firma systém koupí, druhá ho napojí na data a třetí ho reálně používá. Obchodní smlouva přitom často mluví jen o „dodavateli“ a „odběrateli“, takže není jasné, kdo odpovídá za nastavení, kontrolu výstupů, informování lidí a řešení incidentu. Obecný rámec pro toto rozlišení shrnuje přehled AI Act, samotné rozdělení ale musíte udělat pro konkrétní nasazení.
Problém vzniká hlavně u úprav. Zákazník požádá o napojení na interní databázi, integrátor doladí prompty nebo přidá vlastní filtr a uživatelé začnou výstupy používat jinak, než se původně plánovalo. Pokud smlouva nepopisuje, kde končí standardní produkt a kde začíná vaše konfigurace, těžko určíte, kdo měl chybu odhalit. Proto mapa rolí není formalita, ale pracovní nástroj pro přidělení úkolů a důkazů.
Doložený fakt je úzký: Evropská komise vysvětluje, že vlastní značka a uvedení systému do provozu zakládá jinou roli než používání systému pod vlastní autoritou, přičemž zaměstnanec jednající pod autoritou firmy není automaticky samostatný provozovatel. Podrobnosti k výkladu uvádí odpovědi Komise k transparentnosti podle článku 50. Vše ostatní v tomto článku je doporučená interní praxe CIAD, nikoli výklad doložené povinnosti.
Kupující, výrobce a integrátor nejsou totéž co role v AI
Obchodní role a role pro odpovědnost se překrývají jen částečně. Výrobce může být poskytovatelem. Zda změna systému ovlivní role a povinnosti původního výrobce nebo integrátora, závisí na konkrétních okolnostech; u vysoce rizikového systému mohou být relevantní pravidla pro podstatnou změnu. Označení „spolutvůrce“ samo o sobě právní roli neurčuje. Kupující je typicky provozovatelem, pokud systém používá pod vlastní autoritou; účel a okolnosti nasazení jsou důležité pro posouzení konkrétní role.
Pro smlouvu si proto oddělte tři otázky. Kdo systém vytvořil a pod čí značkou se dodává. Kdo ho upravil, napojil a uvedl do provozu v konkrétním prostředí. Kdo ho denně používá, schvaluje výstupy a rozhoduje o důsledcích. Teprve na tyto tři odpovědi navěšte povinnosti, jako je dokumentace, školení, dohled člověka a hlášení problémů. Jak vypadá každodenní stránka provozu, popisují povinnosti firmy, která AI používá.
Praktické pravidlo: pokud druhá strana pouze instaluje systém podle pokynů výrobce, popište její úkoly jako instalační a podpůrné. Pokud mění účel, datové zdroje, prahy rozhodnutí, bezpečnostní filtry nebo propojení s jinými systémy, zaznamenejte změnu a odpovědnost za ni; její právní dopad posuďte podle konkrétního systému a okolností. Nespoléhejte na název pozice ve smlouvě, rozhoduje faktická činnost.
Rozhodovací karta: určete roli v pěti krocích
Tuto kartu projděte pro každé nasazení zvlášť, ne pro celou firmu obecně. Odpovídejte ano nebo ne a výsledek zapište do další tabulky.
- Dodáváme systém pod vlastní značkou nebo vlastním obchodním jménem. Pokud ano, pracujte s hypotézou role poskytovatele a prověřte ji ve smlouvě.
- Systém fakticky uvádíme do provozu u zákazníka, včetně prvního nastavení a předání do rutinního používání. Pokud ano, zapište odpovědnost za uvedení do provozu.
- Systém používáme pod vlastní autoritou. Pokud ano, pracujte s hypotézou role provozovatele a zaznamenejte také účel a okolnosti jeho nasazení.
- Měníme model, trénovací data, účel, napojení, filtry nebo způsob dohledu nad rámec návodu výrobce. Pokud ano, popište změnu jako samostatný řádek odpovědnosti.
- Výstupy používá zaměstnanec pouze podle pokynů firmy, bez vlastního určování účelu. Pak ho nezapisujte jako samostatného provozovatele, ale jako uživatele v rámci firmy.
Pokud vyjdou kladně body 1 i 3 u různých stran, máte typický řetězec s poskytovatelem a provozovatelem. Pokud vyjde kladně bod 4 u integrátora nebo zákazníka, popište ve smlouvě provedenou změnu a rozdělte odpovědnosti za navazující úkoly; samotná změna zde automaticky neurčuje právní roli strany.
Smluvní mapa k vyplnění: kdo dělá co a čím to doloží
Následující tabulku zkopírujte do smlouvy nebo její přílohy a vyplňte konkrétními jmény, systémy a termíny předání. Doporučená interní praxe je vyplnit ji vždy, doloženou povinnost pro konkrétní systém posuzujte podle jeho funkce a rizik.
| Oblast | Odpovědná strana | Konkrétní úkol | Důkaz a předání |
|---|---|---|---|
| Identita a účel | doplnit | Popis systému, verze, obchodní název, účel nasazení | Příloha s technickým popisem |
| Vývoj a značka | doplnit | Kdo systém vytvořil a pod čí značkou se dodává | Prohlášení výrobce, číslo verze |
| Integrace a data | doplnit | Napojení na data, prompty, filtry, přístupová práva | Protokol o nastavení a testech |
| Uvedení do provozu | doplnit | Kdo provedl první nasazení a zaškolení | Předávací protokol, prezenční listina |
| Běžný provoz | doplnit | Kdo schvaluje výstupy a kdy je nutný člověk | Pracovní postup, log schválení |
| Informování lidí | doplnit | Kdo a jak informuje dotčené osoby o použití AI | Text oznámení, místo zveřejnění |
| Monitoring a incidenty | doplnit | Kdo sleduje chyby, komu se hlásí, kdo zastaví provoz | Kontakty, lhůta pro hlášení, záznam incidentu |
| Změny a nové verze | doplnit | Kdo smí měnit nastavení a kdo změnu schvaluje | Změnový požadavek, nová verze mapy |
Nevyřešená odpovědnost je každá prázdná buňka. Zvlášť si hlídejte informování lidí, lidský dohled a postup při zastavení systému. Právě tam smlouvy nejčastěji odkazují na „součinnost“, aniž by určily vlastníka úkolu. U sporu o škodu pak pomůže i jasné rozdělení rolí popsané v textu kdo odpovídá za chybu AI, ale nenahrazuje tuto konkrétní mapu.
Ilustrativní příklad: interní asistent pro přípravu podkladů
Příklad je zcela hypotetický a slouží jen k ukázce vyplnění mapy, nikoli jako popis reálného nasazení.
Hypotetická firma Beta si kupuje jazykový systém od výrobce Gama. Integrátor Delta ho napojí na interní směrnice, nastaví role uživatelů a přidá filtr, který blokuje předávání osobních údajů do shrnutí. Beta používá asistenta pro přípravu podkladů pro mzdové účetní; konečné podklady vždy schvaluje pověřená personalistka.
Výsledek mapy: Gama je zapsána jako strana odpovědná za vývoj a popis standardního produktu včetně verze 3.2. Delta je zapsána jako odpovědná za integraci, filtr a předávací protokol ze dne 12. března. Beta je zapsána jako provozovatel, protože asistenta používá pod vlastní autoritou pro vlastní proces. Personalistka není samostatný provozovatel, je uživatelem v rámci Bety. Beta vlastní schvalování výstupů, měsíční kontrolu deseti náhodných shrnutí a zastavení provozu při třech chybných shrnutích v jednom týdnu.
Přesný výstup příkladu: v mapě nezůstane žádná prázdná buňka, incident se hlásí Deltě do 24 hodin od zjištění a Delta potvrzuje přijetí do následujícího pracovního dne. Takto konkrétní čísla si stanovte vlastním ujednáním, nejsou zákonnou lhůtou.
Omezení této mapy a rozumný další krok
Mapa řeší rozdělení rolí mezi stranami, neřeší sama o sobě soulad celého systému. Nepotvrzuje, že systém je bezpečný, neprokazuje splnění všech povinností a nenahrazuje posouzení konkrétního rizika, dokumentace ani interního školení. Navržená smluvní mapa je pracovní pomůcka, nikoli právní posudek pro vaše nasazení.
Rozlišení doložené povinnosti a doporučené praxe si držte i interně. Doložené je výše uvedené rozlišení značky, uvedení do provozu a používání pod vlastní autoritou. Doporučenou praxí je zbytek: vyplněná tabulka, předávací protokoly, kontrolní vzorky a jasné kontakty pro incidenty.
Další krok: vyberte jedno aktuální nasazení, projděte rozhodovací kartu, vyplňte mapu a nechte ji podepsat všemi třemi stranami, pokud se na dodávce podílejí. Teprve pak řešte další systémy. Prázdná místa z prvního kola berte jako seznam nevyřešených odpovědností pro příští verzi smlouvy.
ZDROJE A OVĚŘENÍ
revidováno Muse Spark 1.3 Contributor; GPT 6 Luna independent review; CIAD Codex editorial source and Czech acceptance ·