Ko upravljanje postane težava v izvajanju

Upravljanje umetne inteligence ni več samo skrb upravnega odbora, ko je treba modele, orodja, podatke, politike, proračune in pritožbe preverjati, medtem ko...

Ko upravljanje postane težava v izvajanju

Politika, ki je zgrešila zahtevo

Sestanek upravljanja je bil previden. Tveganja so bila navedena. Primer uporabe je bil razvrščen. Podatkovni viri so bili odobreni. Pravna podlaga je bila zabeležena. Za primere z velikim vplivom je bil potreben človeški nadzor. Zapisnik je bil dovolj čist, da je uradnik za skladnost za trenutek verjel v civilizacijo. Nato je sistem začel delovati in prva nerodna zahteva je prispela ob 09:14 v torek.

Zahtevi ni bilo mar, da se odbor sestaja mesečno. Nosila je uporabniško vlogo, datoteko stranke, različico politike, pot modela, dovoljenje za orodje, vprašanje o lokaciji podatkov, proračunsko omejitev in morebitni zunanji učinek. Delovni tok se je moral v nekaj sekundah odločiti, ali bo pridobil, ustvaril, stopnjeval, zavrnil, zabeležil, obvestil ali ukrepal. Upravljanje ni bilo več dokument za sistemom. Postalo je težava v realnem času znotraj sistema.

Tu mnogi programi umetne inteligence začutijo, da se tla premikajo. Zasnova upravljanja ni bila nujno napačna. Odbor ni bil nespameten. Jezik politike je bil morda celo dober. Težava je v tem, da sistemi umetne inteligence delujejo v gibanju. Pridobivajo svež kontekst, kličejo orodja, prečkajo meje storitev, ponovno uporabljajo podatke, ustvarjajo nove artefakte in vabijo ljudi, da se zanesejo na rezultate. Politika, ki ne more vstopiti v to gibanje, postane referenčno delo. Uporabno, morda. Ne zadostno.

Upravljanje v realnem času pomeni, da sistem lahko oceni pogoje upravljanja, medtem ko delo poteka. Kdo sprašuje. Za kakšen namen. Kateri podatki se lahko uporabijo. Kateri model je dovoljen. Katero orodje lahko ukrepa. Katera jurisdikcija velja. Kateri proračun je sprejemljiv. Kateri primeri potrebujejo človeški pregled. Kateri zapis je treba ustvariti. Katera pot obstaja za pritožbo. To niso samo vprašanja javnega naročanja ali letnega pregleda. To so vprašanja poti zahteve.

Upravljanje preneha biti oddaljena obljuba, ko mora živa pot zahteve preveriti pooblastila, omejitve in dokaze, preden se delo premakne.

Dokumenti so še vedno pomembni

Modno je skušnjavo posmehovati se dokumentom upravljanja. Politike, registri, ocene vpliva, okviri tveganj, pregledi dobaviteljev, kartice modelov, DPIA, zapiski o javnem naročanju, razporedi hrambe. Zagotovo lahko postanejo okrasni. Nekateri dokumenti so napisani z zloveščo eleganco ljudi, ki vedo, da nihče ne bo prebral dlje od pete strani. Toda odgovor ni v tem, da bi zaničevali dokumente. Odgovor je v tem, da nehamo pretvarjati, da so končna oblika upravljanja.

Dokumenti opisujejo namen, odgovornost, obseg, tveganje in razlago. Ustvarjajo institucionalni spomin. Ljudem omogočajo, da se prepirajo pred uvedbo namesto po škodi. Revizorjem, kupcem, inženirjem, pravnikom in vodjem dajejo skupno površino. To je dragoceno. Upravljanje ob izvajanju je od tega odvisno. Sistem ne more ovrednotiti politike, ki je nihče ni zapisal. Ne more uveljaviti namena, ki ga nihče ni opredelil. Ne more hraniti dokazov v skladu z rokom hrambe, ki ne obstaja.

Težava se začne, ko dokument obravnavamo, kot da se izvaja. Politika pravi, da rezultati z visokim tveganjem zahtevajo pregled, vendar potek dela nima stanja za zahtevan pregled. Ocena tveganja pravi, da model ne sme uporabljati občutljivega vira, vendar iskanje nima zaščite obsega vira. Nabavna opomba pravi, da mora dobavitelj podpirati revizijo, vendar integracija shranjuje le agregirane dnevnike. Rok hrambe pravi, da zapisi potečejo, vendar ustvarjeni izdelki brez sledljivosti zaidejo v nadaljnje sisteme. Dokument je naredil svoj del. Izvajalni sistem ni prejel sporočila, kar ni metafora, če je bilo sporočilo dobesedno poslano po e-pošti.

