Kan en tillsynsmyndighet granska ett rörligt mål?

Ja, men inte genom att låtsas att ett adaptivt system är ett statiskt objekt. En granskning kräver ett fångat tillstånd, ett avgränsat påstående, bevis med...

Kan en tillsynsmyndighet granska ett rörligt mål?

En granskning får ta ett fotografi

Ett rörligt mål är inte bortom granskning. Det är bara bortom den typ av granskning som ställer en tidlös fråga och förväntar sig ett tidlöst svar. Den skillnaden spelar roll. AI-system förändras på flera sätt samtidigt. En leverantör släpper en ny modellversion. En driftsättare ändrar prompten eller beslutströskeln. En hämtningskorpus får ett nytt policy-dokument. En identitetsregel ändrar vem som får anropa ett verktyg. Ett verktyg får ett fält, förlorar ett fält eller börjar returnera en annan betydelse under samma fältnamn. Ett mänskligt team ändrar sin procedur. Världen som levererar indata förändras utan att fråga någons releaseansvarige.

Inget av detta gör en granskning meningslös. Det gör granskningsobjektet mer precist. Frågan är inte om en organisation kan bevisa att ett system kommer att förbli oförändrat för alltid. Det vore ett märkligt löfte även för en miniräknare kopplad till en databas. Frågan är om organisationen kan visa vilket system som var i drift vid en relevant tidpunkt, vad det var avsett att göra, vilka bevis som stödde den användningen, vilka villkor som avgränsade bevisen, vem som ägde beslutet och vilken senare förändring som borde föranleda att beslutet omprövas.

En granskning får ta ett fotografi. Den får bara inte kalla fotografiet för landskapet. En korrekt dokumentation identifierar det tillstånd som granskades och håller reda på vägen från det tillståndet till nästa. Den kan då säga något användbart: denna utvärdering gällde denna modell, dessa inställningar, denna datagräns, dessa verktyg, denna policy, detta arbetsflöde och detta releasebeslut. Den kan också säga något mindre bekvämt och mer värdefullt: slutsatsen följde inte automatiskt med till nästa tillstånd.

Det är en bättre utgångspunkt än den välbekanta teatern med oföränderliga märkningar. En märkning antyder att någon har avgjort saken. En granskningsdokumentation bör göra det möjligt att se vad som avgjordes, på vilken grund, för vilken användning och hur länge den grunden förblev tillämplig. En tillsynsmyndighet behöver inte en frusen organisation. En tillsynsmyndighet behöver en organisation som kan skilja en frusen dokumentation från en levande tjänst utan att behandla någon av dem som ett mystiskt föremål.

Europas AI-regler pekar redan i denna riktning. För AI-system med hög risk kräver AI-förordningen teknisk dokumentation innan ett system släpps på marknaden eller tas i bruk, och kräver att den hålls uppdaterad. Den kräver också automatisk registrering av relevanta händelser under systemets livslängd och ett dokumenterat system för övervakning efter lansering som står i proportion till tekniken och risken. Det är inte instruktioner om att ta en enda ceremoniell skärmbild. Det är instruktioner om att bevara en beviskedja genom förändring.

Det rörliga målet är vanligtvis ett system

Det är frestande att beskriva ett AI-system som en modell och sedan diskutera versionshantering som om en ny modellviktsfil vore hela historien. Det är bekvämt för presentationsbilder och felaktigt för de flesta operativa frågor. En modell är en viktig komponent. Den är sällan det fullständiga objekt vars beteende påverkar en person, ett arbetsflöde eller en rättslig skyldighet.

Betrakta en vanlig beslutsstödsväg, här beskriven som ett hypotetiskt exempel snarare än en redogörelse för en verklig driftsättning. En användare skickar en begäran. Tjänsten hämtar dokument som den har tillstånd att använda. En modell utformar en rekommendation. En regel kontrollerar att nödvändiga bevis finns. En utbildad granskare kan acceptera, ändra eller avvisa rekommendationen. Ett arbetsflöde registrerar sedan en åtgärd. Det observerade utfallet beror på mer än modellen. Det beror på källversioner, hämtningsinställningar, behörigheter, gränssnittstext, trösklar, köregler, mänsklig auktoritet och åtgärdsgränsen.

Om källkorpusen ändras kan modellen få en annan faktabas utan att en enda parameter ändras. Om en prompt ändras kan en modell få i uppdrag att göra en annan typ av bedömning. Om en granskares skärm slutar visa osäkerhet kanske den mänskliga tillsyn som beskrivs i en riskfil inte längre är den tillsyn som människor faktiskt utövar. Om en integration börjar tillämpa rekommendationer automatiskt har systemet fått en ny befogenhet även om modellens svar är identiskt byte för byte.

