A felelős AI állapotgépe

A felelős AI állapotgépe

A form, amely nem futott le

Az első felelős MI-műhely gyakran egy formanyomtatvánnyal zárul. A formanyomtatvány általában csinos, ahogyan a belső űrlapok csinosak tudnak lenni, amikor egy bizottság felfedezi a térközöket. Kérdez a célról, a hatásról, az adatokról, a kockázatról, az elfogultságról, az emberi felügyeletről, a szállítói függőségről, a megőrzésről és az eszkalációról. Az emberek gondosan töltik ki. Egy négyzet be van pipálva. Egy felülvizsgáló bizottság bólint. Egy projekt előrelép. Valahol egy mappa kap egy újabb dokumentumot, és egy kicsit jobban hisz magában.

Három hónappal később a rendszer élesben fut, és a formanyomtatvány már nem ott van, ahol a dolgok történnek. Egy támogatási kérelem érkezik hiányzó mezőkkel. Egy modell magabiztos választ ad gyenge bizonyítékokkal. Egy eszközhívás frissítene egy ügyfélrekordot. Egy szabályzat megváltozik a tervezet és a végső művelet között. Az emberi felülvizsgáló beteg. A keresési index elavult. Új adatforrást javasolnak, mert kényelmes lenne, és így mutatkoznak be udvariasan sok rossz ötlet.

Ebben a pillanatban a felelős MI nem elv. Állapotátmenet. A rendszer egy állapotban van, és egy másikba szeretne kerülni. Tervezettől a döntésig. Javaslattól a cselekvésig. Alacsony hatástól a magas hatásig. Belső segédeszköztől a külső kommunikációig. Felülvizsgálttól a végrehajtottig. Engedélyezettől a blokkoltig. Ideiglenes kivételtől a végleges útvonalig, ha senki sem figyel. A kérdés az, hogy az átmenetnek van-e védelme, nyilvántartása, felelőse és kilépési útvonala.

Ez az állapotgép a felelős MI mögött. Nem azért, mert az etika visszavezethető négyzetekre és nyilakra. Ezt furcsa lenne elhinni, és még furcsább lenne beszerezni. A lényeg egyszerűbb. A komoly rendszerek már eleve állapotokon haladnak keresztül. Ha ezek az állapotok névtelenek, a modell akkor is mozogni fog, a munkafolyamat akkor is haladni fog, és a szervezet véletlenül fedezi fel a saját irányítási rendszerét. Az állapotok elnevezése nem bürokratikus hűhó. Így kap a felelősség futásidőbeli formát.

Miért van szükségük az elveknek határokra

Az elvek az elején hasznosak, mert irányt adnak. Méltányosság, átláthatóság, elszámoltathatóság, adatvédelem, biztonság, emberi önállóság, robusztusság, megtámadhatóság. Ezek a szavak nem üresek. De önmagukban nem végrehajthatók. Egy rendszer nem tud egy elvet futásidőben meghívni, és megkérdezni, hogy a következő művelet megengedett-e. Egy fejlesztő írhat egy utasítást, amely azt mondja, légy méltányos, de a munkafolyamatnak így is tudnia kell, mikor kell megállni, mikor kell kérdezni, mikor kell rögzíteni, és mikor kell megtagadni.

Az élek azok a pontok, ahol az elvek hasznossá válnak. A méltányosság elvéből követelmény lesz, hogy bizonyos döntési kategóriáknak csoportszintű értékelésen kell átesniük a kibocsátás előtt, és esetszintű indoklási kódokat kell produkálniuk a kibocsátás után. Az átláthatóság elvéből nyugta lesz, amely megnevezi a forrásokat, a modellverziót, a szabályzatverziót és az emberi szerepet. A magánélet védelmének elvéből védőburok lesz, amely megtagadja az adatok lekérését a cél, a megőrzési idő, a hozzájárulás vagy a jogalap hiányában. Az elszámoltathatóságból olyan állapot lesz, amely tulajdonos nélkül nem léphet tovább. A megtámadhatóságból fellebbezési út lesz, amely az első panasz előtt létezik, nem pedig az első újságcikk után.

