Lad os være ærlige: at flytte en chatbot‑demo over i produktion for 10.000 medarbejdere er ikke en “skalering”. Det er et helt nyt projekt. VentureBeats samtale med Tarkan Maner og Thomas Cornely fra Nutanix rammer den nervetråd – virksomheder er i gang med at gå fra piloter og skyeksperimenter til rigtige workloads og rigtige brugere. Vi genkender det i Snilld. Det er her, mange snubler.
Interviewet peger på skiftet mod agent‑baserede løsninger. Her bliver efterspørgslen efter infrastruktur pludselig ujævn, uforudsigelig – og ærlig talt lidt kras. Ikke bare flere kald til en model, men kæder af handlinger på tværs af systemer. Det er den virkelighed, vi skriver ind i her. Uden pynt, med kilder og praksis tæt på.
Hvorfor det rammer nu
VentureBeat beskriver et hul mellem prototype og produktion, og bruger et konkret billede: at gøre en prototype tilgængelig for 10.000 medarbejdere. Det giver nye krav til processer, koordinering og sikkerhed, som man ikke ser i en PoC. Den pointe er veldokumenteret i interviewet – og vi ser det samme hos danske kunder, når en god PoC skal bære rigtige sager og gennemsigtighed over for drift og compliance.
Skiftet til agenter øger infrastrakturpresset, fordi workloads bliver realtidsnære og springvise. Flere samtidige agenter, mange små beslutninger i træk, og afhængighed af interne datakilder. Alt sammen på fælles ressourcer, hvor teams står i kø. Det er ikke dramatik, bare hverdagslogistik i stor skala.
Hvad agentic AI kræver af infrastrukturen
Agenter kører multi‑step forløb, slår op i dokumentlagre, kalder ERP og CRM, måske skriver de billetter i ITSM. Det er ikke ét spørgsmål ét svar, men et forløb, der kan variere pr. opgave. Det skaber tre praktiske krav: lav og stabil latenstid, isolation mellem flows, og styring af samtidighed, så et tungt forløb ikke kvæler de andre. VentureBeat‑kilderne beskriver samme mønster, inklusiv ønsket om at køre tæt på data on‑prem, når opgaven er følsom.
Herfra bliver placering af workloads et rigtigt valg: nogle forløb skal bo tæt på data for at ramme latenstargets og adgangskrav, andre kan “burste” i skyen. Uden en klar strategi ender I med at betale for spidsbelastning 24\/7 eller se jeres agenter timeoute, når ERP’et svarer langsomt kl. 10:02. Vi har set begge dele.
Drift: fra hyggelab til 24\/7
Når agenterne flytter ind i forretningen, flytter MLOps ind i driften. Det betyder vagtordning, produktions‑SLA’er og runbooks. VentureBeat peger på behovet for at koordinere adgang til fælles infrastruktur på tværs af teams – vi vil tilføje, at det i praksis kræver konkret prioritering: hvem har ret til GPU’er ved spidslast, og hvornår? Hvem sætter kvoterne? Uden svar drukner man i uforudsigelige køer.
Forklaringerne skal være jordnære. MLOps er: versionsstyring af modeller og prompts, deployments som kan rulles tilbage, overvågning af inferensfejl og tokenforbrug pr. workflow. DataOps er: pipelines der kan fejle sikkert, datakvalitet, adgangsstyring. Orkestrering er: flowet mellem de to, med tidsgrænser, retries og stopklodser, der ikke vælter alt andet.
Sikkerhed og governance, helt konkret
VentureBeat fremhæver behovet for “constructs” omkring agenter, især når de kører on‑prem tæt på data. Oversat til praksis: lav sandboxes til handlinger, capability‑scop agenter (hvad de må gøre, hvor ofte og hvor), brug rollestyring på tværs af agent og bruger, og log alt med sporbarhed ned på step‑niveau. Når en agent skriver i ERP’et, skal I kunne se hvem, hvad, hvornår – og rulle tilbage på få minutter, ikke dage.
Regulatoriske krav i EU skubber i samme retning. EU’s AI‑regulering gør godkendelsesprocesser, dokumentation og adgangsstyring mindre valgfrie og mere faste. Pointen her er praktisk, ikke juridisk rådgivning: hvis jeres agent må handle, så skal I kunne forklare, hvad den måtte, hvorfor den gjorde det, og hvordan I kan stoppe den igen. Det kræver audit trails og godkendelsesflows som standard, ikke som et senere tillæg.
Nutanix’ position – og hvad der er vendorudsagn
Nutanix’ produktside beskriver en full‑stack Agentic AI‑løsning med cloud‑operating‑model, integration til NVIDIAs økosystem og features som smart routing, inference scaling og topology aware placement. Ifølge materialet skal det forenkle drift, maksimere performance og sikkerhed og optimere GPU‑forbrug og per‑token‑omkostninger. Det er klart markerede vendorudsagn i kilden.
Vores krydstjek: VentureBeat‑interviewet underbygger bevægelsen til produktion og behovet for styring, men leverer ikke uafhængige benchmarks for økonomiske gevinster. Der er altså ingen tal i kilderne, der dokumenterer generelle per‑token‑reduktioner eller bredt forbedret GPU‑udnyttelse. Det gør ikke løfterne forkerte, men det gør dem ubeviste uden lokal måling.
Økonomi og kapacitet uden illusionsnummer
Det er fristende at “løse” alt med flere GPU’er. Vi anbefaler først at måle tre ting: udnyttelse over tid (ikke kun peak), latenstid under multi‑agent load og tokenforbrug pr. afsluttet workflow. Hvis I ikke har styr på de tre, kan en ekstra GPU bare gøre det samme dyrere.
Et simpelt testscenarie, vi ofte starter med, før produktionssætning: simuler 200 samtidige agentflows med 500 ms SLA mod et internt API, mål end‑to‑end‑latenstid, kølængder og fejltyper. Gennemfør med og uden caching, og med throttling slået til. Resultatet afslører næsten altid, om I skal investere i orkestrering, caching eller netværk – før I shopper mere hardware. Det lyder kedeligt. Det virker.
Roller og KPI’er, når arbejdet ændrer form
Når agenter overtager gentagne kognitive opgaver, ændrer rollerne sig. Vi ser størst effekt, når virksomheder får ejerskab på tværs: en produktansvarlig for AI‑flowet, en driftsejer med SLA og en dataejer, der godkender adgang og datakvalitet. Uden de tre roller får I gråzoner og lange ventetider.
Start med få, hårde KPI’er: median og P95‑latenstid pr. workflow under last, successrate pr. agentstep, tokenforbrug pr. vellykket opgave, og MTTR ved rollback af en model\/prompt. Det er mål, teams kan arbejde med uge for uge. Og som ledelsen kan forstå uden at få ondt i hovedet.
Placering og beskyttende rammer i praksis
VentureBeat nævner ønsket om on‑prem agenter tæt på data. Vi bygger typisk to zoner: en “read‑nær” zone hvor agenter kan slå op i følsomme kilder med stram adgangsstyring, og en “write‑gate” hvor alle skrivninger sker gennem en godkendt broker med validering, idempotens og auditlog. Det er ikke smukt, men det reducerer risici markant.
Derudover: test latens, ikke kun i LLM‑kaldet, men i hele kæden. Hvis jeres ERP svarer langsomt, hjælper ingen modeloptimering. Vi har siddet i et mødelokale i Hvidovre, hvor ventilationsstøjen overdøvede skærmlyden, mens vi jagtede 700 ms i en integration. Det var ikke modellen. Det var en for smal databaseforbindelse.
Hvornår vendoroptimering kan give mening
Hvis I vurderer Nutanix eller lignende, så lav en kontrolleret A\/B: samme workload, samme SLA’er, med og uden deres smart routing og topology placement. Mål P95‑latenstid, kølængde, GPU‑udnyttelse og per‑workflow‑pris i en uge. Uden den test famler man i mørke, og vendorløfter forbliver – løfter. Kilderne her leverer ikke de tal, så de skal komme fra jer.
En note om spidsbelastninger: dimensionerer I efter værste time, ender I med dyr stilstand resten af dagen. Overvej kødisciplin, reservationsvinduer og “burst‑grænser” pr. team. Det er kedelige ord, men de betaler jeres regning.
Mini‑case fra felten
Internt observation: En mellemstor dansk virksomhed gik fra PoC til udrulning mod 800 brugere. Vi prioriterede observability først og satte en lille on‑prem GPU‑klynge til latency‑følsomme flows. Fejlrate faldt cirka 40 procent på tre måneder. Målt som andel af mislykkede workflows over total, uge for uge, før og efter forbedringer, med samme use cases. Ingen magi – bare bedre orkestrering, caching og adgangsstyring.
Vi siger det, fordi det er det, der flytter nålen. Ikke fordi alle skal gøre det samme. Brug det som pejlemærke, ikke som facitliste.
Konkrete næste skridt
- Definér 3–5 KPI’er: P95‑latenstid, successrate pr. step, token pr. workflow, GPU‑udnyttelse over tid, MTTR ved rollback.
- Lav en 2‑ugers lasttest med realistiske multi‑agent flows og mål end‑to‑end, ikke kun modelkald.
- Etabler to zoner: read‑nær adgang med stærk rollebaseret styring og en write‑gate med validering og audit.
- Aftal kvoter og prioritering på tværs af teams. Skriv dem ned. Hvem vinder ved spidslast?
- Kør en kontrolleret A\/B af enhver vendorfeature, der lover “optimering”. Dokumentér forskellen eller drop den.
Afvejninger, der er værd at kende
Cloud først med hybrid burst giver fart i starten, men kræver disciplin i adgangsstyring og omkostningskontrol. On‑prem tæt på data sænker latenstid og gør governance mere håndgribelig, men binder kapital og kræver moden drift. Managed hybrid, som Nutanix stiller i udsigt, kan forenkle hverdagen – hvis deres routing og placement matcher jeres workloads. Ingen af valgene er forkerte; det forkerte er ikke at vælge.
Til sidst den jordnære sandhed: Projekter mister momentum på grund af uklare KPI’er, svag forandringsledelse og ingen plan for drift. Vi ser det igen og igen. Få styr på de tre, før I køber den næste GPU. Man opdager først forskellen, når man sidder med det i hænderne.
