Když model chybuje, kdo ho smí zastavit?

Lidský dohled není člověk stojící vedle modelu. Je to autorita, důkazy a bezpečný stav, které někomu umožní odmítnout výstup, přerušit proces a vrátit práci...

Když model chybuje, kdo ho smí zastavit?

Evropský akt o umělé inteligenci používá pro digitální povinnost překvapivě fyzické slovo. Článek 14 říká, že lidé pověření dohledem nad vysoce rizikovým systémem umělé inteligence musí být schopni zasáhnout, nebo systém přerušit pomocí tlačítka stop či podobného postupu, který umožní jeho bezpečné zastavení. Věta se týká softwaru. Čte se, jako by si někdo rozumně vzpomněl, že stroje lze vypnout.

Tato vzpomínka je důležitější, než se zdá. V mnoha organizacích je lidský dohled chápán jako přítomnost člověka někde poblíž systému. Recenzent obdrží doporučení. Operátor si může otevřít přehledovou desku. Manažer je jmenován ve směrnici. Existuje podpůrná adresa pro stížnosti. Toto uspořádání je pak popsáno jako člověk ve smyčce, jako by byl člověk umístěn do smyčky a smyčka díky tomu zmoudřela.

Skutečná otázka je těžší a užitečnější: když je model chybný, nejistý, mimo svůj schválený účel nebo se chová způsobem, který důkazy nepodporují, kdo má pravomoc práci zastavit? Kdo může pozastavit nové činnosti bez čekání na dodavatele? Kdo může zabránit tomu, aby se již vygenerované výstupy staly rozhodnutími? Kdo může uchovat stav, který je třeba prošetřit? Kdo může znovu otevřít cestu a na základě jakých důkazů? Člověk, který si problému všimne, ale nemůže systém změnit, je svědek. Člověk, který může kliknout na tlačítko, ale neví, co tlačítko zastavuje, obsluhuje rekvizitu.

Proto musí být právo zastavit navrženo ještě před nasazením. Potřebuje pojmenovanou roli, rozsah, bezpečný stav, stopu důkazů, cestu pro eskalaci a způsob návratu do provozu, který tiše nezavede zpět stejné selhání. Potřebuje dostatek technických podrobností, aby fungovalo, když je systém vytížený, dodavatel nedostupný a člověk, který původní pracovní postup vytvořil, už přešel na jiný projekt. Potřebuje také dostatek institucionální jasnosti, aby člověk mohl pravomoc použít, aniž by byl obviněn z přerušení inovací.

Zastavení je schopnost, ne zdvořilost

Zastavení je často popisováno jako poslední možnost, což mu dodává nešťastnou ceremoniální kvalitu. Organizace slíbí, že někdo může systém zastavit, pokud budou okolnosti dostatečně vážné. Okolnosti nastanou. Člověk hledá pravomoc. Pravomoc se ukáže být odstavcem v dokumentu, oprávněním drženým jiným týmem nebo eskalací adresy, která je monitorována v pracovní době. Systém pokračuje, velmi zdvořile.

Zastavení není nálada. Je to schopnost s rozhraním a smlouvou. Rozhraním může být tlačítko, příkaz, politická brána, odvolaný token, zakázaná cesta, pozastavení fronty nebo řízené vypnutí. Smlouva říká, co akce dělá, co nedělá, které práci zabrání, která práce smí doběhnout, jaký stav je zachován, kdo je informován a jak organizace ví, že zastavení nabylo účinku. Pokud tyto odpovědi chybí, slovo stop znamená jen to, že všichni souhlasí, že zastavení by bylo hezké.

Existuje užitečné rozlišení mezi zastavením modelu a zastavením důsledku. Model může běžet, zatímco jeho výstupy jsou drženy k přezkumu. Služba může zůstat dostupná pro nenáročné psaní, zatímco její cesta doporučení je uzavřena. Nástroj může vracet informace pouze pro čtení, zatímco přístup k zápisu je odebrán. Pracovní postup může přijímat nové případy, ale odmítat je posouvat do externího rozhodnutí. Toto jsou různé ovládací plochy. Zacházet s nimi jako s jedním velkým červeným vypínačem buď zastaví příliš málo, nebo zničí více práce, než je nutné.

Proporcionalita je důležitá, ale proporcionalita není svolením k tomu, aby byl zásah vágní. Asistent s nízkými důsledky může potřebovat lokální odmítnutí a cestu k člověku. Systém používaný v oblasti s vysokým dopadem může potřebovat tvrdou bariéru, než výstup může ovlivnit práva osoby nebo přístup ke službě. Autonomní nástroj, který může měnit externí záznam, může potřebovat samostatnou intervenční cestu než model, který pouze píše návrh. Riziko, míra autonomie a kontext použití určují sílu kontroly. Neodstraňují potřebu kontroly.

Jazyk nařízení o umělé inteligenci je užitečný právě proto, že spojuje lidský dohled se skutečným rizikovým cílem. Dohled má zabránit rizikům pro zdraví, bezpečnost a základní práva nebo je minimalizovat. Není tam proto, aby systém ozdobil lidskou siluetou. Pokud pověřená osoba nedokáže rozpoznat anomálii, interpretovat výstup, přepsat jej nebo bezpečně zastavit provoz, uspořádání nesplnilo praktický účel dohledu, bez ohledu na to, kolik podpisů se objeví v projektovém souboru.

Čtěte článek 14 jako technickou specifikaci

