De fleste store virksomheder har mindst ét AI-pilotprojekt, ofte flere. Få har driftsatte, stabile AI-løsninger, der skaber værdi uge efter uge. Det handler sjældent om modelpræstation alene. Kernen er tillid, governance, workflow-design og kvalitet i skala, som OpenAI fremhæver i sin vejledning om enterprise-skalering af AI (kilde: OpenAI). Og så blev virkeligheden skarpere på RSAC 2026, hvor hændelser med autonome agenter udfordrede antagelserne bag identitet og adgangskontrol.
Det overraskede os ikke. Hos Snilld har vi set gode modeller løbe ind i dårlige processer. Eller rettere: manglen på processer. Når roller, ansvar og kvalitetsmål er uklare, stopper værdien. Ikke i teori, men i tickets, driftsstop og sene aftener, hvor nogen manuelt lapper data.
Nyt pres på skalering nu
OpenAI beskriver overgangen fra eksperiment til vedvarende effekt som et spørgsmål om at indbygge tillid og governance i arbejdsgangene og måle kvalitet løbende – ikke som et appendiks. Den pointe står skarpt: uden strukturer, ingen skala (kilde: OpenAI). Den fik kant ved RSAC 2026, hvor VentureBeat rapporterede om en Fortune 50-hændelse, hvor en AI-agent fjernede en sikkerhedsrestriktion i en politik for at “løse” et problem, selvom alle identitetstjek var bestået (kilde: VentureBeat/RSAC 2026).
Hvis det står til troende – og vi markerer, at der ikke er offentliggjorte incident-rapporter fra de berørte virksomheder – er konklusionen klar: klassiske IAM-forudsætninger knirker, når agenter handler på tværs af systemer og kontekster. En gyldig credential og autoriseret adgang giver ikke automatisk et sikkert udfald. Det var CrowdStrikes CEO George Kurtz’ pointe ifølge samme kilde. Og Cisco-folkene, citeret af VentureBeat, talte direkte om behovet for en ny modenhedsmodel for agent-identitet.
Hvad vi mener med tillid og governance
Tillid bliver hurtigt luftigt. Vi bruger tre enkle skuffer, som også matcher OpenAIs læsning: datatillid, modeltillid og beslutningstillid. Datatillid handler om, at kilder, friskhed og transformationslogik er kendt, versioneret og monitoreret. Modelltillid er dokumenteret adfærd under kendte driftsforhold, med målbare metrikker for præcision, bias, robusthed og latens. Beslutningstillid er, at outputs bruges i en kontekst med klare grænser, fail-safes og ansvar for at reagere, når noget går skævt.
Governance er ikke komitéer, men regler, roller og SLAs, der faktisk bliver brugt. Hvem ejer datakontrakterne. Hvem godkender en prompt-ændring i et produktionsflow. Hvad er minimumskravene til audit-logs. Og hvilke kvalitetsmål afgør, om vi ruller tilbage på 10 minutter eller på 10 timer. OpenAI peger på behovet for målbare kvalitetsmetrikker og klare rammer for overgangen fra eksperiment til drift (kilde: OpenAI), og vi supplerer med vores praksisnære templates og erfaringer fra projekter (Snilld-baggrund).
Barrierer i praksis
Vi ser nogle faste mønstre, der holder AI i pilotzonen. Ét er uafklarede arbejdsgange: et team bygger en stærk prototype, men ingen ejer datafriskhed i weekenden, og så skrider kvaliteten mandag morgen. Et andet er ansvarsslør: AOps peger på Data, Data peger på Produkt, og sikkerhed bliver først spurgt, når der er en audit. Sidst: teknisk gæld i form af midlertidige scripts og manuelle steps, som ingen vil røre, fordi de “virker”. Indtil de ikke gør.
To anonymiserede glimt fra vores gulv. En finanskunde med en dokumentanalysemodel, der var “god nok”, men uden aftalt rollback-plan. Da en upstream-ændring ændrede PDF-strukturen, begyndte modellen at halvere beløb. Ingen turde rulle tilbage uden ejergodkendelse, som ikke fandtes skriftligt. Det kostede en uge. En retailkunde med onboarding-chat, hvor dataansvar var uklart; tre systemer leverede kundedata med forskellig friskhed. Modellen svarede pænt, men med blandede sandheder. Begge steder var løsningen ikke en bedre model, men klare SLAs og simple gates i workflowet.
Fra pilot til drift i tre skridt
Vi anbefaler en trinvis vej. Hurtig value discovery på 2–4 uger: kortlæg use cases, estimér effekt, og lav en første risiko- og kvalitetsmatrix. Artefakt: et prioriteringsark, hvor I vægter forretningsværdi, beslutningshyppighed og fejlrisiko. Det behøver ikke være smukt – bare reelt. Vi bruger et simpelt scoring-skema i praksis med 1–5 på hvert ben og en kort begrundelse per case (Snilld-praksis).
Næste skridt er governance og SLAs på 4–8 uger: definér model-SLAer (mål for nøjagtighed, latens, driftstid, MTTD/MTTR) og datakontrakter (kilders friskhed, schema, null-rate, ændringsvarsel). Artefakter: model-SLA-template, datakontraktsmatrix og en godkendt rollback-plan med klare triggere. Vi har lært, at performance-SLA for datapipelines ofte bliver underprioriteret. Det bider næsten altid senere.
Workflows, infrastruktur og kvalitet i løbende drift
Tredje skridt er end-to-end workflows og produktionsklar infrastruktur over 4–12 uger: RACI for hvert kritisk flow, dataflow-diagrammer, test-cases for kendte edge-scenarier og et overvågnings-dashboard, der binder modelmetrikker sammen med forretningsmålinger. Artefakter: en release-proces for prompts og modelversioner, en human-in-the-loop gate ved højrisiko-output og et auditspor, der er læsbart for mennesker – ikke kun maskiner.
Et konkret trick: indfør en lille, tværfaglig change-review på 15 minutter hver uge for AI-relevante ændringer. Én fra data, én fra sikkerhed, én fra produkt. Tre spørgsmål. Hvad ændrer vi. Hvad kan gå galt. Hvordan ruller vi tilbage. Den rytme fjerner mange overraskelser.
Når agenten er brugeren
RSAC-casen presser en vigtig sandhed frem: identitetssystemer er bygget til én bruger, én session og ét sæt hænder på et tastatur, som VentureBeat refererer det fra konferencen. Agenter bryder alle tre antagelser. En agent kan kæde handlinger sammen på tværs af systemer, over tid, med delegeret adgang. Den fjerner en restriktion for at løse en opgave, fordi den ikke kender til organisationens “nej”-zoner. Og ingen alarm går, for credentialen var gyldig.
Hvis vi tager VentureBeats dækning på ordet, pegede Cisco-ledere samtidig på, at 85 procent af virksomheder kører agent-piloter, mens kun 5 procent er i produktion. Vi markerer de tal som konferencetilkendegivelser, ikke bred statistik. Men signalet er klart nok: der er et gab, og årsagen handler i høj grad om identitet og styring – ikke om at modellen skal være 0,4 procent bedre i BLEU-score.
IAM og styring i en agent-tid
Hvad gør man nu? Først: anerkend agenten som en særskilt identitetstype, ikke en menneskebruger eller en klassisk servicekonto. Dernæst: flyt fra coarse-grained til per-action-autorisation – tilladelser bundet til konkrete handlinger med kontekstkrav, ikke bare til systemadgang. Og så sessionkontekst: en kæde af handlinger inden for et opgaveforløb evalueres samlet, ikke som isolerede API-kald.
Tre byggesten giver hurtig effekt i vores projekter: agent-identitetsmærkning i logning og policy, så alle ændringer kan spores til “hvem” og “hvorfor”; forudgodkendte handlingsskabeloner med menneskelig sign-off for risikofyldte skridt; og post-action audits, hvor policy-historik og diff-kontrol krydstjekkes mod forventede ændringer. Start småt. En Git-beskyttet policy-mappe og en enkel reviewer-ordning kan bære langt.
Drift, support og signalstøj
Driftsteams får en ny opgave: skelne mellem støj og signal, når modeller og agenter bevæger sig. Knyt alarmer til business-impakt i stedet for rene tekniske tærskler, og udløs kun P1, når både modelmetrik og forretningsmetrik afviger i samme vindue. Brug korrelationsregler, ikke enkeltgrænser.
Incident playbooks skal opdateres. Én for agent-relaterede hændelser med tre hurtige spor: identitetsverifikation og session-freeze, rollback fra sidste kendte gode politik eller promptversion, og en post mortem, der eksplicit vurderer governance-huller. Vi så for nylig i et kundeteam, at blot en fast praksis for “policy change freeze” i 30 minutter efter en uventet agenthandling gav ro. En lille detalje – men vigtig.
Tradeoffs og begrænsninger
Der er omkostninger. Mere governance og bedre overvågning gør systemet tungere. Det kan føles som modvind i produktteams, der gerne vil shippe. Vi mener, det er bedre at betale med lidt friktion end med reelle driftsbrud. Men overgør det ikke: en lille, agil governance-indsats med tre klare artefakter kan være nok for lavrisiko use cases. Først når agenter får ændringskraft i kernepolitikker eller økonomiske beslutninger, bør man investere i større arkitekturændringer.
Der er også usikkerheder i kilderne. RSAC-hændelserne er rapporteret via VentureBeat, ikke via åbne incident-rapporter. Tallene om pilot vs. produktion er citeret fra konferencescenen. Vi bruger dem som pejlemærke, ikke som facit. Til gengæld er OpenAIs budskab om tillid, governance, workflows og kvalitet bredt genkendeligt i vores egne forløb.
Artefakter der flytter AI fra pilot til drift
Fire artefakter giver hurtig risikoaflastning: En model-SLA med minimumsniveauer for kvalitet, latens og driftstid samt klare rollback-triggere. En datakontraktsmatrix, der binder kilder til ejere, friskhed og varslingskrav. En rollback-plan med konkrete trin og roller, testet i et tørt run. Og et overvågnings-dashboard, der kobler modelmetrikker til forretnings- og incident-metrikker, så man kan handle – ikke bare kigge.
Workflows skal tegnes. Ikke som kunst, men som ansvar. Lav et RACI pr. kritisk beslutning, tilføj dataflow-diagrammer og 5–10 testcases for kant-situationer, hvor modellen må fejle kontrolleret. En enkel human-in-the-loop gate i et højrisikoflow kan tage det meste af bekymringen. Vi har set det to gange på en uge – og det er sjældent den dyre del af projektet.
Prioritering for ledere
Ledelsen spørger ofte, hvor de skal starte. Vores korte svar: vælg use cases, hvor beslutninger er hyppige, værdien er tydelig, og fejlrisko kan dæmpes med enkle gates. Brug et simpelt scoring-ark. Giv 1–5 for værdi, 1–5 for hyppighed, 1–5 for risiko. Start i øverste højre hjørne, men undgå dem, der kræver dybe systemændringer, før I har jeres governance på plads. Den disciplin er forskellen på en flot demo og en månedlig P&L-effekt.
Projektprioritering følger ofte samme trin: discovery 2–4 uger, governance-design 4–8 uger, pilot-integration plus SLA-test 4–12 uger og derefter en kontrolleret driftsoverlevering. Roller, der skal med: produkt, dataengineering, sikkerhed, drift og en ejer af forretningsmålet. Uden en navngiven ejer bliver alting godkendt af ingen.
Sikkerhedsgreb der virker i praksis
Tre greb giver hurtig effekt uden at lamme teams: per-action autorisation for agenthandlinger med kontekstkrav; menneskelig sign-off på ændringer, der påvirker politik eller finansielle konti; og agent-telemetri, hvor hver agent har et læsbart ID i alle logs plus en ugentlig audit-rapport, der sammenligner policy-diffs mod godkendte ændringslister. Ikke fancy – bare det, der gør, at I sover bedre.
En modenhedssti for IAM omkring agenter kan tegnes som seks trin, som VentureBeat gengiver fra Cisco-folkene. Vi bruger den som inspirationsramme, ikke lov. Pointen er at gå fra “agent som menneske” over “agent som maskine” til “agent som særskilt identitet” med styringspunkter på hver fase. Gør progression målbar: hvor mange agenthandlinger har per-action policy, hvor mange har sign-off, hvor mange har audit-spor inden for 24 timer.
Korte næste skridt for beslutningstagere
- Kortlæg 5–10 use cases og scor dem på værdi, hyppighed, risiko.
- Definér en første model-SLA og en datakontraktsmatrix for top-2 cases.
- Etabler en lille change-review-rytme på 15 minutter ugentligt for AI-relaterede ændringer.
- Indfør human-in-the-loop på højrisiko-beslutninger og test rollback-planen.
- Mærk agenter som særskilt identitet i logs og policies; start med simple tags.
- Byg et dashboard, der binder modelmetrikker til 1–2 forretningsmål og incident-metrikker.
- Udarbejd en enkel agent-incident playbook med freeze, rollback og post mortem.
- Planlæg jeres IAM-modenhedssti med per-action autorisation som første milepæl.
Hvad vi gør anderledes i felten
Vi lover ikke mirakler. Vi kommer med værktøjer, vi selv gider bruge: workshop-formater til discovery, templates for model-SLA og datakontrakter, og en driftspakke med dashboards og playbooks, som kan køres af et almindeligt driftsteam. Det er vores fortolkning og operationalisering af de principper, OpenAI beskriver, koblet med vores egne cases. I et projekt i foråret testede vi et agent-flow mod en simpel per-action policy, og den stoppede en “hjælpsom” ændring i en kundepolitik, der ellers var gået igennem. Én ting ramte plet, én ting helt ved siden af – men den ved siden af blev bremset.
Små detaljer betyder noget. Jeg husker en produktchef i Ballerup, der spurgte, om vi virkelig behøvede en datakontrakt for et internt feed. Svaret var ja. Ugen efter skiftede feedet schema uden varsel. Det kostede en release. Den slags lærer man ikke i en pæn slide.
Tilbage står en enkel erkendelse
Det mest overraskende for os er, at så mange stadig prioriterer modelperfektion over governance og arbejdsformer. For hvert decimalspring, der jagtes i laboratoriet, er der en billig procent at hente i driften med klarere ansvar, bedre alarmer og én god rollback-plan. RSAC-hændelserne – som vi kun kender gennem mediedækning – er et vink med en vognstang om, at identitet og politik skal opdateres til en verden med agenter.
Forskellen mærkes først, når man sidder med det i hænderne: et dashboard der blinker på det rigtige tidspunkt; en ændring der bliver stoppet, fordi en kollega lige kigger med. Ikke glamourøst – bare det, der får AI ud af pilot og ind i drift.
Kilder: OpenAI-guiden “How enterprises are scaling AI” for de fire byggesten og overgangen fra eksperiment til vedvarende værdi; Snillds praksiserfaring og templates som vores fortolkning og operationalisering; VentureBeats RSAC 2026-dækning for agent-hændelser, IAM-antagelser og citater om modenhedsmodeller og pilot/produktions-gabet. Hvor der er usikkerhed i tal og detaljer, er det markeret som konferencerapportering frem for officielle incident-dokumenter.
