Lad os være ærlige. AI bliver først virkelig farligt for en virksomheds marginer, når den får lov at gøre ting i produktionssystemer. Det er her SAP – ret nøgternt – lægger presset: Governance er ikke pynt eller en compliance-afkrydsning. Det er profitbeskyttelse. SAP formulerer det skarpt: Man skal erstatte statistiske gæt med deterministisk kontrol, ellers æder fejl og ekstra driftsomkostningerne op (kilde).
Den vinkel lyder tør, men den rammer praksis. Når agenter får adgang til ordrer, leverandører og likviditetsprognoser, er “næsten rigtigt” ikke godt nok. Vores erfaring er den samme. To forskellige kunder, to forskellige brancher, samme mønster: uden styring begynder små fejl at forplante sig i pipeline og lager – og så står vi et kvartal senere med en CFO, der kigger på dækningsbidraget og spørger: hvor sivede det ud?
Fra 90 til 100 er ikke et nydeligt mellemrum
SAPs Manos Raptopoulos sætter ord på det, mange ledere mærker i maven: Afstanden mellem 90 og 100 procents nøjagtighed er ikke lineær. “The distance between 90% and 100% accuracy is not incremental. In our world, it is existential,” siger han i interviewet (kilde). Det er ikke retorik. Det er hverdagsøkonomi.
SAPs eget eksempel er banalt og derfor godt: Bed en bred forbrugermodel tælle ord i et dokument, og den kan ramme ved siden af med cirka 10 procent. Ikke altid, men ofte nok til at være en risiko (kilde). Hvis en model ikke kan klare en deterministisk opgave stabilt, hvorfor skulle vi så lade den vælge leveringsrute eller rabattrappe uden sikkerhedsnet?
Hvad betyder deterministisk kontrol i en virksomhed
Ordlyden kan lyde teoretisk, men bliver jordnær, når man zoomer ind. Deterministisk kontrol i enterprise-sammenhæng handler om arkitektur: input-filtre, valideringslag, stramme regler for hvor mange gange en agent må iterere i sin “tænke-løkke”, faste audit trails og styring af agenters livscyklus. SAP rammer alle disse elementer i deres ramme for enterprise governance (kilde).
Vi oversætter det typisk til fire lag hos kunder: 1) Data- og policy-gates før prompten overhovedet bygges. 2) Validering af output mod regler og referencekilder. 3) Orkestrering, der kan afbryde eller rulle tilbage. 4) Overvågning og revisionsspor, der kan bruges uden at man skal grave i logfiler en søndag aften. Det er ikke elegant. Men det virker.
Tradeoffs der rammer P&L med det samme
Der er en pris for kontrol. SAP advarer direkte: Når man begrænser agents inference-løkker for at forhindre hallucinationer – særligt på økonomiske eller forsyningskritiske processer – stiger latenstid og compute-forbrug. Det ændrer P&L-billedet, fordi token- og forespørgselsomkostninger hurtigt løber op ved hyppige, deterministiske opslag (kilde).
SAP sætter ikke konkrete tal på ekstra millisekunder eller kroner pr. forespørgsel. Det gør vi heller ikke her – variationen på tværs af modeller og clouds er for stor. Retningen er til gengæld klar. Mere validering betyder mere latency. Flere verificerende opslag betyder højere hyperscaler-regning. I et par projekter har vi set driftsestimatet stige markant, når vi flyttede fra “hurtig demo” til “skudsikker drift”. Ikke en fejl. En omkostning ved at sove roligt.
Dataarkitekturen skurrer mod vektorer
SAP siger det skarpt: Integration af moderne vektordatabaser med legacy relationelle systemer kræver enorme mængder ingeniørkapital (kilde). Vi er ikke uenige. Især når semantik skal kobles til transaktionel sandhed. Forbindelseslaget – hvor en semantisk embedding skal mappes til eksempelvis en ordrelinje i et ERP – er sjældent plug-and-play.
Praktiske blokeringer vi ser: 1) Mismatch i konsistenskrav. 2) Manglende idempotens i agent-udførsel. 3) Sikkerhedspolicies der ikke kender konceptet “semantisk naboskab”. Og så er der overvågning: Hvem fanger driften, når recall i vektorsøgning langsomt skrider pga. data-drift? Vi har set projekter, der starter som tre måneders PoC og ender som 12+ måneders modernisering. Ikke fordi nogen har dummet sig, men fordi afhængighederne først dukker op, når man kobler det til den rigtige finanspost eller den gamle lagerrobot, der siger bip på tredje hylde i Taastrup.
Agenter formerer sig hurtigere end skygge-it
SAP advarer om agent-sprawl og sammenligner med skygge-it – bare med større risiko, fordi agenter kan planlægge, ræsonnere, koordinere og udføre workflows, ofte direkte på følsomme data (kilde). Vi er enige. Den første agent er sjov. Den tiende larmer. Den tredivte skaber rod i change management.
Det kræver styring som for mennesker: Hvem ejer agenten, hvor meget autonomi har den, hvilke politikker håndhæves maskinelt, og hvordan måles performance løbende? SAP kalder eksplicit på agent-lifecycle management, autonomy boundaries, policy enforcement og kontinuerlig performance-overvågning. Det er ikke et slide, det er drift.
Workflows var lavet til mennesker, ikke maskiner
VentureBeat peger på en anden kilde til fejl: Ikke at modellerne ikke kan tænke – men at de underliggende workflows aldrig var bygget til agenter. Handoffs bryder, skjulte antagelser vælter, og så bliver fejl dyre (kilde). Derfor ser vi nye kontrolplaner – “workflow execution control planes” – som prøver at gøre processer deterministiske nok til maskiner.
Salesforce har fx lanceret Agentforce Operations, der oversætter back-office workflows til opgavesæt for specialiserede agenter. Ideen er at bryde processen op og styre udførsel og overdragelser tættere, så agenter ikke løber løbsk i det implicitte (kilde). Det matcher SAPs governance-pointe – uden styringslaget kan agenter hæve omkostningerne i stedet for at løse dem.
Snilld i felten hvor det knager
Vi testede for nylig en ekstraktionspipeline hos en nordisk retailer. Simpelt? Tag pris og enhed ud af leverandør-PDF’er. Første uger lå fejlmargenen omkring ti procent på de PDF’er med små tabeller i sidefoden. Ikke katastrofalt, men nok til at forskyde disponering. Vi lagde valideringslag på: regex-guardrails, referenceopslag i masterdata og afbrudte inference-løkker efter tre forsøg. Fejlraten faldt, latenstid steg, og økonomichefen accepterede byttet.
En anden case – global producent med mange fabrikker – hvor en agent skulle foreslå vedligeholdelsesvinduer. Uden audit trail og klare eskalationstriggere valgte agenten tider, der så smarte ud på papiret, men kolliderede med compliance-kalendere. Vi endte med en governance-kontrakt: hvad må agenten ændre, hvornår skal mennesket sige stop, og hvem får opkaldet, hvis to målepunkter peger hver sin vej. Det var i øvrigt i den bygning, hvor kantinen altid lugter lidt af kanel torsdag formiddag. Sidespor, ja, men man husker det.
Regnestykket der afgør om det giver mening
Hvordan vejer man øget latency og token-omkostning op mod færre fejl? Her er en enkel måde uden pynt: Antag at en 10 procents fejlmargin i ekstraktion påvirker disponering på varer for 50 millioner kroner pr. kvartal. Hvis blot en femtedel af fejlene fører til tabt salg eller overstock, er effekten 1 procent af volumen – 0,5 millioner kroner. Hvis governance-tiltag hæver driftsomkostningen med, lad os sige, nogle hundrede tusinde per kvartal, men reducerer fejlraten til 2 procent, er forskellen hurtigt positiv. Tallene varierer, men rammen holder. Vi har set den udregning ligge på C-level-bordet, med blyant og små rystede tal.
Man skal dog være varsom: SAP giver ikke præcise cost-multiplikatorer for stramme inference-loops, og VentureBeat leverer ikke benchmarks for kontrolplaners effekt. Det er en rapporteret retning, ikke en fast takst. Derfor bør hvert program måle før/efter med klare KPI’er i stedet for at arve et gennemsnit fra en anden organisation.
Ting der går galt uden at blinke
Tre klassiske faldgruber, som vi desværre genkender: 1) Uklart ejerskab. Juridisk, drift og forretning trækker hver sin retning, og agenten lander i et tomrum. 2) Manglende rollback-scenarier. Systemet kan ikke rulle sig selv tilbage, når en beslutning viser sig forkert. 3) Overfladiske tests. Man tester prompts, men ikke end-to-end med rigtige integrationer, så det først knækker, når det kører om natten.
Botemidlerne er ikke smarte, bare nødvendige: governance-workshops med beslutningsmatricer, testsuiter der inkluderer chaos-tests for agenter, og ingeniørestimater for vektor-relations-integration lagt ind i roadmap fra dag ét. Det tager tid. Og ja, det koster ingeniørkapital.
Bestyrelsens tre spørgsmål før go-live
SAP foreslår tre basale afklaringer, før agenter får lov at træde ind i kritiske processer: Hvem er ansvarlig, når en agent begår en fejl; hvordan gemmes revisionsspor for maskinbeslutninger; og hvilke præcise tærskler udløser menneskelig eskalation (kilde)? Vi er helt på linje. Læg dem ind i styringsdokumenterne. Skriv navne på.
Hvis man vil være lidt kantet: Hvis ingen tør skrive deres navn ud for en agent, hører den ikke hjemme i produktion. Så enkelt er det faktisk. Og det var det afsnit, hvor jeg var ved at polere en pænere sætning – men nej, vi har set for meget rod, når ansvar bliver en gruppearbejde-øvelse.
Taktik der virker uden at sluge hele organisationen
Start der, hvor deterministisk kontrol er ufravigelig: økonomi, prisfastsættelse, rabatter, supply chain. Brug enklere probabilistiske outputs i kundevendte teksthjælpere eller idéudforskning. Indfør hurtige tiltag: 1) Output-validering mod referencekilder. 2) Maks-grænse for agenters iterationsdybde. 3) Metrikker som hallucination-rate og tid til menneskelig eskalation, målt pr. proces.
Planlæg kapacitet og omkostning tidligt. Vektor-relations-integration kan trække 3–6 måneder i en “typisk” backend-kontrakt, ofte mere i komplekse ERP-miljøer. Vi har set udsving fra tre måneders PoC til over et år for fuld produktionsintegration, afhængigt af legacy og datakvalitet. Det spænd er ikke en undskyldning for at vente. Det er et signal om at budgettere realistisk.
Modargumenter der faktisk holder vand
“Governance koster for meget.” Ja, nogle gange gør det. Hvis use-casen tåler usikkerhed – fx inspirationstekster eller intern opsummering af mødenoter – er stramme loops unødvendige. Vi anbefaler ikke determinisme overalt, kun hvor beslutninger har kontant effekt. “Modellerne bliver jo bedre.” Rigtigt. Men enterprise-kravet flytter sig med dem: mere dyb integration, mere direkte handling. Risikoen flytter med ind i P&L, ikke ud.
Der er også et hul i dokumentationen: SAPs 10 procents-illustration er netop det, en illustration. Vi savner brede feltstudier for fejlrate i produktion på tværs af brancher. Indtil da må vi kombinere leverandørudsagn, public reporting og egne målinger. Og lade tvivlen komme forretningen til gode. I retning af kontrol.
Hvor SAP og Venture
Beat mødes – og ikke gør
Der er konsistens i kilderne: SAP insisterer på deterministisk kontrol for at sikre marginer; VentureBeat beskriver, hvordan nye kontrolplaner tvinger workflows på skinner, så agenter ikke bryder dem. Et pænt overlap. Uenigheden – eller rettere fraværet af tal – ligger i de konkrete omkostninger: SAP nævner stigende latenstid og compute uden satser; VentureBeat beskriver designet af kontrolplanet uden benchmarks for effekt. Vi markerer derfor omkostningsdelen som usikkerhedszone, der skal måles lokalt.
Det ændrer ikke hovedkonklusionen. Det gør bare arbejdet foran jer tydeligere: Byg måling ind fra start, ellers bliver governance en følelse i stedet for en styringsmekanisme.
Det nøgterne punktum
Vi kan lide nye modeller. Vi bliver også imponerede. Men i praksis er det styringslagene, der redder marginerne. Den kedelige del. Den del hvor man sætter grænser for løkker, måler hallucinationer og skriver ansvar på tavlen. Der opstår først forskel, når man sidder med det i hænderne. Eller rettere, når regnearket i FP&A viser, at det faktisk kan betale sig – selv med en regning fra skyen, der er lidt tykkere end i demoen.
