Vysoce rizikový systém není vysoce rizikový model

Riziko nežije uvnitř modelu jako varovný štítek. Vzniká ze zamýšleného účelu, nasazení, autority, rozhraní a lidí, kteří musí s výsledkem žít.

Vysoce rizikový systém není vysoce rizikový model

Štítek se věší na použití, ne na krabici

Model lze zkopírovat z jednoho serveru na druhý, aniž by se cokoli naučil. Jeho váhy, kód a deklarované schopnosti mohou zůstat beze změny. Přesto se otázka, kterou si Evropa klade ohledně věci kolem něj, může zcela změnit. K čemu slouží? Kdo ji používá? Čí postavení může změnit? Který záznam vstupuje do pracovního postupu? Kdo může zpochybnit odpověď, opravit ji, zastavit ji nebo později zjistit, proč se jí řídil?

Nejde o snahu povýšit jednoduché téma na něco velkolepějšího, než je. Jde o běžný rozdíl mezi součástkou a systémem. Brzdový kotouč není silniční vozidlo. Vzorec v tabulkovém procesoru není daňové rozhodnutí. Univerzální model umělé inteligence sám o sobě není každým systémem umělé inteligence, který se kolem něj může později postavit. Tento rozdíl je snadné odsouhlasit a pozoruhodně snadné ho ztratit, jakmile se na poradě o nákupu začne o modelu mluvit, jako by už v sobě obsahoval celé budoucí nasazení.

Nařízení EU o umělé inteligenci tento rozdíl udržuje v povědomí. Definuje systém umělé inteligence a samostatně definuje univerzální model umělé inteligence. Jeho pravidla pro vysoké riziko se týkají systémů umělé inteligence za konkrétních okolností, včetně systémů, které jsou bezpečnostními součástmi regulovaných výrobků, a systémů používaných v uvedených oblastech. Nařízení také činí zamýšlený účel ústředním prvkem klasifikace a dokumentace systému umělé inteligence. Nevyzývá tým, aby ukázal na název modelu, připevnil červený, oranžový nebo zelený štítek a prohlásil práci za hotovou.

To by mělo být osvobozující i náročné. Model nemá trvalý morální horoskop. Pečlivá analýza může být úzká tam, kde je úzký zamýšlený účel, a může se stát závažnou tam, kde se závažnými stanou pravomoc, expozice a důsledky. Háček je v tom, že analýza musí sledovat skutečný systém. Ne demo. Ne prezentaci dodavatele. Ne neškodný úkol, kterým projekt před šesti měsíci začal. Systém, který bude přijímat vstupy, zpřístupňovat výstupy, utvářet rozhodnutí a bude provozován v obyčejné úterý.

Vezměme si záměrně hypotetický příklad. Stejný jazykový model je nejprve připojen k internímu nástroji pro vyhledávání znalostí. Vyhledává pasáže z politik pro proškoleného kolegu, který si může otevřít původní zdroj a napsat vlastní odpověď. Později organizace připojí model k přijímacímu formuláři, umístí jeho doporučení na začátek záznamu případu, nastaví případu časovač a učiní přijetí doporučení nejrychlejším způsobem, jak vyřídit frontu. K tomu, aby si člověk změnu všiml, není potřeba žádná fiktivní rada, pacient, zaměstnanec ani incident. Model může být identický. Role výstupu, datová cesta, pobídka, dotčená osoba a praktická autorita rozhraní identické nejsou.

To je argument tohoto článku: systém s vysokým rizikem není model s vysokým rizikem. Model může být důležitou součástí systému a může mít vlastní povinnosti. Analýza rizik se ale stává smysluplnou teprve tehdy, když dosáhne zamýšleného účelu, kontextu nasazení, uživatelů, dotčených osob a navazující integrace. Tyto podrobnosti nejsou papírování připojené až po inženýrské práci. Jsou to okolnosti, které dávají výstupu institucionální váhu.

Najeďte na vrstvu nebo ji vyberte. Model je jen jedna vrstva; důsledek se objeví teprve ve chvíli, kdy se vrstvy setkají.

Evropa záměrně používá dvě různá podstatná jména

Rozdíl začíná v definicích aktu. Systém AI je strojový systém navržený tak, aby fungoval s různou mírou autonomie a mohl se po nasazení projevovat adaptivně, přičemž ze vstupů odvozuje, jak generovat výstupy, jako jsou předpovědi, obsah, doporučení nebo rozhodnutí, která mohou ovlivnit fyzická nebo virtuální prostředí. Model AI pro obecné účely je jiný: je to model AI schopný kvalifikovaně plnit širokou škálu různorodých úkolů, ať už je uveden na trh, nebo ne, a lze jej integrovat do různých navazujících systémů nebo aplikací.

