Selvom mange har kunnet bruge dybdegående research individuelt – til at søge efter og sammenfatte oplysninger online – har kun få haft gavn af det i en virksomhedssammenhæng. Det skyldes ikke, at det ikke ville være nyttigt – tværtimod – men bredere bekymringer om pålidelighed, adskilte datakilder og en models evne til at håndtere store mængder kontekst, såsom enorme mængder af forskellige filtyper.
Vores erfaring med at bygge dybdegående researchværktøjer til virksomheder gennem de seneste 12 måneder viser, at gennemtænkt engineering i stigende grad kan afhjælpe disse problemer. I dette blogindlæg gennemgår vi de største hindringer for effektive dybdegående researchløsninger i virksomheder, hvordan vi ville overvinde dem, og hvordan vi forventer, at området udvikler sig i 2026.
Loftet for, hvad der kan realiseres, er hævet markant. Lanceringen af gpt-5 i august 2025 blev et vendepunkt for AI i virksomheder. I vores produktionssystemer, herunder en platform til identifikation af lægemiddelmål for en af verdens største medicinalvirksomheder, så vi kildehallucinationer falde fra 3-4 % til reelt nul. I december udvidede gpt-5.2 derefter den effektive kontekstlængde yderligere. Det praktiske resultat er, at vi nu kan gå fra hundredvis til tusindvis af kilder pr. researchkørsel uden at gå på kompromis med pålideligheden. Flaskehalsen er flyttet fra modellens kapacitet tilbage til der, hvor den hører hjemme: jeres data, evalueringer og programdesign.
Datastrategi: Tilgængelighed slår ensretning. Det er forståeligt at betragte AI i virksomheder som et dataintegrationsproblem, men ofte virker det mod hensigten. Fuld ensretning er langsom og politisk og tvinger jer til at lægge kursen, før I har fundet ud af, hvilke spørgsmål der faktisk betyder noget. Den pragmatiske løsning i 2026 er sparsom konnektivitet. Gør data tilgængelige via stærke holdepunkter såsom specifikationer, politikker, SKU'er og kontraktklausuler i stedet for at vente i årevis på at ensrette alt. Banebrydende modeller kan nu foretage »bløde joins« på tværs af systemer under inferens og forbinde relaterede termer uden formelle mappinger. I bevarer både den hurtige implementering og fleksibiliteten til at tilføje kilder senere.
Navigation forhindrer vildveje. Virksomhedsdata er ikke som internettet. De er spredte, fulde af lokale konventioner og har ofte præcis én korrekt kilde til et givent faktum. Uden vejledning har modeller en tendens til at køre endeløse søgninger for at finde blot én kilde mere og samtidig opbruge både tid og brugernes tålmodighed. Et let semantisk lag – hashtabeller, entitetsopslag og enkle relationsgrafer – giver systemet hurtige og billige veje til effektivt at finde den rette kontekst. Tænk på det som en erfaren kollegas råd til en ny medarbejder: »Gem disse sider som bogmærker, og tal med Ross, hvis du har problemer med AWS.« Det behøver ikke være kompliceret. Det skal blot hjælpe systemet med hurtigt at finde det, det har brug for.
Mekanisk (køres ved hver forespørgsel): kildehenvisningers kvalitet, korrekt brug af værktøjer, latenstid og omkostninger. Det er jeres sikkerhedsforanstaltninger – trivielle, men afgørende.
Analytisk (køres regelmæssigt): Vælger systemet de rette værktøjer og fornuftige researchretninger, bruger det autoritative kilder, og ved det, hvornår det skal stoppe? Bedømmes typisk af en LLM som dommer ud fra mærkede eksempler.
Bruger (løbende): gennemførelsesgrad for opgaver, kvalitativ feedback fra superbrugere og brugsanalyse. Den ultimative prøve. Har vi bygget noget, som folk finder nyttigt?
Afkastet kommer fra svære problemer, ikke sikre valg. Efter rapporter om, at de fleste AI-projekter i virksomheder ikke giver afkast, er tolerancen for imponerende demoer, der aldrig bliver lanceret, forsvundet. Ledelsen vil have dokumentation – og den skal komme hurtigt. Paradoksalt nok kan det pres få teams til at træffe de forkerte valg. Det er fristende at begynde med opgaver med lav risiko, fordi de er nemme at implementere og næppe skaber modstand. Men disse anvendelser gør sjældent en stor nok forskel til at retfærdiggøre fortsatte investeringer. Dybdegående researchsystemer til virksomheder er velegnede til at dokumentere værdi, fordi de retter sig mod arbejde, der allerede er dyrt: komplekse arbejdsgange med stor betydning, hvor prisen for status quo er synlig. De stærkeste anvendelser, vi har set, omfatter udarbejdelse af RFP'er og tilbud, analyse af forskningslandskaber og investeringsresearch – områder, hvor effekten måles på vinderrater, hurtigere vej til forsøg og hurtigere beslutningssikkerhed, ikke blot sparede timer.
UX-skiftet: fra chat til uddelegering og fra svar til leverancer. Vi mener, at dette er et af de skift i brugeroplevelsen, der vil definere 2026. Når vi ser på de løsninger, der på det seneste har opnået størst udbredelse, skiller et par ting sig ud. Efterhånden som systemerne er blevet mere pålidelige, er brugerne begyndt at behandle dem mindre som en chatbot, man spørger, og mere som en analytiker, man uddelegerer til. To ting gør det muligt: Teams kan tilpasse skabeloner og stopkriterier til deres arbejdsgange, og de kan eksportere direkte til det format, de faktisk har brug for – et notat, en præsentation, en brief osv. – i stedet for selv at samle en færdig leverance fra en chattråd. Når begge dele er på plads, går systemet fra at være et opslagsværktøj til at blive måden, arbejdet udføres på.
Sidste år skrev vi om at bringe dybdegående research ind i virksomheder. Vi tog paradigmet for internetbaseret dybdegående research, som OpenAI oprindeligt gjorde populært, og udvidede det til virksomheders egne datakilder uden at miste sporbarhed eller kontrol. Vi understregede også, at dybdegående researchsystemer ikke bør betragtes som et brud med mere klassiske RAG-systemer, men som en videreudvikling af dem.
På vej ind i 2026 er det ikke så meget idéen om dybdegående research, der har ændret sig, som loftet for, hvad der kan realiseres.
Da vi begyndte at bygge disse systemer tidligt i 2025, omfattede de banebrydende modeller o1, gpt-4o og claude-3.5-sonnet – vi er virkelig nået langt på blot 12 måneder – og modeller som o3 og gemini-2.5-pro gav store fremskridt i årets første måneder. De var fremragende på det tidspunkt, og man kunne bestemt bygge robuste løsninger til dybdegående research med dem – op til et vist punkt. Grænsen lå typisk ved nogle få hundrede kilder. Derefter måtte konteksten beskæres meget aggressivt, ellers blev prisen et mangelfuldt svar, svigtende instruktionsefterlevelse eller direkte hallucinationer.
Hvis I har bygget den slags systemer, vil I kunne genkende nogle af disse fejltyper.
Et konkret eksempel: I midten af 2025 begyndte vi at udvikle en dybdegående researchløsning med en af verdens største medicinalvirksomheder. Systemet skulle fremskynde identifikationen af lægemiddelmål, hvor forskere leder efter gener, hormoner eller andet i kroppen, der kan påvirkes for at behandle en lidelse. På det tidspunkt var o3 den stærkeste tilgængelige model. Selvom den leverede stærke resultater, indeholdt 3-4 % af modellens svar kilder, som ikke var blevet angivet til modellen gennem værktøjskald til kundens egne datakilder. Vi afhjulp problemet med efterfølgende kontrol af kildehenvisninger, som markerede afsnit i svarene, der ikke var understøttet af den angivne kontekst. Det fungerede godt til at skabe interessenternes tillid til værktøjet i projektets tidlige PoC-fase og hjalp os med hurtigt at gøre fremskridt. Men vi fortsatte arbejdet med at reducere fejlene, afhjælpe modellernes begrænsninger og samtidig opfylde interessenternes ønsker om at føje flere kilder til systemet.
Et afgørende vendepunkt for udviklingen af banebrydende dybdegående researchløsninger – og agentbaserede løsninger generelt – kom med gpt-5 i august. Da vi skiftede fra o3 til gpt-5, viste vores evalueringer, at andelen af kildehallucinationer straks faldt til 0 %.
Helt præcist måler dette, om modellen citerer et dokument-id eller en URL, som ikke fandtes i den hentede kontekst. I o3-æraen og tidligere opfandt modeller undertiden troværdigt klingende filnavne eller forskningsartikler for at udfylde huller i deres viden. Med gpt-5 kunne vi reelt eliminere netop denne uhensigtsmæssighed.
Bemærk, at dette adskiller sig fra fejl i kildetroskab – hvor det rette dokument citeres, men teksten fejlfortolkes. Det er fortsat en udfordring, som vi håndterer med de tidligere nævnte efterfølgende kontroller.
Det åbnede enorme muligheder. Derefter begyndte vi at teste, hvor langt vi kunne presse systemet med den nye generation af modeller. Vi kunne omtrent tidoble antallet af kilder i en researchkørsel til omkring 3.000-5.000. Den endelige grænse skyldtes ikke svigtende instruktionsefterlevelse, men ydeevnen ved lang kontekst. Modellernes effektive kontekstlængde er ofte langt kortere end oplyst, især med f.eks. kompakte medicinaldata.
Denne begrænsning blev delvist afhjulpet med lanceringen af gpt-5.2 medio december. Vores interne benchmarks for lang kontekst viste en markant forbedring af den effektive ydeevne, så vi kunne presse vores banebrydende dybdegående researchsystemer endnu længere. Det var nyttigt, fordi vi kunne øge antallet af tokens, der sendes direkte til den model, som producerer brugerens output, og dermed levere et mere nuanceret svar. Vi vil dog gerne se de banebrydende modellers effektive kontekstlængde fortsætte med at vokse i 2026.
Med disse fremskridt i modellernes grundlæggende kapacitet er flaskehalsene for kompetente dybdegående researchsystemer på mange måder flyttet tilbage til der, hvor de hele tiden burde have været: jeres data, evalueringer og måden, I organiserer programmet på i virksomheden. Hvert trin kræver pragmatiske beslutninger om, hvad der reelt gør en forskel i udviklingen af en dybdegående researchløsning.
Resten af artiklen beskriver, hvordan vi tænker om disse beslutninger.
Det kan være fristende at behandle researchprojekter i virksomheder som et dataintegrationsproblem. Ensret kilderne, normaliser skemaet, og slip modellerne løs ovenpå.
Og lad os slå fast: Nogle gange er det præcis den rette løsning. Hvis I arbejder på et område, hvor de centrale entiteter er stabile, forespørgslerne gentages, og målet er at industrialisere arbejdsgangen, kan ensretning give store gevinster. Klassiske eksempler er joins mellem kunde- og omsætningsdata, markedsprisdata eller andre områder, der kræver pålidelig rapportering på tværs af systemer.
I praksis søger nutidens innovative ledere dog noget andet i dybdegående researchsystemer til virksomheder.
Med et stadigt større fokus på afkastet af AI-investeringer er et centralt mål for beslutningstagere hurtigt at dokumentere værdi i den rodede virkelighed, som virksomheden faktisk fungerer i. Fuld ensretning af datakilder er en af de langsomste veje til det første bevis. Det er tungt. Det bliver politisk. Og ofte tvinger det jer til at vælge retning, før I har fundet ud af, hvilke spørgsmål der faktisk betyder noget.
Derfor mener vi, at det pragmatiske udgangspunkt for at bygge banebrydende dybdegående researchsystemer i 2026 som regel er: Gør jeres data tilgængelige, før I gør dem perfekte.
Hvis I realistisk set vil tilføje flere kilder med tiden – som de fleste virksomheder – er sparsomme forbindelser undervurderede. I kan gøre snesevis af kilder tilgængelige gennem én ensartet grænseflade til hentning. Systemet vil stadig kunne fungere, og afgørende nok bevarer I evnen til at levere hurtigt. Når I tilføjer flere kilder, behøver I ikke vende op og ned på alt. I kan blot tilslutte en ny connector, forklare kernesystemet, hvad den er, og hvordan den bruges, og lade modellerne klare resten. Det fungerer, fordi nutidens banebrydende modeller kan foretage bløde joins mellem to eller flere datakilder under inferens og forbinde »Customer ID« i ét system med »Client Reference« i et andet, uden at nogen skriver en formel mapping. Vi er ikke det eneste team, der tænker sådan. Vi er ikke det eneste team, der tænker sådan: OpenAI's interne dataagent er designet til at lade modeller ræsonnere over 70.000 forskelligartede datasæt ved at gøre kontekst og forbindelser tilgængelige på forespørgselstidspunktet frem for at kræve fuld ensretning på forhånd.
En vigtig nuance er, at sparsom ikke behøver at betyde overfladisk.
Sparsom integration fungerer bedst, når de forbindelser, I faktisk opretter, er meningsfulde og udtrykt på en måde, som systemet let kan udnytte. En god tilgang er at betragte bestemte oplysninger som holdepunkter, f.eks. specifikationer, politikker, produktdefinitioner, SKU'er og kontraktklausuler. I behøver ikke ensrette alle datasæt for at gøre disse holdepunkter effektive. I skal blot have en stabil identifikator med nogle få stærke forbindelser.
Forestil jer f.eks., at en model eller bruger slår en specifikation op. I et naivt system slutter interaktionen der. I henter specifikationen, sammenfatter den og tilføjer måske en kildehenvisning. Men når vi bygger nyttige datastrukturer, ønsker vi at gøre opslaget til begyndelsen på en kontrolleret udvidelse. Vi kunne f.eks. valgfrit forbinde specifikationens post med historisk relevante leverancer. »Relevant« kan betyde flere ting, men vil typisk afhænge af systemets opgave og kan omfatte RFP'er, der henviser til specifikationen, tidligere vindende tilbud på den, ændringsforslag, hvor juridisk afdeling gjorde indsigelse, osv. Denne tilgang kan forbedre svarkvaliteten og latenstiden markant ved hurtigt at vise systemet de vigtigste indsigter på forespørgselstidspunktet.
Det leder til næste spørgsmål: Når I har et univers af løst forbundne datakilder med nogle få stærke forbindelser, hvordan forhindrer I så systemet i at fare rundt som et barn i en slikbutik og får det i stedet til at navigere som en erfaren analytiker?
Virksomheders datakilder fungerer ikke som internettet. De er spredte, fulde af lokale konventioner og har ofte præcis én »korrekt« kilde til et givent faktum – hvis man kan finde den. Desuden forsøger nutidens modeller ofte altid at maksimere recall ved søgninger og kører forespørgsel efter forespørgsel for at finde blot én kilde mere, mens tiden går og brugernes tålmodighed slipper op. Omhyggelige prompts kan afhjælpe dette til en vis grad.
Den mest effektive løsning er et let værktøj, som hjælper modellen med at orientere sig i det rodede virksomhedslandskab af data. Nogle teams kalder det en ontologi. Andre kalder det et semantisk lag, en opslagstjeneste, en graf eller et begrebslager. Betegnelsen er ikke afgørende.
Det afgørende er, at det giver systemet en række hurtige og billige navigationsmuligheder, så modellen effektivt kan springe mellem de relevante dele af konteksten i stedet for at famle rundt i en evighed.
En enkel metafor er, at det svarer til at være ny i en virksomhed eller på et projekt og få at vide af sine nye kolleger: »Du skal gemme disse sider som bogmærker; du kommer til at bruge dem hele tiden« eller »Hvis du har problemer med AWS, skal du bare tale med Ross. Han skaffer de oplysninger, du har brug for« og så videre. På samme måde forsøger vi blot at hjælpe systemet til dybdegående research med hurtigt at finde det, det har brug for.
I praksis behøver systemet hverken at være kompliceret eller at blive vedligeholdt manuelt. De bedste implementeringer, vi har set, genereres enten af LLM'er under indlæsningen – hvor entiteter udtrækkes og automatisk føjes til grafen – eller fungerer som enkle videreforbindelser til eksisterende kernesystemer, f.eks. et opslag via Salesforce API'en. Almindelige eksempler omfatter:
Opslag i hashtabeller, f.eks. en forespørgsel med et produktnavn, der returnerer produktbeskrivelsen
Et enkelt opslag i »almindelige« relationer, f.eks. at dette gen oftest forbindes med disse sygdomme i vores graf over kausale genrelationer
Modeller til genkendelse af navngivne entiteter, som især er nyttige på områder med komplekse problemer med at skelne entiteter fra hinanden, f.eks. medicinalområdet
For de mest komplekse datarelationer kan lette RDF-grafer være den mest udvidelige løsning til en ontologi
… og meget mere
Når dette er på plads, kan systemet bevæge sig effektivt gennem jeres datakilder. Det næste spørgsmål er enkelt: Hvordan ved I, at det konsekvent gør det rigtige under faktisk brug?
Når jeres data er tilgængelige, og navigationslaget leverer kortet, har systemet kapacitet til at udføre arbejdet. Men i en virksomhed er kapacitet intet værd uden pålidelighed.
Her findes den største kirkegård for AI-projekter. Mange teams er faldet i fælden med evalueringer baseret på mavefornemmelse. De kørte en forespørgsel, læste resultatet, nikkede tilfredse og lancerede det. Den tilgang fungerer ikke, når man bygger et dybdegående researchsystem, der på egen hånd kan gennemgå 5.000 dokumenter for at anbefale en beslutning om en forsyningskæde til et millionbeløb.
Det afgørende skift er, at I ikke længere evaluerer en model, men et system. Fortolkning af spørgsmål, planlægning, værktøjskald, fortolkning, beskæring af kontekst, rerangering og selv tilsyneladende kedelige detaljer i connectorer såsom tidsstempler påvirker alle brugeroplevelsen.
Strukturerede evalueringer, der kan gentages, hjælper os med at løse disse problemer.
Når vi udvikler evalueringer, kan vi overordnet inddele dem i tre kategorier fra det mekaniske til det subjektive.
Denne del minder mest om enhedstest, og her kan teams ofte gøre hurtigst fremskridt i begyndelsen. Det er også typisk de mest stabile evalueringer over tid. Når de først er konfigureret, kan de skabe værdi gennem hele projektets levetid.
»Mekaniske evalueringer« er generelt kontroller, der kan køres ved hver forespørgsel uden menneskelig indgriben. De styrker vores tillid til, at systemet opfører sig forudsigeligt og sikkert under reel brugerbelastning.
Eksempler omfatter:
Kildehenvisningers kvalitet: Peger alle henvisninger på tekstuddrag, der faktisk blev hentet? Er der påstande uden kildehenvisninger? Er der påstande, som kildematerialet ikke understøtter? Er henvisningerne for generelle, f.eks. når et helt dokument citeres som belæg for én enkelt påstand?
Korrekt brug af værktøjer: Brugte systemet alle de værktøjer, det sagde, det havde brugt? Brugte det navigationsværktøjerne korrekt? Formaterede det nogen værktøjsanmodninger forkert? Forsøgte det igen på en fornuftig måde, når der opstod fejl?
Budgetter for latenstid og omkostninger: Holdt det sig inden for målet for tid til første token? Overskred det det forventede antal værktøjskald eller budgettet? Brugte det meget tid og regnekraft på en marginal forbedring?
Det lyder trivielt, men det er netop den type test, der forhindrer et virksomhedssystem i at forfalde.
I vores konkrete projekt om dybdegående research til identifikation af lægemiddelmål anvendte vi to lag af kildekontrol, som køres ved hver forespørgsel. Først instruerer vi modellen i at indsætte hyppige kildehenvisninger i teksten, når den genererer et svar. At LLM'er kan gøre dette pålideligt, er også et relativt nyt fænomen, som opstod i første halvdel af 2025. Alle, der tidligere har forsøgt dette med betydelige datamængder, vil kende den udfordring, det plejede at være. Dermed kan vi bruge en række enkle regex-kontroller til f.eks. at opdage, om der nævnes et link til en artikel, som ikke fandtes blandt de angivne kilder.
Det andet kontrollag udføres, efter at svaret er blevet streamet. Først opdeles svaret i bidder. Derefter vurderes hver bid, mens systemet søger efter kilder i de hentede data, der understøtter påstanden eller påstandene i den. Hvis der ikke findes dokumentation, markeres det som en mulig hallucination.
Hvis de mekaniske evalueringer er jeres enhedstest, er de analytiske evalueringer jeres kodegennemgang.
Her bevæger vi os ind i en verden, hvor vi forsøger at forstå, om systemet udfører arbejdet godt. Vi vil typisk forstå, om det bruger de rette værktøjer, følger de rigtige researchretninger, vælger de mest autoritative kilder og ved, hvornår det skal stoppe – blandt andet.
I praksis udformes de typisk som en række spørgsmål-svar-par, hvor man f.eks. kender en fornuftig rækkefølge af værktøjskald eller den korrekte beslutning ud fra den research, det første værktøj fandt. Parret behøver ikke svare én til én til hele systemets input og output; metoderne kan også teste delprocesser. Med disse etiketter, som enten kan genereres af en menneskelig annotator eller en stærk annoteringsmodel – »stærk« er relativt her – kan vi bruge en LLM som dommer til at bedømme researchkørslernes resultater. Ved at følge resultaterne over tid kan vi se, om vores ændringer forbedrer systemet i den ønskede retning, eller om vi har skabt forringelser.
Fordi disse kørsler koster mere både i tid og penge, bør de normalt udføres regelmæssigt efter en fast tidsplan eller før versionsopdateringer.
Der er også en nyttig afledt fordel: Denne type analytiske evalueringer kan direkte danne grundlag for forbedringer af de sparsomme forbindelser, vi omtalte tidligere. Hvis I gentagne gange ser modellen foretage det samme kvalificerede spring – f.eks. »specifikation → historisk relevante RFP-eksempler« – selvom mennesker ikke udtrykkeligt forbinder disse leverancer i dag, er det værdifuldt. I kan gøre springet til en egentlig forbindelse eller genvej, så fremtidige kørsler får lavere latenstid og større ensartethed.
Det er også her, I opdager en af de dyreste uhensigtsmæssigheder i dybdegående researchsystemer: tendensen til som standard at maksimere recall. En model kan altid finde én kilde mere. Spørgsmålet er, om den bør gøre det. Vi kan justere modellen, så den i højere grad stopper på et fornuftigt tidspunkt, når systemet vurderer, at yderligere hentning næppe ændrer konklusionen, og i stedet leverer et veldokumenteret svar på brugerens spørgsmål.
De mekaniske evalueringer fortæller jer, at systemet er sikkert. De analytiske evalueringer fortæller jer, at det er kompetent. Brugerevalueringerne fortæller jer, om det faktisk er nyttigt.
Det er endnu et område, hvor mange teams snubler. De bygger noget teknisk imponerende, som ingen ønsker at bruge to gange. I en virksomhed er det forskellen mellem en vellykket implementering og et dyrt researchprojekt.
Brugerevalueringer handler grundlæggende om at forstå, om systemet løser det rette problem på den rette måde. Det betyder, at man skal gå videre end »gav det det rigtige svar?« og spørge: »Gav det mig noget, jeg kan handle på?«
I praksis antager brugerevalueringer typisk nogle få former:
Undersøgelser af opgavegennemførelse: Kan brugerne faktisk udføre deres reelle arbejde hurtigere eller bedre med systemet? Det handler ikke om, hvorvidt modellen kunne besvare et spørgsmål, men om en virkelig bruger i sin faktiske arbejdsgang fik det, vedkommende havde brug for.
Kvalitative feedbackforløb: Regelmæssige, strukturerede samtaler med superbrugere. Hvilke forespørgsler kører de gentagne gange? Hvor mister de tilliden? Hvornår giver de op og vender tilbage til den gamle metode? Disse sessioner afslører ofte fejltyper, som aldrig dukker op i testsættene, fordi brugerne stiller spørgsmål på måder, I ikke havde forudset, eller har uudtalte kvalitetskrav, I ikke kendte til.
Brugsanalyse: Hvilke forespørgsler køres igen? Hvilke svar kopieres og bruges andre steder? Hvor klikker brugerne på tommelfinger ned? Faldende brug er ikke altid et tegn på fiasko – nogle gange får brugerne deres svar og går videre – men mønstre i, hvornår og hvordan de opgiver forespørgsler, fortæller meget om, hvor systemet ikke lever op til forventningerne.
Tilsammen giver disse metoder jer mulighed for at måle nytteværdien uden at gætte og hjælper jer med at opdage problemer, før de begynder at undergrave brugernes tillid.
Selv et system, der scorer perfekt på mekanisk nøjagtighed og begejstrer de første brugere, kan dog stadig fejle den ultimative prøve: at øge virksomhedens omsætning. Pålidelighed og brugertilfredshed er blot forudsætninger for dette. For at krydse kløften fra en vellykket pilot til et transformerende aktiv for virksomheden skal I se ud over, hvordan systemet fungerer, og fokusere på, hvor det anvendes.
Vi har gennemgået, hvordan I får jeres data til at fungere for systemet og derefter systemet til at fungere for brugerne. Nu skal vi tale om, hvordan systemet kan skabe resultater for virksomheden.
Det har virksomhedsledere med rette haft intenst fokus på på det seneste. Efter rapporter som MIT's påstand om, at 95 % af virksomheders AI-projekter ikke giver afkast, er tolerancen for imponerende demoer, der aldrig bliver lanceret, forsvundet. Modellerne er klar. Arkitekturerne er afprøvede. Spørgsmålet er nu: Kan I faktisk implementere dette på en måde, der skaber værdi for virksomheden?
Den gode nyhed er, at banebrydende dybdegående researchsystemer, der bygger på ovenstående principper, har gode forudsætninger for at leve op til kravet. De forsøger ikke at automatisere alt eller erstatte hele jobfunktioner. De skal gøre jeres dygtigste medarbejdere markant mere effektive i det værdifulde arbejde, de allerede udfører.
Men vejen fra »teknisk velfungerende« til »giver afkast« kræver yderligere gennembrud: De organisatoriske valg samt valgene om brugeroplevelse og måling, der afgør, om det bliver et dagligt værktøj eller en glemt fane.
Det er vores erfaring, at der er to.
Det er ofte fristende at begynde med interne opgaver med lav risiko som »summarise this meeting«. Selvom det er sikkert, dokumenterer disse anvendelser sjældent nok værdi til at retfærdiggøre omkostningen.
Dybdegående researchsystemer fungerer bedst, når de sættes på store, svære opgaver – dyre problemer, hvor bedre kvalitet eller højere hastighed giver en dokumenterbar stigning i omsætningen eller en strategisk fordel.
Vi ser det højeste afkast, når virksomheder vælger indgange som:
Kompleks udarbejdelse af tilbud og RFP'er: Dybdegående researchsystemer kan automatisk hente de mest lignende historiske sejre og nederlag, udtrække de få klausuler, der altid udløser ændringsforslag, finde den stærkeste dokumentation for et givent krav og meget mere, før det hele omsættes til en stærk og sammenhængende positionering i tilbuddet. Målet er ikke sparede timer, men vinderrate, bevarede marginer og færre juridiske eller kommercielle overraskelser sent i forløbet.
Analyse af forskningslandskabet: I organisationer med tung forskning og udvikling – medicinalvirksomheder, biotek og halvledere – er indgangen at komprimere ugers litteratur og intern viden til en brugbar researchretning. Et dybdegående researchsystem kan gennemgå tusindvis af artikler, patenter, interne rapporter, laboratorienotater og tidligere programevalueringer for at kortlægge kendt og omstridt viden og skabe et evidensbaseret overblik. Det kan give hurtigere iterationscyklusser, færre blindgyder og vigtigst af alt kortere tid til det første forsøg med mennesker.
Markedsindsigt: For banker og hedgefonde ligger værdien i at omsætte fragmenteret intern research – notater, modeller, transskriptioner og mæglerkommentarer – samt eksterne signaler – indberetninger, regnskaber, makrotal og nyheder – til beslutningsklar støtte for handler. Et dybdegående researchsystem kan løbende opbygge og opdatere et syn på en virksomhed, et tema eller et makroøkonomisk spørgsmål, fremhæve de vigtigste ændringer siden sidste uge, afstemme modstridende kilder og udarbejde et investeringsnotat eller handelspakke med fuld dokumentation for oprindelsen.
Fælles for dem er, at de ikke er chats. Det er komplekse arbejdsgange, som normalt kræver dyre eksterne konsulenter eller flere ugers arbejde fra erfarne medarbejdere. Når et dybdegående researchsystem sættes på disse problemer, er værdien ubestridelig.
Dette er et af de skift i brugeroplevelsen, der vil definere 2026.
Hvis jeres dybdegående researchsystem blot er en chatbot, som brugerne spørger for at finde oplysninger, kan brugen hurtigt blive sporadisk. Det forbliver et opslagsværktøj, og brugerne skal i sidste ende selv samle resultaterne til den ønskede sluttleverance. Men hvis det føles som en analytiker, der altid er til rådighed og kan få tildelt arbejde, kan det ændre teamets arbejdsmodel fuldstændigt.
Vi ser et skift væk fra »chat« – korte udvekslinger frem og tilbage – og over mod uddelegering, hvor man definerer omfang, skabelon og mål og lader systemet køre.
Tre konkrete skift muliggør dette:
Resultater som leverancer: Arbejde med høj værdi findes sjældent i et chatvindue, men i dokumenter, notater og præsentationer. Moderne dybdegående researchsystemer bør springe chatfasen over og generere den endelige forretningsleverance direkte. Når en bruger kan bede om et »3-page investment memo in our corporate format« og modtage en fil til download frem for en strøm af tekst, falder tiden til værdiskabelse drastisk. Dette udvides også ofte med planlagte genereringer, hvor brugerne kan få e-mails eller rapporter med ny indsigt genereret automatisk og sendt til relevante modtagere, efterhånden som nye data opstår.
Lokal optimering med tilpassede skabeloner: Modeller er blevet robuste nok til, at forretningsenheder eller individuelle brugere nu kan forme deres egne prompts og systemets adfærd uden at ødelægge det. En risikorapport ser anderledes ud i London end i New York. Ved at lade teams uploade eller designe egne strukturelle skabeloner og definere stopkriterier som »always check these three specific internal databases« eller outputformat kan brugerne få langt større værdi af systemet og skabe noget, de ønsker at bruge igen og igen.
Tillid som grænseflade: Når en bruger uddelegerer en opgave, der tager mere end 20 minutter at køre, bliver tillid højt prioriteret. I kan ikke præsentere en sort boks. Grænsefladen skal synliggøre systemets overvejelser og valg, vise brugeren, hvilke værktøjer der anvendes, generere kildehenvisninger og mere. Vi oplever ofte, at den bedste UX som standard viser overordnede indsigter i researchens fremdrift og giver brugeren mulighed for at gå i dybden ved at folde flere oplysninger ud i en sidebjælke eller lignende.
Vi forestiller os en fremtid, hvor alle førende virksomheder har et skræddersyet dybdegående researchsystem bag deres vigtigste arbejdsgange. Det vil tage form som en række analytikere, der altid er til rådighed, pålideligt kan gennemgå tusindvis af interne leverancer og producere beslutningsgrundlag og resultater, som mennesker kan handle på. Når banebrydende modeller hæver loftet for, hvad der kan realiseres, flytter konkurrencefordelen til det grundlæggende: at gøre data tilgængelige, give systemet et kort og operationalisere pålidelighed gennem evalueringer.
De forbedringer af modellernes kapacitet, vi har set det seneste år, er det tydeligste tegn på, hvor udviklingen bevæger sig hen. Muligheden for ledere i 2026 er at rykke tidligt. Vælg en indgang, hvor værdien er tydelig, opbyg tillid gennem sporbarhed og sikkerhedsforanstaltninger, og gør virksomhedens dybdegående researchløsning fra et pilotprojekt til en voksende kapacitet, som bruges hver dag.