Sovereign compute er ikke et indkøb. Det er en operating model.

Der findes en særlig type fiasko, som først viser sig efter båndklipningen.

Systemet eksisterer. Fakturaerne er betalt. Dashboards er grønne. Og så sker der ingenting. Eller værre: Et par entusiaster bruger det, mens alle andre kører udenom, fordi det er langsommere, mere besværligt, mere risikabelt — eller simpelthen ikke koblet til nogens mål.

Det er den ubehagelige læring i den danske sag, hvor en statslig supercomputer blev vurderet som et højrisikoprojekt med advarsler om omkostningseskalering og afhængighed af eksterne rådgivere, og hvor en senere opgørelse viste, at over 90 procent af compute-kapaciteten stod ubrugt.

Den instinktive reaktion er at gøre det til en teknologi-historie. Forkert leverandør. Forkert dimensionering. Forkert arkitektur. Ikke nok træning. Ikke nok “AI-strategi”.

Det her er en operating model-historie. Sovereign compute fejler, når det behandles som et indkøbsevent i stedet for som et produkt med kunder, constraints og en målbar vej til adoption.

Grundfejlen: kapacitet først, efterspørgsel bagefter

Compute bliver først en utility, når du har formet efterspørgslen omkring den. Indtil da er det en dyr option value. Du betaler for at holde muligheder åbne.

Det kan være rationelt, men kun hvis du gør “brug” til den første leverance — ikke en bivirkning. Ellers bliver platformen et museum: imponerende, inaktivt, politisk forsvaret og operationelt forældreløst.

Når folk ikke flytter deres arbejde til et nyt compute-miljø, skyldes det typisk incitamenter, ikke ideologi. De vælger det, der holder deres delivery flow intakt:

• Hurtig adgang slår perfekt suverænitet. Hvis det tager uger at få et miljø, finder teams en anden vej.
• Friktion slår policy. Hvis identitet, dataadgang og tooling ikke passer til hverdagsarbejdet, forbliver platformen teoretisk.
• Lokal optimering vinder. Hvis hver afdeling bærer smerten, men en anden får gevinsten, går adoption i stå.

Modsvaret er ikke mere kommunikation. Det er demand shaping med hårde commitments.

Giv det en ejer, der kan sige “nej” og “stop”

Sovereign compute-initiativer dør ofte af delt ansvar. Alle bliver hørt. Ingen er accountable.

Du skal have én person, der er ansvarlig for outcomes på tværs af tre planer samtidig:

• Platform health (tilgængelighed, performance, security posture, cost per workload type).
• Adoption (onboarding-tid, antal aktive projekter, repeat usage, workload migration).
• Portfolio fit (hvilke workloads hører hjemme her, hvilke gør ikke, og hvad der bliver afvist).

Denne ejer skal have mandat over prioritering og intake. Ellers ender platformen som en ønskeliste af inkompatible krav, hver især begrundet som “strategisk”.

Jeg har set en cloud-platform i en multi-country produktorganisation blive nyttig først, da teamet bag fik lov til at afvise workloads, der permanent ville forvrænge den. Vendepunktet var ikke en bedre stack. Det var governance, der beskyttede platformens formål.

Definér usage-KPI’er, der tvinger den rigtige samtale frem

“Utilisation” er et groft mål. Du kan presse utilisation op med de forkerte workloads og stadig fejle missionen. Du vil have KPI’er, der afslører, om platformen er ved at blive default-vejen for det rigtige arbejde.

Her er syv metrics, der typisk får sandheden frem hurtigt:

• Time to first job: median tid fra request til første succesfulde run.
• Monthly active projects: ikke brugere — projekter, der leverer outputs.
• Repeat rate: andelen af projekter, der kører igen næste måned.
• Workload mix: procent research-eksperimenter vs production pipelines vs batch analytics.
• Data gravity fit: procent workloads, der kører der, hvor data allerede ligger (eller lovligt kan ligge).
• Cost per outcome proxy: cost per trænet model, per behandlet cohort, per rapportcyklus, per simuleringskørsel. Vælg proxies, der matcher missionen.
• Abandonment reasons: tagges, gennemgås månedligt og knyttes til en fix-owner.

De fleste organisationer skriver aldrig abandonment reasons ned. Det er dér, operating model skjuler sine fejl: indkøbsbegrænsninger, adgangsfriktion, uklare support-grænser, manglende libraries, uklart ansvar for compliance, langsom incident response.

Chargeback handler ikke om penge. Det handler om seriøsitet.

Hvis compute er “gratis”, bliver efterspørgslen performativ. Folk booker kapacitet, fordi de kan. Du får køer, støj og politiske slagsmål — ikke værdi.

