Tee, haigla ja modell jagavad ühte probleemi: tõendid

Ohutusolulised süsteemid ebaõnnestuvad erinevalt, kuid vajavad sama distsipliini: väide seotud kontekstiga, kontrollitavad tõendid, inimesed, kes võivad...

Tee, haigla ja modell jagavad ühte probleemi: tõendid

Tõendid peavad üleandmise üle elama

Teede projekteerija, haigla meeskond ja mudelipakkuja suudavad kõik veenva demonstratsiooni esitada. Ristmik võib plaanil korrapärane välja näha. Kliiniline ekraan võib töötoas rahulik tunduda. Mudel võib hoolikalt valitud näidiste hulga kohta mõistliku vastuse anda. Ükski neist ei lahenda küsimust, mis loeb, kui süsteem igapäevaellu jõuab: millised tõendid toetavad seda konkreetset tegevust nende inimeste jaoks nendes tingimustes ning kellel on õigus kurssi muuta, kui tõendid enam ei kehti?

See küsimus on kasulikum kui arutelu selle üle, kas tee, haigla või tehisintellekti süsteem on „ohutu". Ohutus ei ole omadus, mis saabub pappkastis koos seadmega. See on pidev suhe eesmärgi, keskkonna, inimeste rühma, süsteemi piirangute ja töö vahel, mis toimub siis, kui piiranguni jõutakse. Tee peab mahutama inimesi, kes teevad vigu, ja tingimusi, mis muutuvad. Kliiniline teenus peab säilitama otsustusvõime, kui teave on puudulik, kiireloomuline või vaidlustatud. Tehisintellekti süsteem peab jääma piisavalt arusaadavaks, et inimene näeks, millal selle väljund on lakanud olemast kasulik panus otsusesse.

Euroopal on osa sellest distsipliinist juba eri kohtades olemas. Teede infrastruktuuri eeskirjad nõuavad selliseid protseduure nagu mõjuhinnang, auditid, ohutuskontrollid ja võrguülene hindamine. Tehisintellekti määrus nõuab kõrge riskiga süsteemidelt elutsükli riskijuhtimist, tehnilist dokumentatsiooni, logisid, inimjärelevalvet, asjakohast täpsust, robustsust ja küberturvalisust. Euroopa tervishoiuasutused arutavad ohutust, õiglust, juhtimist, tööjõu valmisolekut ja vastutust koos, mitte ei kohtle kliinilist mudelit tarkvaratükina, mis muutub kahjutuks, sest selle liidesel onstetoskoobi pilt.

Ühine niit on tõendid. Mitte tõendid paksu kaustana, mis üks kord kokku pannakse, ja mitte tõendid meelitava keskmisega tulemustabelina. Tõendid kui midagi, mis on seotud väite, konteksti ja otsusega. Kasulik tõendite register ütleb, milleks süsteem pidi olema mõeldud, kus väide kehtib, millised vaatlused seda toetavad, millised eeldused selle all on, mis on endiselt ebakindel, kes saab sekkuda ja milline muutus tähendab, et argumenti tuleb uuesti kaaluda.

See on vähem glamuursem idee kui autonoomia. See on ka püsivam. See annab inseneridele võimaluse oma piiranguid välja öelda, teeseldes, et testikomplekt on täielik maailm. See annab juhtidele võimaluse küsida, mida nad tegelikult vastu võtavad. See annab operaatoritele midagi paremat kui juhtpaneel, mis süttib pärast seda, kui otsus on juba keeruliseks muutunud. Kõige tähtsam on see, et see annab süsteemist mõjutatud inimestele tee tulemuselt tagasi põhjuste ja tingimuste juurde, mis selle tulemuse tekitasid.

Kolm valdkonda, üks ebamugav küsimus

Tee, haigla ja mudel ei ole sama süsteem. Nende kahjud, õiguslikud kohustused, tõendusbaasid ja professionaalsed kultuurid erinevad. Keegi ei peaks kopeerima teeauditit kliinilisse töövoogu ega kleepima meditsiiniseadme kontrollnimekirja keelemudelile ja nimetama tööd tehtuks. Mõte ei ole erinevusi lamedaks teha. Mõte on märgata ühist inseneriprobleemi: automatiseeritud või poolautomatiseeritud süsteem tegutseb suurema inimeste, protseduuride, liideste, keskkondade ja eelduste koosluse kaudu.

