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.

  1. 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ě.
  2. 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.
  3. Systém používáme pod vlastní autoritou. Pokud ano, pracujte s hypotézou role provozovatele a zaznamenejte také účel a okolnosti jeho nasazení.
  4. 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.
  5. 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.

OblastOdpovědná stranaKonkrétní úkolDůkaz a předání
Identita a účeldoplnitPopis systému, verze, obchodní název, účel nasazeníPříloha s technickým popisem
Vývoj a značkadoplnitKdo systém vytvořil a pod čí značkou se dodáváProhlášení výrobce, číslo verze
Integrace a datadoplnitNapojení na data, prompty, filtry, přístupová právaProtokol o nastavení a testech
Uvedení do provozudoplnitKdo provedl první nasazení a zaškoleníPředávací protokol, prezenční listina
Běžný provozdoplnitKdo schvaluje výstupy a kdy je nutný člověkPracovní postup, log schválení
Informování lidídoplnitKdo a jak informuje dotčené osoby o použití AIText oznámení, místo zveřejnění
Monitoring a incidentydoplnitKdo sleduje chyby, komu se hlásí, kdo zastaví provozKontakty, lhůta pro hlášení, záznam incidentu
Změny a nové verzedoplnitKdo smí měnit nastavení a kdo změnu schvalujeZmě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 ·