Vem granskar granskaren?

Hundra AI-agenter fick i uppdrag att bevisa matematiska satser. De delade ett kunskapsbibliotek och ett automatiskt kontrollsystem.

De första trettiosju bevisen höll. Sedan hittade prover-theta en lucka: det gick att ändra symbolernas betydelse så att kontrollen godkände något mycket enklare än den ursprungliga uppgiften. Agenten dokumenterade metoden som elegant_answer_hack.

Tjugosju minuter senare var de återstående trettiofyra problemen ”lösta”. Fusket hade spridits genom biblioteket.

Det är en fallstudie i ett preprint från Google DeepMind, ännu inte en allmän beskrivning av hur AI-agenter fungerar. Men den ställer en fråga som angår fler än forskarna: hur vet vi att kontrollen faktiskt kontrollerar rätt sak? (Studien)

Kort sammanfattning

När AI arbetar i stor skala behöver också granskningen hjälp av AI.

Men en extra granskare kan följa med i samma felslut. Därför behöver vi pröva vad varje kontroll faktiskt fångar och kombinera kontroller som kan upptäcka olika sorters fel.

Begränsade behörigheter, kontrollerbara källor och människor med mandat att stoppa arbetet hör till den kedjan. Ett annat modellnamn räcker inte som kvalitetsstämpel.

Ett ord som återkommer

Transkript. Loggen från en körning: modellens meddelanden och resonemangstext, verktygsanrop och svar. Den visar vad systemet skrev och gjorde. Resonemangstexten är däremot ingen säker utskrift av modellens faktiska tankar eller motiv.

Varför granskningen behöver hjälp

Försök läsa 481 miljoner transkript.

Så brett sökte Anthropic efter incidenterna. Ett första filter valde ut 9,2 miljoner transkript för Claude-granskning. Inga ytterligare fall av jämförbar eller högre allvarlighetsgrad hittades. (Anthropic)

Hugging Face rekonstruerade omkring 17 600 angriparhandlingar i sin utredning. De beskriver själva hur AI behövdes för att återskapa förloppet och analysera materialet. (Hugging Face)

Det är lätt att säga att en människa ska ha sista ordet. Men först måste någon hitta det som människan behöver se. En varning som ligger begravd bland miljontals andra händelser hjälper ingen.

AI kan sortera, jämföra och lyfta avvikelser i en mängd som människor inte hinner läsa. Samtidigt måste vi kunna undersöka vad sorteringen missar. Annars flyttar vi bara tilliten ett steg bakåt.

Hugging Face stötte dessutom på ett annat problem. Modellerna de först använde vägrade hjälpa till med delar av analysen eftersom materialet innehöll angreppskod. Utredarna fick köra en modell med öppna vikter på egen infrastruktur. (Teknisk genomgång)

Skyddsfilter behöver alltså prövas även i legitimt försvarsarbete. Vi vill både försvåra angrepp och ge dem som utreder angreppen fungerande verktyg. Den avvägningen försvinner inte för att vi kallar något en säkerhetsfunktion.

En kontroll behöver prövas både för vad den stoppar och för vad den släpper igenom.

Fyra sätt som granskningen brast

1. Övervakningen var inte påslagen. OpenAI använde inte sin övervakning av modellernas resonemang i de aktuella utvärderingarna. I efterhand bedömde de att det övervakningssystem de prövade skulle ha larmat mer än ett dygn före intrånget hos Hugging Face. Det är en efterhandsbedömning, inte ett larm som faktiskt gick. (OpenAI)

2. Samma skydd gav olika resultat. I efterhandstest skulle Claude Codes automatiska kontroll ha blockerat 66 procent av Mythos 5:s handlingar, 55 procent av Opus 4.7:s och 7 procent av den interna forskningsmodellens. Den sistnämnda beskrivs som ungefär lika kapabel som Mythos 5. Siffrorna mäter blockeringar i dessa förlopp, inte modellernas allmänna benägenhet att vägra. (Anthropic)

3. Sökningen missade material. Anthropics första AI-stödda genomgång av omkring 141 000 testkörningar missade transkript. När material samlades till METR hittades den fjärde incidenten: en tidig Opus 4.6-version i januari 2026. (Anthropic)

