Kelias, ligoninė ir modelis turi vieną bendrą problemą

Saugai kritinės sistemos žlunga skirtingai, bet joms reikia tos pačios disciplinos: teiginio, susieto su kontekstu, patikrinamų įrodymų, žmonių, galinčių...

Kelias, ligoninė ir modelis turi vieną bendrą problemą: įrodymai

Įrodymai turi išlikti perduodant atsakomybę

Kelių projektuotojas, ligoninės komanda ir modelio teikėjas gali sukurti įtikinamą demonstraciją. Sankryža plane gali atrodyti tvarkinga. Klinikinis ekranas dirbtuvėse gali atrodyti ramus. Modelis gali pateikti protingą atsakymą kruopščiai parinktam pavyzdžių rinkiniui. Nė vienas iš šių dalykų neišsprendžia klausimo, kuris tampa svarbus sistemai pradėjus veikti kasdieniame gyvenime: kokie įrodymai pagrindžia šį konkretų veiksmą, šiems žmonėms, tokiomis sąlygomis, ir kas turi teisę pakeisti kryptį, kai įrodymai nebegalioja?

Tas klausimas naudingesnis nei diskusija, ar kelias, ligoninė ar dirbtinio intelekto sistema yra „saugi“. Sauga nėra savybė, kuri atkeliauja kartoninėje dėžėje kartu su įrenginiu. Tai nuolatinis ryšys tarp tikslo, aplinkos, žmonių grupės, sistemos ribų ir darbo, kuris atliekamas pasiekus ribą. Kelias turi prisitaikyti prie žmonių, kurie daro klaidų, ir besikeičiančių sąlygų. Klinikinė paslauga turi išsaugoti sprendimo laisvę, kai informacija yra neišsami, skubi ar ginčijama. Dirbtinio intelekto sistema turi išlikti pakankamai suprantama, kad žmogus galėtų pastebėti, kada jos rezultatas nustojo būti naudingas indėlis į sprendimą.

Europa jau turi šios disciplinos dalių įvairiose vietose. Kelių infrastruktūros taisyklės reikalauja procedūrų, tokių kaip poveikio vertinimas, auditai, saugos patikros ir viso tinklo vertinimas. Dirbtinio intelekto aktas reikalauja, kad didelės rizikos sistemos naudotų viso gyvavimo ciklo rizikos valdymą, techninę dokumentaciją, žurnalus, žmogiškąją priežiūrą, tinkamą tikslumą, patikimumą ir kibernetinį saugumą. Europos sveikatos institucijos saugą, teisingumą, valdymą, darbo jėgos pasirengimą ir atskaitomybę aptaria kartu, o ne traktuoja klinikinį modelį kaip programinę įrangą, kuri tampa nekenksminga vien todėl, kad jos sąsajoje pavaizduotas stetoskopas.

Bendras siūlas yra įrodymai. Ne įrodymai kaip storas aplankas, surinktas vieną kartą, ir ne įrodymai kaip rezultatų lenta su maloniu vidurkiu. Įrodymai kaip kažkas, kas pririšta prie teiginio, konteksto ir sprendimo. Naudingas įrodymų įrašas nurodo, ką sistema turėjo daryti, kur teiginys galioja, kurie stebėjimai jį pagrindžia, kokios prielaidos slypi po juo, kas dar neaišku, kas gali įsikišti ir koks pokytis reiškia, kad argumentą reikia persvarstyti.

Tai mažiau patraukli idėja nei autonomija. Ji taip pat patvaresnė. Ji suteikia inžinieriams būdą įvardyti savo ribas neapsimetant, kad testų rinkinys yra visas pasaulis. Ji suteikia vadovams būdą paklausti, ką jie iš tikrųjų priima. Ji suteikia operatoriams ką nors geresnio nei skydelis, kuris įsižiebia jau po to, kai sprendimas tapo sudėtingas. Svarbiausia, ji suteikia sistemos paveiktiems žmonėms kelią nuo rezultato atgal prie priežasčių ir sąlygų, kurios jį sukūrė.

Trys sritys, vienas nepatogus klausimas

Kelias, ligoninė ir modelis nėra ta pati sistema. Jų žala, teisinės pareigos, įrodymų bazės ir profesinės kultūros skiriasi. Niekas neturėtų kopijuoti kelių audito į klinikinį darbo srautą arba įklijuoti medicinos prietaisų kontrolinio sąrašo į kalbos modelį ir vadinti darbą baigtu. Esmė ne išlyginti skirtumus. Esmė pastebėti bendrą inžinerinę problemą: automatizuota ar pusiau automatizuota sistema veikia per didesnį žmonių, procedūrų, sąsajų, aplinkų ir prielaidų išdėstymą.

