Hvorfor Enterprise AI går i stykker efter deployment – og hvad du kan gøre ved det

Advarsel: Problemet er ikke modellen

I 2023 lancerede New York City chatbot’en MyCity for at hjælpe virksomheder med at navigere i komplekse regler. Idéen var simpel: gøre det lettere at få adgang til juridisk information.

I praksis producerede systemet svar, der ikke blot var forkerte, men også juridisk misvisende – fra tipregler til boligdiskrimination til betalingslove.

En senere revision fandt, at 71,4% af brugerfeedback var negativt. I stedet for at løse de underliggende problemer var svaret at tilføje advarsler. Chatbot’en forblev endda i “beta”-version i over to år, før den blev lukket ned.

Fejlen var ikke teknisk. Systemet brød sammen i produktion, fordi der ikke var nogen mekanisme til at sikre nøjagtighed, ingen klar ansvarlig og ingen måde at gribe ind, når noget gik galt.

Det er mønsteret bag enterprise AI i dag: teknologien fungerer, men organisationer er ikke klar til at operere den pålideligt, når den er live.

Fra pilot til produktion: Hvor det hele går galt

At bygge en pilot er ret simpelt – vælg en brugsøjne, vælg en model, forbered data, find en sponsor. At køre et system i produktion er en helt anden liga.

Afvigelsen er som forskellen på at springe i en pool og springe fra stratosfæren, som Felix Baumgartner gjorde i 2012. Samme grundlæggende fysik, helt forskellige betingelser – og meget forskellige konsekvenser for fejl.

I produktion kommer AI ind i rigtige beslutningsprocesser, interagerer med kunder og skaber juridiske og operative konsekvenser. Det er der, hvor huller begynder at dukke op – ikke i modellen, men i, hvordan den styres.

Europa gør dette synligt tidligere end de fleste regioner. Regler som EU’s AI-forordning, GDPR og NIS2 sænker ikke antallet af adoptioner – de afslører, om organisationer kan operere AI-systemer under rigtige begrænsninger.

I 2025 var 55% af de store EU-virksomheder allerede i gang med at bruge AI. Adoptionen sker allerede i stor målestok. Udfordringen er, hvad der sker efter deployment.

På det tidspunkt begynder grundlæggende operationelle spørgsmål at dukke op. Og ofte kan ingen svare på dem: Hvem er ansvarlig for AI-udgang og autonome beslutninger? Hvad sker, når systemet opfører sig på uventede måder? Og hvem vil fange det, før skaden når medierne?

Ansvarlig hedder virksomheden, ikke teknologien. Air Canadas chatbot gav en kunde forkert information om sørgefri priser. Kunden stolede på det og blev senere afvist en refusion. En tribunal fastslog, at flyselskabet var ansvarligt – chatbot’en var ikke en separat enhed.

Samme problem, forskellig vinkel: McDonald’s McHire-system afslørede følsomme data fra næsten 64.000 ansøgere. Årsagen var ikke et sofistikeret angreb – admin-login brugte “admin” og “123456”. Systemet så avanceret ud. Fejlen var elementær.

Når du tilføjer styring til et live-system, er det allerede for sent. At deployere et system er en teknisk beslutning. At operere det pålideligt er en organisationsmæssig beslutning. Og det er den del, som de fleste virksomheder undervurderer.

Hvem ejer egentlig AI-risikoen? Ingen.

Dette er kernen i problemet og paradoksalt det, der diskuteres mindst. IT-styrer infrastruktur. Juridisk håndterer overholdelse. Forretningsholdene skynder sig at bruge AI. Men ingen ejer AI-risikoen fra ende til anden.

Det skaber to umiddelbare problemer. “Go”-beslutningen langsommere – fordi ingen vil tage ansvar. Og “stop”-beslutningen langsommere – fordi ingen ved, hvem der kan.

Data viser det. Færre end 10% af AI-brugsøjner når fra pilot til produktion, og de fleste organisationer kæmper med at skabe målbart forretningsudbytte. Samtidig er mange allerede i gang med at deployere AI – men ifølge en styringsmodningsundersøgelse havde kun 7% en velstruktureret og konsekvent anvendt styring på plads.

Hvorfor sker dette så konsekvent? Fordi de fleste rammer og virksomhedsregler definerer, hvad der skal ske – ikke hvem der er ansvarlig, når det kommer til stykket. Når et system begynder at producere forkerte udgang, er spørgsmålet ikke teoretisk. Hvem handler? Og hvem har myndighed til at træffe beslutninger?

Dette bliver kun værre med skala. Et system kan håndteres uformelt. Når du har tredive, fragmenteres ansvar over hold, og ingen har det fulde overblik.

Commonwealth Bank of Australia giver et klart eksempel. Banken erstattede 45 kundeservicearbejdere med AI-voice-bots, forventede, at efterspørgslen ville falde. Den gjorde ikke. Opringninger øgede, chefer trådte til for at håndtere overskuddet, og banken måtte genansætte alle 45 ansatte. Når de blev udfordret, kunne de ikke demonstrere, at automatisering havde reduceret arbejdsmængden.

Ingen havde valideret antagelserne, før de blev deployet. Ingen ejede udfaldet, når antagelserne fejlede. Det er, hvad en ansvars-vakuum ser ud i praksis.

At have regler er ikke nok. Du har brug for en mekanisme

De fleste organisationer mangler ikke politikker. De mangler systemer, der fungerer, når noget går galt.