Élek nélkül a felelős mesterséges intelligencia jelzők halmazává válik egy olyan rendszer körül, amely továbbra is úgy viselkedik, ahogy a munkafolyamat engedi. Egy csapat őszintén hiheti, hogy emberi felügyelet van, mert egy személy ránézhet az eredményekre. De ha a rendszer képes cselekedni, mielőtt az illető látta volna a bizonyítékokat, a felügyelet csak díszlet. Egy csapat hiheti, hogy átláthatóság van, mert a modell magyarázza önmagát. De ha a magyarázat nem köthető forrásokhoz és állapothoz, az átláthatóság színházzá válik. Egy csapat hiheti, hogy biztonságban van, mert a modell visszautasítja a veszélyes utasításokat. De ha az eszközkapu széles jogosítványokat ad, az elutasítás csak egyetlen ajtó egy olyan házban, amelynek nagyon lelkes ablakai vannak.

Az állapotgép nem helyettesíti az ítélőképességet. Ez egy mód arra, hogy az ítélőképességnek helye legyen. Arra kényszeríti a csapatot, hogy gyakorlati kérdésekre válaszoljon. Milyen állapotban van ez az eset. Mely átmenetek lehetségesek innen. Milyen bizonyíték szükséges. Melyik szerepkör hagyhatja jóvá. Melyik átmenet visszafordíthatatlan. Melyik átmenet hoz létre nyilvántartást. Melyik átmenet hoz létre értesítési, megőrzési, törlési vagy eszkalációs kötelezettséget. Ezek a kérdések kevésbé költőiek, mint az értéknyilatkozatok. De nehezebb is kikerülni őket.

A rejtett gép mindig létezik

Minden mesterséges intelligencia munkafolyamatnak már van állapotgépe, még akkor is, ha senki sem rajzolta meg. A rejtett változat jegyállapotokban, táblázatkezelő oszlopokban, újrapróbálkozási sorokban, utasításágakban, bírálói szokásokban, Slack-üzenetekben, adatbázis-jelzőkben, kivételtáblákban és annak az egy személynek az emlékezetében él, akit mindenki megkérdez, mert ott volt, amikor a kísérleti projekt zajlott. Ez nem elbűvölő elosztott architektúra. Ez intézményi folklór késleltetéssel.

A rejtett gép azért veszélyes, mert az ellenőrzés látszatát kelti, miközben a felelősséget olyan helyekre helyezi át, amelyeket nem lehet felülvizsgálni. Az utasítás azt mondhatja, hogy az érzékeny eseteket eszkalálni kell, de a sor nem biztos, hogy megőrzi az okot. Az esetkezelő rendszer mutathatja, hogy jóváhagyva, de azt nem, hogy a jóváhagyás a modell válaszára, az eszközhívásra vagy a külső kommunikációra vonatkozott-e. Egy bíráló elutasíthat egy eredményt, de az elutasítás soha nem kerülhet be az értékelési halmazba. Egy eset lezárható, de a származtatott adatok továbbra is élhetnek egy jellemzőtárban. Egy modell lecserélhető, de a függőben lévő esetek továbbra is hordozhatják a régebbi verzió eredményeit. A rendszer halad; a nyilvántartás nyakkendőben botorkál utána.

Az állapotgép explicitté tétele nem igényli, hogy a szervezet formális módszertani laboratóriummá váljon. Elég fegyelem kell ahhoz, hogy szétválasszuk azokat az állapotokat, amelyekhez különböző kötelezettségek tartoznak. A piszkozat nem felülvizsgált. A felülvizsgált nem végrehajtott. A végrehajtott nem lezárt. A lezárt nem törölt. A törölt nem archivált. A szabályzat által blokkolt nem infrastruktúra-hiba. Az emberi ítélőképességet igénylő nem alacsony megbízhatóságú. A gyanúsított incidens nem megerősített incidens. Ezek a megkülönböztetések hétköznapinak hangzanak, amíg egy audit meg nem kérdezi, hogy melyik történt, mikor és miért.

A megnevezett állapotok egy másik gyakori automatizációs hibát is megállítanak: a segítségnyújtásból a döntéshozatalba való csendes átcsúszást. A rendszer fogalmazási segédként indul. Az emberek megbíznak benne. A fogalmazvány alapértelmezetté válik. Az alapértelmezett ajánlássá válik. Az ajánlás cselekvéssé válik. Senki nem szavazott a teljes automatizálásra. Senki nem tervezte meg az új elszámoltathatósági felületet. Az átmenet a kényelem révén történt, ami a legsikeresebb lobbista a szoftveriparban. Egy állapotgép kikényszerítheti, hogy ez a mozgás láthatóvá váljon.

