AI i produktion fejler ikke på modellerne. Det fejler på data contracten.

Jeg har set den samme film i fabrikker, produktorganisationer og bestyrelseslokaler. Et team leverer en lovende AI-pilot. Det første dashboard ser stærkt ud. Den første model slår baseline. Og så stopper plant’en med at stole på den. Vedligehold ignorerer den. Kvalitet udfordrer den. Operations siger, at data er “beskidt”. Programmet går i stå — stille og roligt.

Mit syn er kontant: AI i produktion fejler sjældent på algoritmer. Det fejler, fordi ingen har skrevet, finansieret og håndhævet data contracten.

Da jeg brugte elleve år i power electronics på tværs af kvalitetsledelse, projektledelse, application engineering og R&D, havde de bedst performende plants én ting til fælles. De behandlede produkt- og proceskrav som kontrakter — med ejerskab, tolerancer og eskalationsveje. Senere, da jeg drev operations på tværs af Danmark og Ukraine inden for elektrificering og energy storage, var reglen den samme. Hvis et krav ikke var ejet, målt og gennemgået, forfaldt det. Data er ikke anderledes.

En data contract er ikke et dokument. Det er en driftsaftale mellem plant’en og hvert system, der rører ved sandheden. Den definerer, hvad “godt” betyder, hvem der ejer det, hvordan exceptions håndteres, og hvordan drift opdages, før det bliver til brandbekæmpelse.

Den reelle flaskehals er ikke “data quality”. Det er data-ejerskab.

I de fleste plants behandles data som udstødning. Noget man indsamler, fordi man kan. AI kommer så og beder plant’en om at basere beslutninger på den udstødning. Det er et governance-problem — ikke et modeling-problem.

I produktion ved vi allerede, hvordan man kører kontrakter. Vi gør det med CTQs (critical to quality), control plans, kalibreringsplaner, MSA og workflows for nonconformance. Fejlen er at tænke data som et IT-asset. For AI er data et produktionsinput. Det hører hjemme i samme disciplin som yield, scrap og uptime.

Her er den reframing, der virker hos både operatører og bestyrelser: Dit AI-system er kun så pålideligt som det svageste led i din målekæde. Hvis en sensor er fejlkalibreret, hvis et PLC-tag genbruges uden versionering, hvis et skift ændrer en manuel kode uden træning, så er modellen ikke “forkert”. Data contracten blev brudt.

Hvad en data contract skal indeholde

• CTQs for data, ikke kun for produkt: definér de få variable, der driver beslutningen, og angiv krav til completeness, timeliness, accuracy og enheder.
• Navngivne ejere: én operationel ejer pr. CTQ og én teknisk ejer pr. pipeline. “Alle” er ikke en ejer.
• Lineage, du kan forklare på en whiteboard: hvor signalet opstår, hvordan det transformeres, og hvor det forbruges.
• Standardiseret exception-håndtering: hvad der sker, når en værdi mangler, ligger uden for range, er duplikeret, er forsinket eller bliver manuelt overstyret.
• Change control: hvordan tag-ændringer, recipe-ændringer og udstyrsopgraderinger slår igennem til features og thresholds.

Hvis du ikke kan svare på dette på 10 minutter, så skalér ikke modellen. Fiks kontrakten først.

At skalere AI er en plant-rollout-udfordring — ikke en data science-rollout

De fleste AI-programmer finansieres som innovation og styres som IT. Produktion fungerer ikke sådan. Plants eksekverer det, der er koblet til deres KPI’er, gennemgås i deres kadence, og ejes af mennesker med mandat til at ændre processen.

Da jeg var CEO for en smart-building og home-automation forretningsenhed, byggede vi forbundne sensorer og controls på tværs af flere lande. Teknologi var aldrig den svære del. Det svære var at definere, hvad “signal integrity” betød på tværs af markeder, installatører, firmware-versioner og cloud-releases. Hvis du ikke standardiserer exceptions, har du ikke et produkt. Du har demos.

I en fabrik er “exceptions” ikke edge cases. Det er tirsdag. En sensor fejler. En linje stopper. Et batch splittes. En rework-loop starter. Hvis din AI antager rene, kontinuerlige data, er den ikke designet til produktion. Data contracten skal afspejle plant’ens virkelighed — ikke labbens.

Operator-first rollout-sekvensen

1. Vælg én beslutning, ikke én model. Eksempel: “Hold eller frigiv et batch”, “Planlæg vedligehold i denne uge eller næste”, “Reducér energispids uden at bryde takt”.
2. Definér den minimum viable truth: de CTQs, der skal til for at træffe beslutningen sikkert.
3. Instrumentér exceptions: manglende værdier, manuelle overrides, sensorfejl, late arrivals. Gør exceptions synlige og tæl dem.
4. Bind funding til KPI’en: scrap-reduktion, first-pass yield, OEE, unplanned downtime, energi pr. enhed. Hvis plant’en ikke mærker det, bliver det ikke fastholdt.
5. Deploy med en kill switch: plant’en skal kunne falde tilbage til tidligere standard work uden drama.

