Právní průšvihy při nasazování AI nástrojů – praktické zkušenosti, kdy se to nepovedlo (1. část)

Úvod: implementace AI nástrojů

Rád bych se zaměřil se na subjekty a jejich povinnosti při implementaci nástrojů umělé inteligence. Také bych s vámi chtěl projít několik otázek, které se mohou objevit ve chvíli, kdy budete jako advokáti pomáhat klientům implementovat nástroje AI, což je role, ve které se často nacházím já a můj tým, anebo když budete v rámci vaší organizace AI implementovat, ať už jako podnikoví právníci nebo jako právníci ve státní správě.

Kdo z vás už se někdy účastnil implementace nějakého nástroje AI? Prosím, nemyslím tím situaci, kdy jste si koupili Codexis a spustili jej u vás, ale že jste skutečně implementovali nějaký nástroj. Je nás tady pět. Jsem přesvědčen, že až tady budeme za pět let, bude tady pět těch, kteří ruku nezvednou, a to budou ti, kteří budou v tu chvíli na nějakém telefonním hovoru nebo nedostatečně uslyší moji otázku. Je to činnost, která nás jako právníky nejen čeká v blízké budoucnosti, ale už na nás dopadá.

Chtěl bych s vámi nasdílet několik myšlenek, ne nějak sofistikovaných. To znamená, že i neprávníci jim možná porozumí. Nemáme příliš právních předpisů, o kterých bychom mohli hovořit; jsou to spíše myšlenky, jakým způsobem k takové implementaci přistupovat.

Regulace není checklist

Uvědomte si, že regulace, která determinuje nástroj, který implementujete, není checklist. Není to o tom, že si vezmete jednotlivé právní předpisy a odškrtáte si, jestli jste splnili příslušné povinnosti. Tradiční schéma, které známe ze situací, kdy jste připravovali všeobecné obchodní podmínky, že jste se podívali do § 1811, do kterého je implementována evropská direktiva, a do následujících ustanovení, a odškrtali jste si, že všechno ve všeobecných obchodních podmínkách máte, je nenávratně pryč.

V případě nástrojů AI, ale i obecně v případě technologických nástrojů, v případě AI se to jen znásobuje, nám regulace podmiňuje samotný design toho nástroje. Tedy to, jak ten nástroj budeme nastavovat a jak jej budeme využívat.

Příklad zdravotnické aplikace

Abychom byli co nejvíce praktičtí, vezmu si na pomoc příklad jedné aplikace. Je to konkrétní příklad, který jsme v právní praxi dělali, a jedná se o zdravotnickou aplikaci. Představte si tedy aplikaci, kterou máte v mobilním telefonu, která je napojená na vaše chytré hodinky a je schopna pracovat s údaji o vašem tělesném tepu, tlaku, s tím, kolik jste ušli kroků, kolik jste toho snědli, a také s dalšími informacemi, které jí poskytnete třeba z jiných aplikací. Jejím úkolem je pomoci vám žít zdravě.

Tato aplikace vám řekne: více cvičte, méně tancujte, méně pijte alkohol, pijte více vína, pijte méně tohoto, více spěte, lépe zvládejte stres, a to na základě konkrétních dat, která bude mít k dispozici.

Aplikace je založena na bázi umělé inteligence, to znamená: je to AI. Její součástí je nějaký chatbot, který je schopen zodpovědět vaše otázky. Takže sedíte, jste v nějaké situaci, bolí vás hlava a zeptáte se: bolí mě hlava, co s tím mám dělat?

Přehled regulace

A implementace takové aplikace znamená, že se musíte dívat na určité právní předpisy.

Nejde o úplný výčet. Právních předpisů, které jsme identifikovali a které se skutečně aplikují nebo připadají v úvahu, je celkem šestnáct. Zhruba šestnáct jich je z pera Evropské unie. Jde tedy o harmonizovanou legislativu.