Tee on eriti selge meeldetuletus, sest see ei tee otsuseid inimese mõistes. See kujundab neid. Geomeetria, vaatejooned, eraldus, ülekäigukohad, märgistus, kiiruse ohjamine, hooldus ja ümbritsev võrgustik mõjutavad seda, mida inimesed näevad, millest nad suudavad taastuda ja kui tõsiseks viga kujuneb. Hea liiklusohutuse tava ei sõltu fantaasiast püsivalt erksast ja täiuslikult informeeritud liiklejast. See püüab muuta ettenähtavaid vigu vähem tõenäoliseks ja vähem karistavaks. Euroopa raamistik teede infrastruktuuri ohutuse juhtimiseks peegeldab seda süsteemset vaadet korduvate hindamis- ja kontrolliprotsesside kaudu, mitte ühekordse kinnitusena, et tee on heaks kiidetud.

Haigla on erinev, kuid ka see elab koos lõhega puhta kirjelduse ja muutuva tegelikkuse vahel. Kliinilisel rajal on personali rollid, üleandmised, dokumendid, seadmed, prioriteedid, katkestused ja inimene, kelle seisund ei pruugi sarnaneda keskmise juhtumiga, mis protokolli kujundas. Soovitus võib olla kasulik ja siiski ebapiisav. Hoiatus võib olla tehniliselt õige ja siiski jõuda hetkel, mil selle järgi ei saa ohutult tegutseda. Süsteem võib parandada üht osa töövoost, luues samal ajal uue koormuse kusagil mujal. Seetõttu ei saa arutelu tehisintellekti üle tervishoius peatuda mudeli näilisel jõudlusel. See peab hõlmama juhtimist, kliinilist vastutust, andmete kvaliteeti, koolitust, avalikku usaldust ja vahendeid kahju tuvastamiseks ja parandamiseks.

Mudel asub samasuguses korralduses. See on kusagil treenitud või seadistatud, ühendatud andmetega kusagil mujal, saab inimeselt päringu või ülesande, paigutatud liidese taha, mõne inimese poolt jälgitud ja teiste poolt mitte. See toodab väljundi, kuid väljund muutub tagajärgedega alles siis, kui keegi käsitleb seda tegutsemise põhjusena. Väljundi ja tegevuse vahel on läved, volitused, ajasurve, juurdepääs lähtematerjalile, koolitus, stiimulid ja eriarvamuse võimalus. Need ei ole dekoratiivsed tegevuslikud üksikasjad. Need otsustavad, kas tehniliselt pädev komponent jääb suurema süsteemi ohutuks osaks.

Käsitlege järgnevat kui selgesõnaliselt hüpoteetilist kooslust, mitte kirjeldust tegelikust teest, haiglast, patsiendist, töötajast või juhtumist. Kohalik omavalitsus kaalub süsteemi, mis märgistab asukohti liiklusohutuse ülevaatuseks. Haigla kaalub tööriista, mis aitab haldusdokumente sorteerida enne, kui kliiniline personal neid näeb. Kolmas organisatsioon kaalub mudelit, mis koostab riskikokkuvõtte infrastruktuurihaldurile. Igas olukorras näitab varajane demonstratsioon, et süsteem suudab leida mustreid olemasolevatest andmetest. Demonstratsioon ei vasta veel sellele, kas andmed esindavad tingimusi, mida teenus järgmisel kuul näeb, kas ebatavalist juhtumit suudetakse ära tunda, kas soovituse saajatel on piisavalt aega ja volitusi seda kahtluse alla seada või kas organisatsioon märkab kahjulikku mustrit enne, kui see muutub tavapäraseks tööks. Tõendusmaterjali probleem algab täpselt seal.