Hvis compute prissættes dårligt, får du det modsatte: afdelinger beskytter deres budgetter ved at undgå platformen, selv når den samlet set ville være billigere.

Pointen med chargeback er at skabe en klar beslutning i marginen. Nogle praktiske mønstre virker bedre end den sædvanlige interne transfer-price-teater:

• Start med showback i 1 til 2 kvartaler: reel omkostningssynlighed pr. projekt og afdeling — men uden fakturering endnu.
• Gå videre til simpel chargeback med to satser: én for reserveret kapacitet og én for burst. Hold det læsbart.
• Budgettér en migrationspulje centralt: teams kan søge tidsbegrænsede credits, der betaler for refaktorering og de første runs.
• Prissæt smerten, ikke skønheden: tag ekstra for workloads, der kræver bespoke support, skrøbelige afhængigheder eller nonstandard security exceptions.

Når et team mærker prisen på et “special case”, standardiserer de enten — eller de kan begrunde, hvorfor de ikke bør. Begge udfald er sundere end stille entropi.

Det, som de fleste indkøb overser: exit ramps

Version2-historien rummer en advarsel om afhængighed af eksterne rådgivere og risiko for omkostningseskalering — præcis den type risiko, der bliver irreversibel, når kontrakter ikke indeholder exit ramps.

En exit ramp er ikke en trussel. Det er et designprincip: du antager, at nogle valg bliver forkerte, og du bygger på forhånd evnen til at komme ud uden et rewrite og uden gidselforhandlinger.

For sovereign compute bør exit ramps være eksplicitte fem steder:

1. Data portability: klare formater, ejerskab og automatiserede eksportveje for datasæt, metadata og lineage.
2. Workload portability: container-standarder, infrastructure-as-code-baselines og CI-templates, der kan målrettes et andet miljø.
3. Identity and access: undgå leverandørspecifikke IAM-konstruktioner, der ikke kan mappes andre steder.
4. Support dependency caps: tidsbokset advisory, med krav om knowledge transfer og målbare handover-kriterier.
5. Commercial break clauses: forhåndsaftalte muligheder for at reducere scope eller terminere specifikke komponenter, hvis adoption-KPI’er ikke bliver mødt.

Uden dette bliver et vendor-led dead end default. Platformen fortsætter med at eksistere, fordi prisen for at skifte retning får lov til at føles større end prisen for spild.

Hvis du vil have en dybere vinkel på indkøb, bliver samme logik udfoldet i Denmark’s AI Problem Isn’t Models. It’s Procurement Without Exit Ramps.

En praktisk operating model for sovereign compute — på én side

Hvis du genopbygger i dette kvartal, ville jeg starte med et one-pager charter, der tvinger klarhed frem:

• Mission: hvilke outcomes denne compute skal muliggøre — og hvilke den ikke skal.
• Customer list: navngivne afdelinger og programmer med committed workloads.
• Intake: en simpel request-vej med en beslutnings-SLA og afvisningskriterier.
• Golden paths: to eller tre understøttede workload patterns, fuldt dokumenteret.
• KPI’er: time to first job, aktive projekter, repeat rate, workload mix og abandonment reasons.
• Økonomi: showback nu, chargeback senere samt en tidsbegrænset migrationspulje.
• Exit ramps: portability-standarder og break clauses knyttet til adoption-metrics.

Og kør det derefter som et produkt. Ugentlige intake-beslutninger. Månedlig KPI-gennemgang. Kvartalsvis portfolio triage. Hård fokus på golden paths. Sådan undgår du at bygge en smuk platform, som ingen vælger.

Det er også derfor, “sovereign cloud”-debatter ofte rammer ved siden af. Spørgsmålet er ikke kun, hvor workloads kører. Det er, om du kan køre dem stabilt, flytte dem når du skal, og retfærdiggøre omkostningen. Jeg skrev om den bredere portefølje-ramme her: Sovereign Cloud Is Portfolio Triage, Not a Vendor Swap.

Min vurdering: sovereign compute fortjenes — det erklæres ikke

Det politiske sprog om suverænitet kan være nyttigt. Det skaber urgency og funding. Men det kan også skjule en enklere sandhed: platforme betyder kun noget, når de bliver brugt.

Den danske sag, hvor mere end 90 procent af kapaciteten stod stille, er ikke en skandale, fordi utilisation var lav. Det er en advarsel: indkøb uden en operating model er sådan velmenende investeringer bliver til sunk-cost-fortællinger.

Hvis du vil have sovereign compute til at virke, så stop med at behandle det som et nationalt monument. Behandl det som en service med kunder, prissignaler og en vej ud, når dele af designet er forkerte. Det er sådan, suverænitet ikke ender som en undskyldning for spild.