Ett högrisksystem är inte en högriskmodell

Risk lever inte i en modell som en varningsetikett. Den uppstår ur avsett syfte, driftsättning, auktoritet, gränssnitt och de människor som måste leva med...

Ett högrisksystem är inte en högriskmodell

Etiketten sitter på en användning, inte på en låda

En modell kan kopieras från en server till en annan utan att lära sig någonting. Dess vikter, kod och annonserade förmågor kan vara oförändrade. Ändå kan frågan som Europa ställer om det som omger den förändras helt. Vad är den till för? Vem använder den? Vems ställning kan den förändra? Vilken post hamnar i arbetsflödet? Vem kan ifrågasätta svaret, rätta det, stoppa det eller senare ta reda på varför det följdes?

Detta är inte ett försök att göra ett enkelt ämne mer storslaget än det är. Det är den vanliga skillnaden mellan en komponent och ett system. En bromsskiva är inte ett vägfordon. En kalkylbladsformel är inte ett skattebeslut. En generell AI-modell är inte i sig själv varenda AI-system som senare kan byggas runt den. Åtskillnaden är lätt att hålla med om och anmärkningsvärt lätt att tappa när ett upphandlingsmöte börjar tala om en modell som om den redan innehåller hela den framtida driftsättningen.

EU:s förordning om artificiell intelligens håller åtskillnaden i sikte. Den definierar ett AI-system och definierar separat en generell AI-modell. Dess regler om hög risk rör AI-system i särskilda omständigheter, inklusive system som är säkerhetskomponenter i reglerade produkter och system som används inom listade områden. Förordningen gör också det avsedda syftet centralt för klassificeringen och dokumentationen av ett AI-system. Den uppmanar inte ett team att peka på ett modellnamn, sätta en röd, gul eller grön etikett och förklara arbetet avslutat.

Det borde vara befriande såväl som krävande. En modell bär inte ett permanent moraliskt horoskop. En noggrann analys kan vara snäv där det avsedda syftet är snävt, och den kan bli allvarlig där auktoritet, exponering och konsekvens blir allvarliga. Haken är att analysen måste följa det faktiska systemet. Inte demon. Inte leverantörens presentation. Inte den harmlösa uppgiften som startade projektet för sex månader sedan. Systemet som kommer att ta emot indata, göra utdata tillgängliga, forma ett beslut och drivas en helt vanlig tisdag.

Betrakta en medvetet hypotetisk illustration. Samma språkmodell kopplas först till ett internt kunskapssökningsverktyg. Den hämtar policyavsnitt åt en utbildad kollega, som kan öppna den ursprungliga källan och skriva sitt eget svar. Senare kopplar en organisation modellen till ett intagsformulär, ger dess rekommendation en plats överst i en ärendepost, tillämpar en timer på ärendet och gör att acceptera rekommendationen är det snabbaste sättet att rensa kön. Ingen fiktiv nämnd, patient, anställd eller incident behövs för att se förändringen. Modellen kan vara identisk. Rollen för utdata, datavägen, incitamentet, den berörda personen och gränssnittets praktiska auktoritet är det inte.

Det är artikelns argument: ett system med hög risk är inte en modell med hög risk. En modell kan vara en viktig del av systemet och kan ha egna skyldigheter. Men riskanalysen blir meningsfull först när den når avsett syfte, driftskontext, användare, berörda personer och nedströmsintegration. Dessa detaljer är inte pappersarbete som läggs till efter tekniken. De är de omständigheter som ger en utdata institutionell kraft.

Hovra över eller välj ett lager. Modellen är ett lager; konsekvensen uppstår först när lagren möts.

Europa använder medvetet två olika substantiv

Skillnaden börjar i förordningens definitioner. Ett AI-system är ett maskinbaserat system som är utformat för att fungera med varierande grad av autonomi och som kan uppvisa anpassningsförmåga efter utsläppande på marknaden, och som utifrån indata sluter sig till hur det ska generera utdata, såsom förutsägelser, innehåll, rekommendationer eller beslut som kan påverka fysiska eller virtuella miljöer. En allmän AI-modell är något annat: det är en AI-modell som på ett kompetent sätt kan utföra ett brett spektrum av skilda uppgifter, oavsett om den släpps på marknaden eller inte, och som kan integreras i en rad olika system eller applikationer längre ner i kedjan.