Dobro upravljanje zato vključuje korak prevajanja. Zapisana politika postane pogoji ob izvajanju: vrata, vloge, pragovi, sheme, dnevniki, opozorila, poti za pritožbe, pravila hrambe in preverjanja izdaje. Vsak stavek ne postane koda. Nekaj presoje ostane človeške. Toda sistem mora vedeti, kateri deli so operativni. V nasprotnem primeru upravljanje postane ceremonialna streha nad stavbo brez sten.

Pot zahteve je tam, kjer se obljube preizkusijo

O upravljanju umetne inteligence se pogosto razpravlja na ravni sistemov. Ali je ta sistem odobren. Ali je ta model zaupanja vreden. Ali je ta primer uporabe sprejemljiv. Ta vprašanja so pomembna, vendar se dejansko tveganje pojavi na ravni zahtev. Isti sistem je lahko za enega uporabnika nizko tveganje in za drugega visoko. Isti model je lahko sprejemljiv za osnutke in nesprejemljiv za avtonomno delovanje. Isti podatki so lahko dovoljeni za podporo in prepovedani za trženje. Isti odgovor je lahko znotraj neškodljiv in pomemben, ko je poslan navzven.

Upravljanje ob izvajanju vidi te razlike, ker ovrednoti kontekst. Zahteva usposobljenega zaposlenega pod ozkim namenom ni enaka zahtevi zunanjega uporabnika s širokim dostopom do orodij. Poizvedba po javni dokumentaciji ni enaka iskanju po občutljivem spisu primera. Osnutek sporočila ni enak poslanemu sporočilu. Priporočilo, ki ga človek lahko prezre, ni enako odločitvi, ki posodobi zapis. Pot zahteve je tam, kjer te razlike postanejo resnične.

To ne pomeni, da vsaka zahteva potrebuje pravni seminar. Pomeni, da mora sistem nositi dovolj konteksta za pravilno usmerjanje. Identiteta, namen, razred podatkov, razred vpliva, odobritev modela, obseg orodij, jurisdikcija, reverzibilnost, človeška vloga in zahteva po dokazih. Številna preverjanja so preprosta, ko so poimenovana. Težji del ni vedno izračun. Težji del je priznati, da je kontekst pomemben, in ga ne zgladiti zaradi udobja.

Udobje je tam, kjer se upravljanje ob izvajanju običajno izgubi. Razvijalec doda bližnjico, ker je čakalna vrsta za pregled počasna. Produktna ekipa ponovno uporabi vir podatkov, ker se imena polj ujemajo. Vodja odobri začasno izjemo, ker je izid blizu. Poziv dobi novo navodilo, ker vrata politike še niso pripravljena. Vsak korak je lahko razumljiv. Skupaj zgradijo sistem, kjer upravljanje obstaja v duhu in odpove na poti. Duh je slab izvajalni pogoj.

Vrata politike niso lastniki politike

Zagonski prehod lahko uveljavi pogoj, vendar ne poseduje pomena pogoja. To razlikovanje je pomembno. Lastnik pravilnika odloča, kateri primeri zahtevajo pregled, kateri viri so dovoljeni, katero obdobje hrambe velja in katere škode so pomembne. Prehod te odločitve izvaja hitro. Če organizacija zamenjuje oboje, inženiring tiho postane pravilnik ali pa pravilnik začne pretvarjati, da je podrobnost izvedbe nekdo drug problem.

Zdrav vzorec je pogodba med pravilnikom in izvajanjem. Lastniki pravilnikov opredelijo pravila, pragove, izjeme in obveznosti pregleda. Inženirji izvajajo prehode, teste, zapise in načine odpovedi. Operaterji spremljajo, ali prehodi sprožajo, kot je pričakovano. Pregledovalci posredujejo povratne informacije, kjer pravila ustvarjajo nesmiselne izide. Upravljavski organi pregledajo dokaze in spremenijo pravilnik, ko je resničnost nevljudna. To je upravljanje kot zanka, ne kot uokvirjen PDF.

