Hvad et AI-proof of concept på fire uger skal bevise, før I skalerer

Et proof of concept, der imponerer i en demo, kan stadig være det forkerte at skalere. Modellen klarer eksempelsagerne, mødelokalet er overbevist, og et par måneder senere er projektet stille og roligt gået i stå. Gartner oplyste i januar 2026, at mindst halvdelen af alle projekter med generativ AI ved udgangen af 2025 var blevet opgivet efter proof of concept, på grund af dårlig datakvalitet, utilstrækkelig risikostyring, stigende omkostninger eller uklar forretningsværdi.

Ingen af de grunde handler om, hvorvidt modellen kan løse opgaven. Det er som regel den nemme del. Et godt proof of concept er bygget til at besvare de svære spørgsmål, mens der stadig er lidt på spil. Hvis I stadig er ved at vælge, hvilken proces I vil teste, så start med fem spørgsmål, der vælger den rigtige første automatisering.

En demo er ikke et bevis

En demo viser, at noget er muligt. Et bevis viser, at det virker på jeres data, ved jeres volumen og for de mennesker, der skal bruge det. Forskellen betyder noget, fordi modellen kun er en lille del af et fungerende system. I en kendt artikel om machine learning i drift viste ingeniører fra Google, at modelkoden kun er en lille brøkdel af et rigtigt system, og at infrastrukturen omkring den er omfattende og kompleks.

En test på fire uger skal derfor gøre mere end at spørge, om modellen kan klare opgaven. Den skal køre den smalleste rigtige version af hele forløbet: rigtigt input, der kommer ind, modellen, der udfører sit trin, resultatet, der lander, hvor folk arbejder, og en person, der kan rette det.

Sæt barren før uge ét

En pilot uden en aftalt definition af succes har en tendens til at trække ud, fordi alle resultater kan tolkes forskelligt. Aftal tre ting, før der bygges noget.

• Et testsæt med rigtige sager. Saml historiske eksempler med kendt korrekt resultat, i den blanding I faktisk modtager, også de besværlige. Anthropics vejledning om evalueringer anbefaler testsæt, der afspejler opgavens reelle fordeling og indeholder grænsetilfælde.
• Et udgangspunkt. Mål, hvordan arbejdet udføres i dag: tid pr. sag, fejlrate, svartid. Googles Rules of Machine Learning sætter målinger først og anbefaler at registrere så meget som muligt i det nuværende system, før I fastlægger, hvad det nye skal gøre.
• En tærskel for hvert mål. Skriv ned, hvilket resultat der vil retfærdiggøre en skalering, og hvilket der får jer til at stoppe. Gør hver tærskel konkret og målbar: "den rigtige kategori på rutinehenvendelser og ingen skråsikre fejl på refusioner" frem for "virker godt".

Fem ting, fire uger skal bevise

Hver række nedenfor svarer til en grund til, at piloter senere fejler. Brug tabellen som dagsorden for den afsluttende gennemgang.

Om data: Hvis testsagerne indeholder personoplysninger, gælder GDPR for piloten på samme måde som for drift. Brug kun de data, testen har brug for (princippet om dataminimering i artikel 5), og afklar før uge ét, hvordan I må bruge dem.

Omkostningerne fortjener deres eget tjek. Gartner påpeger, at projekter, der ser levedygtige ud i et proof of concept, kan blive et budgetproblem i drift, fordi små omkostninger pr. brug ganges op over brugere og anvendelser. Mål omkostningen pr. sag under piloten, og læs de reelle omkostninger ved et AI-system for at se, hvad I ellers skal budgettere med.

En plan på fire uger, der giver plads til svaret

Fire uger er nok, når omfanget er én proces og én beslutning. En opbygning, der virker:

1. Uge 1: aftal og indsaml. Fastlæg barren, saml testsættet, skaf adgang til de rigtige data, og udpeg de personer, der skal afprøve systemet.
2. Uge 2: byg den tynde vej. Forbind input, model og output hele vejen igennem, kun for hovedtilfældet. Kør hele testsættet sidst på ugen, også selv om resultaterne er svage.
3. Uge 3: lad brugerne prøve det. Lad teamet bruge det på rigtigt arbejde ved siden af den normale proces, så intet afhænger af det endnu. Registrér hver rettelse, og mål omkostningen pr. sag.
4. Uge 4: ret, kør igen, beslut. Tag fat på de hyppigste fejltyper, kør testsættet igen, og skriv et beslutningsnotat på én side, der holder tallene op mod barren.

Det er netop pointen at køre det samme testsæt i uge to og uge fire. Det gør fremskridt til et tal og forhindrer, at den afsluttende gennemgang bliver en diskussion om indtryk. NIST's AI Risk Management Framework siger, at AI-systemer bør testes før idriftsættelse og jævnligt under drift, og det testsæt, I bygger nu, kan blive regressionstesten for det kørende system.

Skalér, justér eller stop

Ved udgangen af uge fire er der tre ærlige udfald.

• Skalér, når hver række i tabellen er underbygget, barren er nået, og en navngiven person i forretningen ejer resultatet. Næste fase er udviklingsarbejde: integration, overvågning, adgangsstyring og support.
• Justér, når en eller to rækker er svage, og løsningen er klar, for eksempel en manglende datakilde. Aftal en kort forlængelse med en fast slutdato og den samme barre. Justering må ikke blive en permanent tilstand.
• Stop, når kvaliteten er langt fra barren, eller når værdien forsvinder, så snart driftsomkostninger og tid til gennemgang er regnet med. En pilot, der slutter sådan efter fire uger, har gjort sit arbejde: Den har sparet jer for et langt større projekt.

I vores projekter er det de piloter, hvor beslutningsreglerne blev skrevet ned først, der glider nemmest over i drift. Vil I sætte en realistisk barre, så vurder med ROI-beregneren, hvad processen er værd i dag, eller se typiske workflows fordelt på forretningsområder for at finde kandidater, der er værd at teste.