A road is an especially clear reminder because it does not make decisions in the human sense. It shapes them. Geometry, sight lines, separation, crossings, markings, speed management, maintenance and the surrounding network influence what people can see, what they can recover from and how severe a mistake becomes. Good road safety practice does not depend on the fantasy of a permanently alert, perfectly informed road user. It tries to make foreseeable mistakes less likely and less punishing. The European framework for road infrastructure safety management reflects that systems view through repeatable assessment and inspection processes rather than a single declaration that a route has been approved.

A hospital is different, but it also lives with the gap between a clean description and a changing reality. A clinical pathway has staff roles, handovers, records, equipment, priorities, interruptions and a person whose condition may not resemble the average case that shaped a protocol. A recommendation can be useful and still be insufficient. A warning can be technically correct and still arrive at a moment when it cannot safely be acted on. A system may improve one part of a workflow while creating a new burden somewhere else. That is why the discussion of AI in health cannot stop at a model's apparent performance. It has to include governance, clinical responsibility, data quality, training, public confidence and the means to identify and correct harm.

A model sits inside the same kind of arrangement. It is trained or configured somewhere, connected to data somewhere else, given a prompt or a task by a person, placed behind an interface, watched by some people and not watched by others. It produces an output, but the output becomes consequential only when somebody treats it as a reason to act. Between output and action sit thresholds, authority, time pressure, access to source material, training, incentives and the possibility of dissent. Those are not decorative operational details. They decide whether a technically competent component remains a safe component of the larger system.

Consider the following as an explicitly hypothetical composite, not an account of a real road, hospital, patient, employee or incident. A local authority is considering a system that flags locations for a road-safety review. A hospital is considering a tool that helps sort administrative documents before clinical staff see them. A third organisation is considering a model that drafts a risk summary for an infrastructure manager. In each setting, an early demonstration shows that the system can find patterns in existing records. The demonstration does not yet answer whether the records represent the conditions the service will see next month, whether an unusual case can be recognised, whether the people receiving a recommendation have enough time and authority to question it, or whether the organisation will notice a harmful pattern before it becomes normal work. The evidence problem begins exactly there.

The easy error is to ask for a single number. What is the accuracy? How much time will it save? How many risks will it catch? Those questions are legitimate but incomplete. A number needs a denominator, a sample, a definition, a date, an intended use and a statement of what was excluded. It also needs a relationship to the next decision. A high score on a narrow, stable task can support a narrow, stable claim. It cannot silently authorise a different workflow, a different population or a decision with a different consequence.

Evidence is not a decorative attachment

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.

Ligoninė negali išsklaidyti neapibrėžtumo

Sveikatos priežiūra ypač išryškina įrodymų problemą, nes pasekmės yra asmeninės, o aplinka sudėtinga. Naudinga klinikinė ar administracinė sistema gali padėti darbuotojams rasti informaciją, sumažinti pasikartojančio darbo kiekį, pastebėti galimą modelį ar parengti medžiagą peržiūrai. Tai dar nepaverčia jos klinikiniu autoritetu. Perėjimas nuo informacijos prie gydymo, prioritetų nustatymo ar priežiūros atsisakymo yra susijęs su pareigomis, kurių negalima perkelti sąsajai. Už priežiūrą atsakingas asmuo turi žinoti, ką sistema padarė, ko nepadarė ir kaip reaguoti, kai rezultatas prieštarauja byloje turimiems faktams.

PSO Europos regiono biuro darbas dėl dirbtinio intelekto sveikatos priežiūroje šį klausimą apibrėžia jam derama kalba: sauga, veiksmingumas, teisingumas, žmogaus teisės, skaidrumas, atskaitomybė, valdymas ir darbo jėgos pasirengimas. Esmė ne ta, kad kiekvienas klinikinis darbuotojas turėtų tapti mašininio mokymosi specialistu. Esmė ta, kad sistema negali būti atsakingai naudojama, jei žmonės, kurių tikimasi ja pasikliauti, ją prižiūrėti ar jai prieštarauti, neturi naudingo jos apribojimų aprašo. Mokymas yra kontrolės aplinkos dalis. Taip pat ir eskalavimo keliai, atsakomybės susitarimai, realaus veikimo įrodymai ir būdas pacientams bei specialistams išreikšti susirūpinimą netampant pirma technologijos ekspertais.

