Hvad Europa kan lære af sikkerhedssager

En sikkerhedsargumentation er et levende argument, der fører fra farer og antagelser til dokumentation, restrisiko og en beslutning. Den giver AI-teams en...

Hvad Europa kan lære af sikkerhedssager

En fil, der skal svare, før toget kører

Europæiske jernbaneregler begynder med et uglamourøst spørgsmål: hvad ændrede sig. En ændring kan være teknisk, operationel eller organisatorisk. Den kan involvere udstyr, en procedure, en personalemæssig ordning eller en grænseflade mellem organisationer. Den fælles sikkerhedsmetode for risikovurdering og -evaluering beder forslagsstilleren om at vurdere betydningen af den ændring, anvende en risikostyringsproces, når det kræves, og bruge et uafhængigt vurderingsorgan til at kontrollere, at processen og dens resultater er blevet anvendt korrekt. Reglen er ikke interesseret i, om ændringen blev annonceret med selvsikkerhed. Den er interesseret i, om argumentet for at fortsætte driften kan inspiceres.

Den vane er værd at tage med ind i AI. Et system bliver ikke sikkert, fordi dets model er intelligent, dets grænseflade er rolig, eller fordi dets leverandør har produceret en flot testrapport. Det bliver forsvarligt til en defineret brug, når en organisation kan forklare, hvad den hævder, hvilke farer der ligger bag kravet, hvilke antagelser der gør kravet muligt, hvilke beviser der understøtter hvert led, hvem der accepterede den resterende risiko, og hvad der ville genåbne beslutningen. Resultatet kaldes almindeligvis en safety case: et struktureret argument understøttet af beviser, afgrænset af betingelser og vedligeholdt gennem ændringer.

En safety case er ikke en historie om en imaginær ulykke. Det er en måde at nægte at lade ulykken bære alle beviserne. Den stiller de svære spørgsmål, mens design, indkøb og driftspraksis stadig kan ændres. Det gør den nyttig for jernbaner, luftfart, medicinsk udstyr, industriel kontrol og kritisk infrastruktur. Det gør den også nyttig for AI, hvor en komponent kan være statistisk imponerende og operationelt uforberedt på samme tid. En model kan bestå en test, mens systemet omkring den ikke har et sikkert svar på usikkerhed, ingen ansvarlig operatør og ingen vej til at rette op på en dårlig beslutning.

Forskellen betyder noget i Europa, fordi AI-forordningen allerede kræver, at højrisikosystemer lever med en kontinuerlig, dokumenteret risikostyringsproces. Artikel 9 beskriver iterativ identifikation, estimering, evaluering og behandling af risici gennem hele systemets livscyklus, herunder rimeligt forudsigelig misbrug og information fra overvågning efter markedsføring. Artikel 11 kræver teknisk dokumentation, før et system bringes på markedet, og siger, at den skal holdes opdateret. Disse bestemmelser bruger ikke safety case som en universel betegnelse. De beskriver dog de vaner, der gør en safety case troværdig.

En safety case gør ruten fra et sikkerhedskrav til en frigivelsesbeslutning synlig nok til at blive udfordret.

Safety case er ikke en testrapport

En testrapport besvarer et spørgsmål om en test. Den registrerer, hvad der blev testet, under hvilke betingelser, med hvilket resultat og, hvis arbejdet er godt, med hvilke begrænsninger. Det er værdifuldt. En safety case stiller et andet spørgsmål: er der et tilstrækkeligt underbygget argument for, at dette system er acceptabelt til dette formål, i denne kontekst, med disse mennesker, kontroller og resterende risici. Et testresultat kan være ét stykke af det argument. Det kan ikke stille og roligt blive hele argumentet, blot fordi tabellen har grønne celler.

Antag, at en klassifikator er blevet testet mod et mærket datasæt. Rapporten kan fortælle os, hvordan den klarede sig på det datasæt, måske efter klasse, tærskel eller driftspunkt. Den fortæller ikke i sig selv, om de input, der ankommer i produktion, har samme betydning, om den berørte befolkning er repræsenteret, om en reviewer kan genkende et svagt output, om en appel er mulig, om en leverandør kan ændre modellen uden varsel, eller om organisationen kan stoppe og rulle en nedstrøms handling tilbage. Disse spørgsmål hører til systemet og dets brug, ikke kun til komponenten.

Den modsatte fejl er også almindelig. En stor assurance-fil kan indeholde hundredvis af sider og stadig undlade at lave et argument. En katalog over test, politikker og mødereferater er ikke en safety case, hvis ingen påstand forbinder dem. Beviser har brug for et job. En test kan understøtte en påstand om robusthed. En rollebeskrivelse kan understøtte en påstand om autoritet. En rollback-øvelse kan understøtte en påstand om genopretning. Et revisionsspor kan understøtte en påstand om sporbarhed. Uden forholdet mellem påstand og bevis er filen et arkiv over aktivitet, ikke en forklaring på sikkerhed.

Det er derfor, en safety case kan være kortere end en testrapport ét sted og større et andet. Den vokser omkring farerne og beslutningerne. Et lavkonsekvens-draftingværktøj kan have brug for et beskedent argument, der dækker omfang, datahåndtering, review og korrektion. Et system forbundet til kliniske, transport-, finans- eller offentlige servicebeslutninger har brug for mere bevis, fordi flere mennesker afhænger af resultatet, og fordi vejen til klage kan være vanskelig. Størrelsen følger konsekvensen og usikkerheden, ikke den fashionable længde på modelkortet.

Argumentet bør også adskille komponentbevis fra operationelt bevis. Komponentbevis vedrører modellen, algoritmen eller sensoren isoleret eller i en kontrolleret integration. Operationelt bevis vedrører den faktiske arbejdsgang: adgang, datafriskhed, menneskelig gennemgang, køer, værktøjsrettigheder, håndtering af hændelser og ændringsstyring. En model kan være stabil, mens en kø kollapser. En arbejdsgang kan være veldesignet, mens en leverandør ændrer inputskemaet. Safety cases tvinger begge synspunkter på samme side, hvilket er lidt ubelejligt og derfor sundt.

Start med en påstand, der har kanter

Enhver safety case begynder med en toppåstand. Påstanden skal være snæver nok til at blive testet og nyttig nok til at guide en beslutning. Sætningen denne AI er sikker er ikke en påstand med kanter. Sikker for hvem, til hvad, under hvilke betingelser og med hvilke kontroller. En bedre påstand kunne sige, at en specificeret beslutningsstøttefunktion er acceptabel for en navngiven gruppe af uddannede operatører, forudsat at systemet kun bruges til anbefalinger, at beviser og usikkerhed vises, at et menneske med autoritet gennemgår resultatet, og at definerede stop- og korrektionsruter er tilgængelige.