Jenom když se na to podíváme, tak ta aplikace pracuje s nějakými daty. Jsou to osobní údaje, jsou to neosobní údaje, takže je tam GDPR, je tam Data Act. Je to aplikace, která se dotýká zdravotních dat, to znamená nejen GDPR, ale zároveň zvažujete, zdali se nebude jednat o software, který spadne pod regulaci MDR a zákon o zdravotních službách. V případě, kdy se osoba do aplikace přihlašuje, tak to může být eIDAS, může tam být otázka ePrivacy a samozřejmě již zmiňovaný AI Act. Jsme v oblasti kybernetické bezpečnosti, takže NIS2. Pokud jsou součástí nějaké adTechové nástroje, forma reklamy, tak je to DSA. A musíme si klást otázku, zdali texty, které jsou tam zveřejněny, musí být v souladu s European Accessibility Actem. A když se budeme bavit o odpovědnosti za provozování nějakého softwaru, tak do budoucna to bude Product Liability Directive, která je v procesu implementace, a GPSR, které už máme na stole.

Vidíte tedy, že těch předpisů je obrovské množství. Celá řada povinností, které dopadají na daný subjekt, se může týkat třeba doby zpracování údajů, po kterou si aplikace, respektive její provozovatel, údaje ponechává. I to nám reguluje několik právních předpisů. Vyznat se v té džungli je poměrně složité.

V tomto případě nám bude krásně pomáhat AI, která pomůže s první identifikací těch předpisů a povinností. Nicméně na nás jako na právnících — a AI nám v tom pomůže, ale jen pomůže — je uvědomit si, že my jako právníci pracujeme s designem té aplikace jako takové.

Vezměme si třeba jenom dva ze tří klíčových příkladů.

Co ovlivní design nejvíce?

První je otázka MDR, Medical Devices Regulation. To znamená, zdali ta aplikace, ten software jako takový, poskytuje zdravotnické služby. Ve chvíli, kdybychom byli v této regulaci, tak se nám to dominovým efektem propisuje do celé řady povinností.

Zejména ve chvíli, kdy designér aplikace chce, aby ta aplikace řekla „Aplikujte inzulín“, jsme v této regulaci, a tím pádem současně spadneme i do složitější regulace v rámci kybernetické bezpečnosti.

Ve chvíli, kdy aplikace řekne „Jděte si zaběhat“, jsme pořád v tom nižším režimu. Protože nespadneme do medicínské regulace.

Vrátím se ale zpět: úplně stejné to bude v oblasti GDPR.

Když budeme pracovat s nějakým právním titulem, tak ten nám determinuje, jakým způsobem můžeme či nemůžeme pracovat s osobními údaji. Budu zase konkrétní a uteču od té medicínské aplikace.

Vzpomenu si na nástroj, který jsme implementovali v jedné finanční instituci v České republice. Designéři za námi přišli a říkají: máme tady tento nástroj a pracujeme s nějakým jednoduchým oprávněným zájmem, který jsme si identifikovali. A tady na to další budeme mít souhlasy našich zákazníků.

Když jsme se potom podívali na typ souhlasu a na to, s jakým oprávněným zájmem se pracuje, otázka, která přišla, byla, k čemu vlastně ta data budete používat. Abych vysvětlil, o co se jednalo: šlo o situaci, kterou bychom mohli nazvat datovým trychtýřem. Komunikace se zákazníkem — představte si, že např. vaše banka s vámi komunikuje prostřednictvím e-mailu, telefonu, chatbota a dalších nástrojů — a veškerá tato komunikace jde na jedno místo, kde se analyzuje.

Ve chvíli, kdy ta analýza probíhá tím způsobem, že data jsou anonymizována a výsledkem této analýzy je jen to, že málo zákazníkům nabízíme naše produkty nebo málo zákazníkům zdůrazňujeme, že teď máme sníženou úrokovou sazbu, tak to asi není úplně problém. Ale ve chvíli, kdy chceme být konkrétnější a třeba konkrétnímu zákazníkovi prostřednictvím aplikace doporučit nebo doporučit bankéřům komunikujícím s konkrétním zákazníkem, aby se nějakým způsobem chovali nebo nějaký produkt nabídli, je situace úplně jiná. Musíme si položit otázku, jak máme promyšleno, že se ta aplikace bude vyvíjet do budoucna.

Úplně stejné to bylo u zmíněné zdravotní aplikace. Jak chceme, aby se vyvíjela do budoucna? Protože když se budeme dívat jen na stávající stav, který může být třeba konkrétně u finanční aplikace velmi jednoduchý (jejím cílem bylo zjistit, jakým způsobem zlepšit uživatelský komfort zákazníků při komunikaci s bankou), tak nejde o nic složitého.

