Vai regulators var revidēt kustīgu mērķi?

Jā, bet neizliekoties, ka adaptīva sistēma ir statisks objekts. Revīzijai nepieciešams fiksēts stāvoklis, ierobežots apgalvojums, pierādījumi ar...

Vai regulators var revidēt kustīgu mērķi?

Auditam ir atļauts uzņemt fotogrāfiju

Kustīgs mērķis nav ārpus pārbaudes. Tas ir tikai ārpus tāda veida pārbaudes, kas uzdod vienu mūžīgu jautājumu un sagaida vienu mūžīgu atbildi. Šai atšķirībai ir nozīme. AI sistēmas mainās vairākos veidos vienlaikus. Pakalpojumu sniedzējs izlaiž jaunu modeļa versiju. Izvietotājs maina uzvedni vai lēmuma slieksni. Izguves korpuss iegūst jaunu politikas dokumentu. Identitātes noteikums maina to, kurš drīkst izsaukt rīku. Rīks iegūst lauku, zaudē lauku vai sāk atgriezt citu nozīmi ar tādu pašu lauka nosaukumu. Cilvēku komanda maina savu procedūru. Pasaule, kas piegādā ievaddatus, mainās, nevienam nejautājot par izlaišanas pārvaldību.

Neviens no šiem aspektiem nepadara auditu veltīgu. Tas padara audita objektu precīzāku. Jautājums nav par to, vai organizācija var pierādīt, ka sistēma paliks nemainīga mūžīgi. Tas būtu dīvains solījums pat kalkulatoram, kas savienots ar datubāzi. Jautājums ir par to, vai organizācija var parādīt, kāda sistēma darbojās attiecīgajā brīdī, kam tai bija jākalpo, kādi pierādījumi pamatoja šo izmantošanu, kuri nosacījumi ierobežoja pierādījumus, kam piederēja lēmums un kādām vēlākām izmaiņām būtu jāliek lēmumu pārskatīt.

Auditam ir atļauts uzņemt fotogrāfiju. Tam tikai nedrīkst saukt fotogrāfiju par ainavu. Pareizs ieraksts identificē pārbaudīto stāvokli un saglabā ceļu no šī stāvokļa uz nākamo. Tad tas var pateikt kaut ko noderīgu: šis novērtējums attiecās uz šo modeli, šiem iestatījumiem, šo datu robežu, šiem rīkiem, šo politiku, šo darbplūsmu un šo izlaišanas lēmumu. Tas var pateikt arī kaut ko mazāk ērtu un vērtīgāku: secinājums automātiski nepārcēlās uz nākamo stāvokli.

Tas ir labāks sākumpunkts nekā pazīstamais nemainīgu nozīmīšu teātris. Nozīmīte liecina, ka kāds jau ir atrisinājis jautājumu. Audita ierakstam būtu jāļauj redzēt, kas tika atrisināts, uz kāda pamata, kādam lietojumam un cik ilgi šis pamats palika spēkā. Regulatoram nav vajadzīga sastingusi organizācija. Regulatoram ir vajadzīga organizācija, kas spēj atšķirt sastingušu ierakstu no dzīva pakalpojuma, neuztverot nevienu no tiem kā mistisku objektu.

Eiropas AI noteikumi jau norāda šajā virzienā. Augsta riska AI sistēmām Mākslīgā intelekta akts pieprasa tehnisko dokumentāciju pirms sistēmas laišanas tirgū vai nodošanas ekspluatācijā un pieprasa to uzturēt aktuālu. Tas arī pieprasa automātisku attiecīgo notikumu reģistrēšanu sistēmas darbības laikā un dokumentētu pēctirgus uzraudzības sistēmu, kas ir samērīga ar tehnoloģiju un risku. Tie nav norādījumi uzņemt vienu ceremoniālu ekrānuzņēmumu. Tie ir norādījumi saglabāt pierādījumu pēdas cauri izmaiņām.

Kustīgais mērķis parasti ir sistēma

Ir vilinoši aprakstīt AI sistēmu kā modeli un pēc tam apspriest versiju pārvaldību tā, it kā jauns modeļa svara fails būtu viss stāsts. Tas ir ērti prezentācijām un neprecīzi lielākajai daļai operatīvo jautājumu. Modelis ir svarīga sastāvdaļa. Tas reti ir pilnīgs objekts, kura uzvedība ietekmē cilvēku, darbplūsmu vai juridisku pienākumu.