Dessa definitioner överlappar i vardagligt tal, eftersom samma ord, AI, gör en hel del obetalt arbete. De ska inte överlappa i en bedömning. En allmän modell är gjord för att färdas. Dess möjliga användningsområden är medvetet breda. Ett AI-system är den operativa uppställning genom vilken utdata påverkar en miljö. Det har ett syfte, en konfiguration, ett gränssnitt och en miljö. Det kan innehålla en modell, flera modeller, deterministiska regler, databaser, sensorer, människor, rutiner och en mängd små beslut som ingen kallar artificiell intelligens förrän de misslyckas.

Det är därför en leverantör av en allmän AI-modell och en leverantör eller distributör av ett AI-system inte bara kan byta checklistor med varandra. I kommissionens vägledning om allmänna AI-modeller anges att modellleverantörer måste göra information och dokumentation tillgänglig för leverantörer av AI-system längre ner i kedjan, så att dessa leverantörer kan förstå modellens kapacitet och begränsningar och uppfylla sina egna skyldigheter. Den meningen är mer intressant än den först verkar. Den utgår från att leverantören längre ner i kedjan har ett arbete som inte kan slutföras av modellleverantören. Modelldokumentationen färdas, men den fullbordar inte resan.

Det ligger en praktisk ödmjukhet i detta. En modellleverantör kan beskriva arkitektur, träningsprocess, utvärdering, avsedda uppgifter, integrationskrav, indata och utdata, begränsningar och kända villkor. Ett team längre ner i kedjan vet om en användare är en utbildad specialist, om en berörd person kan bestrida ett utfall, om en rekommendation är rådgivande till namnet men bindande i praktiken, om ett anrop till en extern tjänst ändrar en post, och om en felaktig åtgärd kan ångras. Ingen av parterna har en komplett bild på egen hand.

Uppdelningen är inte en kryphål. Den är en ansvarskarta. Den säger att ett system inte kan styras genom att be modellleverantören lova kontroll över en driftsättning som de varken driver eller ser. Den säger också att en integratör inte kan skylla på okunnighet när dokumentationen gör en viktig begränsning synlig. Poängen är inte att göra en snygg överlämning mellan juridiska enheter. Det är att undvika att frågan tappas bort i glappet mellan dem.

Det finns en andra distinktion som är värd att hålla i minnet vid sidan av den första. En klassificering som hög risk innebär i sig inte tillstånd, säkerhet, rättvisa eller lagenlighet. I sitt gemensamma yttrande över kommissionens ursprungliga förslag betonade Europeiska dataskyddsstyrelsen och Europeiska datatillsynsmannen att en klassificering som hög risk inte nödvändigtvis innebar att ett system var lagenligt som sådant eller att användaren kunde driftsätta det som sådant. Den slutliga akten har förändrat den rättsliga landskapet sedan det yttrandet, men den underliggande varningen är fortfarande användbar. Klassificering är ett regleringsvillkor. Det är inte ett kvitto på att institutionen kan sluta tänka.

Detta är viktigt eftersom en högriskstämpel kan ge upphov till två motsatta fel. Ett team kan behandla den som en permanent fläck på en modell och besluta att svaret helt enkelt är att inte titta vidare. Ett annat kan behandla en genomförd bedömningsprocess som ett tillstånd för alla senare sammanhang. Båda synsätten ersätter en etikett med ett argument. Europa har valt ett mer besvärligt tillvägagångssätt: identifiera systemet, dess syfte och dess roll, granska sedan de relevanta riskerna och skyldigheterna under hela dess livscykel.

Det avsedda syftet är där analysen får sin utgångspunkt

Avsett syfte låter anspråkslöst, nästan byråkratiskt. Det är det inte. Akten definierar det som den användning för vilken ett AI-system är avsett av sin leverantör, inklusive det specifika sammanhanget och de specifika användningsvillkoren i den information som leverantören tillhandahåller. Med andra ord är syftet inte en slogan på en produktsida. Det inkluderar det sammanhang och de villkor under vilka leverantören anger att systemet ska användas. Ett användbart syftesuttalande har tydliga gränser. Det anger vad systemet gör, för vem, med vilka indata, inom vilket arbetsflöde och var dess befogenhet slutar.

Jämför två beskrivningar. Den första säger att ett system använder AI för att hjälpa organisationer att fatta bättre beslut. Den är tillräckligt bred för att passa på en konferensbakgrund och för bred för att vara användbar. Den andra säger att ett system presenterar källkopplade sammanfattningar av en befintlig ärendeakt för utbildade granskare; det kan inte fatta, överföra eller genomföra ett beslut; granskaren måste verifiera citerade källor innan en sammanfattning används; och funktionen är inte tillgänglig för kategorier som kräver en separat lagstadgad process. Den andra beskrivningen är mindre spännande. Den är också något som en ingenjör, upphandlingsansvarig, regelefterlevnadskollega och berörd person kan invända mot i konkreta termer.