Den sætning er mindre salgbar og meget mere værdifuld. Den identificerer formålet, aktøren, grænsen og betingelserne. Den afslører også, hvad der ville gøre påstanden falsk. Hvis den samme funktion er forbundet direkte til en automatisk beslutning, dækker påstanden den ikke længere. Hvis de tilsigtede brugere ikke er uddannede eller ikke kan udfordre et output, svækkes påstanden. Hvis en datakilde ændres og ikke kan spores, kan beviset for påstanden udløbe. En god toppåstand bærer sin egen liste over måder, den kan blive genåbnet på.

Krav kan dekomponeres. Systemet forbliver inden for sit tilsigtede formål. Input opfylder de angivne kvalitets- og tilladelsesbetingelser. Modeloutput fortolkes på en måde, der ikke skaber usikker automatiseringsbias. Handlinger med store konsekvenser modtager en gennemgang, der står mål med deres risiko. Operatører kan tilsidesætte eller omgøre et output. Organisationen kan opdage væsentlig drift. En ændring frigives ikke uden at kontrollere de berørte antagelser. Hvert delkrav kræver kontroller og dokumentation. Træet er ikke en illustration til en præsentation; det er den rute, hvorved en reviewer kan lokalisere et svagt led.

Et krav bør også sige, hvad det ikke forsøger at bevise. Sagen kan understøtte sikker brug til én opgave uden at bevise generel intelligens, universel retfærdighed eller egnethed til enhver befolkningsgruppe. Den kan understøtte en frigivelse under en defineret implementeringsprofil uden at bevise, at en ikke-registreret konfiguration vil opføre sig på samme måde. Ikke-krav er ikke beskedenhedsdekorationer. De forhindrer, at et snævert resultat spreder sig gennem en organisation som et langt større løfte.

Der er en nyttig europæisk instinkt bag denne præcision. Forordning 402/2013 beder en jernbaneansøger om at beslutte, om en ændring er væsentlig, at vælge et princip for risikoakcept og, hvor det er relevant, at anvende en uafhængig vurdering. Ansøgeren bliver ikke bedt om at bevise, at enhver tænkelig fremtidig jernbanetilstand er sikker. Ansøgeren bliver bedt om at gøre den aktuelle ændring og dens grænseflader forståelige nok til en forholdsmæssig beslutning. AI-teams kan låne samme disciplin. Navngiv ændringen, navngiv driftskonteksten, og gør grænsen synlig.

Farer er tilstande, ikke overskrifter

En fare er en tilstand, der kan føre til skade. Forskellen er mere nyttig, end den umiddelbart ser ud. En forkert ydelsesbeslutning er et resultat. En fare kan være en ufuldstændig registrering kombineret med et system, der præsenterer en ubegrundet anbefaling som klar til godkendelse. En forsinket vedligeholdelsesadvarsel er et resultat. En fare kan være et forældet sensorfeed, som arbejdsgangen behandler som aktuelt. Et privatlivsbrud er et resultat. En fare kan være en for bred søgetilladelse kombineret med et værktøj, der kopierer kildemateriale ind i en varig registrering.

At beskrive farer på denne måde flytter opmærksomheden opstrøms. Det gør design- og driftskontroller mulige. Hvis faren er en ubegrundet anbefaling præsenteret med utilbørlig autoritet, kan en kontrol kræve kildedokumentation, synliggøre usikkerhed, begrænse handlingen og tilbyde en gennemgangsrute. Hvis faren er forældet input, kan en kontrol kontrollere friskhed, markere datastatus, blokere handlingen eller henvise til en person. Hvis faren er overdreven adgang, kan en kontrol begrænse søgning, adskille identiteter, redigere output og registrere adgangsbeslutningen. Kontrollen bør adressere tilstanden, ikke blot love at være forsigtig omkring resultatet.

Fareanalyse bør omfatte forudsigelig misbrug, ikke kun formålet beskrevet i et indkøbsdokument. AI-forordningen gør dette eksplicit for højrisikosystemer. Artikel 9 kræver evaluering af risici, når et system bruges som tilsigtet og under rimeligt forudsigeligt misbrug. Misbrug betyder ikke enhver absurd anmodning. Det betyder anvendelser, som et kompetent team kunne forudse ud fra grænsefladen, incitamenter, instruktioner og den omkringliggende arbejdsgang. Hvis den hurtigste rute i systemet er at acceptere en anbefaling uden at læse dens dokumentation, hører den rute med i analysen, selvom politikken siger, at gennemgang er påkrævet.

Farer lever også i grænsefladerne. En model kan producere en afgrænset anbefaling, men en integration kan omdanne den til en ubegrænset instruktion. En leverandør kan stille et versionsstyret endpoint til rådighed, men en deployment kan cache svar ud over gyldighedsperioden. En offentlig myndighed kan beholde beslutningsansvaret, men en kontrakt kan gøre leverandøren til den eneste part, der kan inspicere sporet. Systemgrænsen for en safety case skal følge den kausale vej til konsekvensen. At tegne grænsen omkring modellen alene er en effektiv måde at misse det arbejde, der gør modellen betydningsfuld.

Ikke alle farer fortjener samme behandling. Nogle kan reduceres gennem design. Nogle kræver proceduremæssige kontroller eller menneskelig gennemgang. Nogle kan overvåges og accepteres med betingelser. Nogle indikerer, at den foreslåede anvendelse ikke er passende. En safety case skal vise ræsonnementet, ikke skjule det bag en universel risikoscore. Den europæiske jernbanemetode tillader forskellige principper for risikoaccept, herunder praksiskoder, sammenligning med lignende dele af et system og eksplicit risikoestimering. Lærdommen er ikke, at én metode vinder alle steder. Lærdommen er, at metoden og dens egnethed til ændringen skal dokumenteres.

Antagelser er bærende

Ethvert sikkerhedsargument hviler på antagelser. Operatøren er uddannet. Kilden er aktuel. Tærsklen har den betydning, teamet tror, den har. Personen, der modtager alarmen, kan handle i tide. Den eksterne tjeneste vil være tilgængelig, eller der findes en fallback. Outputtet forbliver en anbefaling snarere end at blive en de facto beslutning. Organisationen vil opdage det, hvis en modelopdatering ændrer adfærd. Mange sikkerhedssvigt skyldes ikke, at en antagelse er urimelig. De skyldes, at en antagelse er usynlig.