Därför börjar en vettig revisionslogg med det avsedda syftet och systemgränsen. AI-förordningens krav på teknisk dokumentation i bilaga IV omfattar beskrivningar av avsett syfte, versioner, övervaknings- och kontrollfunktioner, validering och testning, riskhantering, ändringar under livscykeln samt relevanta prestandamått. Poängen är inte att varje system behöver en katedral av pappersarbete. Poängen är att en granskare inte kan bedöma ett påstående när det objekt som påståendet avser tyst ändrar form.

Att kalla det vidare objektet för ett system är inte ett sätt att få arbetet att låta mer storslaget. Det är ett sätt att undvika ett kategorifel. En modellevaluering kan besvara en modellfråga. En systemrevision måste besvara en systemfråga. Den förra kan fastställa hur en komponent betedde sig under definierade förhållanden. Den senare måste visa hur komponenten var kopplad till människor, data, regler, verktyg och konsekvenser. Det ena ersätter inte det andra. Ett modellresultat är inte en arbetsflödesbeskrivning, precis som ett bra däcktest inte är en färdplan.

Vad en revisor faktiskt försöker fastställa

Att revidera ett föränderligt system innebär inte att man spelar upp varje ögonblick av dess liv i ett mötesrum. Det innebär att göra särskilda påståenden granskningsbara. Användes systemet inom det angivna syftet? Stöddes releasebeslutet av bevisning som var lämplig för det syftet? Bevarade organisationen den information som behövdes för att utreda ett omtvistat utfall? Utlöste meningsfulla ändringar omprövning? Gjorde övervakningen skillnaden mellan en ofarlig uppdatering och en väsentlig ändring synlig? Kunde de ansvariga pausa, begränsa eller korrigera vägen när bevisningen inte längre höll?

Det är praktiska frågor eftersom var och en har en observerbar motsvarighet. Avsett syfte hör hemma i en logg. En evaluering har en testsvit, konfiguration, testpopulation eller inmatningsgräns, metod, resultat och begränsning. Ett releasebeslut har en ägare och villkor. En ändring har en identitet, ett datum, en anledning och en bedömd effekt. Övervakning har namngivna signaler, tröskelvärden eller granskningsutlösare. En pausväg har en befogenhet och en operation. Detaljerna varierar, men granskningsbarheten kommer från att förvandla abstrakta försäkringar till saker som någon annan kan inspektera.

Det finns en viktig gräns här. En revision bevisar inte att varje framtida utfall kommer att vara korrekt, rättvist eller ofarligt. Den kan inte förvandla en osäker värld till en deterministisk. Den kan fastställa om en organisation gjorde påståenden som var tillräckligt avgränsade för att granska, om den samlade in bevisning som kunde stödja dessa påståenden och om den behöll förmågan att ompröva dem. Det kan låta blygsamt. Det är också där ansvarsskyldigheten börjar.

Skillnaden mellan bevisning och försäkringsspråk är viktig. Att säga att en modell har evaluerats är ännu inte bevis på en användbar evaluering. Ordet behöver ett objekt. Utvärderad mot vilken uppgift, vilka kriterier och vilken data? Med vilken modell och vilket systemtillstånd? Under vilka driftsförhållanden? Vem kontrollerade metoden? Vad låg utanför omfattningen? Vad skulle göra resultatet inaktuellt? Utan dessa frågor är evaluering bara ett lugnande förflutet.

Kommissionens tidigare etiska riktlinjer för tillförlitlig AI uttryckte reproducerbarhet i klara ordalag: ett AI-experiment ska uppvisa samma beteende när det upprepas under samma förutsättningar. Det är en användbar definition eftersom den rymmer sin egen begränsning. Samma förutsättningar gör ett reellt arbete. Ett upprepat experiment kan visa huruvida den dokumenterade uppgiften är reproducerbar. Det kan inte visa att ett oförändrat beteende kommer att uppstå efter en ändrad datakälla, policy eller driftsväg. Reproducerbarhet är därför inte ett löfte om att världen står stilla. Det är en disciplin för att exakt ange vad som faktiskt skedde.

En fångad utvärdering är en tidpunkt. Granskningen blir beständig när nästa tillstånd kan jämföras med den.

Ett versionsnummer är nödvändigt men inte tillräckligt

Versionsnummer är användbara eftersom de hindrar en dokumentation från att låtsas att namn räcker. Ändå kan en versionsbeteckning också skapa falsk trygghet. En beteckning som version 4.2 kan identifiera en programvaruversion, men den identifierar inte nödvändigtvis det faktiska tillståndet för en AI-väg. Ett konfigurationsvärde kan ligga utanför modellarkivet. Ett sökindex kan byggas om från föränderliga dokument. En funktionsflagga kan välja en annan verktygssökväg. En policy-motor kan ändra en tillåten åtgärd. En tjänst kan därför ha ett oklanderligt formaterat versionsnummer och ändå vara svår att rekonstruera.