Pravilniški prehodi potrebujejo tudi različice. Zahteve, obravnavane po pravilu iz prejšnjega meseca, ne bi smele biti ocenjene pozneje, kot da bi današnje pravilo že obstajalo. Odprt primer lahko prečka izdajo pravilnika. Model lahko ustvarja osnutke po enem pragu in dejanja po drugem. Če sistem beleži samo trenutno stanje pravilnika, revizije postanejo potovanje skozi čas s slabimi oznakami. Zapis mora povedati, katera različica pravila je veljala za kateri prehod.

Tu je skromna disciplina, ki prihrani veliko drame. Obravnavajte pravilnik kot živo odvisnost. Dajte mu identifikatorje. Dajte mu lastnike. Testirajte ga. Uvajajte ga postopoma. Umaknite ga. Opazujte ga. Zabeležite njegove odločitve. To ne naredi pravilnika mehanskega. Naredi mehanski del dovolj pošten, da lahko ljudje upravljajo preostanek.

Lokalnost spremeni upravljanje v usmerjanje

Lokalnost podatkov je bila nekoč obravnavana kot vprašanje shranjevanja. Kje je podatkovna baza. Katera regija. Kateri ponudnik. Katera varnostna kopija. V sistemih z umetno inteligenco lokalnost postane bolj aktivna. Pridobivanje lahko potegne podatke iz ene regije, model lahko deluje v drugi, orodje lahko pokliče storitev tretje osebe, človeški pregledovalec pa je lahko pod drugačnim pravnim režimom. Vprašanje ni več samo, kje podatki počivajo. Je, kje delo prečka meje.

Upravljanje med izvajanjem mora zato usmerjati glede na lokalnost. Nekateri podatki lahko zapustijo napravo samo kot agregat. Nekateri zapisi se lahko obdelujejo v eni jurisdikciji, ne pa v drugi. Nekateri ponudniki so lahko odobreni za nizko občutljivost in blokirani za višje razrede. Nekatere poti modelov so lahko dovoljene za javno besedilo, ne pa za osebne datoteke. Nekateri dnevniki lahko ostanejo lokalni, tudi ko je klic modela oddaljen. Teh izbir ni mogoče rešiti samo ob nabavi. Živa zahteva nosi odgovor.

Lokalnost ni samo pravo. Je zmogljivost, odpornost, varnost, strošek in institucionalni nadzor. Lokalni model je lahko počasnejši, a bolj sprejemljiv za občutljivo delo. Oddaljena storitev je lahko cenejša, a neprimerna za določene zapise. Regionalni indeks lahko zmanjša zakasnitev, a ustvari razhajanje različic. Ponudnik lahko podpira šifriranje, ne pa izvoznega formata, potrebnega za revizijo. Upravljanje med izvajanjem teh kompromisov ne reši čudežno. Naredi jih eksplicitne, preden sistem pošlje delo čez mejo.

Alternativa je skrito usmerjanje. Potek dela pokliče katero koli končno točko, ki je priročna. Končna točka pokliče drugo storitev. Dnevniki se premaknejo drugam. Izpeljani podatki se pojavijo v analitiki. Šest mesecev pozneje nekdo vpraša, kam je šel primer. Odgovor zahteva diagram, dva inženirja in presenetljivo mero optimizma. To ni upravljanje. To je kartografija po odpravljanju.

Pri sistemih z umetno inteligenco je lokalnost živi problem usmerjanja. Ustrezna meja se lahko pojavi znotraj ene same zahteve.

Proračuni so upravljanje, ne finančna malenkost

O proračunih za umetno inteligenco se pogosto razpravlja šele, ko prispejo računi, kar je nekoliko prepozno, podobno kot je prepozno zapreti hlev, potem ko je konj že naročil premium paket žetonov. Strošek je vprašanje upravljanja v realnem času, ker neobvladan strošek spreminja vedenje. Ekipe onemogočijo sledenje. Skrajšajo vrednotenje. Izognejo se človeškemu pregledu. Znižajo kakovost virov. Preveč agresivno združujejo. Pustijo agentskim zankam, da tavajo. Težava s stroški postane težava z nadzorom, ki ji je priložen še računovodski vidik.