Apsveriet parastu lēmumu atbalsta ceļu, kas šeit aprakstīts kā hipotētisks piemērs, nevis reālas izvietošanas apraksts. Lietotājs iesniedz pieprasījumu. Pakalpojums izgūst dokumentus, kurus tam ir atļauts izmantot. Modelis sagatavo ieteikumu. Noteikums pārbauda, vai ir pieejami nepieciešamie pierādījumi. Apmācīts recenzents var pieņemt, grozīt vai noraidīt ieteikumu. Pēc tam darbplūsma reģistrē darbību. Novērotais rezultāts ir atkarīgs no vairāk nekā tikai modeļa. Tas ir atkarīgs no avotu versijām, izguves iestatījumiem, atļaujām, saskarnes formulējuma, sliekšņiem, rindas noteikumiem, cilvēka pilnvarām un darbības robežas.

Ja mainās avota datu kopa, modelis var iegūt atšķirīgu faktu bāzi, nemainot nevienu parametru. Ja mainās uzvedne, modelim var tikt lūgts pieņemt cita veida spriedumu. Ja recenzenta ekrānā vairs netiek rādīta nenoteiktība, cilvēka uzraudzība, kas aprakstīta riska dokumentā, vairs var nebūt tā uzraudzība, ko cilvēki faktiski īsteno. Ja integrācija sāk automātiski piemērot ieteikumus, sistēma ir ieguvusi jaunu pilnvaru pat tad, ja modeļa atbilde ir burtiski identiska.

Tāpēc saprātīgs revīzijas ieraksts sākas ar paredzēto mērķi un sistēmas robežām. AI akta IV pielikuma tehniskās dokumentācijas prasības ietver paredzētā mērķa, versiju, uzraudzības un kontroles funkciju, validācijas un testēšanas, riska pārvaldības, dzīves cikla laikā veikto izmaiņu un attiecīgo veiktspējas rādītāju aprakstus. Būtība nav tā, ka katrai sistēmai ir nepieciešama dokumentu katedrāle. Būtība ir tā, ka recenzents nevar novērtēt apgalvojumu, ja objekts, uz kuru apgalvojums attiecas, klusi maina savu formu.

Plašāka objekta nosaukšana par sistēmu nav veids, kā likt darbam izklausīties nozīmīgākam. Tas ir veids, kā izvairīties no kategoriju kļūdas. Modeļa novērtējums var atbildēt uz modeļa jautājumu. Sistēmas audits ir jāatbild uz sistēmas jautājumu. Pirmais var noteikt, kā komponents uzvedās noteiktos apstākļos. Otrajam ir jāparāda, kā šis komponents bija saistīts ar cilvēkiem, datiem, noteikumiem, rīkiem un sekām. Neviens neaizstāj otru. Modeļa rezultāts nav darbplūsmas apraksts, tāpat kā labs riepu tests nav maršruta plāns.

Ko revidents patiesībā cenšas noskaidrot

Mainīgas sistēmas auditēšana nenozīmē katra tās dzīves mirkļa atskaņošanu sapulču telpā. Tas nozīmē padarīt konkrētus apgalvojumus pārbaudāmus. Vai sistēma tika izmantota atbilstoši norādītajam mērķim? Vai izlaišanas lēmumu pamatoja pierādījumi, kas atbilst šim mērķim? Vai organizācija saglabāja informāciju, kas nepieciešama strīdīga iznākuma izmeklēšanai? Vai nozīmīgas izmaiņas izraisīja atkārtotu novērtēšanu? Vai uzraudzība padarīja redzamu atšķirību starp nekaitīgu atjauninājumu un būtiskām izmaiņām? Vai atbildīgās personas varēja apturēt, ierobežot vai labot maršrutu, kad pierādījumi vairs nebija spēkā?

Šie ir praktiski jautājumi, jo katram no tiem ir novērojams atbilstošais elements. Paredzētais mērķis pieder ierakstam. Novērtējumam ir komplekts, konfigurācija, testa populācija vai ievades robeža, metode, rezultāts un ierobežojumi. Izlaišanas lēmumam ir īpašnieks un nosacījumi. Izmaiņām ir identitāte, datums, iemesls un novērtētā ietekme. Uzraudzībai ir nosaukti signāli, sliekšņi vai pārskatīšanas trigeri. Apturēšanas maršrutam ir pilnvaras un darbība. Detaļas atšķiras, bet audita iespējamība rodas, pārvēršot abstraktus apliecinājumus lietās, ko kāds cits var pārbaudīt.