Syftet behöver inte vara en enda mening. I ett seriöst system är det vanligtvis ett kompakt paket: uppgift, resultat, användare, berörd population, miljö, befogenhet, undantag, beroenden och villkor. Aktens krav på teknisk dokumentation ger utrymme för just denna typ av redogörelse. Bilaga IV efterfrågar en allmän beskrivning av AI-systemet, inklusive avsett syfte, de personer och grupper som systemet är avsett att användas på, och de specifika versioner eller former i vilka det släpps på marknaden. Den efterfrågar också beskrivningar av systemarkitektur, datakrav, åtgärder för mänsklig tillsyn, livscykelövervakning och riskhanteringsåtgärder. Dokumentationen har den bredden eftersom en modellkort ensamt inte kan beskriva en driftsättning.

Syftet är också där ett team upptäcker att det har beskrivit en ambition snarare än en verksamhet. Vi kommer att stödja handläggare kan dölja ett dussintal olika arrangemang. Söker verktyget i dokument, sorterar arbete, utarbetar ett svar, rekommenderar en kategori, avvisar en ansökan, eskalera en varning, sätter en prioritet eller anropar en annan tjänst? Använder kollegan det före eller efter att ha bildat en oberoende uppfattning? Är resultatet ett förslag i en sidopanel eller ett fält som måste rensas innan ärendet kan gå vidare? Är effekten omedelbar, fördröjd, reversibel eller svår att upptäcka? Svaret förändrar systemet även när användargränssnittet ser bekant ut.

En leverantörs avsedda användningsområde kan inte få verkligheten att försvinna. Ett team kan inte ge ett system ett brett praktiskt mandat, beskriva det som en ofarlig assistent och förvänta sig att beskrivningen ska avgöra saken. Men ett korrekt avgränsat användningsområde är ändå en kontroll. Det talar om för användarna vilka bevis som har beaktats, talar om för integratörer vad de inte får utöka i förbigående, och talar om för granskare vilken förändring som skulle öppna bedömningen på nytt. Ett vagt användningsområde gör varje senare fråga till en diskussion om vad som egentligen menades. Ett avgränsat användningsområde låter en organisation fråga sig om den fortfarande gör det den godkände.

Detta blir särskilt viktigt när en organisation gör en väsentlig ändring. Förordningen innehåller regler om fall där en distributör, importör, driftsättare eller annan tredje part kan bli leverantör, inklusive när den släpper ut ett system på marknaden under eget namn, gör en väsentlig ändring eller ändrar det avsedda användningsområdet på ett sätt som gör att systemet blir högrisk. Den exakta rättsliga tillämpningen beror på omständigheterna och bör kontrolleras i sitt sammanhang. Den operativa lärdomen är enklare: en integrationsändring kan vara en styrningshändelse. Att flytta en modellutdata från en utkastruta till en besluts kö kan vara en produktändring, en arbetsflödesändring och en ansvarsändring på en och samma gång.

Sammanhanget är inte kuliss

Driftsättningssammanhanget behandlas ofta som det som kommer efter det verkliga arbetet: en lista över länder, ett hostingval, några användarpersonas, kanske ett diagram med pilar som lydigt leder från vänster till höger. Men sammanhanget ger risken dess form. Samma typ av utdata kan vara obekväm i en miljö och avgörande i en annan. Ett felaktigt ifyllt svar i ett skrivhjälpmedel kan korrigeras i nästa mening. En felaktig prioritering i ett arbetsflöde med begränsade resurser kan avgöra vilken fil en person ser först. En poäng som verkar vara en av många indata kan bli avgörande om alla andra indata är långsamma, vaga eller gömda bakom ett annat team.

Förordningens högriskansats återspeglar detta. Artikel 6 kopplar högriskklassificeringen till system som är avsedda att användas som säkerhetskomponenter i vissa produkter, eller system som avses i bilaga III. Bilaga III listar områden där AI-system kan vara högrisk eftersom de är avsedda för specifika användningar, såsom vissa biometriska användningar, kritisk infrastruktur, utbildning och yrkesutbildning, anställning, tillgång till väsentliga privata och offentliga tjänster och förmåner, brottsbekämpning, migration och gränskontroll samt rättskipning och demokratiska processer. De juridiska detaljerna spelar roll, men det gör även grammatiken. Det säger inte att en teknisk artefakt är högrisk i abstrakt mening. Det säger upprepade gånger avsedda att användas.