Tyto definice se v běžné konverzaci překrývají, protože totéž slovo AI odvádí velký kus neplacené práce. V posouzení by se překrývat neměly. Model pro obecné účely je stvořen k cestování. Jeho možná použití jsou záměrně široká. Systém AI je provozní uspořádání, jehož prostřednictvím výstupy ovlivňují prostředí. Má účel, konfiguraci, rozhraní a prostředí. Může zahrnovat model, několik modelů, deterministická pravidla, databáze, senzory, lidi, postupy a velké množství drobných rozhodnutí, která nikdo nenazve umělou inteligencí, dokud neselžou.

Proto si poskytovatel modelu AI pro obecné účely a poskytovatel nebo nasazovatel systému AI nemohou jednoduše vyměnit kontrolní seznamy. Pokyny Komise k modelům AI pro obecné účely uvádějí, že poskytovatelé modelů musí zpřístupnit informace a dokumentaci poskytovatelům navazujících systémů AI, aby tito poskytovatelé mohli porozumět schopnostem a omezením modelu a plnit vlastní povinnosti. Tato věta je zajímavější, než se na první pohled zdá. Předpokládá, že navazující poskytovatel má práci, kterou poskytovatel modelu nemůže dokončit. Dokumentace modelu cestuje, ale nedokončí cestu.

Je v tom praktická pokora. Poskytovatel modelu může popsat architekturu, proces trénování, vyhodnocení, zamýšlené úkoly, požadavky na integraci, vstupy a výstupy, omezení a známé podmínky. Navazující tým ví, zda je uživatel vyškolený specialista, zda dotčená osoba může napadnout výsledek, zda je doporučení poradní jen podle názvu, ale závazné v praxi, zda volání externí služby změní záznam a zda lze vadný úkon zvrátit. Žádná ze stran nemá sama o sobě úplný obraz.

Toto rozdělení není mezera v právu. Je to mapa odpovědnosti. Říká, že systém nelze spravovat tím, že požádáme poskytovatele modelu, aby slíbil kontrolu nad nasazením, které neprovozuje ani nevidí. Zároveň říká, že se integrátor nemůže vymlouvat na neznalost tam, kde dokumentace zviditelňuje důležité omezení. Nejde o to vytvořit úhledné předání mezi právnickými osobami. Jde o to, aby se otázka neztratila v mezeře mezi nimi.

Vedle prvního rozlišení stojí za to držet se ještě jednoho. Klasifikace jako vysoce riziková sama o sobě neznamená povolení, bezpečnost, spravedlnost ani zákonnost. Ve společném stanovisku k původnímu návrhu Komise zdůraznily Evropský sbor pro ochranu osobních údajů a Evropský inspektor ochrany údajů, že zařazení mezi vysoce rizikové systémy nutně neznamená, že je systém jako takový zákonný nebo že jej může jeho uživatel jako takový nasadit. Konečný akt od té doby právní prostředí změnil, ale základní varování zůstává užitečné. Klasifikace je regulační podmínka. Není to potvrzení, že instituce může přestat přemýšlet.

To je důležité, protože označení vysoce rizikový může vést ke dvěma opačným chybám. Jeden tým ho může vnímat jako trvalou skvrnu na modelu a usoudit, že řešením je prostě se dál nedívat. Jiný může dokončený proces posuzování shody považovat za povolení pro jakýkoli pozdější kontext. Oba přístupy nahrazují argument nálepkou. Evropa zvolila méně pohodlný přístup: identifikovat systém, jeho účel a jeho roli a poté zkoumat příslušná rizika a povinnosti v průběhu celého jeho životního cyklu.

Zamýšlený účel je místem, kde analýza nachází oporu

Zamýšlený účel zní skromně, téměř úřednicky. Není tomu tak. Akt jej definuje jako použití, pro které je systém umělé inteligence určen poskytovatelem, včetně konkrétního kontextu a podmínek použití uvedených v informacích poskytnutých poskytovatelem. Jinými slovy, účel není slogan na produktové stránce. Zahrnuje kontext a podmínky, v nichž poskytovatel uvádí, že má být systém používán. Užitečné prohlášení o účelu má jasné hranice. Říká, co systém dělá, pro koho, s jakými vstupy, v jakém pracovním postupu a kde jeho pravomoc končí.

Porovnejte dva popisy. První říká, že systém využívá umělou inteligenci k tomu, aby organizacím pomáhal činit lepší rozhodnutí. Je natolik široký, že se hodí na konferenční pozadí, a natolik široký, že je nepoužitelný. Druhý říká, že systém předkládá vyškoleným posuzovatelům návrhy souhrnů stávajícího spisu s odkazy na zdroje; nemůže rozhodnutí vytvářet, předávat ani provádět; posuzovatel musí před použitím souhrnu ověřit citované zdroje; a funkce není dostupná pro kategorie, které vyžadují samostatný zákonný proces. Druhý popis je méně vzrušující. Je to ale také něco, s čím může inženýr, vedoucí nákupu, kolega z oddělení compliance i dotčená osoba konkrétně nesouhlasit.

