Hvorfor AI-piloter dør, og hvad der får dem i drift

Hvad er pilot-teater?

Pilot-teater er, når en AI-løsning bliver demonstreret på udvalgte eksempler, høster applaus på et ledelsesmøde og derefter aldrig kommer i drift. Demoen var ægte nok. Men den beviste kun, at teknologien kan noget, ikke at den løser jeres proces med jeres data i jeres hverdag.

Forskellen på en demo og en pilot er, hvad de skal producere. En demo skal skabe begejstring. En pilot skal producere et beslutningsgrundlag: tal, der gør det muligt at sige ja eller nej til drift med åbne øjne.

Pilot-teater overlever, fordi alle har en interesse i demoen. Leverandøren viser sit produkt fra den bedste side, projektgruppen leverer noget synligt, og ledelsen kan sætte flueben ved innovation. Den eneste, ingen repræsenterer, er tallet: hvad kostede processen før, og hvad koster den nu? Det første skridt mod en seriøs pilot er at give nogen ansvaret for netop det tal.

Hvorfor dør piloter mellem demo og drift?

Vi ser tre årsager igen og igen, når virksomheder fortæller os om piloter, der løb ud i sandet. Ingen af dem handler om teknologi.

• •Ingen baseline: ingen målte, hvor mange timer eller fejl processen kostede før piloten. Så er der heller ikke noget tal, som effekten kan holdes op imod.
• •Ingen ejer: piloten var et projekt, ikke et ansvar. Da projektperioden sluttede, var der ingen i driften, der havde løsningen som en del af deres job.
• •Ingen plan for fejl: alle vidste, at AI'en ville tage fejl af og til, men ingen havde besluttet, hvem der opdager det, og hvad der så skal ske.

Hvordan vælger I den rigtige proces at teste på?

Valget af proces afgør pilotens skæbne, før den starter. Vi ser ofte virksomheder vælge deres mest komplekse proces, fordi det er der, frustrationen er størst. Det er forståeligt og forkert: komplekse processer har flest undtagelser, flest systemer involveret og flest mennesker, der skal ændre vaner. Alt det, der kan slå en pilot ihjel, er til stede fra dag ét.

Vælg i stedet efter fire kriterier. Volumen, så effekten kan ses i tallene efter få uger. Lav konsekvens ved fejl, så AI'en kan arbejde, mens tilliden bygges op. Målbarhed, så der findes et før-tal at holde resultatet op imod. Og en ejer i driften, der selv vil have løsningen, ikke har fået den tildelt.

Zignifikant er et godt eksempel på et velvalgt udgangspunkt: én afgrænset, tilbagevendende opgave, der levede i et komplekst Excel-regneark. Værktøjet blev bygget på en dag, og effekten kunne gøres op med det samme. Kunden opgjorde selv besparelsen til cirka 50 timers manuelt arbejde hvert kvartal.

Hvad skal en pilot bevise?

En pilot skal bevise tre ting: at løsningen virker på jeres rigtige opgaver, at effekten kan måles mod en baseline, og at der findes en realistisk vej til drift i jeres egne systemer med godkendelser, logning og et menneske de rigtige steder.

Derfor kører en seriøs pilot altid på rigtige opgaver med rigtige data. Konstruerede eksempler giver konstruerede resultater. Og derfor starter den med en baseline: en simpel opgørelse af timer, fejl og gennemløbstid, som resultatet kan holdes op imod.

Hvor længe skal en pilot køre?

Kortere end de fleste tror. En pilot, der kører i ni måneder, er ikke en pilot; det er drift uden ejerskab og uden beslutning. Formålet er et beslutningsgrundlag, og det kan i de fleste processer produceres på to til fire ugers reel drift på rigtige opgaver, plus tiden til at sætte baseline før start.

Timeboksen er ikke bare projektdisciplin. Den tvinger de rigtige samtaler frem tidligt: hvad måler vi, hvem ejer løsningen, og hvad skal tallene vise? Kan de spørgsmål ikke besvares inden start, flytter en længere pilot ikke noget. Den udskyder bare beslutningen.

Hvad gør I, når AI'en tager fejl?

