OpenAI offentliggjorde 29. maj 2026 en vejledning om, hvordan uafhængige tredjeparts-evalueringer af avancerede AI-modeller bør gennemføres. Nyheden handler ikke om en ny model, men om måden modeller bliver testet på. Det er relevant, fordi moderne AI-systemer ikke kun svarer på en enkelt prompt. De kan bruge værktøjer, arbejde over mange trin og indgå i større arbejdsgange.
I artiklen A shared playbook for trustworthy third party evaluations argumenterer OpenAI for, at evalueringsresultater ikke giver meget mening uden en præcis forklaring af testmiljø, værktøjer, budget og fejlkilder. For læsere i Danmark er pointen praktisk: hvis en leverandør siger, at en model er sikker, robust eller bedre end en anden, er det ikke nok at kende slutscoren. Du skal også kende betingelserne bag scoren.
Hvad er den konkrete nyhed?
Den konkrete nyhed er, at OpenAI har samlet sine anbefalinger til uafhængige evalueringer i en fælles playbook. OpenAI beskriver, hvilke typer påstande en evaluering kan understøtte, hvilke testopsætninger der passer til hver type påstand, og hvilke kendte fejlkilder der kan forvrænge resultatet.
OpenAI skriver også, at evalueringer af moderne AI ofte bør afspejle den måde brugere faktisk arbejder med systemerne på. Når en model bruges som en AI-agent, afhænger resultatet ikke kun af selve modellen, men også af værktøjsadgang, kontekststyring, gentagelser, budget og regler for, hvornår systemet må fortsætte eller stoppe.
Hvad er en tredjeparts-evaluering af en AI-model?
En tredjeparts-evaluering er en test, hvor en uafhængig aktør vurderer en models evner eller sikkerhedsforanstaltninger. Formålet er at skabe ekstra bevis for, hvordan modellen opfører sig, uden at leverandøren alene står for måling og fortolkning.
Det kan handle om tre forskellige spørgsmål, som OpenAI skelner mellem. Den første type er, om modellen overhovedet kan udføre en opgave under stærk og realistisk aktivering. Den anden type er, om to systemer kan sammenlignes under samme betingelser. Den tredje type er, om en sikkerhedsforanstaltning holder, når modellen udsættes for en troværdig og målrettet angrebsstrategi.
| Type påstand | Hvad man prøver at måle | Hvad der skal beskrives |
|---|---|---|
| Kapabilitet | Om systemet realistisk kan løse opgaver af en bestemt type | Værktøjer, budget, testmiljø og hvorfor opsætningen er troværdig |
| Sammenligning | Om system A klarer sig bedre end system B under samme betingelser | Fælles opgavesæt, samme scoring og samme eller på forhånd fastsat opsætning |
| Sikkerhed | Om en beskyttelse holder mod realistiske forsøg på omgåelse | Angrebsmodel, testharness, ressourcer og hvilke forsøg der blev tilladt |
Hvorfor fylder testmiljøet så meget i OpenAI’s forklaring?
OpenAI bruger ordet harness om det samlede testmiljø omkring modellen. Det dækker blandt andet værktøjer, hukommelse, kontekststyring, regler for genforsøg og måden output bliver scoret på. Pointen er, at to test af den samme model kan give meget forskellige resultater, hvis den ene test giver adgang til værktøjer og længere arbejdsforløb, mens den anden kun måler et enkelt svar.
Det er en vigtig forskel fra ældre benchmarktænkning. Hvis en model arbejder over mange trin, kan et fattigt testmiljø få systemet til at se svagere ud, end det reelt er. Omvendt kan et for generøst eller dårligt kontrolleret testmiljø få systemet til at se bedre ud, end det burde.
OpenAI nævner derfor, at evalueringer bør gøre det tydeligt, om målet er at måle maksimal realistisk præstation eller at sammenligne flere systemer på en ensartet måde. De to mål kræver ikke nødvendigvis samme opsætning.
Hvilke fejlkilder kan forvrænge en evaluering?
OpenAI peger på flere fejlkilder, som kan gøre en evalueringsscore misvisende. Nogle fejlkilder kan løfte scoren kunstigt, mens andre kan presse den ned.
- Reward hacking, hvor systemet finder en genvej til point uden at løse den egentlige opgave.
- Refusals, hvor sikkerhedsafvisninger skjuler, hvad modellen faktisk kunne have gjort.
- Contamination, hvor opgaver eller svar allerede findes i træningsdata eller kan findes via søgning.
- Broken problems, hvor selve testen er fejlbehæftet, tvetydig eller umulig at løse korrekt.
- Sandbagging, hvor modellen underpræsterer strategisk, fordi den genkender evalueringssituationen.
For almindelige brugere minder det om problemet med AI-hallucinationer: et flot svar eller en høj score er ikke det samme som et pålideligt resultat. I begge tilfælde er det afgørende at se på, hvordan svaret eller scoren blev til.
Hvordan bør du læse en evalueringsrapport mere kritisk?
Hvis du læser en rapport om en model, er det nyttigt at spørge, hvilken påstand testen faktisk prøver at understøtte. Viser rapporten, at modellen kan klare en opgave med adgang til relevante værktøjer, eller viser den kun, at modellen gav et stærkt svar i en begrænset chatopsætning? Viser rapporten sammenlignelighed mellem systemer, eller viser den maksimal præstation for ét enkelt system?
Det er også værd at se efter, om rapporten beskriver omkostninger og ressourcer. OpenAI fremhæver, at ekstra testbudget, flere tokens og længere agentforløb i nogle tilfælde ændrer resultatet markant. Derfor kan en lav succesrate stadig være praktisk vigtig, hvis opgaven kan gentages billigt mange gange.
- Se efter om testens formål er klart beskrevet.
- Kontrollér om værktøjer, budget, scoring og testmiljø er dokumenteret.
- Undersøg om rapporten diskuterer kendte fejlkilder og begrænsninger.
- Vurder om konklusionen går længere end data faktisk understøtter.
Det samme gælder, når du arbejder med systemer som RAG eller andre AI-løsninger med datakilder og værktøjer omkring modellen. Den reelle kvalitet opstår i samspillet mellem model, data, styring og kontrol.
Hvad betyder nyheden for danske virksomheder og offentlige arbejdspladser?
For danske virksomheder betyder nyheden først og fremmest, at leverandørers AI-påstande bør læses som dokumentationsspørgsmål og ikke som markedsføring. Hvis en leverandør siger, at en model er sikker, præcis eller robust, bør virksomheden efterspørge, hvordan påstanden er testet, og om testen ligner virksomhedens egen brugssituation.
Det gælder især i arbejdsgange med kundedata, personoplysninger, kontrakter, beslutningsstøtte eller automatiserede processer. En model, der klarer sig godt i et laboratoriemiljø, er ikke nødvendigvis lige så pålidelig i en kompleks arbejdsplads med integrationslag, lange kontekstforløb og brugeradgang på tværs af systemer.
I offentlige organisationer, uddannelse og større private virksomheder hænger det tæt sammen med governance. En AI-beredskabsplan er ikke kun relevant efter en fejl. Den er også relevant før anskaffelse og implementering, fordi organisationen skal kunne forklare, hvilke tests der er gennemført, hvilke risici der er accepteret, og hvordan fejl bliver opdaget og håndteret.
Hvilke EU- og danske forhold bør du kende?
Her er den danske relevans mere konkret end nyhedens amerikanske afsender. Ifølge EU-Kommissionens Q&A om general-purpose AI-modeller i AI Act skal udbydere af general-purpose AI-modeller dokumentere tekniske oplysninger, have en copyrightpolitik og offentliggøre et resumé af træningsindhold. For modeller med systemiske risici nævner Kommissionen desuden evalueringer, risikobegrænsning, hændelsesrapportering og cybersikkerhed som konkrete forpligtelser.
Det betyder ikke, at OpenAI’s playbook er juridisk bindende i sig selv. Den er en virksomheds anbefaling til, hvordan troværdige evalueringer kan se ud. Men anbefalingerne ligger tæt på det bredere regulatoriske behov for dokumentation, sporbarhed og risikovurdering, som danske organisationer allerede møder gennem EU-regler og interne compliancekrav.
Hvis en AI-løsning bruges i Danmark til følsomme formål, bør du derfor skelne mellem tre lag: hvad modellen kan i en demo, hvad leverandøren kan dokumentere i en evaluering, og hvad organisationen selv kan lovliggøre og styre i drift. Det sidste lag handler ofte om databehandling, adgangskontrol, logning, kontrakter og ansvar, ikke kun om modelkvalitet.
Hvilke begrænsninger har OpenAI’s forslag?
OpenAI’s tekst er nyttig, men den er stadig skrevet af en modeludbyder, som også har interesse i, hvordan evalueringer bliver udformet. Derfor bør anbefalingerne læses som et kvalificeret partsindlæg og ikke som en neutral standard i sig selv.
Der er også en praktisk grænse. Jo mere realistisk et testmiljø bliver, desto dyrere og mere komplekst bliver det at evaluere modeller ensartet. Et meget stærkt setup kan være godt til at vise maksimal kapabilitet, men sværere at bruge til fair sammenligninger på tværs af leverandører.
OpenAI foreslår blandt andet, at capability-evalueringer af OpenAI-modeller som minimum bør køre gennem Codex som fælles bundniveau. Det kan være nyttigt for reproducerbarhed, men det løser ikke automatisk spørgsmålet om, hvordan andre leverandører eller andre typer agentopsætninger bør sammenlignes. Derfor er feltet stadig under udvikling.
Hvad sker der sandsynligvis nu?
Den sandsynlige udvikling er, at evalueringer bevæger sig væk fra simple toplister og over mod mere detaljerede rapporter om testmiljø, budget, værktøjsbrug og validitet. Det vil gøre resultater sværere at sammenfatte i én score, men mere brugbare for organisationer, der faktisk skal træffe beslutninger om indkøb, styring og risici.
For almindelige brugere betyder det, at påstande om, at en model er bedst, sikrest eller mest pålidelig, i stigende grad bør læses med samme skepsis som andre tekniske præstationsmålinger. For danske virksomheder betyder det, at gode spørgsmål til leverandører bliver en konkurrencefordel: Hvad blev testet, hvordan blev det testet, og ligner testen den måde løsningen skal bruges på i praksis?
Nyheden peger derfor mindre på en enkelt OpenAI-opdatering og mere på en bredere modning af AI-markedet. Når modeller bliver mere agentiske og indgår i flere arbejdsprocesser, bliver selve evalueringen en del af produktets troværdighed.