En antagelse hører til i casen med en ejer og en måde at kontrollere den på. Hvis argumentet afhænger af uddannede reviewere, skal casen angive den nødvendige kompetence, hvordan den etableres, og hvad der sker, når bemandingen ændres. Hvis argumentet afhænger af, at en kilde forbliver inden for et friskhedsvindue, skal systemet registrere friskheden og lade handlingen afhænge af det, hvor det er nødvendigt. Hvis argumentet afhænger af, at en integration bevarer et felt, skal interfacekontrakten og en test gøre afhængigheden synlig. En antagelse, der ikke kan kontrolleres, er en risiko med et blødere navn.

Antagelser kan handle om omverdenen såvel som softwaren. Et hospital kan afhænge af en klinisk vej. En jernbaneoperatør kan afhænge af en signalinterface. Et offentligt organ kan afhænge af en lovbestemt proces og af, at en menneskelig beslutningstager bevarer autoritet. En producent kan afhænge af, at vedligeholdelse udføres inden for et defineret interval. Safety casen kontrollerer ikke alle eksterne forhold. Den skal dog sige, hvilke forhold den antager, hvilken part der ejer dem, og hvordan en ændring genkendes.

Når antagelser ændrer sig, skal casen ikke stille og roligt strække sig. Et team kan starte med en anbefalingskun-anvendelse og derefter tilføje en automatisk overdragelse, fordi anbefalingen ofte er blevet accepteret. Modellen er ikke ændret, men autoriteten og faren er. En dataleverandør kan tilføje en ny kategori, der virker harmløs, indtil den ændrer betydningen af en nedstrømsregel. En deployment kan flytte fra uddannede specialister til et generelt supportteam. Dette er caseændringer, selvom versionsnummeret på modellen forbliver det samme.

Antagelser er især vigtige for probabilistiske systemer, fordi et stabilt gennemsnit kan skjule en ustabil kant. Casen skal identificere, hvor systemet forventes at være usikkert, hvilke beviser der signalerer denne usikkerhed, og hvilken menneskelig eller teknisk kontrol der overtager. Målet er ikke at lade som om, usikkerhed kan elimineres. Det er at forhindre, at en uudtalt forventning om sikkerhed bliver den operative politik.

Bevis er ikke et pas til enhver kontekst. Dets antagelser afgør, hvor langt det kan rejse.

Bevis kræver en ubrudt kæde

Bevis i en sikkerhedsargumentation er mere end et resultat kopieret ind i en tabel. Det har en identitet, en rækkevidde, en dato, en metode, en ansvarlig person eller et team og en relation til den påstand, det understøtter. En test kræver en defineret input og konfiguration. En gennemgang kræver et spørgsmål og en beslutning. En øvelse kræver en forventet respons og en observation. En log kræver tilstrækkelig kontekst til at kunne fortolkes uden at stole på hukommelse. En kildepost kræver et spor for oprindelse. Detaljerne varierer efter domæne, men princippet er stabilt: bevis skal kunne inspiceres efter det møde, hvor det lød overbevisende.

AI-forordningen giver dette princip juridisk vægt for højrisikosystemer. Artikel 11 kræver, at teknisk dokumentation er tilgængelig, før systemet bringes på markedet, og at den holdes ajour. Artikel 12 kræver automatisk registrering af relevante hændelser i hele systemets levetid, med logningskapacitet, der står i forhold til det tilsigtede formål og er nyttig til at identificere risici, understøtte overvågning efter markedsføring og overvåge drift. Artikel 13 kræver information, der giver udbydere mulighed for at forstå kapaciteter, begrænsninger, forudsigelige risici, menneskeligt tilsyn og krav til input. En sikkerhedsargumentation forbinder disse registreringer i stedet for at lade dem ligge i separate compliance-skuffer.

Bevis skal bevare sine betingelser. Et præstationsresultat uden sin testpopulation kan misforstås. Et robusthedsresultat uden de anvendte perturbationer kan overvurderes. En menneskelig faktor-gennemgang uden den arbejdsgang og det tidspres, den blev udført under, kan blive til en generel kompliment. En hændelseslog uden den version, datatilstand og de tilladelser, der var gældende, kan producere en tiltalende, men forkert rodårsag. Jo mere konsekvensbesværlig beslutningen er, desto mindre acceptabelt er det at adskille et resultat fra de omstændigheder, der gjorde det sandt.

Bevis kan være kvalitativt eller kvantitativt. En dokumenteret ekspertvurdering kan være gyldigt bevis, når spørgsmålet er passende, ekspertisen er identificeret, og begrundelsen er registreret. En numerisk score kan være svagt bevis, når nævneren, tærsklen eller testbetingelserne er uklare. Der er intet moralsk hierarki, hvor et tal automatisk overgår en omhyggelig observation. Argumentationen skal forklare formålsegnethed og usikkerhed, ikke udvise ærbødighed for decimaler.

Sporbarhed gør også uenighed produktiv. En reviewer skal kunne sige, hvilken påstand der ikke er understøttet, hvilken antagelse der er for optimistisk, eller hvilken kontrol der ikke er blevet udøvet. Sagen bliver dermed et fælles objekt for udfordring frem for en ceremoniel godkendelsespakke. Det er en af grundene til, at sikkerhedskritiske industrier investerer i uafhængig vurdering og strukturerede assurance-rapporter. Målet er ikke at gøre uenighed behagelig. Det er at gøre uenighed lokaliserbar.

Restrisiko er en beslutning, ikke en rest

Risiko forsvinder ikke, fordi der er tilføjet kontroller. Den risiko, der er tilbage efter kontroller, er restrisiko. Den skal beskrives og accepteres af en myndighed, der er i stand til at forstå evidensen, pålægge betingelser og standse brugen, når betingelserne ikke er opfyldt. At kalde en risiko acceptabel er ikke det samme som at sige, at den er lille. Det betyder, at organisationen har truffet en velovervejet beslutning om den resterende eksponering i en defineret kontekst og ikke har skjult grundlaget for den beslutning.

Artikel 9 i AI-forordningen bruger dette sprog direkte for højrisikosystemer. Den relevante restrisiko forbundet med hver fare og den samlede restrisiko skal vurderes som acceptabel. Forordningen kræver også eliminering eller reduktion, hvor det er teknisk muligt, samt afbødende og kontrollerende foranstaltninger, hvor risici ikke kan elimineres. Det er en nyttig rækkefølge. Ændr først designet, når det er muligt. Tilføj derefter kontroller. Registrér derefter, hvad der er tilbage. En advarselsetiket er ikke en undskyldning for at beholde en forebyggelig fare i arkitekturen.