Det som spelar roll är den identitet som passar påståendet. Om påståendet gäller en offline-modellbenchmark kan modellartefakten, inferenskoden, parameterinställningarna, datasetversionen, måttdefinitionen och exekveringsmiljön vara väsentliga. Om påståendet gäller en live-tjänst för beslutsstöd kan dokumentationen dessutom behöva prompten eller mallen, sökkonfigurationen, källidentifierare och färskhet, behörighetsstatus, verktygsscheman, policyversion, granskargränssnitt och arbetsflödesregel. Ett granskningspaket behöver inte innehålla varje byte från varje system. Det behöver innehålla eller på ett tillförlitligt sätt peka på de element som skulle kunna ändra innebörden av påståendet.

Det är därför ett manifest ofta är mer användbart än ett arkiv som dumpats på en hårddisk. Ett manifest anger vilka artefakter som hör ihop, deras identifierare, deras integritetsreferenser, deras relationer och deras åtkomstvillkor. Det låter en granskare lokalisera det relevanta paketet utan att anta att varje källa kan kopieras till en obegränsad mapp. Vissa bevis innehåller personuppgifter, säkerhetskänsliga detaljer, licensierat material eller affärshemligheter. Granskningsbarhet kräver kontrollerad åtkomst och meningsfull spårbarhet, inte obligatorisk offentliggörande av allt som får ett system att fungera.

Bilaga IV har ett liknande praktiskt förhållningssätt. Den behandlar inte teknisk dokumentation som en kort produktbeskrivning. Den efterfrågar information om systemet och dess livscykel, inklusive ändringar som gjorts under utvecklingen och efter utsläppande på marknaden, övervaknings- och kontrollfunktioner, validerings- och testförfaranden med resultat, åtgärder för riskhantering samt en beskrivning av prestandamått. Dokumentet måste vara tillräckligt tydligt för att nationella behöriga myndigheter och anmälda organ ska kunna bedöma efterlevnad. Med andra ord måste informationen vara strukturerad för granskning, inte bara insamlad för att ett lagringssystem fanns tillgängligt.

Bakom allt detta ligger en liten men avgörande designfråga: vad skulle behöva ändras innan den tidigare evidensen inte längre kunde stödja det nuvarande påståendet? Svaret skapar versionsgränsen. Om en ny hämtningskälla ändrar den faktiska grunden för rekommendationer, hör den hemma i identiteten. Om ett nytt granskargränssnitt döljer en varning, hör det hemma i identiteten. Om en kosmetisk redaktionell ändring inte kan påverka det utvärderade beteendet, hör den troligen hemma i ändringshistoriken men inte i utvärderingens fingeravtryck. God versionshantering handlar inte om maximal insamling. Den handlar om välgrundad relevans.

Fånga kontraktet, inte bara utdata

Ett utdata är bevis på något, men det är inte alltid bevis på tillräckligt mycket. En skärmbild kan visa vad som visades på en skärm. Den kan ofta inte visa vilken modell som producerade den, vilken källa som hämtades, vad ett verktyg returnerade, vilken regel som tillämpades, vilka indata som utelämnades eller om vyn dolde en varning. Detta är en anledning till att skärmbilder samlas i efterlevnadsmappar med högtidligheten hos arkeologiska fynd och avsevärt mindre förklaringskraft.

Ett fångat kontrakt är rikare. Det knyter samman resultatet med de villkor under vilka systemet förväntades agera. För en utvärdering kan det inkludera den exakta testsviten, indata eller en skyddad referens till dem, de förväntade påståendena, modell- och tjänstekonfigurationen, relevanta policy- och verktygsversioner, exekveringsmiljön där den påverkar resultatet samt acceptansregeln. För en livekörning kan det inkludera förfrågans identitet, auktoriserad omfattning, käll- och hämtningsposter, modellrutt, verktygsanrop, kontroller, mänsklig intervention och resulterande tillståndsändring. Syftet är inte att föra en oändlig dagbok. Det är att behålla tillräckligt med kausalt relevant information för att kunna ställa en seriös fråga senare.

Det finns en användbar åtskillnad att göra. En utvärderingsfångst visar ett påstående om ett definierat test eller en definierad övning. En operativ post hjälper till att rekonstruera en viss händelse eller ett visst beslut. En releasepost förklarar varför en organisation tillät ett system i en definierad rutt. En ändringspost förklarar vad som senare ändrades. Dessa poster överlappar varandra, men de bör inte blandas ihop. Att behandla en produktionslogg som ett riktmärke, eller ett riktmärke som bevis på ett produktionsarbetsflöde, är ett effektivt sätt att få varje post att bära mer än den klarar av.