Lihtne viga on küsida ühte numbrit. Mis on täpsus? Kui palju aega see säästab? Kui palju riske see tabab? Need küsimused on õigustatud, kuid mittetäielikud. Numbril on vaja nimetajat, valimit, määratlust, kuupäeva, kavandatud kasutust ja avaldust selle kohta, mis välja jäeti. Samuti on vaja seost järgmise otsusega. Kõrge skoor kitsa ja stabiilse ülesande puhul võib toetada kitsast ja stabiilset väidet. See ei saa vaikimisi lubada teistsugust töövoogu, teistsugust sihtrühma ega otsust, millel on teistsugune tagajärg.

Tõendusmaterjal ei ole dekoratiivne lisa

Evidence becomes useful when it can change somebody's mind. That sounds obvious, but many evidence packs are built to look complete rather than to make a decision challengeable. They contain screenshots, policy statements, test summaries and signatures, but do not show which claim each item supports, which condition limits the claim, or what should happen if the condition changes. The result is paperwork with a ceremonial role. It can prove that a meeting occurred. It cannot necessarily tell an operator what to do at 07:40 when the service is busy, the data is late and a recommendation does not fit the case in front of them.

A better starting point is a named decision. Not “deploy AI responsibly” and not “improve road safety”, but a proposition with a boundary. For example: this system may prioritise a defined class of review work, in a specified operational context, while a named role remains responsible for accepting or rejecting the recommendation. Or: this design may be opened to traffic after the identified hazards have been assessed through the required process and the identified controls are in place. The wording is deliberately less exciting than a product announcement. It is a contract with reality.

Once the decision is named, the rest of the record has somewhere to attach. The intended purpose tells a reader what not to infer. The context tells them which site, workflow, users, data, equipment and surrounding process matter. Evidence records tests, observations, source material, reviews and exercises. Assumptions make dependencies visible: perhaps an operator has training, perhaps a source register is current, perhaps a particular alert reaches a particular role in time. The owner identifies who may interpret the material and intervene. Review triggers say which signal, change or failure of an assumption requires another look.

Evidence becomes operational when a reader can trace a claim to its conditions, authority and review route.

This structure has an important consequence. It stops evidence from drifting away from use. A test is not just filed under “validation”. It is connected to a claim about a particular behaviour under stated conditions. An audit is not just proof that an auditor visited. It becomes a record of what was examined, what was found, what remained uncertain and which authority decided what happened next. A model evaluation is not a general badge. It is a bounded observation whose relevance depends on the model version, task, data, configuration and deployment conditions.

The same record should make absence visible. If nobody has tested a system with an uncommon but consequential input, that is not a small embarrassment to hide beneath an average. It is an evidence boundary. If a human can technically override a recommendation but has no time, access or authority to do so in the real workflow, that is not meaningful oversight. It is a design gap. If a road safety inspection notices a recurring condition but no organisation owns the remedial work, the observation has not yet become a control. In serious systems, missing evidence is a result. It tells the organisation where it cannot yet make a claim.

Road safety offers a practical lesson in humility

Road safety has spent decades learning that harm is rarely explained by a single bad actor or a single bad component. The person driving too quickly, the crossing that is hard to read, the vehicle, weather, lighting, maintenance state, traffic mix and emergency response may all matter. That does not dissolve individual responsibility. It does prevent the shallow conclusion that every failure can be fixed by telling people to pay more attention. A system that only works when nobody makes a foreseeable mistake is not an impressively strict system. It is a fragile one.

The EU's road-infrastructure safety-management rules provide a useful counterweight to the idea that approval is a one-off event. They organise safety work around procedures that look at prospective consequences, design, operation and the existing network. The exact legal scope matters, and the rules should be read as road-infrastructure law rather than a general template for every technology. Still, their underlying habit is broadly valuable: inspect the system in the conditions in which it will operate, look for patterns rather than waiting for a dramatic event, and treat knowledge as a reason to adjust the arrangement.

That habit is not simply “collect more data”. Data without a question is a very efficient way of storing confusion. The road-safety question might concern where a crossing creates a conflict, which people are exposed to it, how often the conditions occur, what kind of mistake is foreseeable, which physical or operational measures reduce the risk, and how the organisation will know whether the measure has changed the situation. The evidence that matters is therefore mixed. It includes traffic conditions, design records, inspection observations, maintenance information, reports of harm and professional judgement. A map alone cannot carry the claim. Neither can a single collision statistic.