Článek 14 se vztahuje na systémy umělé inteligence s vysokým rizikem, ne na každý software, který získal označení AI. Jeho první požadavek zní, že systém musí být navržen a vyvinut tak, aby jej fyzické osoby mohly účinně dohlížet, dokud je v provozu. Slovní spojení „dokud je v provozu" je důležité. Přezkum při nákupu není dohledem nad živým systémem. Školicí kurz absolvovaný před spuštěním není dohledem nad změněným modelem. Vysvětlení po incidentu nenahrazuje kontrolu, která mohla akci zabránit.

Druhý požadavek dává dohledu účel. Má zabránit rizikům, která se objeví, když je systém používán k zamýšlenému účelu nebo za rozumně předvídatelného zneužití, nebo je minimalizovat. Tato formulace odolává pohodlnému triku, při kterém organizace považuje každé škodlivé použití za nepředvídatelné překvapení. Lidé budou systémy používat pod tlakem, s neúplnými informacemi, prostřednictvím překladů, v neobvyklých kombinacích a na hranici svých pokynů. Seriózní návrh se ptá, které zneužití je rozumně předvídatelné, a dává recenzentovi způsob, jak reagovat dříve, než výstup získá institucionální sílu.

Třetí požadavek činí dohled úměrným riziku, autonomii a kontextu. Poskytovatel může zabudovat opatření do systému a může také určit opatření, která musí zavést nasaditel. Toto je rozdělení práce, nikoli rozdělení odpovědnosti. Poskytovatel nemůže předat systém bez použitelného způsobu jeho přerušení a ukázat na nasaditele. Nasaditel nemůže ignorovat dodané limity a tvrdit, že poskytovatel slíbil bezpečnost v abstraktní rovině. Kontrola musí přežít hranici mezi dodanou věcí a způsobem jejího použití.

Čtvrtý odstavec je místem, kde se právní jazyk stává praktickým kontrolním seznamem. Lidé pověření dohledem musí být schopni porozumět příslušným schopnostem a omezením systému. Musí být schopni jej monitorovat, včetně anomálií, dysfunkcí a neočekávaného výkonu. Musí si být vědomi automatizačního zkreslení, tendence spoléhat se na výstup stroje nebo se na něj příliš spoléhat. Musí být schopni interpretovat výstup. Musí být schopni rozhodnout se jej nepoužít, ignorovat jej, přepsat jej nebo jej zvrátit. Nakonec musí být schopni zasáhnout nebo přerušit provoz pomocí tlačítka zastavení nebo podobného postupu, který jej uvede do bezpečného stavu.

Každé sloveso vytváří jinou konstrukční povinnost. Porozumění vyžaduje použitelné informace o rozsahu a omezeních. Monitorování vyžaduje signály, čas a cestu k jejich prozkoumání. Povědomí o automatizační zaujatosti vyžaduje školení a rozhraní, které nepromění doporučení ve výchozí verdikt. Interpretace vyžaduje důkazy a kontext. Přepsání vyžaduje pravomoc a záznam o nesouhlasu. Přerušení vyžaduje přechod stavu, který je bezpečnější než pokračování. Jediný zelený dashboard nemůže uspokojit pět různých sloves pouze tím, že je velký.

Akt také obsahuje konkrétnější pravidlo pro určité vysoce rizikové systémy biometrické identifikace. V případech, na které se toto ustanovení vztahuje, nelze rozhodnutí přijmout na základě výsledku identifikace, pokud nebyl samostatně ověřen a potvrzen nejméně dvěma způsobilými, proškolenými a oprávněnými fyzickými osobami, s výhradou stanovených právních výjimek. Toto je konkrétní evropský příklad dohledu vyjádřeného jako nezávislá pravomoc, nikoli jako osamělý recenzent proklikávající se doporučením. Ukazuje také, proč musí návrh pojmenovat typ rozhodnutí a důkazy, které jsou pro něj potřebné.

Článek 14 nepředepisuje jeden univerzální model personálního obsazení. Stanovuje hranici. Osoba musí mít dostatečnou způsobilost, školení a pravomoc k výkonu této role. Poskytovatel a nasazovatel musí učinit kontrolu přiměřenou systému. Organizace stále musí rozhodnout, které role provádějí které úkony, kdy je zastavení povinné, jak se nakládá s pozastaveným případem a co se považuje za bezpečné obnovení. Právo může vyžadovat dveře. Nemůže si vybrat osobu, která má klíč v každé budově.

Zastavení není konec správy. Je to přechod, který umožňuje vyšetřování, nápravu a obhajitelné obnovení.

Pět pravomocí skrytých ve slově dohled

Pomáhá vzít pět praktických pravomocí článku 14 jednu po druhé. První je porozumění. Role dohledu nemůže fungovat na základě sloganu typu model je obvykle přesný. Role potřebuje zamýšlený účel, známá omezení, vstupní podmínky, relevantní důkazy o výkonnosti, režimy selhání, politiku aktualizací a význam výstupu ve skutečném pracovním postupu. Porozumění není totéž co přečtení modelového listu. Je to schopnost rozpoznat, kdy živý případ spadá mimo podmínky, za kterých byl systém vyhodnocen.

The second is monitoring. Monitoring is often reduced to uptime, latency and a model score. Those measures matter, but a service can be available and wrong. A model can retain its aggregate performance while a source collection becomes stale, a language distribution changes, a policy deadline passes or a downstream team starts using a recommendation as an automatic decision. Operational monitoring follows the consequence. It looks for unexpected performance, changes in the inputs, changes in the route, unusual override patterns, blocked cases, complaints and signs that the system is being asked to do a job it was not given.

