Kan en tilsynsmyndighed revidere et bevægeligt mål?

Ja, men ikke ved at lade, som om et adaptivt system er et statisk objekt. En revision kræver en fastfrosset tilstand, en afgrænset påstand, dokumentation...

Kan en tilsynsmyndighed revidere et bevægeligt mål?

En revision må gerne tage et fotografi

Et bevægeligt mål er ikke hævet over granskning. Det er kun hævet over den slags granskning, der stiller ét tidløst spørgsmål og forventer ét tidløst svar. Den forskel betyder noget. AI-systemer ændrer sig på flere måder på én gang. En udbyder frigiver en ny modelversion. En implementør ændrer prompten eller beslutningstærsklen. Et genfindingskorpus får et nyt politikdokument. En identitetsregel ændrer, hvem der må kalde et værktøj. Et værktøj får et felt, mister et felt eller begynder at returnere en anden betydning under samme feltnavn. Et menneskeligt team ændrer sin procedure. Den verden, der leverer inputtene, ændrer sig uden at spørge nogen release manager.

Intet af dette gør en revision nytteløs. Det gør revisionsobjektet mere præcist. Spørgsmålet er ikke, om en organisation kan bevise, at et system forbliver uændret for evigt. Det ville være en mærkelig løfte selv for en lommeregner forbundet til en database. Spørgsmålet er, om organisationen kan vise, hvilket system der var i drift på et relevant tidspunkt, hvad det skulle gøre, hvilke beviser der understøttede den brug, hvilke betingelser der afgrænsede beviserne, hvem der ejede beslutningen, og hvilken senere ændring der bør få beslutningen genåbnet.

En revision må gerne tage et fotografi. Den skal bare ikke kalde fotografiet for landskabet. En ordentlig registrering identificerer den tilstand, der blev inspiceret, og holder ruten fra den tilstand til den næste. Den kan så sige noget nyttigt: denne evaluering vedrørte denne model, disse indstillinger, denne datagrænse, disse værktøjer, denne politik, denne arbejdsgang og denne frigivelsesbeslutning. Den kan også sige noget mindre behageligt og mere værdifuldt: konklusionen rejste ikke automatisk videre til den næste tilstand.

Det er et bedre udgangspunkt end det velkendte teater med uforanderlige badges. Et badge antyder, at nogen har afgjort sagen. En revisionsregistrering bør gøre det muligt at se, hvad der blev afgjort, på hvilket grundlag, til hvilken brug, og hvor længe det grundlag forblev gældende. En tilsynsmyndighed har ikke brug for en frossen organisation. En tilsynsmyndighed har brug for en organisation, der kan skelne en frossen registrering fra en live-tjeneste uden at behandle nogen af delene som et mystisk objekt.

Europas AI-regler peger allerede i denne retning. For højrisiko-AI-systemer kræver forordningen om kunstig intelligens teknisk dokumentation, før et system bringes i omsætning eller tages i brug, og kræver, at den holdes ajour. Den kræver også automatisk registrering af relevante hændelser i hele systemets levetid og et dokumenteret overvågningssystem efter markedsføring, der står i forhold til teknologien og risikoen. Det er ikke instrukser om at tage et enkelt ceremonielt skærmbillede. Det er instrukser om at føre en bevissti gennem forandring.

Det bevægelige mål er normalt et system

Det er fristende at beskrive et AI-system som en model og derefter diskutere versionsstyring, som om en ny modelvægtfil var hele historien. Det er bekvemt til præsentationer og unøjagtigt for de fleste operationelle spørgsmål. En model er en vigtig komponent. Den er sjældent det komplette objekt, hvis adfærd påvirker en person, en arbejdsgang eller en juridisk forpligtelse.

Overvej en almindelig beslutningsstøtterute, beskrevet her som et hypotetisk eksempel snarere end en redegørelse for en reel implementering. En bruger indsender en anmodning. Tjenesten henter dokumenter, som den har tilladelse til at bruge. En model udarbejder en anbefaling. En regel kontrollerer, om de nødvendige beviser er til stede. En uddannet gennemgåer kan acceptere, ændre eller afvise anbefalingen. En arbejdsgang registrerer derefter en handling. Det observerede resultat afhænger af mere end modellen. Det afhænger af kildeversioner, genfindingsindstillinger, tilladelser, grænsefladetekst, tærskler, køregler, menneskelig autoritet og handlingsgrænsen.

Hvis kildekorpuset ændrer sig, kan modellen få et andet faktagrundlag uden at en eneste parameter ændres. Hvis en prompt ændrer sig, kan en model blive bedt om at foretage en anden form for vurdering. Hvis en reviewerskærm holder op med at vise usikkerhed, er den menneskelige kontrol, der er beskrevet i en risikofil, måske ikke længere den kontrol, som folk faktisk udøver. Hvis en integration begynder at anvende anbefalinger automatisk, har systemet fået en ny autoritet, selv hvis modelresponsen er identisk byte for byte.