There is a useful human-factors point here. The system has to be designed for people as they are, not for a fictional user who reads every sign, judges every speed perfectly and never arrives distracted, tired, inexperienced, rushed, ill or simply surprised. That is not an excuse for careless behaviour. It is an acknowledgement that safety engineering has to work in the space between intention and actual human capability. When a system relies on a person to notice, understand and act, those three steps need evidence of their own. Can the signal be seen? Can its meaning be understood? Can the person act in time and with enough authority?

AI teams often miss this because the human is represented as a box at the end of a flow diagram. The box says “reviewer”, “operator” or “human in the loop” and therefore appears to solve the problem. But a role name does not describe an interaction. A useful review design needs to say what the person sees, what they do not see, what evidence they can inspect, whether they can request another route, when they are expected to disagree, what happens after disagreement and how the organisation learns from it. These questions are as ordinary as checking whether a crossing can be used safely in rain or darkness. They are also much more informative than a promise that a person remains involved.

Haigla ei suuda ebakindlust kõrvaldada

Tervishoid muudab tõendusmaterjali probleemi eriti nähtavaks, sest tagajärjed on isiklikud ja keskkond on keeruline. Kasulik kliiniline või haldussüsteem võib aidata töötajatel teavet leida, korduvat tööd vähendada, võimalikku mustrit märgata või materjali ülevaatamiseks ette valmistada. See ei muuda seda kliiniliseks autoriteediks. Üleminek teabest ravile, prioriseerimisele või ravi keelamisele kannab kohustusi, mida ei saa delegeerida kasutajaliidesele. Ravi eest vastutav isik peab teadma, mida süsteem tegi, mida ta ei teinud ja kuidas reageerida, kui tulemus on vastuolus juhtumi kohta kättesaadavate faktidega.

WHO/Europe'i töö tehisintellekti kohta tervishoius raamib seda küsimust sõnavaraga, mida see väärib: ohutus, tõhusus, õiglus, inimõigused, läbipaistvus, vastutus, juhtimine ja tööjõu valmisolek. Asi pole selles, et iga kliiniline töötaja peaks saama masinõppe spetsialistiks. Asi on selles, et süsteemi ei saa vastutustundlikult kasutada, kui inimestel, kellelt oodatakse sellele tuginemist, selle järelevalvet või selle vaidlustamist, puudub kasutatav ülevaade selle piirangutest. Koolitus on osa kontrollikeskkonnast. Samuti on eskaleerimisteed, vastutuskorraldus, tõendid tegeliku toimimise kohta ja võimalus patsientidel ning spetsialistidel muret tõstatada ilma, et nad peaksid esmalt tehnoloogia ekspertideks saama.

Euroopa Komisjon paigutab samamoodi tehisintellekti tervishoius laiemasse regulatiivsesse ja operatiivsesse raamistikku. Selle rahvatervise materjal märgib, et meditsiiniliseks otstarbeks mõeldud tehisintellekti tarkvara võib kuuluda AI-määruse kõrge riskiga nõuete alla, sealhulgas riskide maandamine, andmekvaliteet, kasutajate teavitamine ja inimjärelevalve. See ei väida, et iga haiglas kasutatav tööriist saab sama õigusliku klassifikatsiooni. See on meeldetuletus, et sõna „tervis" ei pehmenda vajadust hoolika sihtotstarbe analüüsi järele. Mida olulisem on kasutus, seda vähem usutav on tugineda laiadele kinnitustele.

Kliiniline praktika näitab ka, miks peaksid sekkumisläved olema selgesõnalised. Süsteemile võib lubada allika hankimist, kokkuvõtte koostamist, puuduva välja märkimist või ettepanekut, et juhtum väärib tähelepanu. Need on erinevad teod. Igaüks neist liigub teabest veidi edasi mõjutamise suunas. Mingil hetkel võib süsteemil lubada teha piiratud operatiivne samm, võib-olla reeglitega, mis piiravad ulatust, ja logiga, mis muudab sammu pöörduvaks. Pärast seda punkti võidakse seda paluda tegutseda ilma samaaegse inimese otsuseta. Tõendid, volitused ja taastamiskavand, mida neil tasanditel vajatakse, ei ole omavahel asendatavad.

