Ar gali reguliuotojas audituoti judantį taikinį?

Taip, bet ne apsimetant, kad adaptyvi sistema yra statiškas objektas. Auditui reikia užfiksuotos būsenos, apriboto teiginio, įrodymų su sąlygomis ir įrašo,...

Ar gali reguliuotojas audituoti judantį taikinį?

Auditui leidžiama nufotografuoti

Judantis taikinys nėra nepastebimas. Jis tik nepastebimas tokiai patikrai, kuri užduoda vieną amžiną klausimą ir tikisi vieno amžino atsakymo. Šis skirtumas svarbus. Dirbtinio intelekto sistemos keičiasi keliomis kryptimis vienu metu. Teikėjas išleidžia naują modelio versiją. Diegėjas pakeičia užklausą arba sprendimo slenkstį. Paieškos duomenų rinkinys papildomas nauju politikos dokumentu. Tapatybės taisyklė pakeičia, kas gali iškviesti įrankį. Įrankis įgyja lauką, praranda lauką arba pradeda grąžinti kitą reikšmę tuo pačiu lauko pavadinimu. Žmonių komanda pakeičia savo procedūrą. Pasaulis, kuris tiekia įvestis, keičiasi niekam neklausęs leidimo išleidimui.

Nė vienas iš šių dalykų nepadaro audito beprasmiško. Jie tik padaro audito objektą tikslesnį. Klausimas nėra tai, ar organizacija gali įrodyti, kad sistema liks nepakitusi amžinai. Tai būtų keistas pažadas net skaičiuotuvui, prijungtam prie duomenų bazės. Klausimas yra tai, ar organizacija gali parodyti, kokia sistema veikė atitinkamu momentu, ką ji turėjo daryti, kokie įrodymai pagrindė tą naudojimą, kokios sąlygos apribojo tuos įrodymus, kam priklausė sprendimas ir koks vėlesnis pakeitimas turėtų paskatinti sprendimą persvarstyti.

Auditui leidžiama nufotografuoti. Tik jis neturi vadinti nuotraukos kraštovaizdžiu. Tinkamas įrašas nurodo būseną, kuri buvo patikrinta, ir išlaiko kelią iš tos būsenos į kitą. Tada jis gali pasakyti ką nors naudingo: šis vertinimas buvo susijęs su šiuo modeliu, šiais nustatymais, šia duomenų riba, šiais įrankiais, šia politika, šiuo darbo srautu ir šiuo išleidimo sprendimu. Jis taip pat gali pasakyti ką nors mažiau patogaus ir vertingesnio: išvada automatiškai nepersikėlė į kitą būseną.

Tai geresnis atskaitos taškas nei pažįstamas nekintamų ženklelių teatras. Ženklelis rodo, kad kažkas jau išsprendė klausimą. Audito įrašas turėtų leisti pamatyti, kas buvo išspręsta, kokiu pagrindu, kokiam naudojimui ir kiek laiko tas pagrindas išliko taikytinas. Reguliuotojui nereikia sustingusios organizacijos. Reguliuotojui reikia organizacijos, kuri gebėtų atskirti sustingusį įrašą nuo veikiančios paslaugos, nelaikydama nei vieno mistiniu objektu.

Europos dirbtinio intelekto taisyklės jau rodo šia kryptimi. Didelės rizikos dirbtinio intelekto sistemoms Dirbtinio intelekto aktas reikalauja techninės dokumentacijos prieš pateikiant sistemą rinkai arba pradedant ją naudoti, ir reikalauja ją nuolat atnaujinti. Jis taip pat reikalauja automatiškai registruoti svarbius įvykius per visą sistemos gyvavimo laikotarpį ir dokumentuotos stebėsenos po pateikimo rinkai sistemos, proporcingos technologijai ir rizikai. Tai nėra nurodymai padaryti vieną ceremoninę ekrano nuotrauką. Tai nurodymai išlaikyti įrodymų kelią per pokyčius.

Judantis taikinys paprastai yra sistema

Vilioja apibūdinti dirbtinio intelekto sistemą kaip modelį ir tada aptarti versijavimą taip, tarsi naujas modelio svorių failas būtų visa istorija. Tai patogu skaidrėms, bet netikslu daugeliui veiklos klausimų. Modelis yra svarbus komponentas. Jis retai yra visas objektas, kurio elgsena paveikia žmogų, darbo srautą ar teisinę prievolę.