Derfor begynder en fornuftig revisionsprotokol med det tilsigtede formål og systemafgrænsningen. AI-forordningens krav til teknisk dokumentation i bilag IV omfatter beskrivelser af tilsigtet formål, versioner, overvågnings- og kontrolfunktioner, validering og test, risikostyring, ændringer i livscyklussen og relevante præstationsmålinger. Pointen er ikke, at ethvert system har brug for en katedral af papirarbejde. Pointen er, at en revisor ikke kan vurdere en påstand, når det objekt, som påstanden henviser til, stille og roligt skifter form.

At kalde det bredere objekt for et system er ikke en måde at få arbejdet til at lyde mere imponerende. Det er en måde at undgå en kategorifejl. En modelevaluering kan besvare et modelspørgsmål. En systemrevision skal besvare et systemspørgsmål. Den første kan fastslå, hvordan en komponent opførte sig under definerede betingelser. Den anden skal vise, hvordan den komponent var forbundet med mennesker, data, regler, værktøjer og konsekvenser. Ingen af dem erstatter den anden. En modelscore er ikke en arbejdsgangsbeskrivelse, ligesom en god dæktest ikke er en ruteplan.

Hvad en revisor faktisk forsøger at fastslå

At revidere et system i forandring betyder ikke at gennemspille hvert øjeblik af dets liv i et mødelokale. Det betyder at gøre bestemte udsagn kontrollerbare. Blev systemet brugt inden for det angivne formål? Var frigivelsesbeslutningen understøttet af dokumentation, der passede til formålet? Bevarede organisationen de oplysninger, der var nødvendige for at undersøge et omtvistet resultat? Udløste meningsfulde ændringer en revurdering? Gjorde overvågningen forskellen mellem en harmløs opdatering og en væsentlig ændring synlig? Kunne de ansvarlige pause, begrænse eller korrigere ruten, når dokumentationen ikke længere holdt?

Det er praktiske spørgsmål, fordi hvert enkelt har en observerbar modpart. Det tilsigtede formål hører til i en protokol. En evaluering har en testsuite, konfiguration, testpopulation eller inputafgrænsning, metode, resultat og begrænsning. En frigivelsesbeslutning har en ejer og betingelser. En ændring har en identitet, en dato, en begrundelse og en vurderet effekt. Overvågning har navngivne signaler, tærskler eller udløsende gennemgange. En pauserute har en autoritet og en operation. Detaljerne varierer, men revisionsbarheden kommer fra at forvandle abstrakte forsikringer til noget, andre kan inspicere.

Der er en vigtig begrænsning her. En revision beviser ikke, at ethvert fremtidigt output vil være korrekt, fair eller harmløst. Den kan ikke forvandle en usikker verden til en deterministisk. Den kan fastslå, om en organisation fremsatte påstande, der var snævre nok til at undersøge, om den indsamlede dokumentation, der kunne understøtte disse påstande, og om den bevarede evnen til at genoverveje dem. Det lyder måske beskedent. Det er også her, ansvarligheden begynder.

Forskellen mellem dokumentation og forsikringssprog betyder noget. At sige, at en model blev evalueret, er endnu ikke dokumentation for en nyttig evaluering. Ordet har brug for et objekt. Evalueret mod hvilken opgave, hvilke kriterier og hvilke data? Med hvilken model og systemtilstand? Under hvilke driftsbetingelser? Hvem kontrollerede metoden? Hvad var uden for scope? Hvad ville gøre resultatet forældet? Uden disse spørgsmål er evaluering blot en beroligende datid.

Europa-Kommissionens tidligere etiske retningslinjer for pålidelig kunstig intelligens formulerede reproducerbarhed i klare vendinger: et AI-eksperiment bør udvise samme adfærd, når det gentages under samme betingelser. Det er en brugbar definition, fordi den indeholder sin egen begrænsning. De samme betingelser gør et reelt stykke arbejde. Et gentaget eksperiment kan vise, om den registrerede påstand er reproducerbar. Det kan ikke vise, at uændret adfærd vil opstå efter en ændret datakilde, politik eller implementeringsvej. Reproducerbarhed er derfor ikke et løfte om, at verden står stille. Det er en disciplin for præcist at angive, hvad der skete.

En indfanget evaluering er et øjebliksbillede. Revisionen bliver holdbar, når den næste tilstand kan sammenlignes med den.

Et versionsnummer er nødvendigt, men ikke tilstrækkeligt

Versionsnumre er nyttige, fordi de forhindrer en registrering i at lade som om, at navne er nok. Men en versionsetiket kan også skabe falsk tryghed. En etiket som version 4.2 kan identificere en softwareudgivelse, men den identificerer ikke nødvendigvis den effektive tilstand for en AI-vej. En konfigurationsværdi kan ligge uden for modelregistret. Et søgeindeks kan genopbygges fra skiftende dokumenter. Et feature-flag kan vælge en anden værktøjssti. En politikmotor kan ændre en tilladt handling. En tjeneste kan derfor have et upåklageligt formateret versionsnummer og stadig være svær at rekonstruere.