See ei muuda automatiseerimist võimatuks. See muudab väited proportsionaalseks. Organisatsioon saab valida tagasihoidliku, hästi piiritletud ülesande ja muuta selle usaldusväärseks enne, kui kujutab ette laiaulatuslikku. See võib hoida lähtematerjali kättesaadavana, mitte muuta kokkuvõtet ainsaks dokumendiks. See võib anda kliinikule või muule vastutavale töötajale tõelise võimaluse süsteem peatada, mitte teoreetilise nupu, mis on peidetud poliitika käsiraamatusse. See võib jälgida, mis juhtub pärast kasutuselevõttu, ja käsitleda ootamatut käitumist tõendina, et esialgne argument vajab läbivaatamist. See on aeglasem kui kuulutamine, et mudel on ohjad üle võtnud. See on üldiselt kiirem kui otsuse rekonstrueerimine pärast seda, kui usaldus on juba kaotatud.

Mudel ei ole kogu süsteem

The AI Act is valuable here because it refuses, in its high-risk provisions, to treat the model as the only relevant object. Article 9 sets out a documented, maintained and continuous iterative risk-management process. Article 10 concerns data and data governance. Article 11 and Annex IV address technical documentation. Article 12 addresses automatic recording of relevant events. Article 14 addresses effective human oversight, including the ability to understand relevant limits, override or reverse output where appropriate, and stop the system safely. Article 15 concerns accuracy, robustness and cybersecurity. These are not interchangeable paperwork categories. Together they point at a system that has to be understood across its lifecycle.

The law does not make a technical judgement for every organisation. It does not announce that a given performance measure is enough, nor does it make an operator competent by naming them in a document. It does something more demanding. It requires a way of connecting intended purpose, risk, documentation, records, human oversight and ongoing monitoring. That connection is precisely what gets lost when an AI project is described as a model acquisition rather than an operational change.

Take the commonplace claim that a human can override the model. Override what, exactly? A probability, a ranking, a generated paragraph, a routing decision, an automatic notification, a resource allocation or a physical action? Before or after it takes effect? With which information? Under which time constraint? Does the human see why the system reached the output, or merely that it did? Are there consequences for disagreeing? Is the disagreement recorded? Is it reviewed as a possible model, data or workflow problem? A truthful answer to these questions is more reassuring than a glossy assurance because it describes a control that can actually be exercised.

Human oversight is sometimes treated as a moral accessory: add a person to the process and the system becomes humane. It is better understood as an engineering relationship. The person needs a meaningful opportunity to detect a limitation, the authority to intervene, an action that changes the outcome, and a system state that remains safe when the intervention happens. A powerless reviewer is a witness. A reviewer who only sees an output after it has become irreversible is an auditor of a decision already made. Neither arrangement is equivalent to oversight.

Evidence should therefore grow as discretion and irreversibility grow. A retrieval tool that helps a professional find source material has one kind of evidence burden. A system that ranks work for attention has another, because ranking shapes what may be seen late or not at all. A constrained system that automatically performs an operational task needs clear boundaries, monitoring and a recovery route. A system that acts without a live decision needs the strictest case: a narrow purpose, evidence for the operating context, fail-safe behaviour, independent challenge where appropriate, clear ownership and continuing review. The designation is less important than the principle. More autonomy is a larger claim, not a marketing upgrade.

Kui automatiseeritud süsteem liigub inimese teavitamiselt iseseisva tegutsemiseni, peavad tõendusmaterjali, sekkumise ja taastamise nõuded muutuma tugevamaks, mitte nõrgemaks.

Lävendid hoiavad ära selle, et kasulik tööriist muutub kellegi vastutuseta otsuseks

