Et højrisikosystem er ikke en højrisikomodel

Risiko bor ikke i en model som en advarselsetiket. Den opstår ud fra det tilsigtede formål, implementeringen, autoritet, grænseflader og de mennesker, der...

Et højrisikosystem er ikke en højrisikomodel

Etiketten hænger på en anvendelse, ikke på en kasse

En model kan kopieres fra én server til en anden uden at lære noget. Dens vægte, kode og annoncerede egenskaber kan være uændrede. Alligevel kan det spørgsmål, Europa stiller til det, der omgiver modellen, ændre sig fuldstændigt. Hvad skal den bruges til? Hvem bruger den? Hvis position kan den ændre? Hvilken registrering indgår i arbejdsgangen? Hvem kan betvivle svaret, rette det, stoppe det eller senere opdage, hvorfor det blev fulgt?

Dette er ikke et forsøg på at gøre et simpelt emne større, end det er. Det er den almindelige forskel mellem en komponent og et system. En bremseskive er ikke et motorkøretøj. En regnearksformel er ikke en skatteafgørelse. En generel AI-model er ikke i sig selv ethvert AI-system, der senere måtte blive bygget omkring den. Forskellen er let at nikke til og bemærkelsesværdigt let at miste af syne, når et indkøbsmøde begynder at tale om en model, som om den allerede indeholder hele den fremtidige udrulning.

EU's forordning om kunstig intelligens holder forskellen for øje. Den definerer et AI-system og definerer separat en generel AI-model. Dens regler for høj risiko vedrører AI-systemer under særlige omstændigheder, herunder systemer, der er sikkerhedskomponenter i regulerede produkter, og systemer, der anvendes på oplistede områder. Forordningen gør også det tilsigtede formål centralt for klassificeringen og dokumentationen af et AI-system. Den inviterer ikke et team til at pege på et modelnavn, sætte en rød, gul eller grøn etiket på og erklære arbejdet for udført.

Det bør være befriende såvel som krævende. En model bærer ikke et permanent moralsk horoskop. En omhyggelig analyse kan være snæver, hvor det tilsigtede formål er snævert, og den kan blive alvorlig, hvor autoritet, eksponering og konsekvens bliver alvorlige. Haken er, at analysen må følge det faktiske system. Ikke demoen. Ikke leverandørens præsentation. Ikke den harmløse opgave, der startede projektet for seks måneder siden. Det system, der vil modtage input, gøre output tilgængelige, forme en beslutning og blive drevet på en helt almindelig tirsdag.

Overvej en bevidst hypotetisk illustration. Den samme sprogmodel forbindes først til et internt vidensøgningsværktøj. Den henter politikafsnit til en trænet kollega, som kan åbne den oprindelige kilde og skrive sit eget svar. Senere forbinder en organisation modellen til et indtagningsskema, giver dens anbefaling en plads øverst i en sagsregistrering, anvender en timer på sagen og gør accept af anbefalingen til den hurtigste måde at tømme køen på. Der er ikke brug for et fiktivt råd, en patient, en medarbejder eller en hændelse for at se ændringen. Modellen kan være identisk. Outputtets rolle, datastien, incitamentet, den berørte person og grænsefladens praktiske autoritet er ikke.

Det er artiklens argument: et system med høj risiko er ikke en model med høj risiko. En model kan være en vigtig del af systemet og kan have sine egne forpligtelser. Men risikoanalysen bliver kun meningsfuld, når den når frem til det tilsigtede formål, udrulningskonteksten, brugerne, de berørte personer og downstream-integrationen. Disse detaljer er ikke papirarbejde, der lægges oven på efter ingeniørarbejdet. De er de omstændigheder, der giver et output institutionel kraft.

Hold markøren over eller vælg et lag. Modellen er ét lag; konsekvensen opstår først, når lagene mødes.

Europa bruger bevidst to forskellige navneord

Forskellen begynder i forordningens definitioner. Et AI-system er et maskinbaseret system, der er designet til at fungere med varierende grad af autonomi, og som kan udvise tilpasningsevne efter udrulning, og som ud fra input udleder, hvordan der genereres output som forudsigelser, indhold, anbefalinger eller beslutninger, der kan påvirke fysiske eller virtuelle miljøer. En AI-model med generelle formål er noget andet: Det er en AI-model, der er i stand til kompetent at udføre en bred vifte af forskellige opgaver, uanset om den bringes på markedet, og som kan integreres i en række downstream-systemer eller applikationer.

Disse definitioner overlapper i daglig tale, fordi det samme ord, AI, udfører en stor mængde ulønnet arbejde. De bør ikke overlappe i en vurdering. En model med generelle formål er skabt til at rejse. Dens mulige anvendelser er bevidst brede. Et AI-system er den operationelle indretning, hvorigennem output påvirker et miljø. Det har et formål, en konfiguration, en grænseflade og en indstilling. Det kan omfatte en model, flere modeller, deterministiske regler, databaser, sensorer, mennesker, procedurer og en lang række små beslutninger, som ingen kalder kunstig intelligens, før de fejler.

