OpenAI lancerede Presence den 22. juli 2026 i en begrænset general availability. Det er et enterpriseprodukt til at få AI‑agenter i drift på tværs af kundevendte og interne processer. Realtids stemme og chat er tilgængeligt i dag, ifølge de officielle udmeldinger. Lovende, ja. Men der mangler stadig svar på pris, geografiske begrænsninger, kontraktvilkår og om Presence kan køre på andre modellag end OpenAIs egne.
Det her er ikke en stor, blå knap til “deploy”. Udrulning ledes af OpenAIs egne Forward Deployed Engineers og udvalgte globale integratorer. Det gør produktet mere enterprise, men også tungere i metode og tidsplan.
Hvad Presence lover nu
OpenAI positionerer Presence som et samlet stillads til produktionsklare agenter: policies, systemforbindelser, evalueringer, guardrails, eskaleringsregler og en opdateringsproces. Pointen er, at agenter kan svare på spørgsmål, få adgang til virksomhedssystemer, udføre godkendte handlinger og eskalere til mennesker efter regler, virksomheden sætter. Det er kernen — ikke pynt.
Eksemplerne er konkrete: afklaring af faktureringsspørgsmål, understøttelse af forsikringskrav eller håndtering af interne IT‑bestillinger. Hver udrulning starter med en afgrænset opgave, defineret adgang og tydelige grænser for, hvad agenten må gøre selv, hvad der kræver godkendelse, og hvornår et menneske tager over.
Tilgængelighed uden selvbetjening
Presence er ude i en begrænset GA. Det betyder, at kunder kan komme i gang, men via en styret model. OpenAIs FDE‑teams og udvalgte systemintegratorer leder arbejdet. VentureBeat skriver, at produktet ikke kan købes som self‑service. Organisatorisk betyder det et projektforløb med planlægning, workshops, test, graderinger og kontrolleret go‑live — ikke en hurtig weekend‑POC.
OpenAI viser også skærmbilleder af simulationer, policyændringer, driftssignaler og intention‑mønstre. Fint, men metrikdefinitioner og kobling til SLA er ikke dokumenteret. Det hul bør ledere adressere, før der loves tal videre i styringskæden.
Teknisk arkitektur og integrationspunkter
Kilderne beskriver Presence som en ramme, der forbinder til eksisterende systemer. I praksis peger det mod ERP\/CRM, ticketing og IAM. Agenter får kun den viden og de rettigheder, der er nødvendige. Kilderne er eksplicitte om, at adgang og handlinger styres stramt af policies og godkendelser.
Konsekvensen for integration er konkret: sikre API‑broer, mindst mulige rettigheder (least privilege) og testmiljøer med repræsentative data uden eksponering af følsomt indhold. Ikke raketforskning — men kræver disciplin.
Governance, sikkerhed og risikostyring
Presence lægger vægt på governance — ikke kun i opstarten, men løbende. Teams kan teste mod standardforespørgsler, kanttilfælde og højrisikoscenarier. Graders vurderer, om agenten nåede målet, fulgte politik, brugte værktøjer korrekt og eskalerede i tide. Guardrails kan stoppe samtaler, der løber ud over rammerne.
Den praktiske bundlinje: uden klare policies og definerede handlinger er der ikke noget enterprise‑produkt her. Det er politikkerne, der bærer tilliden. Ellers er det bare en chat.
Drift og support når agenten er live
Efter go‑live overvåges produktionen. Sessions, eskaleringer og kvalitetssignaler viser, hvor agenten virker, og hvor den fejler. OpenAI beskriver, at Codex kan foreslå opdateringer via et Presence‑plugin. Teams kan så teste ændringer mod den version, der kører, før en kontrolleret udrulning. Det peger på change management med A\/B‑test og rollback, men detaljer om CI\/CD og versionsstyring er ikke beskrevet i kilderne.
For drift betyder det, at bemandingen ikke kun er en chatbot‑redaktør. Der skal være produktionsingeniører, graderingskapacitet og folk, der kan læse mønstre i kundeadfærd. Og en eskaleringskæde, der reelt svarer fredag klokken 16.45 — ellers bliver kvalitetssignaler bare pæne grafer uden handling.
Økonomi og de store spørgsmål
OpenAI har ikke oplyst pris. Der er heller ikke nyt om geografiske begrænsninger, datalokaliseringspolitik eller kontraktvilkår. VentureBeat noterer desuden, at ekstern modelkompatibilitet er uklar. Kan Presence køre med modeller fra andre leverandører? Det er ikke bekræftet.
Uden pris og vilkår er en præcis TCO svær. Den sikre antagelse er, at projektomkostningerne inkluderer både OpenAIs FDE‑tid og integratorarbejde plus interne timer til integration, test og governance. Det er ikke billigt. Om det er dyrt eller rimeligt, kan ikke vurderes endnu. Forretningscasen bør derfor bygges på afgrænsede, målbare piloter — ikke slides.
Markedskontekst og risiko for lock‑in
Presence lander i et marked, hvor enterprise‑agenter leveres af hyperscalere, specialiserede platforme og åbne weights. Styrken ved Presence er den samlede pakke til drift, politik og evaluering i produktion. Svagheden er potentiel lock‑in, hvis ekstern‑modelstøtte mangler. Det er centralt for organisationer med flerleverandørstrategi.
Interoperabilitet er ikke bare et buzzword. Hvis modelvalg, logningsformat eller eval‑værktøjer ikke kan flyttes, bliver udskiftning dyr. Det er en generel enterprise‑risiko, som vokser, når agenten får lov at udføre rigtige handlinger i rigtige systemer.
Tre scenarier der faktisk giver mening
1) Hurtig pilot i kundeservice med menneske‑fallback. Afgrænset til 1‑2 typer henvendelser, tydelig refund‑politik, og alle sager over et vist beløb eskaleres. En forsigtig vurdering: 6‑10 uger fra kickoff til kontrolleret pilot, afhængigt af integration til ordresystem og IAM. Primære risici: datakvalitet, mandatgrænser for handling og at piloten drukner i edge cases.
2) Intern IT‑assist med begrænset handlingsadgang. Agenten må oprette tickets, nulstille adgangskoder via godkendt flow og svare på standardspørgsmål. Estimat: 8‑12 uger, fordi IAM‑koblinger og testmiljøer tager tid. Risici: on‑call‑bemanding til eskalation og utilstrækkelig auditlogning ved revision, hvis logformat og retention ikke er aftalt fra start.
3) Tværgående sagshåndtering på tværs af flere systemer. For eksempel en forsikringssag, der kræver opslag i kundedata, dokumenthåndtering og udbetalingsflow. Estimat: 12‑20 uger, fordi der er flere integrationer, stærkere guardrails og flere godkendelsestrin. Risici: uklar ansvarsfordeling mellem leverandører og ændringshastighed i policies, som kræver hyppige gen‑evals. Her bliver governance afgørende.
Hvad ledere kan gøre nu
Man behøver ikke kende prisen for at starte forarbejdet. Det vigtige er at skære klart i roller, data og adgang.
- Kravspecifikation: Definér en snæver use case med mål for succes. Fx ventetid reduceret med X sekunder eller Y procent færre eskalationer.
- Governance‑workshop: Sæt handlinger, godkendelser og eskaleringsregler. Hvad må agenten gøre selv, og hvornår skal et menneske ind?
- Data og adgang: Kortlæg systemer, API’er, testdata og IAM‑rettigheder. Minimér adgang fra dag ét.
- Proof‑of‑value: Kør en kontrolleret pilot med stram målstyring og reel rollback‑mulighed.
- Exit‑ og lock‑in‑afklaring: Afklar krav til model‑fleksibilitet, log‑eksport og dataportabilitet før kontrakt.
Kilder og faktatjek
Bekræftet via OpenAIs officielle udmelding og VentureBeat: at Presence er lanceret som et enterpriseprodukt til udrulning og styring af agenter; at fokus er både kundevendt og internt; at det er tilgængeligt nu i en begrænset GA; at udrulning ledes af OpenAI FDE’er og udvalgte systemintegratorer; at realtids stemme og chat er tilgængeligt i dag; og at Presence pakker policies, systemforbindelser, evalueringer, guardrails og opdateringsprocesser.
Åbne spørgsmål, som kilderne ikke besvarer: pris og licensmodel; geografiske begrænsninger og datalokaliseringspolitik; kontraktlige vilkår og SLA‑struktur; ekstern‑modelstøtte; detaljer om API\/SDK, CI\/CD og udviklerværktøjer; konkrete referencecases med målbare effekter.
Hvorfor det betyder noget
Presence kan forkorte vejen fra demo til drift ved at samle de kedelige, nødvendige ting: politikker, tests og opdateringsrutiner. Og ved at stille folk til rådighed, der har gjort det før. Det har værdi i store organisationer, hvor misforståelser bliver dyre.
Gevinsten afhænger dog af governance, integration og pris. Tre ben. Falder et af dem, vælter taburetten. Begynd med en kravworkshop, og mål på noget, der kan tælles. Resten falder først på plads, når man arbejder med det i praksis.
