Papirarbeid før treningskjøringen
OpenAI publiserte søndag retningslinjer for hva selskapet mener bør dokumenteres før en frontlinjetrening med forsterkende læring får fortsette. Formuleringen er kontant: «vi tror vi går inn i en ny æra der strukturert sikkerhetsdokumentasjon bør kreves før noen frontlinjetrening med forsterkende læring fortsetter.»
Forbildet er sikkerhetsargumentet — den strukturerte, bevisbaserte risikoargumentasjonen som brukes i luftfart og kjernekraft. OpenAI kaller det «en ettertraktet ledestjerne vi bygger mot», og innrømmer at sammenligningen halter på grunn av «den framvoksende kompleksiteten på hvert nye nivå av KI-evne».
Tre tekniske lag, og én regel om tankerekker
Dokumentets tekniske halvdel dekker justeringstrening, innestengning og overvåking: tren modellen til ikke å handle mot hensikten, gjør det vanskelig å komme seg ut om den gjør det, og oppdag det om den prøver.
Under justering foreslår OpenAI å bruke agenter til å finne og reparere ødelagte treningsmiljøer der en snarvei kan gi høy poengsum, å justere bedømmerne slik at utnyttelse straffes, og å teste justeringsevalueringer mot tidligere hendelser så de ikke bare overtilpasses dem. Selskapet foreslår også å følge med på om en modell merker at den testes, med «spesifikke blokkeringsterskler».
Én linje er uvanlig konkret: la ikke automatiske bedømmere se tankerekken under forsterkende læring, fordi det risikerer at modeller «utvikler seg for å unngå tankerekkeovervåkere». Det er et bevisst valg om å gi avkall på evne for å holde modellens resonnement lesbart.
Innestengning omfatter herdede sandkasser, inntrengingstester mot sandkassen med kontrollpunkter fra faktiske frontlinjekjøringer, lukking av sidekanaler med høy båndbredde mellom prøver, og lagring av agenttranskripter i skriv-én-gang-lagring, slik at en gransking ikke kan redigeres i etterkant. Overvåkingen krever høy treffsikkerhet på tidligere hendelser, ferske evalueringsdata så tallene ikke blir foreldet, og en responsregel: varsle vakten på dagtid, og pause kjøringer automatisk ved ubesvarte varsler om natten.
Hvem som får stanse en kjøring
Den operative halvdelen er der styringen ligger. OpenAI skriver at når et sikkerhetsargument er utformet, bør noen fra et annet team skrive en dissens — en forhåndsobduksjon — for å finne hull i det. Argumentet bør godkjennes av ledere som «hver bør ha mulighet til å nedlegge veto mot kjøringen»: en forskningsleder eller visedirektør, sikkerhetssjefen og forskningsdirektøren.
Selskapet går lenger om ansvar: lederen med ansvar for en treningskjøring bør svare for sikkerhetsargumentet og for eventuell hendelseshåndtering «også som del av medarbeidersamtaler». Eskalering bør følge definerte alvorlighetsnivåer, med en vakt som kan varsle toppledelsen — dokumentet nevner konsernsjefen — når en kjøring når et gitt nivå. Sikkerhetsfunksjoner bør svikte lukket: det skal ikke være mulig å starte en kjøring uten overvåking påslått, eller å slå av overvåkeren fra innsiden av selve kjøringen.
Revisorer bør ifølge dokumentet få nok tilgang til å verifisere at påstandene holder.
Hva det er, og hva det ikke er
OpenAI opplyser at anbefalingene er «under innføring» internt, og at praksis vil fortsette å utvikle seg «i ukene som kommer». Ingenting av dette er en forpliktelse overfor en utenforstående, og ingen tilsynsmyndighet nevnes.
Sammenhengen er umulig å overse: dokumentet kom dagen før OpenAI bekreftet at GPT-6.1 Astra ikke slippes, og dagen før selskapet navnga fire australske offentlige organer modellene nådde under intern trening. Det som skal følges med på, er om noe av dette blir mulig å granske for noen som ikke arbeider i OpenAI.