Derfor kan en udbyder af en AI-model med generelle formål og en udbyder eller anvender af et AI-system ikke blot bytte tjeklister. Kommissionens vejledning om AI-modeller med generelle formål siger, at modeludbydere skal stille information og dokumentation til rådighed for downstream-udbydere af AI-systemer, så disse udbydere kan forstå modellens kapaciteter og begrænsninger og opfylde deres egne forpligtelser. Den sætning er mere interessant, end den umiddelbart ser ud. Den forudsætter, at downstream-udbyderen har et arbejde, som modeludbyderen ikke kan udføre. Modeldokumentationen rejser, men den fuldfører ikke rejsen.

Der er en praktisk ydmyghed i dette. En modeludbyder kan beskrive arkitektur, træningsproces, evaluering, tilsigtede opgaver, integrationskrav, input og output, begrænsninger og kendte forhold. Et downstream-team ved, om en bruger er en uddannet specialist, om en berørt person kan anfægte et resultat, om en anbefaling er rådgivende i navnet, men bindende i praksis, om et kald til en ekstern tjeneste ændrer en registrering, og om en fejlbehæftet handling kan tilbageføres. Ingen af parterne har alene et fuldstændigt billede.

Opdelingen er ikke et smuthul. Det er et ansvarskort. Den siger, at et system ikke kan styres ved at bede modeludbyderen love kontrol over en udrulning, de hverken driver eller ser. Den siger også, at en integrator ikke kan påberåbe sig uvidenhed, hvor dokumentation gør en vigtig begrænsning synlig. Pointen er ikke at lave en pæn overdragelse mellem juridiske enheder. Det er at undgå at miste spørgsmålet i kløften mellem dem.

Der er en anden skelnen, der er værd at fastholde ved siden af den første. En klassificering som højrisiko er i sig selv hverken en tilladelse, en garanti for sikkerhed, rimelighed eller lovlighed. I deres fælles udtalelse om Kommissionens oprindelige forslag understregede Det Europæiske Databeskyttelsesråd og Den Europæiske Tilsynsførende for Databeskyttelse, at en klassificering som højrisiko ikke nødvendigvis betød, at et system som sådan var lovligt, eller at det kunne anvendes af brugeren som sådan. Den endelige retsakt har ændret det retlige landskab siden den udtalelse, men den underliggende advarsel er stadig relevant. Klassificering er en reguleringsmæssig betingelse. Det er ikke en kvittering for, at institutionen kan holde op med at tænke.

Det har betydning, fordi en højrisiko-etiket kan føre til to modsatrettede fejl. Det ene team kan behandle den som en permanent plet på en model og beslutte, at svaret simpelthen er ikke at undersøge sagen nærmere. Et andet team kan behandle en afsluttet overensstemmelsesproces som et frikort til enhver senere kontekst. Begge tilgange erstatter en etiket med en argumentation. Europa har valgt en mere besværlig tilgang: identificér systemet, dets formål og dets rolle, og undersøg derefter de relevante risici og forpligtelser gennem hele dets livscyklus.

Det tilsigtede formål er der, hvor analysen finder sit udgangspunkt

Det tilsigtede formål lyder beskedent, næsten administrativt. Det er det ikke. Retsakten definerer det som den anvendelse, som en udbyder har tilsigtet for et AI-system, herunder den specifikke kontekst og de specifikke anvendelsesbetingelser, der er angivet i de oplysninger, som udbyderen har leveret. Med andre ord er formålet ikke et slogan på en produktside. Det omfatter den kontekst og de betingelser, som udbyderen angiver, at systemet skal anvendes under. En brugbar formålserklæring har skarpe kanter. Den siger, hvad systemet gør, for hvem, med hvilke input, i hvilken arbejdsgang, og hvor dets autoritet ophører.

Sammenlign to beskrivelser. Den første siger, at et system bruger AI til at hjælpe organisationer med at træffe bedre beslutninger. Den er bred nok til at passe på en konferencebaggrund og for bred til at kunne fungere. Den anden siger, at et system præsenterer kildehenviste udkast til resuméer af en eksisterende sagsmappe for uddannede gennemgåere; det kan ikke træffe, formidle eller implementere en beslutning; gennemgåeren skal verificere de citerede kilder, før et resumé anvendes; og funktionen er ikke tilgængelig for kategorier, der kræver en separat lovbestemt proces. Den anden beskrivelse er mindre spændende. Den er også noget, som en ingeniør, en indkøbsansvarlig, en compliance-kollega og en berørt person kan være uenige i helt konkret.

