Upravljanje umetne inteligence ima urnik vzdrževanja

Governance ni odobritev, ki se zgodi, preden sistem umetne inteligence začne delovati. Je vsakdanje delo opazovanja, odločanja, spreminjanja, preverjanja in...

Upravljanje umetne inteligence ima urnik vzdrževanja

Koledar za politiko

Večina dokumentov o upravljanju je napisana, kot da se zanimivo dogajanje odvija, preden se sistem začne uporabljati. Nekdo opredeli namen. Ekipa oceni tveganje. Vodja podpiše vrstico. Dobavitelj dostavi PDF, katerega ime datoteke vključuje besedo final, kar je ponavadi majhno opozorilo. Nato sistem vstopi v vsakdanje življenje, kjer se vir podatkov zamenja, oseba spozna bližnjico, politika se spremeni, ponudnik posodobi komponento ali pa prej nenavaden primer postane pogost. Odobritev ostane v svoji mapi. Svet ne.

Zato upravljanje umetne inteligence potrebuje urnik vzdrževanja. Ne ceremonialnega letnega srečanja s prosojnico, ki prikazuje sedem zelenih pik. Urnik običajnih dejanj skrbi: preverjanje, ali navedeni namen še vedno drži, branje signalov, ki bi lahko spremenili oceno tveganja, odločanje o tem, kdo sme spreminjati sistem, vaja, kaj se zgodi, ko ga je treba ustaviti, beleženje, zakaj je bila sprememba narejena, in umik dokazov, ko so njihovi pogoji potekli. To je manj glamurozno kot objava zagona. A prav tu odgovornost bodisi postane resnična bodisi tiho izgine.

Razlika je pomembna, ker sistemi umetne inteligence ne ostanejo tam, kamor jih je postavila začetna ocena. Model lahko ostane nespremenjen, medtem ko se spremenijo njegovi vhodi, uporabniki, vmesnik, pot uvajanja, povezana orodja, poslovni proces ali pravni okvir. Model se lahko spremeni, medtem ko se uporaba zdi stabilna. Sistem lahko ostane tehnično na voljo, a postane operativno neprimeren, ker so ljudje, ki bi ga lahko postavili pod vprašaj, zamenjali službo, ker se je čakalna vrsta za pregled napolnila, ker je nova nadaljnja uporaba njegovim izhodom dala drugačne posledice. Upravljanje, ki datum izdaje obravnava kot ciljno črto, upravlja fotografijo.

Evropska pravila že vsebujejo zahtevnejšo zamisel. Za sisteme umetne inteligence z visokim tveganjem 9. člen akta o umetni inteligenci opredeljuje upravljanje tveganj kot stalen ponavljajoč se proces, načrtovan in izvajan skozi celoten življenjski cikel, z rednim sistematičnim pregledovanjem in posodabljanjem. 72. člen zahteva sorazmeren, dokumentiran sistem spremljanja po dajanju na trg, ki aktivno in sistematično zbira, dokumentira in analizira ustrezne informacije o delovanju skozi celotno življenjsko dobo sistema. Bistvo ni v tem, da vsaka majhna programska oprema potrebuje enak aparat. Bistvo je, da pomembna tehnologija potrebuje ritem delovanja, ne le začetne datoteke.

Uporabno vprašanje torej ni: »Ali imamo okvir upravljanja umetne inteligence?« Temveč: »Kaj se zgodi naslednji torek, ko dokazi ne ustrezajo več storitvi?« Kdo to prvi opazi. Katere informacije ima. Kdo lahko odloči, ali gre za običajni popravek, pomembno spremembo, incident ali razlog za premor. Kako se prvotna odločitev ohrani, ne da bi postala izgovor. In ko sistem še vedno tehnično deluje, a je institucija prenehala razumeti pogoje njegove uporabe, kdo sme reči, da delovanje ni več dovolj dobro?

Urnik vzdrževanja na ta vprašanja ne odgovarja s splošno nadzorno ploščo. Dodeli jih ljudem in trenutkom. Vsakemu zapisu da razlog za ponovni pregled. Nadaljnjo uporabo sistema pogojuje z živim odnosom med dokazi, pooblastili in dejanskim delom okoli njega.

Kaj propada po zagonu

Programski opremi ni treba odpovedati, da postane manj obvladljiva. Najpogostejši propad je tišji. Ekipa ima dober opis predvidene uporabe, a storitev raste vstran. Pomočnik, narejen za notranje osnutke, se preseli na pot za stranke. Klasifikator, zgrajen za razvrščanje določenega nabora dokumentov, prejme novo vrsto vložitev. Sistem, ki ga je sprva pregledovala majhna skupina, postane del širšega procesa, kjer nihče ne pozna meje, ki je bila na začetku pomembna. V tem opisu ni treba izumiti nesreče. To je preprosto tisto, kar se zgodi, ko se institucija spreminja hitreje kot njeni zapisi.

Namen propade prvi, ker je pogosto zapisan kot samostalnik, čeprav je v resnici meja. »Podpora pri odločanju« ni ustrezen namen, če zapis ne more povedati, za katero odločitev gre, za koga, s katerimi vložki, s kakšno avtoriteto in kaj izhodu ni dovoljeno sprožiti. Izjavo o namenu je treba ponovno preučiti, ko sistem začne uporabljati nova ekipa, ko izhod začne odpirati ali zapirati pomembno pot, ko je prizadeta nova populacija ali ko postane človeška predaja manj smiselna. Besede lahko ostanejo enake, medtem ko se praktična posledica občutno poveča.