Artikel 6 innehåller också en kvalifikation för vissa system i bilaga III: de ska inte anses vara högrisk om de inte utgör en betydande risk för skada på fysiska personers hälsa, säkerhet eller grundläggande rättigheter, inklusive genom att inte väsentligen påverka resultatet av beslutsfattande. Leverantörer måste dokumentera den bedömningen innan de släpper ut systemet på marknaden eller tar det i bruk. Detta är inte ett generellt undantagskort. Det är en påminnelse om att systemets faktiska effekt spelar roll. En användbar analys har tillräckligt med detaljer för att förklara varför ett system gör, eller inte gör, en väsentlig påverkan på ett resultat. Om den förklaringen inte kan skrivas utan att sväva på målet, har teamet lärt sig något innan lanseringen.

Context includes time. A recommendation at the start of a broad investigation has a different effect from a recommendation at the point where a person has one chance to supply missing material. It includes volume. An individual reviewer may challenge an output when five cases arrive each day and follow it by default when five hundred arrive before lunch. It includes language. A reviewer who can read the evidence in their own working language may exercise a different kind of oversight from a reviewer who receives an assertive summary of material they cannot independently inspect. It includes local procedure, appeal rights, staffing, access to a specialist, the availability of a fallback, and whether an output reaches a person with enough authority to do something useful.

None of that requires an invented disaster to be true. It is simply how systems work. A formal policy can say human in the loop, but the system may still be functionally automatic if the person has no time, information, authority or practical route to disagree. Article 14 of the Act therefore speaks of effective human oversight appropriate to the risks, level of autonomy and context of use. It requires high-risk systems to be designed and developed so that people can understand relevant capabilities and limitations, remain aware of a tendency to rely automatically on output, correctly interpret output, decide not to use it, override or reverse it, and stop the system safely where appropriate. Those are operational questions. They cannot be answered from a model benchmark alone.

Select a deployment posture. The model stays put; the system boundary, authority and evidence needed do not.

Users are part of the control surface

It is tempting to talk about users as though they sit outside the system, holding a keyboard and making the human bit happen. They are part of the operating arrangement. Their knowledge, workload, authority, incentives and routes to help determine what the output does. A system designed for a specialist who can inspect source material is not automatically suitable for a generalist expected to work at pace. A tool that is useful for a reviewer who can reject a recommendation is not automatically suitable for a colleague who can only click approve or wait for someone else.

Detta innebär inte att en användare måste ifrågasätta varje komponent varje gång. Det vore en märklig definition av användbar teknik. Det innebär att tillsyn bör utformas som en verklig uppgift. Personen behöver veta när systemet används, vad den relevanta begränsningen är, vilka bevis som finns, vilken typ av invändning de kan registrera och vad som händer efter att de registrerat den. De behöver befogenheter som matchar ansvaret. Att be någon övervaka en utdata som de inte kan pausa, korrigera eller dirigera är mindre mänsklig tillsyn och mer mänsklig dekoration.

Förordningen ger distributörer en roll här. Artikel 26 kräver att distributörer av högrisksystem vidtar lämpliga tekniska och organisatoriska åtgärder för att säkerställa att de använder systemen i enlighet med medföljande instruktioner. Den ber distributörer att tilldela mänsklig tillsyn till fysiska personer med nödvändig kompetens, utbildning och befogenhet, samt att övervaka driften på grundval av instruktionerna. I vissa fall krävs också att automatiskt genererade loggar hålls under deras kontroll. Detta är inte en begäran om att hålla en kunnig person i närheten ifall gränssnittet blir nervöst. Det är ett krav på att arrangera en arbetsrutin.

Utbildning diskuteras ofta som hela svaret. Det är det inte. Utbildning kan hjälpa en person att känna igen en begränsning, men den kan inte skapa en källpost som gränssnittet döljer. Den kan inte skapa tid som en ködesign förbrukar. Den kan inte skapa befogenhet som ett kontrakt reserverar någon annanstans. Den kan inte reparera en integration som omvandlar en försiktig rekommendation till en oåterkallelig åtgärd. En organisation bör naturligtvis utbilda människor. Den bör också göra den uppgift de utbildas för möjlig att utföra i det system de faktiskt får.