Europos Komisija taip pat dirbtinį intelektą sveikatos priežiūroje įtraukia į platesnį reglamentavimo ir veiklos kontekstą. Jos visuomenės sveikatos medžiagoje pažymima, kad medicininės paskirties DI programinė įranga gali patekti į DI akto didelės rizikos reikalavimus, įskaitant rizikos mažinimą, duomenų kokybę, informaciją vartotojams ir žmogaus priežiūrą. Tai nereiškia, kad kiekvienas ligoninėje naudojamas įrankis gauna tą pačią teisinę klasifikaciją. Tai priminimas, kad žodis „sveikata“ nesumažina poreikio atidžiai išanalizuoti numatytą paskirtį. Kuo reikšmingesnis naudojimas, tuo mažiau įtikima remtis plačiais patikinimais.

Klinikinė praktika taip pat parodo, kodėl intervencijos ribos turėtų būti aiškios. Sistemai gali būti leista rasti šaltinį, parengti santrauką, pažymėti trūkstamą lauką ar pasiūlyti, kad byla nusipelno dėmesio. Tai skirtingi veiksmai. Kiekvienas iš jų šiek tiek labiau nutolina nuo informacijos link įtakos. Tam tikru momentu sistemai gali būti leista atlikti ribotą operacinį veiksmą, galbūt su taisyklėmis, kurios apriboja apimtį, ir įrašu, kuris daro veiksmą grįžtamą. Už tos ribos jos gali būti paprašyta veikti be tuo metu priimto žmogaus sprendimo. Įrodymai, autoritetas ir atkūrimo dizainas, reikalingi šiuose lygiuose, nėra keičiami.

Tai nepadaro automatizavimo neįmanomo. Tai daro teiginius proporcingus. Organizacija gali pasirinkti kuklią, gerai apibrėžtą užduotį ir padaryti ją patikimą prieš įsivaizduodama plačią. Ji gali išlaikyti šaltinio medžiagą prieinamą, o ne paversti santrauką vieninteliu įrašu. Ji gali suteikti klinicistui ar kitam atsakingam darbuotojui realią galimybę sustabdyti sistemą, o ne teorinį mygtuką, paslėptą politikos vadove. Ji gali stebėti, kas vyksta po diegimo, ir traktuoti netikėtą elgesį kaip įrodymą, kad pradinis argumentas turi būti peržiūrėtas. Tai lėčiau nei skelbti, kad modelis perėmė valdžią. Paprastai tai greičiau nei bandyti atkurti sprendimą po to, kai pasitikėjimas jau prarastas.

Modelis nėra visa sistema

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.

Automatinei sistemai pereinant nuo informavimo žmogaus prie savarankiško veikimo, įrodymų, įsikišimo ir atkūrimo reikalavimai turi stiprėti, o ne silpnėti.

Ribos neleidžia naudingai priemonei tapti niekieno sprendimu

Įsikišimo riba yra praktiškas atsakymas į praktišką klausimą: kada sistemai leidžiama ką nors padaryti, o kada ji privalo grąžinti klausimą žmogui? Ji turi būti matoma prieš diegimą, o ne atrasta iš skundo. Riba gali priklausyti nuo pasitikėjimo, tačiau vien pasitikėjimo nepakanka. Ji gali priklausyti nuo sprendimo tipo, klaidos pasekmių, duomenų kokybės ir naujumo, prieštaringų įrodymų buvimo, kvalifikuoto žmogaus prieinamumo, galimybės atkurti padėtį ir to, kiek atvejis atitinka nustatytą paskirtį.

Ribos nėra įrodymas, kad sistema yra saugi. Jos yra būdas neleisti sistemai reikalauti daugiau įgaliojimų, nei gali pagrįsti jos įrodymai. Modelis gali apibendrinti įrašą, bet negali įvertinti jo išsamumo. Jis gali atpažinti terminą, bet negali nustatyti jo teisinės reikšmės. Jis gali pateikti įtikinamą paaiškinimą, bet negali įrodyti, kad tas paaiškinimas yra teisingas. Jis gali atpažinti įprastą modelį ir vis tiek būti netinkamas neįprastiems atvejams, prieštaringiems šaltiniams ar situacijoms, kuriose mažą klaidą būtų sunku atitaisyti. Riba yra ta vieta, kur organizacija tuos skirtumus paverčia elgesiu.