Dokazi propadejo naslednji. Rezultat vrednotenja je opazovanje pod navedenimi pogoji. Lahko je uporaben dolgo časa, vendar ni nesmrten. Izmerjeno stanje modela se je morda spremenilo. Porazdelitev podatkov se je morda premaknila. Ljudje, ki uporabljajo sistem, lahko njegov izhod zdaj razlagajo drugače. Merilo uspešnosti lahko zajema podskupino, ki je bila sprva reprezentativna, zdaj pa ni več. Test sam je lahko še vedno ponovljiv, medtem ko je argument za zanašanje nanj oslabel. Ohranjanje poročila je dobro vodenje evidenc. Obravnavanje kot trenutnega dokaza brez preverjanja njegovih pogojev pa je nekaj drugega.

Vmesniki propadejo prav tako. To pogosto spregledamo, ker se sprememba vmesnika lahko zdi neškodljiva. Nova privzeta vrednost, izrazitejši gumb, skrajšana razlaga, dodan klic orodja ali spremenjena pot eskalacije lahko spremenijo, kaj uporabniki dejansko počnejo. Model je enak, zato ekipa reče, da do spremembe modela ni prišlo. To je lahko tehnično natančno in operativno nepomembno. Če vmesnik priporočilo naredi obvezujoče, če odstrani kontekst, potreben za izpodbijanje rezultata, ali če omogoči, da izhod potuje dlje kot prej, se je vprašanje upravljanja spremenilo, tudi če se uteži niso.

Avtoriteta propade, ko odgovornost obstaja na papirju, v praksi pa ne več. Imenovani lastnik je morda odšel. Vloga pregleda lahko ostane v organizacijski shemi, medtem ko oseba, ki jo zaseda, nima niti časa niti informacij za presojo. Ustavna avtoriteta je lahko dodeljena višji skupini, ki ne ve, da ji je bila dodeljena. Dobaviteljska pogodba lahko kaže na kontakt za eskalacijo, ki lahko prejme obvestilo, ne more pa narediti spremembe. Upravljanje je tako postalo stari telefonski imenik z nekoliko samozavestnejšo tipografijo.

Odvisnosti propadejo z naraščanjem. Storitev lahko doda vir pridobivanja, ponudnika identitete, izdelek za spremljanje, pot sklepanja, čakalno vrsto, plast shranjevanja ali drug model. Vsak dodatek je lahko smiseln. Skupaj spremenijo sistem, ki dejansko deluje. DORA to poudarja v finančnem okolju z zahtevo, da subjekti opredelijo, razvrstijo in dokumentirajo poslovne funkcije, sredstva, vloge, odgovornosti in odvisnosti, podprte z IKT, ter da ustrezno dokumentacijo pregledajo vsaj letno in ob večjih spremembah. To ni pravilo o umetni inteligenci. Je koristen opomnik, da je predmet, ki potrebuje vzdrževanje, sistem v svojem delovnem okolju, ne komponenta z najbolj modnim imenom.

Nazadnje propade spomin. Organizacija lahko hrani na tisoče vrstic dnevnikov in še vedno izgubi razlog za odločitev. Dnevniki lahko povedo, da se je dogodek zgodil. Ne povedo samodejno, zakaj je bil prag določen, kdo je sprejel omejitev, kateri primeri so bili izključeni iz preizkusa ali kaj je ekipa nameravala preveriti po izdaji. Te informacije običajno odidejo z ljudmi, razen če so zapisane v evidenco z lastnikom in točko pregleda. Revizijska sled, ki ne more pojasniti presoje okoli dogodka, je uporabna, a nepopolna.

Nič od tega ni argument za stalno sumničavost ali za sestanek odbora ob vsaki spremembi menija. Pomembno je razmerje. Akt o umetni inteligenci sam opisuje spremljanje po dajanju na trg kot sorazmerno z naravo tehnologije in tveganjem sistema z visokim tveganjem. Namen vzdrževanja ni onemogočiti običajnih izboljšav. Namen je, da organizacija postane dobra pri prepoznavanju, katere izboljšave niso običajne.

Zakon že razmišlja v ciklih

Evropska pravila o tehnologiji so pogosto opisana kot obveznosti skladnosti, kakor da bi šlo za enkratno oddajo vloge, ki ji sledi žig. Ob natančnejšem branju je njihova operativna logika ciklična. Od organizacij zahtevajo, da prepoznavajo, spremljajo, dokumentirajo, poročajo, pregledujejo, preizkušajo in izboljšujejo. Besedišče se po sektorjih razlikuje, ker se razlikujejo tveganja. Instinkt vzdrževanja je izjemno dosleden.

Za sisteme umetne inteligence z visokim tveganjem Akt o umetni inteligenci uvršča razmišljanje o življenjskem ciklu med prve zahteve. Člen 9 zahteva, da se sistem upravljanja tveganj vzpostavi, izvaja, dokumentira in vzdržuje. Opisuje ga kot neprekinjenega in ponavljajočega se, načrtovanega in izvajanega skozi celoten življenjski cikel, z rednim sistematičnim pregledovanjem in posodabljanjem. Sistem mora prepoznavati in analizirati znana ter razumno predvidljiva tveganja, vključno s tveganji, povezanimi s predvideno uporabo in razumno predvidljivo zlorabo. Uporabljati mora tudi informacije, zbrane s spremljanjem po dajanju na trg. To je navodilo, da je treba začetno oceno narediti popravljivo. Začetni oceni ne dovoljuje, da postane muzejski eksponat.