Sekkumislävend on praktiline vastus praktilisele küsimusele: millal on süsteemil lubatud midagi teha ja millal peab ta asja inimesele tagasi andma? See peaks olema nähtav enne kasutuselevõttu, mitte avastatud kaebuse kaudu. Lävend võib sõltuda usaldusväärsusest, kuid üksi usaldusväärsusest ei piisa. See võib sõltuda otsuse tüübist, vea tagajärgedest, andmete kvaliteedist ja värskusest, vastuoluliste tõendite olemasolust, pädeva inimese kättesaadavusest, taastumisvõimest ja sellest, kuivõrd juhtum jääb seatud eesmärgi piiresse.

Lävendid ei ole tõestus, et süsteem on ohutu. Need on viis takistada süsteemil nõudmast rohkem volitusi, kui selle tõendusmaterjal toetab. Mudel võib olla võimeline kirjet kokku võtma, kuid mitte hindama selle täielikkust. See võib tuvastada mõiste, kuid mitte määrata selle õiguslikku tähendust. See võib koostada usutava selgituse, kuid mitte tõestada selle selgituse tõepärasust. See võib ära tunda rutiinse mustri ja olla siiski sobimatu erakorraliste juhtumite, vastuoluliste allikate või olukordade puhul, kus väikest viga oleks raske tagasi pöörata. Lävend on koht, kus organisatsioon muudab need eristused käitumiseks.

Teedeameti puhul võib lävend öelda, et kontrolli tulemuste ja määratletud riskinäitajate kombinatsioon viib ametliku läbivaatamiseni, samas kui teistsugune kombinatsioon nõuab kiireloomulist ajutist meedet. Täpsed kriteeriumid kuuluvad asjakohasesse õiguslikku ja professionaalsesse raamistikku. Ülekantav mõte on see, et tee vaatlusest sekkumiseni ei tohiks sõltuda ainult sellest, kes juhtumisi valves on või milline mure koosolekul kõige eredamalt meelde jääb. Tõendusmaterjal ei asenda professionaalset hinnangut. See annab hinnangule ühise arvestuse ja korratava tee.

Haigla puhul võib lävend eristada tööriista, mis valmistab materjali läbivaatamiseks ette, ja süsteemi, mis suudab teha piiratud haldustoimingu. Viimane vajab selget arvestust oma ulatuse kohta, viisi erandi tuvastamiseks, nimetatud vastutajat erandi jaoks ja viisi eelmise oleku taastamiseks, kui toiming oli vale. Kui süsteem puudutab kliiniliselt olulist otsust, peab lävend arvestama asjakohaste kliiniliste, õiguslike ja professionaalsete kohustustega. Vastutavalt isikult ei tohi nõuda läbipaistmatu automatiseerimistulemuse parandamist ilma allikajäljeta ja ilma ajata seda kontrollida.

Infrastruktuuri AI-süsteemi puhul võib läviväärtus eristada prognoosi juhtimistoimingust. Prognoos võib operaatorit hoiatada tingimusest, mida tasub kontrollida. Juhtimistoiming võib muuta füüsilist või operatiivset olekut. Teine väide nõuab palju põhjalikumat selgitust sisendi kvaliteedi, süsteemi piirangute, keskkonnatingimuste, seire, volituste, varumehhanismide ja taastumise kohta. See ei ole bürokraatia, mis on toodud inseneride takistamiseks. See on insenertehniline kirjeldus sellest, mis juhtub, kui eksimise hind ei ole pettumust valmistav vastus vestlusaknas.

Kõige kasulikum läviväärtus on sageli keeldumislävi. Mis peaks panema süsteemi tegutsemisest loobuma? Milline puuduv sisend, konflikt, hilinenud kanne, jaotusest väljas tingimus, kättesaamatu ülevaataja või testimata muudatus peaks käivitama ohutu peatuse? Organisatsioonid kipuvad kirjeldama, mida nad loodavad oma süsteemi tegevat. Nad on vähem valmis kirja panema, millal see peab peatuma. Ometi näitab süsteemi peatumiskäitumine sageli selle küpsusastet rohkem kui selle esitluskäitumine. Oskus öelda „see juhtum on väljaspool tõendusmaterjali" ei ole puudus. See on tõend, et piir on olemas.

Inimtegurid on osa tõendusmaterjalist, mitte joonealune märkus