Kelių priežiūros institucijai riba gali nurodyti, kad tam tikras patikrinimų rezultatų ir apibrėžtų rizikos rodiklių derinys lemia formalų peržiūrėjimą, o kitas derinys reikalauja skubios laikinosios priemonės. Tikslūs kriterijai priklauso atitinkamai teisinei ir profesinei sistemai. Perkeliama idėja yra ta, kad kelias nuo stebėjimo iki įsikišimo neturėtų visiškai priklausyti nuo to, kas tuo metu budi ar koks susirūpinimas ryškiausiai įsimenamas posėdyje. Įrodymai nepakeičia profesinio sprendimo. Jie suteikia sprendimui bendrą įrašą ir pakartojamą kelią.

Ligoninei riba gali atskirti priemonę, kuri parengia medžiagą peržiūrai, nuo sistemos, kuri gali atlikti ribotą administracinį veiksmą. Pastarajai reikia aiškaus jos apimties įrašo, būdo išimčiai aptikti, įvardyto išimties savininko ir būdo atkurti ankstesnę būseną, jei veiksmas buvo klaidingas. Jei sistema paliečia kliniškai reikšmingą sprendimą, riba turi atsižvelgti į atitinkamas klinikines, teisines ir profesines prievoles. Atsakingo asmens negalima prašyti taisyti nepermatomo automatizavimo rezultato, kai nėra šaltinio pėdsako ir laiko jį patikrinti.

Dirbtinio intelekto sistemai infrastruktūroje slenkstis gali atskirti prognozę nuo valdymo veiksmo. Prognozė gali įspėti operatorių apie būklę, kurią verta patikrinti. Valdymo veiksmas gali pakeisti fizinę ar veiklos būseną. Antrasis teiginys reikalauja gerokai išsamesnio įvesties kokybės, sistemos apribojimų, aplinkos sąlygų, stebėsenos, įgaliojimų, atsarginių priemonių ir atkūrimo aprašymo. Tai ne biurokratija, įdiegta tam, kad nuviltų inžinierius. Tai inžinerinis aprašymas to, kas nutinka, kai klaidos kaina yra ne nuviliantis atsakymas pokalbio lange.

Dažnai naudingiausias slenkstis yra atsisakymo slenkstis. Kas turėtų priversti sistemą atsisakyti veikti? Kokia trūkstama įvestis, konfliktas, pavėluotas įrašas, už pasiskirstymo ribų esanti sąlyga, nepasiekiamas vertintojas ar neišbandytas pakeitimas turėtų sukelti saugią pertrauką? Organizacijos linkusios aprašyti, ką tikisi, kad jų sistema darys. Jos kur kas mažiau noriai užrašo, kada sistema turi sustoti. Vis dėlto sistemos stabdymo elgsena dažnai atskleidžia daugiau apie jos brandą nei demonstruojama elgsena. Gebėjimas pasakyti „šis atvejis nepatenka į įrodymų apimtį“ nėra trūkumas. Tai įrodymas, kad riba egzistuoja.

Žmogiškasis veiksnys yra įrodymų dalis, o ne išnaša

Žmogiškasis veiksnys kartais redukuojamas į pastebėjimą, kad žmonės gali klysti. Tai tiesa, bet savaime nelabai naudinga. Inžinerinis klausimas yra tai, kaip darbas organizuojamas atsižvelgiant į realų žmogaus dėmesį, atmintį, suvokimą, darbo krūvį, bendravimą ir įgaliojimus. Įspėjimas, kurio negalima pastebėti, nėra įspėjimas. Sudėtingas paaiškinimas, kurio negalima suprasti esant laiko spaudimui, nėra prasmingas skaidrumas. Sustabdymo valdiklis, kuriam reikia nepasiekiamo asmens patvirtinimo, nėra sustabdymo valdiklis. Peržiūros ekranas, slepiantis pagrindinį įrašą, nėra įrodymų paviršius.

Kelių projektavimas tai paverčia konkrečiu. Žmonės juda fizinėje aplinkoje turėdami ribotą laiko pamatyti, interpretuoti ir veikti. Sistemos negalima vertinti vien aprašant jos numatytus signalus. Ją reikia vertinti atsižvelgiant į tai, ar atitinkami žmonės gali jais naudotis realioje aplinkoje. Sveikatos priežiūra tą patį teiginį išreiškia kita kalba. Įspėjimo ar rekomendacijos skaitytojas gali būti pertrauktas, spręsti konkuruojančius prioritetus, pavaduoti kolegą ar susidurti su atveju, kuris netiksliai atitinka procesą. DI prideda dar vieną sluoksnį, nes sklandi išvestis gali sudaryti klaidingą įspūdį, kad sistema įvertino įrodymus, kuriuos ji tik pakartojo.

