AI-adoption handler mest om workflow-ejerskab – ikke om modeller

Jeg har en enkel test på, om en organisation mener det seriøst med AI: Kan I pege på workflow owner?

Ikke product owner for en chatbot. Ikke data-chefen. Men den operatør, der ejer end-to-end-processen, error budgettet og escalation path, når AI rammer ved siden af.

I Danmark kan man se forskellen på “AI theatre” og operationel AI i måden, et stort forsikringsselskab har behandlet AI som nye kolleger, der tager rutineopgaver og frigør tid til menneskerne. Det er ikke en moonshot-fortælling. Det er års workflow-optimering, én rutineopgave ad gangen, med løbende forbedringer og klart ejerskab.

Det er den case, jeg gerne vil have flere bestyrelser og operatører til at tage ind. “AI adoption” er i praksis workflow-ejerskab plus controls. Controls er ikke en komité. Det er det samme, vi industrialiserede for årtier siden i produktion: definerede handoffs, klare definitioner af defects og hurtig escalation. Og så måler man det, der betyder noget: cycle time i skadesbehandling, leakage og complaint rate. Ikke klapsalver til en demo.

Operatørens reframing: AI er en station i din proces

Da jeg brugte elleve år i power electronics, var kvalitet aldrig et PowerPoint-tema. Det var en produktionsrealitet. Man designede linjen, så det rigtige arbejde skete på den rigtige station, med klare acceptance criteria. Hvis en enhed fejlede, diskuterede man ikke filosofi. Man begrænsede fejlen, reworkede og fandt root cause.

De fleste AI-programmer mangler det industrielle instinkt. De starter med en model og går derefter på jagt efter et use case. Operatører gør det omvendte. De starter med et workflow, der allerede findes, med kendt smerte: backlog, rework, kunde-frustration eller leakage. Derefter beslutter de, hvor AI kan fungere som en station – og hvordan “godt” ser ud på den station.

Tre praktiske konsekvenser følger:

• AI “transformerer” ikke en funktion. Den ændrer specifikke handoffs. Det er dér, du vinder eller taber.
• AI-output er ikke en beslutning. Det er et input til en beslutningskæde med eksplicit ansvar.
• Controls er ikke overhead. Det er det, der gør throughput bæredygtig.

Det er også derfor, jeg bliver ved med at vende tilbage til et operator-checklist-syn på AI. Hvis du vil have den dybere tekniske framing, har jeg skrevet en supplerende tekst om, hvorfor AI-arkitektur er en operatørs checklist. Samme mindset gælder her – bare på workflow-niveau.

Definér handoffs mellem mennesker og AI – og skriv reglerne ned

Hvis du kun gør én ting i dette kvartal, så gør det her: Kortlæg ét workflow end-to-end, og markér hvert punkt, hvor arbejdet skifter hænder. Menneske til menneske. System til menneske. Menneske til system. Beslut derefter, hvor AI skal ligge, og hvad der sker, når den er usikker.

Jeg bruger bevidst produktionssprog, fordi det tvinger klarhed frem. På en fabrik ville man aldrig sige “stationen finder nok ud af det.” Man specificerer det.

I vidensarbejde svarer det til et kort sæt operating rules:

1. Entry criteria: Hvilke input kræves, før AI må agere? Hvad er minimum for datakomplethed? Hvilken “freshness” er tilladt?
2. Exit criteria: Hvordan ser et acceptabelt output ud? Hvilke felter skal være udfyldt? Hvilken dokumentation/evidence skal vedhæftes?
3. Handoff design: Hvornår auto-completer AI vs. laver et udkast vs. kun anbefaler? Hvem signerer?
4. Error budget: Hvilke fejltyper kan tolereres – og ved hvilken rate? Hvilke fejl er aldrig acceptable?
5. Escalation path: Hvor skal usikre sager hen? Hvor hurtigt? Til hvem? Med hvilken kontekst?

Det er her, de fleste AI-adoption-indsatser stille og roligt dør. Ikke fordi modellen er svag, men fordi ingen vil eje de ubehagelige detaljer. Især error budgettet.

Error budgets: Stop med at lade som om du kan “eliminere fejl”

Alle reelle processer har defects. Operatørens spørgsmål er ikke, om defects findes. Det er, om du har designet til dem.

Da jeg kørte drift i industrielle kontekster, arbejdede vi med klare defect-definitioner og containment. I R&D- og QA-roller behandlede vi kvalitet som en systemegenskab: prevention, detection og correction. Du får ikke robust output ved at bede folk om “at være forsigtige”. Du får det ved at gøre næste handling åbenlys og hurtig.

AI kræver samme behandling. Definér få kategorier, der betyder noget operationelt:

• Kritiske fejl: forkert handling med kundeskade, regulatorisk risiko eller finansielt tab. De kræver hårde gates og menneskelig godkendelse.
• Dyre fejl: fejl der skaber rework, forsinkelser eller leakage. De kræver sampling, thresholds og hurtige opdateringer af model eller regelsæt.
• Kosmetiske fejl: formatering, formulering, mindre klassifikationsdrift. De bør ikke stoppe flowet.