The third is interpretation. A person cannot exercise oversight if the output arrives without its conditions. Interpretation may require the relevant source, confidence information, policy version, input quality signal, explanation method or comparison with a safe baseline. It does not require a mystical view into every parameter. It requires enough context to answer the question the person is responsible for: what does this output mean here, what does it not mean, and what should happen if the evidence is insufficient?

The fourth is refusal and reversal. Article 14 explicitly gives the oversight role the ability to decide not to use the system, disregard its output, override it or reverse it. This is stronger than asking a person to add a comment after accepting the result. It means the workflow must allow a different decision to survive. The alternative must not be treated as an exception that disappears in the next automated step. If a human can disagree but the system will execute the original recommendation anyway, the human has been invited to express an opinion, not given oversight.

The fifth is interruption. Interruption acts on the operation itself. It may stop a tool call before an external change, place a case on hold, prevent new work from entering a route, revoke a permission or switch the service to a bounded fallback. The technical method varies. The safety property does not: the operation must come to a defined state in which the next consequential action cannot happen by momentum alone.

These powers are related but not interchangeable. A person may understand a system but lack the rights to stop it. A person may have a stop button but no useful signal that tells them when to press it. A person may override one result while a batch process continues to produce the same result for everyone else. A person may halt intake while existing jobs keep writing to an external system. The oversight design has to connect the powers across the actual lifecycle of work.

That connection is also where the human role becomes dignified. The reviewer is not there to absorb the system's uncertainty with a signature. The reviewer is there to exercise a bounded authority that the organisation has deliberately made possible. The work may still be difficult. It may require domain expertise, judgement and courage to challenge a popular system. But difficulty is not a reason to hide the control. It is a reason to specify it.

Who gets the key?

There is no single human in the loop. There are usually several authorities, each with a different reason to intervene. The provider controls parts of the design and release. The deployer controls the purpose, configuration and operational use. The person assigned to oversight controls a particular decision or intervention at runtime. A domain owner controls whether an output is acceptable in a professional context. A security or privacy role may control access to evidence or data. An affected person may have a right to challenge an outcome. A competent authority may require information, corrective action or withdrawal. Treating all of these as one role makes the system sound simple and the accountability impossible.

Odpovědnost poskytovatele začíná dříve, než se systém dostane k uživateli. Poskytovatel rozhoduje o tom, které ovládací prvky jsou zabudované, která omezení jsou zdokumentovaná, jaké protokoly lze vytvářet a které změny se považují za podstatné. Poskytovatel, který tvrdí, že nasazující strana může systém jednoduše monitorovat, musí ukázat, jak to nasazující strana může udělat s dodaným rozhraním a informacemi. Pokud zastavení závisí na nedokumentovaném interním příkazu nebo na lístku podpory s nejistou odezvou, není zastavení schopností nasazující strany. Je to naděje, že dodavatel zůstane vzhůru.

Nasazující strana má jinou pravomoc. Nasazující strana rozhoduje o tom, kde se systém používá, k jakému účelu, s jakými daty, v jakém pracovním postupu a s jakými lidmi odpovědnými za dohled. Nasazující strana může změnit poradenský výstup na faktické rozhodnutí prostřednictvím návrhu rozhraní, pobídek nebo tlaku, i když poskytovatel systém pečlivě popsal. Nasazující strana proto potřebuje zmapovat místní cestu, ne pouze opakovat zamýšlený účel dodavatele. Stejná součást může mít jiný profil rizika, když je připojena k jiné akci.

Role dohledu za běhu potřebuje užší a jasnější pověření. Tato osoba může mít povoleno držet případ, odmítnout doporučení, vyžádat si další důkazy, postoupit věc vlastníkovi domény nebo aktivovat bezpečné zastavení. Nesmí mít povoleno měnit model, mazat důkazy, činit právní rozhodnutí nebo obnovit pozastavenou cestu. Tyto hranice nejsou urážkou této role. Zabraňují tomu, aby osoba, která může zastavit proces, mohla také vymazat důvod jeho zastavení.

Pravomoc by měla následovat důsledek. Recenzent, který může pozastavit návrh, nemusí mít možnost pozastavit všechny cesty v organizaci. Osoba, která může zastavit činnost související s bezpečností, může potřebovat přístup k širšímu incidentnímu týmu a jasnou povinnost informovat. Doménový odborník může být jedinou osobou oprávněnou zvrátit výstup v regulovaném rozhodnutí. Bezpečnostní operátor může mít možnost izolovat službu, zatímco jiná autorita rozhoduje, zda by se používání mělo obnovit. Důležité není vytvářet velkou hierarchii. Důležité je učinit předávání odpovědnosti explicitním.

Postupování na vyšší úroveň nesmí být zaměňováno se vzdáním se odpovědnosti. Pokud první recenzent předává každý obtížný případ výboru, systém nezískal dohled. Získal pomalejší frontu. Cesta postupu by měla říkat, jaká otázka se postupuje, jaká práce je pozastavena, dokud čeká na odpověď, kdo musí odpovědět, jaké důkazy cestují s případem a co se stane, pokud cesta není k dispozici. První osoba zůstává odpovědná za zachování případu a použití bezpečného výchozího stavu. Není povinna vymyslet konečnou odpověď sama.