Šeit ir svarīgs ierobežojums. Audits nepierāda, ka katrs nākotnes rezultāts būs pareizs, taisnīgs vai nekaitīgs. Tas nevar pārvērst nenoteiktu pasauli deterministiskā. Tas var noteikt, vai organizācija izteica apgalvojumus, kas bija pietiekami šauri, lai tos pārbaudītu, vai tā apkopoja pierādījumus, kas spēj atbalstīt šos apgalvojumus, un vai tā saglabāja spēju tos pārskatīt. Tas var izklausīties pieticīgi. Bet tieši tur sākas atbildība.

Atšķirība starp pierādījumiem un apliecinājuma valodu ir svarīga. Apgalvojums, ka modelis ir novērtēts, vēl nav pierādījums lietderīgam novērtējumam. Vārdam ir nepieciešams objekts. Novērtēts pret kuru uzdevumu, kritērijiem un datiem? Ar kuru modeli un sistēmas stāvokli? Kādos darbības apstākļos? Kurš pārbaudīja metodi? Kas bija ārpus darbības jomas? Kas padarītu rezultātu novecojušu? Bez šiem jautājumiem novērtējums ir tikai nomierinoša pagātnes forma.

Eiropas Komisijas agrākās ētikas pamatnostādnes uzticamam mākslīgajam intelektam reproducējamību formulēja vienkārši: MI eksperimentam, atkārtojot to pašos apstākļos, būtu jāuzrāda tāda pati uzvedība. Šī ir noderīga definīcija, jo tā ietver savu ierobežojumu. Vieniem un tiem pašiem apstākļiem ir reāla nozīme. Atkārtots eksperiments var parādīt, vai fiksētais apgalvojums ir reproducējams. Tas nevar parādīt, ka nemainīga uzvedība saglabāsies arī pēc izmainīta datu avota, politikas vai ieviešanas ceļa. Reproducējamība tādējādi nav solījums, ka pasaule stāvēs uz vietas. Tā ir disciplīna, kas nosaka, ko tieši notika.

Fiksēts novērtējums ir konkrēts laika punkts. Audits kļūst noturīgs, kad ar to var salīdzināt nākamo stāvokli.

Versijas numurs ir nepieciešams, bet nepietiekams

Versijas numuri ir noderīgi, jo tie neļauj ierakstam izlikties, ka nosaukumi ir pietiekami. Tomēr versijas etiķete var radīt arī viltus drošības sajūtu. Tāda etiķete kā versija 4.2 var identificēt programmatūras laidienu, bet tā ne vienmēr identificē MI ceļa faktisko stāvokli. Konfigurācijas vērtība var atrasties ārpus modeļa krātuves. Atgūšanas indekss var tikt pārbūvēts no mainīgiem dokumentiem. Funkcijas karodziņš var izvēlēties citu rīka ceļu. Politikas dzinējs var mainīt atļauto darbību. Tādējādi pakalpojumam var būt nevainojami formatēts versijas numurs, un tas joprojām var būt grūti rekonstruējams.

Būtisks ir identitātes veids, kas atbilst apgalvojumam. Ja apgalvojums attiecas uz bezsaistes modeļa etalonu, būtiski var būt modeļa artefakts, secinājumu kods, parametru iestatījumi, datu kopas versija, metrikas definīcija un izpildes vide. Ja apgalvojums attiecas uz tiešsaistes lēmumu atbalsta pakalpojumu, ierakstam papildus var būt nepieciešams uzvedne vai veidne, atgūšanas konfigurācija, avotu identifikatori un to aktualitāte, atļauju stāvoklis, rīku shēmas, politikas versija, recenzenta saskarne un darbplūsmas noteikums. Audita paketei nav jāietver katrs katras sistēmas baits. Tai ir jāietver vai ticami jānorāda elementi, kas varētu mainīt apgalvojuma nozīmi.