Apsvarstykite įprastą sprendimų paramos kelią, aprašytą čia kaip hipotetinį pavyzdį, o ne kaip realaus diegimo aprašymą. Vartotojas pateikia užklausą. Paslauga paima dokumentus, kuriuos jai leidžiama naudoti. Modelis parengia rekomendaciją. Taisyklė patikrina, ar yra reikalingų įrodymų. Apmokytas vertintojas gali priimti, pakeisti arba atmesti rekomendaciją. Tada darbo srautas užregistruoja veiksmą. Stebimas rezultatas priklauso ne tik nuo modelio. Jis priklauso nuo šaltinio versijų, paieškos nustatymų, leidimų, sąsajos formuluočių, slenksčių, eilės taisyklių, žmogaus įgaliojimų ir veiksmo ribos.

Jei keičiasi šaltinio tekstynas, modelis gali gauti kitokį faktinį pagrindą, nors nepasikeičia nė vienas parametras. Jei keičiasi užklausa, modelio gali būti paprašyta priimti kitokio pobūdžio sprendimą. Jei recenzento ekrane nebematyti neapibrėžtumo, žmogaus vykdoma priežiūra, aprašyta rizikos faile, gali nebeatitikti tos priežiūros, kurią žmonės iš tikrųjų vykdo. Jei integracija pradeda automatiškai taikyti rekomendacijas, sistema įgyja naują įgaliojimą, net jei modelio atsakymas yra bitų lygmeniu identiškas.

Būtent todėl tinkamas audito įrašas prasideda nuo numatyto naudojimo tikslo ir sistemos ribų. AI akto techninės dokumentacijos reikalavimai, išdėstyti IV priede, apima numatyto tikslo, versijų, stebėsenos ir valdymo funkcijų, patvirtinimo ir testavimo, rizikos valdymo, pakeitimų, padarytų per gyvavimo ciklą, ir atitinkamų veiklos rodiklių aprašymus. Esmė ne ta, kad kiekvienai sistemai reikia popierizmo katedros. Esmė ta, kad recenzentas negali įvertinti teiginio, kai teiginyje įvardytas objektas tyliai keičia savo pavidalą.

Platesnio objekto vadinti sistema nėra būdas, kaip darbą padaryti skambesnį. Tai būdas išvengti kategorinės klaidos. Modelio vertinimas gali atsakyti į modelio klausimą. Sistemos auditas turi atsakyti į sistemos klausimą. Pirmasis gali nustatyti, kaip komponentas elgėsi apibrėžtomis sąlygomis. Antrasis turi parodyti, kaip tas komponentas buvo susietas su žmonėmis, duomenimis, taisyklėmis, įrankiais ir pasekmėmis. Vienas kito nepakeičia. Modelio balas nėra darbo eigos aprašymas, kaip ir geras padangų testas nėra maršruto planas.

Ką auditorius iš tikrųjų bando nustatyti

Besikeičiančios sistemos auditas nereiškia, kad reikia posėdžių salėje atkartoti kiekvieną jos gyvavimo akimirką. Tai reiškia, kad tam tikrus teiginius reikia padaryti patikrinamus. Ar sistema buvo naudojama pagal nurodytą paskirtį? Ar sprendimas dėl išleidimo buvo pagrįstas tai paskirčiai tinkamais įrodymais? Ar organizacija išsaugojo informaciją, reikalingą ginčytinam rezultatui ištirti? Ar prasmingi pakeitimai paskatino pakartotinį vertinimą? Ar stebėsena leido pastebėti skirtumą tarp nekenksmingo atnaujinimo ir esminio pakeitimo? Ar atsakingi asmenys galėjo sustabdyti, apriboti ar pataisyti kelią, kai įrodymai nebeatlaikė?

Tai praktiniai klausimai, nes kiekvienas jų turi stebimą atitikmenį. Numatytas tikslas turi būti įrašytas. Vertinimas turi testų rinkinį, konfigūraciją, testavimo populiaciją ar įvesties ribas, metodą, rezultatą ir apribojimus. Sprendimas dėl išleidimo turi savininką ir sąlygas. Pakeitimas turi tapatybę, datą, priežastį ir įvertintą poveikį. Stebėsena turi įvardytus signalus, ribines vertes arba peržiūros priežastis. Sustabdymo kelias turi įgaliojimą ir veiksmą. Išsami informacija skiriasi, bet audito galimybė atsiranda iš abstrakčių užtikrinimų pavertimo dalykais, kuriuos kiti gali patikrinti.

Čia yra svarbi riba. Auditas neįrodo, kad kiekviena ateities išvestis bus teisinga, nešališka ar nekenksminga. Jis negali neapibrėžto pasaulio paversti deterministiniu. Jis gali nustatyti, ar organizacija pateikė teiginius, pakankamai siaurus, kad juos būtų galima išnagrinėti, ar surinko įrodymus, galinčius tuos teiginius pagrįsti, ir ar išlaikė galimybę juos persvarstyti. Tai gali skambėti kukliai. Bet būtent čia prasideda atskaitomybė.