Člen 72 je natančnejši glede tega, kaj sledi po dajanju sistema z visokim tveganjem v uporabo. Ponudniki morajo vzpostaviti in dokumentirati sistem spremljanja, ki je sorazmeren s tehnologijo in tveganjem. Ta sistem mora aktivno in sistematično zbirati, dokumentirati in analizirati ustrezne podatke o delovanju skozi celotno življenjsko dobo sistema, da je mogoče oceniti nadaljnjo skladnost z ustreznimi zahtevami. Kjer je to ustrezno, vključuje analizo interakcije z drugimi sistemi umetne inteligence. To je pomembno za dejanske uvedbe, ker se lahko smiselno vedenje sistema pojavi na meji: izhod vstopi v drugo orodje, mehanizem pravilnikov spremeni rezultat v dejanje, človek vidi vmesnik, ki spremeni težo priporočila, ali nadaljnji delovni tok ustvari novo posledico.

Akt ne zahteva, da spremljanje postane pasivno opazovanje vseh, ki uporabljajo storitev. Zahteva ustrezne informacije, okoliško pravno okolje pa še vedno velja. Načrt vzdrževanja bi zato moral začeti z namenom za vsak signal. Na katero vprašanje signal odgovarja. Ali so agregatne informacije dovolj. Ali pregled potrebuje vsebino, identiteto ali samo različico operativnega dejstva. Kdo ima dostop do njega. Kako dolgo se hrani. Kako ga je mogoče izpodbijati. Zbiranje več podatkov, ker nadzorna plošča sprejema več polj, ni strategija vzdrževanja. To je shranjevanje z ambicijami.

Isto poglavje povezuje spremljanje z obravnavanjem resnih incidentov. Člen 73 od ponudnikov sistemov z visokim tveganjem, danih na trg Unije, zahteva, da resne incidente prijavijo ustreznim organom za nadzor trga, potem ko je bila ugotovljena vzročna zveza ali razumna verjetnost zanjo. Določa roke, ki se razlikujejo glede na resnost, vključno z dvema dnevoma za razširjeno kršitev ali resni incident določene vrste. Po prijavi zahteva preiskavo, oceno tveganja in korektivne ukrepe. Ključno operativno spoznanje ni število dni. Gre za to, da odziv na incident ni ločen proces za odnose z javnostmi. Je del dokazne zanke, ki bi morala spremeniti upravljanje tveganj, dokumentacijo in prihodnje delovanje.

NIS2 jasno pove, kdo je odgovoren za kibernetsko varnost. V 20. členu določa, da upravljalni organi bistvenih in pomembnih subjektov odobrijo ukrepe za obvladovanje tveganj na področju kibernetske varnosti, nadzorujejo njihovo izvajanje in so lahko odgovorni za kršitve. 21. člen nato zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe, vključno z obravnavanjem incidentov, neprekinjenim poslovanjem, varnostjo dobavne verige ter varnostjo pri nabavi, razvoju in vzdrževanju. To je koristno daleč prek subjektov, za katere velja NIS2. Upravljanje ni navodilo, poslano navzdol iz gradiva za upravni odbor. Če ljudje s formalno oblastjo ne pregledajo ukrepov in ne razumejo posledic svojih odločitev, je organizacija ustvarila naziv brez nadzora.

NIS2 obravnava tudi poročanje kot storitveno obveznost. Pomembne incidente je treba prijaviti brez nepotrebnega odlašanja, prejemnike storitev pa je treba, kadar je to primerno, obvestiti, kadar bo pomemben incident verjetno škodljivo vplival na opravljanje storitev. Incident je pomemben ne le, kadar moti delovanje same organizacije, ampak tudi kadar prizadene druge ljudi z znatno materialno ali nematerialno škodo. Ta meja je uporabna za upravljanje umetne inteligence. Ekipa ne sme gledati le na to, ali graf razpoložljivosti sistema ostaja zelen. Sistem je lahko razpoložljiv in še vedno povzroči pomembno operativno težavo ali težavo, povezano s pravicami.

DORA ponuja še en praktičen vzorec. Finančni subjekti morajo opredeliti in dokumentirati poslovne funkcije, ki jih podpira IKT, vloge, odgovornosti, informacije in sredstva IKT ter njihove odvisnosti. Ustreznost razvrščanja in dokumentacije pregledujejo po potrebi in vsaj enkrat letno, ob vsaki večji spremembi infrastrukture, procesov ali postopkov, ki vplivajo na podprte funkcije ali sredstva, pa izvedejo oceno tveganja. Tudi to ni argument, da je vsaka organizacija finančni subjekt. Je primer zrelega pravila, ki popis, spremembe in pregled obravnava kot povezano delo. Živ sistem potrebuje zemljevid, zemljevid pa potrebuje datum.

Jezik DORA o obvladovanju sprememb je še posebej trezen. Zahteva dokumentirane politike, postopke in kontrole za spremembe programske opreme, strojne opreme, vdelane programske opreme, sistemov in varnostnih parametrov. Spremembe je treba na nadzorovan način zabeležiti, preizkusiti, oceniti, odobriti, izvesti in preveriti. To zaporedje ni trditev, da je model umetne inteligence mogoče vedno preizkusiti do varnosti. Je način, kako zavrniti zamisel, da je posodobitev produkcije sama po sebi upravičena. Sprememba mora imeti razlog, oceno, pot odobritve, zapis o izvedbi in preverjanje rezultata.

ISO/IEC 42001 ni zakonodaja in javna stran izdelka ni nadomestilo za sam standard. Kljub temu ISO standard opisuje kot sistem upravljanja umetne inteligence, ki temelji na načelu Načrtuj-Izvedi-Preveri-Ukrepaj in je namenjen pomoči organizaciji pri obvladovanju tveganj in priložnosti, povezanih z umetno inteligenco, v celotni organizaciji in ne le pri preučevanju posameznih aplikacij. Krog je koristna zamisel. Načrtuj vzpostavi omejeno namero. Izvedi jo uresniči. Preveri ugotavlja, ali dokazi podpirajo nadaljnje zanašanje. Ukrepaj spremeni sistem dela. Ponavljanje tega kroga ni birokracija sama po sebi. Je minimalno priznanje, da sistemi in institucije ne ostajajo nespremenjeni.