Tāpēc manifests bieži vien ir noderīgāks par arhīvu, kas izgāzts cietajā diskā. Manifests norāda, kuri artefakti pieder kopā, to identifikatorus, to integritātes atsauces, to savstarpējās attiecības un piekļuves nosacījumus. Tas ļauj auditoram atrast attiecīgo paketi, nepieņemot, ka katru avotu var iekopēt neierobežotā mapē. Daži pierādījumi satur personas datus, drošības ziņā sensitīvu informāciju, licencētu materiālu vai komercnoslēpumus. Auditējamība prasa kontrolētu piekļuvi un jēgpilnu izsekojamību, nevis obligātu publisku izpaušanu visam, kas liek sistēmai darboties.

IV pielikums izmanto līdzīgu praktisku pieeju. Tehniskā dokumentācija tajā netiek traktēta kā īss produkta apraksts. Tajā tiek prasīta informācija par sistēmu un tās dzīves ciklu, tostarp par izmaiņām, kas veiktas izstrādes laikā un pēc laišanas tirgū, uzraudzības un kontroles funkcijām, validācijas un testēšanas procedūrām un rezultātiem, riska pārvaldības pasākumiem, kā arī veiktspējas rādītāju apraksts. Dokumentam jābūt pietiekami skaidram, lai valstu kompetentās iestādes un paziņotās institūcijas varētu novērtēt atbilstību. Citiem vārdiem, informācija ir jāsakārto pārbaudei, nevis tikai jāapkopo tāpēc, ka pastāv uzglabāšanas sistēma.

Aiz tā visa slēpjas neliels, bet izšķirošs dizaina jautājums: kam būtu jāmainās, lai iepriekšējie pierādījumi vairs nevarētu pamatot pašreizējo apgalvojumu? Atbilde nosaka versijas robežu. Ja jauns izguves avots maina ieteikumu faktisko pamatu, tas ietilpst identitātē. Ja jauna recenzenta saskarne aizēno brīdinājumu, tas ietilpst identitātē. Ja kosmētisks teksta labojums nevar ietekmēt novērtēto darbību, tas, visticamāk, pieder izmaiņu vēsturei, bet ne novērtējuma nospiedumam. Laba versiju pārvaldība nav maksimāla apkopošana. Tā ir pamatota atbilstība.

Fiksē līgumu, ne tikai rezultātu

Rezultāts ir pierādījums kaut kam, bet tas ne vienmēr ir pietiekams pierādījums. Ekrānuzņēmums var parādīt, kas bija redzams ekrānā. Tas bieži vien nevar parādīt, kurš modelis to izveidoja, kurš avots tika izgūts, ko atgrieza rīks, kurš noteikums tika piemērots, kuri ievaddati tika izlaisti vai vai skats neslēpa brīdinājumu. Tas ir viens no iemesliem, kāpēc ekrānuzņēmumi atbilstības mapēs uzkrājas ar arheoloģisko atradumu svinīgumu un ievērojami mazāku skaidrojošo spēku.

Fiksēts līgums ir bagātāks. Tas saista rezultātu ar apstākļiem, kādos sistēmai bija paredzēts darboties. Novērtējumam tas var ietvert precīzu testu kopu, ievaddatus vai aizsargātu atsauci uz tiem, paredzamās pārbaudes, modeļa un pakalpojuma konfigurāciju, attiecīgās politikas un rīku versijas, izpildes vidi, ja tā ietekmē rezultātu, un pieņemšanas noteikumu. Tiešās darbības gadījumā tas var ietvert pieprasījuma identitāti, autorizēto tvērumu, avota un izguves ierakstus, modeļa maršrutu, rīka izsaukumus, kontroles, cilvēka iejaukšanos un izrietošās stāvokļa izmaiņas. Mērķis nav fiksēt bezgalīgu dienasgrāmatu. Mērķis ir saglabāt pietiekami daudz cēloniski būtiskas informācijas, lai vēlāk varētu uzdot nopietnu jautājumu.

Šeit ir vērts veikt lietderīgu nošķīrumu. Novērtējuma fiksācija apliecina apgalvojumu par noteiktu testu vai vingrinājumu. Darbības ieraksts palīdz rekonstruēt konkrētu notikumu vai lēmumu. Laišanas ieraksts izskaidro, kāpēc organizācija ļāva sistēmai nonākt noteiktā maršrutā. Izmaiņu ieraksts izskaidro, kas vēlāk tika mainīts. Šie ieraksti pārklājas, taču tos nevajadzētu jaukt. Ražošanas žurnāla uzskatīšana par etalonu vai etalona uzskatīšana par ražošanas darbplūsmas pierādījumu ir efektīvs veids, kā likt katram ierakstam nest vairāk, nekā tas spēj izturēt.