AI-förordningens loggningsregel för högrisksystem är på liknande sätt knuten till syftet. Artikel 12 kräver automatisk registrering av relevanta händelser under systemets livstid, med loggningsfunktioner som är lämpliga för det avsedda syftet. Förordningen hänvisar till spårbarhet av systemets funktion, övervakning av drift och övervakning efter utsläppande på marknaden. Den kräver inte en urskillningslös registreringsvana. Den kräver poster med ett uppdrag.

Den frasen, register med ett jobb, är en bättre vägledning än ett allmänt krav på observerbarhet. Modellidentifieraren kan hjälpa till att skilja en uppdatering från en annan. Ursprunget för indata kan förklara en överraskande rekommendation. En regelversion kan förklara varför ett resultat blockerades. En granskares åsidosättande kan förklara varför den operativa åtgärden skiljer sig från modellens förslag. En tidsstämpel kan fastställa ordningsföljd. En integritetsmedveten design ställer ändå frågan om varje fält är nödvändigt, proportionerligt, sparat under en definierad period och skyddat från det system det är avsett att inspektera.

Reproducerbarhet har två ärliga former

Människor använder ofta reproducerbar för att betyda en rad olika saker. Förväxlingen är förståelig. Ett team kan mena att det kan köra om en fast utvärdering och få samma poäng. En forskare kan mena att ett annat team kan köra den angivna metoden och granska resultatet. En operatör kan mena att en utredning kan återskapa det tillstånd som användes för ett visst beslut. En kund kan mena att ett arbetsflöde ger konsekvent behandling snarare än att ändras godtyckligt från tisdag till torsdag. Dessa är relaterade mål. De är inte en enda egenskap som bär flera hattar.

För det första finns reproducerbarhet av den fångade körningen. Om artefakten, konfigurationen, indata, relevant tillstånd och exekveringsvillkor hålls fasta, bör en upprepning producera det dokumenterade resultatet inom de villkor som systemet utlovar. Vissa system kan göra ett starkare deterministiskt anspråk för en definierad exekveringsväg. Andra förlitar sig på kontrollerad slumpmässighet, distribuerad infrastruktur eller tredjepartstjänster och kan bara göra ett snävare anspråk. Det ansvarsfulla språket är specifikt. Det säger vad som är fast, vad som mäts, vilken variation som fortfarande är möjlig och hur jämförelsen utförs.

För det andra finns reproducerbarhet av utvärderingsargumentet. En granskare måste kunna se varför sviten representerar anspråket, om måttet har den angivna innebörden, om acceptanströskeln är motiverad och om bevisen kan överföras till den operativa kontexten. Detta löses inte av en kontrollsumma. En kontrollsumma kan fastställa att en fil inte har ändrats. Den kan inte fastställa att filen testade rätt fråga, att populationen var lämplig eller att en poäng stöder det beslut som är kopplat till den.

De två formerna bör mötas. Ett perfekt repeterbart test som mäter fel sak är fortfarande fel test. Ett sofistikerat argument kopplat till en icke-repeterbar körning lämnar granskare oförmögna att skilja ett fynd från en lyckosam eftermiddag. Den användbara standarden är inte ett abstrakt krav på perfekt reproducerbarhet. Det är en synlig överensstämmelse mellan anspråket, metoden, de fångade villkoren, det observerade resultatet och den användning organisationen önskar tillåta.

Kommissionens vägledning om skyldigheter för leverantörer av allmän AI-modeller håller också utvärdering kopplad till dokumentation och risk. Den beskriver teknisk dokumentation för myndigheter och separat information för nedströmsleverantörer, inklusive kapaciteter, begränsningar och integrationsinformation. För allmänna AI-modeller med systemrisk kräver artikel 55 utvärdering med standardiserade protokoll och toppmoderna verktyg, inklusive dokumenterad adversariell testning för att identifiera och mildra systemrisker. En utvärdering som inte kan säga vad som testades, under vilka villkor och med vilka begränsningar blir inte mer användbar för att den kallas standardiserad.

Bevis har ett utgångsdatum

Bevis upphör inte att vara giltiga för att någon har bestämt sig för att vara svår. De upphör att vara giltiga när de förhållanden som gjorde att de kunde stödja ett påstående har förändrats tillräckligt mycket för att sambandet inte längre kan antas. Detta är vanligt resonemang. Ett test av en brokonstruktion täcker inte automatiskt ett annat material. En livsmedelssäkerhetskontroll täcker inte en ny leverantör genom optimismens kraft. En utvärdering av en AI-rutt bör inte automatiskt täcka en ändrad modell, ändrad datagräns, ändrad verktygsbehörighet eller ändrade konsekvenser av beslut.