Inimtegureid taandatakse mõnikord tähelepanekule, et inimesed on ekslikud. See on tõsi, kuid üksi ei ole see eriti kasulik. Insenertehniline küsimus on see, kuidas töö on korraldatud tegeliku inimese tähelepanu, mälu, taju, töökoormuse, suhtluse ja volituste ümber. Hoiatus, mida ei saa märgata, ei ole hoiatus. Keeruline selgitus, mida ajasurve all ei mõisteta, ei ole tähenduslik läbipaistvus. Peatumisjuhtimine, mis vajab kättesaamatu inimese heakskiitu, ei ole peatumisjuhtimine. Ülevaatusekraan, mis peidab aluseks oleva kirje, ei ole tõendusmaterjali pind.

Tee projekteerimine teeb selle konkreetseks. Inimesed liiguvad füüsilises keskkonnas, kus on piiratud aeg näha, tõlgendada ja tegutseda. Süsteemi ei saa hinnata ainult selle kavandatud signaale kirjeldades. Seda tuleb hinnata, arvestades, kas asjaomased inimesed suudavad neid tegelikus keskkonnas kasutada. Tervishoid esitab sama punkti teises registris. Hoiatuse või soovituse lugejat võidakse katkestada, tal võivad olla konkureerivad prioriteedid, ta võib asendada kolleegi või seista silmitsi juhtumiga, mis protsessiga hästi ei klapi. AI lisab veel ühe kihi, sest sujuv väljund võib luua vale mulje, et süsteem on kaalunud tõendusmaterjali, mida see on lihtsalt korranud.

Vastus ei ole nõuda üliinimlikku keskendumist. Vastus on üleandmise kavandamine ja testimine. Mida süsteem kõigepealt näitab? Millist allikat saab inimene kontrollida? Kuidas väljendab see ebakindlust? Kas inimene saab küsida teistsugust teed? Kas liides eristab kinnitatud kirjet järeldusest? Kas nad saavad aru, kas mudel, andmeallikas, reegel või konfiguratsioon muutus? Mis juhtub tagasisidega? Need on empiirilised ja organisatsioonilised küsimused. Need väärivad harjutusi, vaatlust, kasutajauuringuid ja pärast kasutuselevõttu tehtavat ülevaadet, mitte ainult kinnitust, et liides on kavandatud kasutajat silmas pidades.

Vastutustundlik tõendusmaterjali register peaks jäädvustama inimeste korralduse, muutumata üksikute töötajate toimikuks. See võib registreerida rolli, volitused, koolitusnõude, oodatava sekkumise, saadaoleva aja, teabepinna, eskaleerimistee ja harjutuse tulemuse. See võib registreerida, et protsessi testiti kindlaksmääratud stsenaariumi alusel, teeskluseta, et stsenaarium tõestab iga tulevast tingimust. See võib säilitada otsuste jälje, kasutamata seiret ettekäändena tarbetuks järelevalveks. Need tasakaalud on keerulised. Neid on siiski parem käsitleda avalikult kui jätta ebamäärasele juhisele, et inimesed peaksid „kasutama oma otsustusvõimet".

The Dutch instinct for making complicated systems legible has a useful place here. A cycling junction, a public register or a well-labelled process does not become good merely because it is clear, but clarity lets people see where responsibility sits. Good governance has a similar modesty. It does not promise that no difficult judgement will arise. It makes the route for difficult judgement visible before the day it is needed. There is no ribbon-cutting ceremony for a well-defined escalation path, which is perhaps why it is so often left until later.

Evidence has a shelf life

The hardest part of evidence-led work is accepting that yesterday's evidence may be accurate and still no longer be sufficient. A model changes. A data source changes. A supplier changes a component. A workflow is reorganised. A new group of people uses the service. A road is altered, maintained differently or exposed to a different traffic pattern. A hospital changes staffing, software, triage arrangements or records. The original test might remain valid as a historical observation, but the claim built on it may need a different boundary.

This is why version history is not an administrative nicety. A reader who cannot identify which version of a model, configuration, data source, policy or interface produced an output cannot reconstruct the conditions of the decision. A team that does not record material changes cannot distinguish a new problem from an old one. An organisation that treats release as the end of assurance will eventually have to rediscover why its confidence was justified, at precisely the moment when the answer matters most.

