Bliv en del af mit community / gratis nyhedsbrev — tilmeld dig her
OpenAI’s guardrails og run state gør udrulning af interne agenter til en betalt opgave med godkendelse og revision
Interne AI-udrulninger holder op med at være enkle, så snart en agent kan mere end at besvare spørgsmål. Hvis et system fordeler sager, udarbejder tilbud, beriger leads eller henter research ind i en arbejdskø, er det ikke længere blot en chatbot. Det deltager i en forretningsproces. Derfra ændrer de vigtige spørgsmål sig. Hvem godkendte handlingen? Hvad skete der helt præcist? Hvordan undersøger man det senere, hvis noget ser forkert ud? OpenAI’s aktuelle dokumentation om agenter er nyttig, fordi den behandler udrulning ud fra netop de hensyn: guardrails, godkendelser, tilstand, der kan genoptages, og tracing. Det er et tydeligt tegn på, at udrulning af interne agenter handler lige så meget om governance som om modeller.
Det handler ikke primært om at skrive prompts
Dokumentationen om guardrails opdeler kontrollen i fire kategorier: input-guardrails, output-guardrails, tool-guardrails og menneskelig gennemgang. De håndterer hver sin type fejl. Input-guardrails stopper skadelige eller irrelevante forespørgsler, før workflowet begynder. Output-guardrails validerer, filtrerer eller anonymiserer det, der forlader systemet. Tool-guardrails ligger omkring bestemte funktionskald og kontrollerer argumenter eller resultater. Menneskelig gennemgang sætter kørslen på pause før handlinger med konsekvenser, såsom redigeringer, annulleringer, shell-kommandoer eller følsomme MCP-handlinger.
Denne opdeling er vigtig, fordi den reelle risiko ved intern AI som regel er knyttet til beføjelser, ikke formuleringer. En agent, der læser en sag og udarbejder et forslag, er én ting. En agent, der opdaterer en post i CRM-systemet, sender et tilbud eller udløser et script, er noget andet. OpenAI’s mønster er nyttigt, fordi det lader modellen identificere næste trin uden at forudsætte, at trinnet skal udføres automatisk. I praksis flytter det planlægningen af udrulningen i retning af en oversigt over værktøjer og fornuftige risikoniveauer: værktøjer med skrivebeskyttet adgang, værktøjer med skriveadgang, kundevendte værktøjer og værktøjer med større konsekvenser, som ikke bør køre uden godkendelse.
Run state er forskellen på automatisering og gætværk
Vejledningerne Running agents og Results and state beskriver agenten som et loop frem for et enkeltstående svar. Én kørsel er én tur på applikationsniveau. Runtime-miljøet kan kalde den aktuelle agent, undersøge dens output, udføre værktøjskald, overdrage opgaven til en anden specialist og fortsætte, indtil det når et reelt stoppunkt. Det minder langt mere om et egentligt forretningsworkflow end det enklere chatbotmønster.
Resultatet omfatter også mere. Dokumentationen dækker det endelige output, historik, den senest anvendte agent til næste tur, det seneste response ID til serverstyret fortsættelse og – vigtigst ved udrulninger med governance – afbrydelser samt state. I et godkendelsesflow kan en kørsel stoppe uden at levere et endeligt svar. Afbrydelser viser, hvilke afventende værktøjskald der kræver en beslutning, og state er det gemte snapshot, der sendes tilbage til runtime-miljøet efter en godkendelse eller afvisning. For en virksomhed skaber det et oplagt sted at vedhæfte revisionsdokumentation i stedet for at være afhængig af skærmbilleder, mailtråde eller nogens erindring om, hvad systemet foretog sig.
Godkendelsesprocessen bør afspejle værktøjernes risiko
Vejledningen om integrationer og observability gør det også tydeligere, hvor kontrollen bør ligge. OpenAI skelner mellem hostede MCP-værktøjer og forbindelser til lokale eller private MCP-servere, der administreres via SDK’et. Det passer godt til den måde, en reel udrulning bør designes på. Nogle funktioner kan uden problemer ligge i et hostet miljø. Andre bør blive i jeres eget runtime-miljø, så I kontrollerer forbindelser, filtrering, godkendelser og netværksgrænser.
Det understøtter også en trinvis udrulning, der giver driftsmæssig mening. Hvis en intern researchagent kun bruger godkendte offentlige kilder, kan en høj grad af autonomi være acceptabel. Hvis en salgssupportagent kan søge i interne filer, berige et lead, opdatere stadiet for en salgsmulighed og udarbejde ekstern kommunikation, er en mere sikker opsætning at begrænse adgangen til værktøjer og placere godkendelsespunkter omkring funktionerne med skriveadgang. Vejledningen om guardrails fastslår udtrykkeligt, at tool-guardrails skal placeres ved de værktøjer, de beskytter. Ved handlinger med konsekvenser er kontrol på værktøjsniveau vigtigere end en generisk kontrol i begyndelsen eller slutningen af samtalen.
Tracing sikrer en ærlig debat om udrulningen
Når et workflow først berører produktionssystemer, er observability ikke længere valgfrit. OpenAI’s vejledning oplyser, at tracing er indbygget i Agents SDK og som standard er aktiveret i det normale serverbaserede flow. Et trace kan registrere modelkald, værktøjskald, overdragelser, guardrails og brugerdefinerede spans. Dokumentationen viser også, hvordan flere kørsler kan samles i ét trace, så et større workflow kan undersøges som én samlet enhed.
Det har kommerciel betydning, fordi de fleste uenigheder om intern AI egentlig ikke handler om modellen. De handler om usikkerhed. Kaldte agenten det forkerte værktøj? Medførte en overdragelse kontekst, som ingen havde forventet? Blev en guardrail aktiveret? Godkendte en menneskelig kontrollant noget tvetydigt? Uden strukturerede traces bliver den slags samtaler hurtigt upræcise. Med traces kan et team undersøge, hvad der faktisk skete, og afgøre, om løsningen skal findes i prompts, værktøjsdesign, godkendelsespolitikken eller applikationskoden.
Sikkerhedskontroller er stadig vigtige ved intern brug
Vejledningen om cybersikkerhedskontroller er en nyttig påmindelse om, at udrulning i produktion kræver eksplicit risikohåndtering ud over promptdesign. OpenAI bemærker, at der gælder yderligere automatiserede sikkerhedsforanstaltninger for API’ets mere avancerede modeller, og at mistænkelig aktivitet kan føre til midlertidige adgangsbegrænsninger med en cyber_policy-fejl. Dokumentationen bemærker også, at individuelle safety identifiers for hver bruger kan begrænse driftsforstyrrelsen, så et problem rammer en bestemt bruger frem for en hel organisation.
Den praktiske konsekvens er ligetil: Agenter i produktion skal kunne håndtere afbrydelser og begrænset drift på en kontrolleret måde. Hvis en modelanmodning blokeres, en gennemgang forsinkes eller et værktøjskald afvises, skal workflowet stadig have en kontrolleret fallback. Måske flyttes opgaven til en kø til menneskelig behandling. Måske udarbejder agenten et udkast uden at indsende det. Måske logger systemet det blokerede trin og beder en medarbejder færdiggøre det manuelt. Det er forskellen på en demo, der ser imponerende ud, og intern automatisering, der kan holde til den daglige drift.
Det bør virksomheder reelt købe
Når man ser bort fra hypen, peger OpenAI’s vejledning på en meget praktisk leverancemodel: Definér workflowet, adskil læsehandlinger fra skrivehandlinger, begræns adgangen til værktøjer mest muligt, tilføj godkendelser, hvor handlinger har konsekvenser, gem run state, så arbejdet kan genoptages uden problemer og revideres senere, aktivér tracing, og gennemfør udrulningen trinvist. Det er sådan, man sparer tid uden at skabe et nyt kontrolproblem. Det er også derfor, projekter med interne agenter bedst sælges som governance af workflows og hjælp til API-integration – ikke som en vag AI-strategi.
Har I brug for hjælp til den slags?
Har I brug for hjælp til at omdanne interne AI-workflows til automatiseringer med indbyggede godkendelser, sporbar run state og kontrolleret adgang til værktøjer? Kontakt Greg.
Kilder
Sidst ændret
2026-08-24