AI-pilotprojekter: derfor når de aldrig længere end demoen

Demoen gik forrygende. Der var nik hele vejen rundt om bordet, nogen sagde "det her ændrer alt", og der blev nedsat en arbejdsgruppe. Det er nu et halvt år siden. Spørg dig selv, hvor mange der bruger løsningen i dag.

Det er ikke et særtilfælde. En meget omtalt rapport fra MIT's NANDA-initiativ, offentliggjort i august 2025, satte tallet for generative AI-pilotprojekter uden målbart afkast til omkring 95 procent. Tallet er siden blevet diskuteret grundigt, og metoden bag er bestridt af flere, så brug det ikke som facit. Brug det som det, det er: en indikation af, at spring fra pilot til drift er sværere end spring fra idé til pilot.

Her får du de fem steder, AI-pilotprojekter typisk dør, spørgsmålene der afslører dødsfaldet før det sker, og en fremgangsmåde der gør næste pilot værd at starte.

Demoen tester det forkerte

En demo viser, at teknologien kan. Drift handler om, hvorvidt nogen vil — hver tirsdag, når de har travlt, og den gamle måde stadig virker.

Det er to helt forskellige prøver. Den første kører på udvalgte eksempler, med den mest motiverede medarbejder ved tasterne, og med en, der har bygget løsningen, siddende klar ved siden af. Den anden kører på det rod, virkeligheden leverer: halvt udfyldte felter, undtagelser, en kunde der ringer midt i det hele.

Når et pilotprojekt lykkes og alligevel ikke fører til noget, er det som regel, fordi det bestod den første prøve og aldrig blev udsat for den anden.

De fem steder, pilotprojektet dør

• Opgaven var for lille. I valgte noget ufarligt for at komme i gang. Gevinsten blev tilsvarende ufarlig, og ingen kunne argumentere for at bruge penge på at rulle den ud.
• Ingen ejer den på mandag. Piloten blev drevet af en ildsjæl eller en konsulent. Da projektet sluttede, sluttede ejerskabet også, og løsningen blev hjemløs.
• Den ligger ved siden af arbejdet. Hvis medarbejderen skal åbne et ekstra vindue, logge ind igen og kopiere data frem og tilbage, taber værktøjet mod vanen. Hver gang.
• Kvaliteten blev aldrig defineret. Ingen aftalte, hvad "godt nok" var. Så da den første fejl dukkede op, blev den brugt som bevis på, at løsningen ikke duede.
• Der var ingen tal. I målte ikke, hvor lang tid opgaven tog før. Derfor kunne I heller ikke vise, at den tog kortere tid bagefter.

Læg mærke til, at ingen af de fem handler om modellen. Teknologien er sjældent flaskehalsen længere. Organiseringen er.

De fire spørgsmål, du skal stille før start

Stil dem inden I bygger noget. De tager et kvarter og sparer et halvt år.

Hvem gør det i dag, og hvor lang tid tager det?

Hvis du ikke kan svare med et navn og et tal, har du ikke en opgave, du har en fornemmelse. Mål det i en uge, før I går i gang. Selv et groft estimat fra fem personer er bedre end ingenting.

Hvem ejer løsningen, når piloten er slut?

Ikke hvem der er begejstret. Hvem der har det i sin jobbeskrivelse, sin kalender og sit budget. Kan I ikke pege på en person, så udskyd projektet, til I kan.

Hvad er godt nok?

Skal løsningen ramme rigtigt i ni ud af ti tilfælde? I nitten ud af tyve? Og hvad sker der i de tilfælde, den rammer forkert — hvem opdager det, og hvad koster det? Aftal det skriftligt, før nogen bliver skuffet.

Hvad skal medarbejderen holde op med?

Det er det spørgsmål, flest springer over. Et nyt værktøj, der lægges oven på en fuld kalender, bliver ikke brugt. Hvis I ikke kan sige, hvad der forsvinder, har I ikke frigjort tid. I har tilføjet en opgave.

Agenter hæver både gevinsten og indsatsen

Nyere værktøjer nøjes ikke med at svare. De udfører: henter data, opretter poster, sender udkast videre, følger op. Det flytter gevinsten fra "jeg sparer lidt skrivetid" til "hele trinnet forsvinder".