AI akta prasība par žurnālu reģistrēšanu augsta riska sistēmām ir līdzīgi saistīta ar mērķi. 12. pants pieprasa automātisku attiecīgo notikumu reģistrēšanu visā sistēmas dzīves ciklā, ar žurnālu reģistrēšanas iespējām, kas atbilst paredzētajam mērķim. Regula attiecas uz sistēmas darbības izsekojamību, darbības uzraudzību un pēctirgus uzraudzību. Tā neprasa bezizšķirīgu reģistrēšanas paradumu. Tā prasa ierakstus ar konkrētu uzdevumu.

Šī frāze, ieraksti ar darbu, ir labāks ceļvedis nekā vispārīga prasība pēc novērojamības. Modeļa identifikators var palīdzēt atšķirt atjauninājumu. Ievaddatu izcelsme var izskaidrot pārsteidzošu ieteikumu. Noteikuma versija var izskaidrot, kāpēc rezultāts tika bloķēts. Pārskatītāja atzīme var izskaidrot, kāpēc operatīvā darbība atšķiras no modeļa priekšlikuma. Laika zīmogs var noteikt secību. Privātumu apzinošs dizains joprojām jautā, vai katrs lauks ir nepieciešams, samērīgs, saglabāts noteiktu laiku un aizsargāts no pašas sistēmas, kuru tas paredzēts pārbaudīt.

Atkārtojamībai ir divi godīgi veidi

Cilvēki bieži lieto vārdu atkārtojams, lai apzīmētu vairākas dažādas lietas. Šī neskaidrība ir saprotama. Komanda var domāt, ka tā var atkārtoti palaist fiksētu novērtējumu un iegūt tādu pašu rezultātu. Pētnieks var domāt, ka cita komanda var palaist norādīto metodi un pārbaudīt rezultātu. Operators var domāt, ka izmeklēšana var atjaunot stāvokli, kas izmantots konkrētam lēmumam. Klients var domāt, ka darbplūsma nodrošina konsekventu apstrādi, nevis patvaļīgi mainās no otrdienas uz ceturtdienu. Šie ir saistīti mērķi. Tie nav viena īpašība vairākos veidolos.

Pirmkārt, ir ierakstītās palaišanas atkārtojamība. Ja artefakts, konfigurācija, ievaddati, attiecīgais stāvoklis un izpildes apstākļi tiek turēti nemainīgi, atkārtojumam vajadzētu dot dokumentēto rezultātu sistēmas solīto apstākļu robežās. Dažas sistēmas var sniegt stingrāku determinisma apgalvojumu noteiktam izpildes ceļam. Citas paļaujas uz kontrolētu nejaušību, sadalītu infrastruktūru vai trešo pušu pakalpojumiem un var sniegt tikai šaurāku apgalvojumu. Atbildīga valoda ir konkrēta. Tā norāda, kas ir fiksēts, kas tiek mērīts, kādas variācijas joprojām iespējamas un kā tiek veikta salīdzināšana.

Otrkārt, ir novērtējuma argumenta atkārtojamība. Pārskatītājam jāspēj redzēt, kāpēc kopa atspoguļo apgalvojumu, vai rādītājam ir norādītā nozīme, vai pieņemšanas slieksnis ir pamatots un vai pierādījumi var pārnesties uz operatīvo kontekstu. To neatrisina kontrolsumma. Kontrolsumma var apliecināt, ka fails nav mainījies. Tā nevar apliecināt, ka fails pārbaudīja pareizo jautājumu, ka populācija bija atbilstoša vai ka rezultāts pamato ar to saistīto lēmumu.

Abiem veidiem vajadzētu satikties. Pilnīgi atkārtojams tests, kas mēra nepareizo lietu, joprojām ir nepareizs tests. Sarežģīts arguments, kas piesaistīts neatkārtojamai palaišanai, atstāj pārskatītājus nespējīgus atšķirt atradumu no veiksmīgas dienas. Noderīgais standarts nav abstrakta prasība pēc pilnīgas atkārtojamības. Tā ir redzama atbilstība starp apgalvojumu, metodi, ierakstītajiem apstākļiem, novēroto rezultātu un lietojumu, ko organizācija vēlas atļaut.