Det finns ett användbart test: beskriv användarens åtgärd utan att använda verbet granska. Vad läser de? Vilken jämförelse kan de göra? Vad kan de avböja? Var hamnar skälet? Vem ser det? Vad händer med rekommendationen efter avslag? Kan den person som påverkas av resultatet fråga vad som hände? Kan en senare kollega rekonstruera det relevanta tillståndet? Om svaren förblir allmänna är tillsynsdesignen troligen också allmän.

Det testet gäller bortom högrisksystem. Lagen har specifik räckvidd och datum; gott operativt omdöme väntar inte på en kategorietikett innan det frågar om en person har placerats i en performativ roll. Det är fullt möjligt att bygga ett verktyg med låga konsekvenser som gör människor dummare om sitt eget arbete eftersom utdata är för smidig att ifrågasätta. Det är också möjligt att bygga ett begränsat verktyg som ökar en persons förmåga att ställa bra frågor eftersom det bevarar bevis, begränsar sin auktoritet och gör osäkerhet synlig. Modellen kan bidra till båda utfallen. Systemet avgör vilket utfall som har någonstans att hända.

Berörda personer sitter utanför konsolen

Många av de viktigaste personerna i ett AI-system rör det aldrig. De kan vara en kandidat, elev, arbetstagare, patient, passagerare, boende, kund, sökande, låntagare, vittne eller allmänhetens medlem. De kanske inte vet att en modell var inblandad. De kanske bara upplever ett svar som kommer snabbt, en begäran som försenas, en tjänst som blir otillgänglig, en prioritet som skiftar eller ett beslut som verkar omöjligt att förstå. Deras frånvaro från gränssnittet gör dem inte frånvarande från systemet.

Detta är en anledning till att förordningens riskramverk hänvisar till hälsa, säkerhet och grundläggande rättigheter. Det riktar uppmärksamheten mot konsekvenser som inte kan reduceras till huruvida en inloggad kollega gillade verktyget. Det är också därför en syftesbeskrivning bör namnge de personer och grupper som systemet är avsett att användas på, som bilaga IV kräver. Ett system byggt kring en kategori som kallas användare kan tyst dölja en skillnad mellan den person som manövrerar gränssnittet och den person som lever med resultatet.

De som berörs ändrar vilka frågor ett team behöver ställa. Finns det ett sätt att veta att systemet hade en meningsfull roll? Bygger beslutet på information som kan korrigeras? Gör ett språk, en funktionsnedsättning, en enhet, en plats eller en administrativ status det svårare att delta? Får det operativa teamet signaler från de berörda, eller bara från instrumentpanelen? Når en korrigering datat, rekommendationen, beslutet och eventuell efterföljande text som byggde på det? Dessa frågor är inte en begäran om att göra om varje system till ett offentligt samråd. De är en begäran om att följa konsekvensen tillräckligt långt för att se människan i andra änden.

Dataskyddslagstiftningen är relevant när personuppgifter behandlas, parallellt med AI-förordningens ramverk. EDPB och EDPS gjorde den punkten tydlig i sitt gemensamma yttrande från 2021 om förslaget: befintlig EU-lagstiftning om dataskydd gäller för behandling av personuppgifter inom förslagets tillämpningsområde. Den exakta rättsliga analysen beror på behandlingen och de aktörer som är inblandade. Lärdomarna för styrningen är okomplicerade. En klassificeringsövning kan inte absorbera alla andra skyldigheter. Integritet, icke-diskriminering, sektorsspecifika skyldigheter, krav inom förvaltningsrätten, konsumentregler och avtalsåtaganden försvinner inte bara för att ett team har gjort en snygg riskregister.

Det finns också en grundläggande fråga om läsbarhet. En person behöver inte bli maskininlärningsexpert för att förstå hur man söker korrigering. Men ett system får inte använda teknisk komplexitet som skäl för att göra korrigering omöjlig. En bra väg skiljer mellan vad systemet registrerade, vad en människa beslutade, vilka bevis som övervägdes, vad som fortfarande är osäkert och vad som fortfarande kan ändras. Den gör inte anspråk på en precision som registren inte kan stödja. Inom detta område är ärlighet inte bara en ton i rösten. Det är en del av tjänsten.

Integration är där ansvar byter händer

Team ritar ibland en AI-arkitektur som en snygg kedja: modell, prompt, svar, användare. Verkliga driftsättningar liknar mer en kommunal karta efter att någon har kommit ihåg servicerören. Det finns identitetssystem, hämtningslager, verktygsbehörigheter, köer, scheman, cacheminnen, observerbarhetsplattformar, webbläsartillägg, batchjobb, godkännanderegler, lagringsinställningar, leverantörer och människor som ärver en uppgift för att den tidigare personen har gått på semester. Modellen är viktig. Den är sällan ensam.