Sistem v realnem času bi moral proračun poznati kot del poti. Koliko klicev modela lahko opravi ta zahteva. Katera orodja so dovoljena. Koliko konteksta je upravičenega. Koliko poskusov ponovitve. Kdaj naj agent ustavi. Kdaj je cenejša pot sprejemljiva. Kdaj primer z velikim vplivom zasluži dražje dokaze. Strošek ni le zgornja meja. Je način za izražanje prednosti in preprečevanje neobvladanega vedenja.

Proračunske zaščite zmanjšujejo tudi varnostno tveganje. Zanka, ki porablja denar, lahko ponavlja dejanja, podvaja sporočila, zaklepa zapise ali obremenjuje dobavitelja. Postopek pridobivanja, ki potegne preveč podatkov, lahko poveča izpostavljenost zasebnosti. Naloga povzemanja, ki obdela vsak dokument, lahko ustvari izpeljane zapise z novimi obveznostmi. Omejitve korakov, kvote, preklic in metrike stroškov na uporaben rezultat so nadzorni mehanizmi upravljanja. So manj plemeniti kot izjave o vrednotah in bolj verjetno ustavijo stroj ob pravem trenutku.

To ne pomeni, da je najcenejša pot tudi odgovorna pot. Včasih močnejši dokazi stanejo več. Včasih lokalna obdelava stane več in je še vedno pravilna. Včasih je človeški pregled drag, ker je prav to bistvo. Upravljanje v realnem času bi moralo te odločitve narediti vidne. Cilj ni poceni umetna inteligenca. Cilj je umetna inteligenca, katere stroški, dokazi in tveganja so razumljeni, medtem ko delo poteka.

Načini odpovedi imajo znan vonj

Odpovedi upravljanja v realnem času redko pridejo z napisom. Imajo znan vonj. Odmik od politik. Senčna orodja. Prekoračitev pooblastil. Manjkajoča pritožba. Proračunske zanke. Zastarela privolitev. To niso eksotične pošasti umetne inteligence. To so običajne organizacijske odpovedi, ki jih programska oprema pospeši. To je skoraj še huje, ker je običajne odpovedi lahko opravičiti, dokler ne postanejo infrastruktura.

Do politike pride do odmika, ko se pisno pravilo spremeni, izvajalna pot pa ne, ali ko se izvajalna pot spremeni, pisno pravilo pa ne. Senčna orodja se pojavijo, ko ekipe zaobidejo počasne kontrole z neuradnimi integracijami. Do prekoračitve pride, ko sistem, odobren za podporo, tiho začne vplivati na uveljavljanje, cene ali dostop. Do manjkajoče pritožbe pride, ko uporabniki prejmejo izid, ki ga je oblikovala umetna inteligenca, vendar ga ne morejo izpodbijati na način, ki bi prišel v zapisnik. Do zank v proračunu pride, ko agenti ali paketna opravila še naprej porabljajo sredstva, potem ko se je koristno delo končalo. Do zastarele privolitve pride, ko se stara dovoljenja obravnavajo kot sveža, ker nihče ni naredil privolitve dela poti zahteve.

Koristen odziv ni panika. Je instrumentacija. Poimenujte vrsto napake. Dodajte zaščito, kjer jo je mogoče preprečiti. Dodajte opozorilo, kjer jo je mogoče zaznati. Določite odgovorno osebo, kjer jo je mogoče odpraviti. Dodajte zapis, kjer je potreben nadzor. Nekatere napake zahtevajo spremembo politike. Nekatere zahtevajo spremembo vmesnika. Nekatere zahtevajo podatkovne pogodbe. Nekatere zahtevajo nabavno disciplino. Upravljanje izvajanja pomaga, ker organizaciji daje mesto, kamor lahko pritrdi rešitev.

Razkriva tudi neprijetne resnice. Vrata lahko pokažejo, da priljubljenemu primeru uporabe manjka pravna podlaga. Preverjanje privolitve lahko pokaže, da podatkovni cevovod ni tako urejen, kot kažejo predstavitvene prosojnice. Omejitev proračuna lahko pokaže, da poslovni načrt deluje le, če je vrednotenje premalo financirano. Zapisnik pritožbe lahko pokaže, da nepoštene izide ustvarja politika, ne model. Dobri dokazi upravljanja so nevljudni. To je ena njihovih najboljših lastnosti.

Upravljanje izvajanja poimenuje napako, medtem ko sistem še vedno deluje, ne šele potem, ko je poprodajna analiza odkrila pridevnike.