Účel nemusí být jediná věta. U seriózního systému jde obvykle o kompaktní balíček: úkol, výstup, uživatel, dotčená populace, prostředí, pravomoc, vyloučení, závislosti a podmínky. Požadavky aktu na technickou dokumentaci přesně pro tento druh popisu vytvářejí prostor. Příloha IV vyžaduje obecný popis systému umělé inteligence, včetně zamýšleného účelu, osob a skupin, na které má být systém používán, a konkrétních verzí nebo forem, v nichž je uváděn na trh. Vyžaduje také popisy architektury systému, požadavků na data, opatření lidského dohledu, monitorování životního cyklu a opatření řízení rizik. Dokumentace má takový záběr, protože samotný modelový list nedokáže popsat nasazení.

Účel je také místem, kde tým zjistí, že popisoval spíše ambici než provoz. Věta „budeme podporovat pracovníky v sociální práci“ může skrývat tucet různých uspořádání. Vyhledává nástroj dokumenty, řadí práci, navrhuje odpověď, doporučuje kategorii, zamítá žádost, eskaluje upozornění, nastavuje prioritu nebo volá jinou službu? Používá jej kolega před vytvořením nezávislého názoru, nebo až po něm? Je výstup návrhem na bočním panelu, nebo polem, které musí být vyplněno, než se záznam může posunout dál? Je účinek okamžitý, opožděný, vratný, nebo obtížně zjistitelný? Odpověď mění systém, i když uživatelské rozhraní vypadá povědomě.

Zamýšlený účel poskytovatele nemůže způsobit, aby realita zmizela. Tým nemůže systému udělit širokou praktickou pravomoc, popsat jej jako neškodného asistenta a očekávat, že tím bude věc vyřešena. Řádně vymezený účel je však stále kontrolním prvkem. Uživatelům říká, jaké důkazy byly zohledněny, integrátorům říká, co nesmějí bez rozmyslu rozšiřovat, a posuzovatelům říká, jaká změna by znamenala znovuotevření posouzení. Vágní účel promění každou pozdější otázku ve spor o to, co bylo míněno. Vymezený účel umožňuje organizaci ptát se, zda stále dělá to, co schválila.

To se stává obzvláště důležitým, když organizace provede podstatnou změnu. Nařízení obsahuje pravidla pro případy, kdy se distributor, dovozce, zavádějící subjekt nebo jiná třetí strana může stát poskytovatelem, a to i v případě, že systém uvádí na trh pod vlastním jménem, provede podstatnou změnu nebo změní zamýšlený účel způsobem, který způsobí, že se systém stane vysoce rizikovým. Přesné právní posouzení závisí na konkrétních skutečnostech a je třeba je ověřit v daném kontextu. Provozní ponaučení je jednodušší: změna integrace může být událostí z hlediska správy a řízení. Přesun výstupu modelu z návrhové oblasti do fronty rozhodnutí může být zároveň změnou produktu, změnou pracovního postupu i změnou odpovědnosti.

Kontext není kulisou

S kontextem nasazení se často zachází jako s tím, co přichází až po skutečné práci: seznam zemí, volba hostingu, několik uživatelských person, možná diagram se šipkami, které poslušně vedou zleva doprava. Ale právě kontext dává riziku jeho podobu. Stejný druh výstupu může být v jednom prostředí nepříjemný a v jiném mít závažné důsledky. Chybný doplněný text v pomocníkovi pro psaní lze opravit v následující větě. Chybně stanovená priorita v pracovním postupu se vzácnými zdroji může rozhodnout, který soubor člověk uvidí jako první. Skóre, které se zdá být jen jedním z mnoha vstupů, se může stát rozhodujícím, pokud jsou všechny ostatní vstupy pomalé, vágní nebo skryté za jiným týmem.

Přístup nařízení k vysoce rizikovým systémům to odráží. Článek 6 spojuje klasifikaci vysoce rizikových systémů se systémy určenými k použití jako bezpečnostní součásti určitých produktů nebo se systémy uvedenými v příloze III. Příloha III uvádí oblasti, kde mohou být systémy AI vysoce rizikové, protože jsou určeny pro stanovená použití, jako jsou některá biometrická použití, kritická infrastruktura, vzdělávání a odborná příprava, zaměstnanost, přístup k základním soukromým a veřejným službám a výhodám, vymáhání práva, migrace a správa hranic a výkon soudnictví a demokratické procesy. Právní podrobnosti jsou důležité, ale důležitá je i gramatika. Neříká se zde, že technický artefakt je vysoce rizikový v abstraktní rovině. Opakovaně se zde uvádí, že je určen k použití.

