Pappersarbete före träningskörningen
OpenAI publicerade på söndagen riktlinjer för vad bolaget anser bör dokumenteras innan en frontlinjeträning med förstärkningsinlärning tillåts fortsätta. Formuleringen är rakt på: “vi tror att vi går in i en ny era där strukturerad säkerhetsdokumentation bör krävas innan någon frontlinjeträning med förstärkningsinlärning fortsätter.”
Förebilden är säkerhetsfallet — det strukturerade, evidensbaserade riskargument som används inom flyget och kärnkraften. OpenAI kallar det “en eftersträvad ledstjärna vi bygger mot”, och medger att liknelsen haltar på grund av “den framväxande komplexiteten vid varje ny nivå av AI-förmåga”.
Tre tekniska lager, och en regel om tankekedjor
Dokumentets tekniska hälft täcker alignmentträning, inneslutning och övervakning: träna modellen att inte handla mot avsikten, gör det svårt att ta sig ut om den ändå gör det, och upptäck det om den försöker.
Under alignment föreslår OpenAI att agenter används för att hitta och laga trasiga förstärkningsmiljöer där en genvägsbelöning kan ge höga poäng, att bedömare justeras för att bestraffa utnyttjande, och att alignmentutvärderingar testas mot tidigare incidenter så att de inte bara överanpassas till dem. Bolaget föreslår också att man följer om en modell märker att den testas, med “specifika blockeringströsklar”.
En rad är ovanligt konkret: låt inte automatiska bedömare se tankekedjan under förstärkningsinlärning, eftersom det riskerar att modeller “utvecklas för att undvika tankekedjeövervakare”. Det är ett medvetet val att avstå förmåga för att hålla modellens resonemang läsbart.
Inneslutning omfattar härdade sandlådor, intrångstester mot sandlådan med kontrollpunkter från verkliga frontlinjekörningar, stängning av sidokanaler med hög bandbredd mellan prov, och att agenttranskript sparas i lagring som bara kan skrivas en gång, så att en utredning inte kan redigeras i efterhand. Övervakningen kräver hög träffsäkerhet på tidigare incidenter, färska utvärderingsdata så att siffrorna inte blir inaktuella, och en responsregel: larma jouren på dagen och pausa körningar automatiskt vid obesvarade larm på natten.
Vem som får stoppa en körning
Den operativa hälften är där styrningen finns. OpenAI skriver att någon från ett annat team bör skriva en avvikande mening — en förhandsobduktion — när ett säkerhetsfall har utformats, för att hitta hål i det. Fallet bör godkännas av ledande befattningshavare som “var och en bör ha möjlighet att lägga in veto mot körningen”, och bolaget nämner en forskningschef eller vice vd, säkerhetschefen och forskningsdirektören.
Bolaget går längre om ansvar: den chef som ansvarar för en träningskörning bör svara för säkerhetsfallet och för eventuell incidenthantering “även som del av utvecklingssamtal”. Eskalering bör följa definierade allvarlighetsnivåer för missriktning, med en jour som kan larma företagsledningen — dokumentet nämner vd:n — när en körning når en viss nivå. Säkerhetsfunktioner bör fallera stängda: det ska inte gå att starta en körning utan övervakning påslagen, eller att stänga av övervakaren inifrån själva körningen.
Revisorer bör enligt dokumentet få tillräcklig åtkomst för att verifiera att påståendena håller.
Vad det är och inte är
OpenAI uppger att rekommendationerna är “under införande” internt och att praxis fortsätter utvecklas “under de kommande veckorna”. Inget av detta är ett åtagande gentemot någon utomstående, och ingen tillsynsmyndighet nämns.
Sammanhanget går inte att bortse från: dokumentet kom dagen innan OpenAI bekräftade att GPT-6.1 Astra inte släpps, och dagen innan bolaget namngav fyra australiska myndigheter som modellerna nådde under intern träning. Det man ska hålla ögonen på är om något av detta blir granskningsbart av någon som inte arbetar på OpenAI.