Det, der betyder noget, er den identitet, der passer til påstanden. Hvis påstanden vedrører en offline modelbenchmark, kan modelartefakten, inferenskoden, parameterindstillingerne, datasætversionen, metrikdefinitionen og eksekveringsmiljøet være afgørende. Hvis påstanden vedrører en live beslutningsstøttetjeneste, kan registreringen desuden have brug for prompten eller skabelonen, søgekonfigurationen, kildeidentifikatorer og friskhed, tilladelsesstatus, værktøjsskemaer, politikversion, reviewergrænseflade og arbejdsgangsregel. En revisionspakke behøver ikke at indeholde hver eneste byte fra hvert system. Den skal indeholde eller pålideligt pege på de elementer, der kan ændre betydningen af påstanden.

Derfor er et manifest ofte mere nyttigt end et arkiv, der er dumpet på en harddisk. Et manifest angiver, hvilke artefakter der hører sammen, deres identifikatorer, deres integritetsreferencer, deres relationer og deres adgangsbetingelser. Det giver en revisor mulighed for at lokalisere den relevante pakke uden at antage, at alle kilder kan kopieres ind i en ubegrænset mappe. Noget dokumentation indeholder personoplysninger, sikkerhedsfølsomme detaljer, licenseret materiale eller forretningshemmeligheder. Reviderbarhed kræver kontrolleret adgang og meningsfuld sporbarhed, ikke obligatorisk offentliggørelse af alt, der får et system til at fungere.

Bilag IV anlægger en tilsvarende praktisk tilgang. Det behandler ikke teknisk dokumentation som en kort produktbeskrivelse. Det kræver oplysninger om systemet og dets livscyklus, herunder ændringer foretaget under udviklingen og efter markedsføring, overvågnings- og kontrolfunktioner, validerings- og testprocedurer og -resultater, risikostyringsforanstaltninger samt en beskrivelse af præstationsmålinger. Dokumentet skal være tilstrækkeligt klart til, at nationale kompetente myndigheder og bemyndigede organer kan vurdere overensstemmelse. Med andre ord skal oplysningerne være tilrettelagt med henblik på granskning, ikke blot indsamlet, fordi der var et lagersystem til rådighed.

Der ligger et lille, men afgørende designspørgsmål bag alt dette: hvad skulle der ændre sig, før den tidligere dokumentation ikke længere kunne understøtte den nuværende påstand? Svaret skaber versionsgrænsen. Hvis en ny hentekilde ændrer det faktuelle grundlag for anbefalingerne, hører den til i identiteten. Hvis en ny grænseflade for gennemgående skjuler en advarsel, hører den til i identiteten. Hvis en kosmetisk redigering ikke kan påvirke den evaluerede adfærd, hører den formentlig til i ændringshistorikken, men ikke i evalueringsfingeraftrykket. God versionsstyring er ikke maksimal indsamling. Det er begrundet relevans.

Indfang kontrakten, ikke kun outputtet

Et output er dokumentation for noget, men det er ikke altid dokumentation for nok. Et skærmbillede kan vise, hvad der fremkom på en skærm. Det kan ofte ikke vise, hvilken model der producerede det, hvilken kilde der blev hentet, hvad et værktøj returnerede, hvilken regel der blev anvendt, hvilke input der blev udeladt, eller om visningen skjulte en advarsel. Dette er en af grundene til, at skærmbilleder ophobes i overensstemmelsesmapper med samme højtidelighed som arkæologiske fund og med betydeligt mindre forklaringskraft.

En indfanget kontrakt er rigere. Den binder resultatet til de betingelser, hvorunder systemet forventedes at handle. For en evaluering kan det omfatte den nøjagtige testsuite, inputtene eller en beskyttet reference til dem, de forventede påstande, model- og servicekonfigurationen, de relevante politik- og værktøjsversioner, udførelsesmiljøet, hvor det påvirker resultatet, og acceptreglen. For en livekørsel kan det omfatte anmodningens identitet, autoriseret omfang, kilde- og henteposter, modelrute, værktøjskald, kontroller, menneskelig indgriben og den resulterende tilstandsændring. Formålet er ikke at føre en endeløs dagbog. Det er at bevare tilstrækkeligt kausalt relevant information til at kunne stille et seriøst spørgsmål senere.

Der er en nyttig sondring at foretage. En evalueringsindfangning dokumenterer en påstand om en defineret test eller øvelse. En operationel post hjælper med at rekonstruere en bestemt hændelse eller beslutning. En udgivelsespost forklarer, hvorfor en organisation tillod et system i en defineret rute. En ændringspost forklarer, hvad der senere ændrede sig. Disse poster overlapper, men de bør ikke forveksles. At behandle en produktionslog som en benchmark, eller en benchmark som dokumentation for en produktionsarbejdsgang, er en effektiv måde at få hver post til at bære mere, end den kan holde til.