Den vil tage fejl. Sprogmodeller formulerer sig lige så overbevisende, når de tager fejl, som når de har ret, og derfor er fejlhåndtering ikke et appendiks til piloten. Det er en del af det, den skal bevise. En pilot uden fejlplan tester kun solskinsscenariet, og drift består ikke af solskin.

Planen behøver ikke være kompliceret: beslut hvem der laver stikprøver og hvor ofte, hvilke opgavetyper der altid skal forbi et menneske, og hvordan en fejl meldes tilbage, så den ikke gentages. Mål løsningsraten: hvor stor en andel klarer AI'en korrekt uden hjælp? Det tal er ofte vigtigere end hastigheden, for det afgør, hvor meget kontrolarbejde driften reelt kræver.

Princippet er konsekvens-styret kontrol: det rutineprægede kører automatisk, mens beslutninger med reel nedside altid har et menneske i flowet. En pilot, der viser, hvor grænsen skal ligge i netop jeres proces, har leveret noget af det mest værdifulde, den kan.

Hvordan ser en pilot ud, der overlever?

Hos FlowNordics ligger piloten som fase to i et fast forløb på seks uger: kortlægning, pilot, implementering og forankring. Kortlægningen finder de processer, hvor AI flytter mest med mindst risiko, og sætter baseline. Piloten tester på rigtige opgaver. Implementeringen bygger løsningen ind i de systemer, I allerede bruger. Forankringen sikrer, at den lever videre uden os.

Forankring er det trin, der oftest bliver sparet væk, og det er en dyr besparelse. Konkret betyder det, at ejeren i driften kan justere løsningen uden at ringe efter hjælp, at fejlhåndteringen er en del af teamets rutine, og at der findes en side eller et dokument, hvor det står, hvordan løsningen virker, og hvem der gør hvad. Uden det dør løsningen den dag, den første ildsjæl skifter job.

Det afgørende er ikke vores model, men princippet: beslut på forhånd, hvilke tal der udløser et ja. Når piloten er slut, er spørgsmålet ikke, om folk er imponerede, men om tallene holder til at sætte løsningen i drift.

Hvilke tal skal udløse et ja?

Beslut succeskriterierne, før piloten starter, og skriv dem ned. Ikke fordi papir er magisk, men fordi kriterier, der formuleres efter resultatet, altid passer til resultatet. Et beslutningsgrundlag, der er defineret på forhånd, kan sige nej. Det er dét, der gør det troværdigt, når det siger ja.

Fire tal dækker de fleste piloter: timer sparet mod baseline, løsningsrate uden menneskelig hjælp, fejlprocent sammenlignet med den manuelle proces, og faktisk brug. Åbner medarbejderne løsningen, eller arbejder de udenom? Det sidste tal bliver ofte glemt og er alligevel det mest afslørende. En løsning, ingen bruger, har en effekt på nul, uanset hvor god teknologien er.

Og husk, at pris og effekt er to forskellige ting. SYBO Games havde brugt 300.000 kroner på at få bygget et værktøj eksternt uden at nå i mål, før de på én workshopdag selv byggede det, der virkede. Størrelsen på et projekt siger intet om dets værdi. Tallene gør.

Hvad betyder det for jeres næste AI-beslutning?

Stil tre spørgsmål, før I godkender endnu en pilot: Hvad er baseline i dag? Hvem ejer løsningen efter piloten? Og hvilke tal skal den levere, for at vi siger ja til drift? Kan de tre spørgsmål ikke besvares, er projektet en demo, uanset hvad det bliver kaldt.

Regulering peger samme vej. EU's AI-forordning stiller krav om dokumentation og menneskeligt tilsyn for en række anvendelser, og de krav er nemmest at opfylde, når governance er bygget ind fra piloten, ikke skruet på bagefter.

Og husk gevinsten ved at gøre det ordentligt første gang: den anden pilot er altid billigere end den første. Baseline-metoden, fejlplanen og beslutningskriterierne kan genbruges, så hver ny proces, I vil automatisere, starter med en skabelon i stedet for et blankt ark. Det er sådan, AI går fra enkeltprojekter til en arbejdsform.