Článek 6 také obsahuje výjimku pro některé systémy podle přílohy III: nepovažují se za vysoce rizikové, pokud nepředstavují významné riziko poškození zdraví, bezpečnosti nebo základních práv fyzických osob, a to ani tím, že podstatně neovlivňují výsledek rozhodování. Poskytovatelé musí toto posouzení zdokumentovat před uvedením systému na trh nebo do provozu. Toto není obecná výjimka z pravidel. Je to připomínka, že na skutečném účinku systému záleží. Užitečná analýza obsahuje dostatek podrobností k vysvětlení, proč systém podstatně ovlivňuje nebo neovlivňuje výsledek. Pokud toto vysvětlení nelze napsat bez obecných frází, tým se před vydáním něco naučil.

Kontext zahrnuje čas. Doporučení na začátku širokého šetření má jiný účinek než doporučení ve chvíli, kdy má člověk jedinou příležitost dodat chybějící materiál. Zahrnuje objem. Jednotlivý posuzovatel může zpochybnit výstup, když denně přijde pět případů, a může se jím řídit automaticky, když jich před obědem přijde pět set. Zahrnuje jazyk. Posuzovatel, který si může přečíst důkazy ve svém pracovním jazyce, může vykonávat jiný druh dohledu než posuzovatel, který dostane sebevědomé shrnutí materiálu, který si nemůže samostatně ověřit. Zahrnuje místní postupy, právo na odvolání, personální obsazení, přístup ke specialistovi, dostupnost záložního řešení a to, zda se výstup dostane k člověku s dostatečnou pravomocí, aby mohl udělat něco užitečného.

K tomu, aby to byla pravda, není potřeba žádná smyšlená katastrofa. Tak prostě systémy fungují. Formální politika může říkat, že člověk je v procesu, ale systém může být přesto funkčně automatický, pokud daná osoba nemá čas, informace, pravomoc ani praktickou možnost nesouhlasit. Článek 14 nařízení proto hovoří o účinném lidském dohledu přiměřeném rizikům, míře autonomie a kontextu použití. Vyžaduje, aby byly vysoce rizikové systémy navrženy a vyvinuty tak, aby lidé mohli porozumět příslušným schopnostem a omezením, zůstávali si vědomi tendence spoléhat se na výstup automaticky, správně výstup interpretovat, rozhodnout se jej nepoužít, přepsat jej nebo zvrátit a v případě potřeby systém bezpečně zastavit. To jsou provozní otázky. Nelze na ně odpovědět pouze na základě benchmarku modelu.

Vyberte způsob nasazení. Model zůstává na místě; hranice systému, pravomoc a potřebné důkazy se mění.

Uživatelé jsou součástí řídicí plochy

Je lákavé mluvit o uživatelích, jako by stáli mimo systém, drželi klávesnici a zajišťovali ten lidský krok. Jsou součástí provozního uspořádání. Jejich znalosti, pracovní zátěž, pravomoc, motivace a cesty k pomoci určují, co výstup udělá. Systém navržený pro specialistu, který si může prohlédnout zdrojový materiál, není automaticky vhodný pro zobecňujícího pracovníka, který má pracovat rychle. Nástroj užitečný pro posuzovatele, který může odmítnout doporučení, není automaticky vhodný pro kolegu, který může pouze kliknout na schválit nebo čekat na někoho jiného.

To neznamená, že uživatel musí pokaždé zpochybňovat každou součást systému. To by byla podivná definice užitečné technologie. Znamená to, že dohled má být navržen jako skutečný úkol. Člověk potřebuje vědět, kdy je systém používán, jaké je příslušné omezení, jaké důkazy jsou k dispozici, jaký druh nesouhlasu může zaznamenat a co se stane poté, co jej zaznamená. Potřebuje pravomoc odpovídající odpovědnosti. Žádat někoho, aby dohlížel na výstup, který nemůže pozastavit, opravit ani nasměrovat, je spíše lidská dekorace než lidský dohled.

Nařízení dává nasazujícím subjektům v tomto ohledu roli. Článek 26 ukládá nasazujícím subjektům systémů s vysokým rizikem povinnost přijmout vhodná technická a organizační opatření, aby zajistily používání těchto systémů v souladu s přiloženými pokyny. Vyžaduje, aby nasazující subjekty svěřily lidský dohled fyzickým osobám s potřebnou způsobilostí, školením a pravomocí, a aby sledovaly provoz na základě pokynů. V určitých případech rovněž vyžaduje, aby automaticky generované protokoly zůstaly pod jejich kontrolou. Toto není žádost, aby v blízkosti stál znalý člověk pro případ, že by rozhraní znejistělo. Je to požadavek na uspořádání pracovního postupu.

Školení je často zmiňováno jako jediné řešení. Není tomu tak. Školení může člověku pomoci rozpoznat omezení, ale nemůže vytvořit záznam o zdroji, který rozhraní skrývá. Nemůže vytvořit čas, který pohlcuje návrh fronty. Nemůže vytvořit pravomoc, kterou smlouva vyhrazuje jinam. Nemůže opravit integraci, která přemění opatrné doporučení na nezvratný úkon. Organizace by samozřejmě měla své lidi školit. Měla by také zajistit, aby úkol, na který je školí, bylo možné vykonávat v systému, který skutečně dostanou.