AI-forordningens logningsregel for højrisikosystemer er tilsvarende knyttet til formålet. Artikel 12 kræver automatisk registrering af relevante hændelser i hele systemets levetid med logningsfunktioner, der passer til det tilsigtede formål. Forordningen henviser til sporbarhed af systemets funktion, overvågning af driften og overvågning efter markedsføring. Den kræver ikke en vilkårlig registreringsvane. Den kræver poster med et formål.

Den vending, registreringer med et job, er en bedre rettesnor end et generisk krav om observerbarhed. Modelidentifikatoren kan hjælpe med at skelne en opdatering. Proveniensen af inputdata kan forklare en overraskende anbefaling. En regelversion kan forklare, hvorfor et resultat blev blokeret. En tilsynsgennemgang kan forklare, hvorfor den operationelle handling adskiller sig fra modellens forslag. Et tidsstempel kan fastlægge rækkefølgen. Et privatlivsbevidst design spørger stadig, om hvert felt er nødvendigt, proportionalt, opbevaret i en defineret periode og beskyttet mod netop det system, det er beregnet til at inspicere.

Reproducerbarhed har to ærlige former

Folk bruger ofte reproducerbar til at betyde en række forskellige ting. Forvirringen er forståelig. Et team kan mene, at det kan køre en fast evaluering igen og få samme score. En forsker kan mene, at et andet team kan køre den angivne metode og inspicere resultatet. En operatør kan mene, at en undersøgelse kan genskabe den tilstand, der blev brugt til en bestemt beslutning. En kunde kan mene, at en arbejdsgang giver konsistent behandling frem for at ændre sig vilkårligt fra tirsdag til torsdag. Disse er beslægtede mål. De er ikke én egenskab med flere hatte.

For det første er der reproducerbarhed af den fangede kørsel. Hvis artefakten, konfigurationen, input, relevant tilstand og eksekveringsbetingelser holdes faste, bør en gentagelse producere det dokumenterede resultat inden for de betingelser, systemet lover. Nogle systemer kan komme med et stærkere deterministisk krav for en defineret eksekveringssti. Andre afhænger af kontrolleret tilfældighed, distribueret infrastruktur eller tredjepartstjenester og kan kun komme med et snævrere krav. Det ansvarlige sprog er specifikt. Det siger, hvad der er fast, hvad der måles, hvilken variation der forbliver mulig, og hvordan sammenligning udføres.

For det andet er der reproducerbarhed af evalueringsargumentet. En tilsynsperson skal kunne se, hvorfor suiten repræsenterer kravet, om målingen har den angivne betydning, om accepttærsklen er berettiget, og om beviset kan overføres til den operationelle kontekst. Dette løses ikke af en kontrolsum. En kontrolsum kan fastslå, at en fil ikke er ændret. Den kan ikke fastslå, at filen testede det rigtige spørgsmål, at populationen var passende, eller at en score understøtter den beslutning, der er knyttet til den.

De to former bør mødes. En perfekt gentagelig test, der måler det forkerte, er stadig den forkerte test. Et sofistikeret argument knyttet til en ikke-gentagelig kørsel efterlader tilsynspersoner ude af stand til at skelne et fund fra en heldig eftermiddag. Den nyttige standard er ikke et abstrakt krav om perfekt reproducerbarhed. Det er en synlig korrespondance mellem kravet, metoden, de fangede betingelser, det observerede resultat og den brug, organisationen ønsker at tillade.

Kommissionens vejledning om forpligtelser for udbydere af generel kunstig intelligens holder også evaluering forbundet med dokumentation og risiko. Den beskriver teknisk dokumentation for myndigheder og separat information til downstream-udbydere, herunder kapaciteter, begrænsninger og integrationsinformation. For generelle AI-modeller med systemisk risiko kræver artikel 55 evaluering ved hjælp af standardiserede protokoller og state-of-the-art værktøjer, herunder dokumenteret adversarial testning for at identificere og afbøde systemiske risici. En evaluering, der ikke kan sige, hvad der blev testet, under hvilke betingelser og med hvilke begrænsninger, bliver ikke mere nyttig af at blive kaldt standardiseret.

Bevis har en udløbsbetingelse

Beviser udløber ikke, fordi nogen har besluttet at være vanskelige. De udløber, når de forhold, der gjorde det muligt for dem at understøtte en påstand, har ændret sig så meget, at sammenhængen ikke længere kan antages. Dette er almindelig ræsonneren. En test af en brokonstruktion dækker ikke automatisk et andet materiale. En fødevaresikkerhedskontrol dækker ikke en ny leverandør af ren optimisme. En evaluering af en AI-rute bør ikke automatisk dække en ændret model, ændret datagrænse, ændret værktøjsautoritet eller ændret beslutningskonsekvens.