Varje integration kan förändra vad systemet kan göra och hur ett fel rör sig. Hämtning kan få ett modellresultat att verka förankrat medan källan är inaktuell, ofullständig eller felaktigt avgränsad. Ett verktygsanrop kan förvandla ett utkast till en tillståndsändring. En kö kan förvandla en aktuell rekommendation till en försenad. Ett orkestreringslager kan välja en annan modell eller en annan promptversion. Ett användargränssnitt kan dölja osäkerhet som finns i ett lägre lager. En identitetsintegration kan ge ett användbart verktyg åtkomst till material som en användare annars inte kunde öppna. Ingen av dessa iakttagelser anklagar en viss produkt eller organisation. De beskriver vanliga systemegenskaper, vilket är just därför de bör dokumenteras innan de blir överraskande.

Kommissionens vägledning om GPAI är användbar här eftersom den placerar information vid överlämningspunkten. Dokumentationen för nedströmsleverantörer är tänkt att hjälpa dem att förstå modellens kapacitet och begränsningar, dess avsedda uppgifter, tekniska integrationskrav, specifikationer för in- och utdata samt information om träningsdata. Den informationen är nödvändig. Den räcker inte. Nedströmsteam måste fortfarande besluta hur modellen ska användas med promptar, om ett resultat ska visas med bevis, vilka verktygsbehörigheter som tillåts, hur en ändring testas, vilka loggar som behålls och om en rekommendation får påverka ett visst arbetsflöde.

Det är därför ett köp av en modelltjänst inte är ett köp av en komplett riskprofil. Leverantörens dokumentation kan berätta för ett team att en modell har en känd begränsning eller att den utvärderades under vissa förhållanden. Den kan inte bevisa att köparens eget hämtningsindex är aktuellt, att köparens personal har den behörighet som krävs eller att en berörd person har tillgång till en kanal för att invända. Omvänt kan köparen inte kräva att en modellleverantör känner till varje lokal policy eller efterföljande process. Det ansvarsfulla är inte att låtsas att en sida kan känna till hela systemet. Det är att göra gränsen tydlig och hålla bevisningen i rörelse över den.

Artikel 25 utgör en användbar juridisk markör för denna operativa verklighet. Den anger omständigheter under vilka en annan part än den ursprungliga leverantören anses vara leverantör av ett högrisksystem för artificiell intelligens. Detta inkluderar att släppa ut systemet på marknaden under den partens namn eller varumärke, att göra en väsentlig ändring eller att ändra det avsedda syftet på ett sätt som gör att systemet blir högrisk. Bestämmelsen är teknisk och faktaberoende; ingen bör självklassificera utifrån ett blogginlägg. Men dess riktning är tydlig. Integrering och omprofilering kan förändra vem som bär leverantörsansvar. En efterföljande uppställning är inte för evigt efterföljande bara för att den ursprungliga modellen kom från någon annanstans.

Det finns en institutionell anledning att ta detta på allvar. När ansvaret förändras tyst blir säkerhet och upprättelse ett spel av organisatorisk ping-pong. Modellleverantören pekar på driftsättningen. Den som driftsätter pekar på modellen. Integratören pekar på molntjänsten. Tjänsteägaren pekar på en konfiguration som inte längre finns. Berörda personer får en polerad förklaring av hur komplext allt är. Det kan vara korrekt, men det är inte ett svar. Systemet behöver en registrering av vilken organisation som äger frågan vid varje gräns, och en väg för frågan att färdas när svaret finns någon annanstans.

Dokumentationen bör beskriva ett system som fortfarande kan förändras

Teknisk dokumentation har ett rykte om att anlända i slutet av ett projekt med en svag doft av panik. Förordningen beskriver en annan roll. För högrisksystem ska teknisk dokumentation upprättas innan systemet släpps ut på marknaden eller tas i bruk och hållas aktuell. Bilaga IV:s lista sträcker sig bortom modellbeteende till avsett syfte, versioner, systemarkitektur, utveckling, datakrav, validering och testning, mänsklig tillsyn, noggrannhet och cybersäkerhetsåtgärder, riskhantering, ändringar och övervakning efter lansering. Det är inte en dekorativ bilaga. Det är ett försök att bevara tillräckligt med minne för att någon ska kunna inspektera systemet efter att lanseringsmötet har blivit folklore.