Derfor kan jeg lide at tænke i checklister. Jeg har skrevet om den tilgang i AI architecture as an operator’s checklist. Arkitektur er ikke et billede. Det er en sekvens af forpligtelser, der overlever mødet med virkeligheden.

Data CTQs: behandl målinger som et produktkrav

I kvalitet diskuterer vi ikke, om en måling er “god nok” i abstrakt forstand. Vi definerer tolerancer, validerer metoden og auditerer drift. Gør det samme for AI-inputs.

En praktisk skabelon til data CTQs

• Definition: navn, enhed, sampling frequency og source system of record (PLC, MES, SCADA, ERP, LIMS).
• Acceptable range og fysiske constraints: hvilke værdier der er umulige eller usikre.
• Freshness window: hvor sent er “sent”, før beslutningen bliver ugyldig.
• Completeness threshold: hvor stor en andel manglende værdier tolereres, før modeloutput undertrykkes.
• Reconciliation rule: hvad sker der, når MES og ERP er uenige, eller når en manuel registrering konflikter med en automatisk aflæsning.
• Audit cadence: hvem gennemgår det ugentligt, og hvad udløser en corrective action.

Gør du det her godt, vil plant’en stole på systemet, fordi det opfører sig som en kontrolleret proces. Gør du det ikke, bliver hver anomali til en diskussion — og diskussioner skalerer ikke.

Governance der virker: gør exceptions, lineage og incitamenter synlige

Jeg bryder mig ikke om governance-teater. Komitéer, der diskuterer principper, mens operatører slukker brande, ændrer ikke resultater. Effektiv governance er et operating system: det omsætter dataproblemer til tickets, ejere, deadlines og forebyggelse.

Her er det styrende spørgsmål, jeg har brugt i lederroller: “Når modellen tager fejl, hvem bliver så vækket?” Hvis svaret er uklart, er systemet ikke governable.

Minimum governance-stack til AI i produktion

• Ét samlet scoreboard: AI-adoption koblet til plant-KPI’er plus data contract health (exception rate, freshness breaches, schema drift events).
• Lineage der kan auditeres: ikke først og fremmest af compliance-hensyn, men til troubleshooting kl. 02 om natten.
• Standard work for overrides: når operatører overstyrer AI, skal de vælge en reason code. Ikke for at kontrollere dem, men for at lære systematisk.
• Release-disciplin: feature-ændringer og modelopdateringer følger samme alvor som firmware-ændringer i embedded systems.
• Budget der matcher ansvar: hvis operations ejer KPI’en, skal de også med-eje budgettet til sensorer, integration og vedligehold af pipelines.

Det er også her, applied AI bliver virkelig. I mine ventures som Shopeno og IBHQ tænker jeg på AI som produktadfærd — ikke som et science experiment. Produktet skal kunne degrade gracefully, forklare sig selv og skabe et audit trail. Fabrikker har brug for de samme egenskaber, bare med højere stakes og strammere feedback loops.

Bestyrelsesperspektivet: finansier data contracten, som du finansierer reliability

Hvis du sidder i en bestyrelse eller ejer P&L, er her fælden, du skal undgå. Du finansierer et AI-initiativ som et projekt, og så forventer du compounding value. Men den underliggende data contract er et levende system. Det kræver vedligehold — ligesom preventive maintenance på udstyr.

Min holdning: behandl data contracten som reliability-arbejde. Den skal have en backlog, en cadence og en tydelig ROI-historie koblet til plant-KPI’er. Hvis den ikke finansieres, bliver det “alles problem” og ingens job.

Hvis du vil have en enkel diagnostic for dette kvartal, så bed om tre tal ved næste ops review:

• Exception rate: hvor ofte AI-pipelinen ser manglende, forsinkede eller ugyldige inputs.
• Mean time to innocence: hvor hurtigt teamet kan bevise, om et issue ligger i sensor, integration, transformation eller model.
• Override learning loop: andel af overrides der fører til en contract-opdatering, en træningsopdatering eller en procesændring.

Hvis de tal er ukendte, er modellen ikke flaskehalsen. Kontrakten er.

Min afsluttende pointe er enkel. Stop med at spørge: “Er modellen præcis?” Start med at spørge: “Er data contracten håndhævelig?” AI i produktion skalerer, når data behandles som operationel sandhed med CTQs, ejerskab, lineage og standardiserede exceptions. Alt andet er en pilot.