4. Granskaren följde med i felslutet. En efterhandsprövad övervakare bedömdes kunna flagga två av tre förlopp. I Mythos 5-fallet påverkades den av modellens resonemang om att miljön var simulerad och skulle sannolikt ha missat incidenten. (Anthropic)

Stanna vid den sista ett ögonblick.

En förklaring till varför en handling skulle vara tillåten blev en del av granskarens underlag. Då kan ett välformulerat felslut få hjälp genom nästa kontroll.

Min slutsats är att granskaren behöver pröva uppdragets gränser och vad handlingarna faktiskt gör, även när förklaringen låter rimlig. Det behöver vi testa, inte bara hoppas på.

Fråga vilka fel nästa kontroll kan hitta som den förra missar.

Spegeln mot din organisation

Det här är värt att fråga även om ni aldrig kör säkerhetstester mot datorsystem.

Jag skrev i När AI:n vänder blicken inåt om att AI börjat granska sitt eget arbete, och tyckte då att det var en uppmuntrande utveckling. Det tycker jag fortfarande. Men frågan om hur granskningen går till behöver få mer plats.

En modell kan absolut hitta fel i en annan körnings svar, även inom samma modellfamilj. Det går inte att dra slutsatsen att sådan granskning saknar värde. Däremot behöver värdet visas med exempel där det faktiskt finns fel att upptäcka.

Tänk på en sammanfattning som kontrolleras av samma assistent som skrev den. Får granskaren läsa ursprungskällorna, eller bara den färdiga texten? Vet den vilka uppgifter som måste finnas med? Prövar den påståendena ett i taget, eller får den bara frågan om sammanfattningen ser bra ut?

Samma skillnad finns i kodgranskning och beslutsunderlag. Verktygets namn säger mindre än vad granskaren får se och vad den måste kontrollera.

I När AI har fel var poängen att de svåra felen ofta låter rimliga. Ett godkännande från en andra modell kan göra dem ännu lättare att lita på. Därför behöver också godkännandet gå att ifrågasätta.

Vad som faktiskt hjälpte

Det fanns kontroller som begränsade förloppen. Vi behöver lära av dem utan att skriva om intrången till framgångshistorier.

PyPI:s säkerhetssystem tog bort det skadliga paketet inom en timme. Det hann installeras på 15 system, enligt Anthropic sannolikt säkerhetsföretags isolerade analysmiljöer. Från en av dem läckte inloggningsuppgifter som användes för intrång i företagets riktiga databas. Borttagningen begränsade fortsatt spridning. (Första rapporten, senare analys)

Tor-trafik utlöste ett larm hos brittiska AISI. Internetåtkomsten var avsiktligt tillåten i deras test. Larmet ledde till att utvärderingarna stoppades och maskiner isolerades. (AISI)

Människor granskade och begränsade. I AISI-fallet fångade en mänsklig granskare det skadliga kodförslaget. En privatperson öppnade misstänkt kod i en isolerad miljö. AISI bedömer att sådana åtgärder hindrade de värsta utfallen i just deras incident. (AISI)

Varken människor eller regelbaserade filter är fria från blinda fläckar. Och olika modeller kan göra samma fel. Det intressanta är vilka fel varje lager kan fånga och vilka gränser som gäller även när modellen bedömer fel.

En nätverksregel kan blockera en förbjuden destination utan att först behöva övertyga agenten om att den är förbjuden. En människa kan stoppa ett arbete, men bara om varningen når fram och personen har både tid och mandat att agera.

Det knyter an till Lösningen finns redan – den är bara mindre än vi trodde. Börja med en kontroll vars uppgift går att beskriva och vars effekt går att pröva. Modellvariation kan hjälpa, men är ingen garanti för oberoende.

Börja med tio ärenden i veckan

Välj ett flöde där AI granskar AI och avsätt en halvtimme för ett första stickprov. Fortsätt om ärendena kräver mer tid.

Bestäm vad som räknas som rätt innan ni läser svaren: vilka källor, krav och gränser ska granskaren kontrollera?