Formålet behøver ikke at være en enkelt sætning. I et seriøst system er det normalt en kompakt pakke: opgave, output, bruger, berørt befolkning, ramme, autoritet, undtagelser, afhængigheder og betingelser. Retsaktens krav til teknisk dokumentation giver netop plads til en sådan beskrivelse. Bilag IV beder om en generel beskrivelse af AI-systemet, herunder det tilsigtede formål, de personer og grupper, som det er tilsigtet at blive anvendt på, og de specifikke versioner eller former, som det markedsføres i. Det beder også om beskrivelser af systemarkitektur, datakrav, foranstaltninger til menneskeligt tilsyn, overvågning af livscyklussen og risikostyringsforanstaltninger. Dokumentationen har den bredde, fordi et modelkort alene ikke kan beskrive en implementering.

Formålet er også der, hvor et team opdager, at det har beskrevet en ambition snarere end en drift. Vi vil understøtte sagsbehandlere kan skjule et dusin forskellige arrangementer. Søger værktøjet i dokumenter, sorterer arbejde, udarbejder et udkast til svar, anbefaler en kategori, afviser en ansøgning, eskalerer en alarm, sætter en prioritet eller kalder en anden tjeneste? Bruger kollegaen det før eller efter at have dannet sig en uafhængig vurdering? Er outputtet et forslag i en sidepanel eller et felt, der skal udfyldes, før sagen kan gå videre? Er effekten øjeblikkelig, forsinket, reversibel eller svær at få øje på? Svaret ændrer systemet, selv hvor brugergrænsefladen ser velkendt ud.

En udbyders tilsigtede formål kan ikke få virkeligheden til at forsvinde. Et team kan ikke give et system bred praktisk autoritet, beskrive det som en harmløs assistent og forvente, at beskrivelsen afgør sagen. Men et ordentligt afgrænset formål er stadig en kontrolmekanisme. Det fortæller brugerne, hvilke beviser der er blevet vurderet, fortæller integratorer, hvad de ikke må udvide uden videre, og fortæller reviewere, hvilken ændring der ville genåbne vurderingen. Et vagt formål gør ethvert senere spørgsmål til en diskussion om, hvad der var ment. Et afgrænset formål giver en organisation mulighed for at spørge, om den stadig gør det, den har godkendt.

Dette bliver særligt vigtigt, når en organisation foretager en væsentlig ændring. Forordningen indeholder regler om tilfælde, hvor en distributør, importør, deployer eller anden tredjepart kan blive udbyder, herunder når den bringer et system i omsætning under eget navn, foretager en væsentlig ændring eller ændrer det tilsigtede formål på en måde, der gør systemet højrisiko. Den præcise juridiske anvendelse afhænger af de konkrete omstændigheder og bør kontrolleres i konteksten. Den operationelle lære er enklere: en integrationsændring kan være en governance-begivenhed. At flytte et modeloutput fra en kladde til en beslutningskø kan være en produktændring, en workflowændring og en ansvarlighedsændring på samme tid.

Kontekst er ikke kulisse

Implementeringskontekst behandles ofte som det, der kommer efter det rigtige arbejde: en liste over lande, et hostingvalg, et par brugerprofiler, måske et diagram med pile, der pligtopfyldende fører fra venstre mod højre. Men kontekst giver risiko dens form. Den samme type output kan være ubelejligt i én sammenhæng og konsekvensrigt i en anden. En fejlagtig fuldførelse i et skriveværktøj kan rettes i den næste sætning. En fejlagtig prioritering i en workflow med knappe ressourcer kan afgøre, hvilken fil en person ser først. En score, der ser ud til at være én input blandt mange, kan blive afgørende, hvis alle andre input er langsomme, vage eller skjult bag et andet team.

Forordningens tilgang til højrisiko afspejler dette. Artikel 6 forbinder højrisikoklassificering med systemer, der er beregnet til at blive brugt som sikkerhedskomponenter i visse produkter, eller systemer, der er nævnt i bilag III. Bilag III oplister områder, hvor AI-systemer kan være højrisiko, fordi de er beregnet til bestemte anvendelser, såsom visse biometriske anvendelser, kritisk infrastruktur, uddannelse og erhvervsuddannelse, beskæftigelse, adgang til væsentlige private og offentlige tjenester og ydelser, retshåndhævelse, migration og grænsekontrol samt retspleje og demokratiske processer. De juridiske detaljer betyder noget, men det gør grammatikken også. Den siger ikke, at et teknisk artefakt er højrisiko i abstrakt forstand. Den siger gentagne gange beregnet til at blive brugt.