Det vanskelige arbejde er at afgøre, hvilke ændringer der betyder noget. Dette er et spørgsmål om teknisk vurdering, risikoanalyse og governance, ikke en enkelt procentdel skrevet ind i en politik. En opdatering, der ændrer en knaps farve, har måske ingen betydning for en evaluering. En ændring, der gør en advarsel mindre synlig, kan være væsentlig, hvis sikkerhedsargumentet afhænger af, at en reviewer ser den. Genindeksering af et kildekorpus kan være harmløst for én opgave og kritisk for en anden. Et nyt modelendepunkt kan bevare en bred kapacitet, mens det ændrer latens, afvisningsadfærd, sprogdækning eller værktøjsbrugsmønstre, der betyder noget for ruten.

Nyttig ændringskontrol begynder derfor med et påvirkningsspørgsmål, ikke et udgivelsesritual. Hvilken påstand kan denne ændring påvirke? Hvilken antagelse forstyrrer den? Hvilke beviser var betinget af den gamle tilstand? Besvarer en afgrænset kontrol spørgsmålet, eller har ruten brug for en ny evaluering og udgivelsesbeslutning? Hvem må træffe den beslutning, og hvem kan udfordre den? Svarene bør registreres, fordi den næste reviewer ellers bliver nødt til at udlede dem fra ticket-titler, mundtlig overlevering og en lille ændring i skrifttypen på udgivelsesdashboardet.

Det er også her, overvågning bliver en del af beviserne snarere end en separat observabilitetshobby. Artikel 72 kræver, at udbydere af højrisiko-AI-systemer aktivt og systematisk indsamler, dokumenterer og analyserer relevante data om ydeevne gennem hele systemets levetid, så de kan vurdere løbende overholdelse. Planen for overvågning efter markedsføring udgør en del af den tekniske dokumentation. Overvågning er således ikke blot en måde at vide, om tjenesten er travl. Det er en måde at lære, om forholdene bag den oprindelige påstand fortsat holder.

Overvågning gør ikke ethvert resultat selvindlysende. En stigning i uenighed mellem reviewers og et system kan have mange årsager. En ændring i kildens friskhed kan afspejle et datapipeline-problem snarere end modeldrift. En højere afvisningsrate kan repræsentere en sikrere politik, en brudt integration eller en ny forespørgselspopulation. Registret bør bevare nok kontekst til en menneskelig undersøgelse. Målinger er signaler. De er ikke vidner.

Beviser er gyldige i en defineret kontekst. En væsentlig ændring skaber et spørgsmål til gennemgang, ikke et smuthul uden om gennemgang.

Væsentlig ændring kræver en beslutningsvej

Udtrykket væsentlig ændring behandles ofte, som om det navngiver en selvindlysende egenskab. Det gør det ikke. Væsentlig for hvilket krav, hvilken risiko og hvilken bruger? Svaret skal være så specifikt, at folk kan bruge det, når de er trætte, har travlt og gerne vil kalde en ændring for mindre. En god politik lover ikke at klassificere enhver tænkelig opdatering på forhånd. Den navngiver de faktorer, der afgør, om der er behov for en ny vurdering.

Disse faktorer omfatter typisk tilsigtet formål, berørte personer, den autoritet, der er givet til routen, datakilder og deres kvalitetskontroller, model- eller systemarkitektur, evalueringsomfang, beslutningstærskler, overvågningssignaler, menneskeligt tilsyn, sikkerhedskontroller og genopretningsveje. En ændring, der påvirker nogen af disse, kan være væsentlig eller ej. Det afgørende er, om den kan ændre det bevismateriale, der kræves for det eksisterende krav, eller den risiko, der er tilbage efter kontrollerne.

AI-forordningen indeholder et eksplicit ansvar omkring væsentlige ændringer. Den præcise juridiske anvendelse afhænger af systemet og de involverede aktører, så den bør ikke komprimeres til et slogan. Den operationelle lære er enklere og bredere: en organisation bør vide, hvornår en ændring overfører eller skaber ansvar, hvornår den eksisterende dokumentation ikke længere er tilstrækkelig, og hvornår systemet skal vurderes igen, før en ny brug fortsætter. Det er mindre spændende end en funktionslancering. Det er også mindre tilbøjeligt til at skabe en vanskelig sag, hvor alle er enige om, at systemet er ændret, men ingen ejer beslutningen.

En beslutningssti giver en ændring et sted at gå hen. Én sti kan tillade et dokumenteret fund om ingen påvirkning. En anden kan kræve en målrettet regressionsevaluering. En tredje kan kræve en bredere risikogennemgang, en ændring af brugsanvisningen, en revideret overvågningsplan eller en ny godkendelse til udgivelse. Den mest alvorlige sti kan kræve, at routen forbliver begrænset eller sat på pause, indtil der foreligger dokumentation. Pointen er ikke at gøre enhver redigering dyr. Det er at gøre den vigtige redigering umulig at forklæde som rutinemæssig vedligeholdelse.

Der er en tilfredsstillende mangel på romantik i dette. En ændringsregistrering kan vise den tidligere tilstand, den foreslåede tilstand, de berørte krav, det gennemgåede bevismateriale, beslutningen, autoriteten og betingelserne efter udgivelsen. Det er governance i arbejdstøj. Det vil aldrig se så spændende ud som en modeldemonstration. Det har den mere nyttige egenskab, at det hjælper en organisation med at forklare sig selv, når en demonstration er blevet en rigtig tjeneste.