A védőfeltételek nem hangulatok

Egy átmenethez védőfeltétel kell. A védőfeltétel az a feltétel, amelynek teljesülnie kell, mielőtt a rendszer továbbléphet. A hétköznapi szoftverekben ez lehet logikai ellenőrzés, szabályzatértékelés, engedélyezési határ, érvényesítési eredmény vagy emberi jóváhagyás. A felelős MI esetében ez az a hely is, ahol az intézményi ígéretek működőképessé válnak. A védőfeltétel azt kérdezi, hogy a cél megengedett-e, az adat a hatókörön belül van-e, a kimenetnek van-e elég bizonyítéka, a modell jóváhagyott-e erre a felhasználásra, a cselekvés visszafordítható-e, a személynek van-e felhatalmazása, a költség korlátos-e, és az érintett felhasználónak van-e visszaútja.

A gyakorlati trükk az, hogy a védőfeltételeket közel tartsuk az átmenethez, amelyet védenek. Ha egy védőfeltétel csak egy szabályzati dokumentumban él, a futásidejű környezet lenyűgöző sebességgel fogja elfelejteni. Ha csak egy promptban él, nehéz lesz tesztelni és könnyű megkerülni. Ha csak emberi szokásban él, akkor betegség, ünnepnapok, átszervezések és azon a héten fog kudarcot vallani, amikor mindenki szállítani próbál. Egy jó védőfeltétel elég kifejezett a teszteléshez és elég lokális ahhoz, hogy számítson.

Ez nem azt jelenti, hogy minden védőfeltételt automatizálni kell. Egyes védőfeltételek emberiek, mert a kérdés valóban kontextuális. De még az emberi védőfeltételeknek is állapotra van szükségük. A felülvizsgálónak látnia kell a bizonyítékokat, az alkalmazandó szabályzatot, a kockázati besorolást, a javasolt cselekvést és a jóváhagyás következményeit. A rendszernek átmenetként kell rögzítenie a döntést, nem pedig megjegyzésként, amelyet a jövőbeli régészet talán felfedez, talán nem. Az emberi felügyelet állapotváltozás nélkül gyakran csak egy találkozó felhasználói felülettel.

Van egy unalmas, de fontos pont a negatív védőfeltételekről is. A felelős MI nem csak arról szól, hogy felelősen mondjunk igent. Arról is szól, hogy világosan mondjunk nemet. Nem, mert hiányzik a cél. Nem, mert a forrás elavult. Nem, mert a modell a jóváhagyott tartományon kívül van. Nem, mert a felhasználónak nincs felhatalmazása. Nem, mert emberi felülvizsgálat szükséges. Nem, mert a cselekvés túl jelentős következményekkel jár a rendelkezésre álló bizonyítékokhoz képest. Az indoklással ellátott elutasítás jobb rendszerállapot, mint egy homályos hiba, amely arra ösztönöz, hogy próbálkozzunk újra, amíg valami el nem mozdul.

Az állapotok teszik hozzárendelhetővé a felelősséget

Az AI-elszámoltathatóság egyik oka válik köddé, hogy a felelősségről az egész rendszer szintjén beszélünk. A szervezet felelős. A szállító felelős. A terméktulajdonos felelős. Az adatvédelmi tisztviselő felelős. A modell felelős, ami egy olyan mondat, amitől egy ügyvéd a plafont bámulja erőért. Futásidőben a felelősségnek kisebb fogantyúra van szüksége.

Az állapotok adják ezt a fogantyút. A befogadás során a szolgáltatás tulajdonosa lehet felelős a célért és a terjedelemért. A lekérés során az adatgazda lehet felelős a forrás minőségéért és az engedélyekért. A modellgenerálás során a technikai tulajdonos lehet felelős a jóváhagyott verziókért és beállításokért. A felülvizsgálat során egy emberi szerepkör lehet felelős az ítéletért. A művelet során a munkafolyamat tulajdonosa lehet felelős a külső hatásokért. A lezárás során az iratkezelés lehet felelős a megőrzésért és a törlésért. A pontos térkép eltérhet, de az elv áll: a felelősség jobban tapad az átmenetekhez, mint a ködhöz.