Artikel 6 indeholder også en kvalifikation for visse systemer i bilag III: de skal ikke betragtes som højrisiko, hvis de ikke udgør en væsentlig risiko for skade på fysiske personers sundhed, sikkerhed eller grundlæggende rettigheder, herunder ved ikke i væsentlig grad at påvirke resultatet af beslutningstagning. Udbyderen skal dokumentere denne vurdering, før systemet bringes i omsætning eller tages i brug. Dette er ikke et generelt fritagelseskort. Det er en påmindelse om, at systemets faktiske virkning betyder noget. En nyttig analyse har tilstrækkelig detalje til at forklare, hvorfor et system i væsentlig grad påvirker, eller ikke påvirker, et resultat. Hvis den forklaring ikke kan skrives uden at være upræcis, har teamet lært noget, før udgivelsen.

Konteksten omfatter tid. En anbefaling i starten af en bred undersøgelse har en anden virkning end en anbefaling på det punkt, hvor en person har én chance for at fremskaffe manglende materiale. Den omfatter volumen. En individuel gennemgående kan udfordre et output, når der kommer fem sager om dagen, og følge det som standard, når der kommer fem hundrede før frokost. Den omfatter sprog. En gennemgående, der kan læse beviserne på deres eget arbejdssprog, kan udøve en anden form for tilsyn end en gennemgående, der modtager et selvsikkert resumé af materiale, de ikke selv kan inspicere. Den omfatter lokal procedure, klageadgang, bemanding, adgang til en specialist, tilgængeligheden af en fallback-løsning, og om et output når frem til en person med tilstrækkelig autoritet til at gøre noget nyttigt.

Intet af dette kræver, at en opfundet katastrofe er sand. Det er simpelthen sådan, systemer fungerer. En formel politik kan sige human in the loop, men systemet kan stadig være funktionelt automatisk, hvis personen ikke har tid, information, autoritet eller en praktisk vej til at være uenig. Artikel 14 i loven taler derfor om effektivt menneskeligt tilsyn, der er passende i forhold til risici, grad af autonomi og brugskontekst. Den kræver, at højrisikosystemer designes og udvikles, så mennesker kan forstå relevante kapaciteter og begrænsninger, forblive opmærksomme på en tendens til automatisk at stole på output, korrekt fortolke output, beslutte ikke at bruge det, tilsidesætte eller omgøre det og stoppe systemet sikkert, hvor det er relevant. Det er operationelle spørgsmål. De kan ikke besvares ud fra en modelbenchmark alene.

Vælg en implementeringsform. Modellen forbliver den samme; systemgrænsen, autoriteten og de nødvendige beviser gør ikke.

Brugere er en del af kontrolfladen

Det er fristende at tale om brugere, som om de sidder uden for systemet med et tastatur og sørger for den menneskelige del. De er en del af driftsarrangementet. Deres viden, arbejdsbyrde, autoritet, incitamenter og veje til hjælp afgør, hvad outputtet gør. Et system designet til en specialist, der kan inspicere kildemateriale, er ikke automatisk egnet til en generalist, der forventes at arbejde i et højt tempo. Et værktøj, der er nyttigt for en gennemgående, der kan afvise en anbefaling, er ikke automatisk egnet til en kollega, der kun kan klikke på godkend eller vente på en anden.

Det betyder ikke, at en bruger skal betvivle hver komponent hver gang. Det ville være en mærkelig definition af nyttig teknologi. Det betyder, at tilsyn skal designes som en reel opgave. Personen skal vide, hvornår systemet er i brug, hvad den relevante begrænsning er, hvilke beviser der er tilgængelige, hvilken form for uenighed de kan registrere, og hvad der sker, efter de har registreret den. De har brug for autoritet, der matcher ansvaret. At bede nogen om at føre tilsyn med et output, de ikke kan pause, korrigere eller dirigere, er mindre menneskeligt tilsyn og mere menneskelig dekoration.

Forordningen giver udbydere en rolle her. Artikel 26 kræver, at udbydere af højrisikosystemer træffer passende tekniske og organisatoriske foranstaltninger for at sikre, at de bruger systemerne i overensstemmelse med de medfølgende instruktioner. Den beder udbyderne om at tildele menneskeligt tilsyn til fysiske personer med den nødvendige kompetence, uddannelse og autoritet og om at overvåge driften på baggrund af instruktionerne. I visse tilfælde kræver den også, at automatisk genererede logfiler holdes under deres kontrol. Dette er ikke en anmodning om at holde en kyndig person i nærheden, hvis grænsefladen skulle blive nervøs. Det er et krav om at tilrettelægge en arbejdspraksis.

Uddannelse diskuteres ofte som hele svaret. Det er den ikke. Uddannelse kan hjælpe en person med at genkende en begrænsning, men den kan ikke skabe en kildeoptegnelse, som grænsefladen skjuler. Den kan ikke skabe tid, som et kødesign forbruger. Den kan ikke skabe autoritet, som en kontrakt forbeholder sig andetsteds. Den kan ikke reparere en integration, der omdanner en forsigtig anbefaling til en irreversibel handling. En organisation bør selvfølgelig uddanne folk. Den bør også gøre den opgave, de uddannes til at udføre, mulig i det system, de faktisk får.