Krog upravljanja mora dokaze vrniti k odločitvi. V nasprotnem primeru je le zapis stvari, ki so bile opažene.

Nadzorovanju je treba dovoliti, da je pomembno

Nadzorovanje se pogosto obravnava kot tehnična dejavnost, kar je razumljivo. Sistemi ustvarjajo telemetrijo. Ekipe izbirajo metrike. Nadzorne plošče prikazujejo krivulje, ki naraščajo, padajo in včasih sprožijo alarmantne sestanke. Toda težavni del ni zbiranje signala. Težavni del je dogovor o tem, kaj se signalu sme spremeniti.

Načrt nadzorovanja se začne z vprašanjem odločitve. Pritožba lahko pomeni, da je razlaga nejasna, da je vnos napačen, da je uporabnik naletel na omejitev ali da je organizacija slabo zasnovala pot za pritožbe. Povečanje števila človeških posegov lahko pomeni slabše prileganje modela, večje zaupanje osebja, spremenjeno politiko, zastarele izvorne podatke, novo vrsto primerov ali vmesnik, ki zavaja pregledovalce. Povečanje števila zavrnitev lahko pomeni, da varnostni nadzor deluje, da je odvisnost postala nezanesljiva ali da se izdelek uporablja zunaj njegovega deklariranega namena. Surovo število ni zaključek. Je povabilo k preučitvi razmerja.

Zato uporaben načrt ločuje opazovanje od razlage. Opazovanje pove, kaj je bilo zabeleženo, s katero različico, potjo, časom, kontekstom in zaupanjem. Razlaga pove, kaj organizacija meni, da bi signal lahko pomenil, in katere alternativne razlage ostajajo. Odločitev pove, kdo lahko izbere odziv. Zapis pove, kaj se je spremenilo in zakaj. To je počasneje kot obravnavanje vsakega opozorila kot dokaza okvare modela. Je pa hitreje kot pošiljanje slabo razumljenega problema v cikel ponovnega usposabljanja in odkrivanje, da je bila dejanska napaka v politiki, kakovosti virov, pravicah dostopa ali kadrih.

Metrike bi morale ustrezati tudi posledicam sistema. Ocena kakovosti modela je lahko pomembna, vendar bo redko zadostovala. Če izhod vpliva na čakalno vrsto, mora ekipa morda poznati zamude, neobravnavane izjeme, razveljavitve in to, kateri primeri se pošiljajo v ročni pregled. Če pomočnik priporoča vire, mora ekipa morda poznati razpoložljivost virov, popravke navedb, sporne odgovore in to, ali uporabniki delujejo na podlagi gradiva zunaj navedenega obsega. Če sistem filtrira vsebino, pregled morda potrebuje vzorce pritožb, izide pritožb, jezikovno pokritost in razloge za posege. Nadzorovanje bi moralo potovati po poti, kjer ima sistem učinke, in se ne sme ustaviti na točki, kjer je model ustvaril žeton ali oceno.

Tudi pot do človeka potrebuje nadzorovanje. V politiki je lahko zapisati »človeški nadzor«, težko pa je dokazati, ali ga oseba dejansko lahko izvaja. Kako pogosto ljudje posegajo. Ali imajo dostop do vnosov in razlogov, potrebnih za to. Ali poseg doseže proces, ki je ustvaril izid, ali zgolj doda opombo na koncu. Koliko časa traja eskalacija. Ali nekateri primeri nikoli ne dosežejo poti pregleda, ker vmesnik skriva to možnost. To so operativna vprašanja. So tudi vprašanja upravljanja, ker odgovor določa, ali je človeški nadzor resničen ali zgolj dekorativen.

Ni treba, da je vsak signal javen. Nekateri bodo poslovno občutljivi. Nekateri bodo povezani z varnostjo. Nekateri lahko vsebujejo osebne podatke in jih sploh ne bi smeli zbirati. Disciplina vzdrževanja je, da te meje postanejo izrecne. Pregled morda potrebuje agregirane vzorce namesto celotnega arhiva vsebine. Morda potrebuje zajeto stanje namesto zapisa vsake interakcije. Morda potrebuje zaščiten dostop za preiskovalca incidentov in ločeno javno razlago metode. Preglednost ne pomeni objavljanja surovega operativnega gradiva. Pomeni, da so obstoj, namen, meje in lastništvo nadzora razumljivi.

Med načrtom spremljanja in seznamom želja je majhna, a pomembna razlika. Načrt pove, kateri signali se zbirajo, kako so zaščiteni, kaj sproži pregled, kdo je odgovoren za pregled, kakšni so možni izidi in kako odločitev vstopi v evidenco sprememb. Seznam želja pove, da bo organizacija spremljala kakovost, varnost, poštenost in zadovoljstvo uporabnikov. Prvega je mogoče preizkusiti. Drugi se zelo dobro poda v predstavitev strategije in nikamor drugam.

Dobro spremljanje naredi vidne tudi dogodke, ki se niso zgodili. Če ne prispe nobeno poročilo, ali je to zato, ker sistem ni povzročil težave, ker je pot poročanja nedostopna, ker ljudje ne vedo, da obstaja, ali ker postopek poročil ne ohranja? Če prag za incident ni presežen, ali je to zato, ker je sistem stabilen, ali zato, ker prag ni povezan z dejansko škodo? Odsotnost signala je lahko dokaz, vendar šele potem, ko je bil pregledan način zbiranja. Tišina ni samodejno pomiritev. Včasih je le obrazec s slabo označeno potjo.

