AI-arkitektur er ikke et diagram. Det er en operatørs tjekliste.

Jeg har siddet på begge sider af den her problemstilling: siden der leverer teknologi, og siden der bærer de operationelle konsekvenser.

Da jeg stod for driften i en elektrificerings- og energilagringsforretning, kunne jeg ikke gemme mig bag roadmaps. Engineering, R&D, produktion, supply chain og service mødte virkeligheden hver dag. Et produkt, der “næsten virker”, er ikke et produkt; det er en risiko. Senere, da jeg ledte en smart-building business unit på tværs af flere lande, lærte connected devices og cloud services den samme lektie i en anden indpakning: oppetid er ikke en feature. Det er en driftsdisciplin.

AI gentager nu det mønster—bare hurtigere. Ledere spørger efter “AI-arkitekturen”. De får et diagram: modeller, vector databases, agents, orchestration. Det ser pænt ud. Og så går det i stykker dér, hvor det eneste der tæller: i produktion, hos kunder, under tidspres.

Min holdning er enkel: AI-arkitektur er ikke et diagram. Det er en operatørs tjekliste. Hvis du ikke kan drive det, så har du det ikke.

Den bedste framing jeg har set for nylig, er i MIT Technology Review’s overblik over de grundlæggende elementer, ledere skal have på plads for at skalere AI. Det understreger det, operatører allerede ved: jo mere kapabel og agentic AI bliver, jo større bliver din risk surface. Svaret er ikke mere begejstring. Det er mere disciplin.

Spændingen: AI vil gerne være produkt, men opfører sig som drift

I industrielle miljøer forveksler vi ikke en prototype med en produktionslinje. Vi gate’r. Vi kvalificerer. Vi skriver procedurer. Vi måler yield. Vi kører corrective actions. AI skal behandles på samme måde, fordi AI’s failure modes minder mindre om “bugs” og mere om “process drift”.

Og drift er dødeligt. Ikke fordi modellen er “dårlig”, men fordi systemet omkring den er udefineret. Inputs ændrer sig. Tools ændrer sig. Brugeradfærd ændrer sig. Regulering ændrer sig. Pludselig giver din AI-assistent med stor selvtillid det forkerte svar, eller din agent tager den forkerte handling, og alle opdager—for sent—at ingen ejer operating system’et omkring den.

Hvis du er bestyrelsesmedlem eller operatør, så er det her den omformulering, jeg vil have dig til at adoptere: behandl AI som et produktions operating system. Ikke en demo. Ikke en capability. Ikke en slide. Et operating system med kontrakter, quality gates, performance commitments og en incident playbook.

Operatørens tjekliste: hvad “AI-arkitektur” reelt betyder

Jeg undgår bevidst en komponentliste. Du kan købe komponenter. Du kan ikke købe operationel integritet. Det her er tjeklisten, jeg bruger, når jeg gennemgår et AI-program—uanset om det er til et manufacturing workflow, en field-service support assistant, et fintech back office eller et AI-lag i en af mine egne ventures som Shopeno eller IBHQ.

1) Data contracts, ikke “data access”

I power electronics tidligere i min karriere var kvalitetsproblemer sjældent mystiske. De kunne spores: en tolerance stack-up, en leverandørændring, et test-gap. AI kræver samme sporbarhedsdisciplin—startende ved input-grænsen.

• Definér input schemas for hver AI-relevant kilde (tickets, sensor feeds, invoices, SOPs, chat logs). Versionér dem.
• Udpeg en data owner, der kan godkende ændringer og acceptere konsekvenserne.
• Fastlæg forventninger til freshness og completeness på samme måde som for en produktions-KPI.
• Dokumentér tilladte transformationer (redaction, summarization, deduplication), så du kan reproducere outputs.

“Vi har koblet modellen på vores data lake” er ikke en kontrakt. Det er et fremtidigt incident.

2) Evals er din incoming inspection

I hardware og embedded systems kvalificerer du komponenter, før du skalerer. AI er ikke anderledes—bortset fra, at “komponenten” ændrer adfærd med prompts, context windows, retrieval og tool-tilgængelighed.

• Vedligehold et levende evaluation set, der spejler reelt arbejde (ikke benchmark-teater).
• Mål task success, ikke kun accuracy: resolution time, escalation rate, rework skabt, customer impact.
• Test for failure modes: hallucination under usikkerhed, policy violations, tool misuse, data leakage.
• Kør evals ved hver ændring: model, prompt, retrieval, tool schema, routing logic.

Hvis du ikke kan beskrive din evaluation harness lige så klart, som du kan beskrive en teststation i en fabrik, er du ikke klar til at skalere.

3) SLO’er, ikke “det virker fint”

Da jeg ledte R&D-organisationer på tværs af embedded software og cloud, lærte vi at oversætte kundesmerte til målbare commitments. AI kræver samme oversættelse.

• Latency SLO: time-to-first-token og time-to-action.
• Reliability SLO: tool-call success rate, retrieval success rate, fallback behavior.
• Quality SLO: pass rate på kritiske eval-cases; “no-regret”-thresholds for regulerede outputs.
• Cost SLO: cost per resolved case eller per workflow completion, ikke cost per token.

Bestyrelser forstår SLO’er. Operatører kan styre SLO’er. Teams kan ikke styre vibes.