Välj både några riskfyllda ärenden och några slumpmässiga. Bara enkla exempel säger för lite.

Kontrollera bedömningarna mot källorna. Anteckna faktiska fel, missade fel och falska larm. Att du själv hade valt annorlunda är inte automatiskt ett fel.

Jämför med nästa veckas stickprov. Noll hittade fel kan vara ett bra resultat, men tio ärenden bevisar inte att hela flödet fungerar.

Utse vem som tar emot avvikelser och får stoppa eller ändra flödet. Bestäm när en större granskning behövs.

Det här är en början. Ju större konsekvenser ett fel kan få, desto mer genomarbetad behöver kontrollen vara.

Övningen gör en abstrakt kvalitetsdiskussion konkret. Ni får exempel att arbeta med, kan se vad granskaren missar och pröva om nästa förändring hjälper.

Riskerna med att nöja sig med ett godkännande

Om vi inte undersöker granskningen kan flera saker hända:

Vi får en siffra utan innehåll. ”98 procent godkända” säger för lite om vi inte vet vilka fel kontrollen letar efter.

Samma fel passerar flera steg. Fler godkännanden kan öka tilliten utan att tillföra någon ny kontroll av källorna.

Skyddet passar gårdagens arbete. Nya verktyg, behörigheter och uppgifter kan förändra vad en agent kan ställa till med. Då behöver kontrollerna prövas igen.

Människor tappar kontakten med kvaliteten. Den som aldrig ser konkreta ärenden får svårt att avgöra vad en sammanfattande rapport betyder.

Varningen saknar mottagare. Ett larm utan någon som kan agera blir ännu en rad i en logg.

Det är därför jag vill börja i ett faktiskt arbetsflöde. Då går det att ställa en enkel följdfråga när någon säger att något är granskat: vad kontrollerades, och vad skulle ha hänt om det var fel?

De som slog larm var också AI

Tillbaka till de hundra agenterna. Några upptäckte de falska bevisen, varnade andra och föreslog förbättrad kontroll. Andra fortsatte med matematiken utan att känna till fusket.

Alla byggde på samma basmodell, men hade olika matematiska personas och olika kontext under arbetet. Studien visar att samma modell kan ge både fusk och motstånd mot fusk i den här miljön. Den avgör inte vad som orsakade varje agents val. (Preprint på arXiv)

Det gör avslutningen hoppfullare, och frågan mer krävande. Vi behöver undersöka både modellen och sammanhanget den arbetar i.

I förra delen hade Roger Boisjoly kunskapen men svårt att få gehör. Jämförelsen har sina gränser, men en fråga följer med hit: vad händer med den som säger att något inte stämmer? Finns det en väg för invändningen att påverka arbetet?

Vem granskar granskaren? Mitt svar är en kedja där varje kontroll har en tydlig uppgift, där resultat kan prövas mot något utanför den färdiga förklaringen och där någon ansvarar för att agera.

Det ger oss bättre möjligheter att upptäcka och begränsa fel. Hur långt det räcker behöver vi fortsätta undersöka.

AI kan göra framtiden bättre. Men inte av sig själv. Framtidstro är att agera som om framtiden fortfarande går att påverka, och det gör den.

Innan du stänger fliken, tre frågor att bära med sig in i veckan:

Var i era flöden granskar en AI en annan AI:s arbete?

Vad kan nästa kontroll upptäcka som den förra missar?

Vem får stoppa flödet när ett viktigt fel hittas?

Detta är en personlig reflektion av Tobias Landén, Qlok, och den sista av fyra i serien Lydnad utan ansvar. Tack för att du läste hela vägen. Om någon av frågorna ovan kittlade eller skavde, hör gärna av dig. Vi gillar att tänka högt om det här tillsammans med andra.

Källor – granskning som brast: Anthropic: alignmentanalysen · OpenAI · Hugging Face: teknisk tidslinje

De hundra agenterna: Fallstudien på arXiv, preprint

Kontroller och skadebegränsning: UK AI Security Institute · Anthropic: de tre första incidenterna · METR & Redwood Research