Dnevnik ni dokaz
Neprijeten del po nadzorni plošči
Prvi revizijski sestanek se običajno začne s samozavestjo. Ekipa ima nadzorne plošče. Ekipa ima beleženje. Ekipa ima politiko hrambe, integracijo SIEM, nekaj posnetkov zaslona in nekoga, ki ve, kje v oblaku se skriva gumb za izvoz. Vsi so naredili običajne stvari. Prav zato sestanek postane neprijeten.
Revizor ne vpraša, ali obstajajo dnevniki. Seveda obstajajo. Vsak sodoben sistem jih piše na kilograme. Vprašanje je, ali lahko zapis odgovori na določeno revizijsko vprašanje, ne da bi ekipa zgodbo ročno obnovila. Kdo je odobril klic orodja? Katera različica poteka dela se je izvedla? Katera podatkovna pravica je bila uveljavljena? Kdaj je incident z umetno inteligenco postal znan? Kaj točno je bilo izdano? Ali je verigo mogoče preveriti, potem ko se je sistem premaknil, ko je bila datoteka rotirana, ko je bila prvotna storitev zamenjana?
Tu začne običajno beleženje pešati. Vrstica dnevnika je uporaben operativni znak. Razvijalcu pove, od kod prihaja dim. Ni samodejno dokaz. Lahko je prosto besedilo. Lahko jo premeščajo ure, medpomnjenje, delavci, ponovni poskusi in rotacija datotek. Lahko ima nedosledna polja, ker je ena ekipa pisala strukturiran JSON, druga pa kar se ji je zdelo koristno ob 23:41. Nizozemska posebnost, mimogrede: napiši čudovit procesni dokument, potem pa shrani edino uporabno dejstvo v sporočilo dnevnika z imenom misc. Zelo učinkovito, če je cilj kasnejše obžalovanje.
Ledger obstaja za točko, kjer obžalovanje postane drago. Je tok dogodkov, ki se le dodaja, s tipiziranimi dogodki, združenimi v seje, povezanimi z zgoščenimi vrednostmi, shranjenimi prek pomnilniških zaledij in predvajljivimi kot sistemska zgodovina. Ne poskuša nadomestiti vsake podatkovne zbirke. Ne poskuša biti AION. Ni dokaz zaključka znotraj ene same odločitve. Je zapečaten operativni zapis tega, kar se je dogajalo okoli sistema.
Razlika se sliši majhna, dokler ne pride prva resna revizija. Dnevniki od revizorja zahtevajo, da verjame, da je niz vrstic dovolj popoln, dovolj urejen in dovolj nespremenjen. Ledger spremeni obliko odgovora. Pravi: tukaj je dogodek, tukaj je prejšnja zgoščena vrednost, tukaj je seja, tukaj je tipizirana vsebina, tukaj je, kako se sprehoditi po verigi. Manj gledališča. Več objekta.
Revizijsko vprašanje ima obliko
Dobra revizijska vprašanja so nadležno konkretna. Ne navduši jih dejstvo, da je bil sistem zapleten. Ne zanima jih, da je imela uvedba deset storitev in sporočilno vodilo z mnenji. Zahtevajo točko v času, odgovorno dejanje, zapis in način, kako preveriti, da zapis še vedno pomeni to, kar je pomenil, ko je bil napisan.
Zato Ledger začne s tipiziranimi dogodki. Klic orodja ni le niz, ki vsebuje klicano orodje. Rezultat orodja ni le stavek. Odobritev ni skomigni z rameni v karti. Privolitev, dejavnost DPIA, pravice posameznika, zahteve za izbris, incidenti z umetno inteligenco, ustvarjanje SBOM, potrdila, artefakti, seje, kontrolne točke, rezultati predvajanja: vse to sodi v oblike dogodkov. Spletno mesto opisuje devet kategorij in triindvajset različic; lokalna shema dogodkov podpira to strukturo. Točno število je manj pomembno kot oblikovalska navada za njim. Revizijsko vprašanje bi moralo pristati na tipu, ne na odstavku.
Tipkanje ni birokracija sama sebi namen. Prav to preprečuje, da bi vsaka preiskava postala manjši arheološki projekt. Če ima dogodek kategorijo, vsebino, časovni žig, sejo, nadrejeno relacijo, kjer je potrebna, metapodatke, zgoščeno vrednost vsebine, prejšnjo zgoščeno vrednost, neobvezen podpis in metapodatke o skladnosti, ima pregledovalec zapis, ki ga lahko preuči. Če je dogodek oblikovan niz, ima pregledovalec le občutek.
To ni vojna proti dnevnikom. Dnevniki ostajajo uporabni za delujoče sisteme. So inženirjev periferni vid. Ledger je namenjen trenutkom, ko periferni vid ni dovolj. Pregled sprašuje, ali je bila zgodovina ohranjena, ali je zapis mogoče predvajati, ali je stanje mogoče obnoviti in ali se tihe spremembe pokažejo. Ta vprašanja zahtevajo strukturo, ki je bila zasnovana pred incidentom, ne pa sestavljena po njem.
Dodajanje na konec je obljuba, ki jo lahko preizkusite
Dodajanje na konec zveni kot preprosta obljuba. Zapiši enkrat. Dodaj na konec. Ne prepisuj zgodovine. V praksi je ta obljuba pomembna le, če lahko zapis razkrije posege, okrnitev, manjkajoče povezave in prekinjeno kontinuiteto. Besedilno datoteko lahko v politiki imenujemo dodajanje na konec, a če vrstica izgine in se nihče ne pritoži, je bila politika večinoma le notranja dekoracija.
Ledger modelira celovitost na ravni dogodka. Vsak dogodek ima vsebino, ki prispeva k zgoščeni vrednosti vsebine. Dogodek kaže tudi na prejšnjo zgoščeno vrednost verige. Vzdrževanje shrambe lahko preverja kontinuiteto. Predvajanje lahko prehodi dogodke po vrstnem redu. Zaupne točke lahko zapečatijo segmente. Pomembna zamisel je, da celovitost ni prenesena na ozadnjo shrambo, ki reče, da je bil zapis uspešen. Dogodek sam nosi povezavo, ki omogoča preverjanje verige.
Cevec je namerno običajen: dodajanje, zgoščevanje, sidranje, trajno shranjevanje, predvajanje. Običajnost je tu dobra. Revizijska infrastruktura ne sme biti odvisna od junaških dejanj. Če sistem vsakič, ko pregledovalec postavi osnovno vprašanje, potrebuje pogumnega inženirja s preglednico, sistem ni bil narejen odgovoren. Le zaposlil je nekoga potrpežljivega.
Izvorno gradivo je tudi uporabna točka za uvajanje. Ledger je lahko blizu sistema: kot vgrajen API v Rustu, C ABI, stranski proces ali storitvena površina. To je pomembno, ker izvor, zapisan daleč stran, pogosto prispe pozno, izgubi kontekst ali je filtriran skozi udobje tistega, kar opravlja prenos. Bližje ko je dogodek tistemu, kar se je zgodilo, manj interpretativnih vaj je potrebnih pozneje.
Ledger ni AION, in to je dobro
Pogosta napaka pri upravljanju umetne inteligence je uporaba ene besede za pet različnih vrst dokazov. Vse postane sledljivost, izvor, razložljivost ali preglednost. Besede postanejo topla juha. Vsi prikimavajo, nihče ne more ničesar predvajati, nato pa regulator postavi konkretno vprašanje. To ni strategija. To je megla z računi.
Ledger in AION odgovarjata na različna vprašanja. Ledger beleži, kaj se je zgodilo v sistemu: klici orodij, rezultati, odobritve, artefakti, seje, dogodki skladnosti, incidenti, potrdila. AION potrjuje korake sklepanja znotraj odločitve: ali je ob danih premisah in pravilih ta sklep sledil skozi zabeležen dokaz? Sled nato nosi operativne grafe, vrata politik, zgoščene vrednosti, korene in poti predvajanja za izračun. Selvedge beleži prepise izvajanja v peskovniku. Lattice vrednoti vrata politik. To so sosedje, ne sopomenke.
Ta ločitev ni pedanterija. Preprečuje ekipam, da bi si pripisovale preveč zaslug. Zelo dober zapis v Ledger lahko pokaže, da je bil model poklican, da je bilo odobreno dovoljenje, da je bil ustvarjen izdelek in da je bil zabeležen incident. Sam po sebi pa ne dokazuje, da je sledil logičen sklep. To je področje AION. Dobro potrdilo AION lahko dokaže pot sklepanja, vendar samo po sebi ne zabeleži vseh okoliških operativnih dogodkov v poteku dela. To je področje Ledger.
Ko so meje jasne, je sklad lažje zagovarjati. Operativna časovnica živi v Ledger. Dokaz odločitve živi v AION. Sled izračunov živi v Trace. Odločitev o politiki je mogoče ponovno ovrednotiti prek Lattice. Izvajanje v peskovniku je mogoče ponovno predvajati prek Selvedge. Pregledovalec lahko zastavi natančno vprašanje in prejme pravo vrsto predmeta, ne pa brošure o preglednosti.
Shranjevanje ne sme spremeniti pomena
Eden najlažjih načinov, kako uničiti revizijsko sled, je, da izbira shranjevanja spremeni pomen zapisa. Pomnilniški vmesnik za teste, datoteka JSONL za prenosljivost, lokalna podatkovna zbirka za vgrajeno delo, strežniška podatkovna zbirka za indeksirano produkcijsko uporabo, arhivski predal za dolgotrajno hrambo: to so odločitve o namestitvi. Ne bi smele ustvariti petih različnih resnic.
Vir in spletišče Ledger poudarjata vtičniško shranjevanje in stabilen model dogodkov. Natančen seznam vmesnikov ima nekaj razhajanj med viri, zato je javna lekcija preprostejša in močnejša: shranjevanje je raven, ne shema. Oblika zapisa mora preživeti selitev. Migracija ne sme dogodka spremeniti v novo interpretacijo njega samega. Če organizacija spremeni način namestitve, mora veriga ostati veriga.
To se sliši očitno, dokler ne vidite, kako resnični sistemi pri tem odpovejo. Ekipa v razvoju beleži vsa polja, v produkciji polja odstrani zaradi stroškov, v analitiko izvozi drugačno obliko, v podatkovno jezero shrani podmnožico in nato upa, da bo poznejši pregled sprejel sestavljanko. To ni veriga. To je album. Včasih uporaben album, a še vedno album.
Praktična vrednost Ledger je v tem, da ekipam daje enotno obliko dogodka, okoli katere lahko načrtujejo. Plast shranjevanja je mogoče izbrati glede na obseg, stroške, hrambo, zmogljivost poizvedovanja ali izolacijo. Predmet pregleda ostaja tok dogodkov. Revizorju ni treba spoznati osebnosti vsakega vmesnika, preden lahko vpraša, ali je bila zgodovina ohranjena.
Kaj pregled sprašuje
Trenutek pregleda je vedno manj abstrakten, kot namigujejo arhitekturne sheme. Nekdo vpraša, kdo je odobril dejanje. Nekdo vpraša, ali je obstajala privolitev. Nekdo vpraša, kdaj je organizacija izvedela za incident z umetno inteligenco. Nekdo vpraša, kakšen seznam programskih komponent ali potrdilo je obstajal, ko je bil izdelek izdan. Če ta dejstva še niso zapisi, jih ekipa začne rekonstruirati iz vstopnic, klepetov, dnevnikov uvajanja, e-pošte in upanja. Upanje ni podatkovni model. Škoda, ker ima odlično sprejetost.
Tu se taksonomija dogodkov Ledger obnese. ApprovalRequested, ApprovalGranted, ApprovalDenied. ConsentRecorded. DataSubjectRightExercised. DpiaCompleted. RightToErasureRequested. AiIncidentDetected. SbomGenerated. AttestationCompleted. Ta imena niso glamurozna. Dobro. Glamurozni del skladnosti je običajno tam, kjer se začnejo težave. Uporabni del je dolgočasen zapis, ki obstaja, preden je kdo zaskrbljen.
Za sisteme umetne inteligence je to pomembno, ker so okoliška operativna dejstva pogosto prav tako pomembna kot izhod modela. Odločitev je lahko tehnično pravilna, a še vedno operativno neobranljiva, če je tekla napačna različica, je bil uporabljen napačen obseg podatkov, je bila obidena napačna pot odobritve ali pa je bil zapis o incidentu ustvarjen tri dni potem, ko so vsi že vedeli. Model ni celoten sistem. Zelo nadležno za častilce modelov, zelo uporabno za odrasle.
Tipizirani dogodki tudi zmanjšujejo izmuzljivost odgovornosti. Revizijsko vprašanje lahko pokaže na dogodek, ki bi moral obstajati. Če obstaja, ga preglejte. Če ne obstaja, je ta odsotnost sama po sebi dejstvo. To je bolje kot se pretvarjati, da je odgovor nekje v dnevnikih, če bi le imel nekdo dovolj vzdržljivosti za regularne izraze.
Predvajanje je tam, kjer zapis postane uporaben
Zapis, ki ga ni mogoče predvajati, je pogosto le pripomoček za spomin. Lahko pomaga ljudem razložiti, kaj se je verjetno zgodilo. Predvajanje to spremeni. Ekipi omogoča, da hodi skozi urejene dogodke in obnovi stanje v določeni točki v času. To se razlikuje od branja časovnice. Bolj je podobno temu, da sistem zgodovine prosimo, naj izračuna svojo lastno preteklost.
Knjiga dogodkov združuje dogodke v seje. Seja lahko predstavlja pogovor, potek dela, zagon ali obdobje izvajanja. Dogodke je mogoče poizvedovati skupaj in jih predvajati skupaj. Kontrolne točke naredijo dolge zgodovine manj boleče. Preverjanja celovitosti naredijo prekinjene verige vidne. To je pomembno, ker pravi incidenti redko so posamezni dogodki. So zaporedja. Vrstni red, kontekst in nadrejene povezave postanejo del odgovora.
Predvajanje spremeni tudi ekonomiko dokazov. Brez predvajanja vsako resno vprašanje postane ročno delo. S predvajanjem lahko organizacija vzorči zapise, preizkuša kontinuiteto, pregleduje seje in obnavlja stanje kot del običajnega delovanja. To ne odstrani presoje. Odstrani kategorijo izogibnega kaosa.
Najboljša različica tega je tiha. Nihče ne praznuje, ker je bilo revizijsko vprašanje odgovorjeno iz zapisa. Moral bi se zdeti normalen. Dogodek je bil zapisan, ko se je dejanje zgodilo. Veriga se še vedno preverja. Seja se obnovi. Stanje na izbrani točki je vidno. To je programski ekvivalent shranjevanja računov, le da se račun lahko pritoži, če mu nekdo izreže kos.
Zakaj to sodi blizu dela z umetno inteligenco
Delo z umetno inteligenco ima navado proizvajati impresivne odgovore in šibek operativni spomin. Ekipe si zapomnijo predstavitev, poziv, ime modela, morda posnetek zaslona, morda nit v Slacku, kjer je nekdo rekel objavi. Nato sistem vstopi v produkcijo in začne sprejemati odločitve, klicati orodja, uporabljati podatke, premikati artefakte, zahtevati odobritve in ustvarjati izjeme. Na tej točki izhod ni več edina zgodba.
Agentski sistemi to še poudarijo. Agent ne le odgovarja. Zaznava, pridobiva, razmišlja, deluje in predaja delo drugim sistemom. Vsak klic orodja in rezultat sta lahko pomembna. Vsaka odobritev je lahko pomembna. Vsak artefakt je lahko pomemben. Vsaka vrata pravilnika so lahko pomembna. Če je edini trajen zapis mešan kup dnevnikov, je organizacija zgradila zaposlen sistem s slabim spominom.
Knjiga dogodkov da temu spominu obliko. Sama po sebi ne naredi agenta varnega. Ne blagoslovi slabega poteka dela. Ne dokaže matematičnega zaključka. Zabeleži operativno sled na način, ki ga je mogoče preveriti in predvajati. To je že resen korak naprej od posnetkov zaslona, izvozov konzole in svete preglednice retrospektivne resnice.
To izboljša tudi inženirsko vedenje. Ko so dogodki tipizirani, se morajo ekipe odločiti, kaj je pomembno. Ko so dogodki povezani z zgoščevalnimi verigami, morajo ekipe obravnavati zgodovino kot verigo. Ko so dogodki predvajljivi, lahko ekipe preizkusijo, ali njihova operativna zgodba dejansko omogoča obnovo. Odgovornost preneha biti odstavek v razdelku o tveganjih in postane del pogodbe o izvajanju.
Nauk
Nauk ni v tem, da so dnevniki slabi. Dnevniki so uporabni. Ljudem pomagajo upravljati sisteme, diagnosticirati napake, razumeti delovanje in razbremeniti razvijalce, da jim ni treba ugibati o vedenju produkcije iz občutkov. Toda dnevniki sami po sebi niso dokazi. Vrstica besedila ne postane zaupanja vredna samo zato, ker jo je zapisal strežnik z resnim imenom.
Dokazi potrebujejo strukturo. Potrebujejo kontinuiteto. Potrebujejo lastništvo. Potrebujejo način za odkrivanje sprememb in vrzeli. Preživeti morajo selitve shrambe, spremembe uvajanja, spremembe dobaviteljev in zelo človeško željo po urejanju zgodovine pred pregledom. Ledger je odprt operativni zapis za to nalogo: tipizirani dogodki, zgoščevalne verige, seje, predvajanje, preverjanja celovitosti in površine uvajanja, ki so dovolj blizu sistemu, da so uporabne.
V dejstvu, da je prihodnost odgovorne umetne inteligence odvisna od boljšega beleženja dolgočasnih dogodkov, je suhoparna komedija. Toda tako delujejo resni sistemi. Impozanten odgovor pritegne pozornost. Zapis odloča o tem, ali naj kdo sistemu še verjame šest mesecev pozneje.
Zato obdržite dnevnike. Berite jih, iščite po njih, rišite grafe iz njih, preklinjajte jih, ko se spremeni oblika časovnega žiga. Le ne zamenjujte jih z dokazi. Dokazi so zapis, skozi katerega se lahko vrnete nazaj, veriga, ki se pritoži, ko je prekinjena, in stanje, ki ga lahko obnovite, ko v prostoru nastane tišina in nekdo vpraša, kaj se je v resnici zgodilo.