Skirtumas tarp įrodymų ir užtikrinimo kalbos yra svarbus. Sakyti, kad modelis buvo įvertintas, dar nėra naudingo vertinimo įrodymas. Žodžiui reikia objekto. Įvertintas pagal kurią užduotį, kokius kriterijus ir kokius duomenis? Su kokiu modeliu ir kokia sistemos būsena? Kokiomis veikimo sąlygomis? Kas patikrino metodą? Kas buvo už taikymo ribų? Kas padarytų rezultatą pasenusį? Be šių klausimų vertinimas yra tik raminamasis būtasis laikas.

Europos Komisijos ankstesnėse Patikimo dirbtinio intelekto etikos gairėse atkuriamumas apibrėžtas paprastai: atliekant dirbtinio intelekto eksperimentą, pakartojus jį tomis pačiomis sąlygomis, turėtų būti gautas toks pat elgesys. Šis apibrėžimas naudingas, nes jame glūdi jo paties riba. Tos pačios sąlygos čia nėra tuščia frazė. Pakartotinis eksperimentas gali parodyti, ar užfiksuotas teiginys yra atkuriamas. Jis negali parodyti, kad nepakitęs elgesys išliks ir pasikeitus duomenų šaltiniui, politikai ar diegimo keliui. Taigi atkuriamumas nėra pažadas, kad pasaulis stovės vietoje. Tai disciplina, padedanti tiksliai pasakyti, kas iš tikrųjų įvyko.

Užfiksuotas vertinimas yra tam tikras laiko momentas. Auditas tampa patvarus, kai su juo galima palyginti kitą būseną.

Versijos numeris yra būtinas, bet nepakankamas

Versijos numeriai naudingi, nes neleidžia įrašui apsimesti, kad pavadinimų pakanka. Vis dėlto versijos etiketė gali sukurti ir klaidingą saugumo jausmą. Tokia etiketė kaip versija 4.2 gali identifikuoti programinės įrangos leidimą, bet nebūtinai nurodo faktinę dirbtinio intelekto kelio būseną. Konfigūracijos reikšmė gali būti saugoma ne modelio saugykloje. Paieškos indeksas gali būti atkurtas iš besikeičiančių dokumentų. Funkcijos vėliavėlė gali parinkti kitą įrankio kelią. Politikos modulis gali pakeisti leidžiamą veiksmą. Todėl paslauga gali turėti nepriekaištingai suformatuotą versijos numerį ir vis tiek būti sunkiai atkuriama.

Svarbiausia yra tapatybė, atitinkanti teiginį. Jei teiginys susijęs su neprisijungus veikiančio modelio etalonu, gali būti būtini modelio artefaktas, išvadų kodas, parametrų nustatymai, duomenų rinkinio versija, metrikos apibrėžtis ir vykdymo aplinka. Jei teiginys susijęs su tiesiogiai veikiančia sprendimų paramos paslauga, įraše papildomai gali prireikti raginimo ar šablono, paieškos konfigūracijos, šaltinių identifikatorių ir naujumo, leidimų būsenos, įrankių schemų, politikos versijos, vertintojo sąsajos ir darbo eigos taisyklės. Audito paketui nereikia talpinti kiekvieno kiekvienos sistemos baito. Jis turi talpinti arba patikimai nurodyti elementus, galinčius pakeisti teiginio prasmę.

Štai kodėl manifestas dažnai yra naudingesnis nei archyvas, išmestas į standųjį diską. Manifestas nurodo, kurie artefaktai priklauso kartu, jų identifikatorius, vientisumo nuorodas, ryšius ir prieigos sąlygas. Jis leidžia auditoriui rasti reikiamą paketą nereikalaujant, kad kiekvienas šaltinis būtų nukopijuotas į neribotos prieigos aplanką. Kai kuriuose įrodymuose yra asmens duomenų, saugumui jautrios informacijos, licencijuotos medžiagos ar komercinių paslapčių. Audituojamumas reikalauja kontroliuojamos prieigos ir prasmingo atsekamumo, o ne privalomo viešo visko, kas užtikrina sistemos veikimą, atskleidimo.

IV priedas laikosi panašaus praktinio požiūrio. Techninės dokumentacijos nelaiko trumpu produkto aprašymu. Jame prašoma informacijos apie sistemą ir jos gyvavimo ciklą, įskaitant pakeitimus, padarytus kūrimo metu ir po pateikimo rinkai, stebėsenos ir valdymo funkcijas, patvirtinimo ir bandymų procedūras bei rezultatus, rizikos valdymo priemones ir veiklos rodiklių aprašymą. Dokumentas turi būti pakankamai aiškus, kad nacionalinės kompetentingos institucijos ir notifikuotosios įstaigos galėtų įvertinti atitiktį. Kitaip tariant, informacija turi būti susisteminta vertinimui, o ne tik surinkta todėl, kad egzistavo saugojimo sistema.