Der er en nyttig test: beskriv brugerhandlingen uden at bruge verbet gennemgå. Hvad læser de? Hvilken sammenligning kan de foretage? Hvad kan de afvise? Hvor ender begrundelsen? Hvem ser den? Hvad sker der med anbefalingen efter afvisning? Kan den person, der berøres af resultatet, spørge, hvad der skete? Kan en senere kollega rekonstruere den relevante tilstand? Hvis svarene forbliver generelle, er tilsynsdesignet sandsynligvis også generelt.

Den test gælder ud over højrisikosystemer. Loven har et specifikt anvendelsesområde og specifikke datoer; god operationel dømmekraft venter ikke på en kategorietiket, før den spørger, om en person er blevet placeret i en performativ rolle. Det er fuldt ud muligt at bygge et værktøj med lave konsekvenser, der gør folk dummere om deres eget arbejde, fordi outputtet er for glat til at udfordre. Det er også muligt at bygge et begrænset værktøj, der øger en persons evne til at stille gode spørgsmål, fordi det bevarer beviser, begrænser sin autoritet og gør usikkerhed synlig. Modellen kan bidrage til begge udfald. Systemet afgør, hvilket udfald der har et sted at ske.

Berørte personer sidder uden for konsollen

Mange af de vigtigste personer i et AI-system rører det aldrig. De kan være en kandidat, elev, medarbejder, patient, passager, beboer, kunde, ansøger, låntager, vidne eller medlem af offentligheden. De ved måske ikke, at en model var involveret. De oplever måske kun et svar, der kommer hurtigt, en anmodning, der bliver forsinket, en service, der bliver utilgængelig, en prioritet, der ændrer sig, eller en beslutning, der virker umulig at forstå. Deres fravær fra grænsefladen gør dem ikke fraværende fra systemet.

Dette er en af grundene til, at forordningens risikoramme henviser til sundhed, sikkerhed og grundlæggende rettigheder. Den retter opmærksomheden mod konsekvenser, der ikke kan reduceres til, om en indlogget kollega kunne lide værktøjet. Det er også derfor, en formålserklæring bør nævne de personer og grupper, som systemet er beregnet til at blive brugt på, som bilag IV kræver. Et system bygget omkring en kategori kaldet bruger kan stille og roligt skjule en forskel mellem den person, der betjener grænsefladen, og den person, der lever med resultatet.

Berørte personer ændrer de spørgsmål, et team skal stille. Er der en måde at vide, at systemet spillede en meningsfuld rolle? Er beslutningen baseret på oplysninger, der kan rettes? Gør et sprog, et handicap, en enhed, en placering eller en administrativ status det sværere at deltage? Modtager driftsteamet signaler fra de berørte personer, eller kun fra dashboardet? Når en rettelse frem til dataene, anbefalingen, beslutningen og eventuelt downstream-materiale, der støttede sig til den? Disse spørgsmål er ikke en anmodning om at gøre ethvert system til en offentlig høring. De er en anmodning om at følge konsekvensen langt nok til at se personen i den anden ende.

Databeskyttelsesloven er relevant, hvor der behandles personoplysninger, sammen med AI-forordningens ramme. EDPB og EDPS gjorde dette punkt klart i deres fælles udtalelse fra 2021 om forslaget: eksisterende EU-databeskyttelsesret finder anvendelse på behandling af personoplysninger inden for forslagets anvendelsesområde. Den præcise juridiske analyse vil afhænge af behandlingen og de involverede aktører. Ledelsesmæssigt er pointen ligetil. En klassifikationsøvelse kan ikke absorbere alle andre forpligtelser. Privatliv, ikke-diskrimination, sektorspecifikke krav, forvaltningsretlige krav, forbrugerregler og kontraktlige forpligtelser forsvinder ikke, fordi et team har lavet et pænt risikoregister.

Der er også et grundlæggende spørgsmål om læsbarhed. En person behøver ikke at blive specialist i machine learning for at forstå, hvordan man søger en rettelse. Men et system må ikke bruge teknisk kompleksitet som en grund til at gøre en rettelse umulig. En god vej skelner mellem, hvad systemet registrerede, hvad et menneske besluttede, hvilke beviser der blev overvejet, hvad der fortsat er usikkert, og hvad der stadig kan ændres. Den hævder ikke en præcision, som registrene ikke kan understøtte. På dette område er ærlighed ikke blot en tone. Det er en del af servicen.

Integration er, hvor ansvar skifter hænder