Det svåra arbetet är att avgöra vilka ändringar som spelar roll. Detta är en fråga om teknisk bedömning, riskanalys och styrning, inte en enda procentsats inskriven i en policy. En korrigering som ändrar färgen på en knapp kanske inte har någon betydelse för en utvärdering. En ändring som gör en varning mindre synlig kan vara väsentlig om säkerhetsargumentet beror på att en granskare ser den. Omindexering av en källkorpus kan vara ofarlig för en uppgift och kritisk för en annan. En ny modellslutpunkt kan bevara en bred förmåga samtidigt som den ändrar latens, vägrarbeteende, språktäckning eller verktygsanvändningsmönster som spelar roll för rutten.

Användbar ändringskontroll börjar därför med en påverkansfråga, inte en release-ritual. Vilket påstående kan denna ändring påverka? Vilket antagande stör den? Vilka bevis var villkorade av det gamla tillståndet? Besvarar en avgränsad kontroll frågan, eller behöver rutten en ny utvärdering och ett nytt releasebeslut? Vem får fatta det beslutet, och vem kan ifrågasätta det? Svaren bör dokumenteras, eftersom nästa granskare annars måste sluta sig till dem från ärendetitlar, muntlig tradition och en liten ändring i teckensnittet på release-instrumentpanelen.

Det är också här som övervakning blir en del av bevisunderlaget snarare än en separat observabilitetshobby. Artikel 72 kräver att leverantörer av AI-system med hög risk aktivt och systematiskt samlar in, dokumenterar och analyserar relevanta data om prestanda under hela systemets livslängd så att de kan utvärdera fortlöpande efterlevnad. Planen för övervakning efter lansering utgör en del av den tekniska dokumentationen. Övervakning är således inte bara ett sätt att veta om tjänsten är belastad. Det är ett sätt att lära sig om de förhållanden som låg bakom det ursprungliga påståendet fortfarande gäller.

Övervakning gör inte varje resultat självförklarande. En ökning av oenighet mellan granskare och ett system kan ha många orsaker. En ändring i källfärskhet kan återspegla ett problem i datapipelinen snarare än modellförskjutning. En högre vägrarfrekvens kan representera en säkrare policy, en bruten integration eller en ny population av förfrågningar. Registret bör bevara tillräckligt med sammanhang för en mänsklig utredning. Mätvärden är signaler. De är inte vittnen.

Bevis är giltiga i ett definierat sammanhang. En väsentlig ändring skapar en fråga för granskning, inte en kryphål runt granskning.

Väsentlig ändring kräver en beslutsväg

Frasen väsentlig förändring behandlas ofta som om den namnger en självklar egenskap. Det gör den inte. Väsentlig för vilket anspråk, vilken risk och vilken användare? Svaret måste vara tillräckligt specifikt för att människor ska kunna använda det när de är trötta, sena och ivriga att kalla en förändring för mindre. En bra policy lovar inte att i förväg klassificera varje tänkbar uppdatering. Den namnger de faktorer som avgör om en ny bedömning behövs.

Dessa faktorer omfattar vanligtvis avsett syfte, berörda personer, befogenhet som beviljats rutten, datakällor och deras kvalitetskontroller, modell- eller systemarkitektur, utvärderingsomfattning, beslutströsklar, övervakningssignaler, mänsklig tillsyn, säkerhetskontroller och återställningsvägar. En ändring som påverkar någon av dessa kan vara väsentlig eller inte. Det som spelar roll är om den kan förändra de bevis som krävs för det befintliga anspråket eller den risk som återstår efter kontroller.

AI-förordningen innehåller ett uttryckligt ansvar kring väsentlig ändring. Dess exakta rättsliga tillämpning beror på systemet och de aktörer som är inblandade, så den bör inte komprimeras till en slogan. Den operativa lärdomen är enklare och bredare: en organisation bör veta när en förändring överför eller skapar ansvar, när den befintliga dokumentationen inte längre är tillräcklig, och när systemet måste bedömas igen innan en ny användning fortsätter. Det är mindre spännande än en funktionslansering. Det är också mindre sannolikt att det leder till ett svårt samtal där alla är överens om att systemet har förändrats men ingen äger beslutet.

En beslutsväg ger en förändring någonstans att ta vägen. En väg kan tillåta ett dokumenterat fynd om ingen påverkan. En annan kan kräva en riktad regressionsevaluering. En tredje kan kräva en bredare riskgranskning, en ändring av bruksanvisningen, en reviderad övervakningsplan eller ett nytt godkännande för lansering. Den allvarligaste vägen kan kräva att rutten förblir begränsad eller pausad tills bevis finns tillgängliga. Poängen är inte att göra varje redigering dyr. Det är att göra den viktiga redigeringen omöjlig att dölja som rutinmässigt underhåll.

Det finns en tillfredsställande brist på romantik i detta. En ändringslogg kan visa det tidigare tillståndet, det föreslagna tillståndet, de berörda anspråken, de granskade bevisen, beslutet, befogenheten och villkoren efter lansering. Det är styrning i arbetskläder. Det kommer aldrig att se lika spännande ut som en modelldemonstration. Det har den mer användbara egenskapen att det hjälper en organisation att förklara sig när en demonstration har blivit en verklig tjänst.