Človeško upravljanje mora ostati v zanki

Upravljanje izvajanja ni načrt za odstranitev ljudi iz upravljanja. Ravno nasprotno. Ljudem daje boljša mesta za posredovanje. Upravni odbor ne more oceniti vsake zahteve. Lastnik politike ne more odobriti vsakega klica orodja. Pravnik ne more sedeti pri vsaki odločitvi o pridobivanju. Pregledovalec ne more pregledati vsakega osnutka z nizkim tveganjem. Sistem mora obravnavati običajne preglede. Ljudje morajo biti lastniki pravil, izjem, spornih primerov, razlage in popravil.

Ključ je načrtovanje eskalacije. Kdaj naj se sistem ustavi in vpraša. Kdaj naj zavrne brez vprašanja. Kdaj naj dovoli in zabeleži. Kdaj naj vzorči za poznejši pregled. Kdaj naj se ponavljajoči signali z nizkim tveganjem spremenijo v vzorec z visokim tveganjem. Kdaj naj pritožba uporabnika znova odpre zaprto stanje. To so odločitve upravljanja. Ne smejo biti skrite v pozivih, privzetih nastavitvah čakalne vrste ali junaški presoji tistega, ki je trenutno na voljo.

Runtime dokazi izboljšujejo človeško upravljanje, ker odborom dajo nekaj boljšega od anekdot. Upravljalna skupina lahko vidi, kako pogosto so bila vrata blokirana, kje so bile izjeme združene, kateri pritožbi sta bili uspešni, kateri dobavitelji so povzročali trenja, katere politike so upočasnjevale delo in katere poti modelov so povzročale incidente. Nato sestanek postane osredotočen na dokaze. Še vedno je lahko dolg. Ne smemo obljubljati čudežev. Toda vsaj ima možnost, da bo koristen.

Ljudje so še vedno potrebni, ker politika včasih nasprotuje resničnosti. Pravilo je lahko pravno pravilno in operativno kruto. Vir podatkov je lahko dovoljen in še vedno družbeno tvegan. Model lahko deluje dobro v povprečju in odpove pri ranljivem robnem primeru. Proračunska omejitev lahko prihrani denar in ustvari nepošteno zamudo. Sistemi za izvajanje lahko razkrijejo te konflikte. Ljudje se morajo odločiti, kaj pomenijo.

Upravljanje izvajanja spreminja javna naročila

Nakup umetne inteligence brez podpore za upravljanje izvajanja pomeni nakup prihodnje negotovosti. Dobavitelj ima lahko odlične modele, prijetne predstavitve, certifikate in samozavestne predstavitve. Praktična vprašanja so manj glamurozna. Ali lahko sistem razkrije odločitve o politikah za vsako zahtevo. Ali je mogoče zakleniti različice modelov in pozivov. Ali je mogoče lokalnost podatkov uveljaviti dinamično. Ali je mogoče klice orodij omejiti in zabeležiti. Ali je mogoče dnevnike ločiti po namenu. Ali je mogoče dokaze izvoziti v uporabni obliki. Ali lahko institucija odide s svojimi zapisi. Ali je mogoče primer ponoviti, ko je dobavitelj spremenil svojo platformo.

Ta vprašanja niso sovražna do dobaviteljev. So odrasla. Dobavitelj, ki podpira upravljanje izvajanja, kupcu pomaga delovati odgovorno. Dobavitelj, ki tega ne more podpreti, je lahko še vedno uporaben za naloge z nizkim tveganjem, vendar mora kupec poznati mejo. Najslabši izid je pretvarjanje, da je splošna zmogljivost primerna za pomembno delo, zgolj zato, ker predstavitev ni vključevala težave z upravljanjem. Predstavitve tega redko vključujejo. Zato se prilegajo v prostore s prigrizki.

Javna naročila bi morala vprašati tudi o odpovedi. Kaj se zgodi, ko vrata politike niso na voljo. Ali sistem odpove zaprto, odpove odprto ali preusmeri na pregled. Kaj se zgodi, ko je model opuščen. Kaj se zgodi, ko regija postane nedosegljiva. Kaj se zgodi, ko je zahtevan izvoz revizije. Kaj se zgodi, ko uporabnik zahteva izbris. Kaj se zgodi, ko dnevniki vsebujejo občutljive podatke. Odgovor na upravljanje je pogosto skrit v načinu odpovedi.