Už viso to slypi mažas, bet lemiamas dizaino klausimas: kas turėtų pasikeisti, kad ankstesni įrodymai nebegalėtų pagrįsti dabartinės pretenzijos? Atsakymas nubrėžia versijos ribą. Jei naujas paieškos šaltinis keičia rekomendacijų faktinį pagrindą, jis priklauso tapatybei. Jei nauja peržiūros sąsaja užgožia įspėjimą, ji priklauso tapatybei. Jei kosmetinis teksto pakeitimas negali paveikti vertinamo elgesio, jis greičiausiai priklauso pakeitimų istorijai, bet ne vertinimo atspaudui. Geras versijavimas nėra maksimalus rinkimas. Tai apgalvotas aktualumas.

Užfiksuokite sutartį, ne tik rezultatą

Rezultatas yra kažko įrodymas, bet ne visada pakankamas įrodymas. Ekrano nuotrauka gali parodyti, kas buvo matoma ekrane. Ji dažnai negali parodyti, kuris modelis jį sukūrė, kuris šaltinis buvo gautas, ką grąžino įrankis, kuri taisyklė buvo taikyta, kurie įvesties duomenys buvo praleisti arba ar rodinyje buvo paslėptas įspėjimas. Tai viena iš priežasčių, kodėl ekrano nuotraukos kaupiasi atitikties aplankuose su archeologinių radinių iškilmingumu ir gerokai mažesne aiškinamąja galia.

Užfiksuota sutartis yra turtingesnė. Ji susieja rezultatą su sąlygomis, kuriomis sistema turėjo veikti. Vertinimui tai gali apimti tikslią rinkinį, įvesties duomenis arba apsaugotą nuorodą į juos, numatytus teiginius, modelio ir paslaugos konfigūraciją, atitinkamas politikos ir įrankių versijas, vykdymo aplinką, kai ji turi įtakos rezultatui, ir priėmimo taisyklę. Tiesioginiam paleidimui tai gali apimti užklausos tapatybę, įgaliotą apimtį, šaltinio ir gavimo įrašus, modelio maršrutą, įrankio iškvietimus, valdiklius, žmogaus įsikišimą ir gautą būsenos pasikeitimą. Tikslas nėra įrašyti begalinį dienoraštį. Tikslas yra išlaikyti pakankamai priežastingai svarbios informacijos, kad vėliau būtų galima užduoti rimtą klausimą.

Yra naudingas atskyrimas. Vertinimo fiksavimas įrodo teiginį apie apibrėžtą testą ar pratimą. Veiklos įrašas padeda rekonstruoti konkretų įvykį ar sprendimą. Leidimo įrašas paaiškina, kodėl organizacija leido sistemai patekti į apibrėžtą maršrutą. Pakeitimų įrašas paaiškina, kas vėliau pasikeitė. Šie įrašai persidengia, bet jų nereikėtų painioti. Gamybos žurnalo laikymas etalonu arba etalono laikymas gamybos darbo eigos įrodymu yra efektyvus būdas priversti kiekvieną įrašą nešti daugiau, nei jis gali.

AI akto registravimo taisyklė didelės rizikos sistemoms taip pat susieta su tikslu. 12 straipsnis reikalauja automatiškai registruoti atitinkamus įvykius per visą sistemos gyvavimo laiką, o registravimo galimybės turi atitikti numatytą paskirtį. Reglamentas nurodo sistemos veikimo atsekamumą, veiklos stebėseną ir stebėseną po pateikimo rinkai. Jis nereikalauja beatodairiško registravimo įpročio. Jis reikalauja įrašų, kurie turi paskirtį.

Ši frazė, įrašai su užduotimi, yra geresnis orientyras nei bendras reikalavimas stebėti. Modelio identifikatorius gali padėti atskirti atnaujinimą. Įvesties duomenų kilmė gali paaiškinti netikėtą rekomendaciją. Taisyklės versija gali paaiškinti, kodėl rezultatas buvo užblokuotas. Peržiūros teisės panaikinimas gali paaiškinti, kodėl operacinis veiksmas skiriasi nuo modelio pasiūlymo. Laiko žyma gali nustatyti eiliškumą. Privatumą gerbiantis dizainas vis tiek klausia, ar kiekvienas laukas yra būtinas, proporcingas, saugomas apibrėžtą laikotarpį ir apsaugotas nuo pačios sistemos, kurią jis turi tikrinti.

Atkuriamumas turi dvi sąžiningas formas

