Lad os være ærlige: De fleste AI‑projekter vælter ikke på grund af én stor fejl, men på grund af hundrede små. MITs 2025‑undersøgelse, citeret af Forbes, peger på, at 95 procent af GenAI‑piloter ikke bliver til værdi i produktion, og S&P Global Market Intelligence registrerer, at 42 procent af virksomhederne skrottede flere AI‑initiativer i 2025, op fra 17 procent året før. Det er ikke et PR‑problem; det er et drift‑problem. Og kernen er en form for teknisk gæld, der er svær at se, svær at måle og dyr at ignorere.
VentureBeat rammer hovedet på sømmet: AI lægger nye lag af teknisk gæld på tværs af prompts, modeller og dataafhængigheder, hvor fejltilstande er subtile og ofte ikke‑lineære. Det matcher det, vi ser hos både store og mellemstore kunder. Små ændringer i en prompt, et par dublerede PDF’er i datalageret, en modelopdatering fra leverandøren uden changelog—og så forsvinder reproducérbarheden, og supporten får travlt om natten.
Hvad mener vi med AI‑gæld
AI‑gæld dækker over risikoen, der akkumuleres, når prompts, modeller, retrieval‑lag og evaluering lever deres eget liv uden entydig struktur. VentureBeat beskriver især tre former i vækst: prompt debt, retrieval debt og evaluation debt, med en beslægtet dimension i model dependency debt. Pointen er ikke ny kode kontra gammel kode; pointen er, at det nye lag er mere levende, mere stokastisk og sværere at fange med traditionel test.
Prompt debt er den moderne udgave af spaghetti: uloggede prompt‑rettelser, hurtige nødløsninger, manglende versionskontrol og prompt stuffing, hvor alt for meget kontekst presses direkte ind i prompten. Retrieval debt opstår, når RAG‑laget trækker fra rodede, dublerede eller forældede kilder og derfor leverer svar, som var rigtige i går, men ikke i dag. Evaluation debt er fraværet af faste målesystemer, ground‑truth‑datasæt og driftsnær overvågning; der er ingen CI for prompts, som VentureBeat påpeger—et hul, der kun vokser ved skalering.
Model dependency debt er så den stille fætter: afhængigheden af eksterne grundmodeller, som ændrer sig uden for jeres kontrol. En opdatering kan skifte temperatur, tokenisering eller systemadfærd, og pludselig performer en nøje tunet prompt dårligere. Det opdager man ofte først, når en leder spørger, hvorfor KPI’en faldt tolv procent i sidste uge.
Hvorfor det skader mere end klassisk teknisk gæld
I klassisk software er fejl ofte deterministiske: man kan genskabe dem. AI opfører sig probabilistisk, så fejl er intermittent og afhænger af små variationer i input, modelversion eller retrieval‑orden. Konsekvensen er kedelig, men klar: test dækker mindre, og drift kræver mere overvågning.
Ikke‑lineære fejl slår hul i QA. En prompt, der virkede fint med 100 testcases, kan falde igennem, når retrieval serverer en forældet kontraktskabelon fra et arkiv på et andet sprog. Den type fejl opstår ikke konsistent, og derfor er sporingen svær uden observability, der binder input, model, retrieval og output sammen. Vi har set, at en enkel ændring i chunk‑størrelse i en vector‑store flyttede fejlmønstret fra “aldrig” til “indimellem—nok til at gøre ondt”.
Det stiller nye krav i drift: kontinuerlig monitorering, datadrift‑alarmer, løbende replay af virkelige samtaler og en praksis for hurtig rollback af prompts og retrieval‑pipelines. Klassisk staging alene rækker ikke. Man skal kunne forklare afvigelser ugen efter—ikke i en retrospektiv tre måneder senere.
Hvad tallene siger om omfanget
MIT‑studiet, rapporteret af Forbes, estimerer, at kun fem procent af GenAI‑piloter reelt bliver til værdi. Vi har forsøgt at krydstjekke metodikken; Forbes gengiver resultaterne og pointerer forskellen mellem trivielle chatbots og tilpassede værktøjer i arbejdsprocesser. Uden fuld adgang til MITs rådata bør tallet læses med et gran salt, men retningen stemmer med, hvad store virksomheder melder til os uofficielt: vejen fra pilot til produktion er stejlt stigende.
S&P Global Market Intelligence, refereret i VentureBeat, angiver, at 42 procent skrottede flere AI‑initiativer i 2025, en markant stigning fra 17 procent året før. Metodevalg betyder noget—stikprøve, brancher, definitionen af “skrottet”—men springet er svært at bortforklare. Det lugter af AI‑gæld, der indhenter projekterne, når de rammer drift.
Prompt debt i praksis
Vi har set det på tæt hold i to kundecases det sidste halve år, én i finans og én i retail. Prompt‑ændringer blev skubbet direkte til produktion som “hurtige forbedringer” uden versionskontrol. Da en modelopdatering ændrede tokenisering, begyndte en navngivningsregel at glide, og supporten fik en drypvis strøm af sager, som ikke kunne genskabes. På tavlen stod der længe: “fejlen lugter af prompt—men hvor og hvornår?”.
Et andet klassisk spor er prompt stuffing. Når man ikke får styr på retrieval‑laget, ryger alt ned i prompten: lange politikdokumenter, hele FAQ’er, sikkerhedsnoter. Det gør modellen langsommere, dyrere og mere følsom over for små skift i input. Så opstår en grim cirkel, hvor man justerer på output‑instruktioner for at lappe et dataproblem, der egentlig ligger før prompten. Vi endte med at fjerne omkring 40 procent af promptens “kloge” regler i en pilot, da retrieval blev renset op.
Løsningen er jordnær: behandl prompts som kode. Versionskontrol, peer review, short‑lived feature branches og en changelog, der kobler til incidents. I en anonymiseret pilot så vi cirka 30 procent færre support‑tickets efter, at vi indførte simpel prompt‑versionering og daglig driftsmonitorering. Det er anekdotisk, ja—men mærkbart i hverdagen.
Retrieval debt og datakvalitet
RAG bygger på, at dokumenter, noter og tabeller gøres søgbare som embeddings. Hvis kilden er rodet, får du pæne, men forældede svar. Det er ikke hallucination—det er korrekt, men uaktuelt—og derfor ekstra farligt i compliance. En pensionssats fra sidste år er stadig en flot sætning, men den er forkert i dag. Testteams går ofte forbi den slags, fordi svaret ser plausibelt ud.
Praktisk betyder retrieval debt, at I må indføre datakvalitetsrutiner foran vector‑store: dubletkontrol, dokumentlivscyklus, metadata for version og ophavsret, og et sted at smide ting ud med god samvittighed. Ellers æder man sin egen hale: udviklere lapper på prompts, mens kundeservice manuelt må dobbelttjekke svar. Pludselig flytter dyr arbejdstid fra produkt til data‑rens.
Compliance‑risici er ikke teoretiske. Trækker RAG fra forældede PII‑kilder uden clear consent eller fra systemer uden audit‑spor, rammer I hurtigt GDPR‑problemer og revisionsspørgsmål. Governance skal være kedelig og konkret: hvilke kilder må bruges, hvornår, og hvordan må det logges.
Evaluation debt: måling og governance
Uden baseline‑suite og klar ansvarslinje for modeladfærd akkumulerer risikoen sig stille. Små regressioner går ubemærket hen, indtil en kunderejse vælter. Vi savner ofte tre ting hos nye kunder: faste eval‑datasæt, løbende model‑ og retrieval‑telemetri og en ejer, der kan sige ja eller nej til en ændring i produktionsprompten.
Vil man i gang i morgen, så start simpelt: definer 50–200 repræsentative cases; mål nøjagtighed, retursvarstid og “did we hit the right source”. Log model‑ og retrieval‑version i hver hændelse. Opsæt vagtplan for alarmer på drift—ikke kun for nedetid, men for performance‑drift. KPI’er, der kan bruges: svarrigtighed på ground truth, kildedækning, escaped PII‑forekomster og andelen af manuelle eskalationer pr. 1.000 forespørgsler.
En konkret case fra feltet: TencentDB Agent Memory
Tencent har open‑sourcet TencentDB Agent Memory, et agent‑hukommelsessystem under MIT‑licens, som adresserer kontekstophobning og glemsomhed i langvarige agenter. Ifølge MarkTechPost bruger det en lagdelt arkitektur med symbolsk korttidshukommelse og lagdelt langtidshukommelse og kører som standard på lokal SQLite med sqlite‑vec, så man undgår eksterne API‑kald. Integrationen nævner OpenClaw og Hermes‑agenten via adaptere. Vi har søgt efter et offentligt repo for at krydstjekke detaljerne; hvis det findes, bør licens og integrationer bekræftes direkte ved kilden, da sekundær dækning kan halte efter.
Hvorfor er det relevant? Fordi det viser en praktisk vej ud af visse former for prompt‑ og retrieval‑gæld: lagdelt hukommelse, der strukturerer fakta, scenarier og personaer, så man ikke tvinger hele fortiden ind i hver prompt. Lokale backends giver bedre kontrol over latency og data—men også et driftsansvar. Det er ikke magi, og det skalerer ikke af sig selv, men det giver enterprise‑teams et håndtag på en ellers flydende hukommelse.
Hvad vi anbefaler—praktiske prioriteter
Start med et kort, brutalt AI‑gælds‑review. Kortlæg prompts, retrieval‑kilder, modelafhængigheder og eval‑rutiner. Brug farvekoder, hvis det hjælper—bare I ikke ender i powerpoint‑pynt. Få tre ugers backlog ud af det, og beslut hvad der ikke skal fikses før Q4. Det føles hårdt, men klarhed er billigere end nattens incident.
Indfør versionskontrol for prompts og konfigurationer. Git, navnekonventioner, labels der binder til incidents. Et lille eval‑suite i CI, der afviser uventede regressioner. Tilføj observability på tværs af pipeline: log model‑version, temperatur, top‑p, embeddings‑model, dokument‑ID’er og kildekæder. Brug feature‑flags til hurtig rollback—ikke heltearbejde i produktion fredag aften.
Rens retrieval‑laget. Byg en simpel dokumentlivscyklus, meta‑felter for gyldighedsdato og deduplikering før ingestion. Overvej lokale eller hybride memory‑/vector‑stores for følsomt indhold, og lav klare regler for, hvad der må bo hvor. Og vigtigst: udpeg en ansvarlig model‑ejer pr. domæne, som kan sige stop. Governance bør være kedelig på den gode måde.
Tradeoffs, begrænsninger og modargumenter
“Det lyder dyrt,” siger skeptikeren. Ja, MLOps koster. Men at lade AI‑gæld akkumulere koster mere i form af support, tabte kunder og frosne releases. Vi anbefaler at afsætte 20–30 procent af startbudgettet til drift, datakvalitet og evaluering frem for kun modellicenser. Det er bremserne på bilen—uden dem ser demoen flot ud, indtil man rammer svinget.
“Friction sænker farten,” hører vi også. Rigtigt—lidt. Men VentureBeat og Forbes’ læsning af MIT‑studiet peger netop på, at friktion i form af governance og måling korrelerer med, at man faktisk overlever pilotkløften. En anden bekymring er vendor lock‑in fra for meget styring omkring én platform. Det kan minimeres med åbne formater, løse koblinger og ved at logge nok signaler til at skifte model uden at miste historik. Lokale hukommelser som TencentDB Agent Memory giver kontrol, men flytter driftsansvar hjem. Man kan ikke få både nul ansvar og fuld kontrol.
Handlingsliste for ledelsen
Næste to uger: udpeg model‑ejere, aktiver versionskontrol for prompts, og definér et minimums‑evalsæt på 50 cases. Sæt logging af model‑ og retrieval‑parametre i produktion—også hvis det gør lidt ondt. Saml prompt‑ændringer to gange om ugen i stedet for løbende; det giver færre skjulte regressioner.
Næste kvartal: gennemfør et AI‑gælds‑kort, prioriter top‑5 risici, og ryd op i retrieval‑kilder med dublet‑ og forældelsespolitik. Etabler en observability‑pipeline med alarmer for performance‑drift og PII‑læk. Overvej lokal memory‑komponent der, hvor latency og kontrol trumfer skalerbarhed—men gør det bevidst: hvem pager, når disken er fuld? Budgettér 20–30 procent til drift og datakvalitet, før I køber endnu en modellicens.
Det her er måske lidt niche, men jeg kan stadig høre klikket fra en svag loftsventilator i det mødelokale, hvor vi opdagede, at én glemt PDF fra 2022 smadrede en hel uge med metrics. AI‑gæld er kedelig, lavpraktisk og helt afgørende. Man mærker først forskellen, når man har fået den ud af systemet.