Evaluering skal kunne fejle offentligt, eller i det mindste i filen

Evaluering bliver performativ, når hvert resultat antages at være et udgivelsesresultat. Et modent evalueringsprogram skal kunne konkludere, at bevismaterialet er ufuldstændigt, at en tærskel ikke blev nået, at en kendt begrænsning forhindrer en foreslået brug, eller at et krav skal indsnævres. Dette er ikke pinlige undtagelser fra processen. Det er output fra processen.

Det er særligt vigtigt for adaptive eller eksternt forbundne systemer. Et team kan opdage, at en testsuite ikke længere repræsenterer en levende inputpopulation. En værktøjskontrakt kan blive for ustabil til at understøtte et krav om afspilning. En modelopdatering kan forbedre én opgave, men gøre en beskyttet route sværere at føre tilsyn med. Et operationelt signal kan vise, at overdragelsen fra system til reviewer fejler under almindelig arbejdsbyrde. Det rigtige svar er ikke nødvendigvis en dramatisk nedlukning. Det kan være en begrænsning, en revideret arbejdsgang, en yderligere test, en ny acceptbetingelse eller en beslutning om ikke at fremsætte det oprindelige krav.

Registreringen skal gøre det muligt for en revisor at se det negative resultat. Ellers opbygger en organisation en meget effektiv maskine til kun at indsamle de beviser, den kan lide. Kvalitetsstyringskravene i artikel 17 er relevante her. De dækker blandt andet teknikker og procedurer for design, udvikling og kvalitetskontrol; undersøgelse, test og validering; dataforvaltning; risikostyring; overvågning efter markedsføring; indberetning af hændelser; og kommunikation med myndigheder. Et kvalitetssystem er ikke en mappe, der får fejl til at forsvinde. Det er en måde at opdage, dokumentere og håndtere dem på.

Det samme princip gælder for adgang. En ekstern tilsynsmyndighed, et bemyndiget organ eller en autoriseret revisor kan have brug for teknisk dokumentation, som ikke kan offentliggøres åbent. Et offentligt resumé kan være passende for andre dele af registreringen. Det er forskellige adgangsveje, ikke forskellige fakta. Offentligheden skal ikke tilbydes en munter beskrivelse, mens den kontrollerede registrering beskriver en snævrere og mere betinget virkelighed. Fortrolighed kan være legitim. Modsigelse er en styringssvigt.

Hos Dweve udgør vores offentlige Trust Centre et lille, bevidst afgrænset eksempel på denne sondring. Dets evalueringsside siger, at en evaluering identificerer modellen, den præcise suite, konfigurationen, den registrerede tilstand, dokumentationen og revisorens beslutning. Den siger også, at en gentaget registreret kontrakt bør give identiske resultater på understøttede arkitekturer, mens en live-gennemførsel kan afvige, når eksterne beviser eller adaptiv tilstand ændres. Siden adskiller den offentlige metode fra et udfyldt markedsføringsresultat. Det er ikke et bevis på en models kvalitet. Det er simpelthen den rigtige form for et krav om evalueringsregistreringer.

Live-overvågning er ikke en erstatning for en beslutning før udgivelse

Overvågning beskrives nogle gange som svaret på usikkerhed: udgiv systemet, hold øje med dashboardet, forbedr løbende. Der er en nyttig intuition i den sætning. Systemer har brug for observation efter udgivelse, fordi implementering producerer information, som et laboratorium ikke kan. Men overvågning kan ikke retrospektivt understøtte en beslutning, hvor dokumentationen aldrig var tilstrækkelig. Det kan ikke fortælle en person, der er berørt af en fejlbehæftet handling med store konsekvenser, at organisationen vil lære af grafen næste måned.

Evaluering før udgivelse og overvågning efter udgivelse besvarer forskellige spørgsmål. Evaluering spørger, om organisationen har tilstrækkelig dokumentation til at tillade en defineret brug nu. Overvågning spørger, om betingelserne bag denne tilladelse stadig gælder, og om nye risici eller fejl er ved at opstå. Det første etablerer en startgrænse. Det andet overvåger grænsen i drift. Et troværdigt system har brug for begge dele samt en vej for data og operationel læring til at vende tilbage til risikovurdering, dokumentation og ændringsstyring.

Den sløjfe er det, der forvandler en statisk sikkerhedspakke til en levende registrering. En evaluering giver en baseline. En implementeringsregistrering angiver, hvilken baseline der blev vedtaget. Logning og overvågning viser relevant adfærd. En ændring kan ændre baselinen eller afsløre dens begrænsninger. En gennemgang opdaterer derefter kravet, dets dokumentation, dets begrænsninger eller dets status. Systemet bevæger sig. Registreringen bevæger sig med det, men omskriver ikke sin egen fortid. En revisor kan se både den aktuelle position og den vej, ad hvilken den nåede dertil.