Žmonės dažnai vartoja žodį atkuriamas įvairiomis reikšmėmis. Tokia painiava suprantama. Komanda gali turėti omenyje, kad gali pakartotinai paleisti fiksuotą vertinimą ir gauti tą patį rezultatą. Tyrėjas gali turėti omenyje, kad kita komanda gali atlikti aprašytą metodą ir patikrinti rezultatą. Operatorius gali turėti omenyje, kad tyrimas gali atkurti būseną, naudotą konkrečiam sprendimui. Klientas gali turėti omenyje, kad darbo eiga užtikrina nuoseklų vertinimą, o ne savavališkai keičiasi nuo antradienio iki ketvirtadienio. Tai susiję tikslai. Tai ne viena savybė, turinti kelias skrybėles.

Pirma, yra užfiksuoto paleidimo atkuriamumas. Jei artefaktas, konfigūracija, įvestys, atitinkama būsena ir vykdymo sąlygos išlaikomos fiksuotos, pakartojimas turėtų duoti dokumentuotą rezultatą laikantis sistemos žadėtų sąlygų. Kai kurios sistemos gali pateikti stipresnį deterministinį teiginį apibrėžtam vykdymo keliui. Kitos priklauso nuo kontroliuojamo atsitiktinumo, paskirstytos infrastruktūros ar trečiųjų šalių paslaugų ir gali pateikti tik siauresnį teiginį. Atsakinga kalba yra konkreti. Ji nurodo, kas yra fiksuota, kas matuojama, koks kitimas lieka galimas ir kaip atliekamas palyginimas.

Antra, yra vertinimo argumento atkuriamumas. Peržiūrintysis turi matyti, kodėl rinkinys atspindi teiginį, ar metrika turi nurodytą reikšmę, ar priėmimo riba yra pagrįsta ir ar įrodymai gali būti perkelti į operacinį kontekstą. To neišsprendžia kontrolinė suma. Kontrolinė suma gali patvirtinti, kad failas nepasikeitė. Ji negali patvirtinti, kad failas tikrino teisingą klausimą, kad populiacija buvo tinkama arba kad rezultatas pagrindžia su juo susijusį sprendimą.

Šios dvi formos turėtų susitikti. Puikiai pakartojamas testas, matuojantis ne tą dalyką, vis tiek yra netinkamas testas. Sudėtingas argumentas, susietas su nepakartojamu paleidimu, neleidžia peržiūrintiesiems atskirti išvados nuo laimingo atsitiktinumo. Naudingas standartas nėra abstraktus reikalavimas tobulam atkuriamumui. Tai matomas atitikimas tarp teiginio, metodo, užfiksuotų sąlygų, stebėto rezultato ir naudojimo, kurį organizacija nori leisti.

Komisijos gairės dėl bendrosios paskirties DI teikėjų įsipareigojimų taip pat sieja vertinimą su dokumentacija ir rizika. Jose aprašoma techninė dokumentacija institucijoms ir atskira informacija vėlesniems teikėjams, įskaitant galimybes, apribojimus ir integracijos informaciją. Bendrosios paskirties DI modeliams, keliantiems sisteminę riziką, 55 straipsnis reikalauja vertinimo naudojant standartizuotus protokolus ir pažangiausius įrankius, įskaitant dokumentuotą priešišką testavimą sisteminei rizikai nustatyti ir sumažinti. Vertinimas, kuris negali pasakyti, kas buvo tikrinta, kokiomis sąlygomis ir su kokiais apribojimais, netampa naudingesnis vien todėl, kad vadinamas standartizuotu.

Įrodymai turi galiojimo pabaigos sąlygą

Įrodymai nesensta vien todėl, kad kažkas nusprendė būti sunkiai sukalbamas. Jie nustoja galioti, kai sąlygos, kurios leido jiems pagrįsti teiginį, pasikeičia tiek, kad ryšio nebegalima laikyti savaime suprantamu. Tai įprastas samprotavimas. Tilto konstrukcijos bandymas automatiškai neapima kitos medžiagos. Maisto saugos patikra neapima naujo tiekėjo vien dėl optimizmo. Dirbtinio intelekto maršruto vertinimas neturėtų automatiškai apimti pakeisto modelio, pakeistos duomenų ribos, pakeisto įrankio įgaliojimų ar pakeistų sprendimo pasekmių.