Pravomoc také potřebuje cestu návratu. Zastavení bez způsobu, jak předat řízení zpět, se stane buď trvalým výpadkem, nebo tichým obejitím. Cesta návratu by měla jmenovat, kdo může obnovit, jaké podmínky musí být splněny, zda zachycený stav zůstává platný, která čekající práce potřebuje nové vyhodnocení a jak jsou uživatelé informováni, že se cesta změnila. Obnovení je další rozhodnutí. Zaslouží si stejnou vážnost jako přerušení, i když málokdy dostane stejně atraktivní tlačítko.

Zastavení musí být bezpečné

Slovní spojení bezpečný stav z nařízení o umělé inteligenci si zaslouží více pozornosti než hardwarová představa tlačítka zastavení. Systém může přestat odesílat nové požadavky a přesto nechat nebezpečnou práci v pohybu. Může ukončit proces uprostřed transakce. Může opustit výstup, aniž by řekl osobě, která čekala na rozhodnutí. Může zakázat viditelné rozhraní, zatímco naplánovaná úloha pokračuje na pozadí. Může zastavit model a nechat doporučení z mezipaměti k dispozici další službě. Zastavení je bezpečné pouze ve vztahu ke skutečným účinkům systému.

Definujte stavy dříve, než zvolíte řízení. Běžící trasa může přijímat, vyhodnocovat, doporučovat a jednat. Podržená trasa nesmí přijímat nic nového, ale musí zachovat již přijatý materiál. Zastavená trasa může odmítnout veškerou zásadní práci a zároveň umožnit autorizovanou kontrolu. Degradovaná trasa může poskytovat omezenou službu pouze pro čtení nebo pouze pro lidi. Stažená trasa může před návratem vyžadovat nové schválení. Toto jsou návrhová rozhodnutí, nikoli univerzální názvy. Stanou se užitečnými, když lidé vidí, v jakém stavu se nacházejí a co každý stav umožňuje.

Probíhající práce potřebuje vlastní pravidlo. Některé operace jsou vratné a mohou bezpečně skončit. Některé již překročily vnější hranici a potřebují kompenzační opatření. Některé musí být zahozeny a regenerovány, protože důkazy již nejsou důvěryhodné. Některé mají nízký dopad a mohou zůstat jako koncepty. Systém by neměl nutit operátora hádat z jediného stavového štítku. Měl by zobrazit sadu prací, její přechodový bod a akci, která nastane, pokud se neudělá nic jiného.

Bezpečný stav také chrání důkazy. Zastavení systému smazáním jeho dočasných souborů může odstranit právě ten kontext, který je potřebný k pochopení selhání. Zastavení tím, že v širokém diagnostickém exportu zůstanou tajemství, může vytvořit druhý incident. Řízení potřebuje cestu pro zachování důkazů s hranicemi přístupu, pravidly uchovávání a jmenovaným vlastníkem. Bezpečnost a soukromí zde nejsou rivaly. Obě vyžadují promyšlené zacházení, nikoli známou nouzovou praxi kopírování všeho do složky s názvem urgent.

Testování zastavení je součástí nasazení systému. Tlačítko, které bylo kliknuto pouze v demonstraci, dokazuje, že na tlačítko lze kliknout. Nedokazuje, že se příjem zastaví, akce se uklidní, záznamy zůstanou konzistentní, oznámení se dostanou ke správným lidem nebo že restart nezopakuje práci dvakrát. Test by měl procvičit skutečnou trasu, včetně částečného selhání a operátora, který má zamýšlenou autoritu, ale ne soukromé znalosti vývojáře. Pokud zastavení nelze nacvičit bez zvláštního výkonu, není to dosud provozní řízení.

Fronta je součástí rozhodnutí

Zastavení systému AI je často představováno jako zastavení modelu. V praxi je fronta kolem modelu součástí rozhodnutí. Práce může čekat na vstup, čekat na výsledek modelu, čekat na lidskou kontrolu, čekat na navazující nástroj nebo čekat na oznámení. Každá pozice má jiné riziko. Zastavení, které chrání pouze model, může umožnit okolní frontě, aby nadále považovala staré výstupy za platné.

Čekající práce potřebuje politiku. Dostane nový požadavek jasné odmítnutí, oznámení o zpoždění nebo lidskou trasu? Zůstává výsledek vytvořený před zastavením použitelný? Jsou případy, které ještě nebyly zkontrolovány, označeny jako vyžadující nové vyhodnocení? Rozlišuje systém práci pozastavenou člověkem od práce, která technicky selhala? Může uživatel odvolat požadavek, dokud je podržen? Podrobnosti závisí na službě, ale rozhodnutí nelze ponechat na výchozím chování fronty při opakování.

Opakování jsou obzvláště odhalující. Technická fronta často předpokládá, že operace, která nebyla dokončena, by měla být znovu pokusena. Správní fronta nemůže předpokládat, že stejné doporučení by mělo být vytvořeno znovu poté, co je důvodem zastavení nejistota, rozsah nebo potenciální škoda. Opakování může být bezpečné pro idempotentní čtení a nebezpečné pro vnější akci. Politika zastavení by proto měla nést důvod a povolený další krok, nikoli pouze červený stav.

Stávající výstupy potřebují klasifikaci. Některé jsou návrhy, na které se žádný člověk nespoléhal. Některé byly ukázány pracovníkovi. Některé byly zkopírovány do záznamu o rozhodnutí. Některé spustily oznámení nebo změnily systém mimo cestu AI. Organizace nemůže rozhodnout, co s nimi udělá, dokud neví, kterou hranici každý výstup překročil. Proto není sledovatelnost jen administrativní ozdobou. Je mapou důsledků, které musí zastavení obsáhnout.