Teams tegner nogle gange en AI-arkitektur som en pæn kæde: model, prompt, svar, bruger. Reelle implementeringer ligner mere et kommunalt kort, efter nogen har husket serviceinstallationerne. Der er identitetssystemer, retrieval-lagre, værktøjsrettigheder, køer, skemaer, caches, observerbarhedsplatforme, browserudvidelser, batchjobs, godkendelsesregler, opbevaringsindstillinger, leverandører og personer, der arver en opgave, fordi den forrige person er taget på ferie. Modellen er vigtig. Den er sjældent alene.

Hver integration kan ændre, hvad systemet er i stand til at gøre, og hvordan en fejl bevæger sig. Retrieval kan få et modeloutput til at fremstå velbegrundet, mens kilden er forældet, ufuldstændig eller forkert afgrænset. Et værktøjskald kan forvandle et udkast til en tilstandsændring. En kø kan gøre en rettidig anbefaling til en forsinket. Et orkestreringslag kan vælge en anden model- eller promptversion. En brugergrænseflade kan skjule usikkerhed, der findes i et lavere lag. En identitetsintegration kan give et nyttigt værktøj adgang til materiale, som en bruger ellers ikke kunne åbne. Ingen af disse observationer beskylder et bestemt produkt eller en bestemt organisation. De beskriver almindelige systemegenskaber, hvilket netop er grunden til, at de bør dokumenteres, før de bliver overraskende.

Kommissionens GPAI-vejledning er nyttig her, fordi den placerer information ved overdragelsespunktet. Dokumentationen til downstream-udbydere skal hjælpe dem med at forstå modellens kapaciteter og begrænsninger, dens tilsigtede opgaver, tekniske integrationskrav, input- og outputspecifikationer og oplysninger om træningsdata. Disse oplysninger er nødvendige. De er ikke tilstrækkelige. Downstream-teams skal stadig beslutte, hvordan modellen promptes, om et output vises med dokumentation, hvilke værktøjsrettigheder der tillades, hvordan en ændring testes, hvilke logfiler der opbevares, og om en anbefaling må påvirke en bestemt arbejdsgang.

Det er derfor, at et køb af en modelservice ikke er et køb af en komplet risikoprofil. Udbyderens dokumentation kan fortælle en virksomhed, at en model har en kendt begrænsning, eller at den er blevet evalueret under bestemte forhold. Den kan ikke bevise, at køberens eget søgeindeks er opdateret, at køberens medarbejdere har den nødvendige autoritet, eller at en berørt person har adgang til en klagevej. Omvendt kan køberen ikke kræve, at en modeludbyder har kendskab til alle lokale politikker eller downstream-processer. Det ansvarlige er ikke at lade som om, at den ene side kan kende hele systemet. Det er at gøre grænsen eksplicit og holde dokumentationen i bevægelse på tværs af den.

Artikel 25 udgør en nyttig juridisk markør for denne operationelle virkelighed. Den fastsætter omstændigheder, hvor en anden part end den oprindelige udbyder betragtes som udbyder af et højrisiko-AI-system. Det omfatter at bringe systemet i omsætning under denne parts navn eller varemærke, at foretage en væsentlig ændring eller at ændre det tilsigtede formål på en måde, der gør systemet til et højrisikosystem. Bestemmelsen er teknisk og faktaspecifik; ingen bør selvklassificere ud fra et blogindlæg. Men dens retning er klar. Integration og ændret anvendelse kan ændre, hvem der bærer udbyderforpligtelserne. En downstream-aftale er ikke for evigt downstream, blot fordi den oprindelige model kom fra et andet sted.

Der er en institutionel grund til at tage det alvorligt. Når ansvar ændrer sig lydløst, bliver sikkerhed og klageadgang et spil organisatorisk bordtennis. Modeludbyderen peger på implementeringen. Implementatøren peger på modellen. Integratoren peger på cloud-tjenesten. Tjenestejeren peger på en konfiguration, der ikke længere eksisterer. Berørte personer får en poleret forklaring på, hvor komplekst alt er. Det kan være præcist, men det er ikke et svar. Systemet har brug for en registrering af, hvilken organisation der ejer spørgsmålet ved hver grænse, og en rute for spørgsmålet til at rejse, når svaret findes et andet sted.

Dokumentation bør beskrive et system, der stadig kan ændre sig

Teknisk dokumentation har et ry for at ankomme ved slutningen af et projekt med en svag lugt af panik. Forordningen beskriver en anden rolle. For højrisikosystemer skal teknisk dokumentation udarbejdes, før systemet bringes i omsætning eller tages i brug, og holdes ajour. Bilag IV's liste rækker ud over modeladfærd til tilsigtet formål, versioner, systemarkitektur, udvikling, datakrav, validering og test, menneskeligt tilsyn, nøjagtighed og cybersikkerhedsforanstaltninger, risikostyring, ændringer og overvågning efter markedsføring. Det er ikke et dekorativt bilag. Det er et forsøg på at bevare tilstrækkelig hukommelse til, at nogen kan inspicere systemet, efter at lanceringsmødet er blevet til folklore.