Men det hæver også kravene. Nu skal du tage stilling til rettigheder, logning, hvem der godkender hvad, og hvad der sker, når noget går skævt klokken 23. Det er ikke svært, men det skal besluttes af nogen, og det skal besluttes før, ikke efter. Vi bruger en stor del af vores kursus i AI-agenter på netop de beslutninger, fordi det er dem, der afgør, om løsningen tåler at komme ud af demoløftet.

Sådan kommer du i gang

Fem trin til den næste pilot. De kræver ingen ny platform.

1. Vælg en opgave, der gør ondt. Noget der tager tid hver uge, som flere laver, og som ingen holder af. Den slags opgaver har både en målbar gevinst og en indbygget ambassadør.
2. Mål nulpunktet i en uge. Antal sager, minutter per sag, antal fejl. Tre tal er nok. Uden dem har du ingen historie at fortælle bagefter.
3. Sæt en slutdato på seks uger. Ikke seks måneder. Korte forløb tvinger jer til at vælge noget lille nok til at lykkes og stort nok til at tælle.
4. Lad dem, der laver opgaven, bygge løsningen. Ikke it alene, og ikke ledelsen. De, der kender undtagelserne, er de eneste, der kan bygge noget, der tåler dem.
5. Beslut på forhånd, hvad der sker bagefter. Skriv de tre udfald ned: udrul, juster og kør seks uger mere, eller stop. Et pilotprojekt, der kun kan ende med succes, er ikke en pilot. Det er en beslutning, der allerede er taget.

Udrulning er forandringsledelse, ikke installation

Når piloten virker, begynder det svære. Nu skal mennesker, der ikke var med, ændre en vane, de har haft i årevis, til fordel for noget de ikke selv har valgt.

Det er ikke et teknisk problem, og det løses ikke med en mail og en vejledning. Det løses med de sædvanlige, kedelige ting, der virker: en tydelig grund, synlig opbakning fra nærmeste leder, tid til at øve sig, og et sted at sige højt at man ikke kan finde ud af det. Er det disciplinen, I mangler, er implementering og forandringsledelse et mere presserende kursus end noget teknisk.

Regn med et dyk

Produktiviteten falder, når folk skifter metode. Det er normalt, og det varer typisk nogle uger. Problemet opstår, når ingen har advaret om det, for så bliver dykket læst som bevis på, at det nye ikke virker. Sig det højt på forhånd, og dykket bliver en forventet omkostning i stedet for en skuffelse.

Det, der faktisk adskiller dem, der lykkes

Det er ikke større budgetter, og det er ikke bedre modeller. Det er, at de behandler AI som en ændring af, hvordan arbejdet gøres — med alt hvad det indebærer af roller, kvalitetskrav og oplæring — i stedet for som et værktøj, der købes ind og deles ud.

Det lyder mindre spændende end demoen. Det er også grunden til, at så få gør det.

Den gode nyhed om små pilotprojekter

Der er en grund til at holde fast, selvom tallene for udrulning ser dystre ud: prisen for at prøve er faldet dramatisk. Et pilotprojekt, der for få år siden krævede udviklere, en server og et halvt års arbejde, kan i dag ofte bygges på en uge af den afdeling, der selv har problemet.

Det ændrer regnestykket. Når et forsøg koster en uge, behøver du ikke ramme rigtigt hver gang. Du har råd til at prøve fem ting og beholde den ene, der virker, og det er en langt sundere strategi end at satse alt på ét stort projekt, der skal godkendes tre steder, før nogen må røre det.

Fælden er bare, at billige forsøg også er nemme at glemme. Fem piloter uden ejerskab er ikke bedre end én. Derfor gælder de samme spørgsmål, uanset hvor lidt det koster at gå i gang.

Næste skridt

Skal jeres næste pilot ende i drift, så start med at vælge den rigtige opgave og den rigtige ejer. Vil I bygge løsninger, der selv tager fat i arbejdet, giver kurset i AI-agenter jer både håndværket og de kontrolpunkter, der skal følge med. Og skal det længere ud end til de første fem entusiaster, så er implementering og forandringsledelse det, der afgør resten.

Start med spørgsmålet om, hvem der ejer det på mandag. Resten følger efter.