Sunkiausias darbas yra nuspręsti, kurie pokyčiai yra svarbūs. Tai techninio sprendimo, rizikos analizės ir valdysenos reikalas, o ne vienas procentas, įrašytas į politiką. Pataisa, keičianti mygtuko spalvą, gali neturėti jokios įtakos vertinimui. Pokytis, dėl kurio įspėjimas tampa mažiau matomas, gali būti esminis, jei saugos argumentas priklauso nuo to, kad vertintojas jį pamatytų. Šaltinio rinkinio perkatalogavimas gali būti nekenksmingas vienai užduočiai ir kritinis kitai. Naujas modelio galutinis taškas gali išlaikyti plačią galimybę, kartu pakeisdamas delsą, atsisakymo elgseną, kalbų aprėptį ar įrankio naudojimo modelius, kurie yra svarbūs maršrutui.

Todėl naudinga pokyčių kontrolė prasideda nuo poveikio klausimo, o ne nuo išleidimo ritualo. Kokiam teiginiui šis pokytis galėtų turėti įtakos? Kurią prielaidą jis sutrikdo? Kurie įrodymai priklausė nuo ankstesnės būsenos? Ar ribota patikra atsako į klausimą, ar maršrutui reikia naujo vertinimo ir išleidimo sprendimo? Kas gali priimti tą sprendimą, ir kas gali jį užginčyti? Atsakymai turėtų būti užfiksuoti, nes kitaip kitam vertintojui teks juos atspėti iš bilietų pavadinimų, padavimų ir nežymaus šrifto pasikeitimo išleidimo skydelyje.

Čia taip pat stebėsena tampa įrodymų dalimi, o ne atskiru stebėjimo pomėgiu. 72 straipsnis reikalauja, kad didelės rizikos dirbtinio intelekto sistemų teikėjai aktyviai ir sistemingai rinktų, dokumentuotų ir analizuotų atitinkamus veiklos duomenis visą sistemos gyvavimo laikotarpį, kad galėtų įvertinti nuolatinę atitiktį. Rinkodaros stebėsenos planas yra techninės dokumentacijos dalis. Taigi stebėsena nėra tik būdas sužinoti, ar paslauga yra apkrauta. Tai būdas sužinoti, ar sąlygos, kuriomis buvo grindžiamas pirminis teiginys, tebegalioja.

Stebėsena nepadaro kiekvieno rezultato savaime suprantamo. Vertintojų ir sistemos nesutarimų padidėjimas gali turėti daug priežasčių. Šaltinio šviežumo pokytis gali atspindėti dujotiekio problemą, o ne modelio poslinkį. Didesnis atsisakymų rodiklis gali reikšti saugesnę politiką, sugedusią integraciją ar naują užklausų grupę. Įraše turėtų būti išsaugota pakankamai konteksto žmogiškam tyrimui. Metrika yra signalai. Jie nėra liudytojai.

Įrodymai galioja apibrėžtame kontekste. Esminis pokytis sukuria klausimą peržiūrai, o ne spragą, leidžiančią jos išvengti.

Esminis pokytis reikalauja sprendimo kelio

The phrase material change is often treated as if it names a self-evident property. It does not. Material to which claim, risk and user? The answer must be specific enough that people can use it when they are tired, late and keen to call a change minor. A good policy does not promise to classify every possible update in advance. It names the factors that determine whether reassessment is needed.

Those factors usually include intended purpose, affected people, authority granted to the route, data sources and their quality controls, model or system architecture, evaluation scope, decision thresholds, monitoring signals, human oversight, security controls and recovery paths. A modification that changes any of these may or may not be material. What matters is whether it can alter the evidence required for the existing claim or the risk left after controls.

The AI Act contains an explicit responsibility around substantial modification. Its exact legal application depends on the system and actors involved, so it should not be compressed into a slogan. The operational lesson is simpler and broader: an organisation should know when a change transfers or creates responsibility, when the existing documentation is no longer adequate, and when the system must be assessed again before a new use continues. It is less exciting than a feature launch. It is also less likely to produce a difficult call in which everyone agrees the system changed but nobody owns the decision.

A decision path gives a change somewhere to go. One path may permit a documented no-impact finding. Another may require a targeted regression evaluation. Another may require a broader risk review, a change to instructions for use, a revised monitoring plan or a fresh release approval. The most serious path may require the route to remain limited or paused until evidence is available. The point is not to make every edit expensive. It is to make the important edit impossible to disguise as routine housekeeping.

There is a satisfying lack of romance in this. A change record can show the previous state, the proposed state, the affected claims, the evidence reviewed, the decision, the authority and the conditions after release. That is governance in its working clothes. It will never look as thrilling as a model demonstration. It has the more useful property of helping an organisation explain itself when a demonstration has become a real service.

Evaluation should be able to fail in public, or at least in the file

Evaluation becomes performative when every result is assumed to be a release result. A mature evaluation programme must be able to conclude that evidence is incomplete, that a threshold was missed, that a known limitation prevents a proposed use, or that a claim needs narrowing. These are not embarrassing exceptions to the process. They are outputs of the process.