For systemer med høj risiko er AI-forordningen eksplicit om, at overvågning efter markedsføring bør indsamle og analysere relevante præstationsdata i hele levetiden og muliggøre vurdering af løbende overensstemmelse. Den kræver også, at udbydere overvåger drift baseret på brugsanvisningen og underretter producenten og den relevante myndighed uden unødig forsinkelse, hvis de har grund til at overveje, at brugen kan udgøre en risiko. Disse krav fjerner ikke behovet for professionel dømmekraft. De giver professionel dømmekraft registreringer, udløsere og veje.

Der er en organisatorisk fristelse til at behandle monitorering som driftsteamets ansvar og evaluering som modelteamets ansvar. Den opdeling vil fejle ved det første meningsfulde spørgsmål om en live-rute. Modelløren ved måske, hvorfor en test blev valgt. Operatøren ved måske, at kilderne var forældede. Politikansvarlig ved måske, at en beslutningsregel blev ændret. Revieweren ved måske, at grænsefladen skaber automatiseringsbias. En revisionsspor bør samle deres beviser uden at lade, som om én person ser hele systemet.

Kan en regulator reproducere en beslutning?

Nogle gange bør svaret være ja, inden for et defineret omfang. Hvis en organisation hævder, at en beslutning eller evaluering kan afspilles, skal den definere, hvad afspilning betyder. Betyder det at gentage et modelkald med samme prompt? Betyder det at genskabe hele retrieval- og værktøjssekvensen? Betyder det at rekonstruere den registrering, som en reviewer så? Betyder det at validere en deterministisk beregning ud fra bevarede input? Hver mulighed er nyttig. Hver har forskellige tekniske og juridiske forudsætninger.

En meningsfuld afspilning begynder med bevaret identitet. Revieweren skal vide, hvilken systemversion og konfiguration der var gældende, hvilke input og kildeversioner der var tilladt, hvilke politikker og tilladelser der gjaldt, hvilke eksterne afhængigheder der svarede, og hvilke menneskelige handlinger der ændrede stien. Nogle elementer skal måske gemmes direkte. Andre kan refereres via stabile identifikatorer og rekonstrueres gennem kontrollerede systemer. Det, der ikke er acceptabelt, er at kalde en øvelse afspilbar, når den afhænger af en live-websøgning, en overskrevet database-række og en husket indstilling fra en ingeniørs bærbare computer.

Selv da kan en afspilning reproducere en registrering snarere end gentage verden. En live-kilde kan opdateres eller trækkes tilbage. En tredjepartstjeneste kan ændre sig. En adaptiv tjeneste kan akkumulere ny styret tilstand. Et menneske kan træffe en anden vurdering, når det præsenteres for de samme oplysninger. Dette er ikke fejl i idéen om afspilning. Det er skel, som registreringen skal bevare. Afspilningen kan vise, hvad systemet gjorde under den indfangede kontrakt. Den hævder ikke, at den nuværende verden er identisk med den kontrakt.

Derfor hører menneskelige beslutningsregistreringer ved siden af tekniske registreringer, når menneskeligt tilsyn er en del af sikkerheds- eller rettighedsargumentet. En revision kan have brug for at vide, at en person gennemgik en anbefaling, hvilke oplysninger der var tilgængelige for dem, hvad de valgte, og hvilken autoritet de havde. Den behøver ikke at gøre enhver reviewer til et overvågningsobjekt eller bevare ubegrænset personligt materiale. Den behøver nok oplysninger til at fastslå, om det lovede tilsyn eksisterede i den pågældende hændelse.

Reproduktion er derfor en stige, ikke et pral. På et trin kan en reviewer identificere udgivelsen. På det næste kan de inspicere beviserne. Højere oppe kan de genskabe en test eller analysere en live-beslutningssti. Organisationen bør sige, hvilket trin den understøtter, hvor grænserne er, og hvilke dele der kræver autoriseret adgang. Et beskedent, testbart afspilningskrav er meget stærkere end en vag forsikring om, at alt er sporbar.

Revisioner har brug for registreringer, der er uenige med hinanden

En organisations offentlige statusregistrering, interne udgivelsesregistrering, evalueringsrapport, driftslogfiler og hændelsesregister bør ikke sige forskellige ting om den samme grundlæggende tilstand. Men de bør heller ikke være identiske dokumenter. Hver har et andet publikum og formål. Den offentlige registrering kan angive tilsigtet formål, status, kendte begrænsninger og en vej til yderligere oplysninger. Den tekniske fil kan indeholde detaljeret arkitektur, data, test og kontroller. Den operationelle registrering kan indeholde hændelsesniveau-sporbarhed. Ændringsfilen kan forklare, hvorfor en tidligere konklusion blev genovervejet.

