Fra AI-pilot til drift: hvorfor prototyper går i stå – og hvad der får dem videre

Det er blevet let at bygge en AI-prototype. På en eftermiddag kan man koble en sprogmodel til nogle dokumenter eller et udtræk fra CRM'et og vise noget, der ser imponerende ud. Det svære kommer bagefter: at få løsningen til at køre hver dag, på rigtige data, i de systemer medarbejderne allerede arbejder i – og med en person, der har ansvaret, når den tager fejl.

Når en pilot går i stå, er det sjældent, fordi modellen er for dårlig. Det er fordi de ting, der ikke var nødvendige for at lave en demo, pludselig bliver nødvendige for at lave en løsning. Her gennemgår vi de fem områder, der oftest bremser overgangen fra pilot til drift, og hvordan I kan tage højde for dem, allerede før piloten starter.

Hvorfor demoen virker, og driften ikke gør

En pilot er bygget til at bevise, at noget kan lade sig gøre. Derfor bliver den typisk lavet med håndplukkede eksempler, et udtræk af data og én ildsjæl, der passer på den. Det er helt fint – men det betyder også, at piloten undgår de spørgsmål, som driften ikke kan undgå:

• Hvad sker der, når data er ufuldstændige, forældede eller i et andet format end forventet?
• Hvem retter fejlene, og hvordan opdager man dem?
• Hvor skal resultatet ende – i en mail, i CRM'et eller i økonomisystemet?
• Hvem betaler for drift, licenser og vedligehold, når projektbudgettet er brugt?

Hvis de spørgsmål først bliver stillet, når piloten er "færdig", starter projektet reelt forfra. Det er dér, mange AI-initiativer stille og roligt dør.

1. Aftal på forhånd, hvad der skal til for at gå videre

En pilot uden succeskriterier ender næsten altid med konklusionen "lovende, men vi skal lige se lidt mere". Beslut derfor, før I går i gang, hvad piloten skal vise for at fortsætte:

• Én konkret opgave, fx at sortere indgående mails, lave kladder til tilbud eller forkontere bilag – ikke "at bruge AI i kundeservice".
• Et målepunkt, I allerede kender, fx tid pr. sag, svartid, fejlrate eller antal manuelle rettelser. Mål udgangspunktet, før piloten starter.
• En tærskel: Hvor god skal løsningen være, før den må hjælpe i hverdagen? Ofte er "rigtig i de fleste tilfælde, og et menneske godkender resten" et fuldt brugbart niveau.
• En dato for beslutningen: fortsæt, justér eller stop.

Det lyder banalt, men det er den vigtigste enkeltfaktor. Når kriterierne er aftalt på forhånd, bliver beslutningen om at gå i drift en konstatering i stedet for en diskussion.

Indsigt: En pilot, der ikke kan fejle, kan heller ikke lykkes. Hvis ingen har defineret, hvad "godt nok" betyder, bliver piloten ved med at være næsten klar.

2. Test på rigtige data – også de besværlige

Demoer bliver lavet på pæne data. Driften kører på det, der faktisk ligger i systemerne: dubletter, felter der er udfyldt forskelligt af forskellige medarbejdere, PDF'er der er scannet skævt, og kunder der hedder tre forskellige ting i CRM, ERP og økonomisystem.

Brug derfor en del af piloten på at køre løsningen på et repræsentativt udsnit af rigtige sager, inklusive de besværlige. Notér, hvor den fejler, og om fejlen skyldes AI'en eller data. Ofte viser det sig, at en stor del af gevinsten ligger i at rydde op i datagrundlaget – en opgave, der gavner meget mere end den ene AI-løsning. Læs mere om, hvordan I får mere værdi ud af eksisterende kundedata.

3. Placér ejerskabet i forretningen

En pilot har ofte en projektleder. En driftsløsning har brug for en ejer: en person i forretningen, der bruger løsningen, ved hvornår den svarer forkert, og har mandat til at prioritere forbedringer. Uden en ejer bliver AI-løsningen et IT-projekt, som ingen i afdelingen føler ansvar for – og som langsomt holder op med at blive brugt.

Afklar også, hvem der må ændre i prompts, regler og opsætning, og hvordan ændringer bliver testet. Det er en lille opgave, men den gør stor forskel, når løsningen har kørt et halvt år. AI-governance handler i praksis meget om netop den slags hverdagsbeslutninger.

4. Byg det ind i de systemer, folk allerede bruger

Den hyppigste grund til, at en god pilot ikke bliver brugt, er, at den kræver et ekstra vindue. Hvis medarbejderne skal kopiere tekst fra CRM'et over i et AI-værktøj og tilbage igen, falder brugen, så snart nyhedens interesse har lagt sig.

Driftsversionen bør derfor arbejde direkte i de systemer, der allerede er hverdagen: forslaget til svar ligger i supportsystemet, kladden til opfølgning ligger på aftalen i CRM'et, og forkonteringen venter i økonomisystemet til godkendelse. Det kræver integrationer, og det er her, en stor del af arbejdet ligger. Se fx de platforme, vi arbejder med, under integrationer til ERP, CRM og økonomi.

5. Planlæg opfølgning og drift fra start

En AI-løsning er ikke færdig, når den er sat i drift. Data ændrer sig, sprogmodeller bliver opdateret, og forretningen begynder at bruge løsningen til ting, ingen havde forudset. Sørg derfor for:

• Logning af input, output og menneskelige rettelser, så I kan se, hvor løsningen fejler.
• Menneskelig godkendelse dér, hvor fejl koster noget – især i starten.
• En fast gennemgang, fx en gang om måneden, hvor ejeren ser på eksempler og beslutter justeringer.
• Et driftsbudget til licenser, forbrug og vedligehold, så løsningen ikke afhænger af et projektbudget, der er brugt op.

Sådan ser en realistisk vej fra pilot til drift ud

Et forløb behøver ikke være stort for at være solidt. Når opgaven er afgrænset, ser rækkefølgen typisk sådan ud:

1. Afklaring: Vælg opgaven, mål udgangspunktet og aftal kriterierne for at gå videre.
2. Pilot på rigtige data: Byg den enkleste version, der kan køre på et udsnit af virkelige sager, og lad et par medarbejdere bruge den.
3. Beslutning: Sammenlign resultatet med kriterierne. Fortsæt, justér eller stop – alle tre er gode udfald.
4. Integration og drift: Flyt løsningen ind i de eksisterende systemer, tilføj logning og godkendelse, og overdrag ejerskabet.
5. Opfølgning: Gennemgå løbende eksempler og effekt, og udvid først, når den første opgave kører stabilt.

Hvor lang tid det tager, afhænger mest af systemerne og datakvaliteten – ikke af AI-delen. Derfor er det en god idé at se på integrationer og data allerede i afklaringen. Læs også vores guide til, hvordan I kommer i gang med AI, og forskellen på AI-rådgivning og AI-implementering.

Hvornår skal man stoppe en pilot?

Det er lige så vigtigt at kunne stoppe som at kunne fortsætte. Stop eller parkér piloten, hvis:

• gevinsten afhænger af data, I ikke har eller ikke må bruge,
• den manuelle kontrol tager lige så lang tid som at løse opgaven selv,
• ingen i forretningen vil eje løsningen, eller
• opgaven viser sig at være for sjælden til, at det kan betale sig at automatisere den.

En stoppet pilot er ikke spildt, hvis I har lært, hvor gevinsten faktisk ligger. Det vigtigste er, at beslutningen bliver truffet – i stedet for at piloten bliver ved med at være "næsten klar".