Droga, szpital i model mają jeden wspólny problem: dowody
The evidence has to survive the handover
A road designer, a hospital team and a model provider can all produce a convincing demonstration. The junction can look orderly on a plan. The clinical screen can look calm in a workshop. The model can return a sensible answer on a carefully selected set of examples. None of that settles the question that matters when the system enters ordinary life: what evidence supports this particular action, for these people, in these conditions, and who is entitled to change course when the evidence no longer holds?
That question is more useful than a debate about whether a road, a hospital or an AI system is “safe”. Safety is not a property that arrives in a cardboard box with the device. It is a continuing relationship between a purpose, a setting, a set of people, a system's limits and the work that happens when a limit is reached. A road needs to accommodate people who make mistakes and conditions that change. A clinical service needs to preserve judgement when information is incomplete, urgent or contested. An AI system needs to remain understandable enough that a person can see when its output has stopped being a useful contribution to a decision.
Europe already has parts of this discipline in different places. Road-infrastructure rules require procedures such as impact assessment, audits, safety inspections and network-wide assessment. The Artificial Intelligence Act asks high-risk systems to work with lifecycle risk management, technical documentation, logs, human oversight, appropriate accuracy, robustness and cybersecurity. European health institutions are discussing safety, equity, governance, workforce readiness and accountability together, rather than treating a clinical model as a piece of software that becomes harmless because its interface has a stethoscope on it.
The common thread is evidence. Not evidence as a thick folder assembled once, and not evidence as a scoreboard with a flattering average. Evidence as something attached to a claim, a context and a decision. A useful evidence record says what the system was meant to do, where the claim applies, which observations support it, which assumptions sit underneath it, what is still uncertain, who can intervene and which change means the argument must be reconsidered.
This is a less glamorous idea than autonomy. It is also more durable. It gives engineers a way to state their limits without pretending that a test set is a complete world. It gives managers a way to ask what they are actually accepting. It gives operators something better than a dashboard that lights up after the decision has already become difficult. Most importantly, it gives people affected by a system a route from an outcome back to the reasons and conditions that produced it.
Three domains, one awkward question
The road, the hospital and the model are not the same system. Their harms, legal duties, evidence bases and professional cultures differ. Nobody should copy a road audit into a clinical workflow, or paste a medical-device checklist onto a language model and call the job finished. The point is not to flatten the differences. The point is to notice a shared engineering problem: an automated or semi-automated system acts through a larger arrangement of people, procedures, interfaces, environments and assumptions.
Droga jest szczególnie wyraźnym przypomnieniem, ponieważ nie podejmuje decyzji w ludzkim sensie. To ona je kształtuje. Geometria, linie widoczności, separacja, przejścia, oznakowanie, zarządzanie prędkością, utrzymanie i otaczająca sieć wpływają na to, co ludzie mogą zobaczyć, z czego mogą się wycofać i jak poważny stanie się błąd. Dobra praktyka bezpieczeństwa drogowego nie opiera się na fantazji o wiecznie czujnym, doskonale poinformowanym użytkowniku drogi. Stara się sprawić, by przewidywalne błędy były mniej prawdopodobne i mniej kosztowne. Europejskie ramy zarządzania bezpieczeństwem infrastruktury drogowej odzwierciedlają to systemowe podejście poprzez powtarzalne procesy oceny i inspekcji, a nie pojedynczą deklarację, że trasa została zatwierdzona.
Szpital jest inny, ale również żyje z przepaścią między czystym opisem a zmieniającą się rzeczywistością. Ścieżka kliniczna obejmuje role personelu, przekazywanie informacji, dokumentację, sprzęt, priorytety, przerwy oraz osobę, której stan może nie przypominać przeciętnego przypadku, który ukształtował protokół. Zalecenie może być użyteczne, a mimo to niewystarczające. Ostrzeżenie może być technicznie poprawne, a mimo to pojawić się w momencie, gdy nie można na nie bezpiecznie zareagować. System może usprawnić jedną część przepływu pracy, tworząc jednocześnie nowe obciążenie gdzie indziej. Dlatego dyskusja o sztucznej inteligencji w ochronie zdrowia nie może zatrzymać się na pozornej skuteczności modelu. Musi obejmować zarządzanie, odpowiedzialność kliniczną, jakość danych, szkolenia, zaufanie publiczne oraz środki umożliwiające identyfikację i naprawę szkód.
Model znajduje się w podobnym układzie. Jest trenowany lub konfigurowany gdzieś, podłączony do danych gdzie indziej, otrzymuje polecenie lub zadanie od człowieka, jest umieszczony za interfejsem, obserwowany przez niektórych ludzi, a nie obserwowany przez innych. Generuje wynik, ale wynik staje się istotny dopiero wtedy, gdy ktoś potraktuje go jako podstawę do działania. Między wynikiem a działaniem znajdują się progi, uprawnienia, presja czasu, dostęp do materiałów źródłowych, szkolenia, zachęty i możliwość wyrażenia sprzeciwu. To nie są dekoracyjne szczegóły operacyjne. To one decydują, czy technicznie kompetentny komponent pozostaje bezpiecznym elementem większego systemu.
Potraktuj poniższe jako wyraźnie hipotetyczną kompozycję, a nie opis prawdziwej drogi, szpitala, pacjenta, pracownika czy zdarzenia. Władza lokalna rozważa system, który wyznacza lokalizacje do przeglądu bezpieczeństwa drogowego. Szpital rozważa narzędzie, które pomaga sortować dokumenty administracyjne, zanim zobaczy je personel kliniczny. Trzecia organizacja rozważa model, który przygotowuje streszczenie ryzyka dla zarządcy infrastruktury. W każdej z tych sytuacji wczesna demonstracja pokazuje, że system potrafi znajdować wzorce w istniejących danych. Demonstracja nie odpowiada jeszcze na pytanie, czy dane odzwierciedlają warunki, z którymi usługa spotka się w przyszłym miesiącu, czy nietypowy przypadek może zostać rozpoznany, czy osoby otrzymujące zalecenie mają wystarczająco dużo czasu i uprawnień, by je zakwestionować, ani czy organizacja zauważy szkodliwy wzorzec, zanim stanie się on normalną praktyką. Problem z dowodami zaczyna się właśnie tutaj.
Łatwym błędem jest proszenie o jedną liczbę. Jaka jest dokładność? Ile czasu to zaoszczędzi? Ile ryzyk wykryje? Te pytania są uzasadnione, ale niepełne. Liczba potrzebuje mianownika, próby, definicji, daty, zamierzonego zastosowania i stwierdzenia, co zostało wykluczone. Potrzebuje także związku z kolejną decyzją. Wysoki wynik w wąskim, stabilnym zadaniu może wspierać wąskie, stabilne twierdzenie. Nie może po cichu upoważniać do innego przepływu pracy, innej populacji ani decyzji o innych konsekwencjach.
Dowody nie są ozdobnym dodatkiem
Dowody stają się użyteczne, gdy mogą zmienić czyjeś zdanie. To brzmi oczywisto, ale wiele pakietów dowodowych tworzy się tak, by wyglądały na kompletne, a nie po to, by decyzję można było podważyć. Zawierają zrzuty ekranu, oświadczenia polityczne, podsumowania testów i podpisy, ale nie pokazują, które twierdzenie wspiera dany element, jaki warunek ogranicza to twierdzenie ani co powinno się stać, gdy warunek się zmieni. Efektem jest dokumentacja o charakterze ceremonialnym. Może dowieść, że odbyło się spotkanie. Nie musi jednak powiedzieć operatorowi, co ma zrobić o 07:40, gdy usługa jest obciążona, dane są opóźnione, a rekomendacja nie pasuje do sytuacji, z którą się mierzy.
Lepszym punktem wyjścia jest nazwana decyzja. Nie „odpowiedzialne wdrożenie AI” ani „poprawa bezpieczeństwa ruchu drogowego”, lecz twierdzenie z granicą. Na przykład: system może priorytetyzować określoną klasę prac przeglądowych w zdefiniowanym kontekście operacyjnym, podczas gdy wskazana rola pozostaje odpowiedzialna za przyjęcie lub odrzucenie rekomendacji. Albo: ten projekt może zostać dopuszczony do ruchu po ocenie zidentyfikowanych zagrożeń w wymaganym procesie i po wdrożeniu wskazanych środków kontroli. To sformułowanie jest celowo mniej ekscytujące niż zapowiedź produktu. To umowa z rzeczywistością.
Gdy decyzja jest nazwana, reszta dokumentacji ma się do czego przyczepić. Zamierzony cel mówi czytelnikowi, czego nie należy wnioskować. Kontekst wskazuje, które miejsce, przepływ pracy, użytkownicy, dane, sprzęt i otaczający proces mają znaczenie. Dowody rejestrują testy, obserwacje, materiały źródłowe, przeglądy i ćwiczenia. Założenia uwidaczniają zależności: być może operator ma szkolenie, być może rejestr źródłowy jest aktualny, być może konkretne ostrzeżenie dociera do właściwej roli na czas. Właściciel wskazuje, kto może interpretować materiał i interweniować. Wyzwalacze przeglądu określają, który sygnał, zmiana lub niespełnienie założenia wymaga ponownego spojrzenia.
Ta struktura ma ważną konsekwencję. Powstrzymuje dryfowanie dowodów z dala od zastosowania. Test nie jest tylko archiwizowany pod hasłem „walidacja”. Jest powiązany z twierdzeniem o konkretnym zachowaniu w określonych warunkach. Audyt nie jest tylko dowodem, że audytor złożył wizytę. Staje się zapisem tego, co zbadano, co ustalono, co pozostało niepewne i który autorytet zdecydował, co dalej. Ewaluacja modelu nie jest ogólną odznaką. To ograniczona obserwacja, której znaczenie zależy od wersji modelu, zadania, danych, konfiguracji i warunków wdrożenia.
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.
Szpital nie może sprawić, by niepewność zniknęła
Opieka zdrowotna czyni problem dowodów szczególnie widocznym, ponieważ konsekwencje są osobiste, a środowisko złożone. Użyteczny system kliniczny lub administracyjny może pomóc personelowi w znajdowaniu informacji, ograniczyć powtarzalną pracę, zauważyć możliwy wzorzec lub przygotować materiał do przeglądu. To nie czyni z niego autorytetu klinicznego. Przejście od informacji do leczenia, priorytetyzacji lub odmowy opieki wiąże się z obowiązkami, których nie można zlecić interfejsowi. Osoba odpowiedzialna za opiekę musi wiedzieć, co system zrobił, czego nie zrobił i jak zareagować, gdy wynik jest sprzeczny z faktami dostępnymi w danym przypadku.
Prace WHO/Europa nad sztuczną inteligencją w zdrowiu ujmują tę kwestię w słownictwie, na jakie zasługuje: bezpieczeństwo, skuteczność, równość, prawa człowieka, przejrzystość, rozliczalność, zarządzanie i gotowość kadr. Nie chodzi o to, by każdy pracownik kliniczny stał się specjalistą od uczenia maszynowego. Chodzi o to, że system nie może być odpowiedzialnie używany, jeśli osoby, które mają na nim polegać, nadzorować go lub go kwestionować, nie mają użytecznego opisu jego ograniczeń. Szkolenie jest częścią środowiska kontroli. Podobnie jak ścieżki eskalacji, ustalenia dotyczące odpowiedzialności, dowody rzeczywistego działania oraz sposób, w jaki pacjenci i profesjonaliści mogą zgłaszać obawy bez uprzedniego stawania się ekspertami w tej technologii.
Komisja Europejska podobnie umieszcza sztuczną inteligencję w zdrowiu w szerszym kontekście regulacyjnym i operacyjnym. Jej materiały dotyczące zdrowia publicznego zauważają, że oprogramowanie AI do celów medycznych może podlegać wymogom wysokiego ryzyka określonym w akcie o sztucznej inteligencji, w tym ograniczaniu ryzyka, jakości danych, informowaniu użytkowników i nadzorowi człowieka. To nie jest twierdzenie, że każde narzędzie używane w szpitalu otrzymuje tę samą klasyfikację prawną. To przypomnienie, że słowo „zdrowie” nie łagodzi potrzeby starannej analizy zamierzonego celu. Im bardziej doniosłe zastosowanie, tym mniej wiarygodne jest poleganie na ogólnych zapewnieniach.
Praktyka kliniczna pokazuje również, dlaczego progi interwencji powinny być jawne. System może mieć pozwolenie na pobranie źródła, przygotowanie streszczenia, oznaczenie brakującego pola lub zasugerowanie, że przypadek zasługuje na uwagę. To różne działania. Każde z nich przesuwa się nieco dalej od informacji w stronę wpływu. W pewnym momencie system może mieć pozwolenie na wykonanie ograniczonego kroku operacyjnego, być może z regułami ograniczającymi zakres i zapisem, który czyni ten krok odwracalnym. Poza tym punktem można go poprosić o działanie bez równoczesnej decyzji człowieka. Dowody, autorytet i projekt odzyskiwania potrzebne na tych poziomach nie są wymienne.
To nie czyni automatyzacji niemożliwą. To czyni twierdzenia proporcjonalnymi. Organizacja może wybrać skromne, dobrze ograniczone zadanie i uczynić je niezawodnym, zanim wyobrazi sobie szersze. Może utrzymać dostępność materiałów źródłowych, zamiast czynić streszczenie jedynym zapisem. Może dać klinicyście lub innemu odpowiedzialnemu pracownikowi realny sposób na zatrzymanie systemu, a nie teoretyczny przycisk ukryty w podręczniku polityki. Może monitorować, co dzieje się po wdrożeniu, i traktować nieoczekiwane zachowanie jako dowód, że pierwotny argument wymaga rewizji. To wolniejsze niż ogłoszenie, że model przejął kontrolę. Zwykle jest szybsze niż próba odtworzenia decyzji po tym, jak zaufanie już zostało utracone.
Model to nie cały system
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.
Progi zapobiegają przekształceniu użytecznego narzędzia w decyzję bez właściciela
Próg interwencji to praktyczna odpowiedź na praktyczne pytanie: kiedy system może coś zrobić, a kiedy musi przekazać sprawę dalej? Powinien być widoczny przed wdrożeniem, a nie odkryty po skardze. Próg może zależeć od pewności, ale sama pewność nie wystarczy. Może zależeć od rodzaju decyzji, konsekwencji błędu, jakości i świeżości danych, obecności sprzecznych dowodów, dostępności wykwalifikowanej osoby, możliwości odzyskania oraz stopnia, w jakim sprawa mieści się w określonym celu.
Progi nie są dowodem na to, że system jest bezpieczny. Są sposobem zapobiegania sytuacji, w której system rości sobie więcej autorytetu, niż mogą potwierdzić jego dowody. Model może podsumować rekord, ale nie ocenić jego kompletności. Może zidentyfikować termin, ale nie określić jego znaczenia prawnego. Może wygenerować prawdopodobne wyjaśnienie, ale nie ustalić prawdziwości tego wyjaśnienia. Może rozpoznać rutynowy wzorzec, a mimo to nie nadawać się do nietypowych przypadków, sprzecznych źródeł lub sytuacji, w których mały błąd byłby trudny do odwrócenia. Próg to miejsce, w którym organizacja przekształca te rozróżnienia w zachowanie.
Dla zarządcy dróg próg może określać, że połączenie wyników inspekcji i zdefiniowanych wskaźników ryzyka prowadzi do formalnego przeglądu, podczas gdy inna kombinacja wymaga pilnego środka tymczasowego. Dokładne kryteria należą do właściwych ram prawnych i zawodowych. Przenośną ideą jest to, że droga od obserwacji do interwencji nie powinna zależeć wyłącznie od tego, kto akurat pełni dyżur, ani od tego, która obawa jest najżywiej zapamiętana na spotkaniu. Dowody nie zastępują profesjonalnego osądu. Dają osądowi wspólny zapis i powtarzalną ścieżkę.
Dla szpitala próg może odróżniać narzędzie przygotowujące materiał do przeglądu od systemu, który może wykonać ograniczone działanie administracyjne. Ten drugi potrzebuje jasnego zapisu swojego zakresu, sposobu wykrywania wyjątku, wyznaczonego właściciela wyjątku oraz sposobu przywrócenia poprzedniego stanu, jeśli działanie było błędne. Jeśli system dotyka decyzji istotnej klinicznie, próg musi uwzględniać odpowiednie obowiązki kliniczne, prawne i zawodowe. Osoba odpowiedzialna nie może być proszona o naprawienie nieprzejrzystego wyniku automatyzacji bez śladu źródłowego i czasu na jego sprawdzenie.
W systemie AI dla infrastruktury próg może odróżniać prognozę od działania sterującego. Prognoza może ostrzec operatora o stanie wartym sprawdzenia. Działanie sterujące może zmienić stan fizyczny lub operacyjny. To drugie twierdzenie wymaga znacznie mocniejszego uzasadnienia jakości danych wejściowych, ograniczeń systemu, warunków środowiskowych, monitorowania, uprawnień, mechanizmów awaryjnych i odzyskiwania sprawności. To nie jest biurokracja wprowadzona, by frustrować inżynierów. To inżynieryjny opis tego, co się dzieje, gdy koszt błędu to nie rozczarowująca odpowiedź w oknie czatu.
Najbardziej użytecznym progiem jest często próg odmowy. Co powinno sprawić, że system wstrzyma działanie? Który brakujący element wejściowy, konflikt, spóźniony rekord, warunek spoza rozkładu, niedostępny recenzent lub nieprzetestowana zmiana powinny wywołać bezpieczną pauzę? Organizacje zwykle opisują, co według ich nadziei system będzie robił. Znacznie mniej chętnie zapisują, kiedy musi się zatrzymać. A zachowanie systemu w momencie zatrzymania często mówi o jego dojrzałości więcej niż zachowanie podczas pokazów. Umiejętność stwierdzenia „ten przypadek wykracza poza dostępne dowody” nie jest wadą. To dowód na to, że granica istnieje.
Czynnik ludzki jest częścią dowodów, a nie przypisem
Czynnik ludzki bywa sprowadzany do obserwacji, że ludzie są omylni. To prawda, ale sama w sobie mało użyteczna. Pytanie inżynieryjne brzmi: jak zorganizowano pracę wokół rzeczywistej uwagi, pamięci, percepcji, obciążenia, komunikacji i uprawnień ludzi? Ostrzeżenie, którego nie można zauważyć, nie jest ostrzeżeniem. Złożone wyjaśnienie, którego nie da się zrozumieć pod presją czasu, nie jest znaczącą przejrzystością. Sterowanie zatrzymaniem wymagające zgody osoby niedostępnej nie jest sterowaniem zatrzymaniem. Ekran przeglądu ukrywający źródłowy rekord nie jest powierzchnią dowodową.
Projektowanie dróg pokazuje to w konkretny sposób. Ludzie poruszają się w fizycznym środowisku, mając ograniczony czas na dostrzeżenie, zinterpretowanie i działanie. Systemu nie można oceniać tylko przez opis jego zamierzonych sygnałów. Trzeba go oceniać przez sprawdzenie, czy właściwi ludzie mogą z nich korzystać w rzeczywistym środowisku. Opieka zdrowotna ujmuje to samo w innym rejestrze. Osoba czytająca alert lub zalecenie może być przerywana, zajmować się sprzecznymi priorytetami, zastępować kolegę lub mierzyć się z przypadkiem, który nie pasuje do procedury. AI dodaje kolejną warstwę, bo płynny wynik może stwarzać fałszywe wrażenie, że system rozważył dowody, które jedynie powtórzył.
Reakcją nie jest wymaganie nadludzkiej koncentracji. Reakcją jest zaprojektowanie i przetestowanie przekazania odpowiedzialności. Co system pokazuje najpierw? Które źródło może sprawdzić człowiek? Jak system wyraża niepewność? Czy człowiek może poprosić o inną ścieżkę? Czy interfejs odróżnia potwierdzony rekord od wnioskowania? Czy można stwierdzić, czy zmienił się model, źródło danych, reguła lub konfiguracja? Co się dzieje z informacją zwrotną? To pytania empiryczne i organizacyjne. Zasługują na ćwiczenia, obserwację, badania użytkowników i przegląd po wdrożeniu, a nie tylko na stwierdzenie, że interfejs zaprojektowano z myślą o użytkowniku.
Odpowiedzialny zapis dowodowy powinien ujmować ludzkie ustalenia, nie zamieniając się w teczkę na temat poszczególnych pracowników. Może odnotować rolę, uprawnienia, wymóg szkolenia, oczekiwaną interwencję, dostępny czas, powierzchnię informacyjną, ścieżkę eskalacji i wynik ćwiczeń. Może odnotować, że proces przetestowano w określonym scenariuszu, nie udając, że scenariusz dowodzi słuszności dla każdego przyszłego warunku. Może zachować ślad decyzji bez wykorzystywania monitorowania jako pretekstu do zbędnej inwigilacji. Te równowagi są trudne. Wciąż lepiej radzić sobie z nimi jawnie, niż zostawić je mglistemu poleceniu, by ludzie „kierowali się osądem”.
Holenderski instynkt czynienia skomplikowanych systemów czytelnymi ma tu swoje zastosowanie. Skrzyżowanie rowerowe, rejestr publiczny czy dobrze opisany proces nie stają się dobre tylko dlatego, że są jasne, ale jasność pozwala ludziom zobaczyć, gdzie spoczywa odpowiedzialność. Dobre rządy mają podobną skromność. Nie obiecują, że nie pojawi się żadna trudna decyzja. Sprawiają, że droga dla trudnych decyzji jest widoczna, zanim nadejdzie dzień, w którym będzie potrzebna. Nie ma ceremonii przecięcia wstęgi dla dobrze zdefiniowanej ścieżki eskalacji, co być może tłumaczy, dlaczego tak często odkłada się ją na później.
Dowody mają termin ważności
Najtrudniejszą częścią pracy opartej na dowodach jest zaakceptowanie, że wczorajsze dowody mogą być dokładne, a mimo to już niewystarczające. Model się zmienia. Źródło danych się zmienia. Dostawca zmienia komponent. Przepływ pracy jest reorganizowany. Nowa grupa osób korzysta z usługi. Droga jest przebudowywana, inaczej utrzymywana lub wystawiona na inny wzorzec ruchu. Szpital zmienia obsadę, oprogramowanie, zasady segregacji medycznej lub dokumentację. Oryginalny test może pozostać ważny jako obserwacja historyczna, ale twierdzenie na nim zbudowane może wymagać innego zakresu.
Dlatego historia wersji nie jest administracyjnym drobiazgiem. Czytelnik, który nie może ustalić, która wersja modelu, konfiguracji, źródła danych, polityki lub interfejsu wygenerowała wynik, nie może zrekonstruować warunków decyzji. Zespół, który nie rejestruje istotnych zmian, nie potrafi odróżnić nowego problemu od starego. Organizacja, która traktuje wydanie jako koniec zapewniania jakości, w końcu będzie musiała odkryć na nowo, dlaczego jej pewność była uzasadniona, dokładnie w momencie, gdy odpowiedź ma największe znaczenie.
Monitorowanie po wprowadzeniu do obrotu na mocy aktu o sztucznej inteligencji uwzględnia tę rzeczywistość cyklu życia w przypadku systemów wysokiego ryzyka. Wymóg ten nie jest obietnicą, że monitorowanie eliminuje niepewność. Jest uznaniem, że informacje docierają po wdrożeniu i muszą mieć drogę powrotu do zarządzania ryzykiem. Odpowiednia lekcja w bezpieczeństwie ruchu drogowego jest dobrze znana: systemy należy kontrolować i oceniać w trakcie działania, a nie zakładać, że pozostaną bezpieczne, ponieważ kiedyś spełniły wymóg projektowy. W ochronie zdrowia rzeczywiste zastosowanie, doświadczenie personelu, wpływ na pacjentów i ustalenia dotyczące zarządzania mają znaczenie obok jakiejkolwiek oceny przedwdrożeniowej.
Wyzwalacz przeglądu powinien być na tyle konkretny, aby można go było zastosować. „Przeglądać okresowo” to uprzejmy sposób poproszenia przyszłych współpracowników o zgadywanie. Lepszy wyzwalacz wskazuje istotne zdarzenie: nową wersję modelu, zmianę źródła wejściowego, nową lokalizację wdrożenia, zmienioną grupę użytkowników, nierozwiązana rozbieżność, wzorzec skarg, sygnał bezpieczeństwa, niemożność wykonania kroku nadzoru lub zmianę organu odpowiedzialnego za decyzję. Lista będzie inna dla każdego systemu. Liczy się to, aby pierwotny argument wskazywał warunki, które mogłyby uczynić go nieaktualnym.
Zmienia to również znaczenie dziennika audytu. Dziennik audytu nie powinien być magazynem pełnym zdarzeń, których nikt nie potrafi zinterpretować. Powinien być drogą przez historię systemu. Które twierdzenie obowiązywało? Jakie dowody je wspierały w danym czasie? Która wersja wygenerowała wynik? Która osoba lub rola podjęła decyzję o konsekwencjach? Co się stało, gdy system został zakwestionowany? Który problem został rozwiązany, a który pozostał otwarty? Rejestr powinien być proporcjonalny. Powinien też umożliwiać odpowiedź na realne pytanie bez konieczności heroicznej wyprawy archeologicznej przez logi aplikacji.
Jak brzmi poważne pytanie o dowody
Gdy organizacja ocenia system krytyczny dla bezpieczeństwa, użyteczne pytanie rzadko brzmi „czy to działa?”. Działa dla kogo, w jakim celu, w jakich warunkach, w porównaniu z czym i z jakimi konsekwencjami, jeśli zawiedzie? Te pytania mogą wydawać się spowalniające, ponieważ uniemożliwiają łatwe „tak”. Są to również pytania, które sprawiają, że późniejsze „tak” jest coś warte.
Dobra recenzja wymaga zatem łańcucha, a nie zbioru. Pyta zespół o zamierzony cel i decyzję, która z niego wynika. Pyta, jakie szkody i tryby awarii są istotne. Pyta, które dowody wspierają każde istotne twierdzenie i czego te dowody nie pokazują. Pyta, które założenia muszą pozostać prawdziwe. Pyta, kto ma uprawnienia do nadzorowania, zawieszania, wstrzymywania i naprawy. Pyta, jak system zachowuje się, gdy brakuje dowodów lub gdy przypadek wykracza poza zakres. Pyta, co będzie monitorowane po wdrożeniu i która zmiana uruchamia ponowną ocenę.
Nie ma uniwersalnego wyniku, który kończyłby to ćwiczenie. Droga ma jeden kontekst, szpital inny, a model jeszcze inny. Dobrze zaprojektowany mały system może mieć mocniejsze podstawy dowodowe niż szeroki system opisany z większą pewnością. Wąskie twierdzenie z wyraźną granicą nie jest słabym twierdzeniem. To początek uczciwego twierdzenia.
Dlatego też nasze strony badawcze opisują wyraźne pytania, granice dowodów i status dostępu, zamiast domyślnie przedstawiać materiał badawczy jako gotową funkcję. Metoda jest skromna: zidentyfikować pytanie, uczynić granicę dowodów widoczną i utrzymać czytelny status publikacji. Nie dowodzi, że produkt nadaje się do konkretnego wdrożenia, i nie zastępuje sektorowej oceny zgodności. Jest jednak użytecznym nawykiem. Jeśli organizacja nie potrafi powiedzieć, co wspierają jej dowody, czego nie wspierają i kto może je zakwestionować, nie zasłużyła jeszcze na mocniejsze twierdzenie.
Droga, szpital i model mają jeden wspólny problem. Każdy z nich potrzebuje sposobu na przekształcenie wiedzy w działanie bez ukrywania warunków, w których to działanie jest uzasadnione. Odpowiedzią nie jest ceremonialny plik, średni wynik ani przycisk oznaczony jako nadzór człowieka. To praktyka dowodowa, która pozostaje związana z celem, ludźmi, uprawnieniami i zmianą. Ta praca nie jest efektowna. To dzięki niej system staje się rozliczalny, zanim będzie musiał być wytłumaczalny.
Źródła
- Rozporządzenie (UE) 2024/1689, Akt w sprawie sztucznej inteligencji, EUR-Lex
- Dyrektywa 2008/96/WE w sprawie zarządzania bezpieczeństwem infrastruktury drogowej, EUR-Lex
- Polityka bezpieczeństwa ruchu drogowego, Komisja Europejska
- Sztuczna inteligencja przekształca systemy opieki zdrowotnej: stan gotowości w europejskim regionie WHO, WHO/Europa
- Sztuczna inteligencja w opiece zdrowotnej, Komisja Europejska
- Program badawczy Dweve