Existuje užitečný test: popište činnost uživatele, aniž byste použili sloveso „přezkoumávat“. Co čte? Jaké srovnání může provést? Co může odmítnout? Kam se zaznamená důvod? Kdo jej uvidí? Co se stane s doporučením po zamítnutí? Může se osoba dotčená výsledkem zeptat, co se stalo? Může si pozdější kolega rekonstruovat příslušný stav? Pokud odpovědi zůstanou obecné, bude pravděpodobně obecný i návrh dohledu.

Tento test se vztahuje i na systémy, které nejsou vysoce rizikové. Právní předpis má konkrétní rozsah a lhůty; dobrý provozní úsudek nečeká na kategorii, než se zeptá, zda byl člověk postaven do performativní role. Je naprosto možné vytvořit nástroj s nízkými důsledky, který lidi činí méně schopnými v jejich vlastní práci, protože výstup je příliš hladký na to, aby jej zpochybňovali. Je také možné vytvořit omezený nástroj, který zvyšuje schopnost člověka klást dobré otázky, protože uchovává důkazy, omezuje svou vlastní pravomoc a zviditelňuje nejistotu. Model může přispět k oběma výsledkům. Systém rozhoduje o tom, který výsledek má kde vzniknout.

Dotčené osoby stojí mimo konzoli

Mnoho z nejdůležitějších osob v systému umělé inteligence se jej nikdy nedotkne. Mohou to být uchazeči, žáci, pracovníci, pacienti, cestující, obyvatelé, zákazníci, žadatelé, dlužníci, svědci nebo členové veřejnosti. Nemusí vědět, že byl použit model. Mohou pouze zažít odpověď, která přijde rychle, žádost, která je zpožděna, službu, která se stane nedostupnou, prioritu, která se změní, nebo rozhodnutí, které se zdá nemožné pochopit. Jejich nepřítomnost v rozhraní z nich nedělá osoby nepřítomné v systému.

To je jeden z důvodů, proč se rizikový rámec nařízení vztahuje na zdraví, bezpečnost a základní práva. Směřuje pozornost k důsledkům, které nelze redukovat na to, zda si přihlášený kolega nástroj užil. Je to také důvod, proč by prohlášení o účelu mělo jmenovat osoby a skupiny, na které má být systém používán, jak vyžaduje příloha IV. Systém postavený kolem kategorie zvané uživatel může tiše skrývat rozdíl mezi osobou obsluhující rozhraní a osobou, která žije s výsledkem.

Lidé, kterých se systém týká, mění otázky, které si tým musí klást. Existuje způsob, jak poznat, že systém hrál skutečně podstatnou roli? Je rozhodnutí založeno na informacích, které lze opravit? Ztěžuje účast jazyk, zdravotní postižení, zařízení, místo pobytu nebo administrativní status? Dostává provozní tým signály od dotčených lidí, nebo pouze z přehledové desky? Dostane se oprava k datům, doporučení, rozhodnutí a všem navazujícím materiálům, které se o ně opíraly? Tyto otázky nejsou výzvou, aby se každý systém proměnil ve veřejnou konzultaci. Jsou výzvou, abychom důsledek sledovali dostatečně daleko, abychom na jeho konci viděli člověka.

Právo na ochranu osobních údajů je relevantní tam, kde dochází ke zpracování osobních údajů, a to vedle rámce aktu o umělé inteligenci. EDPB a EDPS tento bod jasně uvedly ve svém společném stanovisku z roku 2021 k návrhu: stávající právo EU na ochranu osobních údajů se vztahuje na zpracování osobních údajů v rozsahu návrhu. Přesná právní analýza bude záviset na zpracování a zúčastněných subjektech. Poučení pro řízení je přímočaré. Klasifikační cvičení nemůže pohltit všechny ostatní povinnosti. Soukromí, nediskriminace, odvětvové povinnosti, požadavky správního práva, pravidla ochrany spotřebitele a smluvní závazky nezmizí jen proto, že tým vytvořil pěkně vypadající registr rizik.

Existuje také základní otázka srozumitelnosti. Člověk se nemusí stát specialistou na strojové učení, aby pochopil, jak žádat o opravu. Systém ale nesmí používat technickou složitost jako důvod, proč opravu znemožnit. Dobrá cesta rozlišuje, co systém zaznamenal, co rozhodl člověk, jaké důkazy byly zváženy, co zůstává nejisté a co lze ještě změnit. Netvrdí přesnost, kterou záznamy nemohou podložit. V této oblasti není poctivost pouze tónem hlasu. Je součástí služby.

Integrace je místem, kde si odpovědnosti předávají ruce