Do budoucna ale víme, že myšlenka byla taková, že AI může dokonce převzít komunikaci se zákazníkem jako takovou. Ve chvíli, kdy by AI tuto komunikaci přebírala, je právní základ zpracování osobního údaje úplně jiný. To znamená, že nemůžeme pracovat s oprávněným zájmem.

Pracujeme se souhlasem, a ještě v nějakém konkrétním designu. Ve chvíli, kdy tak neuděláte, je to jeden z těch velkých právních průšvihů, protože tím do budoucna určujete, že za rok se může stát, že váš klient musí znovu přijít za svými zákazníky, znovu od nich požadovat nějaký souhlas, a to jsou obrovské náklady. A nelze vyloučit, že v rozsahu, ve kterém získá oprávnění užívat data v tuto chvíli, je za několik let nedostane.

A zpět ke zdravotnické aplikaci: ve chvíli, kdy nadesignujete aplikaci tak, že budete trvat na tom, aby pracovala s nějakými zdravotnickými doporučeními, mohou se náklady na její vývoj s ohledem na způsob regulace, do které spadne, protáhnout o 6 až 12 měsíců.

Spadneme totiž do vyššího režimu v rámci aktu o umělé inteligenci. Tady vidíte, jak právní regulace přímo determinuje design. Velmi dobře to znázorňuje tento obrázek:

Souhlas pro poskytování služby, tj. v oblasti osobních údajů, ve chvíli, kdy v budoucnosti budete zákazníka profilovat, dělat mu konkrétní doporučení a klasifikovat ho na bázi AI, znamená, že budete potřebovat nové souhlasy. Právní profese se tady poměrně proměňuje – musíme s klientem přemýšlet o designu produktu do budoucna.

Design produktu

Vybral jsem si několik parametrů, které jsou pro designy produktů klíčové a které jsou podle mě vlastně nejzajímavější a souvisí s tím, jak jsme uvažovali při designu mobilní aplikace.

První z nich je tedy požadavek na souhlas. Tento sloupeček vychází z GDPR, to znáte. Jaké to potom má architektonické požadavky, samozřejmě souvisí s tím, jak bude koncipovaný souhlas, jak budou zaškrtnuta různá políčka a podobně. To je něco, co je podle mě řadě z vás poměrně blízké, protože GDPR vám není úplně vzdálené.

Nicméně, ve chvíli, kdy jsme se s klientem bavili o tom, jak designovat profilování a automatizované rozhodování, jsou ty architektonické požadavky poměrně složité. Jakým způsobem tedy nadesignovat, že se uživatel může z doporučení odhlásit? Jak nadesignovat, aby to bylo uživatelsky zajímavé a aby ho to neodradilo od dalšího používání aplikace, když dostane informaci, že povaha výstupů je jenom doporučující?

Musíme tam v takovou chvíli zaimplementovat varování, že aplikace není náhradou za profesionální zdravotní konzultaci.

AI modely a integrace třetích stran

Dalším z požadavků je požadavek na zpracovatele podle GDPR, protože žádný z těchto nástrojů samozřejmě není stand-alone. Tzn. tyto nástroje v sobě integrují další nástroje, je tam celá řada dalších uživatelů, kterým jsou předávány osobní údaje. A v takovém případě je zapotřebí v rámci architektonických požadavků pracovat se smluvními zárukami, s lokalizací dat, s tím, že data nebudou používána k trénování modelů, a tak dále.

Cesta dat

Zajímavá otázka byla i samotná cesta dat. Je to jedno z doporučení, které bych byl rád, aby tady zaznělo a které byste si možná mohli odnést. V rámci designování aplikací a jejich implementací musíte porozumět tomu, jak data tečou v rámci organizace. To znamená nejen navnímat, že se data vloží do nějakého systému, ale také to, že ten systém, jak jsem říkal, ne vždycky je stand-alone; většinou není.

To znamená, kde se data objevují, na jakých uzlech, kam jsou předávána a jak jsou logována, s jakou retencí a po jakou dobu v systémech zůstávají. Jedním z příkladů cesty dat je už samotné přihlášení do aplikace. Jde tedy o logování jednotlivých událostí, kdy přijdete do aplikace, protože vývojáři samozřejmě všichni chtějí vidět, co tam uživatel dělal. A také to, jestli logy, které se v aplikacích objevují, musí být pseudonymizované, anonymizované a tak dále.