Evaluering bör kunna misslyckas offentligt, eller åtminstone i filen

Evaluering blir performativ när varje resultat antas vara ett lanseringsresultat. Ett moget evalueringsprogram måste kunna dra slutsatsen att bevisen är ofullständiga, att en tröskel missades, att en känd begränsning förhindrar en föreslagen användning, eller att ett anspråk behöver begränsas. Dessa är inte pinsamma undantag från processen. De är resultat av processen.

Detta är särskilt viktigt för adaptiva eller externt anslutna system. Ett team kan upptäcka att en svit inte längre representerar en levande inputpopulation. Ett verktygskontrakt kan bli för instabilt för att stödja ett anspråk om uppspelning. En modelluppdatering kan förbättra en uppgift men göra en skyddad rutt svårare att övervaka. En operativ signal kan visa att överlämningen från system till granskare misslyckas under normal arbetsbelastning. Det rätta svaret är inte nödvändigtvis en dramatisk nedstängning. Det kan vara en begränsning, ett reviderat arbetsflöde, ytterligare ett test, ett nytt acceptansvillkor eller ett beslut att inte göra det ursprungliga anspråket.

Protokollet måste låta en granskare se det negativa resultatet. Annars bygger en organisation en mycket effektiv maskin för att samla in enbart de bevis den gillar. Kvalitetsledningskraven i artikel 17 är relevanta här. De omfattar bland annat tekniker och förfaranden för konstruktion, utveckling och kvalitetskontroll; undersökning, provning och validering; datahantering; riskhantering; övervakning efter utsläppande på marknaden; rapportering av incidenter; och kommunikation med myndigheter. Ett kvalitetssystem är inte en pärm som får misslyckanden att försvinna. Det är ett sätt att upptäcka, dokumentera och åtgärda dem.

Samma princip styr tillgången. En extern tillsynsmyndighet, anmält organ eller auktoriserad granskare kan behöva teknisk bevisning som inte kan publiceras öppet. En offentlig sammanfattning kan vara lämplig för andra delar av protokollet. Detta är olika åtkomstvägar, inte olika fakta. Allmänheten ska inte erbjudas en gladlynt redogörelse medan det kontrollerade protokollet beskriver en snävare och mer villkorad verklighet. Sekretess kan vara legitim. Motsägelse är ett styrningsmisslyckande.

På Dweve gör vårt offentliga Trust Centre ett litet, medvetet begränsat exempel på denna åtskillnad. Dess utvärderingssida säger att en utvärdering identifierar modellen, exakt testsvit, konfiguration, fångat tillstånd, bevis och granskarens beslut. Den säger också att ett upprepat fångat kontrakt bör ge byteidentiska resultat på stödda arkitekturer, medan en livekörning kan skilja sig när externa bevis eller adaptivt tillstånd ändras. Sidan skiljer den offentliga metoden från ett ifyllt marknadsföringsresultat. Det är inte bevis på en modells kvalitet. Det är helt enkelt rätt form för ett påstående om utvärderingsprotokoll.

Liveövervakning är inte ett substitut för ett beslut före lansering

Övervakning beskrivs ibland som svaret på osäkerhet: lansera systemet, titta på instrumentpanelen, förbättra kontinuerligt. Det finns en användbar instinkt i den meningen. System behöver observation efter lansering eftersom driftsättning producerar information som ett laboratorium inte kan. Men övervakning kan inte i efterhand stödja ett beslut för vilket bevisningen aldrig var tillräcklig. Den kan inte säga till en person som påverkats av en bristfällig åtgärd med stora konsekvenser att organisationen ska lära sig av grafen nästa månad.

Utvärdering före lansering och övervakning efter lansering besvarar olika frågor. Utvärdering frågar om organisationen har tillräckliga bevis för att tillåta en definierad användning nu. Övervakning frågar om förutsättningarna bakom det tillståndet fortfarande gäller och om nya risker eller misslyckanden håller på att uppstå. Det första etablerar en startgräns. Det andra bevakar gränsen i drift. Ett trovärdigt system behöver båda, liksom en väg för data och operativt lärande att återvända till riskbedömning, dokumentation och ändringskontroll.

Den slingan är vad som förvandlar ett statiskt säkerhetspaket till ett levande protokoll. En utvärdering ger en baslinje. En driftsättningspost säger vilken baslinje som antogs. Loggning och övervakning visar relevant beteende. En ändring kan förändra baslinjen eller avslöja dess begränsningar. En granskning uppdaterar sedan påståendet, dess bevis, dess begränsningar eller dess status. Systemet rör sig. Protokollet följer med, men skriver inte om sitt eget förflutna. En revisor kan se både den aktuella positionen och vägen dit.