Restrisiko bør omfatte reversibilitet. AI-forordningens risikokriterier overvejer, om et udfald kan korrigeres eller vendes, og bemærker, at negative virkninger på sundhed, sikkerhed eller grundlæggende rettigheder ikke bør behandles som let korrigerbare, blot fordi der findes en teknisk fortryd-knap. Det er en stille, men vigtig skelnen. Et udkast kan korrigeres. Et tabt gode, en afvist tjeneste eller en offentlig beskyldning kan være langt sværere at reparere. Sagen bør tildele stærkere kontroller, hvor den berørte person ikke realistisk kan fravælge eller fortryde resultatet.

Accept skal have betingelser. Et system kan accepteres til et afgrænset pilotforløb, et trænet team, en navngiven datakilde og en gennemgangsproces. Det må ikke accepteres til en anden population, en ubemandet arbejdsgang eller en integration, der fjerner evidens. Betingelser bør formuleres, så en operatør kan se, om de stadig er opfyldt. Hvis en betingelse blot er, at brugerne vil udvise dømmekraft, har sagen ikke sagt, hvordan systemet understøtter dømmekraft, eller hvad der sker, når arbejdsbyrden gør dømmekraft vanskelig.

En beslutning om restrisiko kræver også en udløbsdato eller en gennemgangsudløser. En fast kalenderdato kan hjælpe, men hændelser er normalt mere informative: en modelændring, en ny kilde, en væsentlig hændelse, et driftssignal, en ændring i brugere, en ny juridisk forpligtelse eller en fejlet kontroløvelse. Beslutningen er ikke en amulet, der placeres på udgivelsen. Det er en tilladelse med en vedligeholdelsesplan.

Menneskeligt tilsyn skal have autoritet

Menneskeligt tilsyn nævnes ofte, som om en person, der står et sted i nærheden af outputtet, gør systemet sikkert. AI-forordningen er mere krævende. Artikel 14 siger, at højrisikosystemer skal designes, så fysiske personer effektivt kan føre tilsyn med dem under brug. Tilsyn skal stå i forhold til risiko, autonomi og kontekst. De personer, der tildeles opgaven, bør forstå kapaciteter og begrænsninger, opdage anomalier, genkende automatiseringsbias, fortolke output, beslutte ikke at bruge eller tilsidesætte det samt gribe ind eller standse systemet gennem en sikker procedure.

Det er designkrav i lige så høj grad som bemandingskrav. En reviewer kan ikke fortolke et output, hvis evidensen er skjult. En reviewer kan ikke udfordre en anbefaling, hvis grænsefladen kun tilbyder accept som den bekvemme vej. En reviewer kan ikke stoppe et system, hvis stop-handlingen kræver en tilladelse, som ingen har givet. En reviewer kan ikke føre meningsfuldt tilsyn, hvis vedkommende kun måles på gennemløb. En safety case bør derfor behandle den menneskelige rolle som en kontrol med input, autoritet, arbejdsbyrde, træning og observerbar adfærd.

Autoritet er den detalje, som pæne beskrivelser udelader. Hvem må sætte arbejdsgangen på pause. Hvem må omgøre en handling. Hvem kan erklære, at en antagelse ikke længere holder. Hvem kan kontakte leverandøren. Hvem ejer registreringen. Hvem beslutter, om den resterende risiko stadig er acceptabel. Hvis ingen har autoriteten, er human-in-the-loop-beskrivelsen teater. Personen kan måske se outputtet, men at se er ikke at styre.

Godt tilsyn er også selektivt. Målet er ikke at sende ethvert trivielt udkast til en komité. Det er at placere menneskelig dømmekraft, hvor konsekvenserne, usikkerheden eller anfægteligheden kræver det. Nogle sager kan håndteres med strukturerede kontroller. Nogle kræver en uddannet specialist. Nogle kræver to uafhængige bekræftelser i henhold til gældende lov. Nogle bør afvises. Casen bør forklare udvælgelsen og demonstrere, at den valgte vej er tilgængelig i faktisk drift, ikke kun i en proceduremanual.

Der er en beskeden form for respekt i at designe på denne måde. Den anerkender, at mennesker bliver trætte, at køer vokser, at grænseflader former opmærksomhed, og at en advarsel, der vises hundrede gange, kan holde op med at være en advarsel. Safety engineering har lært dette gennem erfaring på tværs af transport og industri. AI-teams behøver ikke at gentage hver lektion ved at køre et forebyggeligt eksperiment på offentligheden.

Forandring bliver ved med at vandre ind i casen

En safety case er levende, fordi systemet er levende. Modelversionen kan ændre sig, men det kan prompten, retrieveringsindekset, taksonomien, politikken, hardwaren, bemandingen, grænsefladen, datakilden eller leverandøren også. En lille ændring kan ugyldiggøre en antagelse eller flytte en kontrol. Den resulterende risiko kan være højere, lavere eller blot anderledes. Det korrekte svar er ikke at fryse systemet for evigt. Det er at gøre forandring synlig, klassificere dens betydning og beslutte, hvilke dele af argumentet der skal genbesøges.

Jernbanepraksis tilbyder et klart mønster. Forordning 402/2013 anvender sin fælles metode, når tekniske, operationelle eller organisatoriske ændringer påvirker jernbanesystemet. Forslagsstilleren vurderer ændringens betydning og bruger, når det er nødvendigt, principper for risikoaccept og uafhængig vurdering. Forordningen advarer også om, at helheden af ændringer siden den sidste risikoproces kan have betydning. Flere små ændringer kan lægge sig sammen til en betydelig en. AI-styring har brug for den samme mistanke over for uskyldigt udseende trin.

For AI bør en ændringsregistrering identificere, hvad der flyttede sig, og hvad der ikke gjorde. Ændrede modelvægtene sig. Ændrede evidensindsamlingen sig. Ændrede værktøjstilladelserne sig. Ændrede brugerpopulationen sig. Flyttede tærsklen sig. Blev arbejdsgangen automatisk på et punkt, der tidligere var rådgivende. Forblev fallback-stien tilgængelig. Fangede evalueringen den nye tilstand. Registreringen bør forbinde hvert svar med den berørte påstand, fare, kontrol eller antagelse og specificere de tests eller reviews, der er nødvendige før udgivelse.