That is particularly important for adaptive or externally connected systems. A team may discover that a suite no longer represents a live input population. A tool contract may become too unstable to support a replay claim. A model update may improve one task but make a protected route harder to supervise. An operational signal may show that the hand-off from system to reviewer fails under ordinary workload. The right answer is not necessarily a dramatic shutdown. It may be a limit, a revised workflow, a further test, a new acceptance condition or a decision not to make the original claim.

The record must let a reviewer see that negative result. Otherwise an organisation builds a very effective machine for collecting only the evidence it likes. The quality-management requirements in Article 17 are relevant here. They cover, among other things, techniques and procedures for design, development and quality control; examination, test and validation; data management; risk management; post-market monitoring; incident reporting; and communication with authorities. A quality system is not a folder that makes failures disappear. It is a way to detect, document and address them.

The same principle governs access. An external regulator, notified body or authorised reviewer may need technical evidence that cannot be published openly. A public summary may be appropriate for other parts of the record. These are different access routes, not different facts. The public should not be offered a cheerful account while the controlled record describes a narrower and more conditional reality. Confidentiality can be legitimate. Contradiction is a governance failure.

At Dweve, our public Trust Centre makes a small, deliberately limited example of this distinction. Its evaluations page says that an evaluation identifies the model, exact suite, configuration, captured state, evidence and reviewer decision. It also says that a repeated captured contract should produce byte-identical results on supported architectures, while a live rerun can differ when external evidence or adaptive state changes. The page separates the public method from a filled-in marketing result. That is not proof of a model's quality. It is simply the right shape of a claim about evaluation records.

Live monitoring is not a substitute for a pre-release decision

Monitoring is sometimes described as the answer to uncertainty: release the system, watch the dashboard, improve continuously. There is a useful instinct in that sentence. Systems need observation after release because deployment produces information that a laboratory cannot. But monitoring cannot retroactively support a decision for which the evidence was never adequate. It cannot tell a person affected by a flawed high-consequence action that the organisation will learn from the graph next month.

Pre-release evaluation and post-release monitoring answer different questions. Evaluation asks whether the organisation has enough evidence to permit a defined use now. Monitoring asks whether the conditions behind that permission still hold and whether new risks or failures are emerging. The first establishes a starting boundary. The second watches the boundary in operation. A credible system needs both, as well as a route for data and operational learning to return to risk assessment, documentation and change control.

That loop is what turns a static assurance packet into a living record. An evaluation gives a baseline. A deployment record says which baseline was adopted. Logging and monitoring show relevant behaviour. A change may alter the baseline or reveal its limits. A review then updates the claim, its evidence, its constraints or its status. The system moves. The record moves with it, but does not rewrite its own past. An auditor can see both the current position and the path by which it arrived there.

For high-risk systems, the AI Act is explicit that post-market monitoring should gather and analyse relevant performance data throughout the lifetime and allow continuous compliance to be evaluated. It also requires deployers to monitor operation based on instructions for use, and to inform the provider and relevant authority without undue delay where they have reason to consider that use may present a risk. Those requirements do not remove the need for professional judgement. They give professional judgement records, triggers and routes.

There is an organisational temptation to treat monitoring as the responsibility of the operations team and evaluation as the responsibility of the model team. That division will fail at the first meaningful question about a live route. The modeller may know why a test was chosen. The operator may know that the sources were stale. The policy owner may know that a decision rule changed. The reviewer may know that the interface creates automation bias. An audit trail should join their evidence without pretending that one person sees the whole system.

Can a regulator reproduce a decision?

Sometimes the answer should be yes, within a defined scope. If an organisation claims that a decision or evaluation can be replayed, it needs to name what replay means. Does it mean repeating a model call with the same prompt? Does it mean rebuilding the full retrieval-and-tool sequence? Does it mean reconstructing the record that a reviewer saw? Does it mean validating a deterministic calculation from preserved inputs? Each is useful. Each has different technical and legal prerequisites.

A meaningful replay begins with preserved identity. The reviewer needs to know which system version and configuration were in force, which inputs and source versions were admissible, which policies and permissions applied, which external dependencies responded, and which human actions changed the path. Some elements may need to be stored directly. Others may be referenced by stable identifiers and reconstructed through controlled systems. What is not acceptable is to call an exercise replayable when it depends on a live web search, an overwritten database row and a remembered setting from an engineer's laptop.

Even then, a replay may reproduce a record rather than repeat the world. A live source can be updated or withdrawn. A third-party service can change. An adaptive service can accumulate new governed state. A human may make a different judgement when presented with the same information. These are not defects in the idea of replay. They are distinctions the record must preserve. The replay can show what the system did under the captured contract. It does not claim that the present world is identical to that contract.

