Auditabilitatea nu ar trebui adăugată ulterior.
Folderul care a sosit prea târziu
Sala de ședințe avea semnele obișnuite ale seriozității instituționale: pereți de sticlă, o mașină de cafea care încerca să pară un vas sub presiune și un folder numit evidence pack pe ecranul partajat. Sistemul aflat în analiză era activ de nouă luni. Ruta cazurile interne, recomanda următorii pași, escalada unele dintre ele către specialiști și le respingea pe altele în liniște, pentru că pragurile configurate așa cereau. Nimeni din sală nu l-a descris ca fiind un sistem cu risc ridicat în timpul achiziției. Era un instrument de productivitate, adică ceea ce organizațiile numesc infrastructură de decizie înainte ca cineva să întrebe cine a fost afectat.
Auditorul a pus o întrebare mică. Pentru acest caz, ce versiune de politică era activă când a fost produsă recomandarea. Product owner-ul s-a uitat la arhitect. Arhitectul s-a uitat la data lead. Data lead-ul a deschis un dashboard, apoi un export de loguri, apoi un tichet. Un dezvoltator și-a amintit că versiunile de politică fuseseră stocate într-o variabilă de mediu la prima lansare și într-un tabel de bază de date după migrarea din ianuarie. Cineva a spus că schimbarea era probabil inofensivă. Aceasta este rareori fraza care îl relaxează pe un auditor.
Nimic nu fusese construit cu intenții rele. Echipa avea loguri, monitorizare, control al accesului, backup-uri, tichete de incident și un wiki intern cu suficiente pagini cât să strice o imprimantă. Dar dovezile nu erau o proprietate a sistemului. Erau un exercițiu de reconstrucție făcut după fapt, de oameni care încă își aminteau implementarea. Asta nu este auditabilitate. Asta este istorie orală cu timestamp-uri.
Auditabilitatea nu ar trebui adăugată mai târziu, pentru că mai târziu este exact momentul în care memoria a devenit politică. Oamenii sunt nervoși. Sistemul s-a schimbat. Furnizorii au fost înlocuiți. Dashboard-urile au fost reproiectate. Singurul inginer care înțelegea importul original de date are acum un alt titlu de post și vorbește despre acea perioadă cu calmul cuiva care a supraviețuit unui incident de instalații sanitare. Dacă înregistrarea nu a fost creată când s-a întâmplat munca, povestea ulterioară va conține întotdeauna mai multă interpretare decât dovezi.
Auditabilitatea este o proprietate de design
Multe echipe tratează auditabilitatea ca pe documentație. O imaginează ca pe un set de diagrame, controale, aprobări, butoane de export și declarații de politică ce pot fi asamblate odată ce sistemul este aproape de lansare. Această viziune este tentantă pentru că documentația pare mai ieftină decât designul. Lasă proiectul să meargă mai departe în timp ce guvernanța așteaptă politicos în coridor cu o clipboard. Factura ajunge mai târziu, cu dobândă.
Auditabilitatea este mai aproape de durabilitate decât de documentație. Un sistem durabil nu devine durabil pentru că cineva scrie un raport care spune că acoperișul ar rezista probabil la ploaie. Acoperișul fie îndepărtează apa, fie nu. Un sistem auditabil fie păstrează faptele necesare pentru a-i inspecta comportamentul, fie nu. Faptele pot fi plictisitoare: versiune, sursă, marcaj temporal, actor, regulă, prag, excepție, aprobare, identificator de model, șablon de prompt, domeniu de date, stare de retenție. Plictisitor este în regulă. Un pod este și el susținut de piese plictisitoare. Lămpile decorative nu fac parte din calea de încărcare.
Partea dificilă este că faptele de audit trebuie capturate la același nivel la care se iau deciziile. Dacă un flux de lucru folosește o regulă de politică, versiunea regulii aparține evenimentului. Dacă un rezultat al modelului este acceptat într-un dosar de caz, versiunea modelului, încrederea, domeniul sursei și regula de acceptare aparțin înregistrării. Dacă un om anulează o recomandare, motivul anulării aparține lângă acțiune, nu într-o notă de întâlnire două săptămâni mai târziu. Sistemul nu ar trebui să ceară unui istoric să deducă ceea ce mașina știa deja la momentul execuției.
De aceea auditabilitatea nu este același lucru cu logarea. Jurnalele sunt utile, dar loialitatea lor principală este de obicei operațiunile. Ele explică eșecuri, sincronizări, reîncercări, excepții și performanță. Auditabilitatea pune un set diferit de întrebări: ce autoritate a fost folosită, ce dovezi au fost luate în considerare, ce stare s-a schimbat, cine sau ce a cauzat-o și poate fi verificată secvența fără a avea încredere în serviciul curent. Jurnalele pot sprijini această activitate. Rareori o susțin singure.
Prima decizie este ce contează
Înainte ca un sistem să poată fi auditabil, organizația trebuie să decidă ce contează ca eveniment auditabil. Sună administrativ, dar aici începe arhitectura reală. Dacă fiecare clic este un eveniment, înregistrarea devine o groapă de gunoi. Dacă doar rezultatele finale sunt evenimente, înregistrarea devine un truc de magie. Mijlocul util este să captezi momentele în care autoritatea, dovezile sau starea își schimbă mâinile.
O primire de caz este un astfel de moment. Un document sursă care intră în domeniu este altul. O recomandare a modelului este unul dacă poate influența munca. O declanșare a unei porți de politică este unul. O aprobare umană este unul. Un refuz, o escaladare, o excepție, o corecție de date, o schimbare de retenție, o cerere de ștergere și un apel sunt toate candidați. Scopul nu este să păstrezi fiecare respirație a sistemului. Scopul este să păstrezi îmbinările unde un recenzent ulterior ar întreba în mod rezonabil: de ce s-a mutat sistemul de aici acolo.
Această selecție trebuie să fie explicită. Altfel, echipa descoperă în timpul revizuirii că evenimentul important a trăit în umbra dintre două componente. Front-end-ul știe că utilizatorul a văzut un avertisment. Back-end-ul știe că dosarul a schimbat starea. Serviciul de model știe că a returnat un scor. Motorul de flux de lucru știe că a fost luată o ramură. Nicio înregistrare unică nu spune că avertismentul, scorul, regula și ramura au aparținut aceleiași decizii. Toată lumea are o bucată din vază. Masa este încă udă.
Odată ce setul de evenimente este numit, inginerii pot proiecta contracte în jurul lui. Fiecare eveniment poate avea câmpuri obligatorii. Fiecare câmp poate avea un proprietar. Fiecare schimbare de schemă poate fi versionată. Fiecare regulă de retenție poate fi legată de nevoia legală și operațională. Aceasta nu este birocrație care stă lângă sistem. Este parte din granița sistemului. Înregistrarea devine un produs al fluxului de lucru, nu o scuză scrisă de fluxul de lucru după prânz.
Timpul nu este o decorațiune
Munca de audit este obsedată de timp pe bună dreptate. O decizie luată înainte de o schimbare de politică nu este aceeași cu o decizie luată după ea. O ieșire de model produsă înainte de o corecție de date nu este aceeași cu una produsă după ea. Un caz escaladat după un termen limită este diferit de un caz escaladat înaintea unuia. Timpul nu este metadate presărate peste evenimente. Face parte din semnificația evenimentului.
Sistemele distribuite fac timpul incomod. Ceasurile deviază. Cozile reordonează. Reîncercările au loc. Lucrătorii procesează mesajele cu întârziere. Loturile sunt încărcate peste noapte de joburi care au fost numite temporare în 2021 și acum sunt permanent cultural. Dacă designul de audit presupune o singură cronologie ordonată, primul incident îl va educa. Acea educație are loc de obicei într-o foaie de calcul, care este o sală de clasă scumpă.
Un design auditabil distinge timpul evenimentului, timpul de procesare, timpul efectiv și timpul de revizuire acolo unde diferența contează. Timpul evenimentului spune când s-a întâmplat lucrul în procesul de afaceri. Timpul de procesare spune când l-a gestionat o componentă. Timpul efectiv spune când o regulă sau o stare a devenit validă. Timpul de revizuire spune când cineva l-a inspectat sau corectat mai târziu. Aceste distincții pot părea mofturoase până când un caz trece de miezul nopții, o regulă se schimbă la 09:00 și o coadă se golește încet pentru că cineva a redimensionat pool-ul de lucrători cu încredere și fără dovezi.
Aceeași grijă se aplică identității. Actorul poate fi o persoană, un serviciu, un agent, un job programat, un utilizator delegat sau un sistem extern. Sistemul ar trebui să spună care. Nu ar trebui să se ascundă în spatele adminului de utilizatori pentru că acolo locuiește contul de integrare. Când autoritatea este delegată, delegarea ar trebui să fie vizibilă. Când un serviciu acționează automat, serviciul deținător și regula ar trebui să fie vizibile. Auditabilitatea necesită responsabilitate numită, chiar și atunci când numele nu este o ființă umană.
Reconstrucția nu este redare
Când echipele adaugă auditabilitatea târziu, ele se mulțumesc adesea cu reconstrucția. Ele adună jurnale, instantanee de bază de date, tichete, mesaje de chat și note de lansare. Ele construiesc o cronologie plauzibilă. Uneori cronologia este corectă. Uneori este o ficțiune foarte ordonată cu autori sinceri. Problema nu este că oamenii mint. Problema este că reconstrucția cere oamenilor să umple golurile sub presiune, iar instituțiile sunt extrem de bune să facă golurile să pară intenționate odată ce o întâlnire de nivel superior a început.
Replay este un standard diferit. Replay înseamnă că sistemul a păstrat suficient istoric structurat pentru a putea parcurge din nou secvența. Nu înseamnă că modelul original trebuie apelat din nou sau că fiecare dependență externă poate fi readusă la viață. Înseamnă că înregistrarea poate arăta ce intrare a fost acceptată, ce versiune de regulă a fost declanșată, ce ieșire a fost produsă, ce acțiune a fost întreprinsă și ce stare a rezultat. Recenzorul ar trebui să poată inspecta lanțul fără să se bazeze pe aplicația curentă ca să spună o poveste flatantă despre sinele ei mai tânăr.
Replay schimbă comportamentul în inginerie. Dacă o echipă știe că deciziile pot fi redate, devine mai greu să ascunzi politici în căi de cod cu nume precum helper2. Devine mai greu să lași pragurile să derive fără să înregistrezi cine le-a schimbat. Devine mai greu să tratezi șabloanele de prompt ca obiecte meșteșugărești locale pe un laptop. Replay cere ca fiecare acțiune importantă să își poarte propriul context. Acest lucru este enervant în felul în care sunt enervante centurile de siguranță: mai ales înainte de accident.
Replay permite, de asemenea, ca guvernanța să devină o rutină. În loc să aștepte un incident, echipele pot eșantiona cazuri, pot inspecta lanțuri, pot compara rezultate între versiuni de politici și pot detecta înregistrări lipsă. Traseul de audit devine ceva ce organizația folosește, nu ceva pe care îl produce doar când este încolțită. Această diferență contează. Controalele care sunt exercitate doar în timpul fricii au obiceiul de a fi decorative.
Costul adăugării ulterioare
Auditabilitatea târzie are un miros foarte specific. Miroase a tabele noi cu nume precum audit_log_final. Miroase a export de date care are majoritatea coloanelor, dar nu și pe cele legate de întrebare. Miroase a consultant care întreabă dacă există o sursă de adevăr și primește un tur al cinci sisteme. Miroase, mai presus de toate, a inginerie inversă a intenției din efecte secundare.
Costul direct este timpul de inginerie. Echipele trebuie să identifice unde au avut loc deciziile, să adauge capturarea evenimentelor, să completeze înregistrările istorice, să corecteze lacunele, să documenteze ipotezele și să construiască suprafețe de export. Această muncă ajunge adesea când sistemul poartă deja utilizatori, incidente, cereri de funcționalități și așteptări. Costul indirect este mai rău: încrederea scade. Dacă organizația nu poate răspunde la întrebări de bază despre propriul sistem, fiecare răspuns ulterior este tratat cu suspiciune, chiar și cele corecte.
Există și un cost de design. Odată ce un sistem a fost construit fără auditabilitate, granițele sale s-ar putea să nu se alinieze cu nevoile de evidență. Decizia poate fi împărțită între componente. Starea poate fi suprascrisă în loc să fie adăugată. Motivele pot fi calculate pentru afișare, dar nu stocate. Intrările modelului pot fi transformate și aruncate. Intervențiile umane pot trăi în comentarii. Modernizarea auditabilității devine apoi mai puțin ca adăugarea unei ferestre și mai mult ca descoperirea că peretele este structural.
Costul nu este doar tehnic. Auditabilitatea întârziată creează dispute politice despre ce s-a întâmplat cu adevărat. Oamenii își apără echipele. Furnizorii își apără interfețele. Managerii își apără deciziile de lansare. Toată lumea devine un filosof amator al cauzalității. Acest lucru este de înțeles și în mare parte inutil. O evidență bună reduce nevoia de adevăr condus de personalitate. Permite instituției să dezbată politica și îmbunătățirile în loc să dezbată dacă trecutul există.
Evidențele bune nu sunt teatru de supraveghere
Există o teamă legitimă că auditabilitatea devine supraveghere. Unele organizații aud „înregistrați totul” și se comportă ca și cum fiecare ezitare umană merită un timestamp. Aceasta nu este auditabilitate. Aceasta este anxietate instituțională cu stocare atașată. Un design bun de audit este selectiv, proporționat și legat de schimbări cu consecințe. Înregistrează autoritatea și starea, nu zgomotul privat.
Pentru angajați, distincția contează. Un operator care aprobă o excepție ar trebui să se aștepte ca aprobarea să fie înregistrată. Nu ar trebui să se aștepte ca fiecare mișcare a cursorului să devină parte dintr-o piesă morală permanentă. Un specialist care anulează o recomandare a modelului ar trebui să lase un cod de motiv și o notă atunci când decizia afectează un caz. Nu ar trebui să fie pedepsit pentru că a fost în dezacord cu automatizarea care era oricum incertă. Auditabilitatea ar trebui să facă judecata profesională vizibilă, nu să facă profesioniștii timizi.
Pentru cetățeni, clienți, pacienți sau studenți, auditabilitatea ar trebui să sprijine drepturile. Ar trebui să facă posibil să explici o decizie, să corectezi date greșite, să contestezi un rezultat, să dovedești ștergerea sau să arăți că o sursă nu a fost folosită. O evidență care protejează doar instituția este incompletă. Traseul de audit nu ar trebui să fie o oglindă unilaterală. Dacă sistemul afectează oameni, evidența ar trebui să ajute să răspundă și la întrebările lor legitime.
Aici se întâlnesc minimizarea datelor și auditabilitatea. Răspunsul nu este să păstrezi totul pentru totdeauna. Răspunsul este să păstrezi faptele potrivite pentru perioada potrivită, cu scop clar, reguli de acces și logică de ștergere sau retenție. O evidență rară, bine structurată este adesea mai respectuoasă și mai utilă decât o grămadă uriașă de emisii captate. Grămada pare sigură până când cineva întreabă ce este în ea. Apoi devine o datorie cu căutare.
Registrul de riscuri ar trebui să comunice cu schema de evenimente
Registrele de riscuri trăiesc adesea în documente de guvernanță, în timp ce schemele de evenimente trăiesc în depozitele de inginerie. Această separare este convenabilă și periculoasă. Registrul de riscuri spune că există un risc de escaladare neautorizată. Schema de evenimente ar trebui, prin urmare, să înregistreze cine a escaladat, sub ce autoritate, din ce stare, în ce stare și dacă escaladarea a fost automată sau manuală. Dacă schema nu surprinde aceste fapte, controlul este aspirațional. Aspirațiile sunt mai ieftine decât controalele, ceea ce explică popularitatea lor.
Același lucru se aplică riscului modelului. Dacă registrul spune că recomandările cu încredere scăzută trebuie revizuite, sistemul ar trebui să înregistreze încrederea, pragul, cerința de revizuire, revizorul, rezultatul și motivul pentru eliberare sau refuz. Dacă registrul spune că domeniul sursei contează, evenimentele ar trebui să înregistreze domeniul sursei. Dacă retenția este un risc, evenimentele ar trebui să înregistreze schimbările de stare ale retenției. Registrul de riscuri nu ar trebui să fie proză plutind deasupra software-ului. Ar trebui să fie un set de afirmații pe care runtime-ul le poate ajuta să verifice.
Acest lucru nu înseamnă că fiecare cerință de guvernanță devine cod imediat. Unele controale sunt umane, contractuale sau organizaționale. Dar chiar și controalele umane au nevoie de dovezi. O verificare manuală poate crea totuși o înregistrare. O obligație contractuală poate fi totuși mapată la o atestare cerută. Un proces al unui furnizor poate fi totuși reprezentat printr-un eveniment primit, un raport semnat sau o stare de dovezi lipsă. Ideea este să conectăm limbajul riscului de limbajul dovezilor înainte ca sistemul să înceapă să producă consecințe.
Beneficiul tăcut este o conversație mai bună. Inginerii nu mai percep guvernanța ca pe o mustrare venită târziu în proces. Echipele de guvernanță nu mai percep ingineria ca pe un festival de cazuri limită. Ambele părți pot privi același schemă de evenimente și pot întreba dacă aceasta conține faptele necesare pentru a gestiona riscul. Acest lucru este mai puțin spectaculos decât un atelier de strategie AI. Este, de asemenea, mai puțin probabil să producă un PDF pe care nimeni să nu îl poată pune în practică.
Auditabilitatea schimbă conversația despre construcție
Când auditabilitatea este prezentă de la început, revizuirile de design devin mai concrete. Echipa nu se întreabă doar dacă o funcționalitate funcționează. Se întreabă ce înregistrare lasă funcționalitatea în urmă. Se întreabă cine poate inspecta înregistrarea, cât timp trăiește, ce poate fi corectat, ce nu trebuie niciodată suprascris și la ce întrebare viitoare ar trebui să poată răspunde. Aceste întrebări îmbunătățesc funcționalitatea pentru că expun stări ascunse și autoritate neclară.
Procurările se schimbă și ele. În loc să întrebe furnizorii dacă suportă jurnale de audit, la care aproape toată lumea poate răspunde cu un da entuziast, organizația poate cere capacități specifice de dovezi. Pot fi exportate versiunile de politici împreună cu fiecare decizie. Pot fi incluse identificatorii de model și domeniile sursă. Pot fi distinse suprascrierile umane de acțiunile automate. Pot fi păstrate, șterse, semnate sau redate înregistrările conform regulilor noastre. Putem inspecta traseul fără să plătim pentru o aventură eroică de servicii profesionale. Ultimul punct este adesea cel la care discuția devine educativă.
Operațiunile se schimbă și ele. Răspunsul la incidente devine mai puțin speculativ. O echipă poate identifica cazurile afectate, le poate compara cu versiunile cunoscute de politici, poate găsi înregistrările lipsă și poate arăta calea de la semnal la acțiune. Munca de conformitate devine mai puțin sezonieră. Îmbunătățirea produsului devine mai onestă pentru că echipa poate vedea nu doar ce a făcut sistemul, ci și în ce condiții a făcut-o. Auditabilitatea nu este o frână pentru livrare. Este unul dintre lucrurile care împiedică livrarea să devină o viitoare săpătură arheologică.
Nimic din toate acestea nu face sistemul perfect. Un sistem auditabil poate lua în continuare decizii proaste. Poate încorpora politici slabe, poate folosi date fragile sau poate fi operat de oameni care au o zi proastă, foarte omenească. Auditabilitatea nu garantează înțelepciunea. Ea garantează că instituția are o șansă mai mare să vadă ce s-a întâmplat, să învețe din asta și să demonstreze că nu a inventat pur și simplu răspunsul după ce faptele s-au produs.
Lecția
Greșeala centrală este să crezi că auditabilitatea aparține finalului, pentru că auditurile au loc la final. Nu este așa. Auditurile au loc după consecințe, dar auditabilitatea trebuie să existe înaintea consecințelor. Înregistrarea trebuie să se nască odată cu acțiunea. Evenimentul trebuie să își poarte contextul cât timp contextul este încă adevărat. Sistemul trebuie să păstreze diferența dintre un fapt, o inferență, o politică, o excepție și o corecție.
Nu este o chemare la procese greoaie pentru fiecare instrument mărunt. Este o chemare la proporție. Cu cât un sistem schimbă mai mult drepturi, acces, bani, siguranță, eligibilitate, volum de muncă sau memoria instituțională, cu atât mai mult trebuie să lase dovezi structurate. Începeți cu granițele cu consecințe. Denumiți evenimentele. Versionați regulile. Păstrați timpul și identitatea. Faceți corecțiile aditive. Testați reluarea înainte ca frica să intre în încăpere.
Există ceva aproape comic în această disciplină. Viitorul automatizării de încredere depinde mai puțin de inteligență spectaculoasă și mai mult de a-ți aminti ce regulă a fost declanșată într-o miercuri ploioasă din februarie. Dar instituțiile serioase sunt construite din acest tip de memorie. Ele nu au încredere în sisteme pentru că sistemele sună încrezător. Au încredere în sisteme pentru că sistemele pot fi inspectate când încrederea nu mai este suficientă.
Așa că adăugați dovezile cât timp munca este încă obișnuită. Înainte de petrecerea de lansare, înainte de incident, înainte de migrare, înainte ca echipa să uite de ce acel câmp era opțional. Mai târziu va veni. Mai târziu vine întotdeauna, purtând un dosar numit pachet de dovezi și o întrebare care merită un răspuns mai bun decât probabil.