Fronta také mění lidskou pracovní zátěž. Zastavení může chránit lidi před nebezpečnou automatizovanou akcí, ale zároveň vytváří velké množství revizní práce. Tuto práci je třeba uznat, prioritizovat a zajistit pro ni zdroje. Jinak organizace nakonec cestu znovu otevře, protože zadržené případy se staly nepohodlnými, ne proto, že se zlepšily důkazy. Pauza, která pouze přesune újmu do vyčerpané manuální fronty, je odklad s dobrými úmysly.

Není žádná ostuda, když se fronta zpomalí, pokud je alternativou neprozkoumaný důsledek. Problém návrhu nastává, když fronta nemá model kapacity, žádné pravidlo třídění a žádný způsob, jak postiženým lidem sdělit, co se děje. Lidský dohled není bezplatná pozornost. Je to provozní služba s omezeními, která by měla být známa dříve, než je stroj požádán o běh ve velkém měřítku.

Po zastavení paměť

Zastavení je událost, která mění to, co organizace ví a co je povinna udělat. Záznam by měl obsahovat spouštěč, čas, cestu, stav před zásahem, použitou pravomoc, rozsah pozastavení, dotčenou práci, zachycené důkazy, provedená oznámení a podmínky pro přezkum. Měl by rozlišovat pozorování od závěru. Operátor může zaznamenat, že výstup nebyl v souladu s dodanými důkazy, aniž by tvrdil, že byl prokázán incident. Přesnost v záznamu chrání jak vyšetřování, tak zúčastněné osoby.

Nařízení o umělé inteligenci považuje vedení záznamů za technickou vlastnost systémů s vysokým rizikem. Článek 12 vyžaduje, aby takové systémy umožňovaly automatické zaznamenávání událostí po celou dobu jejich životnosti, s možnostmi protokolování, které podporují sledovatelnost, identifikaci rizik, monitorování po uvedení na trh a monitorování provozu. Článek 19 se zabývá uchováváním automaticky generovaných protokolů pod kontrolou poskytovatele, s ohledem na zamýšlený účel a platné právní předpisy o ochraně údajů. To je užitečná připomínka, že zastavení nemůže záviset na snímku obrazovky sestaveném dodatečně. Systém musí být schopen zanechat stopu, zatímco funguje.

Protokolování není pokyn ke shromažďování všech osobních údajů navždy. Je to požadavek zaznamenávat události relevantní pro účel a riziko. Dobrý záznam o zastavení může používat odkazy, hashe, identifikátory verzí, redigovaný obsah a samostatné kontroly přístupu. Může uchovávat vstup potřebný pro přehrání v chráněném úložišti, spíše než jej umisťovat do běžného dashboardu. Mělo by být možné vyšetřovat, aniž by se úložiště důkazů stalo druhým nekontrolovaným datovým prostředím.

Povinnost poskytovatele přijmout nápravná opatření je také důležitá. Pokud se poskytovatel domnívá, nebo má důvod se domnívat, že systém s vysokým rizikem není v souladu s předpisy, nařízení vyžaduje nezbytná nápravná opatření, která mohou zahrnovat uvedení do souladu, stažení z trhu, deaktivaci nebo odvolání podle potřeby. Volba není marketingové rozhodnutí. Je to reakce vázaná na důkazy, rozsah a riziko. Nasaďovatel může potřebovat zastavit místní cestu dříve, než poskytovatel dokončí toto posouzení. Poskytovatel může potřebovat deaktivovat nebo stáhnout cestu, kterou nasaďovatel nadále provozuje. Obě autority musí být schopny komunikovat, aniž by ztratily důkazy, které změnu vysvětlují.

Monitorace po uvedení na trh rozšiřuje paměť za hranice jedné události. Nařízení popisuje systém, který aktivně a systematicky shromažďuje, dokumentuje a analyzuje relevantní údaje po celou dobu životnosti systému s vysokým rizikem. Smyslem není, aby poskytovatel zíral na přehledovou obrazovku. Smyslem je zjistit, zda systém nadále vyhovuje požadavkům a zda se nezměnil kontext kolem něj. Zastavení může být prvním užitečným signálem v tomto procesu. Řada drobných zásahů může o vhodnosti systému vypovědět více než jediné úhledné hodnocení při uvedení.

Závažné incidenty mají v nařízení vlastní ohlašovací cestu, včetně povinnosti vyšetřit je a přijmout nápravná opatření po ohlášení. Článek nepřeměňuje každé přepsání rozhodnutí na závažný incident. Tento rozdíl je podstatný. Provozovatel, který zvrátí doporučení, může uplatňovat zdravou kontrolu, nikoli objevovat ohlašovací povinnost. Záznam by měl uchovat dostatek informací, aby se organizace mohla rozhodnout, co se stalo, místo aby každý nesouhlas tlačil buď do mlčení, nebo do dramatického označení.

Eskalace je řízený přenos otázky, ne zdvořilý způsob, jak nechat odpovědnost zmizet.

Eskalace je cesta, ne nálada

Lidé často říkají, že obtížný případ by se měl eskalovat. Tato formulace zní odpovědně, ale neobsahuje téměř žádné provozní informace. Komu eskalovat? K jakému rozhodnutí? S jakými důkazy? V jakém čase? Co se drží, dokud odpověď nepřijde? Co se stane, když nikdo neodpoví? Cesta, která na žádnou z těchto otázek neodpovídá, odmění spíše vytrvalost než úsudek. Případ se bude buď předávat, dokud se lhůta nestane rozhodnutím, nebo se tiše vrátí tomu, kdo problém poprvé zaznamenal.