Ez akkor számít, ha valami rosszul sül el. Ha egy kimenet azért volt rossz, mert a forrás elavult volt, az állapotgépnek meg kell mutatnia, hol ellenőrizték a frissességet, vagy hol maradt el. Ha egy ember jóváhagyott egy kockázatos műveletet, a nyilvántartásnak meg kell mutatnia, milyen bizonyítékot láttak. Ha egy szabályzat megváltozott, a függőben lévő esetekből ki kell derülnie, melyik verzió irányította őket. Ha egy modellt frissítettek, a kiadási határon átívelő átmeneteknek ellenőrizhetőknek kell lenniük. A lényeg nem az, hogy gyorsabban találjunk bűnbakot. A lényeg az, hogy lehetővé tegyük a javítást anélkül, hogy úgy tennénk, mintha az egész rendszer egyetlen differenciálatlan vállrándítással omlott volna össze.

A kijelölhető felelősség a mindennapi munkát is javítja. A csapatok tudják, melyik állapotot birtokolják. A mérőszámok kevésbé lesznek teátrálisak. Ahelyett, hogy bejelentenék, hogy a felelős AI-program érett, a szervezet mérheti az elavult források miatti blokkolásokat, a cél hiánya miatti elutasításokat, a felülvizsgálati felülbírálásokat, a fellebbezési eredményeket, az incidens-átmeneteket és a lezárási késedelmeket. Ez kevésbé alkalmas egy fényes diára. Sokkal alkalmasabb egy rendszer működtetésére.

A rossz állapotok megérdemlik a saját nevüket

A legtöbb felelős AI-meghibásodás nem gonosz. Ezek hétköznapi állapotok rossz vagy hiányzó nevekkel. Egy piszkozatválaszt végleges válaszként kezelnek. Egy ideiglenes kivétel útvonallá válik. Egy alacsony megbízhatóságú kimenet nagy hatású műveletté válik, mert a munkafolyamatnak nem volt köztes állapota. Egy modell olyan adatot lát, amit nem kellett volna látnia, mert a lekérési állapot nem hordozta a célt. Egy emberi felülvizsgáló bélyegzővé válik, mert a felülvizsgálat nevű állapot nem követelte meg a bizonyítékot vagy a nézeteltérés rögzítését.

A rossz állapotok elnevezése kényelmetlen és hasznos. Néma piszkozat. Terjedő hatókör. Elavult forrás. Hiányzó tulajdonos. Felül nem vizsgált művelet. Nincs kiút. Ezek önmagukban nem gyökérokok, de helyek, ahová kontrollokat lehet tenni. Egy rendszer észlelheti a néma piszkozatot, amikor generált szöveget jóváhagyás nélkül másolnak külső kommunikációba. Észlelheti a terjedő hatókört, amikor egy munkafolyamat a bejelentett célon kívüli forrást kér. Észlelheti az elavult forrást, amikor egy hivatkozás régebbi, mint amit a szabályzat megenged. Észlelheti a nincs kiút állapotot, amikor a blokkolt esetek örökre ülnek, mert senki nem tervezte meg az emberséges elutasítást.

A szokás a túlzott erkölcsi reakciót is megakadályozza. Nem minden meghibásodás etikai válság. Néha ez egy sorban álló állapot tulajdonos nélkül. Néha egy megőrzési állapot, amelyet senki nem kötött össze a törléssel. Néha egy megbízhatósági küszöb, amely ítéletnek adja ki magát. Az állapot elnevezése lehetővé teszi a csapat számára, hogy megjavítsa a mechanizmust. Nevek nélkül minden incidens a kultúráról szóló vitává válik. A kultúra számít, de rossz helyettesítője annak, hogy tudjuk, melyik átmenet szivárgott.

Száraz komédia van abban, ahogy a szervezetek félnek az állapotgép szótól, mert túl technikainak hangzik, miközben boldogan működtetnek egy jóváhagyási e-mailek, táblázatkezelői státuszok és kivételek labirintusát, amelyet csak három ember és egy naptármeghívó ismer. A formális változat gyakran egyszerűbb. Csak megvan az a tapintatlansága, hogy látható.