Atsakymas nėra reikalavimas antžmogiškos koncentracijos. Tai perdavimo projektavimas ir išbandymas. Ką sistema rodo pirmiausia? Kurį šaltinį asmuo gali patikrinti? Kaip sistema išreiškia neapibrėžtumą? Ar asmuo gali paprašyti kito maršruto? Ar sąsaja atskiria patvirtintą įrašą nuo išvados? Ar jie gali pasakyti, ar pasikeitė modelis, duomenų šaltinis, taisyklė ar konfigūracija? Kas nutinka grįžtamajam ryšiui? Tai empiriniai ir organizaciniai klausimai. Jiems reikia pratybų, stebėjimo, vartotojų tyrimų ir po diegimo atliekamos peržiūros, o ne tik teiginio, kad sąsaja sukurta turint omenyje vartotoją.

Atsakingas įrodymų įrašas turėtų užfiksuoti žmogiškąjį susitarimą netapdamas atskirų darbuotojų byla. Jame galima užfiksuoti vaidmenį, įgaliojimus, mokymo reikalavimą, numatytą intervenciją, turimą laiką, informacijos paviršių, eskalavimo kelią ir pratybų rezultatą. Jame galima užfiksuoti, kad procesas buvo išbandytas pagal nurodytą scenarijų, neapsimetant, kad scenarijus įrodo kiekvieną būsimą sąlygą. Jame galima išsaugoti sprendimų kelią nenaudojant stebėsenos kaip pasiteisinimo nereikalingam sekimui. Šios pusiausvyros yra sudėtingos. Vis dėlto jas geriau spręsti atvirai, nei palikti miglotam nurodymui, kad žmonės turėtų „pasikliauti savo sprendimu“.

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.

Įrodymai turi galiojimo laiką

Sunkiausia įrodymais grindžiamo darbo dalis yra pripažinti, kad vakarykščiai įrodymai gali būti tikslūs ir vis tiek nebepakakti. Pasikeičia modelis. Pasikeičia duomenų šaltinis. Tiekėjas pakeičia komponentą. Pertvarkomas darbo procesas. Paslauga pradeda naudotis nauja žmonių grupė. Kelias pakeičiamas, kitaip prižiūrimas arba veikiamas kitokio eismo srauto. Ligoninė pakeičia personalą, programinę įrangą, skubios pagalbos tvarką ar įrašus. Pirminis testas gali likti galiojantis kaip istorinis stebėjimas, tačiau juo grindžiamam teiginiui gali prireikti kitokių ribų.

Štai kodėl versijų istorija nėra administracinė smulkmena. Skaitytojas, negalintis nustatyti, kuri modelio, konfigūracijos, duomenų šaltinio, politikos ar sąsajos versija sukūrė rezultatą, negali atkurti sprendimo sąlygų. Komanda, nefiksuojanti esminių pakeitimų, negali atskirti naujos problemos nuo senos. Organizacija, vertinanti išleidimą kaip užtikrinimo pabaigą, anksčiau ar vėliau turės iš naujo atrasti, kuo buvo grindžiamas jos pasitikėjimas, būtent tą akimirką, kai atsakymas svarbiausias.

Poreginė stebėsena pagal DI aktą pripažįsta šią gyvavimo ciklo realybę didelės rizikos sistemoms. Reikalavimas nėra pažadas, kad stebėsena pašalins neapibrėžtumą. Tai pripažinimas, kad informacija gaunama po diegimo ir turi turėti kelią atgal į rizikos valdymą. Lygiavertė pamoka kelių saugos srityje yra gerai žinoma: sistemas reikia tikrinti ir vertinti joms veikiant, o ne manyti, kad jos lieka saugios, nes kažkada atitiko projektinį reikalavimą. Sveikatos srityje realus naudojimas, darbuotojų patirtis, poveikis pacientams ir valdymo susitarimai yra svarbūs kartu su bet kokiu vertinimu prieš diegimą.

