Flere virksomheder finder fejl, når de faktisk begynder at lede efter dem. Det lyder banalt, men her gør det forskellen i driften. I juli-udgaven af VB Pulse-undersøgelsen svarer 68 procent af 101 større virksomheder, at de i løbet af det seneste halve år har sporet et “confident but wrong”-agentsvar tilbage til manglende eller uens forretningskontekst. I juni var tallet 57 procent, ifølge VentureBeat. Samtidig melder flere, at de har et styret kontekstlag i produktion – andelen steg fra 25 til 32 procent på en måned.
Det strider mod intuitionen. Man bygger et governed context layer for at reducere fejl. Alligevel stiger andelen, der rapporterer fejl, når sådan et lag rulles ud. VentureBeat anfører, at virksomheder med – eller på vej mod – et styret lag rapporterer den tilbagevendende fejl mere end dobbelt så ofte som dem uden. Ikke fordi laget skaber fejlen, men fordi det gør den synlig: der opstår et fælles referencepunkt, så man kan se præcis, hvor definitionen knækkede.
Hvorfor det overrasker
Mange forestiller sig governance som en sikkerhedssele: klik – og færre problemer. I praksis gør governance afvigelser målbare. Når definitioner, kilder og adgangsregler bliver eksplicitte, er fejl ikke længere diffuse “modellens hallucination”. De kan spores til en forældet tabel, en forkert term, en tvetydig KPI-definition. Det er godt – men det føles som flere fejl, fordi de nu tælles.
Hvem er spurgt – og hvor sikre er tallene
VB Pulse-tallene stammer fra 101 kvalificerede virksomheder med over 100 ansatte. Det er mere end anekdoter og gentaget fra juni til juli, så trendlinjen er brugbar. Men det er selvrapportering, og stikprøven er ikke stor. Læs det som retning, ikke dom.
Der er også indbygget skævhed. Teams, der har investeret i governance og observability, opdager – og rapporterer – flere fejl. Det er pointen. Derfor kan springet fra 57 til 68 procent lige så vel være et tegn på modenhed i måling som på, at agenter faktisk fejler oftere.
Hvordan virksomheder giver kontekst
Undersøgelsen viser, at retrieval over dokumenter er den primære kilde til kontekst for 31 procent af virksomhederne. Den klassiske vej: split dokumenter i bidder, lav embeddings, hent relevante passager, og lad modellen svare med citater. Det virker ofte – men kræver disciplin omkring kvalitet og versionering.
13 procent læsser lange dokumenter direkte ind i modellens kontekst frem for at hente dem ved behov. Og 5 procent kører uden struktureret kontekst overhovedet. Næsten én ud af fem ligger altså i “brute force” long-context eller intet lag. Ikke nødvendigvis forkert, men skrøbeligt, når regler og tabeller flytter sig fra uge til uge.
Hvorfor retrieval også kan ramme ved siden af
Fejlene opstår typisk, når KPI’er, finansielle termer eller policys har små, men afgørende forskelle. “Opkrævningsdato” kan betyde én ting i faktureringssystemet og noget andet i ERP’en. Retrieval finder begge – og blander dem. Uden en valideringspipeline, der tjekker logik og tidsstempler, ser svaret pænt ud. Indtil man bogfører.
Harness-laget kort og nøgternt
MarkTechPost beskriver DeepSeek Harness i developer preview som et lag mellem model og miljø – værktøjer, filer, sandboxes og en kontrolsløjfe, der holder agenten kørende. Kernen er arkitekturen: “everything is a plugin”. Modeller, værktøjer, sessioner, lagring, løkker – alt kan byttes via konfiguration. Det er ikke en færdig enterprise-agent, men infrastruktur, MIT-licenseret og selvhostet i v0.1.
Relevansen er arkitektursignalet: et bevægeligt harness gør det lettere at eksperimentere med retrieval, permissioning og audit uden at skifte hele agenten ud. For store it-miljøer, der allerede drifter interne værktøjer, kan den modulære tilgang være den praktiske vej til at forbedre kontekstlaget trin for trin – og rulle tilbage, når noget går galt.
Hvad betyder det for driften
Fire implikationer stikker ud. For det første overvågning og metrikker: uden faste tal for correctness-rate, retrieval-accuracy og provenance-dækning ender man i mavefornemmelser. Det skalerer dårligt. For det andet valideringspipelines, der kombinerer syntetiske scenarier (kendte fælder) med feltdata. Ingen af delene kan stå alene.
For det tredje indkøb og prioritering: surveyen viser, at adgangskontrol og dataintegration vægter højt ved køb af retrieval – 24 procent hver – mens retrieval-accuracy kun vægter 15 procent. Det er et faresignal, fordi den egenskab, der mest direkte påvirker forkerte svar, underprioriteres i købsprocessen. Endelig skal der være klare rollback- og menneske-i-løkken-regler. Ikke som pynt, men som drift: hvornår skifter agenten mode, hvem godkender ændringer, og hvordan dokumenteres det.
Designprincipper for et kontekstlag der holder
Et effektivt kontekstlag har nogle faste byggesten. Versionering af både dokumenter og udtræk, så spørgsmål besvares mod den rigtige tidslinje. Proveniens på hver bid – kilde, stempel, adgangsniveau – så man kan genskabe et svar og se, hvor det skred. Kvalitetsscorer på dokumenter og passager, ikke kun på hele kilder.
Dertil audit logs og sampling til menneskelig gennemgang. Ikke hele strømmen, men klog sampling med tærskler, så high-risk spørgsmål bliver set af et menneske. Og husk: adgangsstyring og kvalitet må ikke modarbejde hinanden. Fine-grained permissioning må ikke klippe de passager væk, som faktisk er nødvendige for et korrekt svar.
Flere fejl i rapporten kan være et sundhedstegn
Stigningen fra 57 til 68 procent ligner forværring. Men den kan lige så vel være et tegn på, at governance og sporbarhed virker. Når der kommer flere klare hændelser i loggen, kan teams lære af dem og rette strukturelt. Forudsætningen er, at man undgår alarmtræthed: for mange notifikationer uden handling, og man holder op med at kigge.
Modgiften er simple, hårde regler: målrettede alarmer kun på hændelser over en aftalt risikoprofil, batch-gennemgang af lavrisiko med sampling, og faste rytmer for at gennemgå “fejl med læringspotentiale”. Ikke alt skal patches i morgen. Noget skal dokumenteres og ind i næste sprint.
Værktøjer og økosystem
DeepSeek Harness er et eksempel på udviklerinfrastruktur – ikke en færdig enterprise-løsning. Det gør det relevant for platformteams, der vil teste nye retrieval-strategier, udskifte embeddings eller ændre kontrolsløjfer uden at rive hele agenten ned. At det er MIT-licenseret og selvhostet, muliggør piloter i regulerede miljøer – men v0.1 er stadig en developer preview, som MarkTechPost pointerer.
Det bredere signal er, at kontekstlaget er ved at blive en selvstændig arkitekturkomponent. Ikke “et par scripts” foran modellen. Når leverandører konkurrerer på explainability i retrieval, bedre provenance og mere udskiftelige værktøjskæder, får slutbrugere flere håndtag at skrue på. Det er nødvendigt, hvis de 68 procent skal ned på den rigtige måde – gennem bedre kvalitet, ikke mindre synlighed.
Prioritering for ledelse og tekniske teams
Helt lavpraktisk: sæt eksplicitte KPI’er for correctness. Eksempler: andel svar med fuld provenance, feltvalideret correctness-rate over high-stakes forespørgsler og fejl pr. 1.000 agentkørsler. Byg testpipelines, der kører ved hver ændring i kontekstindekser, dokumentversioner og prompts – ikke kun ved modelopdateringer. Og lad regressionstests dække edge cases, ikke kun de glade veje.
Hav en klar fallback- og rollback-strategi. Når metadata mangler, når score falder under tærskel, eller når kilder modsiger hinanden, skal agenten skifte mode, begrunde usikkerhed eller eskalere til menneske. Indkøb bør desuden vægte governance-led kriterier uden at tabe retrieval-accuracy: spørg leverandører om dokumenterede målemetoder, ikke kun checkbokse for adgangskontrol.
Mulige modargumenter og usikkerheder
Der er rapporteringsbias: de virksomheder, der har bygget et governed lag, har bedre værktøjer til at opdage og dokumentere fejl. VentureBeat beskriver netop, at blandt dem, der kører eller bygger et styret lag, rapporteres den tilbagevendende fejl langt hyppigere end hos dem uden. Det er mekanismen, der gør governance værdifuld – og som kan forveksles med forværring.
Konsekvenser for leverandører
Når kunder i højere grad måler correctness og provenance, flytter kravene sig. Roadmaps bør dreje mod retrieval-accuracy, forklarbarhed og fine-grained permissions, der ikke klipper mening ud af konteksten. Dertil en developer-first harness-arkitektur, hvor værktøjer, embeddings, vektordatabaser og sløjfer kan skiftes uden omskrivning af hele stakken.
Leverandører, der kan dokumentere testprotokoller for retrieval (fx negative kontroller, kontradiktoriske dokumenter, tidsfølsomme kilder) og eksponere metrikker per svar – ikke kun på systemniveau – står stærkere i næste runde RFP’er. Det er sjældent de pæneste dashboards, der vinder her, men de mest nøgne logfiler.
Et kort, konkret scenarie
Forestil dig et agentforløb i finans. Brugeren spørger, om en kunde er i restance pr. månedsskiftet. I billing-dokumentationen betyder “opkrævningsdato” den dag faktura sendes. I ERP-datamodellen er “opkrævningsdato” lig betalingsfristens start. Retrieval finder begge kilder; sproget ligner, men betydningen er forskellig. Agenten svarer selvsikkert “nej, ikke i restance”.
Med et stærkere kontekstlag ville passager være versioneret, og felter have entydige definitioner og provenance. En valideringspipeline ville opdage konflikten, markere usikkerhed eller skifte til HITL. Og et auditspor ville vise, at svaret trak fra en ikke-opdateret ERP-definition. Ikke perfekt, men nok til at forhindre den forkerte afmelding til inkasso.
Spørgsmål at stille i næste RFP eller PoC
Hvordan måler I retrieval-accuracy – med hvilke datasæt, og med hvilke negative kontroller? Hvordan registrerer og eksponerer I provenance på passageniveau? Hvad er jeres strategi for versionering af dokumenter og indeks, og hvordan sikrer I, at svar knyttes til den rigtige version? Hvilke fallback-regler aktiveres, når kilder modsiger hinanden?
Hvordan vægter jeres købs- og designkriterier adgangskontrol versus korrekthed? Hvilke auditmuligheder får driftsteamet, og kan de skifte embeddings- eller tool-implementering uden kodeændringer (harness-uafhængighed)? Og til sidst: hvilke metrikker får ledergruppen måned for måned, som reelt siger noget om kvalitet – ikke kun trafik og latenstid?
Afslutning uden glans
Synligheden er blevet bedre. Det er den mest positive læsning af, at 68 procent nu kan spore “confident but wrong”-svar til kontekst. Den svære del starter nu: operationaliser kvalitet – ikke bare governance på papir. Mål correctness, test retrieval, og byg kontekst som et produkt med versioner, logs og rollback.
Forskellen mærkes først, når nogen spørger: “Hvorfor sagde agenten det dér?” Hvis svaret findes i loggen – med passage, version og regel – er I på vej den rigtige vej. Hvis ikke, er det bare endnu et gæt, leveret med selvtillid.