Ændringsstyring bør omfatte en sikker udgivelsestilstand. En skyggekørsel, en trinvis rute, en begrænset population, en eksplicit rollback-betingelse eller en menneskelig bekræftelse kan forhindre, at den nye adfærd bliver en institutionsdækkende kendsgerning, før nogen har inspiceret den. Disse mekanismer er ikke evidens for, at systemet er svagt. De er evidens for, at organisationen forstår, at ny adfærd har brug for et sted at lære.

Overvågning efter markedsføring udvider sagen efter udgivelsen. Artikel 9 henviser til data indsamlet via artikel 72, og artikel 72 kræver et dokumenteret overvågningssystem for højrisikosystemer gennem hele deres levetid. Overvågningen bør se efter de signaler, der betyder noget for påstanden: ændrede fejlmønstre, usædvanlige afvisninger, uventet brug, resultater af klager, manglende dokumentation, sikkerhedshændelser og svigt i menneskelige kontroller. Et dashboard, der kun rapporterer oppetid, er en munter måde at overse et sikkerhedsproblem på.

Uafhængig vurdering er en nyttig gene

De, der har bygget et system, kender dets elegance, dets genveje og de pres, det blev leveret under. Den viden er nødvendig. Den er ikke tilstrækkelig til at acceptere risikoen. En uafhængig vurdering skaber plads til, at nogen kan udfordre argumentet uden at bære de samme lanceringsincitamenter. Uafhængighed kræver ikke fjendtlighed eller en ekstern logo på hver side. Den kræver kompetence, omfang, adgang til dokumentation og autoritet til at registrere en uenighed, som ejeren ikke bare kan slette.

Den europæiske jernbanemetode gør denne adskillelse konkret. ERA beskriver et vurderingsorgan, der er ansvarligt for at kontrollere den korrekte anvendelse af risikovurderingsprocessen og dens resultater, med krav til kompetence, akkreditering eller anerkendelse. Forordningen tillader en uafhængig og kompetent ekstern eller intern enhed, forudsat at den opfylder kriterierne. Designet er proportionelt frem for teatralsk. Det anerkender, at sikkerhedsdokumentation kan være intern, når uafhængigheden er reel, og at et mærke ikke kan redde en revisor, der ikke kan se den relevante dokumentation.

For AI kan uafhængighed lagdeles. En domæneejer kontrollerer, at brugen er legitim, og at fareanalysen afspejler arbejdet. En ingeniørrevisor kontrollerer integration og fejltilstande. En sikkerhedsrevisor tester adgangs- og manipulationsveje. En driftsrevisor kontrollerer arbejdsbyrde, eskalering og genopretning. En governance- eller compliancefunktion kontrollerer registreringer og pligter. For anvendelser med store konsekvenser kan en ekstern vurdering eller et bemyndiget organ være påkrævet i henhold til den relevante lovgivning. Sikkerhedssagen bør angive den rolle, hver revisor spiller, og de spørgsmål, de har lov til at stille.

Uafhængighed er også en beskyttelse mod leverandørens uigennemsigtighed. En leverandørrapport kan understøtte en påstand, men udbyderen skal vide, hvad der blev testet, under hvilken konfiguration og hvilke begrænsninger der fortsat gælder. Hvis et kritisk resultat ikke kan genskabes, inspiceres eller overføres, når kontrakten udløber, hører afhængigheden med i sagen. Indkøb bør kræve adgang til dokumentation, versionsidentitet, hændelsesmeddelelser, ændringsmeddelelser, eksport, rollback og en praktisk exit. Ordet praktisk gør et stort stykke arbejde her. En ret, der ikke kan udøves under tidspres, er ikke meget af en kontrol.

En god vurdering producerer mere end et godkendelsesstempel. Den registrerer betingelser, åbne fund, dokumentationsmangler, resterende risiko og nødvendig opfølgning. Nogle gange er den rigtige beslutning at udgive med begrænsninger. Nogle gange er den at udsætte. Nogle gange er den at afvise den foreslåede brug. En sikkerhedskultur er ikke en, hvor hver sag består. Det er en, hvor beslutningen følger argumentet.

Hvad AI-forordningen tilføjer til argumentet

AI-forordningen gør ikke enhver AI-udrulning til en jernbane. Den etablerer et europæisk vokabular for risikostyring, teknisk dokumentation, logning, gennemsigtighed, menneskeligt tilsyn, nøjagtighed, robusthed og cybersikkerhed for højrisikosystemer. En sikkerhedssag kan hjælpe en organisation med at samle disse pligter i en operationel forklaring i stedet for at behandle hver artikel som en separat complianceopgave.

Artikel 8 knytter overholdelse til det tilsigtede formål og den almindeligt anerkendte teknologiske standard og giver mulighed for, at nødvendig testning, rapportering, information og dokumentation kan integreres i eksisterende EU-harmoniseringsprocedurer, hvor et produkt allerede er omfattet af dem. Det er vigtigt for sikkerhedsteknik. Den anerkender, at et system allerede kan have en moden assuranceproces, og at det er mindre nyttigt at duplikere filer end at forbinde dem. Sagen bør vise, hvor AI-dokumentationen indgår i det bredere produkt- eller serviceargument.

Artikel 11 og bilag IV giver den tekniske dokumentation en bred form. Den omfatter tilsigtet formål, versioner, grænseflader, hardware, udviklingsmetoder, arkitektur, dataoprindelse og -karakteristika, menneskeligt tilsyn, forudbestemte ændringer, validerings- og testprocedurer, målinger, testlogfiler og cybersikkerhedsforanstaltninger. Dette er ikke det samme som en sikkerhedsbegrundelse, men den leverer mange af de objekter, som en sikkerhedsbegrundelse har brug for. Et team kan knytte hvert objekt til en påstand og afdække, hvad der stadig ikke har en ejer eller dokumentation.

Logkravet i artikel 12 er særligt praktisk. Hvis et højrisikosystem teknisk set skal muliggøre automatisk registrering af hændelser i hele dets levetid, bør frigivelsesbeslutningen stille spørgsmål om, hvad systemet faktisk kan rekonstruere. Hvilken input, model, konfiguration, dokumentation, værktøjskald, menneskelig indgriben og efterfølgende handling kan forbindes. Hvilke logfiler er under udbyderens kontrol, og hvilke er under implementørens. Hvordan beskyttes og opbevares de. Kan en berørt person eller myndighed forstå den relevante vej uden at modtage en dump af uvedkommende personoplysninger.

Artikel 15 tilføjer et livscyklusperspektiv på nøjagtighed, robusthed og cybersikkerhed, herunder modstandsdygtighed over for fejl, mangler og inkonsistenser og, hvor relevant, backup- eller fail-safe-planer. En sikkerhedsbegrundelse giver disse ord et sted at lande. Påstanden er ikke, at en score er høj. Påstanden er, at systemet præsterer konsekvent til dets tilsigtede formål, at kendte fejltilstande er afgrænset, og at arbejdsgangen har en sikker reaktion, når de opstår. Dokumentationen skal angive de betingelser, under hvilke konklusionen gælder.