Užitečná eskalace začíná otázkou. Je výstup mimo schválený účel? Jsou důkazy neúplné? Změnil se systém od hodnocení? Existuje riziko pro základní právo? Došlo již k nějakému vnějšímu zásahu? Je problém technický, právní, doménově specifický, bezpečnostní nebo jejich kombinace? Otázka určuje, která role na ni může odpovědět. Eskalace, která posílá stejný nerozlišený případ každému týmu, není důkladná. Je to skupinový e-mail s budoucím časem.

Role místního dohledu by měla mít bezpečný výchozí stav, dokud je otázka otevřená. Tím může být pozastavení, odmítnutí, návrat k čistě lidské cestě, uchování návrhu nebo omezení systému na režim pouze pro čtení. Výchozí stav by měl být viditelný pro danou osobu a případně i pro dotčeného uživatele. Ticho není bezpečným výchozím stavem, pokud pracovní postup pod ním dál běží.

Důkazy musí putovat společně s eskalací. Přijímající role by neměla muset rekonstruovat případ z výstupu modelu a časového razítka. Měla by obdržet příslušný odkaz na vstup, výstup, verze modelu a politik, zdrojový materiál, signál spolehlivosti nebo nejistoty, stav akce, předchozí zásahy a přesné rozhodnutí, které je potřeba učinit. Právě zde také platí disciplína ochrany soukromí. Pošlete dostatek informací k zodpovězení otázky, ne celý život člověka jen proto, že bylo tlačítko exportu poblíž.

Eskalace potřebuje časový rámec, ale ne každý časový rámec je lhůtou ke schválení. Nízkozávažná otázka může počkat na běžnou kontrolu. Vysoce závažná akce může vyžadovat okamžité pozastavení a pohotovostní cestu. Pravidlo časování by mělo říkat, co se stane, když okno pro odpověď vyprší. Může prodloužit pozastavení, přenést pravomoc, upozornit nadřízeného nebo vyžadovat nové rozhodnutí. Nemělo by tiše přeměnit chybějící odpověď na svolení.

Uzavření je součástí eskalace. Záznam by měl říkat, co bylo rozhodnuto, kým, na základě jakých důkazů, s jakými omezeními a jaké následné kroky budou následovat. Pokud je odpovědí, že systém může pokračovat pouze v užším kontextu, měla by být nová hranice uplatněna, ne pouze obdivována. Pokud je odpovědí, že systém musí být stažen, potřebují dotčená práce a uživatelé plán. Pokud je odpovědí, že anomálie byla neškodná, měly by důkazy stále informovat monitorování a školení. Eskalace, která zmizí po schůzce, se nestala institucionální znalostí.

Dobrá eskalace také chrání osobu, která problém vznesla. Pravomoc zastavit systém je k ničemu, pokud je její použití považováno za neloajalitu. Organizace učí své skutečné priority tím, co se stane poté, co někdo řekne ne. Pokud je reakcí zvědavost, důkazy a podpora, lidé se naučí, že dohled je součástí práce. Pokud je reakcí obviňování, průtahy a žádost o pozitivnější přístup, systém obdrží méně varování a varování, která obdrží, přijdou později.

Lidský dohled je pracovní zátěž

Odkaz zákona na kompetence, školení a pravomoc lze snadno číst jako požadavek na personální oddělení. Je to také požadavek na kapacitu. Člověk nemůže efektivně monitorovat systém umělé inteligence, pokud rozhraní ukazuje příliš mnoho šumu, fronta nenechává čas na kontrolu, důkazy přicházejí v jiném nástroji, rozhodnutí jsou měřena pouze rychlostí nebo organizace přidělila práci někomu bez doménových znalostí. Role může existovat na papíře a přesto být nevykonatelná.

Školení by mělo zahrnovat omezení systému, schválený účel, známky neočekávaného výkonu, význam nejistoty, mechanismy přepsání a zastavení, soukromí důkazů a cestu po zásahu. Mělo by zahrnovat případy, kdy výstup vypadá věrohodně. Dohled je nejvíce potřeba, když odpověď není natolik absurdní, aby byla okamžitě odmítnuta. Kurz, který učí lidi rozpoznat karikaturně špatnou odpověď, je připravuje na demonstraci, ne na fungující službu.

Automatizační zaujatost si zaslouží praktickou pozornost. Doporučení se může stát ukotvením dříve, než recenzent přečte podpůrné důkazy. Štítek s mírou jistoty může být interpretován jako pravděpodobnost, i když jí není. Vyleštěné vysvětlení může působit jako nezávislé potvrzení, i když jde jen o přeformulování. Pořadí v rozhraní záleží. Pokud systém nejprve zobrazí svou odpověď a teprve poté důkazy, může recenzent strávit zbytek procesu obhajováním nebo opravováním prvního dojmu. Ovládací prvek pro zastavení, který je skrytý za stejným pracovním postupem jako schválení, také vypovídá o tom, jakou akci organizace očekává.

Limity pracovního vytížení jsou bezpečnostními kontrolami. Recenzent, který musí projít velkou frontu, se může naučit považovat výchozí hodnotu modelu za nejrychlejší bezpečnou volbu. Specialista, který dostává každý nejednoznačný případ, může začít schvalovat jen proto, aby služba běžela dál. Malý tým, který vlastní pohotovostní trasu zastavení, může být nedostupný v hodinách, kdy systém skutečně běží. Toto nejsou osobní selhání. Jsou to předvídatelné reakce na provozní návrh, který od lidského úsudku vyžaduje, aby kompenzoval neomezenou automatizaci.