Integriteten kommer fra overensstemmelse. Hvis en offentlig side siger, at en rute er begrænset til anbefaling, bør de tekniske og operationelle registreringer ikke beskrive automatisk handling. Hvis en evaluering siger, at den vedrører et fastfrosset kildeudsnit, bør udgivelsesregistreringen ikke stiltiende anvende den på et senere. Hvis en ændringsregistrering siger, at en modelopdatering var uvæsentlig, bør konsekvensvurderingen angive den berørte påstand og dokumentationen. Hvis et overvågningssignal udløser en gennemgang, bør den efterfølgende beslutning kunne spores. Dokumenterne må godt afvige i detaljeringsgrad. De må ikke være uenige om virkeligheden.

Den overensstemmelse er nyttig for tilsynsmyndigheder, fordi den mindsker behovet for at stole på ét poleret artefakt. En revisor kan sammenligne registreringer. Den er nyttig for organisationer, fordi den afslører afstand mellem teams, før en ekstern revision gør det. Og den er nyttig for berørte personer, fordi den offentlige forklaring kan blive en reel vej til ansvarlighed i stedet for et dekorativt lag lagt oven på et separat internt system.

Arkitekturen behøver ikke at være indviklet. En lille organisation kan bruge et kontrolleret register, versionsstyrede dokumenter, signerede eksporter og disciplinerede ændringsgennemgange. En større organisation kan bruge strukturerede manifester, append-only-logfiler, politikker og automatiseret indsamling af dokumentation. Det vigtige spørgsmål er, om metoden pålideligt kan forbinde påstand, tilstand, dokumentation, beslutning og senere ændring. Et gigantisk værktøjslandskab, der mister denne sammenhæng, er blot en dyrere måde at være upræcis på.

Der er en særlig europæisk dyd i at gøre registreringen inspicerbar uden at gøre den teatralsk. Ikke alle svar hører til på et offentligt dashboard. Ikke al dokumenteret usikkerhed har brug for et muntert ikon. Men når en organisation har fremsat en væsentlig påstand om et adaptivt system, bør den kunne vise en tilsynsmyndighed, hvor den påstand lever, hvilken tilstand den henviste til, og hvordan organisationen ville vide, at den var blevet forældet.

Revisionsspørgsmålet ændrer designspørgsmålet

Spørg tidligt, om en tilsynsmyndighed kunne revidere systemet, som det faktisk vil fungere. Svaret ændrer designvalg længe før en formel revision begynder. Det favoriserer stabile identifikatorer frem for tvetydige etiketter. Det favoriserer eksplicitte politikversioner frem for regler gemt i prosa. Det favoriserer værktøjskontrakter, der kan registreres og testes. Det favoriserer kildeoprindelse og friskhedsmarkører. Det favoriserer en klar grænse mellem anbefaling og handling. Det favoriserer gennemsynsskærme, der bevarer de oplysninger, en revisor har brug for. Det favoriserer pause- og genoprettelsesmekanismer med navngivet autoritet.

Det ændrer også indkøb. En leverandørs erklæring om, at en model jævnligt forbedres, er ikke nok, når implementeringen afhænger af en defineret evalueret tilstand. Køberen skal vide, hvordan ændringer meddeles, hvilke artefakter der kan identificeres, hvilke oplysninger der er tilgængelige til konsekvensvurdering, om historiske registreringer forbliver fortolkbare, og hvordan en rute kan begrænses eller sættes på pause. Det er ikke eksotiske krav. Det er de praktiske vilkår, hvorunder en organisation forbliver ansvarlig for et system, der indeholder en leverandørkomponent.

Det samme spørgsmål ændrer evalueringsdesign. En nyttig suite har en identitet og en begrundelse. Dens input eller referencer er kontrollerede. Dens målinger og tærskler er defineret, før resultatet læses. Dens udelukkelser er synlige. Dens resultater knytter sig til den systemtilstand, der faktisk diskuteres. Dens fejl har en vej ind i en beslutning. Dens betingelser for genkørsel er klare. En evaluering med disse egenskaber kan udfordres. Det er en funktion, ikke en uheldig bivirkning af at være grundig.

Frem for alt ændrer spørgsmålet forandringens rolle. Forandring ophører med at være en pinlighed, som dokumentationen forsøger at skjule. Den bliver en førsteklasses begivenhed i systemets evidensmodel. Nogle forandringer kræver ikke meget mere end en registrering. Nogle udløser en test. Nogle genåbner releasebeslutningen. Den disciplinerede organisation blander ikke disse kategorier sammen, og den behøver ikke en fremtidig hændelse for at opdage, at de fandtes.

Så ja: en tilsynsmyndighed kan revidere et bevægeligt mål. Revisionen begynder med at afvise det falske valg mellem et frosset modelkort og en fuldstændig uforudsigelig live-tjeneste. Indfang tilstanden. Angiv kravet. Bevar betingelserne. Forbind evidensen med beslutningen. Registrer, hvad der ændrer sig. Vurder på ny, når forbindelsen ikke længere holder. Målet kan bevæge sig. Sporet skal forblive læseligt.

Kilder