Týmy někdy kreslí architekturu umělé inteligence jako úhledný řetězec: model, výzva, odpověď, uživatel. Skutečná nasazení se spíše podobají obecní mapě poté, co si někdo vzpomněl na servisní potrubí. Existují systémy pro identitu, úložiště pro vyhledávání, oprávnění nástrojů, fronty, schémata, mezipaměti, platformy pro sledování, rozšíření prohlížeče, dávkové úlohy, pravidla schvalování, nastavení uchovávání, dodavatelé a lidé, kteří zdědí úkol, protože předchozí osoba odjela na dovolenou. Model je důležitý. Málokdy je však sám.

Každá integrace může změnit, co je systém schopen dělat a jak se pohybuje chyba. Vyhledávání může způsobit, že výstup modelu vypadá podloženě, zatímco zdroj je zastaralý, neúplný nebo nesprávně vymezený. Volání nástroje může změnit návrh na změnu stavu. Fronta může změnit včasné doporučení na opožděné. Orchestrační vrstva může vybrat jiný model nebo verzi výzvy. Uživatelské rozhraní může skrývat nejistotu, která existuje v nižší vrstvě. Integrace identity může užitečnému nástroji poskytnout přístup k materiálu, který by uživatel jinak nemohl otevřít. Žádné z těchto pozorování neobviňuje konkrétní produkt nebo organizaci. Popisují běžné vlastnosti systémů, což je přesně důvod, proč by měly být zdokumentovány dříve, než začnou překvapovat.

Pokyny Komise pro GPAI jsou zde užitečné, protože umisťují informace do bodu předání. Dokumentace pro poskytovatele navazujících služeb má jim pomoci pochopit schopnosti a omezení modelu, zamýšlené úkoly, technické požadavky na integraci, specifikace vstupů a výstupů a informace o trénovacích datech. Tyto informace jsou nezbytné. Nejsou však dostatečné. Týmy navazujících služeb stále musí rozhodnout, jak je model vyzván, zda je výstup zobrazen s důkazy, která oprávnění nástrojů jsou povolena, jak se změna testuje, jaké protokoly se uchovávají a zda může doporučení ovlivnit konkrétní pracovní postup.

Proto nákup modelové služby není nákupem kompletního rizikového profilu. Dokumentace poskytovatele může týmu sdělit, že model má známé omezení nebo že byl vyhodnocen za určitých podmínek. Nemůže však prokázat, že vyhledávací index kupujícího je aktuální, že pracovníci kupujícího mají potřebné pravomoci nebo že dotčená osoba má přístup ke kanálu pro podání námitek. Naopak kupující nemůže požadovat, aby poskytovatel modelu znal všechny místní předpisy nebo navazující procesy. Zodpovědným přístupem není předstírat, že jedna strana může znát celý systém. Je jím jasně vymezit hranici a zajistit, aby přes ni důkazy plynule proudily.

Článek 25 poskytuje užitečný právní ukazatel pro tuto provozní realitu. Stanoví okolnosti, za nichž je strana jiná než původní poskytovatel považována za poskytovatele vysoce rizikového systému umělé inteligence. Patří mezi ně uvedení systému na trh pod jménem nebo ochrannou známkou této strany, provedení podstatné úpravy nebo změna zamýšleného účelu způsobem, který způsobí, že se systém stane vysoce rizikovým. Toto ustanovení je technické a závisí na konkrétních skutečnostech; nikdo by se neměl sám klasifikovat na základě příspěvku na blogu. Jeho směr je však jasný. Integrace a změna účelu mohou změnit to, kdo nese povinnosti poskytovatele. Navazující uspořádání není navždy navazující jen proto, že původní model pocházel odjinud.

Existuje institucionální důvod brát to vážně. Když se odpovědnost mění tiše, bezpečnost a náprava se stávají hrou organizačního ping-pongu. Poskytovatel modelu ukazuje na nasazení. Nasazovatel ukazuje na model. Integrátor ukazuje na cloudovou službu. Vlastník služby ukazuje na konfiguraci, která už neexistuje. Dotčené osoby dostanou vytříbené vysvětlení, jak je vše složité. To může být přesné, ale není to odpověď. Systém potřebuje záznam o tom, která organizace vlastní otázku na každé hranici, a cestu, kterou se otázka může ubírat, když odpověď leží jinde.

Dokumentace by měla popisovat systém, který se může stále měnit

Technická dokumentace má pověst něčeho, co dorazí na konci projektu s mírným zápachem paniky. Nařízení popisuje jinou roli. U vysoce rizikových systémů musí být technická dokumentace vypracována před uvedením systému na trh nebo do provozu a musí být průběžně aktualizována. Seznam v příloze IV přesahuje chování modelu a zahrnuje zamýšlený účel, verze, architekturu systému, vývoj, požadavky na data, validaci a testování, dohled člověka, opatření pro přesnost a kybernetickou bezpečnost, řízení rizik, změny a monitorování po uvedení na trh. To není dekorativní příloha. Je to pokus zachovat dostatek paměti, aby někdo mohl systém prozkoumat poté, co se z porady po spuštění stane folklór.