Odzivanje na incidente je oblika institucionalnega spomina

Postopek za incidente se mora začeti pred incidentom, saj so prve minute nenavadnega dogodka slab čas za izumljanje pooblastil. Postopek potrebuje način za sprejem prijave, ohranitev dovolj dokazov za razumevanje, zaščito ljudi pred nadaljnjo izpostavljenostjo, odločitev, ali dogodek izpolnjuje opredeljen prag, in komunikacijo z ljudmi, ki morajo ukrepati. Potrebuje tudi pot nazaj v sistem upravljanja. Brez te zadnje poti organizacija obravnava dogodek in nato z občudovanja vredno učinkovitostjo znova ustvari pogoje, ki so do njega privedli.

DORA to jasno izraža za incidente, povezane z IKT. Finančne subjekte zavezuje, da opredelijo, vzpostavijo in izvajajo postopek upravljanja incidentov za odkrivanje, obvladovanje in prijavljanje incidentov. Zabeležijo incidente in pomembne kibernetske grožnje ter vzdržujejo postopke za dosledno, celovito spremljanje, obravnavo in nadaljnje ukrepanje, da se ugotovijo, dokumentirajo in obravnavajo glavni vzroki. Postopek mora vzpostaviti zgodnje opozorilne kazalnike, dodeliti vloge in odgovornosti za različne scenarije ter določiti komunikacijske in eskalacijske dogovore. To so posebne zahteve za finančni sektor. Njihova osnovna logika je splošno uporabna: incident bi moral organizaciji zapustiti boljše znanje, kot ga je imela prej.

Pri umetni inteligenci si vprašanje dokazov zasluži posebno pozornost. Ekipa bo morda želela takoj po ugotovitvi škodljivega izida spremeniti model ali storitev. Včasih je hitra omejitev škode povsem prava. Toda nenadzorovana sprememba lahko uniči tudi zmožnost razumevanja, kaj se je zgodilo. Akt o umetni inteligenci določa, da ponudnik, ki preiskuje resen incident, ne sme spremeniti sistema umetne inteligence na način, ki bi lahko vplival na poznejšo oceno vzrokov, preden o tem ukrepu obvesti pristojne organe. To ne pomeni dovoljenja, da ljudje ostanejo izpostavljeni, medtem ko se ohranja nedotaknjen poskus. Zaradi tega je kompromis viden. Omejite tveganje, ohrani pomembno stanje, zabeleži poseg in se izogni temu, da bi preiskava postala rekonstrukcija po spominu.

Uporabna evidenca incidenta ima več plasti. Obstaja prijavljeno opažanje, ki je lahko nepopolno ali sporno. Obstaja tehnični in operativni kontekst, vključno z različico, potjo, stanjem in povezanimi sistemi, ki so pomembni. Obstaja ocena vpliva in negotovosti. Obstajajo koraki za omejitev škode, vključno s tem, kdo jih je izvedel in kaj so spremenili. Obstaja preiskava, ki mora razlikovati med dokazi in hipotezami. Nato je tu odločitev o korektivnih ukrepih in nadaljnje spremljanje, ki preveri, ali so delovali. Če se vse te plasti zlijejo, je lahko zgodnje poročilo videti kot končni sklep ali pa poznejši sklep videti tako zanesljiv kot prvo opozorilo.

Komunikacija je del vzdrževanja, ne okrasni epilog. Ljudje, ki jih prizadene prekinitev ali resna grožnja, morda potrebujejo praktično rešitev. Operaterji morajo vedeti, ali naj ustavijo, nadaljujejo z omejitvami ali uporabijo nadomestno možnost. Vodstvo potrebuje jasen prikaz vpliva, negotovosti in pooblastil za odločanje. Regulator lahko zahteva določeno poročilo. Dobavitelji bodo morda morali preiskati vmesnik ali odvisnost. Sporočila si ni treba, da so enaka, vendar morajo imeti skupno dejstveno jedro. Organizacija, ki svojim ekipam posreduje nezdružljive opise, ni previdna. Ustvarja naslednji incident.

Za razumevanje tega ni treba izumiti dramatičnega izpada. Poglejmo jasno označen hipotetični primer: skupina za pregled opazi skupino nepričakovanih popravkov, ko nov format vira vstopi v sicer znani potek dela. Prvo vprašanje ni, ali je model »zašel s poti«, besedna zveza, ki jo je najbolje pustiti v smeteh skupaj z nekaterimi drugimi. Vprašanje je, kaj se je spremenilo. Ali format vira spreminja vhodne podatke. Ali pot pridobivanja izpostavlja neprimerno gradivo. Ali se je pogoj pravilnika premaknil. Ali vmesnik povzroča, da pregledovalci spregledajo kontekst. Ali se prizadeti primeri popravljajo dovolj hitro. Odziv je lahko začasna ustavitev ene poti, vrnitev konfiguracije, dodajanje preverjanja, posodobitev smernic ali ugotovitev, da vir nikoli ne bi smel biti sprejet. Bistvo hipotetičnega primera ni zaplet. Bistvo je, da pripravljen postopek organizaciji prepreči, da bi se v prvi uri prebijala z ugibanjem.

Po incidentu bi moral načrt vzdrževanja vprašati več kot le, ali je vidna napaka odpravljena. Ali je signal za odkrivanje deloval. Ali ga je prejela prava oseba. Ali je imela pooblastila. Ali je dnevnik ohranil ustrezen kontekst. Ali je bila pot eskalacije uporabna. Ali je javno sporočilo ali sporočilo strankam ustrezalo temu, kar je bilo znano. Ali je odločitev ustvarila novo zahtevo za spremljanje. Ali je vrzel v usposabljanju ali dokumentaciji poslabšala dogodek. Odgovori spremenijo incident iz osamljene prekinitve v spremembo operativnega modela.