Upravljanje izvajanja ne zahteva, da vsak dobavitelj razkrije vsako notranjo metodo. Zahteva, da je meja storitve odgovorna. Kupec potrebuje dovolj nadzora in dokazov, da izpolni lastne dolžnosti. Če lahko komponenta črne škatle varno sedi za upravljano mejo, je to v redu. Če je meja sama črna škatla, je kupec oddal ne le zmogljivost, ampak tudi del svoje sposobnosti, da odgovarja za delo.

Upravljanje kot operativna zanka

Zrel vzorec je operativna zanka. Zaznaj, kaj se dogaja. Oceni kontekst. Zavrni dejanje. Deluj v mejah. Preglej rezultate. Posodobi pravila, podatke, modele in vmesnike. Ta zanka deluje pri različnih hitrostih. Nekateri pregledi se zgodijo za vsako zahtevo. Nekateri dnevno. Nekateri po objavi. Nekateri četrtletno. Nekateri po incidentih. Pomembno je, da so zanke povezane. Pritožba mora doseči oceno. Pritožba mora doseči politiko. Sprememba politike mora doseči vrata. Nadgradnja modela mora doseči teste. Incident dobavitelja mora doseči usmerjanje.

Tako upravljanje postane manj teatralno. Neha biti niz slovesnosti okoli sistema in postane lastnost delovanja sistema. Organizacija lahko še vedno ima odbore, registre, politike in poročila. Mora jih imeti. Toda ti artefakti so zdaj povezani z živimi dokazi. Sestanek o upravljanju lahko vpraša, kaj je sistem naredil, ne le, kaj sistem trdi, da je.

Delovna zanka naredi upravljanje tudi bolj prilagodljivo. Sistemi umetne inteligence se spreminjajo. Zakoni se spreminjajo. Podatki se spreminjajo. Vedenje uporabnikov se spreminja. Modeli se spreminjajo. Pogoji dobaviteljev se spreminjajo. Statično odobravanje ne more zajeti vsega tega. Upravljanje v realnem času ne rešuje negotovosti z zamrznitvijo sveta. Organizaciji daje način za zaznavanje, odločanje in posodabljanje, ne da bi pri tem izgubila odgovornost za prejšnje odločitve.

Zanka mora imeti spomin. Sicer prilagajanje postane tiho prepisovanje. Ko se pravilo spremeni, stari primeri še vedno potrebujejo svoj stari kontekst. Ko se pot modela umakne, pretekle odločitve še vedno potrebujejo pojasnilo. Ko se vir odstrani, izpeljani rezultati še vedno potrebujejo izvor. Upravljanje v realnem času mora podpirati spremembe, ne da bi izbrisalo razloge iz preteklosti. To je dolgočasen stavek z velikimi posledicami.

Upravljanje postane trajno, ko živi dokazi spremenijo naslednje pravilo in ko naslednje pravilo ostane povezano z zapisom, ki ga je nadomestilo.

Nauček

Upravljanje postane problem v realnem času, ko se sistemi umetne inteligence premikajo hitreje, širše in bolj kontekstualno, kot lahko artefakti upravnih odborov obvladajo sami. Odgovor ni opustiti dokumente o upravljanju ali nadomestiti človeške presoje s kodo. Odgovor je povezati dokumente, vloge, politike, vrata, zapise in pregledovalne zanke, da lahko upravljanje deluje, medtem ko delo poteka.

Upravljanje v realnem času preverja identiteto, namen, podatke, lokacijo, pot modela, pooblastila orodij, proračun, človeški pregled, dokaze, pritožbe in hrambo v živi poti. Politike obravnava kot žive odvisnosti. Namenoma usmerja promet čez pravne in operativne meje. Zapisuje, katero pravilo je veljalo. Poimenuje načine odpovedi, preden postanejo navade. Ljudem daje dokaze namesto anekdot.

To je manj romantičen pogled na upravljanje in bolj uporaben. Resno vprašanje ni, ali ima organizacija okvir za upravljanje umetne inteligence. Resno vprašanje je, kaj se zgodi ob 09:14 v torek, ko resnična zahteva pozove sistem, naj se premakne. Če je odgovor preverjen, omejen, zabeležen in pregleden, upravljanje deluje. Če je odgovor, da je politika v mapi, upravljanje še vedno čaka na uradne ure.