AI og automatisering er på alles læber, men bag overskrifterne gemmer sig en overraskende barsk virkelighed: Op mod 95% af alle AI-automatiseringsprojekter fejler. Det gælder både i det offentlige og i private virksomheder, hvor store investeringer ofte ender som dyre lærepenge. Hvorfor går det så galt, og hvad kan vi gøre anderledes? Vi dykker ned i de reelle årsager og giver konkrete eksempler og værktøjer, du kan bruge i din organisation.

Den høje fejlraten – og de klassiske forklaringer

Statistikken er chokerende: Ifølge flere analyser, herunder fra Towards AI, lykkes kun omkring 5% af AI-automatiseringsprojekter med at skabe reel forretningsværdi. De fleste forklaringer peger på problemer med data, integration eller teknologi. Det er rigtigt, at dårlige data eller svær integration kan spænde ben, men det er sjældent hele forklaringen. Mange projekter fejler, selv når teknologien er på plads og dataene er tilgængelige.

Den klassiske forklaring lyder ofte sådan: “Vi manglede de rigtige data” eller “Systemerne kunne ikke tale sammen”. Men hvis vi kigger dybere, viser det sig, at de tekniske udfordringer kun er toppen af isbjerget.

Translation Barrier – den usynlige stopklods

Den egentlige hovedårsag til de mange fejlslagne projekter er det, vi kalder Translation Barrier. Det er den barriere, der opstår, når forretningskrav skal oversættes til tekniske specifikationer gennem flere led – fra forretning til IT, videre til udviklere og måske endda eksterne leverandører. Undervejs bliver de oprindelige behov forvansket, fortolket eller glemt.

Forestil dig en kommune, der vil automatisere sagsbehandlingen. Forretningen beskriver et behov for at spare tid og sikre ensartethed. IT-afdelingen oversætter det til krav om et workflow-system, og udviklerne ender med at bygge en løsning, der teknisk set virker – men som ikke passer til sagsbehandlernes daglige arbejdsgange. Resultatet? Løsningen bliver aldrig brugt, og projektet fejler.

Konkrete cases fra praksis

I en større dansk kommune blev der investeret millioner i et AI-baseret sagsbehandlingssystem. Selvom teknologien var lovende, blev løsningen aldrig forankret i praksis. Sagsbehandlerne oplevede, at systemet ikke tog højde for de mange undtagelser i deres arbejde, og de vendte hurtigt tilbage til gamle rutiner. Hvad gik galt? Kravene var ikke blevet oversat korrekt fra forretning til IT – og brugerne var ikke inddraget løbende.

I en stor privat virksomhed forsøgte man at automatisere kundeservice med AI. Projektet strandede, fordi forretningskravene blev fortolket forskelligt af IT og leverandøren. Kunden ønskede personlig betjening, men løsningen blev for rigid og automatiseret. Igen: Translation Barrier var den egentlige synder.

Hvad kunne man have gjort anderledes?

I begge cases kunne løbende dialog mellem forretning, IT og brugere have afdækket misforståelser tidligt. Iterativ udvikling, hvor prototyper testes i praksis, kan afsløre fejl og mangler, før de bliver dyre at rette. Og vigtigst: En klar metode til at oversætte forretningsbehov til tekniske krav – og tilbage igen – er afgørende.

Sådan nedbryder du Translation Barrier

Hvordan bygger man bro mellem forretning og IT? Først og fremmest handler det om at skabe fælles forståelse og sprog. Her er nogle konkrete værktøjer og metoder, vi hos Snilld anbefaler:

• Brug tjeklister til kravhåndtering, hvor både forretning og IT skal godkende hvert punkt.
• Indfør tværfaglige workshops, hvor brugere, forretning og udviklere arbejder sammen om at beskrive behov og løsninger.
• Arbejd med prototyper og mockups, så alle kan se og afprøve løsningen tidligt i forløbet.

Et simpelt framework til kravoversættelse

Vi anbefaler et simpelt framework baseret på tre trin:

• 1. Forretningskrav beskrives i dagligdags sprog af dem, der skal bruge løsningen.
• 2. IT oversætter kravene til tekniske specifikationer – men vender altid tilbage til forretningen for at få dem valideret.
• 3. Prototyper testes af brugerne, og feedback bruges til at justere både krav og løsninger.

Anbefalinger og best practices

For at undgå de klassiske faldgruber anbefaler vi:

• Arbejd iterativt og test løbende – vent ikke til alt er færdigt.
• Inddrag brugerne fra start til slut.
• Prioritér tværfaglige teams, hvor både forretning og IT er repræsenteret.
• Vælg arkitekturer, der gør det let at justere og udvide løsningen.

Arkitekturmæssige valg der gør en forskel

Tværfaglige teams og løbende validering er ikke bare buzzwords. De er afgørende for at sikre, at løsningen faktisk løser det problem, den er sat i verden for. Prototyper og MVP’er (Minimum Viable Products) gør det muligt at lære hurtigt og justere kursen undervejs, så man undgår dyre fejlinvesteringer.

Perspektiv: Hvordan Snilld kan hjælpe

Hos Snilld har vi specialiseret os i at bygge bro over Translation Barrier. Vi hjælper både offentlige og private organisationer med at facilitere dialogen mellem forretning og IT, udvikle klare krav og sikre løbende validering. Vores erfaring viser, at selv små ændringer i processen kan øge succesraten markant.

Vi opfordrer til dialog og videndeling i branchen. Del dine erfaringer, og lad os sammen gøre AI-automatisering til en succes – ikke bare et dyrt eksperiment.

Kilder:

• https://towardsai.net/p/machine-learning/why-95-of-ai-automation-projects-fail
• https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/
• https://pub.towardsai.net/
• https://towardsai.net/
• https://towardsai.net/p/artificial-intelligence/differences-between-ai-and-machine-learning-1255b182fc6
• https://rtslabs.com/ai-debt-collection/

Målgruppens mening om artiklen

Anders Møller, IT-chef i mellemstor kommune:
Jeg giver artiklen 85. Jeg synes, den rammer plet i forhold til de udfordringer, vi oplever med AI og automatisering i det offentlige. Translation Barrier er spot on – det er præcis dér, vi ofte fejler. Jeg savner dog endnu flere konkrete eksempler fra det offentlige, men artiklen er meget relevant og praktisk anvendelig.

Camilla Jensen, Digitaliseringskonsulent i region:
Jeg vil give artiklen 90. Den forklarer meget klart, hvorfor så mange projekter går galt, og jeg kan genkende problematikken med, at forretning og IT taler forbi hinanden. Jeg kan bruge anbefalingerne direkte i mit arbejde. Det trækker lidt ned, at det også er en reklame for Snilld, men indholdet er stærkt.

Michael Sørensen, IT-projektleder i stor privat virksomhed:
Jeg giver den 80. Artiklen er meget relevant for os, især pointerne om løbende brugerinddragelse og prototyper. Det er dog ikke nyt for mig, og jeg kunne godt tænke mig flere konkrete værktøjer. Men den rammer hovedet på sømmet med Translation Barrier.

Louise Frederiksen, Sektionsleder, offentlig sagsbehandling:
Jeg giver den 75. Jeg synes, artiklen beskriver vores udfordringer godt, især med implementering af nye systemer. Men jeg savner mere om, hvordan man konkret får medarbejderne med, og hvordan man håndterer modstand mod forandring.

Jonas Hald, Udvikler i IT-virksomhed:
Jeg giver artiklen 70. Den er relevant, men lidt for overfladisk på de tekniske aspekter. Jeg savner mere dybde om, hvordan man rent faktisk oversætter kravene, og hvilke tekniske metoder der virker bedst. Men den sætter fokus på et vigtigt problem.

*Denne artiklen er skrevet af en redaktion bestående af kunstig intelligenser, der har skrevet artiklen på baggrund af automatiseret research og oplysninger om de seneste teknologi nyheder fra internettet.

Billederne i artiklen er lavet af FLUX.1.1 Pro fra Black Forest Labs.