Forordningens forpligtelser gælder afhængigt af systemet, udbyderen, implementøren og anvendelsen. En sikkerhedsbegrundelse bør ikke lade som om, at en generel skabelon afgør klassificering eller juridisk rådgivning. Den bør registrere anvendelighedsbeslutningen, dens begrundelse og de punkter, der ville ændre den. Dette er endnu en fordel ved eksplicitte antagelser. Når en kendsgerning ændrer sig, ved organisationen, hvilken del af argumentet der kræver opmærksomhed, i stedet for at skulle genopdage hele det juridiske landskab i panik.

Luftfart behandler læring som en del af assurance

Det Europæiske Luftfartssikkerhedsagenturs AI-konceptpapir, udgave 2, er nyttigt, fordi det ikke beskriver AI-sikkerhed som en enkelt modelegenskab. Papiret forfiner vejledningen til niveau 1-applikationer, der forbedrer menneskelige evner, og uddyber arbejdet med læringsassurance, AI-forklarlighed og etikbaseret vurdering. Det adresserer også niveau 2-systemer, hvor AI kan træffe beslutninger automatisk under menneskeligt tilsyn, og fremhæver menneske-AI-samarbejde og design af sikker interaktion.

Den vigtige idé er ikke, at enhver organisation skal kopiere luftfartsterminologi. Det er, at assurance skal følge forholdet mellem systemet og det menneskelige arbejde. En model, der hjælper en uddannet operatør, er ikke det samme sikkerhedsproblem som en model, der beslutter, mens en person blot fører tilsyn. Operatørens evne til at forstå, gribe ind og genoprette er en del af systemet. Det samme gælder grænserne omkring læring, opdateringer og dokumentation. EASA-papiret giver AI-teams et europæisk eksempel på en industri, der forsøger at gøre disse forhold eksplicitte før implementering.

Læringssikkerhed er et nyttigt udtryk, fordi maskinlæring kan ændre den sædvanlige evidensfortælling. En konventionel softwareudgivelse kan testes mod en defineret implementering. Et adaptivt system kan ændre sin adfærd, når data, tilstand eller miljø ændrer sig. Sikkerhedsargumentationen skal derfor fastlægge, hvad der må lære, hvad der er frosset, hvordan ændringen registreres, hvilken evidens der opdateres, og hvornår systemet igen gennemgår en acceptproces. Hvis læring ligger uden for argumentationen, handler argumentationen om gårsdagens system.

Menneskelig-AI-samarbejde ændrer også betydningen af tilsyn. Mennesket er ikke en nødbremses, der er fastgjort til en maskine, der er designet uden en fører. Teamet er et socioteknisk arrangement med roller, forventninger, signaler, autoritet og træning. En sikker interaktion kan kræve, at maskinen forklarer en begrænsning, anmoder om bekræftelse, afviser en handling eller gør usikkerhed synlig. Det kan kræve, at mennesket udfordrer maskinen, og at organisationen belønner den udfordring. Evidensen bør undersøge interaktionen snarere end at udlede den fra en politikformulering.

Igen er der ingen opfundet flyvning eller ulykke nødvendig for at gøre pointen. Et offentligt agenturs konceptpapir er nok til at vise, at europæisk sikkerhedstænkning bevæger sig mod læring, menneskelig interaktion og sikkerhedsargumentation som ét designproblem. AI-teams kan læse materialet som en opfordring til at spørge, hvad deres eget system lærer, hvad operatøren kan se, og hvilken evidens der overlever en ændring.

En sammensat udgivelsesport, mærket som sådan

Illustrativ sammensætning, ikke en rapporteret hændelse: forestil dig en offentlig tjeneste, der overvejer et AI-værktøj, som hjælper medarbejdere med at organisere indkommende sagsmateriale, før en person træffer beslutningen. Værktøjet er ikke autoriseret til at afgøre berettigelse, sende en meddelelse eller lukke en sag. Det foreslåede sikkerhedskrav er snævert: uddannede medarbejdere kan bruge værktøjet til at forberede en gennemgangskø, når kildejournalen er komplet, evidenspanelet er synligt, anbefalingen er tydeligt markeret som en anbefaling, og medarbejderen kan tilsidesætte, pause eller fjerne den.

Den første gren af argumentationen navngiver farer. En ufuldstændig journal kunne få en tilsyneladende sammenhængende prioritet. Et forældet politikdokument kunne forme anbefalingen. En kø kunne lægge pres på en gennemgående person til at acceptere rækkefølgen uden at kontrollere. En tilladelsesfejl kunne eksponere én persons materiale i en anden sag. En leverandøropdatering kunne ændre betydningen af en kategori. Disse er ikke påstande om, at sådan en hændelse er sket. Det er forhold, som teamet med rimelighed kan forudse ud fra det foreslåede design.

Den næste gren navngiver kontroller. Inputkomplethed og friskhed kontrolleres, før en anbefaling vises. Evidensen, der bruges til forslaget, er synlig ved siden af sagen. Handlingen forbliver et udkast, indtil en uddannet person accepterer eller ændrer den. En manglende kilde ruter elementet til en anden sti. Tilladelser testes ved genfindingsgrænsen, ikke kun ved brugergrænsefladen. Arbejdsgangen har en pausekontrol og en manuel rute. En versionsændring kører i en begrænset tilstand og kan rulles tilbage. Sagen registrerer, hvorfor hver kontrol findes, og hvilken fare den adresserer.

Evidens skal derefter udøve kontrollerne. En datatest leverer ufuldstændige og forældede journaler og registrerer resultatet. En brugervenlighedsgennemgang undersøger, om medarbejdere kan finde evidensen og forstå anbefalingen under realistisk arbejdsbyrde. En adgangstest kontrollerer, at en sag ikke kan hente materiale uden for sit omfang. En udgivelsesprøve verificerer, at pause- og tilbagerulningsstierne fungerer. En ændringsgennemgang bekræfter, at den nye kategori og politik ikke ugyldiggør kølogikken. Disse er hypotetiske tests i denne sammensætning, ikke rapporter om tests udført af en navngiven tjeneste.