Peržiūros priežastis turi būti pakankamai konkreti, kad ją būtų galima naudoti. „Peržiūrėti periodiškai“ yra mandagus būdas paprašyti būsimų kolegų spėlioti. Geresnė priežastis įvardija esminį įvykį: naują modelio versiją, įvesties šaltinio pakeitimą, naują diegimo vietą, pasikeitusią naudotojų grupę, neišspręstą neatitikimą, skundų pobūdį, saugos signalą, negalėjimą atlikti priežiūros veiksmo arba sprendimą priimančios institucijos pasikeitimą. Sąrašas kiekvienai sistemai bus kitoks. Svarbu tai, kad pirminis argumentas įvardytų sąlygas, dėl kurių jis gali pasenti.

Tai taip pat keičia audito tako prasmę. Audito takas neturėtų būti sandėlis, pilnas įvykių, kurių niekas negali interpretuoti. Tai turėtų būti kelias per sistemos istoriją. Kuris teiginys galiojo? Kurie įrodymai jį tuo metu rėmė? Kuri versija sukūrė rezultatą? Kuris asmuo ar vaidmuo atliko reikšmingą veiksmą? Kas atsitiko, kai sistema buvo užginčyta? Kuris klausimas buvo išspręstas, o kuris liko atviras? Įrašas turi būti proporcingas. Jis taip pat turi gebėti atsakyti į tikrą klausimą nereikalaujant herojiškos archeologinės ekspedicijos per programų žurnalus.

Kaip skamba rimtas įrodymų klausimas

Kai organizacija vertina saugai kritišką sistemą, naudingas klausimas retai būna „ar ji veikia?“. Veikia kam, kokiu tikslu, kokiomis sąlygomis, palyginti su kuo ir su kokia pasekme, jei nepavyks? Šie klausimai gali atrodyti lėti, nes jie užkerta kelią lengvam „taip“. Tai taip pat klausimai, dėl kurių vėlesnis „taip“ ką nors reiškia.

Gera peržiūra todėl reikalauja grandinės, o ne rinkinio. Ji prašo komandos įvardyti numatytą paskirtį ir sprendimą, kuris seka. Ji klausia, kokios žalos ir gedimo scenarijai yra svarbūs. Ji klausia, kokie įrodymai pagrindžia kiekvieną esminį teiginį ir ko tie įrodymai neparodo. Ji klausia, kokios prielaidos turi išlikti teisingos. Ji klausia, kas turi įgaliojimus prižiūrėti, perimti, sustabdyti ir taisyti. Ji klausia, kaip sistema elgiasi, kai įrodymų trūksta arba atvejis nepatenka į taikymo sritį. Ji klausia, kas bus stebima po išleidimo ir kokie pokyčiai sukelia pakartotinį vertinimą.

Nėra universalaus balo, kuris užbaigtų šį pratimą. Kelias turi vieną kontekstą, ligoninė kitą, modelis dar kitą. Gerai suprojektuota maža sistema gali turėti tvirtesnį įrodymų pagrindą nei plati sistema, aprašyta su didesniu pasitikėjimu. Siauras teiginys su aiškia riba nėra silpnas teiginys. Tai pradžia sąžiningo teiginio.

Dėl to mūsų tyrimų puslapiai taip pat aprašo aiškius klausimus, įrodymų ribas ir prieigos statusą, o ne pagal nutylėjimą pristato tyrimų medžiagą kaip baigtą galimybę. Metodas kuklus: įvardyti klausimą, padaryti įrodymų ribą matomą ir išlaikyti publikavimo statusą aiškų. Jis neįrodo, kad produktas tinka konkrečiam diegimui, ir nepakeičia sektoriui būdingo užtikrinimo. Vis dėlto tai naudingas įprotis. Jei organizacija negali pasakyti, ką jos įrodymai pagrindžia, ko nepagrindžia ir kas gali juos užginčyti, ji dar neužsitarnavo tvirtesnio teiginio.

Kelias, ligoninė ir modelis turi vieną bendrą problemą. Kiekvienam reikia būdo paversti žinias veiksmais neslepiant sąlygų, kuriomis tie veiksmai yra pateisinami. Atsakymas nėra ceremoninis failas, vidutinis balas ar mygtukas, pažymėtas žmogaus priežiūra. Tai įrodymų praktika, kuri išlieka susijusi su paskirtimi, žmonėmis, įgaliojimais ir pokyčiais. Tas darbas nėra įspūdingas. Taip sistema tampa atskaitinga, kol dar neturi tapti paaiškinama.

Kelias, ligoninė ir modelis turi vieną bendrą problemą: įrodymai