Dokumentation fungerar bara när den kan visa samband. En modellversion måste kopplas till den systemversion som använde den. Ett test måste kopplas till sina inmatningsvillkor och sitt syfte. En policy måste kopplas till en verkställighetspunkt. En användarroll måste kopplas till den behörighet den har i gränssnittet. En loggningspolicy måste kopplas till den händelse den kan rekonstruera. En ändring måste kopplas till den bedömning den utlöste. Annars har ett team ett bibliotek av bra dokument och inget sätt att besvara en specifik fråga.

Loggar är ett liknande fall. Artikel 12 kräver att AI-system med hög risk har teknisk kapacitet för automatisk registrering av händelser under systemets livslängd, i proportion till det avsedda syftet. Loggar kan bidra till spårbarhet, övervakning efter lansering och operativ övervakning. De förklarar inte ett beslut genom magi. En logg kan berätta för en senare utredare att ett verktyg anropades, att en version var aktiv eller att en granskare klickade på en kontroll. Den kan inte på egen hand fastställa om granskaren förstod bevisningen, om inmatningskällan var auktoritativ eller om en process var rättvis. Register är värdefulla eftersom de ger en utredning en ärlig utgångspunkt, inte för att de eliminerar behovet av omdöme.

Övervakning efter lansering fullbordar bilden. Artikel 72 kräver att leverantörer av system med hög risk etablerar och dokumenterar ett system för övervakning efter lansering på ett sätt som står i proportion till teknikens art och riskerna med AI-systemet med hög risk. Detta har en enkel innebörd för driftsättningsteam: en release är inte det ögonblick då systemet blir fullständigt känt. Organisationen behöver ett sätt att ta emot relevant information, skilja en signal från en slutsats, avgöra om gränsen för det avsedda syftet fortfarande håller, och göra en ändring eller stoppa en användning när bevisningen kräver det.

Det arbetet är inte glamoröst. Det ser ut som versionsidentifierare, tydliga releasekriterier, en registrering av beroenden, ett test för en återställningsväg, en namngiven ägare för en begränsning och ett beslut som förblir synligt efter att personen som fattade det bytt roll. Det ser ut som att fråga om en integration har ändrats innan man frågar om modellen har ändrats. Det ser ut som att bevara tillräckligt med bevis för att korrigera en konsekvens snarare än att bara förklara den i efterhand. Tråkigt är inte motsatsen till ambitiöst här. Det är den del som gör att ambitionen får plats inom en institution.

Hur man resonerar om hela systemet utan att låtsas säkerhet

En fullständig analys är inte en strävan efter en universell riskscore. Det är en sekvens av frågor som blir mer exakt i takt med att en design blir mer exakt. Den första frågan är syfte: vad är detta system tänkt att göra, och vad är det specifikt inte tänkt att göra? Den andra är konsekvens: vem kan påverkas, hur, och genom vilket beslut eller vilken tjänst? Den tredje är auktoritet: vilken utdata kan ändra ett tillstånd, påverka ett beslut, sätta en prioritet eller ändra vad en person får? Den fjärde är bevis: vad stödjer systemets användning i detta sammanhang, och vilka villkor gör att bevisningen överförs?

Sedan kommer de obekväma frågorna. Vad händer när modellen är osäker, felaktig, otillgänglig eller används utanför sin angivna gräns? Vad ändras när en källa är inaktuell eller ett verktyg nekas? Vad händer om en användare har bråttom, är ny i rollen eller inte kan granska det underliggande materialet? Vad händer om en berörd person begär rättelse? Vad händer om en uppdatering ändrar en prompt, ett hämtningskorpus, ett gränssnittsstandardvärde, en modellversion eller en rollbehörighet? Svaret är ibland en teknisk kontroll, ibland en procedur, ibland en mer begränsad användning, ibland en annan ägare och ibland ett beslut att inte driftsätta. Styrning som aldrig tillåter det sista svaret är bara godkännande i en snyggare jacka.

Det hjälper att hålla flera påståenden åtskilda. Ett bekräftat faktum anger vad modellleverantören dokumenterade eller vad organisationen observerade i ett definierat test. En slutsats anger varför det faktumet kan vara relevant i ett särskilt arbetsflöde. En föreslagen kontroll anger vad teamet avser att genomföra. En kvarstående risk anger vad som återstår efter kontrollen. En juridisk slutsats anger vad som gäller enligt lag. Dessa är inte utbytbara. Ett bra dokument märker dem eftersom läsaren kan behöva ifrågasätta ett utan att förkasta de andra.