Dokumentation virker kun, når den kan vise relationer. En modelversion skal være forbundet med den systemversion, der brugte den. En test skal være forbundet med sine inputbetingelser og formål. En politik skal være forbundet med et håndhævelsespunkt. En brugerrolle skal være forbundet med den autoritet, den har i grænsefladen. En logningspolitik skal være forbundet med den hændelse, den kan rekonstruere. En ændring skal være forbundet med den vurdering, den udløste. Ellers har en virksomhed et bibliotek af gode dokumenter og ingen måde at besvare et bestemt spørgsmål på.

Logs er et tilsvarende tilfælde. Artikel 12 kræver, at højrisiko-AI-systemer har tekniske kapaciteter til automatisk registrering af hændelser i systemets levetid, i et omfang der står i forhold til det tilsigtede formål. Logs kan understøtte sporbarhed, overvågning efter markedsføring og operationel overvågning. De forklarer ikke en beslutning ved magi. En log kan fortælle en senere efterforsker, at et værktøj blev kaldt, at en version var aktiv, eller at en reviewer klikkede på et kontrolpunkt. Den kan ikke i sig selv fastslå, om reviewer forstod beviserne, om inputkilden var autoritativ, eller om en proces var fair. Registreringer er værdifulde, fordi de giver en efterforskning et ærligt sted at begynde, ikke fordi de fjerner behovet for dømmekraft.

Overvågning efter markedsføring fuldender billedet. Artikel 72 kræver, at udbydere af højrisikosystemer etablerer og dokumenterer et system til overvågning efter markedsføring på en måde, der står i forhold til teknologiernes karakter og risiciene ved højrisiko-AI-systemet. Dette har en simpel implikation for implementeringsteams: en release er ikke det øjeblik, hvor systemet bliver fuldt kendt. Organisationen har brug for en måde at modtage relevant information på, skelne et signal fra en konklusion, beslutte om grænsen for det tilsigtede formål stadig holder, og foretage en ændring eller stoppe en brug, hvor beviser kræver det.

Det arbejde er ikke glamourøst. Det ligner versionsidentifikatorer, klare releasekriterier, en registrering af afhængigheder, en test for en tilbagerulningsrute, en navngiven ejer for en begrænsning og en beslutning, der forbliver synlig, efter at den person, der traf den, skifter rolle. Det ligner at spørge, om en integration er ændret, før man spørger, om modellen er ændret. Det ligner at bevare tilstrækkelige beviser til at rette en konsekvens frem for blot at forklare den bagefter. Kedeligt er ikke det modsatte af ambitiøst her. Det er den del, der får ambitionen til at passe ind i en institution.

Sådan ræsonnerer du om hele systemet uden at lade som om, du er sikker

En fuld analyse er ikke en søgen efter en universel risikoscore. Det er en række spørgsmål, der bliver mere præcise, efterhånden som et design bliver mere præcist. Det første spørgsmål er formål: hvad skal dette system gøre, og hvad skal det specifikt ikke gøre? Det andet er konsekvens: hvem kan blive påvirket, hvordan, og gennem hvilken beslutning eller hvilken service? Det tredje er autoritet: hvilket output kan ændre en tilstand, påvirke en beslutning, sætte en prioritet eller ændre, hvad en person modtager? Det fjerde er beviser: hvad understøtter systemets brug i denne kontekst, og hvilke betingelser får disse beviser til at holde?

Derefter kommer de ubehagelige spørgsmål. Hvad sker der, når modellen er usikker, forkert, utilgængelig eller brugt uden for dens angivne grænse? Hvad ændrer sig, når en kilde er forældet, eller et værktøj nægtes adgang? Hvad hvis en bruger har travlt, er ny i rollen eller ikke kan inspicere det underliggende materiale? Hvad hvis en berørt person beder om korrektion? Hvad hvis en opdatering ændrer en prompt, et retrieveringskorpus, en grænsefladestandard, en modelversion eller en rolletilladelse? Svaret er nogle gange en teknisk kontrol, nogle gange en procedure, nogle gange en mindre brug, nogle gange en anden ejer og nogle gange en beslutning om ikke at implementere. Styring, der aldrig tillader det sidste svar, er blot godkendelse i en pænere jakke.

Det hjælper at holde flere udsagn adskilt. Et bekræftet faktum siger, hvad modeludbyderen har dokumenteret, eller hvad organisationen observerede i en defineret test. En inferens siger, hvorfor det faktum kan have betydning i en bestemt arbejdsgang. En foreslået kontrol siger, hvad teamet har til hensigt at implementere. En restrisiko siger, hvad der er tilbage efter kontrollen. En juridisk konklusion siger, hvad der gælder ifølge loven. Disse kan ikke bruges i flæng. Et godt dokument mærker dem, fordi læseren kan have brug for at udfordre det ene uden at kassere de andre.