För högrisksystem är AI-förordningen uttrycklig med att övervakning efter utsläppande på marknaden bör samla in och analysera relevanta prestandauppgifter under hela livslängden och möjliggöra utvärdering av kontinuerlig efterlevnad. Den kräver också att distributörer övervakar drift baserat på bruksanvisningen och informerar leverantören och berörd myndighet utan onödigt dröjsmål när de har anledning att anse att användningen kan innebära en risk. Dessa krav undanröjer inte behovet av professionellt omdöme. De ger professionellt omdöme protokoll, utlösare och vägar.

Det finns en organisatorisk frestelse att behandla övervakning som driftteamets ansvar och utvärdering som modellteamets ansvar. Den uppdelningen kommer att misslyckas vid den första meningsfulla frågan om en live-rutt. Modellbyggaren kan veta varför ett test valdes. Operatören kan veta att källorna var inaktuella. Policyägaren kan veta att en beslutsregel ändrades. Granskaren kan veta att gränssnittet skapar automatiseringsbias. En granskningsspår bör förena deras bevisning utan att låtsas att en person ser hela systemet.

Kan en tillsynsmyndighet återskapa ett beslut?

Ibland bör svaret vara ja, inom en avgränsad omfattning. Om en organisation hävdar att ett beslut eller en utvärdering kan spelas upp, måste den definiera vad uppspelning innebär. Innebär det att upprepa ett modellanrop med samma prompt? Innebär det att återskapa hela hämtnings- och verktygssekvensen? Innebär det att rekonstruera den post som en granskare såg? Innebär det att validera en deterministisk beräkning från bevarade indata? Varje alternativ är användbart. Varje alternativ har olika tekniska och juridiska förutsättningar.

En meningsfull uppspelning börjar med bevarad identitet. Granskaren behöver veta vilken systemversion och konfiguration som gällde, vilka indata och källversioner som var tillåtna, vilka policyer och behörigheter som tillämpades, vilka externa beroenden som svarade och vilka mänskliga åtgärder som ändrade vägen. Vissa element kan behöva lagras direkt. Andra kan refereras via stabila identifierare och rekonstrueras genom kontrollerade system. Det som inte är acceptabelt är att kalla en övning uppspelningsbar när den är beroende av en live-webbsökning, en överskriven databasrad och en ihågkommen inställning från en ingenjörs bärbara dator.

Även då kan en uppspelning återskapa en post snarare än att upprepa världen. En live-källa kan uppdateras eller dras tillbaka. En tredjepartstjänst kan ändras. En adaptiv tjänst kan ackumulera nytt styrt tillstånd. En människa kan fatta ett annat omdöme när samma information presenteras. Dessa är inte brister i idén om uppspelning. Det är distinktioner som posten måste bevara. Uppspelningen kan visa vad systemet gjorde under det fångade avtalet. Den gör inte anspråk på att den nuvarande världen är identisk med det avtalet.

Det är därför mänskliga beslutsprotokoll hör hemma bredvid tekniska protokoll när mänsklig tillsyn är en del av säkerhets- eller rättighetsargumentet. En granskning kan behöva veta att en person granskade en rekommendation, vilken information som fanns tillgänglig för dem, vad de valde och vilken befogenhet de hade. Den behöver inte göra varje granskare till ett övervakningsobjekt eller bevara obegränsat personligt material. Den behöver tillräckligt med information för att fastställa om den utlovade tillsynen fanns i den aktuella händelsen.

Reproduktion är därför en stege, inte en skrytsamhet. På ett steg kan en granskare identifiera releasen. På nästa kan de inspektera bevisningen. Högre upp kan de återskapa ett test eller analysera en live-beslutsväg. Organisationen bör ange vilket steg den stödjer, var gränserna går och vilka delar som kräver auktoriserad åtkomst. Ett anspråk på blygsam, testbar uppspelning är mycket starkare än en vag försäkran om att allt är spårbart.

Granskningar behöver poster som inte överensstämmer med varandra

En organisations offentliga statuspost, interna releasepost, utvärderingsrapport, operativa loggar och incidentregister bör inte säga olika saker om samma grundläggande tillstånd. Men de bör inte heller vara identiska dokument. Var och en har en annan målgrupp och ett annat syfte. Den offentliga posten kan ange avsett syfte, status, kända begränsningar och en väg till ytterligare information. Den tekniska filen kan innehålla detaljerad arkitektur, data, tester och kontroller. Den operativa posten kan innehålla händelsenivåspårbarhet. Ändringsfilen kan förklara varför en tidigare slutsats omprövades.