Komisijas norādījumi par vispārēja mērķa mākslīgā intelekta sniedzēju pienākumiem arī saglabā novērtējumu saistītu ar dokumentāciju un risku. Tie apraksta tehnisko dokumentāciju iestādēm un atsevišķu informāciju lejupstraumes sniedzējiem, tostarp iespējas, ierobežojumus un integrācijas informāciju. Vispārēja mērķa mākslīgā intelekta modeļiem ar sistēmisku risku 55. pants pieprasa novērtēšanu, izmantojot standartizētus protokolus un jaunākos rīkus, tostarp dokumentētu pretestības testēšanu, lai identificētu un mazinātu sistēmiskus riskus. Novērtējums, kas nevar pateikt, kas tika pārbaudīts, kādos apstākļos un ar kādiem ierobežojumiem, nekļūst noderīgāks tāpēc, ka to sauc par standartizētu.

Pierādījumiem ir derīguma termiņš

Evidence does not expire because someone has decided to be difficult. It expires when the conditions that allowed it to support a claim have changed enough that the connection can no longer be assumed. This is ordinary reasoning. A test of a bridge design does not automatically cover a different material. A food-safety check does not cover a new supplier by force of optimism. An evaluation of an AI route should not automatically cover a changed model, changed data boundary, changed tool authority or changed decision consequence.

The difficult work is deciding which changes matter. This is a matter for technical judgement, risk analysis and governance, not a single percentage written into a policy. A patch that changes a button colour may have no bearing on an evaluation. A change that makes a warning less visible may be material if the safety argument depends on a reviewer seeing it. Reindexing a source corpus may be harmless for one task and critical for another. A new model endpoint may preserve a broad capability while changing latency, refusal behaviour, language coverage or tool-use patterns that matter to the route.

Useful change control therefore begins with an impact question, not a release ritual. What claim could this change affect? Which assumption does it disturb? Which evidence was conditional on the old state? Does a bounded check answer the question, or does the route need a new evaluation and release decision? Who may make that call, and who can challenge it? The answers should be recorded because the next reviewer will otherwise have to infer them from ticket titles, folklore and a slight change in the font used by the release dashboard.

This is also where monitoring becomes part of the evidence rather than a separate observability hobby. Article 72 requires providers of high-risk AI systems to actively and systematically collect, document and analyse relevant data on performance throughout the system lifetime so they can evaluate continuous compliance. The post-market monitoring plan forms part of technical documentation. Monitoring is thus not merely a way to know whether the service is busy. It is a way to learn whether the conditions behind the original claim continue to hold.

Monitoring does not make every result self-explanatory. A rise in disagreement between reviewers and a system may have many causes. A change in source freshness might reflect a data-pipeline issue rather than model drift. A higher refusal rate could represent a safer policy, a broken integration or a new request population. The record should preserve enough context for a human investigation. Metrics are signals. They are not witnesses.

Evidence is valid in a defined context. A material change creates a question for review, not a loophole around review.

Material change needs a decision path

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.

Vissvarīgākais ir tas, ka jautājums maina pārmaiņu lomu. Pārmaiņas vairs nav apmulsums, ko dokumentācija cenšas noslēpt. Tās kļūst par pirmšķirīgu notikumu sistēmas pierādījumu modelī. Dažām pārmaiņām pietiks ar ierakstu. Dažas izraisīs testu. Dažas atkārtoti atvērs izlaišanas lēmumu. Disciplinēta organizācija šīs kategorijas nesajauc, un tai nav vajadzīgs nākotnes incidents, lai atklātu, ka tās pastāvēja.

Tātad jā: regulators var revidēt kustīgu mērķi. Revīzija sākas, atsakoties no viltus izvēles starp sastingušu modeļa karti un pilnīgi neizzināmu tiešsaistes pakalpojumu. Uztver stāvokli. Norādi apgalvojumu. Saglabā nosacījumus. Saisti pierādījumus ar lēmumu. Ieraksti, kas mainās. Pārvērtē, kad saikne vairs nav spēkā. Mērķis var kustēties. Pēdas paliek salasāmas.

Avoti