Dokumentace funguje pouze tehdy, když dokáže ukázat vztahy. Verze modelu musí být propojena s verzí systému, která ji používala. Test musí být propojen se svými vstupními podmínkami a účelem. Politika musí být propojena s místem jejího vynucování. Uživatelská role musí být propojena s oprávněním, které má v rozhraní. Politika protokolování musí být propojena s událostí, kterou může rekonstruovat. Změna musí být propojena s posouzením, které vyvolala. Jinak má tým knihovnu dobrých dokumentů, ale žádný způsob, jak odpovědět na konkrétní otázku.

Protokoly jsou podobný případ. Článek 12 vyžaduje, aby systémy AI s vysokým rizikem měly technické schopnosti pro automatické zaznamenávání událostí po celou dobu životnosti systému, přiměřené zamýšlenému účelu. Protokoly mohou pomoci při vysledovatelnosti, monitorování po uvedení na trh a provozním monitorování. Nevysvětlují rozhodnutí kouzlem. Protokol může pozdějšímu vyšetřovateli říci, že byl zavolán nástroj, že byla aktivní určitá verze nebo že recenzent klikl na ovládací prvek. Sám o sobě nemůže prokázat, zda recenzent porozuměl důkazům, zda byl zdroj vstupu autoritativní nebo zda byl proces spravedlivý. Záznamy jsou cenné, protože dávají vyšetřování poctivý výchozí bod, ne proto, že odstraňují potřebu úsudku.

Monitorování po uvedení na trh dotváří obraz. Článek 72 vyžaduje, aby poskytovatelé systémů s vysokým rizikem vytvořili a zdokumentovali systém monitorování po uvedení na trh způsobem přiměřeným povaze technologií a rizikům systému AI s vysokým rizikem. To má pro týmy nasazení jednoduchý důsledek: vydání není okamžikem, kdy se systém stává plně známým. Organizace potřebuje způsob, jak přijímat relevantní informace, rozlišit signál od závěru, rozhodnout, zda hranice zamýšleného účelu stále platí, a provést změnu nebo zastavit používání tam, kde to důkazy vyžadují.

Tato práce není okouzlující. Vypadá jako identifikátory verzí, jasná kritéria vydání, záznam závislostí, test cesty zpět, jmenovaný vlastník omezení a rozhodnutí, které zůstává viditelné i poté, co osoba, která je učinila, změní roli. Vypadá jako otázka, zda se integrace změnila, dříve než otázka, zda se změnil model. Vypadá jako uchování dostatečných důkazů k nápravě následku, ne jen jeho vysvětlení zpětně. Nuda zde není opakem ambice. Je to část, díky které se ambice vejde do instituce.

Jak uvažovat o celém systému bez předstírání jistoty

Úplná analýza není hledáním univerzálního rizikového skóre. Je to sled otázek, který se zpřesňuje s tím, jak se zpřesňuje návrh. První otázka je účel: co má tento systém dělat a co konkrétně dělat nemá? Druhá je důsledek: kdo může být ovlivněn, jak a prostřednictvím jakého rozhodnutí nebo služby? Třetí je autorita: který výstup může změnit stav, ovlivnit rozhodnutí, nastavit prioritu nebo změnit to, co osoba obdrží? Čtvrtá je důkaz: co podporuje použití systému v tomto kontextu a za jakých podmínek se tyto důkazy přenášejí?

Pak přicházejí nepříjemné otázky. Co se stane, když je model nejistý, chybný, nedostupný nebo používaný mimo stanovené hranice? Co se změní, když je zdroj zastaralý nebo je nástroj odepřen? Co když je uživatel ve spěchu, je v roli nový nebo nemůže prozkoumat základní materiál? Co když dotčená osoba požádá o opravu? Co když aktualizace změní výzvu, korpus pro vyhledávání, výchozí nastavení rozhraní, verzi modelu nebo oprávnění role? Odpovědí je někdy technická kontrola, někdy postup, někdy užší použití, někdy jiný vlastník a někdy rozhodnutí nenasadit. Správa, která nikdy nepřipustí poslední odpověď, je pouze schvalování v hezčím kabátě.

Pomáhá držet několik tvrzení odděleně. Potvrzený fakt říká, co poskytovatel modelu zdokumentoval nebo co organizace pozorovala v definovaném testu. Odvození říká, proč na tomto faktu může záležet v konkrétním pracovním postupu. Navrhovaná kontrola říká, co tým zamýšlí zavést. Zbytkové riziko říká, co zůstává po kontrole. Právní závěr říká, co platí podle práva. Tyto věci nejsou zaměnitelné. Dobrý dokument je označuje, protože čtenář může potřebovat zpochybnit jedno, aniž by zavrhl ostatní.