Beslutningen er betinget. Værktøjet kan bruges til forberedelse af køen inden for det angivne omfang. Det kan ikke bruges til at træffe eller kommunikere den materielle beslutning. Betingelsen om, at personalet skal have beføjelse til at tilsidesætte, er tildelt en rolle. Betingelsen om, at kildens aktualitet registreres, overvåges. En ændring af modellen, politikken, datakontrakten, brugerpopulationen eller den efterfølgende handling genåbner sagen. Hvis organisationen ikke kan dokumentere disse betingelser, forbliver frigivelsesporten lukket. Historien er nyttig netop, fordi ingen behøver at lade, som om en bestemt by, et bestemt team eller en bestemt tirsdag eksisterede.

Et lille eksempel fra vores Trust Centre

Hos Dweve foretager vores offentlige Trust Centre en tilsvarende sondring i sin evalueringsjournal. Siden med evalueringer præsenterer en metode, der identificerer modellen, den nøjagtige suite, konfigurationen, den registrerede tilstand, dokumentationen og beslutningen fra revieweren. Den adskiller evalueringens identitet fra modellens skiftende tilstand, skelner mellem forberedt dækning og et faktisk resultat og beskriver replay som en kontrakt, der afhænger af det registrerede artefakt, eksekveringsgrafen, routing, rækkefølge, tilstand, begrænsninger, værktøjer og dokumentation. Siden angiver også, at der ikke fandtes noget første eksternt frigivelsesresultat pr. 1. august 2026, fordi denne frigivelse ikke var sket.

Det er et lille eksempel, ikke et bevis på, at en sikkerhedsbegrundelse er gennemført for enhver brug af vores systemer. Dets værdi er grænsen. En metode er ikke et resultat. En kategori er ikke en score. En planlagt frigivelse er ikke en historisk kørsel. En replaybar registreret tilstand er ikke det samme som en levende verden, hvis dokumentation og adaptive tilstand har ændret sig. Disse sondringer er præcis, hvad en sikkerhedsbegrundelse har brug for, når den angiver, hvor dokumentationen gælder, og hvor den ophører.

For en europæisk teknologivirksomhed kan det føles som at lade nyttig markedsføringsplads stå tom at offentliggøre sådanne begrænsninger. Det er mere nyttigt end at fylde pladsen med et tal, ingen kan forsvare. Den samme disciplin gælder for en offentlig myndighed, en leverandør, en forskningsgruppe eller et internt platformsteam. Angiv, hvilken dokumentation der findes, hvilken der er forberedt, hvilken der er beskyttet, hvilken der ikke blev indsamlet, og hvilken fremtidig begivenhed der ville skabe et nyt resultat. Læseren kan derefter beslutte, hvad dokumentationen understøtter.

Vores eksempel viser også, hvorfor et Trust Centre bør læses som et dokumentationsindeks snarere end et løfte. Den offentlige side peger på identitet, metode, registrering, gennemgang og frigivelsesgrænser. Den fjerner ikke behovet for at inspicere en bestemt implementering, et bestemt formål eller en bestemt berørt population. En sikkerhedsbegrundelse ville tilføje den lokale kontekst, farerne ved den faktiske arbejdsgang og autoriteten hos den person, der træffer beslutningen. Offentlig gennemsigtighed er en startflade, ikke et universelt certifikat.

Hvad en sikkerhedsbegrundelse kan bevise

En god sikkerhedsbegrundelse kan understøtte en afgrænset konklusion. Den kan vise, at et system blev designet til et navngivet formål, at forudsigelige farer blev identificeret, at kontroller adresserer disse farer, at dokumentation blev indsamlet under angivne betingelser, at resterende risici blev vurderet, at en kompetent myndighed accepterede eller afviste brugen, og at organisationen har en måde at opdage ændringer og genoverveje beslutningen på. Den kan gøre et argument tilstrækkeligt inspektérbart til udfordring og vedligeholdelse.

Den kan også vise, hvad der er usikkert. En begrundelse kan demonstrere stærk dokumentation for én population og begrænset dokumentation for en anden. Den kan vise, at systemet er robust over for en defineret klasse af fejlformede input, men ikke over for en ukendt klasse. Den kan vise, at et menneske kan gribe ind, når bemanding og tilladelser er som specificeret. Den kan vise, at en fallback findes, men endnu ikke er blevet afprøvet i fuld operationel skala. En sandfærdig begrundelse skjuler ikke disse asymmetrier. Den gør dem til brugsbetingelser.

En safety case kan også understøtte indkøbs- og ledelsesbeslutninger. En køber kan sammenligne de beviser, en leverandør tilbyder, med de beviser, arbejdsgangen har brug for. En tilsynsmyndighed kan se, hvilke påstande der er understøttet, og hvilke registreringer der mangler. En bestyrelse kan forstå, hvor den resterende risiko ligger, og hvem der ejer den. En operatør kan vide, hvilket signal der bør udløse en pause. Berørte personer kan få en klarere vej til at udfordre et resultat. Casen bliver et kort over ansvar, ikke bare en teknisk artefakt.

Den kan understøtte forandring uden at lade, som om forandring er gratis. Ved at forbinde påstande, farer, antagelser, kontroller og beviser kan organisationen identificere den mindste meningsfulde revurdering, når en komponent ændres. Det er mere effektivt end at gentage hver test blindt og sikrere end at antage, at ingen revurdering er nødvendig. Proportionalitet virker kun, når strukturen er synlig. Ellers ender et team enten med at udføre ritualer eller tage genveje.

Hvad en safety case ikke kan bevise

En safety case kan ikke bevise, at skade aldrig vil ske. Virkelige systemer møder forhold, der ikke var forudset, og mennesker reagerer på incitamenter og pres på måder, intet diagram fuldt ud kan forudsige. Formålet er ikke sikkerhed. Det er et disciplineret grundlag for at drive, lære og stoppe, når grundlaget ikke længere holder.

Den kan ikke bevise, at en model er generelt intelligent, generelt fair eller sikker på alle områder. Beviser har en rækkevidde. En test på ét datasæt afgør ikke resultatet for et andet. En vellykket gennemgang i én arbejdsgang etablerer ikke samme autoritet i en anden. En veldesignet stopvej beviser ikke, at enhver operatør vil bruge den uden træning, tid eller organisatorisk støtte. Casen skal modstå trangen til at gøre lokale beviser til et globalt adjektiv.

Den kan ikke overføre ansvar til en leverandør, revisor eller certificeringsmærke. Beviser kan være produceret af en anden, men udbyderen har stadig en anvendelse, en arbejdsgang og mennesker, der afhænger af resultatet. Kontrakter kan fordele opgaver og give adgang. De kan ikke gøre en organisation uvidende om det system, den driver. Et certifikat kan heller ikke undskylde en ændring, der flytter systemet uden for det vurderede omfang.