Jak regulace mění design?

Když se podíváme na další požadavky, jak regulace mění samotný design, tak jsem si tady kromě věcí, které už jsme si říkali, vybral ještě retenci. To znamená, po jakou dobu data ponecháváme.

To má samozřejmě obrovský vliv na kapacitu hardwarových nástrojů. Když spadneme do vyššího režimu regulací, zvyšují se náklady na bezpečnost a data minimization je samozřejmě jeden ze základních principů.

Data minimization → méně features
Retention → kapacita HW
Security → náklady
Auditovatelnost → logování

Dopad na ekosystém: Bureau Krediet Registratie

Když se podíváme na rozhodovací praxi, vidíme, že může nastat situace, kdy podceněný design na začátku může vést k samotnému pádu celého systému.

Mám rád tento příklad, je z Beneluxu, z Holandska, a už je poměrně starší. Není to úplně AI, ale je to situace, kdy holandský soud posuzoval Bureau Krediet Registratie, což je v zásadě systém založený na hodnocení úvěruschopnosti osob, a konstatoval, že právní základ, v tomto případě zpracování osobních údajů, byl zvolen nesprávně. Z toho vyplývá, že každý subjekt údajů, jehož úvěruschopnost je v tomto systému posuzována, může podat námitku a následně může být z tohoto systému vymazán. Rozhodnutí, které proběhlo nejvyšším holandským soudem, tuším v roce 2020, v zásadě znamenalo, že celý tento ekosystém byl opuštěn. Obrovské náklady, které do toho byly investovány, byly ztraceny, a to z toho důvodu, že se podcenil samotný začátek.

Podcenilo se tedy, jaká data pustím do systému. A tady jsme byli ještě mimo nástroj AI. Se znalostí celé řady různých systémů v České republice, o kterých konkrétně nemůžu úplně hovořit, jsem přesvědčen, že nemálo z nich by dopadlo podobným způsobem. Protože způsob, jak pracují s daty, není úplně korektní.

V souvislosti s implementací nástrojů AI bych klienty rozdělil na dvě kategorie. První kategorie je taková overcompliance, to znamená, že čekají na spuštění teprve, když si udělají cvičení, o kterém tady mluvíme.

Druhá skupina je taková, že bezhlavě implementuje nástroje umělé inteligence a příliš to neřeší. Vlastně budou řešit věci až někdy v budoucnu reaktivně. Nicméně reaktivní přístup může být poměrně drahý, protože nemáte vyřešen základní stavební kámen celého řešení.

Na závěr bych rád prošel několik doporučení.

Doporučení

Prvním z nich je porozumění life cycle produktu. Ve chvíli, kdy za vámi někdo přijde nebo vy sami budete implementovat takový nástroj, ptejte se na to, jak se bude ten nástroj vyvíjet do budoucnu. To determinuje jeden ze základních stavebních kamenů.

Druhá věc: rozumějte datovým tokům v rámci těchto nástrojů. Proveďte si data mapping, protože to samo o sobě, typicky v oblasti GDPR, determinuje, jaké regulatorní věci musíte podstoupit.

Identifikujte si regulace, pod které spadáte, a soustřeďte se na regulace determinující klíčová nastavení produktu.

V případě naší aplikace to bylo MDR a byly dvě možnosti. Postupovali jsme tak, že jsme připravili design systému, který je v souladu s MDR, a k tomu související časový odhad nástupu. Ve druhém případě to byla situace, kdy jsme byli mimo MDR, kdy samozřejmě náklady byly nižší, ale znamenalo to nějaké komerční omezení nástroje.

A poslední mé doporučení: protože odpovědi na tyto otázky vám nedá nikdo jiný než vývojáři nebo produkťáci, je třeba pracovat s nimi bok po boku. Velmi často se totiž i jako praktikující právníci budete setkávat se situací, kdy budete klást otázky jako advokáti řediteli právního oddělení a ten na ně nebude umět odpovědět nebo bude pracovat s nějakými domněnkami. To nedělejte. Pracujte s tím, co je reálně součástí systému, tak, jak je naplánováno, že se systém bude vyvíjet. Pracujte bok po boku s vývojáři, a ještě možná dodám s produktovými manažery, protože z praxe můžu říct, že velmi často se stává, že každý z nich míří myšlenkově někam trochu jinam.