En politik definerer, hvad der skal ske. En mekanisme bestemmer, hvad der faktisk sker – når en model producerer forkerte udgang, når en leverandør ændrer noget i baggrunden eller når et system begynder at opføre sig på uventede måder.

Den forskel bliver synlig i produktion – når beslutninger skal træffes under rigtige betingelser.

Disse fejl følger en konsekvent dynamik. I hvert tilfælde dukker de samme operationelle huller op – blot i forskellige former.

Ejerskab kommer først

Hvert deployet AI-system har brug for en tydelig ansvarlig ejer – en person, ikke et hold eller en afdeling, med myndighed til at godkende, pausere og lukke det ned.

Uden det er det hverken muligt at deployere hurtigt eller gribe ind sikkert. Som set i Commonwealth Bank-eksemplet fører manglen på tydeligt ejerskab direkte til operationel fejl.

Data og juridisk klarhed mangler ofte

Mange systemer går live uden dokumenterede datastrømme, en verificeret juridisk basis eller klarhed om, hvilke forpligtelser gælder, når systemet er i produktion.

Den italienske tilsynsmyndigheds handling mod DeepSeek i 2025 illustrerer dette tydeligt. Problemet var ikke modelkvalitet – det var udeevnen til at forklare, hvordan persondata blev behandlet. Resultatet var en pludselig tjenesteforsinkel for europæiske brugere.

Testning reflekterer sjældent rigtig verden

Systemer evalueres ofte på scenarier, hvor de fungerer godt, men ikke på tilfælde, hvor fejl ville have betydning.

MyCity-chatbot’en er et klart eksempel. Grundlæggende edge-cases – omkring arbejdslov, boligdiskrimination eller betalingsregler – blev ikke fanget, før deployment. Når de blev udsat for rigtige brugere, blev fejlene offentlige med det samme.

Testning handler ikke kun om ydeevne – det handler om at identificere, hvor systemet fejler, før brugere, tilsynsmyndigheder eller journalister gør.

Indgreb er uklart eller for langsomt

Selv når problemer er synlige, er der ofte ingen klar udløser eller myndighed til at pausere eller lukke systemet ned.

Zillow Offers demonstrerer dette i stor målestok. Systemet brugte en algoritme til at prissætte og købe huse. Da markedet kølnede i 2021, fortsatte systemet med at købe til høje priser. Der var ingen mekanisme til at registrere afvigelse i tide, og ingen klar beslutningspunkt til at stoppe det. Resultatet var tab på over 880 millioner dollars og lukningen af hele afdelingen.

Overvågning er ikke ejerskab

Overvågning reduceres ofte til dashboards, men det er ikke, hvad forhindrer fejl.

Det, der betyder noget, er defineret ansvar: Hvem sporer signaler, hvad udløser eskalering, og hvem forventes at handle?

Deloitte Australiens sag viser, hvad der sker, når det mangler. En regeringsrapport indeholdt hallucinerede citater og forkerte juridiske referencer, fordi ingen var udtrykkeligt ansvarlig for at verificere udgang, før levering. Resultatet var en delvis refusion og reputationskade.

Agentic AI: Hvad der kommer, vil være endnu sværere

Generativ AI producerer udgang. Agentic AI tager handling. Det ændrer risikoen helt.

I stedet for et enkelt svar at evaluere kan en enkelt instruksjon udløse en kæde af beslutninger på tværs af systemer – API-kald, dataadgang, transaktioner, opdateringer – ofte uden menneskelig indgriben på hvert trin.

Når noget går galt, er problemet ikke længere nøjagtighed. Det er sporbarehed. Hvilet trin forårsagede problemet? Hvad data blev brugt? Hvem godkendte handlingen? I mange tilfælde er disse spørgsmål svære at besvare efterfølgende.

Det er, hvor eksisterende huller bliver kritiske. Uklart ejerskab, svag overvågning og manglende indgreb persistere ikke blot – de forstærker. En fejlbesked kan korrigeres. En fejlhandling kan skabe konsekvenser, før nogen lægger mærke til det.

Tidlige signaler peger allerede i den retning. Gartner estimerer, at over 40% af agentic AI-projekter vil blive aflyst inden udgangen af 2027 – ikke på grund af modelbegrænsninger, men fordi organisationer kæmper med at kontrollere omkostninger, risici og resultater. Det er samme mønster, vi ser med generativ AI efter deployment. Kun med højere indsats.

Tilsynsmyndighederne reagerer allerede med en simpel princip: Automatisering fjerner ikke ansvar. For organisationer skaber det en klar implikation: Hvis ejerskab og kontrol er uklare i dag, vil skalering til agentic-systemer ikke løse problemet. Det vil forstærke det.

Operér det – eller tab det

AI er ikke længere begrænsningen. Modeller er vidt tilgængelige, kapable og stadig mere kommodificerede. Den virkelige differentiator er ikke, om en organisation kan bygge AI – men om den kan operere det pålideligt, når det er live.

Det er, hvor de fleste fejl sker – i, hvordan systemer køres, ikke i, hvordan de bygges. Organisationerne, der lykkes, vil ikke være dem med de mest avancerede modeller. De vil være dem med de klareste operationelle strukturer omkring dem.

Dette kan testes direkte. Tag dit vigtigste AI-system og besvar tre spørgsmål:

• Hvem kan lukke det ned?
• Hvordan ved du, når det fejler?
• Hvad sker, når det gør?

Hvis disse svar er uklare, er systemet ikke klar til produktion.

Modellen kan være det. Organisationen er det ikke.