Den kan ikke gøre en forbudt eller uegnet anvendelse acceptabel ved at tilføje papirarbejde. Hvis faren ikke kan kontrolleres til et acceptabelt niveau, kan svaret være at ændre formålet eller ikke at udrulle. Safety cases beskrives ofte som assurance, men det mest værdifulde resultat kan være et velunderbygget nej. En komplet fil kan stadig understøtte en dårlig beslutning, hvis argumentet er svagt. Pointen med filen er at gøre beslutningen bedre, ikke blot mere læsbar, efter den er truffet.

Endelig kan den ikke erstatte lov, professionel dømmekraft eller demokratisk ansvarlighed. Det er et teknisk og ledelsesmæssigt instrument. Den skal hjælpe folk med at forstå beslutningen og dens betingelser, ikke lade, som om den afgør spørgsmål, der tilhører domstole, tilsynsmyndigheder, klinikere, offentlige embedsmænd eller de berørte.

Spørgsmål til et europæisk release-møde

Et team behøver ikke at vente på en perfekt standard eller en 400-siders mappe for at begynde. Det kan stille en række enkle spørgsmål. Hvad præcist hævder vi, at dette system må gøre. Hvem er berørt, når det tager fejl. Hvilke farer er betingelser i systemet og arbejdsgangen frem for vage dårlige udfald. Hvilke antagelser skal forblive sande. Hvilke beviser understøtter hver påstand, og under hvilken konfiguration og population. Hvad forbliver usikkert. Hvem accepterer den resterende risiko. Hvem kan stoppe systemet. Hvilken hændelse ville genåbne argumentet.

Mødet bør give plads til et mindre behageligt spørgsmål: hvad skulle få os til at nægte udgivelsen. Hvis det eneste svar er en lavere score, har teamet formentlig ikke beskrevet sine risici. En nægtelse kan udløses af manglende dokumentation, en uforvaltet antagelse, en mislykket genoprettelsesøvelse, en utilgængelig reviewer, en ubegrænset integration eller en ændring, der ikke kan gentages. At navngive nægtelsesbetingelserne gør sikkerhed til en operationel kontrol frem for en stemning.

Spørg, hvordan sagen følger med systemet. Kan en operatør finde det tilsigtede formål, begrænsninger og stoprute. Kan en hændeinvestigator identificere modellen, dokumentationen, tilladelserne og de menneskelige beslutninger, der havde betydning. Kan en køber eksportere registreringerne, hvis leverandøren skifter. Kan en tilsynsmyndighed få de oplysninger, der er nødvendige for at vurdere overensstemmelse. Kan et nyt team forstå, hvorfor en kontrol findes, uden at interviewe den person, der er gået. En sikkerhedssag, der kun lever i en privat mappe, er en skrøbelig hukommelse, ikke et levende argument.

Spørg, hvordan sagen ændrer sig. Hvad er review-udløseren for en modelopdatering, kildeændring, politikændring, ny brugergruppe, nyt værktøj, ny jurisdiktion eller ny downstream-handling. Hvilke evalueringer gentages, og hvilke antagelser kontrolleres. Hvad sker der, når overvågning finder et svagt signal, men endnu ikke en alvorlig hændelse. Er der en sikker, forvaltet rute til at pause og undersøge. En veldrevet organisation bør kunne svare uden at opfinde en krise for at få processen til at føles ægte.

Og spørg, om dokumentationen kan læses af de mennesker, hvis beslutning den skal understøtte. En teknisk fil, som ingen kan fortolke, er ikke gennemsigtig. En politik, som ingen kan anvende, er ikke en kontrol. Et dashboard fyldt med grønne celler, der skjuler nævneren, er ikke en beroligelse. Europæisk sikkerhedspraksis er bedst, når den gør ræsonnementet tilgængeligt for den person, der har ansvaret, ikke kun for den person, der samlede dokumentet.

Den stille fordel ved et ærligt argument

Sikkerhedssager ser bureaukratiske ud på afstand, fordi de indeholder registreringer, roller, betingelser og review-punkter. Tæt på er de en måde at holde ingeniørarbejdet ærligt, når systemer bliver overbevisende. De forhindrer en test i at udgive sig for at være en beslutning, en antagelse i at udgive sig for at være et faktum, en planlagt evaluering i at udgive sig for at være et resultat og en menneskelig tilstedeværelse i at udgive sig for at være autoritet.

Europa har allerede dele af denne disciplin i sine institutioner. Jernbaner behandler teknisk, operationel og organisatorisk ændring som et risikospørgsmål og bruger fælles metoder og uafhængig vurdering. Luftfartsvejledning diskuterer læringssikring, forklarbarhed og menneske-AI-samarbejde. AI-forordningen forener livscyklusrisikostyring med dokumentation, logfiler, gennemsigtighed, menneskeligt tilsyn og livscykluspræstation. Disse er ikke identiske rammer, og de bør ikke flades ud til én tjekliste. De deler dog en respekt for betingelser, dokumentation og ansvar.

Den praktiske lektie er enkel nok til at tage med til et mandagsmøde. Begynd med en påstand, der har kanter. Navngiv de risici, der kunne gøre den falsk. Registrer de antagelser, der lader den stå. Placer kontroller, hvor arbejdet faktisk sker. Vedhæft dokumentation med identitet og omfang. Vurder restrisiko frem for at skjule den. Giv en person reel autoritet til at gribe ind. Genåbn argumentet, når systemet eller konteksten ændrer sig. Lad en uafhængig reviewer være ubekvem. Offentliggør begrænsninger med samme omhu som succeser.

Den tilgang vil ikke gøre alle AI-systemer sikre, og den vil ikke forvandle usikkerhed til sikkerhed. Den vil gøre usikker selvtillid sværere at opretholde. Den vil give operatører en rute til at pause, give reviewers noget konkret at udfordre og give berørte mennesker en bedre forklaring på, hvor ansvaret ligger. Den vil også gøre gode systemer lettere at forbedre, fordi organisationen kan se, hvilken del af argumentet der ændrede sig.

En sikkerhedscase er derfor ikke et afsluttende afsnit efter ingeniørarbejdet. Det er tråden, der binder formål, design, mennesker, evidens og forandring sammen. Europa kan lære af sikkerhedscases, fordi de tilbyder en borgerlig version af ingeniørdisciplin: intet slogan accepteres uden en rute, ingen rute accepteres uden evidens, og ingen evidens får lov til at rejse længere end dens forudsætninger.

Kilder