Měřte samotnou práci dohledu. Jak často jsou výstupy přepsány? Jak často je pokus o zastavení? Které signály vedou k zásahu? Jak dlouho zůstávají pozastavení otevřená? Které skupiny nebo jazyky generují více nejistoty? Kolik oprav je potřeba, než lze výstup použít? Metriky nenahrazují úsudek, ale mohou odhalit, že slibovaná kontrola se stává pouhým razítkem. Cílem není trestat vysokou míru přepsání. Cílem je ptát se, co nám tato míra říká o systému a pracovním postupu.

Evropské bezpečnostní tradice to už znají

Evropský politický jazyk o důvěryhodné umělé inteligenci nezačal zákonem o umělé inteligenci. V roce 2019 zveřejnila skupina odborníků na vysoké úrovni Evropské komise pro umělou inteligenci etické pokyny pro důvěryhodnou umělou inteligenci. Pokyny označují lidskou činnost a dohled za jeden ze sedmi požadavků a popisují přístupy human-in-the-loop, human-on-the-loop a human-in-command. Rovněž spojují dohled s technickou robustností, záložními plány, transparentností, sledovatelností a odpovědností. Důležitý není slovník. Důležité je rozhodnutí popsat důvěryhodnost jako soubor podmínek, které lze posoudit.

Pozdější hodnotící práce Komise dává organizacím způsob, jak tyto podmínky přeměnit na otázky. Vědí lidé, že interagují se systémem umělé inteligence? Rozumějí schopnostem a omezením systému? Mohou zasáhnout a rozhodnout se systém nepoužívat? Existují mechanismy pro nápravu? Kontrolní seznam neudělá provoz bezpečným. Ztěžuje ale předstírání, že osoba pověřená dohledem je automaticky osobou oprávněnou jej vykonávat.

Práce agentury ENISA v oblasti kybernetické bezpečnosti umělé inteligence přistupuje k tématu prostřednictvím životního cyklu a ekosystému kolem modelu. Její mapa hrozeb pro umělou inteligenci z roku 2020 mapuje aktiva, aktéry, hrozby a fáze od požadavků až po nasazení. Tato perspektiva je pro zastavení cenná, protože to, co je třeba izolovat, nemusí být model. Může to být zdroj dat, oprávnění nástroje, balíček pro nasazení, monitorovací cesta nebo komponenta dodavatele. Zastavení navržené kolem názvu modelu může ponechat skutečnou schopnost nedotčenou jinde v řetězci.

Toto jsou zdokumentované evropské přístupy, nikoli tvrzení, že Evropa vyřešila dohled. Pokyny a zákon stanovují očekávání. Agentura ENISA mapuje bezpečnostní problém. Práce na implementaci zůstává místní, technická a nevyhnutelně všední. Někdo stále musí rozhodnout, která role může držet trasu ve tři odpoledne, které důkazy se objeví na jeho obrazovce a kdo odpovídá, když bylo zastavení použito.

Zadávání veřejných zakázek rozhoduje dříve než operátoři

Mnoho selhání při zastavení systému je rozhodnutím z oblasti nákupu, které se vydává za provozní záležitost. Smlouva může dodavateli umožnit změnit model bez použitelného oznámení. Služba nemusí zpřístupňovat logy ani identifikátor verze. Export může vynechávat čekající práci a historii zásahů. Smlouva o podpoře nemusí nabízet žádnou cestu pro reakci na bezpečnostní pozastavení. Kupující mohl přijmout obecné prohlášení, že za použití odpovídá zákazník, aniž by získal kontrolní mechanismy potřebné k výkonu této odpovědnosti. Ve chvíli, kdy operátor požádá o vypínač, už smlouva rozhodla, zda existuje.

Nákup by proto měl klást provozní otázky. Která strana může deaktivovat jednotlivé trasy? Může nasazující pracovník zastavit závažnou akci bez čekání na podporu dodavatele? Co se stane s probíhající a zařazenou prací? Jaký stav je zachycen? Jak jsou změny oznamovány? Může zákazník získat logy a důkazy v použitelném formátu? Jaké je záložní řešení, když služba není dostupná? Které role jsou proškoleny a kdo financuje toto školení? Jak je opraven sporný výstup? Jak organizace odejde, aniž by ztratila záznamy potřebné k vysvětlení předchozích rozhodnutí?

Tyto otázky nejsou pokusem přimět každého dodavatele, aby se choval jako veřejný orgán. Jsou způsobem, jak udržet pravomoc v souladu s používáním. Pokud organizace nese povinnost chránit osoby dotčené systémem, potřebuje dostatečnou kontrolu nad trasou, aby tuto povinnost mohla plnit. Smlouva, která ponechává odpovědnost na zákazníkovi, ale zbavuje ho provozní moci, není modelem řízení. Je to přenos odpovědnosti s logem.

Krátká poznámka od nás

Ve společnosti Dweve naše práce na stavově založené odpovědné umělé inteligenci zdůrazňuje z inženýrské strany stejný skromný bod: odpovědný pracovní postup má pojmenované stavy, ochrany, záznamy, vlastníky a výstupy. To není tvrzení, že diagram může vyřešit řízení. Je to připomínka, že principy potřebují místo, kde se uchytí, když systém běží. Ať už je nástrojem komponenta Dweve, služba veřejného sektoru nebo model dodavatele, test je stejný. Může skutečný člověk vidět problém, vykonat pravomoc, zastavit další následek, uchovat důkazy a vrátit práci do obhajitelného stavu?