Integriteten kommer från överensstämmelsen. Om en offentlig sida säger att en rutt är begränsad till rekommendation, ska de tekniska och operativa dokumenten inte beskriva automatiska åtgärder. Om en utvärdering säger att den rör en avgränsad källuppsättning, ska lanseringsdokumentet inte tyst tillämpa den på en senare uppsättning. Om en ändringslogg säger att en modelluppdatering var utan väsentlig betydelse, ska konsekvensbedömningen ange vilket påstående och vilken evidens som berörs. Om en övervakningssignal föranleder en granskning, ska det efterföljande beslutet vara spårbart. Dokumenten kan skilja sig åt i detaljeringsgrad. De får inte skilja sig åt om verkligheten.

Denna överensstämmelse är användbar för tillsynsmyndigheter eftersom den minskar behovet av att lita på en enda polerad artefakt. En granskare kan jämföra dokument. Den är användbar för organisationer eftersom den blottlägger avvikelser mellan team innan en extern revision gör det. Och den är användbar för berörda personer eftersom den offentliga förklaringen kan bli en verklig väg till ansvarsutkrävande snarare än ett dekorativt lager ovanpå ett separat internt system.

Arkitekturen behöver inte vara avancerad. En liten organisation kan använda en kontrollerad registerhållning, versionshanterade dokument, signerade exporter och disciplinerade ändringsgranskningar. En större organisation kan använda strukturerade manifest, append-only-loggar, policy-motorer och automatiserad evidensfångst. Den viktiga frågan är om metoden på ett tillförlitligt sätt kan koppla samman påstående, tillstånd, evidens, beslut och senare ändringar. En gigantisk verktygsflotta som tappar denna relation är helt enkelt ett dyrare sätt att vara vag.

Det finns en särskilt europeisk dygd i att göra dokumentationen granskningsbar utan att göra den teatralisk. Inte varje svar hör hemma på en offentlig instrumentpanel. Inte varje dokumenterad osäkerhet behöver en gladlynt ikon. Men när en organisation har gjort ett väsentligt påstående om ett adaptivt system, bör den kunna visa en tillsynsmyndighet var påståendet finns, vilket tillstånd det avsåg, och hur organisationen skulle veta att det hade blivit inaktuellt.

Granskningsfrågan förändrar designfrågan

Fråga tidigt om en tillsynsmyndighet skulle kunna granska systemet så som det faktiskt kommer att fungera. Svaret förändrar designval långt innan en formell granskning börjar. Det gynnar stabila identifierare framför tvetydiga etiketter. Det gynnar explicita policyversioner framför regler inbäddade i prosa. Det gynnar verktygskontrakt som kan dokumenteras och testas. Det gynnar källspårbarhet och färskhetsmarkeringar. Det gynnar en tydlig gräns mellan rekommendation och åtgärd. Det gynnar granskningsskärmar som bevarar den information en granskare behöver. Det gynnar paus- och återställningsmekanismer med namngiven behörighet.

Det förändrar också upphandlingen. En leverantörs uttalande om att en modell regelbundet förbättras räcker inte när driften är beroende av ett definierat utvärderat tillstånd. Köparen behöver veta hur ändringar meddelas, vilka artefakter som kan identifieras, vilken information som finns tillgänglig för konsekvensbedömning, om historiska dokument förblir tolkningsbara, och hur en rutt kan begränsas eller pausas. Detta är inte exotiska krav. Det är de praktiska villkoren under vilka en organisation förblir ansvarig för ett system som innehåller en leverantörskomponent.

Samma fråga förändrar utvärderingsdesignen. En användbar utvärderingssvit har en identitet och en motivering. Dess indata eller referenser är kontrollerade. Dess mätetal och tröskelvärden definieras innan resultatet läses. Dess undantag är synliga. Dess resultat knyts till det systemtillstånd som faktiskt diskuteras. Dess misslyckanden har en väg in i ett beslut. Dess villkor för omkörning är tydliga. En utvärdering med dessa egenskaper kan ifrågasättas. Det är en funktion, inte en olycklig bieffekt av att vara grundlig.

Framför allt ändrar frågan förändringens roll. Förändring slutar vara en pinsamhet som dokumentationen försöker dölja. Den blir en förstklassig händelse i systemets evidensmodell. Vissa förändringar kräver knappt mer än en registrering. Vissa utlöser ett test. Vissa öppnar upp releasebeslutet igen. Den disciplinerade organisationen blandar inte ihop dessa kategorier, och den behöver ingen framtida incident för att upptäcka att de fanns.

Så ja: en tillsynsmyndighet kan granska ett rörligt mål. Granskningen börjar med att vägra det falska valet mellan ett fruset modellkort och en helt okänd live-tjänst. Fånga tillståndet. Ange anspråket. Bevara villkoren. Koppla evidensen till beslutet. Registrera vad som förändras. Ombedöm när kopplingen inte längre håller. Målet kan röra sig. Spåret måste förbli läsbart.

Källor