Kun hallinnosta tulee ajonaikainen ongelma
Käytäntö, joka ei tavoittanut pyyntöä
Hallintokokous oli huolellinen. Riskit listattiin. Käyttötapaus luokiteltiin. Tietolähteet hyväksyttiin. Oikeusperusta kirjattiin. Ihmisen valvontaa edellytettiin vaikutuksiltaan merkittävissä tapauksissa. Pöytäkirja oli niin siisti, että vaatimustenmukaisuudesta vastaava virkamies saattoi hetken uskoa sivilisaatioon. Sitten järjestelmä otettiin käyttöön, ja ensimmäinen hankala pyyntö saapui tiistaina kello 09:14.
Pyyntö ei välittänyt siitä, että komitea kokoontui kuukausittain. Se sisälsi käyttäjäroolin, asiakastiedoston, käytäntöversion, mallireitin, työkaluoikeuden, tietojen sijaintia koskevan kysymyksen, budjettirajan ja mahdollisen ulkoisen vaikutuksen. Työnkulun oli päätettävä sekunneissa, haetaanko, luodaanko, nostetaanko asiaa, kieltäydytäänkö, kirjataanko, ilmoitetaanko vai toimitaanko. Hallinto ei ollut enää järjestelmän takana oleva asiakirja. Siitä oli tullut järjestelmän sisäinen suoritusaikainen ongelma.
Tässä kohdassa monet tekoälyohjelmat tuntevat maan liikkuvan jalkojen alla. Hallintorakenne ei välttämättä ollut väärä. Hallitus ei ollut tyhmä. Käytännön kieli saattoi jopa olla hyvää. Ongelma on se, että tekoälyjärjestelmät toimivat liikkeessä. Ne hakevat tuoretta kontekstia, kutsuvat työkaluja, ylittävät palvelurajoja, käyttävät dataa uudelleen, tuottavat uusia artefakteja ja kutsuvat ihmisiä luottamaan tuloksiin. Käytäntö, joka ei pääse mukaan tähän liikkeeseen, muuttuu hakuteokseksi. Hyödyllinen ehkä. Ei riittävä.
Suoritusaikainen hallinto tarkoittaa, että järjestelmä voi arvioida hallinnon edellytykset työn ollessa käynnissä. Kuka kysyy. Mihin tarkoitukseen. Mitä dataa saa käyttää. Mikä malli on sallittu. Mikä työkalu saa toimia. Mikä lainkäyttöalue soveltuu. Mikä budjetti on hyväksyttävä. Mitkä tapaukset vaativat ihmisen tarkistuksen. Mikä tietue on kirjoitettava. Mikä reitti on olemassa haastamista varten. Nämä eivät ole vain hankintakysymyksiä tai vuosiarviointikysymyksiä. Ne ovat pyyntöpolun kysymyksiä.
Asiakirjoillakin on merkitystä
On muodikasta kiusaus pilkata hallintoasiakirjoja. Käytännöt, rekisterit, vaikutustenarvioinnit, riskikehykset, toimittaja-arvioinnit, mallikortit, tietosuojan vaikutustenarvioinnit, hankintamuistiot, säilytysaikataulut. Niistä voi varmasti tulla koristeellisia. Jotkin asiakirjat on kirjoitettu sillä kummittelevalla eleganssilla, joka on tyypillistä ihmisille, jotka tietävät, ettei kukaan lue viidennen sivun jälkeen. Mutta vastaus ei ole halveksia asiakirjoja. Vastaus on lopettaa teeskentely siitä, että ne ovat hallinnon lopullinen muoto.
Asiakirjat kuvaavat tarkoitusta, vastuuta, laajuutta, riskiä ja tulkintaa. Ne luovat institutionaalisen muistin. Ne antavat ihmisille mahdollisuuden väitellä ennen käyttöönottoa sen sijaan, että he väittelivät vahingon jälkeen. Ne antavat auditoijille, ostajille, insinööreille, juristeille ja esihenkilöille yhteisen pinnan. Se on arvokasta. Käytönaikainen hallinta riippuu siitä. Järjestelmä ei voi arvioida käytäntöä, jota kukaan ei ole kirjoittanut. Se ei voi valvoa tarkoitusta, jota kukaan ei ole määritellyt. Se ei voi säilyttää todisteita aikataulun mukaan, jota ei ole olemassa.
Ongelma alkaa, kun asiakirjaa kohdellaan kuin se toimisi. Käytäntö sanoo, että suuren riskin tulokset vaativat tarkistuksen, mutta työnkulussa ei ole tilaa tarkistuksen vaatimiselle. Riskinarviointi sanoo, että malli ei saa käyttää arkaluonteista lähdettä, mutta haussa ei ole lähdealueen suojaa. Hankintamuistio sanoo, että toimittajan on tuettava auditointia, mutta integraatio tallentaa vain koostetut lokit. Säilytysaikataulu sanoo, että tietueet vanhenevat, mutta tuotetut artefaktit kulkeutuvat alavirran järjestelmiin ilman alkuperäketjua. Asiakirja teki osansa. Käytönaikainen järjestelmä ei saanut muistiota, mikä ei ole vertauskuva, kun muistio lähetettiin kirjaimellisesti sähköpostilla.
Hyvällä hallinnalla on siksi käännösvaihe. Kirjoitetusta käytännöstä tulee käytönaikaisia ehtoja: portit, roolit, kynnykset, skeemat, lokit, hälytykset, valitusreitit, säilytyssäännöt ja julkaisutarkistukset. Jokaisesta lauseesta ei tule koodia. Osa harkinnasta pysyy ihmisellä. Mutta järjestelmän on tiedettävä, mitkä osat ovat toiminnallisia. Muuten hallinnasta tulee seremoniallinen katto rakennuksen päällä, jossa ei ole seiniä.
Pyyntöpolku on paikka, jossa lupaukset testataan
Tekoälyhallinnasta keskustellaan usein järjestelmien tasolla. Onko tämä järjestelmä hyväksytty. Onko tämä malli luotettava. Onko tämä käyttötapaus hyväksyttävä. Näillä kysymyksillä on merkitystä, mutta todellinen riski näkyy pyyntöjen tasolla. Sama järjestelmä voi olla pienen riskin toiselle käyttäjälle ja suuren riskin toiselle. Sama malli voi olla hyväksyttävä luonnosteluun ja ei-hyväksyttävä autonomiseen toimintaan. Samat tiedot voivat olla sallittuja tukeen ja kiellettyjä markkinointiin. Sama vastaus voi olla vaaraton sisäisesti ja seurauksellinen, kun se lähetetään ulkopuolelle.
Käytönaikainen hallinta näkee nämä erot, koska se arvioi kontekstia. Koulutetun työntekijän pyyntö kapeassa tarkoituksessa ei ole sama kuin ulkoisen käyttäjän pyyntö laajoilla työkaluoikeuksilla. Haku julkisesta dokumentaatiosta ei ole sama kuin haku arkaluonteisesta asiakirjasta. Luonnosviesti ei ole sama kuin lähetetty viesti. Suositus, jonka ihminen voi jättää huomiotta, ei ole sama kuin päätös, joka päivittää tietueen. Pyyntöpolku on paikka, jossa nämä erot tulevat todellisiksi.
Tämä ei tarkoita, että jokainen pyyntö tarvitsisi juridisen seminaarin. Se tarkoittaa, että järjestelmän tulisi kantaa riittävästi kontekstia reitittääkseen oikein. Identiteetti, tarkoitus, tietoluokka, vaikutusluokka, mallin hyväksyntä, työkalujen laajuus, lainkäyttöalue, peruutettavuus, ihmisen rooli ja todistevaatimus. Monet tarkistukset ovat yksinkertaisia, kun ne on nimetty. Vaikea osa ei ole aina laskenta. Vaikea osa on myöntää, että kontekstilla on merkitystä, ja kieltäytyä tasoittamasta sitä pois mukavuuden vuoksi.
Mukavuus on paikka, jossa käytönaikainen hallinta yleensä menetetään. Kehittäjä lisää oikotien, koska tarkistusjono on hidas. Tuotetiimi käyttää uudelleen tietolähdettä, koska kenttien nimet täsmäävät. Esihenkilö hyväksyy väliaikaisen poikkeuksen, koska julkaisu on lähellä. Kehote saa uuden ohjeen, koska käytäntöportti ei ole valmis. Jokainen liike voi olla ymmärrettävä. Yhdessä ne rakentavat järjestelmän, jossa hallinta on olemassa hengessä ja epäonnistuu polussa. Henki on huono käytönaikainen riippuvuus.
Käytäntöportit eivät ole käytäntöjen omistajia
Runtime-portti voi pakottaa ehdon, mutta se ei omista ehdon merkitystä. Tämä ero on tärkeä. Käytännön omistaja päättää, mitkä tapaukset vaativat tarkistuksen, mitkä lähteet ovat sallittuja, mikä säilytysaika sovelletaan ja mitkä haitat ovat merkityksellisiä. Portti soveltaa näitä päätöksiä nopeasti. Jos organisaatio sekoittaa nämä kaksi, tekniikka alkaa huomaamatta muuttua käytännöksi tai käytäntö alkaa teeskennellä, että toteutuksen yksityiskohdat ovat jonkun muun ongelma.
Terve malli on sopimus käytännön ja rungon välillä. Käytännön omistajat määrittelevät säännöt, kynnykset, poikkeukset ja tarkistusvelvoitteet. Insinöörit toteuttavat portit, testit, lokit ja vikatilat. Operaattorit seuraavat, laukeavatko portit odotetusti. Tarkistajat antavat palautetta siitä, missä säännöt tuottavat absurdeja lopputuloksia. Hallintoelimet tarkastelevat todisteita ja muuttavat käytäntöä, kun todellisuus on ollut epäkohtelias. Tämä on hallintoa silmukkana, ei kehystettynä PDF:nä.
Käytäntöporteissa tarvitaan myös versiointia. Viime kuun säännön mukaan käsiteltyä pyyntöä ei pitäisi myöhemmin arvioida niin kuin tämän päivän sääntö olisi ollut voimassa. Vireillä oleva tapaus voi ylittää käytännön julkaisun. Malli voi tuottaa luonnoksia yhdellä kynnyksellä ja toimia toisella. Jos järjestelmä tallentaa vain nykyisen käytännön tilan, auditoinneista tulee aikamatkustusta huonoine opasteineen. Lokin on kerrottava, mikä sääntöversio sovellettiin mihinkin siirtymään.
Tässä on vaatimaton kurinalaisuus, joka säästää paljon draamalta. Kohtele käytäntöä kuin elävää riippuvuutta. Anna sille tunnisteet. Anna sille omistajat. Testaa se. Vaiheista se. Palauta se. Tarkkaile sitä. Tallenna sen päätökset. Tämä ei tee käytännöstä mekaanista. Se tekee mekaanisesta osasta riittävän rehellisen, jotta ihmiset voivat hallita loppua.
Lokaalisuus muuttaa hallinnon reititykseksi
Tietojen lokaalisuudesta puhuttiin ennen tallennusongelmana. Missä tietokanta on. Mikä alue. Mikä toimittaja. Mikä varmuuskopio. Tekoälyjärjestelmissä lokaalisuudesta tulee aktiivisempaa. Haku voi tuoda tietoja yhdeltä alueelta, malli voi toimia toisella, työkalu voi kutsua kolmannen osapuolen palvelua ja ihmistarkistaja voi toimia eri oikeusjärjestelmän alla. Kysymys ei ole enää vain siitä, missä tiedot lepäävät. Se on siitä, missä työ ylittää rajoja.
Runtimen hallinnon on siis reititettävä lokaalisuuden mukaan. Osa tiedoista voi poistua laitteesta vain aggregaattina. Osa lokitiedoista voidaan käsitellä yhdessä lainkäyttöalueella, mutta ei toisessa. Osa toimittajista voidaan hyväksyä matalalle herkkyystasolle ja estää korkeammille luokille. Osa mallireiteistä voidaan sallia julkiselle tekstille, mutta ei henkilökohtaisille tiedostoille. Osa lokeista voi pysyä paikallisina, vaikka mallikutsu olisi etä. Näitä valintoja ei voida ratkaista vain hankintavaiheessa. Elävä pyyntö kantaa vastauksen mukanaan.
Lokaalisuus ei ole vain lakia. Se on suorituskykyä, sietokykyä, tietoturvaa, kustannuksia ja institutionaalista hallintaa. Paikallinen malli voi olla hitaampi, mutta hyväksyttävämpi herkälle työlle. Etäpalvelu voi olla halvempi, mutta sopimaton tietyille tietueille. Alueellinen indeksi voi vähentää viivettä, mutta aiheuttaa versioiden eriytymistä. Toimittaja voi tukea salausta, mutta ei auditoinnin edellyttämää vientimuotoa. Runtimen hallinto ei ratkaise näitä kompromisseja taianomaisesti. Se tekee niistä näkyviä ennen kuin järjestelmä lähettää työtä rajan yli.
Vaihtoehto on piilotettu reititys. Työnkulku kutsuu mitä tahansa päätepistettä, joka on kätevä. Päätepiste kutsuu toista palvelua. Lokit siirtyvät muualle. Johdettu data ilmestyy analytiikkaan. Kuusi kuukautta myöhemmin joku kysyy, minne tapaus meni. Vastaus vaatii kaavion, kaksi insinööriä ja yllättävän määrän optimismia. Tämä ei ole hallintoa. Se on kartografiaa retkikunnan jälkeen.
Budjetit ovat hallintaa, eivät talousasioiden yksityiskohtia
Tekoälybudjeteista keskustellaan usein vasta, kun laskut ovat saapuneet, mikä on hieman myöhäistä samalla tavalla kuin tallin oven sulkeminen sen jälkeen, kun hevonen on tilannut premium-token-paketin, on hieman myöhäistä. Kustannus on suorituksenaikainen hallintakysymys, koska hallitsemattomat kustannukset muuttavat käyttäytymistä. Tiimit poistavat jäljityksen käytöstä. He lyhentävät arviointia. He välttävät ihmisen tekemää tarkistusta. He laskevat lähdelaatua. He eräajavat liian aggressiivisesti. He antavat agenttisilmukoiden harhailla. Kustannusongelmasta tulee valvontaongelma, johon on liitetty kirjanpito.
Suorituksenaikaisen järjestelmän tulisi tuntea budjetti osana reittiä. Kuinka monta mallikutsua tämä pyyntö saa tehdä. Mitkä työkalut ovat sallittuja. Kuinka paljon kontekstia on perusteltua. Kuinka monta uudelleenyritystä. Milloin agentin tulisi pysähtyä. Milloin halvempi reitti on hyväksyttävä. Milloin vaikutukseltaan suuri tapaus ansaitsee kalliimmat todisteet. Kustannus ei ole vain katto. Se on tapa ilmaista prioriteetti ja estää hallitsematon käyttäytyminen.
Budjettisuojat vähentävät myös turvallisuusriskiä. Silmukka, joka kuluttaa rahaa, voi myös toistaa toimintoja, kopioida viestejä, lukita tietueita tai kuormittaa toimittajaa. Hakutoiminto, joka vetää liikaa dataa, voi lisätä yksityisyyden altistumista. Yhteenvetotehtävä, joka käsittelee jokaisen asiakirjan, voi luoda johdettuja tietueita, joihin liittyy uusia velvoitteita. Vaiherajat, kiintiöt, peruutus ja kustannus-per-hyödyllinen-tulos-mittarit ovat hallintakeinoja. Ne ovat vähemmän jalostettuja kuin arvolausunnot ja todennäköisemmin pysäyttävät koneen oikealla hetkellä.
Tämä ei tarkoita, että halvin reitti olisi vastuullinen reitti. Joskus vahvemmat todisteet maksavat enemmän. Joskus paikallinen käsittely maksaa enemmän ja on silti oikein. Joskus ihmisen tekemä tarkistus on kallista, koska se on tarkoitus. Suorituksenaikaisen hallinnan tulisi tehdä nämä valinnat näkyviksi. Tavoitteena ei ole halpa tekoäly. Tavoitteena on tekoäly, jonka kustannukset, todisteet ja riskit ymmärretään työn ollessa käynnissä.
Vikatilat tuoksuvat tutuilta
Suorituksenaikaisen hallinnan viat eivät harvoin saavu kyltin kanssa. Ne tuoksuvat tutuilta. Käytäntöjen ajautuminen. Varjotyökalut. Ylilyönnit. Puuttuva valitus. Budjettisilmukat. Vanhentunut suostumus. Nämä eivät ole eksoottisia tekoälyhirviöitä. Ne ovat tavallisia organisaation epäonnistumisia, joita ohjelmisto on kiihdyttänyt. Se on melkein pahempaa, koska tavalliset epäonnistumiset on helppo antaa anteeksi, kunnes niistä tulee infrastruktuuria.
Politiikan ajautuminen tapahtuu, kun kirjattu sääntö muuttuu mutta tuotannon reitti ei, tai kun tuotannon reitti muuttuu mutta kirjattu sääntö ei. Varjotyökalut ilmestyvät, kun tiimit kiertävät hitaita kontrolleja epävirallisilla integraatioilla. Ylikantaminen tapahtuu, kun tukikäyttöön hyväksytty järjestelmä alkaa huomaamattomasti vaikuttaa täytäntöönpanoon, hinnoitteluun tai pääsyyn. Puuttuva valitusoikeus tapahtuu, kun käyttäjä voi saada tekoälyn muovaaman lopputuloksen, mutta ei voi haastaa sitä tavalla, joka päätyy rekisteriin. Budjettisilmukat ilmestyvät, kun agentit tai eräajot jatkavat kuluttamista hyödyllisen työn päätyttyä. Vanhentunut suostumus tapahtuu, kun vanhoja lupia kohdellaan tuoreina, koska kukaan ei ole tehnyt suostumuksesta osaa pyyntöpolkua.
Hyödyllinen vastaus ei ole paniikki. Se on instrumentointi. Nimeä vikatila. Lisää suoja, jos se voidaan estää. Lisää hälytys, jos se voidaan havaita. Lisää omistaja, jos se voidaan korjata. Lisää kirjaus, jos se on auditoitava. Jotkut viat vaativat politiikan muutosta. Jotkut vaativat rajapinnan muutosta. Jotkut vaativat datakontakteja. Jotkut vaativat hankintakuria. Tuotannon hallinta auttaa, koska se antaa organisaatiolle paikan, johon korjaus kiinnitetään.
Se paljastaa myös epämiellyttäviä totuuksia. Portti voi osoittaa, että suositulta käyttötapaukselta puuttuu oikeusperusta. Suostumuksen tarkistus voi osoittaa, että dataputki ei ole niin siisti kuin diaesitys väittää. Budjettiraja voi osoittaa, että liiketoimintaperuste toimii vain, jos arviointi on aliresursoitu. Valitusrekisteri voi osoittaa, että epäreilut lopputulokset luo politiikka, ei malli. Hyvä hallinnan todistusaineisto on epäkohteliasta. Se on yksi sen parhaista ominaisuuksista.
Ihmisen hallinta on pidettävä mukana
Tuotannon hallinta ei ole suunnitelma ihmisten poistamiseksi hallinnasta. Päinvastoin. Se antaa ihmisille parempia paikkoja puuttua asiaan. Hallitus ei voi arvioida jokaista pyyntöä. Politiikan omistaja ei voi hyväksyä jokaista työkalukutsua. Lakimies ei voi istua jokaisen hakupäätöksen sisällä. Arvioija ei voi tarkastaa jokaista matalan riskin luonnosta. Järjestelmän on hoidettava tavalliset tarkistukset. Ihmisten on omistettava säännöt, poikkeukset, kiistetyt tapaukset, tulkinta ja korjaus.
Avain on eskalaation suunnittelu. Milloin järjestelmän pitäisi pysähtyä ja kysyä. Milloin sen pitäisi kieltäytyä kysymättä. Milloin sen pitäisi sallia ja kirjata. Milloin sen pitäisi poimia otos myöhempää tarkastelua varten. Milloin toistuvista matalan riskin signaaleista pitäisi tulla korkean riskin malli. Milloin käyttäjän valituksen pitäisi avata suljettu tila uudelleen. Nämä ovat hallinnan valintoja. Niitä ei pitäisi piilottaa kehotteisiin, jonojen oletuksiin tai päivystäjän sankarilliseen harkintaan.
Runtime-aineisto parantaa ihmisten tekemää hallintaa, koska se antaa komiteoille jotain parempaa kuin anekdootit. Hallintoryhmä näkee, kuinka usein portit estivät toimintoja, missä poikkeukset kasautuivat, mitkä valitukset menivät läpi, mitkä toimittajat aiheuttivat kitkaa, mitkä käytännöt hidastivat työtä ja mitkä mallireitit aiheuttivat häiriöitä. Sitten kokous käsittelee aineistoa. Se voi silti olla pitkä. Meidän ei pidä luvata ihmeitä. Mutta sillä on ainakin mahdollisuus olla hyödyllinen.
Ihmiset ovat myös edelleen välttämättömiä, koska käytännöt ovat joskus ristiriidassa todellisuuden kanssa. Sääntö voi olla juridisesti oikea ja toiminnallisesti julma. Tietolähde voi olla sallittu ja silti sosiaalisesti riskialtis. Malli voi toimia hyvin keskimäärin ja epäonnistua haavoittuvassa reunatapauksessa. Budjettiraja voi säästää rahaa ja aiheuttaa epäoikeudenmukaista viivästystä. Runtime-järjestelmät voivat tuoda nämä ristiriidat esiin. Ihmisten on päätettävä, mitä ne tarkoittavat.
Runtime-hallinta muuttaa hankintaa
Tehokkaan mallin ostaminen ilman runtime-hallinnan tukea on tulevaisuuden epävarmuuden ostamista. Toimittajalla voi olla erinomaisia malleja, miellyttäviä demoja, sertifikaatteja ja varmoja kalvoja. Käytännön kysymykset ovat vähemmän hohdokkaita. Voiko järjestelmä paljastaa käytäntöpäätökset pyyntökohtaisesti. Voidaanko malli- ja kehoteversiot lukita. Voidaanko tietojen sijainti pakottaa dynaamisesti. Voidaanko työkalukutsut rajata ja tallentaa. Voidaanko lokit erotella tarkoituksen mukaan. Voidaanko aineisto viedä käyttökelpoisessa muodossa. Voiko organisaatio lähteä omien tietojensa kanssa. Voidaanko tapaus toistaa, kun toimittaja on muuttanut alustaansa.
Nämä kysymykset eivät ole vihamielisiä toimittajia kohtaan. Ne ovat aikuismaisia. Toimittaja, joka tukee runtime-hallintaa, auttaa ostajaa toimimaan vastuullisesti. Toimittaja, joka ei pysty siihen, voi silti olla hyödyllinen vähäriskisiin tehtäviin, mutta ostajan on tiedettävä raja. Pahin lopputulos on teeskennellä, että yleinen ominaisuus sopii merkittävään työhön vain siksi, että demo ei sisältänyt hallintaongelmaa. Demot eivät harvoin sisällä niitä. Siksi ne sopivat huoneisiin, joissa on naposteltavaa.
Hankinnassa pitäisi kysyä myös epäonnistumisesta. Mitä tapahtuu, kun käytäntöportti ei ole käytettävissä. Sulkeutuuko järjestelmä turvallisesti, avautuuko se vai ohjaako se tarkasteluun. Mitä tapahtuu, kun malli poistetaan käytöstä. Mitä tapahtuu, kun alue muuttuu saavuttamattomaksi. Mitä tapahtuu, kun auditointivientiä pyydetään. Mitä tapahtuu, kun käyttäjä pyytää poistoa. Mitä tapahtuu, kun lokit sisältävät arkaluonteisia tietoja. Vastaus hallintaan on usein piilotettu epäonnistumistapaan.
Runtime-hallinta ei edellytä, että jokainen toimittaja paljastaa kaikki sisäiset menetelmänsä. Se edellyttää, että palvelurajapinta on vastuullinen. Ostaja tarvitsee riittävästi hallintaa ja aineistoa täyttääkseen omat velvollisuutensa. Jos musta laatikko voi turvallisesti sijaita hallitun rajapinnan takana, hyvä niin. Jos itse rajapinta on musta laatikko, ostaja on ulkoistanut paitsi kyvykkyyden myös osan kyvystään vastata työstä.
Hallinta toimintasilmukkana
Kypsä malli on toimintasilmukka. Havaitse, mitä tapahtuu. Arvioi konteksti. Portita toiminto. Toimi rajojen sisällä. Arvioi tulokset. Päivitä käytännöt, tiedot, mallit ja rajapinnat. Tämä silmukka toimii eri nopeuksilla. Jotkin tarkistukset tapahtuvat pyyntökohtaisesti. Jotkin päivittäin. Jotkin julkaisun jälkeen. Jotkin neljännesvuosittain. Jotkin häiriöiden jälkeen. Tärkeää on, että silmukat ovat yhteydessä toisiinsa. Valituksen pitäisi tavoittaa arviointi. Valituksen pitäisi tavoittaa käytäntö. Käytäntömuutoksen pitäisi tavoittaa portit. Mallipäivityksen pitäisi tavoittaa testit. Toimittajahäiriön pitäisi tavoittaa reititys.
Näin hallinnasta tulee vähemmän teatraalista. Se lakkaa olemasta joukko seremonioita järjestelmän ympärillä ja siitä tulee järjestelmän toiminnan ominaisuus. Organisaatiolla voi edelleen olla komiteoita, rekistereitä, käytäntöjä ja raportteja. Niin pitääkin olla. Mutta nämä artefaktit ovat nyt yhteydessä elävään aineistoon. Hallintakokous voi kysyä, mitä järjestelmä teki, ei vain sitä, mitä järjestelmä väittää olevansa.
Toimintasilmukka tekee hallinnosta myös mukautuvampaa. AI-järjestelmät muuttuvat. Lait muuttuvat. Data muuttuu. Käyttäjien käyttäytyminen muuttuu. Mallit muuttuvat. Toimittajien ehdot muuttuvat. Staattinen hyväksyntä ei voi kantaa kaikkea tätä. Ajonaikainen hallinto ei ratkaise epävarmuutta jäädyttämällä maailmaa. Se antaa organisaatiolle keinon havaita, päättää ja päivittää menettämättä vastuuta aiemmista valinnoista.
Silmukalla on oltava muisti. Muuten mukautumisesta tulee hiljaista uudelleenkirjoittamista. Kun sääntö muuttuu, vanhat tapaukset tarvitsevat edelleen vanhan kontekstinsa. Kun mallireitti poistetaan käytöstä, aiemmat päätökset tarvitsevat edelleen selityksen. Kun lähde poistetaan, johdetut tulosteet tarvitsevat edelleen alkuperäketjunsa. Ajonaikaisen hallinnon tulisi tukea muutosta pyyhkimättä pois aiempia syitä. Tämä on tylsä lause, jolla on suuria seurauksia.
Opetus
Hallinnosta tulee ajonaikainen ongelma, kun AI-järjestelmät liikkuvat nopeammin, laajemmin ja kontekstuaalisemmin kuin hallitustason artefaktit pystyvät yksin hallitsemaan. Vastaus ei ole hylätä hallintoasiakirjoja tai korvata ihmisen harkintaa koodilla. Vastaus on yhdistää asiakirjat, roolit, politiikat, portit, tallenteet ja tarkistussilmukat niin, että hallinto voi toimia työn ollessa käynnissä.
Ajonaikainen hallinto tarkistaa identiteetin, tarkoituksen, datan, sijainnin, mallireitin, työkalun valtuudet, budjetin, ihmisen tarkistuksen, todisteaineiston, valituksen ja säilytyksen reaaliaikaisessa polussa. Se kohtelee politiikkoja elävinä riippuvuuksina. Se reitittää tarkoituksella oikeudellisten ja toiminnallisten rajojen yli. Se tallentaa, mikä sääntö sovellettiin. Se nimeää vikatilat ennen kuin niistä tulee tapoja. Se antaa ihmisille todisteita anekdoottien sijaan.
Tämä on vähemmän romanttinen näkemys hallinnosta ja hyödyllisempi sellainen. Vakava kysymys ei ole se, onko organisaatiolla AI-hallintokehys. Vakava kysymys on se, mitä tapahtuu tiistaina kello 09.14, kun oikea pyyntö pyytää järjestelmää liikkumaan. Jos vastaus on tarkistettu, rajattu, tallennettu ja tarkistettavissa, hallinto toimii. Jos vastaus on, että politiikka on kansiossa, hallinto odottaa edelleen toimistoaikoja.