Lze například říci: dokumentace poskytovatele uvádí, že model má určité omezení; nasazovací tým usuzuje, že toto omezení by mohlo ovlivnit konkrétní použití; tým navrhne bránu pro ověření zdroje; tato brána dosud nebyla testována při zamýšleném zatížení; a právní oddělení musí posoudit výsledné použití podle platného práva. Taková věta není tak uspokojivá jako zelená fajfka. Je užitečnější než zelená fajfka, protože nenechává žádné pochybnosti o tom, co bylo a co nebylo prokázáno.

Týmy by měly být obzvláště opatrné se slovem člověk. Lidská role může být kontrolou, ale pouze tehdy, má-li definovaný úkol, dostatek informací, čas, školení, pravomoc a cestu k jednání. Lidská role se také může stát způsobem, jak přesunout vinu na osobu nejblíže obrazovce. Tento rozdíl není filozofický. Je viditelný v pracovním postupu. Pokud může recenzent pouze schvalovat, pokud nesouhlas zmizí v nesledovaném poli pro komentáře, nebo pokud nikdo nemůže napravit následné důsledky, systém nezískal smysluplný dohled jen proto, že někdo něco klikl.

Stejná opatrnost platí pro transparentnost. Dlouhý dokument může učinit systém popsatelným, aniž by byl zpochybnitelný. Dashboard může učinit systém viditelným, aniž by byl srozumitelný. Informace o tom, že je do systému zapojena umělá inteligence, může uživateli sdělit, že je zapojena, ale už mu neřekne, co lze s chybou dělat. Užitečná otázka je praktická: může příslušná osoba najít hranici, důkazy, odpovědnou roli a cestu k nápravě v okamžiku, kdy na těchto věcech záleží? Pokud ne, informace existuje na špatném místě, aby mohla proběhnout správa.

Malá poznámka od nás

V naší společnosti Dweve náš veřejný Trust Centre zachází se záznamem o modelu a s navazující integrací jako se souvisejícími, ale samostatnými záznamy. Jeho stránka o navazujících systémech uvádí, že týmy, které integrují nebo nasazují Loom, potřebují aktuální schopnosti, omezení, rozhraní, kontext hodnocení a změny, zatímco veřejný záznam uvádí, že model je jedním vláknem v širší tkanině komponent a provozních hranic. Toto je dokumentační postoj, nikoli tvrzení, že veřejná stránka klasifikuje každé možné nasazení nebo prokazuje shodu pro integrátora. Účel tohoto oddělení je skromnější: záznam o modelu by měl cestovat spolu s integrací, aniž by předstíral, že nahrazuje vlastní systémovou analýzu integrátora.

Toto je standard, který stojí za to zachovat. Poskytovatel modelu by měl zpřístupnit užitečné informace. Organizace, která model nasazuje nebo integruje, by měla popsat skutečný systém, který vytvořila: účel, lidi, data, rozhraní, pravomoci, monitorování a nápravu. Žádná strana by neměla používat dokumentaci jako ceremoniální výměnu, při níž jedna strana obdrží PDF a druhá rozhřešení.

Těžší otázka je obvykle ta lepší

Když se tým ptá, zda je model vysoce rizikový, může sahat po rychlé odpovědi na oprávněnou obavu. Užitečnější otázka je ale obvykle delší: jaký systém z tohoto modelu vytváříme, pro jaký účel, v jakém kontextu, s jakými lidmi, a co se stane, když systém selže? Na tuto otázku nelze vždy odpovědět na jedné schůzce. Může odhalit, že zamýšlené použití je užší, než se očekávalo, že důkazy jsou neúplné, že uživatelská role nemá dostatečné pravomoci, že smlouva ponechává důležitou hranici bez vlastníka, nebo že se navazující integrace tiše stala středobodem systému.

Žádné z těchto zjištění není selháním inovace. Jsou to věci, které se instituce naučí, než systému udělí moc utvářet možnosti jiného člověka. Evropský přístup je často popisován jako soubor povinností. Je také disciplínou pojmenovávání: pojmenujte účel, aktéra, kontext, verzi, dotčenou osobu, omezení, důkazy a cestu k zásahu. Jakmile jsou tyto věci pojmenovány, lze je testovat, měnit a zpochybňovat. Dokud pojmenovány nejsou, mají tendenci se později znovu objevit jako překvapení.

Model může být schopný, pečlivě zdokumentovaný a hodnotný. Může být také umístěn do systému, který od něj žádá příliš mnoho, skrývá před uživateli příliš mnoho nebo ponechává příliš málo prostoru člověku dotčenému výsledkem. Rozdíl vzniká mimo váhy. Právě tam leží obtížná práce, a také vážná příležitost: budujte systémy, jejichž autorita odpovídá jejich důkazům, jejichž hranice přežijí integraci a jejichž provozovatelé stále umějí říci ne.

Zdroje