Sprememba potrebuje drugo uro

Vsak sistem ima tehnično uro. Različice se zgradijo, uvedejo, umaknejo in zamenjajo. Upravljanje potrebuje drugo uro: časovni načrt za ponovno presojo, ali so dokazi, namen in pooblastila še vedno ustrezni. Ti uri se včasih premikata skupaj, včasih pa ne. Če ju obravnavamo kot eno, zanesljivo spregledamo pomembne spremembe.

Tehnična sprememba je lahko majhna in še vedno pomembna. Nova zbirka za pridobivanje lahko spremeni vire, uporabljene v odgovorih. Spremenjeno navodilo ali pravilo pravilnika lahko spremeni nabor primerov, ki jih sistem zavrne. Posodobitev konfiguracije lahko spremeni, kam potujejo podatki. Nova različica odvisnosti lahko spremeni zakasnitev, beleženje ali razpoložljive varnostne nadzore. Ustrezen odziv je odvisen od sistema in njegovih posledic. Načrt vzdrževanja ne bi smel vsake spremembe vnaprej razglasiti za pomembno. Zagotoviti bi moral način za odločanje o tem, kaj potrebuje testiranje, ponovno odobritev, javno obvestilo, ponovno oceno tveganja, novo zajeto stanje ali zgolj zapis.

Nasprotno pa lahko do spremembe upravljanja pride brez kakršne koli uvedbe kode. Storitev lahko začne uporabljati nov oddelek. Nabavna pogodba lahko doda obdelovalca. Pravna razlaga lahko spremeni pogoje poteka dela. Pot se lahko premakne iz notranjega preizkušanja v zunanji dostop. Obstoječi rezultat lahko začne vplivati na odločitev dlje v verigi. Tehnična ekipa morda ne vidi nobene izdaje. Prizadeti ljudje pa lahko vidijo zelo drugačen sistem. Načrt vzdrževanja mora opaziti obe uri.

DORA uporablja praktično klasifikacijsko pravilo: izvedite oceno tveganja za vsako večjo spremembo infrastrukture omrežij in informacijskih sistemov, procesov ali postopkov, ki vplivajo na podprte funkcije ali sredstva. Prav tako zahteva, da se inventarji posodabljajo občasno in ob vsaki večji spremembi. Pri delu z umetno inteligenco fraze »večja sprememba« ne bi smeli obravnavati kot samoumevne. Ekipe naj svoja merila zapišejo vnaprej. Ali vključuje spremembo predvidenega namena, nov vir podatkov, novo stanje modela, novo dovoljenje orodja, novo populacijo, spremenjeno pot človeškega nadzora, spremenjeno razlago ali novo zunanjo odvisnost? Odgovor se bo razlikoval. Odsotnost odgovora je sama po sebi tveganje.

Zapis spremembe ni dnevnik sprememb, napisan za javno pohvalo. Je argument, ki povezuje stanje pred spremembo, razlog, oceno, odločitev, izvedbo in preverjanje. Za nekatere spremembe je lahko javna različica kratka: ustrezna politika ali omejitev za uporabnike se je spremenila, velja od navedenega datuma, s povezavo do tega, kaj je drugače. Za notranje dokaze lahko zapis vključuje več podrobnosti o vrednotenju, nadzoru dostopa, okoliščinah incidenta ali informacijah o dobavitelju. Pomembno je, da se obe ravni nanašata na isto odločitev in ne postaneta ločeni zgodbi.

Identiteta različice je še posebej pomembna, ko se sistem sčasoma prilagaja. Stabilno ime izdelka ne more vedno opredeliti stanja, ki je ustvarilo določen rezultat. Toda poskus dodelitve stalne številke različice vsakemu prehodnemu stanju lahko ustvari drugačno vrsto fikcije. Boljši pristop je razlikovati trajno identiteto modela ali storitve od zajetega stanja, konfiguracije in dokazov, potrebnih za opredeljen pregled ali ponovitev. Zapis nato pove, kaj je bilo pregledano, ne da bi se pretvarjal, da je bilo vse zamrznjeno za vedno.

Preverjanje sprememb je področje, kjer mnogi zapisi postanejo optimistični. Organizacija je odobrila popravek, zato je incident zaprt. Toda izvedba ni preverjanje. Ali je novi nadzor deloval v realističnih pogojih. Ali je ustvaril drugačen problem. Ali je rezervni načrt deloval. Ali so človeški pregledovalci prejeli spremenjene smernice. Ali se je ustrezna metrika premaknila v predvideno smer. Ali razlaga še vedno ustreza storitvi. Preverjanje lahko pokaže, da je treba spremembo razveljaviti, izboljšati ali pustiti z novo omejitvijo. Lahko je neprijetno. To je del njegove naloge.

Razpored daje temu delu običajen ritem. Nekateri zapisi se pregledajo po sprožilcu. Drugi potrebujejo določen datum, ker čakanje na sprožilec predpostavlja, da bo organizacija sprožilec vedno prepoznala. Izjava o namenu bo morda potrebovala pregled, ko se uporaba spremeni, in v načrtovanem intervalu. Vrednotenje lahko poteče po spremembi različice, podatkovne poti ali konteksta. Načrt za incidente bo morda potreboval datum vaje, ker je lahko načrt, ki ni bil nikoli uporabljen, popolnoma napisan in praktično namišljen. Izhodno pot bo morda treba preizkusiti, preden jo nujno potrebujemo. Datum ne zagotavlja skrbnosti. Omogoča, da je zanemarjanje lažje opaziti.