A bizonyíték az átmenethez tartozik

Ha az állapotgépnek jelentősége van, bizonyítékra van szüksége. A feljegyzésnek nem pusztán azt kell mondania, hogy egy esetet jóváhagytak. Azt is meg kell mondania, hogy mi váltotta ki az átmenetet, melyik védelmet értékelték, milyen adatot használtak, melyik modell- és házirendverzió volt érvényben, ki vagy mi hagyta jóvá, milyen hatás következett, és hogyan lehet az esetet újra lejátszani vagy megkérdőjelezni. A bizonyíték nem díszítés a cselekvés után. Része annak, hogy a cselekvés elszámoltathatóvá váljon.

Ez különösen fontos az AI esetében, mert a kimenetek hihetőek lehetnek, miközben az útjuk törékeny. Egy összefoglaló helyes lehet, de olyan forráson alapulhat, amelyhez a felhasználónak nem volt hozzáférése. Egy javaslat észszerű lehet, de kívül eshet a modell jóváhagyott használatán. Egy osztályozás pontos lehet, de egy házirend határideje után készült. Egy elutasítás biztonságos lehet, de jogilag haszontalan, ha nem ad utat a hibajavításhoz. A válasz önmagában nem árulja el ezeket. Az átmeneti feljegyzés igen.

A jó bizonyíték bátorságot is ad a csapatoknak ahhoz, hogy ott automatizáljanak, ahol az automatizálás megfelelő. A felelős AI nem állandó bocsánatkérés a gépek használatáért. Ha egy feladat alacsony hatású, jól körülhatárolt, visszafordítható, megfelelően tesztelt és megfelelően rögzített, az automatizálás lehet a felelős út. Ha egy feladat nagy hatású, vitatott, újszerű vagy visszafordíthatatlan, az állapotgépnek lassítania kell rajta. A lényeg nem az, hogy imádjuk az emberi felülvizsgálatot. A lényeg az, hogy a munkát kockázat, bizonyíték és orvoslás szerint irányítsuk.

A bizonyíték kevésbé politikussá teszi ezt az irányítást. Egy csapat megmutathatja, hogy egy állapot biztonságos az automatizáláshoz, mert a korábbi átmenetek pontosak voltak, a fellebbezések ritkák voltak, a korrekciókat beépítették, és a védelmek a megfelelő eseteket fogták el. Vagy megmutathatja, hogy egy állapotnak több emberi ítéletre van szüksége, mert a hibaminták továbbra is nehezek, az érintettek vitatják az eredményeket, vagy az adatminőség gyenge. Ez jobb érv, mint a szokásos színház, ahol az egyik oldal innovációt mond, a másik kockázatot, amíg mindenkinek kávéra nincs szüksége.

Az emberi felülvizsgálat állapot, nem gesztus

Az emberi felülvizsgálatra gyakran úgy hivatkoznak, mintha a puszta létezésével megoldaná a felelősséget. Ember van a folyamatban. Rendben. Melyik folyamatban. Melyik állapotnál. Milyen bizonyítékkal. Milyen felhatalmazással. Vitatkozhat-e az ember. Megváltoztatja-e a vita a rendszert. A felülvizsgálat mintavételezett, kötelező, kockázatvezérelt vagy pusztán formális. A felülvizsgáló az eredeti anyagot látja, vagy csak a modell rendezett szövegét. Van idő gondolkodni. Van képzés. Van nyilvántartás. Az ember a folyamatban kifejezést nyitó kérdésként kell kezelni, nem záró érvként.

Az állapotgép kézzelfoghatóvá teszi az emberi felülvizsgálatot. Meg tudja különböztetni a kötelező felülvizsgálatot az opcionálistól, a folyamatban lévőt a lezárttól, az ember által módosított kimenetet az ember által megerősítettől, a szükséges eszkalációt a lezárttól. Azt is meg tudja különböztetni, milyen ítéletről van szó. Egyes felülvizsgálatok a tények forráshasználatát ellenőrzik. Egyesek a szabályzatnak való megfelelést. Egyesek az empátiát és a hangnemet. Egyesek a jogi felhatalmazást. Egyesek azt, hogy egy kivétel indokolt-e. Egyetlen jóváhagyott mező ritkán elég gazdag a komoly munkához.