Det går till exempel att säga: leverantörens dokumentation anger att modellen har en viss begränsning; driftsättningsteamet drar slutsatsen att begränsningen kan påverka en specificerad användning; teamet föreslår en kontrollpunkt för källverifiering; kontrollpunkten har ännu inte testats under den avsedda arbetsbelastningen; och juridisk rådgivning måste bedöma den resulterande användningen enligt tillämplig lag. Den meningen är mindre tillfredsställande än en grön bock. Den är mer användbar än en grön bock eftersom den inte lämnar några frågetecken kring vad som har och inte har fastställts.

Team bör vara särskilt försiktiga med ordet människa. En mänsklig roll kan vara en kontroll, men bara när den har en definierad uppgift, tillräcklig information, tid, utbildning, befogenhet och en väg att agera. En mänsklig roll kan också bli ett sätt att överföra skuld till personen närmast skärmen. Distinktionen är inte filosofisk. Den är synlig i arbetsflödet. Om en granskare bara kan godkänna, om invändningar försvinner i ett oövervakat kommentarsfält, eller om ingen kan korrigera konsekvensen nedströms, har systemet inte fått någon meningsfull tillsyn bara för att en person klickade på något.

Samma försiktighet gäller transparens. Ett långt dokument kan göra ett system beskrivbart utan att göra det ifrågasättbart. En instrumentpanel kan göra det synligt utan att göra det begripligt. En upplysning kan tala om för en användare att AI är inblandad utan att tala om vad som kan göras åt ett fel. Den användbara frågan är praktisk: kan den relevanta personen hitta gränsen, bevisningen, den ansvariga rollen och korrigeringsvägen vid den punkt där dessa saker spelar roll? Om inte, finns informationen på fel plats för att styrning ska kunna ske.

En liten not från oss

På Dweve behandlar vårt offentliga Trust Centre modellposten och integrationen nedströms som relaterade men separata poster. Dess sida för nedströms säger att team som integrerar eller driftsätter Loom behöver aktuella funktioner, begränsningar, gränssnitt, utvärderingskontext och ändringar, medan den offentliga posten anger att en modell är en tråd i en bredare väv av komponenter och operativa gränser. Detta är en dokumentationshållning, inte ett påstående om att en offentlig sida klassificerar varje tänkbar driftsättning eller bevisar efterlevnad för en integrerare. Syftet med separationen är mer blygsamt: en modellpost ska följa med integrationen utan att låtsas ersätta integrerarens egen systemanalys.

Det är den standard som är värd att behålla. En modellleverantör bör göra användbar information tillgänglig. En organisation som driftsätter eller integrerar modellen bör beskriva det faktiska system den har skapat: syfte, människor, data, gränssnitt, befogenhet, övervakning och korrigering. Ingen av sidorna bör använda dokumentation som ett ceremoniellt utbyte där en part får en PDF och den andra får absolution.

Den svårare frågan är oftast den bättre

När ett team frågar om en modell innebär hög risk kanske det söker ett snabbt svar på en rimlig oro. Men den mer användbara frågan är oftast längre: vilket system bygger vi av den här modellen, för vilket syfte, i vilket sammanhang, med vilka människor, och vad händer när det blir fel? Den frågan kan inte alltid besvaras i ett enda möte. Den kan visa att den föreslagna användningen är snävare än väntat, att bevisningen är ofullständig, att en användarroll saknar befogenhet, att ett avtal lämnar en viktig gräns utan ägare, eller att en integration nedströms tyst har blivit systemets centrum.

Inget av dessa resultat är ett misslyckande med innovation. Det är saker som en institution lär sig innan den ger ett system makten att forma en annan persons valmöjligheter. Den europeiska ansatsen beskrivs ofta som en uppsättning skyldigheter. Den är också en disciplin av namngivning: namnge syftet, aktören, sammanhanget, versionen, den berörda personen, begränsningen, bevisningen och vägen till ingripande. När de väl är namngivna kan dessa saker testas, ändras och ifrågasättas. Innan de namnges tenderar de att dyka upp igen senare som överraskningar.

En modell kan vara kapabel, noggrant dokumenterad och värdefull. Den kan också placeras i ett system som kräver för mycket av den, döljer för mycket för dess användare eller lämnar för lite utrymme för en person som påverkas av resultatet. Skillnaden skapas utanför vikterna. Det är där det svåra arbetet finns, och där den allvarliga möjligheten också finns: bygg system vars auktoritet matchar deras bevisning, vars gränser överlever integration, och vars operatörer fortfarande kan säga nej.

Källor