Zapisi lahko ostanejo v arhivu, medtem ko izgubijo svojo veljavo za podporo trenutni odločitvi. Datum pregleda to razliko naredi vidno.

Potek veljavnosti ni neuspeh

Ekipe se pogosto upirajo datumom poteka veljavnosti, ker izraz "potek veljavnosti" zveni kot obtožba. Ni. Gre za izjavo o obsegu. Rezultat kalibracije je lahko veljaven za stanje modela in vhodne pogoje, ki so bili preizkušeni. Ocena varstva podatkov je lahko skrbna za opisano pot obdelave. Zagotovilo dobavitelja je lahko pomembno za določeno različico storitve in pogodbo. Program usposabljanja je lahko primeren za delo, ki so ga ljudje opravljali, ko so ga obiskovali. Noben od teh zapisov ne postane slab, ko se njegovi pogoji spremenijo. Postane nepopoln za novo odločitev.

To je eden od razlogov, zakaj je letni pregled hkrati uporaben in nezadosten. Letni datum vzpostavi minimalni ritem in prepreči, da bi zapisi za nedoločen čas izginili v skupni pogon. Toda večja sprememba se lahko zgodi že jutri. DORA združuje obe zamisli z zahtevo po rednem pregledu vsaj enkrat letno in oceno tveganja ob vsaki večji spremembi. Obe uri delujeta skupaj: periodični pregled ujame počasen odmik; sproženi pregled ujame pogoj, ki je že spremenil odločitev.

Potek veljavnosti bi moral biti vezan na trditve, ne le na dokumente. Dokument lahko vsebuje več trditev z različnimi življenjskimi dobami. Arhitekturni diagram lahko ostane večinoma točen, medtem ko se je opis varnostnega nadzora spremenil. Ocena lahko še vedno dokazuje ozko zmogljivost, čeprav ne podpira več širše izjave o delovanju. Politika je lahko aktualna, imenovani lastnik pa ne. Ko ekipa označi celotno datoteko kot aktualno ali zastarelo, izgubi te razlike. Vzdrževanje na ravni trditev je več dela. Prav tako daje pregledovalcem priložnost, da posodobijo tisto, kar se je spremenilo, ne da bi prepisovali zgodovino.

Tu je tudi človeška korist. Ljudje, ki podedujejo sistem, morajo vedeti, na kaj se lahko zanesejo. Zapis, ki pravi "aktualno" brez datuma, obsega ali lastnika, jim preda težavo z zaupanjem, preoblečeno v dokumentacijo. Zapis, ki pravi "ocenjeno za ta namen, s tem zajetim stanjem, pod temi pogoji, pregledano na ta datum, naslednji pregled tukaj", jim da nekaj, kar lahko preverijo in izpodbijajo. Sistem s tem ni varen zgolj na podlagi izjave. Meja obstoječega znanja postane vidna.

Potek veljavnosti tudi zmanjša dramatičnost umika. Sistemu ni treba biti škandal, da bi bil umaknjen ali zamenjan. Dobavitelj lahko preneha z podporo. Model morda ne ustreza več novemu jezikovnemu ali političnemu okolju. Dokazno breme lahko preseže vrednost vzdrževanja stare poti. Lahko obstaja varnejša alternativa. Organizacija se lahko odloči, da se naloga vrne osebi ali preprostejšemu mehanizmu brez umetne inteligence. Načrt vzdrževanja mora vključevati izhodno pot, preden storitev postane težko odstraniti. Umik je upravljavsko dejanje, ne dokaz, da je upravljanje spodletelo.

Kar ne sme poteči, je zgodovina. Organizacija mora ohraniti, kaj je bilo ocenjeno, odločeno, spremenjeno in opaženo, v skladu z veljavnimi pravili o hrambi, zaupnosti in varstvu podatkov. Ohranjanje zgodovine ni isto kot obravnavanje starih dokazov kot aktualnih. Eno podpira učenje in odgovornost. Drugo lahko spremeni zapuščinski zapis v lažno zagotovilo. Dobri arhivi si zapomnijo razliko.

Načrt je razporeditev pooblastil

Najbolj uporaben upravljavski artefakt je lahko manj razburljiv kot matrika tveganj: koledar z imeni ob njem. Kdo pregleda namen. Kdo bere signal spremljanja. Kdo lahko razglasi, da je prag dosežen. Kdo lahko začasno ustavi pot. Kdo odobri pomembno spremembo. Kdo preveri dokaze o preverjanju. Kdo komunicira z dobaviteljem. Kdo odloči, da stara ocena ne podpira več nadaljnje uporabe. Če je odgovor na vsa ta vprašanja "ekipa za umetno inteligenco", organizacija ni razporedila pooblastil. Poimenovala je sobo.

Organ oblasti potrebuje dovolj neodvisnosti, da je smiseln, in dovolj bližine, da lahko deluje. Upravni ali vodstveni organ lahko nosi odgovornost za nadzor in vire. Operativni lastnik lahko razume dejansko delo. Tehnični lastnik lahko pozna omejitve sistema. Strokovnjak za varnost ali zasebnost lahko prepozna mejo, ki je drugi ne vidijo. Ekipa, ki dela z strankami ali javnostjo, lahko opazi škodo prej kot nadzorna plošča. Teh vlog ni treba združiti v enega samega junaka. Potrebujejo opredeljene predaje in način za reševanje nesoglasij. Poudarek NIS2 na odobritvi in nadzoru s strani vodstva je tu uporaben, ker zavrača priročno izmišljotino, da je mogoče upravljanje v celoti prenesti, medtem ko odgovornost ostaja na vrhu.