Ha a felülvizsgálatot állapotként tervezzük, az megvédi az embereket attól, hogy erkölcsi kitöltőanyagként használják őket. Ha a rendszer minden kínos esetet bizonyíték, rangsorolás vagy visszajelzés nélkül küld egy emberhez, az ember a bizonytalanság szemétlerakójává válik. Ez nem felügyelet. Ez egy munkaerő-modell bűntudattal. A felelős felülvizsgálati állapot becsomagolja az ügyet, megnevezi a szükséges döntést, megőrzi az eltérő véleményt, és visszavezeti az eredményeket az értékelésbe. Olyan munkát ad az embernek, amely méltó egy emberhez.

Az ellenkezője is igaz. Egyes rendszerek ott alkalmaznak emberi felülvizsgálatot, ahol egy jobb védőkapu emberségesebb lenne. Ha egy ügyből hiányzik a jogalap, ne küldjük felülvizsgálóhoz, hogy manuálisan fedezze fel. Blokkoljuk. Ha a forrás elavult, frissítsük vagy utasítsuk el. Ha a felhasználónak nincs felhatalmazása, mondjuk meg neki. Az embereknek ítéletet kell hozniuk, nem pedig hiányzó csővezetéket pótolni. Évtizedeket töltöttünk gépek feltalálásával. Rossz modor lenne arra kérni az embereket, hogy érvényesítő szkriptként viselkedjenek.

A visszafordíthatatlanság megváltoztatja a gépet

Nem minden átmenet egyenlő. Egyesek visszafordíthatók. Egy piszkozat szerkeszthető. Egy útvonal módosítható. Egy ajánlás visszavonható. Más átmeneteket nehezebb visszacsinálni: egy üzenet elküldésre került, egy juttatást megtagadtak, egy kockázati jelzés átsorol egy várakozási sort, egy nyilvántartás frissül, egy személyt bejelentenek, egy fizetés megtörténik, egy ügyfelet kizárnak. A felelős MI-nek tudnia kell, mely átmenetek lépnek át a világba.

Az irreverzibilitásnak meg kell változtatnia a védelmet. A rendszernek több bizonyítékot, erősebb felhatalmazást, világosabb emberi ítéletet, jobb tájékoztatást és láthatóbb fellebbezési utat kell követelnie, mielőtt visszafordíthatatlan hatások következnek be. Emellett lehetőség szerint előnyben kell részesítenie a fokozatos átmeneteket. Piszkozat a küldés előtt. Javaslat a döntés előtt. Várakozás az elutasítás előtt. Értesítés a végrehajtás előtt. Felülvizsgálat a jelentés előtt. Ez nem a lassúság önmagáért. Ez a különbség egy olyan rendszer között, amely képes kijavítani önmagát, és egy olyan rendszer között, amely magabiztos arccal hoz létre takarítási munkát.

Az állapotgép a részleges visszafordíthatóságban is segít. Egyes károk technikailag helyreállíthatók, de társadalmilag nem. Egy hibás belső összefoglaló kijavítható. Egy hibás külső vád a javítás után is megmaradhat. Egy késleltetett juttatás később kifizethető, de a bérleti díj korábban esedékes volt. Egy törölt rekord néha visszaállítható, de a bizalom nem feltétlenül. A gépnek ezeket az átmeneteket emberi hatásuk komolyságával kell kezelnie, nem csupán az adatbázis-visszaállítás szempontjából.

Itt menekül meg a felelős mesterséges intelligencia attól a fantáziától, hogy az etika különálló a működéstől. A működési részlet az etikai felület. A sorban állási tervezés hatással van a méltányosságra. Az újrapróbálkozási szabályzat hatással van a duplikációra. Az időtúllépési viselkedés hatással van a hozzáférésre. Az adatmegőrzés hatással van a magánéletre. A felülvizsgálati terhelés hatással van a méltóságra. Az állapotátmenetek nem semleges csővezetékek. Ezek azok a módok, ahogyan a rendszer találkozik az emberekkel.

Az értékelés mint átmeneti bizonyíték