Post-market monitoring under the AI Act recognises this lifecycle reality for high-risk systems. The requirement is not a promise that monitoring eliminates uncertainty. It is an acknowledgement that information arrives after deployment and must have a route back into risk management. The equivalent lesson in road safety is familiar: systems should be inspected and assessed as they operate, rather than assumed to remain safe because they once met a design requirement. In health, real-world use, workforce experience, patient impact and governance arrangements matter alongside any pre-deployment assessment.

A review trigger should be specific enough to be used. “Review periodically” is a polite way of asking future colleagues to guess. A better trigger names the material event: a new model version, a change to an input source, a new deployment location, a changed user group, an unresolved discrepancy, a complaint pattern, a safety signal, an inability to perform an oversight step, or a change in the authority that owns the decision. The list will be different for every system. What matters is that the original argument names the conditions that could make it stale.

This also changes the meaning of an audit trail. An audit trail should not be a warehouse full of events that nobody can interpret. It should be a route through the system's history. Which claim was in force? Which evidence supported it at the time? Which version made the output? Which person or role took the consequential action? What happened when the system was challenged? Which issue was resolved, and which remained open? The record should be proportionate. It should also be capable of answering a real question without requiring a heroic archaeological expedition through application logs.

What a serious evidence question sounds like

When an organisation evaluates a safety-critical system, the useful question is rarely “does it work?”. Work for whom, to what end, under which conditions, compared with what, and with what consequence if it fails? Those questions can feel slow because they prevent an easy yes. They are also the questions that make a later yes worth something.

Hea ülevaade küsib seega pigem ahelat kui kogumit. See palub meeskonnal nimetada kavandatud eesmärk ja otsus, mis sellele järgneb. See küsib, millised kahjud ja rikkerežiimid on asjakohased. See küsib, millised tõendid toetavad iga olulist väidet ja mida need tõendid ei näita. See küsib, millised eeldused peavad tõeseks jääma. See küsib, kellel on volitus järelevalveks, ülekirjutamiseks, peatamiseks ja parandamiseks. See küsib, kuidas süsteem käitub, kui tõendid puuduvad või juhtum jääb ulatusest välja. See küsib, mida pärast kasutuselevõttu jälgitakse ja milline muutus käivitab uuesti hindamise.

Pole olemas universaalset skoori, mis selle harjutuse lõpetaks. Teel on üks kontekst, haiglas teine, mudelil jälle kolmas. Hästi kavandatud väikesel süsteemil võib olla tugevam tõendusbaas kui laial süsteemil, mida on kirjeldatud suurema enesekindlusega. Kitsas väide selge piiriga ei ole nõrk väide. See on ausa väite algus.

Seetõttu kirjeldavad meie teaduslehed ka selgesõnalisi küsimusi, tõendite piire ja juurdepääsu staatust, mitte ei esitle teadusmaterjali vaikimisi valmis võimekusena. Meetod on tagasihoidlik: tuvasta küsimus, tee tõendite piir nähtavaks ja hoia avaldamisstaatus loetav. See ei tõesta, et toode sobib konkreetseks kasutuselevõtuks, ega asenda sektoripõhist kindlustust. Sellegipoolest on see kasulik harjumus. Kui organisatsioon ei suuda öelda, mida tema tõendid toetavad, mida need ei toeta ja kes võib neid vaidlustada, pole ta veel tugevamat väidet välja teeninud.

Teel, haiglas ja mudelil on siiski üks ühine probleem. Igaüks neist vajab viisi, kuidas muuta teadmine tegudeks, varjamata tingimusi, mille korral see tegu on õigustatud. Vastus ei ole tseremoniaalne fail, keskmine skoor ega nupp pealkirjaga inimese järelevalve. See on tõenduspraktika, mis jääb seotuks eesmärgi, inimeste, volituste ja muutustega. See töö ei ole glamuurne. Nii muutub süsteem vastutavaks enne, kui see peab muutuma selgitavaks.

Allikad