De fleste større virksomheder har i dag et pænt AI-governance slide. Et org-diagram, et udvalg, en principliste. VentureBeat Pulse Research kalder det en Governance Mirage, og tallene fra maj 2026 forklarer hvorfor. 43 procent svarer, at et centralt team ejer governance. 23 procent kan ikke engang blive enige om ejerskabet. Og 31 procent peger på leverandør-opacitet som den største forhindring. Det lyder bekendt. Vi har set det igen og igen hos kunder – og ja, vi har selv taget et par af de samme antagelser for gode varer.
Det overraskende er ikke tallene. Det er hvor bruddet sker. Ifølge VentureBeat er det ikke modellen, der knækker. Det er runtime: infrastruktur og drift. Når agenter flytter fra demo til virkelighed, er det container-restarts, state management og uforudsigelige omkostninger, der vælter læsset – ikke prompts, ikke endnu en frontier-model. Den diagnose rammer rigtigt – og uprætentiøst praktisk.
Hvad VentureBeat fandt
VentureBeats Pulse Research interviewede 132 verificerede teknologiledere i maj 2026 på tværs af organisationer med 100+ ansatte. En fokuseret, men solid kohorte: direktører for AI\/Analytics og Engineering, VP’er, CIO\/CTO\/CISO-profiler og arkitekter. Dominans fra teknologi og finans, men bredde nok til at kalde fundene robuste. Der findes ikke en særskilt nordisk nedbrydning, så direkte danske tal mangler – det skal stå åbent.
Hovedpointen er klar i rapporten: Det primære fejlpunkt i enterprise-agentprojekter er runtime, ikke modellen. Respondenterne beskriver stateless opsætninger, ad hoc-kæder i Python eller LangChain og skrøbelig orkestrering, der dør ved mødet med produktion. Container-restarts fjerner kontekst. Token-forbrug vælter business casen. Hallucinationer i et tidligt step kan forplante sig til deciderede systemfejl senere i flowet. Og ingeniørteams bruger for meget tid på rørføringen i stedet for at bygge intelligensen. Det matcher 1:1, hvad vi hører i maskinrummet.
Fra diagram til drift: Hvor runtime knækker sammen
Det er her kæden hopper af. Ikke på governance-dokumentet, men i gearkassen. Vi så for nylig en pilot, hvor en multi-step agent fungerede fejlfrit i staging. I produktion begyndte pods at genstarte ved spidsbelastning. Hver genstart nulstillede agentens kontekst, fordi state lå kun i process-hukommelsen. Brugeren oplevede, at agenten glemte aftaler indtastet to minutter før. Det tog en uge at opdage mønstret, fordi loggerne ikke kædede session og state på tværs af restarts. Ikke kønt – men lærerigt.
Andre klassikere: Token-økonomien. I test kører man med små dokumenter og lav belastning. I virkeligheden eksploderer prompt-længder, chunking bliver overivrig, og tool-calls duplikerer input. Uden overblik over cost-per-transaction per step drifter forbruget. Pludseligt bliver en ellers fin NPV til et sort hul i budgettet. Det er ikke ondt. Det er bare fysikken i systemet, når alt er dynamisk.
Konsekvenser i praksis
Konsekvens ét: Time-to-market glider. Når driften ikke er bygget til at bære agenters state, ender produktteamet i et Sisifos-loop med hotfixes, feature-freezes og midlertidige bypasses. Der går måneder med at “stabilisere”, mens værdien venter på parkeringspladsen. VentureBeat beskriver præcis den skred-bane. Vi genkender den.
Konsekvens to: Skjulte driftsomkostninger. Når der mangler automatiseret kvalitetssikring og observability, ryger alt over i manuelle reviews. Vi har set en kundes manuelle review-kø tredobles, da agenten begyndte at miste kontekst efter container-genstart. Et simpelt metrik-sæt – success-rate per step, cost per session, MTTR ved context loss – ville have fanget det tidligere. Vi hjalp med at identificere fejlen og indføre state-lagring og alarmering; MTTR faldt markant bagefter. Ikke et mirakel – bare basal drift.
Konsekvens tre: Compliance og revision. Uden audit-logs, model-versionering og datalinjer bliver dokumentationskravene tunge. Vi har siddet til intern audit og forsøgt at rekonstruere, hvorfor en agent traf en beslutning tirsdag klokken 14.17. Når hver request er et lille eksperiment, og intet bindes sammen, bliver sandheden efterrationaliseret. Det går ikke i 2026 – slet ikke med kommende AI-krav hos tilsyn.
Hvad virksomheder typisk gør forkert
Første fejltrin: Jagt på bedre modeller. Selvfølgelig betyder modelkvalitet noget, men for mange bliver modelvalg en overspringshandling. Man bytter hjernen, mens ryggraden er skæv – resultatet holder kun kort.
Andet: Ad hoc-orkestrering i Python eller med løse kæder. Det ser hurtigt ud på GitHub, men skalerer dårligt uden stærkt state management, retries med idempotens, kontrakt-tests og backpressure. Tredje: Outsourcing af ansvaret. “Platform-teamet fikser det.” Nej. Uden en klar runtime-ejer for det konkrete produkt ender man med en supportlinje, der ikke ejer risikoen – og så taber man timer hver uge i uklarhed.
Snillds anbefaling: Operations-drevet governance
Drop flere slides. Udpeg én model- og runtime-ejer per use case med mandat, plus en central governance-funktion til regler, tooling og audits. Ejerskab løser ikke alt, men det forkorter vejen til handling. Når nogen har nøglen til produktions-dashboards og kan trykke stop, falder pulsen i organisationen.
Derudover governance-as-code – som konkrete tests og kontroller: kontrakt-tests på tools, schema-checks og PII-guards i pipelines, canary-deploys for modelversioner, automatiserede rollback-planer samt observability, der binder session, state og omkostning sammen. Det reducerer tre risici på én gang: driftsnedbrud, cost-drift og audit-gab. Ja, det ligner DevOps 101. Præcis.
Implementeringsvej: Hvad koster det, og hvad kræver det
Hold stacken nøgtern: Et orkestreringslag, der kan håndtere state eksternt (database eller dedikeret state store), en kø til idempotente job, feature-flagging til model- og prompt-versioner og et observability-setup, der korrelerer metrics, logs og traces. Brug service-kontoer og klare scopes til tools. Og vigtigst: bind cost-metrics til forretningsmål – ikke kun til pods.
Metrikker der virker: Success-rate pr. step og samlet; 95p latens per tool-call; cost per transaktion og per vellykket output; context-loss-incidens; hallucination-eskaleringer; MTTR for genopretning. Roller: En runtime lead per use case, en SRE\/infra-ansvarlig, en produktleder med cost- og kvalitetsansvar og en data\/compliance-rolle, der ejer audit-krav. Tæt bemanding i starten, men en lille kerne kan bære en pilot, hvis opsætningen er rigtig.
Tradeoff’en er enkel: Lidt mere arbejde up front, markant mindre driftskaos senere. I vores projekter har en 4–6 ugers pilot med governance-as-code og observability typisk reduceret efterfølgende manuel review-tid i produktion betydeligt. Vi angiver ikke generelle procenter – offentlige tal mangler – men mønsteret går igen. Omkostningen er forudsigelig udviklingstid; gevinsten er forudsigelig drift.
Integrationer er den virkelige møntfod. Jo flere tools en agent styrer, desto vigtigere bliver kontrakter. Vores regel er kedelig og effektiv: Alle tools har en skriftlig kontrakt med pre- og postbetingelser, schema valideres maskinelt, og fejl-håndtering er idempotent. Det alene fjerner en stor del af fantomfejlene.
Leverandørlandskabet og offentlig information
31 procent af VentureBeats respondenter peger på leverandør-opacitet som den største barriere. Det mærkes som uforudsigelige priser, uklare rate-limits og svingende release-rytmer. Markedet kan være på vej mod større modenhed: Dækningen af Anthropics planlagte IPO peger på mere enterprise-venlig adfærd med tydeligere prisrammer og releases. Et signal – ikke en garanti – men relevant for procurement-planlægning.
Usikkerheden er tidshorisonten. En børsnotering ændrer ikke fra dag ét teknisk support eller SLA-kultur. Og vi mangler stadig offentlige, konsistente sammenligninger på tværs af udbydere om fx pinned versions, reproducerbarhed og lange supportvinduer. Indtil de findes, må runtime-design antage variation – og bygges til at tåle den.
Hvad kan gå galt: Modargumenter og usikkerheder
Der er cases, hvor modellen er flaskehalsen: kompleks specialistviden, regulatoriske edge cases eller behov for at følge stramme handlingsregler i lange kæder. Her kan bedre modelvalg og skarpere instruktioner være afgørende. VentureBeats data favner bredt, men dækker ikke alle sektorer eller størrelser – og vi mangler sektoropdelte data for Norden. Hvor ofte fejler Day Two i danske virksomheder? Hvor tit ser vi token-overløb i finans versus detail? Ingen solide, offentlige tal endnu. Indtil da må vi læne os op ad VentureBeat, egne erfaringer og nøgtern log-læsning.
Anbefalet redaktionel vinkel og call-to-action for læsere
Tre jordnære skridt denne uge: 1) Udpeg en runtime-ejer for jeres vigtigste agent-case. Med navn. 2) Mål tre ting i produktion eller pre-prod: success-rate per step, cost per transaktion og MTTR ved context loss. 3) Sæt én automatisk kontrakt-test på det mest brugte tool. Det er ikke perfekt, men det flytter jer fra slide til styring.
Vi har en kort, gratis governance-readiness tjekliste, vi bruger internt som startpunkt. Den er kedelig og effektiv. Ingen raketvidenskab – bare de spørgsmål, der hjælper jer med at se hullerne, før brugerne gør det. Spørg os ikke om flere slides; bed hellere om et log-udtræk. Sandheden står der.
Afslutning
VentureBeats data rammer rigtigt: Det er runtime, der gør mest ondt lige nu. Ikke fordi modeller er ligegyldige, men fordi driftens fysik altid vinder til sidst. Og ja, flotte governance-diagrammer giver en kortvarig ro – indtil den første container dør, og ingen kan forklare, hvorfor agenten glemte trin fire. Forskellen mærkes først, når man sidder med det i hænderne. Og når pageren hyler klokken 02.11.