Az értékelés gyakran a munkafolyamaton kívül helyezkedik el, mintha iskolai vizsga lenne, amelyet a rendszer a végzés előtt tesz le. Egy felelős állapotgépben az értékelés folyamatos átmeneti bizonyítékká válik. Minden átmenet jeleket produkálhat: milyen gyakran blokkolt a védelem, milyen gyakran bírálták felül az emberek, milyen gyakran jártak sikerrel a fellebbezések, milyen gyakran voltak elavultak a források, milyen gyakran tért el a modell megbízhatósága az emberi ítélettől, milyen gyakran keltett panaszokat egy feltételezett alacsony hatású útvonal.

Ezeknek a jeleknek táplálniuk kell a gépet. Egy átmenet, amely ismételt fellebbezéseket eredményez, erősebb védelmet vagy világosabb tájékoztatást igényelhet. Egy emberi felülvizsgálati állapot, amely magas egyetértéssel és alacsony hatással jár, jogosult lehet több automatizálásra, feltéve, hogy a jogorvoslat valós marad. Egy elutasítási állapot, amely csapdába ejti a felhasználókat, javítási utat igényelhet. Egy szakpolitikai védelem, amely túl sok jogos esetet blokkol, rossz szakpolitikát tárhat fel, nem rossz modellt. A gép nem azért felelős, mert statikus. Azért felelős, mert képes tanulni anélkül, hogy elrejtené a múltat.

Ez a tanulás verziókezelést igényel. Az állapotok, védelmek, küszöbértékek, promptok, modellek, szakpolitikák, adatforrások és felülvizsgálati utasítások változnak. A nyilvántartásnak meg kell mondania, melyik verzió melyik átmenetre vonatkozott. Ellenkező esetben a szervezet csak a múltbeli döntések zagyváját tudja értékelni. A zagyvának vannak kulináris felhasználásai. Nem kormányzási módszer, akárhány irányítópult is lebeg a tetején.

A verziózott átmeneti bizonyíték az őszinteséget is javítja. Egy csapat elmondhatja, hogy egy új védelem csökkentette a felülvizsgálatlan műveleteket, de növelte a késleltetést. Elmondhatja, hogy egy új forrás javította a pontosságot, de növelte a magánéleti súrlódást. Elmondhatja, hogy egy modellfrissítés javította az összefoglalókat, de gyengítette az elutasítási fegyelmet. A kompromisszumok nem kudarcok. A rejtett kompromisszumok kudarcok, amelyek naptári meghívóra várnak.

A tanulság

A felelős mesterséges intelligencia mögött álló állapotgép nem a ridegebb rendszerekre való felhívás. Ez egy felhívás olyan rendszerekre, amelyek tudják, mit csinálnak, miközben csinálják. Egy elnevezett állapot nem erkölcsi teljesítmény. Egy védelem nem igazságosság. Egy nyugta nem bizalom. De ezek nélkül a felelős mesterséges intelligencia a szándék szintjén marad, és a szándék rossz rendelkezésre állási mutatóval rendelkezik.

A felelős MI-nek szüksége van célra, felhatalmazásra, bizonyítékokra, korlátokra, emberi ítélőképességre, fellebbezésre, javításra, megőrzésre és tanulásra. Ezek a szavak állapotokon és átmeneteken keresztül válnak működőképessé. Ezek döntik el, hogy egy eset mikor halad tovább, mikor áll le, ki a felelős érte, milyen nyilvántartás készül, milyen jogorvoslat létezik, és mit kell a rendszernek legközelebb megjegyeznie. Ez nem a teljes etika. Ez az a rész, amely megállíthat egy rossz cselekedetet, mielőtt az nagyon jól dokumentált megbánássá válna.

Az elején lévő űrlapnak még mindig van értéke. Felteszi a megfelelő nyitó kérdéseket. De az űrlapnak egy működő géphez kell vezetnie: elnevezett állapotokhoz, egyértelmű védőkorlátokhoz, tartós bizonyítékokhoz, valódi felülvizsgálathoz és kilépési lehetőségekhez a rendszer által érintett emberek számára. A felelős MI-t nem a szabályzat megléte bizonyítja. Az bizonyítja, vagy cáfolja, az az átmenet, ahol a rendszer eldönti, mi történjen ezután.