This is why human decision records belong beside technical records when human oversight is part of the safety or rights argument. An audit may need to know that a person reviewed a recommendation, what information was available to them, what they chose and what authority they held. It does not need to turn every reviewer into a surveillance target or preserve unbounded personal material. It does need enough information to establish whether the promised oversight existed in the event under question.

Reproduction is therefore a ladder, not a boast. At one rung, a reviewer can identify the release. At the next, they can inspect the evidence. Higher up, they can recreate a test or analyse a live decision path. The organisation should say which rung it supports, where the limits are, and which parts require authorised access. A modest, testable replay claim is much stronger than a vague assurance that everything is traceable.

Audits need records that disagree with each other

An organisation's public status record, internal release record, evaluation report, operational logs and incident register should not say different things about the same basic state. But they should not be identical documents either. Each has a different audience and purpose. The public record may state intended purpose, status, known limitations and a route to further information. The technical file may hold detailed architecture, data, tests and controls. The operational record may hold event-level traceability. The change file may explain why a prior conclusion was revisited.

The integrity comes from correspondence. If a public page says a route is limited to recommendation, the technical and operational records should not describe automatic action. If an evaluation says it concerns a captured source set, the release record should not silently apply it to a later one. If a change record says a model update was immaterial, the impact assessment should state the affected claim and evidence. If a monitoring signal raises a review, the subsequent decision should be traceable. The documents may disagree in granularity. They must not disagree about reality.

That correspondence is useful for regulators because it reduces the need to trust one polished artefact. A reviewer can compare records. It is useful for organisations because it exposes drift between teams before an external audit does. And it is useful for affected people because the public explanation can become a real route to accountability rather than a decorative layer placed over a separate private system.

The architecture does not have to be elaborate. A small organisation may use a controlled register, versioned documents, signed exports and disciplined change reviews. A larger organisation may use structured manifests, append-only logs, policy engines and automated evidence capture. The important question is whether the method can reliably connect claim, state, evidence, decision and later change. A gigantic tooling estate that loses this relationship is simply a more expensive way to be vague.

There is a particularly European virtue in making the record inspectable without making it theatrical. Not every answer belongs on a public dashboard. Not every documented uncertainty needs a cheerful icon. But when an organisation has made a consequential claim about an adaptive system, it should be able to show a regulator where that claim lives, what state it referred to, and how the organisation would know that it had become stale.

The audit question changes the design question

Ask early whether a regulator could audit the system as it will actually operate. The answer changes design choices well before a formal audit begins. It favours stable identifiers over ambiguous labels. It favours explicit policy versions over rules embedded in prose. It favours tool contracts that can be recorded and tested. It favours source provenance and freshness markers. It favours a clear boundary between recommendation and action. It favours review screens that preserve the information a reviewer needs. It favours pause and recovery mechanisms with named authority.

It also changes procurement. A supplier's statement that a model is regularly improved is not enough when the deployment depends on a defined evaluated state. The buyer needs to know how changes are notified, what artefacts can be identified, which information is available for impact assessment, whether historical records remain interpretable, and how a route can be limited or paused. These are not exotic demands. They are the practical terms under which an organisation remains responsible for a system that contains a supplier component.

The same question changes evaluation design. A useful suite has an identity and a rationale. Its inputs or references are controlled. Its metrics and thresholds are defined before the result is read. Its exclusions are visible. Its results attach to the system state actually under discussion. Its failures have a route into a decision. Its re-run conditions are clear. An evaluation with these properties can be challenged. That is a feature, not an unfortunate side effect of being thorough.

Visų svarbiausia, klausimas pakeičia paties pokyčio vaidmenį. Pokytis nustoja būti nepatogumas, kurį dokumentacija bando nuslėpti. Jis tampa pirmos klasės įvykiu sistemos įrodymų modelyje. Kai kuriems pokyčiams užteks tik įrašo. Kai kurie paskatins testą. Kai kurie atvers iš naujo sprendimą dėl išleidimo. Drausminga organizacija nepainioja šių kategorijų ir jai nereikia būsimo incidento, kad sužinotų, jog jos egzistavo.

Taigi taip: reguliuotojas gali audituoti judantį taikinį. Auditas prasideda atsisakant klaidingos dilemos tarp užšaldyto modelio kortelės ir visiškai nepažinios tiesioginės paslaugos. Užfiksuokite būseną. Išsakykite teiginį. Išsaugokite sąlygas. Susiekite įrodymus su sprendimu. Užrašykite, kas keičiasi. Įvertinkite iš naujo, kai ryšys nebegalioja. Taikinys gali judėti. Pėdsakas turi likti įskaitomas.

Šaltiniai