Otázky před nasazením

Než model vstoupí do závažného pracovního postupu, položte otázky týkající se zastavení v místnosti, kde bude systém skutečně fungovat. Nenechávejte je na přezkumu politik, který nikdy neuvidí frontu, bránu nástrojů ani osobu, která obdrží upozornění.

  • Co přesně lze zastavit? Uveďte trasu modelu, volání nástroje, frontu, oznámení, zápis a navazující službu. Pokud je odpovědí pouze proces modelu, hledejte schopnost, která zůstane zachována i po jeho zastavení.
  • Kdo to může zastavit, aniž by se ptal tvůrce? Uveďte roli za běhu, její oprávnění, její zálohu a její omezení. Dotyčná osoba by k použití ovládacího prvku neměla potřebovat soukromé znalosti o implementaci.
  • Jaký signál jim řekne, že mají jednat? Definujte anomálie, chybějící důkazy, konflikt rozsahu, nepřijatelnou nejistotu, změnu zásad, bezpečnostní obavy a námitku uživatele způsobem, který může operátor pozorovat.
  • Co se stane s prací, která již probíhá? Oddělte nové příchozí požadavky, čekající práci, probíhající operace, výstupy zobrazené lidem a již provedené akce. Každé z nich přiřaďte bezpečné zacházení.
  • Jaký je bezpečný stav? Popište, co systém po přerušení přijímá, odmítá, drží, dokončuje nebo zveřejňuje. Ověřte, že je stav skutečný, a ne jen popisek na obrazovce.
  • Jaké důkazy přetrvají? Zachovejte příslušný vstup, výstup, verze, zásady, odkazy na zdroje, lidské akce, načasování a oznámení s odpovídajícími kontrolami soukromí.
  • Kdo obdrží eskalaci? Uveďte rozhodovací otázku, lhůtu pro odpověď, balíček důkazů a výchozí stav během čekání. Rozesílací seznam není mapa odpovědnosti.
  • Kdo může trasu obnovit, zúžit nebo odebrat? Rozhodnutí o návratu explicitně uveďte. Určete podmínky, opětovné vyhodnocení, komunikaci s uživatelem a spouštěč přezkumu, které ho doprovázejí.
  • Co vám řekne, že ovládací prvek selhává? Sledujte vzorce obcházení, dobu držení, opakované incidenty, nerovnoměrné dopady, tlak ve frontě, stížnosti uživatelů a odchylky v okolním pracovním postupu. Zřídka používané zastavení může znamenat bezpečný systém nebo skrytý ovládací prvek.

Otázky jsou záměrně prosté. Nenahrazují posouzení rizik, proces shody, plán řešení incidentů ani právní přezkum. Jsou bodem, ve kterém se tyto činnosti stávají provozními. Pokud na ně organizace nedokáže odpovědět, chybějící práce není filozofický spor o tom, zda lze AI důvěřovat. Je to chybějící součást systému.

Oprávnění zastavit je oprávnění pečovat

Model se může mýlit způsobem, který vypadá běžně. Zdroj je starý. Vstup je neúplný. Trasa se rozšířila. Práh byl posunut. Překlad změnil význam. Oprávnění nástroje přežilo svůj účel. Recenzentovi se zobrazí závěr, ale ne důkazy. Žádný poplach se nespustí, protože systém je stále dostupný a přístrojová deska je stále zelená. Škoda začíná jako malý nesoulad mezi tím, co systém směl dělat, a tím, co od něj organizace nyní očekává.

Lidský dohled je odpovědí instituce na tento nesoulad, ale pouze tehdy, pokud je víc než jen přítomnost. Role dohledu potřebuje znalosti k rozpoznání problému, čas k jeho prošetření, oprávnění odmítnout nebo přerušit, bezpečný stav, který činí přerušení smysluplným, a záznamy, které ostatním umožní pochopit, co se stalo. Potřebuje eskalaci, která nese otázku a důkazy, ne vágní žádost o pomoc. Potřebuje obnovení, které je rozhodnutím, ne koncem výpadku.

Evropský akt o umělé inteligenci správně používá jazyk zásahu a bezpečného zastavení pro vysoce rizikové systémy. Dává správě hmatatelný rozměr. Žádá lidi, kteří systémy navrhují a nasazují, aby umožnili lidskou kontrolu během používání, ne pouze obdivuhodnou v zásadě. Dřívější práce Komise na důvěryhodné umělé inteligenci a přístup ENISA k životnímu cyklu posilují stejný směr: dohled patří do provozu systému, jeho důkazů a jeho okolního dodavatelského řetězce.

Ve společnosti Dweve dáváme přednost neromantické verzi této myšlenky. Seriózní systém by měl znát své stavy, své meze a svého vlastníka. Měl by umět držet práci, ukázat, proč ji drží, a poctivě se zastavit, když důkazy nestačí. To není zvláštní ctnost jedné architektury. Je to minimální respekt vůči lidem, kteří musí žít s výsledkem.

Když se model mýlí, rozhodující otázkou není, zda byl člověk technicky přítomen. Je to, zda pojmenovaná lidská autorita mohla změnit to, co se stalo dál, a zda si organizace tuto změnu dokázala zapamatovat. Pokud je odpověď ano, dohled plní svou funkci. Pokud je odpověď ne, systém má poblíž člověka, někde tlačítko a žádnou brzdu.

Zdroje