Prag za eskalacijo mora biti zapisan v jeziku, ki ustreza odločitvi. „Eskaliraj, če ocena anomalije preseže 0,8“ je lahko tehnično potrebno, vendar instituciji ne pove, kaj je na kocki. Boljši prag lahko združi signal in posledico: eskaliraj, ko sistem začne vplivati na uporabo zunaj opredeljenega obsega; ko bi lahko okvara nadzora pustila prizadeto osebo brez pregleda; ko se spremeni pomemben vir ali odvisnost; ko popravki kažejo vzorec, ki ga obstoječa ocena ni zajela; ko je prijavljen resen varnostni, varnostni ali pravni pomislek; ko zahtevani lastnik ali rezervna možnost ni več na voljo. Natančni pragovi se bodo razlikovali. Jezik odločanja se ne bi smel.

Vzdrževanje potrebuje tudi proračun. To je vsakdanje in odločilno. Spremljanje porablja čas. Pregled spremembe porablja tehnične, pravne in operativne zmogljivosti. Vaja načrta za incidente prekinja redno delo. Posodabljanje pojasnila, zapisa ali programa usposabljanja je delo. Kadar upravljanje nima kadrovsko podprtega operativnega modela, postane nujni davek, ki ga plača tisti, ki težavo opazi prvi. Takšna ureditev je videti ekonomična do prvega težkega dogodka, ko organizacija ugotovi, da je prihranila stroške priprave in kupila stroške improvizacije.

Obstaja prostor za sorazmernost. Ozko notranje orodje z jasno uporabo brez posledic lahko potrebuje lažji urnik kot sistem, ki vpliva na dostop do dela, storitev, pravic ali varnosti. Toda lažje ne pomeni odsotno. Še vedno lahko potrebuje lastnika, mejo namena, zapis sprememb, osnovno pot za incidente in izhodni pogoj. Kompleksnost naj sledi posledicam in negotovosti, ne količini navdušenja, ki je na voljo ob začetku projekta.

Uporaben urnik vzdrževanja je mogoče zapisati v preprostem jeziku. Preglej namen, ko se spremenijo uporaba, uporabniki ali posledice. Preglej odvisnosti, ko se spremeni dobavitelj, podatkovna pot ali povezana storitev. Preglej dokaze o oceni, ko se spremenijo model, konfiguracija ali ustrezni pogoji delovanja. Izvajaj vajo poti za incidente in zaustavitev v opredeljenem intervalu. Preglej dodelitve vlog, ko se organizacija spremeni. Objavi ali hrani zapis sprememb, kadar ima odločitev pomemben učinek. Preizkusi izhodno pot, preden storitev postane odvisna od nje. Nobeno od tega ne obljublja, da do napak ne bo prišlo. Obljublja, da ima organizacija način, kako jih opaziti, se o njih odločiti in se iz njih učiti, ko se zgodijo.

Majhna opomba od nas

Pri Dweve naš Trust Centre opisuje spremljanje kot ločen javni zapis in ne kot obljubo, da je izdelek dosegel trajno stanje dokončanosti. Objavljeno gradivo o spremljanju navaja, da so signali povezani z opredeljenimi mejami zbiranja, da pregledi opredelijo ustrezen model, pot, stanje in dokaze ter da lahko pomembne spremembe sprožijo pregled ocene, tveganja, incidenta ali izdaje. Javni zapis sprememb prav tako razlikuje trenutna dejstva od pripravljenih kontrol in prihodnjih dogodkov. To so opisi našega navedenega operativnega načrta, ne neodvisno zagotovilo, rezultat za stranko ali trditev, da javna stran razreši vsako vprašanje upravljanja.

Ta meja je namerna. Menimo, da je zapis o spremljanju uporaben, ko bralcem pove, kaj je mogoče opazovati, kaj ostaja zaščiteno, kaj lahko sproži ukrepanje in kje bo zabeležena pomembna odločitev. Zapis ne more presojati v imenu ljudi, ki upravljajo sistem. Lahko pa poskrbi, da je presojo lažje preveriti, ko je sprejeta.

Vzdrževanje je pošteni del

Zagon je uporaben trenutek. Ustvari razlog za opredelitev namena, oceno tveganj in sprejemanje zavez. Ni pa trenutek, ko tehnologija preneha srečevati svet. Upravljanje postane verodostojno pozneje, pri ponavljajočem se delu ugotavljanja, ali stara odločitev še vedno zasluži, da ostane v veljavi.

To delo potrebuje koledar, ker imajo dobre namere kratek rok trajanja, če nimajo datuma, lastnika in poti do ukrepanja. Potrebuje dokaze, ker barva nadzorne plošče ni pojasnilo. Potrebuje pooblastila, ker je spremljanje brez pravice do sprememb le opazovanje z dobro tržno znamko. Potrebuje zgodovino, ker popravka, ki ga ni mogoče izslediti, ni mogoče zanesljivo uporabiti za izboljšanje naslednje odločitve. In potrebuje izhod, ker mora nadaljnje delovanje ostati izbira, ne podedovano dejstvo.

Zrelo vprašanje ni, ali lahko organizacija pripravi okvir upravljanja. Mnoge to zmorejo. Vprašanje je, ali lahko organizacija mesece po odobritvi dokumenta še vedno pove, čemu sistem služi, kaj se je spremenilo, kateri dokazi ga zdaj podpirajo, kdo ga lahko ustavi in kaj se zgodi, ko odgovor ni več jasen. Če to zmore, se upravljanje vzdržuje. Če tega ne zmore, ima organizacija morda še vedno politiko. Preprosto je prenehala imeti živo.

Viri