Oversæt det derefter til en eksplicit policy: Når confidence er under X, sendes sagen til human review. Når casetypen er Y, må der aldrig auto-actes. Når data er ufuldstændige, indhentes manglende felter, før man går videre. Det er ikke sexet. Det virker.

Bestyrelser spørger ofte: “Hvad er risikoen?” Et bedre spørgsmål er: “Hvad er vores designede respons, når AI tager fejl?” Hvis du ikke kan svare på det, har du ikke et AI-system. Du har en prototype i produktion.

Mål adoption som en operatør: cycle time, leakage, complaint rate

Hvis du måler AI på antal pilots, får du pilots. Hvis du måler på demo-tilfredshed, får du flotte demos. Operatører måler throughput og kvalitet.

I skadesbehandling betyder det metrics som cycle time, leakage og complaint rate. I produktion er det first-pass yield, scrap og returns. I SaaS er det resolution time, ticket deflection uden repeat contact og churn-signaler. Domænet ændrer sig. Operatørlogikken er identisk.

Her er et praktisk KPI-sæt, der oversættes godt på tværs af brancher:

• Cycle time: median og 90-percentil fra intake til beslutning.
• Rework rate: andel af sager, der kommer tilbage efter et AI- eller menneskestep.
• Leakage proxy: målbar “værdi tabt” i processen (overbetaling, underfakturering, missede recoveries, frafaldne fees, unødvendig dispatch).
• Complaint rate: normaliseret pr. volumen, med severity-niveauer.
• Escalation volume: hvor ofte AI triggere human review – og hvorfor.

To af disse er dit early warning system: rework og escalations. Når de spiker, diskuterer man ikke. Man undersøger stationen: inputkvalitet, prompt-logik, model drift, brugeradfærd eller uklar policy. Og så retter man processen.

Et eksempel fra virkeligheden: Jeg lærte det på den hårde måde, da jeg byggede og skalerede teams

Da jeg genopbyggede og skalerede en R&D-organisation til omkring 22 specialister på tværs af embedded software, cloud, elektronik, mekanik og QA, var flaskehalsen sjældent rå talent. Det var interfaces. Hvem ejede handoffet fra elektronik til firmware? Hvornår var en release candidate “done”? Hvad skete der, når QA fandt et systemisk problem sent?

I det øjeblik vi skrev acceptance criteria og escalation paths ned, steg throughput. Kvaliteten steg. Stress faldt. Ikke fordi folk arbejdede mindre, men fordi tvetydigheden faldt.

Jeg bruger samme mindset i dag i mine ventures. Når jeg bygger produkter som IBHQ eller Shopeno, behandler jeg applied AI som en del af operating systemet: hvad den må gøre, hvad den aldrig må gøre, og hvilken evidence den skal vedhæfte, så et menneske hurtigt kan verificere eller override. Gevinsten er ikke “AI overalt”. Gevinsten er færre uklare handoffs og hurtigere beslutninger med kontrol.

Det er også derfor, jeg ikke bliver imponeret, når nogen siger, at de har “rullet AI ud i organisationen”. Jeg spørger: Hvilket workflow, hvilken station, hvilket error budget, hvilken escalation owner, og hvilken metric flyttede sig?

Bestyrelsens og operatørens checklist for dette kvartal

Hvis du vil have en konkret plan, du kan eksekvere på 90 dage, så brug denne checklist.

1. Vælg ét workflow med volumen. Skadeintake. Fakturamatch. Customer support-triage. Supplier onboarding. Ét workflow – ikke en afdeling.
2. Navngiv workflow owner. Én person med ansvar for end-to-end-flow og outcomes.
3. Kortlæg stationer og handoffs. Hvor skifter arbejdet hænder, og hvor går det i stå?
4. Indsæt AI som en station – ikke et lag. Definér entry og exit criteria.
5. Skriv error budget og escalation path. Inkludér “never auto-act”-cases.
6. Instrumentér metrics. Cycle time, rework, leakage proxy, complaint rate.
7. Kør ugentlige ops reviews. Som et produktionsmøde. Top defects. Top escalations. Root causes. Fixes shipped.

Hvis du har brug for en mental model fra et andet domæne: I grid-scale energy bygges bankability på controls og forudsigelig performance. Den samme operatørdisciplin er grunden til, at jeg skrev en playbook om at gøre grid-scale storage bankable. AI er ikke anderledes. Tillid konstrueres.

Min holdning: Stop med at købe AI. Begynd at operate det.

Den danske case er “kedelig” på den gode måde. Årevis med at optimere workflows og frigøre tid ved at lægge AI på rutineopgaver – ikke som magi, men som en produktionskapabilitet, du forbedrer løbende.

Det er den standard, jeg mener bestyrelser bør kræve. Ikke et innovationslab. Ikke en bunke pilots. Men en navngiven workflow owner. Definerede handoffs. Error budgets. Escalations. Og metrics, der kan mærkes på P&L og kundeoplevelsen.

Når du gør det, bliver modellerne næsten den lette del. Den svære del er ledelse: at eje workflowet, som var det din produktionslinje – for det er det.