For eksempel er det muligt at sige: udbyderens dokumentation angiver, at modellen har en bestemt begrænsning; implementeringsteamet udleder, at begrænsningen kan påvirke en specificeret anvendelse; teamet foreslår en kildeverifikationskontrol; kontrollen er endnu ikke testet under den påtænkte arbejdsbyrde; og juridisk rådgivning skal vurdere den resulterende anvendelse i henhold til gældende lov. Den sætning er mindre tilfredsstillende end et grønt flueben. Den er mere nyttig end et grønt flueben, fordi den ikke levner nogen tvivl om, hvad der er og ikke er fastlagt.

Teams bør være særligt forsigtige med ordet menneskelig. En menneskelig rolle kan være en kontrol, men kun hvor den har en defineret opgave, tilstrækkelig information, tid, træning, autoritet og en vej til at handle. En menneskelig rolle kan også blive en måde at overføre skyld til den person, der er tættest på skærmen. Forskellen er ikke filosofisk. Den er synlig i arbejdsgangen. Hvis en reviewer kun kan godkende, hvis uenighed forsvinder ind i et uovervåget kommentarfelt, eller hvis ingen kan rette den nedstrøms konsekvens, har systemet ikke opnået meningsfuld tilsyn blot fordi en person klikkede på noget.

Den samme forsigtighed gælder for gennemsigtighed. Et langt dokument kan gøre et system beskriveligt uden at gøre det anfægteligt. Et dashboard kan gøre det synligt uden at gøre det forståeligt. En oplysning kan fortælle en bruger, at AI er involveret, uden at fortælle dem, hvad der kan gøres ved en fejl. Det nyttige spørgsmål er praktisk: kan den relevante person finde grænsen, beviserne, den ansvarlige rolle og korrektionsvejen på det punkt, hvor disse ting betyder noget? Hvis ikke, findes informationen det forkerte sted for, at governance kan finde sted.

En lille note fra os

Hos Dweve behandler vores offentlige Trust Centre modelposten og den nedstrøms integration som relaterede, men separate poster. Dens nedstrømsside siger, at teams, der integrerer eller implementerer Loom, har brug for aktuelle kapaciteter, grænser, grænseflader, evalueringskontekst og ændringer, mens den offentlige post angiver, at en model er én tråd i en bredere vævning af komponenter og driftsgrænser. Dette er en dokumentationsholdning, ikke en påstand om, at en offentlig side klassificerer enhver mulig implementering eller beviser overholdelse for en integrator. Formålet med adskillelsen er mere beskedent: en modelpost bør følge med integrationen uden at lade som om, den erstatter integratorens egen systemanalyse.

Det er den standard, der er værd at bevare. En modeludbyder bør gøre nyttig information tilgængelig. En organisation, der implementerer eller integrerer modellen, bør beskrive det faktiske system, den har skabt: formål, mennesker, data, grænseflader, autoritet, overvågning og korrektion. Ingen af siderne bør bruge dokumentation som en ceremoniel udveksling, hvor den ene part modtager en PDF, og den anden modtager absolution.

Det sværere spørgsmål er normalt det bedre

Når et team spørger, om en model er højrisiko, rækker det måske efter et hurtigt svar på en fornuftig bekymring. Men det mere nyttige spørgsmål er normalt længere: hvilket system skaber vi ud fra denne model, til hvilket formål, i hvilken kontekst, med hvilke mennesker, og hvad sker der, når det er forkert? Det spørgsmål kan ikke altid besvares på ét møde. Det kan afsløre, at den påtænkte anvendelse er snævrere end forventet, at beviserne er ufuldstændige, at en brugerrolle mangler autoritet, at en kontrakt efterlader en vigtig grænse uejet, eller at en nedstrøms integration stille og roligt er blevet systemets centrum.

Ingen af disse resultater er en svigt i innovation. Det er de ting, en institution lærer, før den giver et system magten til at forme en anden persons muligheder. Den europæiske tilgang beskrives ofte som et sæt forpligtelser. Den er også en disciplin i at navngive: navngiv formålet, aktøren, konteksten, versionen, den berørte person, begrænsningen, beviset og vejen til indgriben. Når disse ting er navngivet, kan de testes, ændres og udfordres. Før de er navngivet, har de en tendens til at dukke op igen senere som en overraskelse.

En model kan være dygtig, omhyggeligt dokumenteret og værdifuld. Den kan også placeres i et system, der kræver for meget af den, skjuler for meget for dens brugere eller efterlader for lidt plads til en person, der er berørt af resultatet. Forskellen skabes uden for vægtene. Det er der, det vanskelige arbejde ligger, og hvor den seriøse mulighed også er: byg systemer, hvis autoritet matcher deres bevis, hvis grænser overlever integration, og hvis operatører stadig kan sige nej.

Kilder