4) Menneskelige kontroller er ikke en svaghed; de er control plane

AI-programmer svinger ofte mellem to yderpunkter: fantasier om “full automation” og “human-in-the-loop” som et diffust sikkerhedstæppe.

Operatører tænker anderledes. Vi definerer control modes.

• Advisory mode: AI anbefaler; mennesket beslutter. Godt i højrisko-domæner og ved tidlig udrulning.
• Guarded execution: AI handler inden for stramme rammer (limits, templates, approval steps).
• Autopilot: AI eksekverer end-to-end, men med målbare stopbetingelser og auditability.

Spørgsmålet er ikke “human in the loop eller ej”. Spørgsmålet er: hvor ligger myndighed, hvor ligger accountability, og hvad er override?

5) Incident response: antag, at du tager fejl i skala

I connected building controls har hvert incident to omkostninger: den umiddelbare customer impact og den langsigtede erosion af tillid. AI tilføjer en tredje: epistemic risk. Folk holder op med at vide, hvad de kan stole på.

• Definér incident types: forkert svar, forkert handling, policy breach, data leak, runaway cost, degraderet performance.
• Lav en kill switch: slå tool execution fra, slå eksterne calls fra, revert til en sikker model eller fald tilbage til human-only flows.
• Log til forensics: prompts, context, retrieval results, tool calls, outputs, user actions (med privacy controls).
• Kør postmortems, der ændrer systemet: eval-opdateringer, kontraktopdateringer, routing-opdateringer, ændringer i permissions.

Uden incident-muskel er skalering af AI bare skalering af blast radius.

Et mønster i praksis: hvorfor AI og industriel eksekvering rimer

Her er mønsteret, jeg har set igen og igen—først i industriel teknologi, så i SaaS og fintech, og nu i applied AI:

Begrænsningen er sjældent capability. Begrænsningen er koordinering under usikkerhed.

Da jeg ledte en smart-building-enhed på tværs af flere lande, havde vi embedded devices i felten, cloud services i udvikling og kunder med forskellige compliance-forventninger. Det, der virkede, var ikke “bedre arkitekturdiagrammer”. Det, der virkede, var operationel klarhed: hvilke ændringer der var tilladt, hvordan vi validerede dem, hvad vi monitorerede, og hvordan vi kom tilbage, når noget slap igennem.

Jeg bruger samme disciplin i mine ventures i dag—særligt i platforme som Shopeno og IBHQ, hvor tillid, korrekthed og cost control betyder noget. AI-features frister til hurtig shipping. Men den eneste AI, der overlever, er den AI, du kan drive: versionerede inputs, gentagelige evals, eksplicitte SLO’er og en tydelig authority model.

Det er også derfor, jeg godt kan lide at låne mental models fra energi og infrastruktur. Bankability handler ikke om optimisme. Det handler om kontroller, garantier og response plans. Den samme operator-logik går igen i, hvordan jeg tænker om execution risk i energiprojekter (jeg har skrevet mere om det i The Operator’s Playbook for Making Grid-Scale Storage Bankable). AI har brug for sin egen version af bankability: decision-grade quality, afgrænset risiko og forudsigelig drift.

Bestyrelsesspørgsmålene, der afslører “demo-arkitektur”

Hvis du sidder i en bestyrelse, eller du ejer et P&L, behøver du ikke diskutere modelfamilier. Du skal pressure-teste operationel parathed. De her spørgsmål gør det hurtigt:

1. Hvad må AI’en gøre? Ikke “hvad kan den”—hvad er autoriseret i produktion?
2. Hvad er SLO’erne? For latency, cost, reliability og quality. Hvem ejer dem?
3. Vis mig eval suite. Hvilke tasks? Hvilke failure modes? Hvor ofte kører den? Hvad blokerer release?
4. Hvilke ændringer udløser re-qualification? Model, prompt, retrieval corpus, tool schema, policy changes.
5. Hvor er kill switch? Hvem kan trække i den? Under hvilke betingelser? Hvad er fallback workflow?
6. Hvordan undersøger vi et incident? Hvilke logs findes? Hvor længe gemmes de? Hvad er vores privacy posture?
7. Hvad er rollout-strategien? Advisory → guarded → autopilot, med eksplicitte gates.

Hvis ledelsen ikke kan svare på de her uden at tale udenom, så er “arkitekturen” stadig bare et diagram.

Min klare holdning: byg mindre AI. Operér mere AI.

AI-samtalen er fyldt med frameworks, stacks og vendor-løfter. Operatører bør holde sig stædigt praktiske.

AI skalerer, når du behandler det som produktion. Det betyder kontrakter frem for access, evals frem for vibes, SLO’er frem for anekdoter, control modes frem for en generel “human-in-the-loop”, og incident response frem for håb.

Hvis du vil have én handling for det her kvartal, så gør dette: vælg én AI use case, der rammer reel drift (service triage, procurement support, maintenance planning, customer onboarding). Skriv derefter tjeklisten på én side. Udpeg ejere. Sæt SLO’er på et dashboard. Kør en incident drill. Du lærer mere på 30 dage med drift end på seks måneder med diagrammer.

Det er pointen. Arkitektur er ikke det, du tegner. Det er det, du kan drive.