Selv om mange har kunnet bruke dyp forskning individuelt – til å søke etter og sammenstille informasjon på nettet – har få hatt nytte av det i virksomhetssammenheng. Det skyldes ikke at det mangler nytteverdi – snarere tvert imot – men bredere bekymringer om pålitelighet, spredte datakilder og modellens evne til å håndtere store mengder kontekst, som svært mange ulike filtyper.
Erfaringen vår med å bygge virksomhetsklare verktøy for dyp forskning de siste tolv månedene viser at gjennomtenkt utvikling i økende grad kan redusere disse utfordringene. I dette blogginnlegget drøfter vi de største hindringene for effektive løsninger for dyp forskning i næringslivet, hvordan vi ville overvunnet dem, og hvordan vi tror området vil utvikle seg gjennom 2026.
Taket for hva som kan gjennomføres, har blitt dramatisk høyere. Lanseringen av gpt-5 i august 2025 markerte et vendepunkt for KI i næringslivet. I produksjonssystemene våre, blant annet en plattform for identifisering av legemiddelmål for et av verdens største legemiddelselskaper, så vi at kildehallusinasjoner falt fra 3–4 % til praktisk talt null. I desember utvidet gpt-5.2 den effektive kontekstlengden ytterligere. Det praktiske resultatet er at vi nå kan skalere fra hundrevis til tusenvis av kilder per forskningskjøring uten å ofre påliteligheten. Flaskehalsen har flyttet seg fra modellens kapasitet og tilbake dit den hører hjemme – til dataene, evalueringene og programutformingen deres.
Datastrategi: Tilgjengelig slår enhetlig. Det er forståelig å betrakte KI i næringslivet som et dataintegrasjonsproblem, men det virker ofte mot sin hensikt. Full samordning er langsom og politisk betent, og tvinger frem for tidlige veivalg før dere har funnet ut hvilke spørsmål som faktisk betyr noe. Den pragmatiske løsningen i 2026 er begrenset sammenkobling. Gjør data tilgjengelige gjennom informasjonsrike holdepunkter – spesifikasjoner, retningslinjer, SKU-er og kontraktsklausuler – fremfor å vente i årevis på å samordne alt. Banebrytende modeller kan nå utføre «myke koblinger» mellom systemer ved inferens og knytte sammen relaterte begreper uten formelle tilordninger. Dere beholder rask utrulling og fleksibiliteten til å legge til flere kilder senere.
Navigasjon hindrer formålsløs leting. Virksomhetsdata er ikke som nettet. De er spredte, fulle av lokale konvensjoner og har ofte nøyaktig én riktig kilde til et bestemt faktum. Uten veiledning har modeller en tendens til å kjøre endeløse søk for å finne bare én kilde til, på bekostning av responstid og brukernes tålmodighet. Et lett semantisk lag – hashtabeller, enhetsoppslag og enkle relasjonsgrafer – gir systemet raske og rimelige veier til riktig kontekst. Tenk på rådene en erfaren kollega gir en nyansatt: «bookmark these sites, talk to Ross if you have AWS issues.» Det trenger ikke være komplisert. Det må bare hjelpe systemet med raskt å finne det det trenger.
Mekanisk (kjøres for hvert søk): kildehenvisningenes kvalitet, ryddig verktøybruk, responstid og kostnader. Dette er sikkerhetsrekkverkene deres – hverdagslige, men avgjørende.
Analytisk (kjøres regelmessig): Velger systemet riktige verktøy og fornuftige forskningsretninger, bruker autoritative kilder og vet når det skal stoppe? Vurderes vanligvis ved at en LLM fungerer som dommer opp mot merkede eksempler.
Bruker (løpende): fullføringsgrad for oppgaver, kvalitative tilbakemeldinger fra avanserte brukere og bruksanalyse. Den avgjørende testen. Har vi laget noe folk synes er nyttig?
Avkastningen kommer fra vanskelige problemer, ikke trygge oppgaver. Etter rapporter om at de fleste KI-prosjekter i næringslivet ikke gir avkastning, har toleransen for imponerende demoer som aldri settes i drift, forsvunnet. Ledere vil ha bevis, og de vil ha dem raskt. Paradoksalt nok kan dette presset få team til å velge feil. Det er fristende å starte med oppgaver der lite står på spill, fordi de er enkle å rulle ut og neppe skaper motstand. Men slike bruksområder gir sjelden stor nok effekt til å rettferdiggjøre videre investeringer. Systemer for dyp forskning i næringslivet er godt egnet til å dokumentere verdi fordi de retter seg mot arbeid som allerede er kostbart: komplekse arbeidsflyter med høy risiko, der kostnaden ved dagens praksis er synlig. De sterkeste bruksområdene vi har sett, er blant annet utarbeidelse av tilbud og svar på anbudsforespørsler, vitenskapelige landskapsanalyser og investeringsanalyse – områder der effekten måles i høyere vinnerandel, raskere vei til kliniske studier og raskere beslutningssikkerhet, ikke bare i sparte timer.
Skiftet i brukeropplevelsen: fra samtale til delegering, fra svar til leveranser. Vi tror dette blir et av skiftene i brukeropplevelsen som vil prege 2026. Når vi ser på løsningene som nylig har fått størst utbredelse, er det særlig et par ting som skiller seg ut. Etter hvert som systemene har blitt mer pålitelige, har brukerne begynt å behandle dem mindre som en chatbot de stiller spørsmål til, og mer som en analytiker de delegerer arbeid til. To ting gjør dette mulig: at team kan tilpasse maler og stoppkriterier til sine egne arbeidsflyter, og at de kan eksportere direkte til formatet de faktisk trenger – et notat, en presentasjon, et sammendrag og så videre – i stedet for å måtte sette sammen en ferdig leveranse fra en chattetråd. Når begge deler er på plass, slutter systemet å være et oppslagsverktøy og blir måten arbeidet utføres på.
I fjor skrev vi om å bringe dyp forskning inn i næringslivet. Vi tok paradigmet for nettorientert dyp forskning, som OpenAI opprinnelig populariserte, og utvidet det til virksomheters egne datakilder uten å miste sporbarhet eller kontroll. Vi påpekte også at systemer for dyp forskning ikke bør ses som et brudd med mer klassiske RAG-systemer, men som en videreutvikling av dem.
Det som har endret seg på vei inn i 2026, er ikke først og fremst ideen om dyp forskning, men taket for hva som kan gjennomføres.
Da vi begynte å bygge disse systemene tidlig i 2025, omfattet de banebrytende modellene o1, gpt-4o og claude-3.5-sonnet – vi har virkelig kommet langt på bare tolv måneder – før modeller som o3 og gemini-2.5-pro ga store fremskritt i årets første måneder. De var svært gode for sin tid, og det var absolutt mulig å bygge robuste løsninger for dyp forskning med dem – opp til et visst punkt. Dette punktet lå vanligvis på noen få hundre kilder. Deretter måtte konteksten beskjæres aggressivt, ellers risikerte man et mangelfullt svar, sviktende instruksjonsfølging eller rene hallusinasjoner.
Hvis dere har bygget slike systemer, vil dere kjenne igjen noen av disse feiltypene.
Et konkret eksempel: I midten av 2025 begynte vi å bygge en løsning for dyp forskning sammen med et av verdens største legemiddelselskaper. Systemet skal fremskynde identifiseringen av legemiddelmål, en prosess der forskere leter etter gener, hormoner eller andre deler av menneskekroppen som kan påvirkes for å behandle en sykdom. På dette tidspunktet var o3 den sterkeste tilgjengelige modellen. Selv om modellen leverte gode resultater, inneholdt 3–4 % av svarene kilder som ikke var blitt gitt til modellen gjennom verktøykall mot kundens egne datakilder. Vi begrenset dette med kildekontroller i etterkant, som flagget deler av svarene som ikke hadde støtte i den oppgitte konteksten. Dette fungerte godt for å skape tillit til verktøyet blant interessentene i prosjektets tidlige konseptutprøvingsfase og hjalp oss med å gjøre raske fremskritt. Samtidig fortsatte vi arbeidet med å redusere feilene, håndtere modellenes begrensninger og oppfylle interessentenes ønsker om å legge til flere kilder i systemet.
Et avgjørende vendepunkt for bygging av banebrytende løsninger for dyp forskning – og mer generelt agentbaserte løsninger – kom da gpt-5 ble lansert i august. Da vi byttet fra o3 til gpt-5, viste evalueringene umiddelbart at andelen kildehallusinasjoner falt til 0 %.
For å definere måltallet presist: Det registrerer utelukkende om modellen viser til en dokument-ID eller URL som ikke fantes i den innhentede konteksten. I o3-æraen og tidligere fant modellene noen ganger på plausible filnavn eller artikler for å fylle hull i kunnskapen. Med gpt-5 kunne vi i praksis eliminere akkurat denne svakheten.
Dette må ikke forveksles med troverdighetsfeil – å sitere riktig dokument, men feiltolke teksten – som fortsatt er en utfordring vi håndterer med de nevnte etterkontrollene.
Dette åpnet enorme muligheter. Dermed begynte vi å teste hvor langt vi kunne presse systemet med den nye modellgenerasjonen. Vi fant ut at vi kunne tidoble antallet kilder i én kjøring med dyp forskning, til rundt 3000–5000. Grensen vi til slutt møtte, var ikke svikt i instruksjonsfølgingen, men ytelsen med lang kontekst. Modellenes effektive kontekstlengde er ofte langt kortere enn oppgitt, særlig med for eksempel tettpakkede legemiddeldata.
Denne begrensningen ble delvis redusert da gpt-5.2 ble lansert i midten av desember. De interne testene våre for lang kontekst viste et betydelig løft i den effektive ytelsen med lang kontekst, slik at vi kunne presse de banebrytende systemene våre for dyp forskning enda lenger. Dette var nyttig fordi vi kunne øke antallet tokener som sendes direkte til modellen som lager resultatet for brukeren, og dermed levere et rikere svar. Vi ønsker likevel at den effektive kontekstlengden til banebrytende modeller skal fortsette å øke gjennom 2026.
Med disse fremskrittene i ren modellkapasitet har flaskehalsene for å bygge gode systemer for dyp forskning på mange måter flyttet seg tilbake dit de hele tiden burde ha vært: til dataene, evalueringene og måten programmet for dyp forskning organiseres i virksomheten. Hvert av disse trinnene krever pragmatiske beslutninger om hva som faktisk gir merkbar fremdrift i en løsning for dyp forskning.
Resten av artikkelen forklarer hvordan vi vurderer disse beslutningene.
Det kan være fristende å behandle forskningsprosjekter i næringslivet som et dataintegrasjonsproblem. Samordne kildene, normaliser skjemaet og slipp modellene løs oppå det hele.
Og for å være tydelig: Noen ganger er det nettopp dette som er riktig. Hvis dere arbeider på et område der de sentrale enhetene er stabile, søkene gjentas og målet er å industrialisere arbeidsflyten, kan samordning gi betydelig avkastning. Klassiske eksempler er sammenkobling av kunde- og inntektsdata, markedsprisdata eller annet som krever pålitelig rapportering på tvers av systemer.
I praksis ønsker imidlertid dagens innovative ledere noe annet fra systemer for dyp forskning i næringslivet.
Med stadig større vekt på avkastningen fra KI-investeringer er et hovedmål for beslutningstakere å dokumentere verdi raskt, midt i den uoversiktlige virkeligheten der virksomheten faktisk opererer. Full samordning av datakilder er en av de tregeste veiene til det første verdibeviset. Det er tungt. Det blir politisk. Og ofte tvinger det dere til å velge retning før dere har funnet ut hvilke spørsmål som faktisk betyr noe.
Derfor mener vi at det pragmatiske utgangspunktet for å bygge banebrytende systemer for dyp forskning i 2026 vanligvis er dette: Gjør dataene tilgjengelige før dere gjør dem elegante.
Hvis det er realistisk at dere vil legge til flere kilder over tid – slik de fleste virksomheter gjør – er begrenset sammenkobling undervurdert. Dere kan gjøre titalls kilder tilgjengelige bak ett konsekvent grensesnitt for innhenting. Systemet vil fortsatt kunne fungere, og viktigst av alt beholder dere evnen til å levere raskt. Når flere kilder skal legges til, trenger dere ikke å flytte fjell. Dere kobler ganske enkelt til en ny integrasjon, forklarer kjernesystemet hva den er og hvordan den skal brukes, og lar modellene gjøre resten. Dette fungerer fordi dagens banebrytende modeller kan koble to eller flere datakilder «mykt» ved inferens og knytte «Customer ID» i ett system til «Client Reference» i et annet uten at noen skriver en formell tilordning. Vi er ikke det eneste teamet som tenker slik. Vi er ikke det eneste teamet som tenker slik: OpenAIs interne dataagent er utformet slik at modeller kan resonnere over 70 000 heterogene datasett ved å gjøre kontekst og forbindelser tilgjengelige når et søk utføres, fremfor å kreve full samordning på forhånd.
En viktig nyanse er at begrenset ikke trenger å bety overfladisk.
Begrenset integrasjon fungerer best når forbindelsene dere faktisk oppretter, er meningsfulle og uttrykt slik at systemet enkelt kan utnytte dem. En god tilnærming er å betrakte visse opplysninger som holdepunkter, for eksempel spesifikasjoner, retningslinjer, produktdefinisjoner, SKU-er og kontraktsklausuler. Dere trenger ikke å samordne alle datasett for å gjøre disse holdepunktene nyttige. Det holder med en stabil identifikator og noen få informasjonsrike kanter.
Tenk for eksempel at en modell – eller en bruker – slår opp en spesifikasjon. I et naivt system stopper samhandlingen der. Dere henter spesifikasjonen, oppsummerer den og oppgir kanskje en kilde. Når vi bygger nyttige datastrukturer, vil vi imidlertid gjøre dette oppslaget til starten på en kontrollert utvidelse. Vi kan for eksempel velge å knytte spesifikasjonens oppføring til historisk relevante leveranser. «Relevant» kan bety flere ting, men vil vanligvis avhenge av oppgaven systemet utfører. Det kan omfatte RFP-er som viste til spesifikasjonen, tidligere svar som vant tilbud basert på den, endringsforslag der juridisk avdeling motsatte seg den, og så videre. Denne tilnærmingen kan gi stor gevinst i svarkvalitet og responstid ved raskt å vise systemet for dyp forskning den viktigste innsikten idet søket utføres.
Det leder til neste spørsmål: Når dere har en verden av løst sammenkoblede datakilder med noen få informasjonsrike kanter, hvordan hindrer dere systemet for dyp forskning i å virre rundt som et barn i en godtebutikk og får det til å navigere som en erfaren analytiker?
Virksomhetsdatakilder fungerer ikke som nettet. De er spredte, fulle av lokale konvensjoner og har ofte nøyaktig én «riktig» kilde til et bestemt faktum – hvis dere finner den. Dagens modeller prøver dessuten ofte å maksimere gjenfinningen i søk. De kjører søk etter søk for å finne bare én kilde til, på bekostning av responstid og brukernes tålmodighet. Dette kan til en viss grad begrenses med gode instruksjoner.
Den mest effektive løsningen er et lett verktøy som hjelper modellen med å orientere seg i det uoversiktlige virksomhetsdatalandskapet. Noen team kaller dette en ontologi. Andre kaller det et semantisk lag, en oppslagstjeneste, en graf eller et begrepslager. Navnet spiller egentlig ingen rolle.
Det viktige er at systemet får raske og rimelige veier mellom de rette delene av konteksten, i stedet for å famle rundt i det som føles som en evighet.
En enkel metafor er når du nettopp har begynt i en ny bedrift eller et nytt prosjekt, og de nye kollegene sier: “You must bookmark these sites, you’ll use them all the time,” eller “any time you have an issue with AWS just speak to Ross, he’ll get you the info you need,” og så videre. På samme måte prøver vi her ganske enkelt å hjelpe systemet for dyp forskning med å finne det det trenger, raskt.
I praksis trenger ikke dette systemet å være komplisert eller vedlikeholdes manuelt. De beste løsningene vi har sett, genereres enten av LLM-er i innlesingsprosessen – som automatisk trekker ut enheter og fyller grafen – eller er enkle gjennomkoblinger til eksisterende kildesystemer, som oppslag mot Salesforce API-et. Noen vanlige eksempler er:
Oppslag i hashtabeller, for eksempel søk med produktnavn som returnerer produktbeskrivelsen
Et enkelt oppslag for «vanlige» relasjoner, for eksempel hvilke sykdommer et gen oftest er knyttet til i grafen vår over årsaksrelasjoner mellom gener og sykdommer
Modeller for gjenkjenning av navngitte enheter, særlig nyttige på områder med krevende enhetstvetydighet, som legemidler
For de mest komplekse datarelasjonene kan lette RDF-grafer være den mest utvidbare ontologiløsningen
… og mer
Når dette er på plass, kan systemet bevege seg effektivt gjennom datakildene deres. Neste spørsmål er enkelt: Hvordan vet dere at det konsekvent gjør det rette i faktisk bruk?
Når dataene er tilgjengelige og navigasjonslaget sørger for kartet, har systemet kapasitet til å gjøre jobben. Men i virksomhetssammenheng er kapasitet verdiløs uten pålitelighet.
Her ligger den største gravplassen for KI-prosjekter. Mange team har gått i fellen med magefølelsesbaserte evalueringer. De kjørte et søk, leste resultatet, nikket anerkjennende og satte det i drift. Denne tilnærmingen fungerer ikke når man bygger et system for dyp forskning som på egen hånd kan gå gjennom 5000 dokumenter for å anbefale en beslutning om en forsyningskjede verdt flere millioner dollar.
Det viktige skiftet er at dere ikke lenger evaluerer en modell, men et system. Tolkning av spørsmål, planlegging, verktøykall, fortolkning, beskjæring av kontekst, omrangering og tilsynelatende kjedelige koblingsdetaljer som tidsstempler påvirker alle brukeropplevelsen.
Strukturerte, repeterbare evalueringer hjelper oss med å løse disse problemene.
Når vi utformer evalueringer, kan vi grovt dele dem i tre kategorier, fra mekaniske til subjektive.
Dette er delen som ligner mest på enhetstester, og her kan team ofte gjøre raskest fremskritt i starten. Disse er vanligvis også mest stabile over tid. Når de først er satt opp, kan de gi verdi gjennom hele prosjektets levetid.
«Mekaniske evalueringer» er vanligvis kontroller som kan kjøres for hvert søk uten at et menneske deltar. De gjør oss tryggere på at systemet oppfører seg forutsigbart og sikkert under reell brukerbelastning.
Noen eksempler er:
Kildehenvisningenes kvalitet: Viser alle henvisninger til tekstavsnitt som faktisk ble hentet inn? Finnes det påstander uten kildehenvisning? Finnes det påstander som ikke støttes av kildematerialet? Er kildehenvisningene for generelle, for eksempel ved at et helt dokument oppgis som kilde til én påstand?
Ryddig verktøybruk: Brukte systemet alle verktøyene det sa at det brukte? Brukte det navigasjonsverktøyene riktig? Formaterte det noen verktøyforespørsler feil? Prøvde det på nytt på en fornuftig måte når det oppsto feil?
Budsjetter for responstid og kostnader: Holdt systemet seg innenfor målet for tid til første token? Overskred det forventet antall verktøykall eller budsjettet? Brukte det mye tid og regnekraft på en marginal gevinst?
Dette høres hverdagslig ut, men det er nettopp slike tester som hindrer et virksomhetssystem i å forvitre.
I prosjektet for dyp forskning knyttet til identifisering av legemiddelmål brukte vi for eksempel to lag med kildekontroller som kjøres for hvert søk. Først ber vi modellen om å legge inn hyppige kildehenvisninger i teksten når den genererer et svar. At LLM-er kan gjøre dette pålitelig, er også et relativt nytt fenomen som kom i første halvdel av 2025. Alle som forsøkte dette med betydelige datamengder tidligere, vet hvor krevende det var. Dermed kan vi bruke enkle regex-kontroller til blant annet å oppdage om en artikkellenke nevnes uten å finnes i de oppgitte kildene.
Det andre kontrollaget kjøres etter at svaret er strømmet. Først deles svaret i bolker. Deretter vurderes hver bolk ved at systemet søker i de innhentede dataene etter kilder som støtter påstanden eller påstandene i bolken. Hvis det ikke finnes støttende dokumentasjon, flagges dette som en mulig hallusinasjon.
Hvis de mekaniske evalueringene er enhetstestene, er de analytiske evalueringene kodegjennomgangen.
Her går vi over til å undersøke om systemet utfører arbeidet godt. Vi ønsker gjerne å forstå om det bruker riktige verktøy, følger de rette forskningsretningene, velger de mest autoritative kildene og vet når det skal stoppe, blant annet.
I praksis består dette gjerne av en serie spørsmål–svar-par der man for eksempel kjenner en fornuftig rekkefølge for verktøykall, eller vet hvilken beslutning som er riktig ut fra forskningsmaterialet det første verktøyet fant. Spørsmål–svar-parene trenger ikke å tilsvare inndataene og utdataene til hele systemet én til én; metodene kan også teste delprosesser. Med disse merkelappene – som kan lages av en menneskelig annotatør eller en sterk annoteringsmodell, der «sterk» er relativt – kan vi bruke en LLM som dommer til å poengsette forskningskjøringer og vurdere ytelsen. Ved å følge poengsummene over tid kan vi se om endringene forbedrer systemet i ønsket retning, eller om vi har innført ytelsesmessige tilbakeskritt.
Fordi disse kjøringene koster mer både i tid og penger, bør de vanligvis gjennomføres regelmessig, enten etter en fast tidsplan eller før versjonsoppdateringer.
Det finnes også en nyttig sekundærgevinst: Slike analytiske evalueringer kan gi direkte grunnlag for å forbedre de begrensede koblingene vi omtalte tidligere. Hvis modellen gjentatte ganger gjør det samme gode spranget – for eksempel «spesifikasjon → historisk relevante RFP-eksempler» – selv om mennesker ikke uttrykkelig knytter disse leveransene sammen i dag, er det nyttig informasjon. Dere kan gjøre dette spranget til en eksplisitt kant eller snarvei, slik at fremtidige kjøringer får lavere responstid og mer konsistente resultater.
Her oppdager dere også en av de dyreste svakhetene i systemer for dyp forskning: tendensen til å maksimere gjenfinning som standard. En modell kan alltid finne én kilde til. Spørsmålet er om den bør gjøre det. Vi kan justere modellen slik at den lærer fornuftig stoppatferd: Systemet gjenkjenner når mer innhenting neppe vil endre konklusjonen, og velger å levere et godt underbygget svar som besvarer brukerens spørsmål.
De mekaniske evalueringene forteller at systemet er sikkert. De analytiske evalueringene forteller at det er kompetent. Brukerevalueringene forteller om det faktisk er nyttig.
Dette er et annet område der mange team snubler. De bygger noe teknisk imponerende som ingen ønsker å bruke to ganger. I virksomhetssammenheng er dette forskjellen mellom en vellykket utrulling og et kostbart forskningsprosjekt.
Brukerevalueringer handler grunnleggende sett om å forstå om systemet løser riktig problem på riktig måte. Det betyr å gå lenger enn «ga systemet riktig svar?» og spørre «ga det meg noe jeg kan handle ut fra?»
I praksis tar brukerevalueringer vanligvis noen få former:
Studier av oppgavefullføring: Kan brukerne faktisk utføre det virkelige arbeidet sitt raskere eller bedre med systemet? Det handler ikke om modellen kunne besvare et spørsmål, men om en virkelig bruker fikk det vedkommende trengte i den faktiske arbeidsflyten.
Kvalitative tilbakemeldingssløyfer: Regelmessige, strukturerte samtaler med avanserte brukere. Hvilke søk kjører de gjentatte ganger? Hvor mister de tilliten? Når gir de opp og går tilbake til den gamle arbeidsmåten? Disse øktene avdekker ofte feiltyper som aldri vises i testsettene, fordi brukerne stiller spørsmål på måter dere ikke forutså, eller har implisitte kvalitetskrav dere ikke visste fantes.
Bruksanalyse: Hvilke søk kjøres på nytt? Hvilke svar kopieres og brukes andre steder? Hvor klikker brukerne på tommel ned? Synkende bruk betyr ikke alltid at noe har mislyktes – noen ganger får brukerne svaret sitt og går videre – men mønstrene i når og hvordan folk avbryter søk, forteller mye om hvor systemet ikke innfrir forventningene.
Til sammen gjør dette det mulig å måle nytten uten å gjette og oppdage problemer før de begynner å svekke brukernes tillit.
Selv et system som oppnår perfekt mekanisk nøyaktighet og begeistrer de første brukerne, kan imidlertid stryke på den avgjørende testen: å øke virksomhetens omsetning. Pålitelighet og brukertilfredshet er bare forutsetninger for dette. For å krysse kløften fra en vellykket pilot til en omveltende virksomhetsressurs må dere se forbi hvordan systemet fungerer, og konsentrere dere om hvor det brukes.
Vi har gjennomgått hvordan dataene kan fungere for systemet, og deretter hvordan systemet kan fungere for brukerne. Nå må vi snakke om hvordan systemet kan fungere for virksomheten.
Den siste tiden har næringslivsledere med rette vært svært opptatt av dette. Etter rapporter som MITs påstand om at 95 % av KI-prosjektene i næringslivet ikke gir avkastning, har toleransen for imponerende demoer som aldri settes i drift, forsvunnet. Modellene er klare. Arkitekturene er utprøvd. Spørsmålet nå er: Kan dere faktisk rulle dette ut på en måte som skaper verdi for virksomheten?
Den gode nyheten er at banebrytende systemer for dyp forskning, bygget etter prinsippene ovenfor, er godt rustet til å innfri dette kravet. De prøver ikke å automatisere alt eller erstatte hele stillingskategorier. De skal gjøre de dyktigste medarbeiderne deres dramatisk mer effektive i arbeidet med høy verdi som de allerede utfører.
Veien fra «teknisk fungerende» til «gir avkastning» krever likevel noen ekstra gjennombrudd: valg knyttet til organisering, brukeropplevelse og måling som avgjør om dette blir et hverdagsverktøy eller en glemt nettleserfane.
Etter vår erfaring er det to.
Det er ofte fristende å starte med interne oppgaver der lite står på spill, som «summarise this meeting». Selv om det er trygt, viser slike bruksområder sjelden nok verdi til å forsvare kostnaden.
Systemer for dyp forskning lykkes best når de brukes på store, vanskelige oppgaver – kostbare problemer der bedre kvalitet eller høyere hastighet gir en dokumenterbar inntektsøkning eller strategisk fordel.
Vi ser høyest avkastning når virksomheter velger inngangspunkter som:
Komplekse tilbud og RFP-svar: Systemer for dyp forskning kan automatisk hente inn de mest sammenlignbare tidligere tilbudene som ble vunnet – og tapt – trekke ut klausulene som alltid utløser endringsforslag, finne de sterkeste bevisene for et bestemt krav og mer, før alt omformes til en sterk og helhetlig posisjonering for anbudet. Måltallet er ikke spart tid, men vinnerandel, bevarte marginer og færre juridiske eller kommersielle overraskelser sent i prosessen.
Vitenskapelig landskapsanalyse: I forsknings- og utviklingsintensive virksomheter – som legemidler, bioteknologi og halvledere – er inngangspunktet å omforme flere ukers litteratur og intern kunnskap til en anvendelig forskningsretning. Et system for dyp forskning kan lese tusenvis av artikler, patenter, interne rapporter, laboratorienotater og tidligere programgjennomganger for å kartlegge hva man vet, og hva det er uenighet om, og dermed skape et evidensbasert landskap. Det kan gi raskere iterasjonssykluser, færre blindspor og – viktigst av alt – kortere tid frem til den første kliniske studien på mennesker.
Markedsinnsikt: For banker og hedgefond ligger verdien i å gjøre fragmentert intern analyse – notater, modeller, transkripsjoner og meglerkommentarer – samt eksterne signaler – innrapporteringer, resultater, makrotall og nyheter – om til beslutningsgrunnlag for handel. Et system for dyp forskning kan kontinuerlig bygge og oppdatere et syn på et selskap, et tema eller et makrospørsmål, fremheve de viktigste endringene siden forrige uke, avstemme motstridende kilder og utarbeide et investeringsnotat eller en handelspakke med full sporbarhet.
Fellesnevneren er at dette ikke er samtaler. Det er komplekse arbeidsflyter som vanligvis krever dyre eksterne konsulenter eller flere uker av tiden til erfarne medarbeidere. Når et system for dyp forskning settes inn mot slike problemer, er verdien ubestridelig.
Dette er et av skiftene i brukeropplevelsen som vil prege 2026.
Hvis systemet for dyp forskning bare er en chatbot som brukerne spør for å finne ting, kan det raskt ende opp med å bli brukt sporadisk. Det forblir et oppslagsverktøy, og brukerne må til slutt selv sette sammen resultatene til den ønskede sluttleveransen. Men hvis det oppleves som en analytiker som alltid er tilgjengelig og kan tildeles arbeid, kan det fullstendig endre teamets arbeidsmodell.
Vi ser et skifte fra «samtale» – korte utvekslinger frem og tilbake – til delegering, der man definerer omfang, mal og mål og lar systemet kjøre.
Tre konkrete skifter muliggjør dette:
Resultater som leveranser: Arbeid med høy verdi finnes sjelden i et chattevindu, men i dokumenter, notater og presentasjoner. Moderne systemer for dyp forskning bør hoppe over chattefasen og generere den endelige forretningsleveransen direkte. Når en bruker kan be om et «3-page investment memo in our corporate format» og motta en nedlastbar fil i stedet for en tekststrøm, faller tiden frem til verdi dramatisk. Dette utvides også ofte med planlagt generering, slik at brukerne kan be om at e-poster eller rapporter automatisk utarbeides med ny innsikt og distribueres til relevante mottakere når nye data kommer inn.
Lokal optimalisering med egendefinerte maler: Modellene er blitt robuste nok til at forretningsenheter og enkeltbrukere kan forme egne instruksjoner og virkemåter uten å ødelegge systemet. En risikorapport ser annerledes ut i London enn i New York. Ved å la team laste opp eller utforme egne strukturmaler og definere stoppkriterier – for eksempel «always check these three specific internal databases» – eller utdataformat, kan brukerne få langt større verdi av systemet og skape noe de ønsker å bruke stadig mer.
Tillit som grensesnitt: Når en bruker delegerer en oppgave som tar over 20 minutter å kjøre, blir tillit svært viktig. Dere kan ikke presentere en svart boks. Grensesnittet må synliggjøre systemets resonnementer og valg, blant annet ved å vise hvilke verktøy som brukes, og generere kildehenvisninger. Vi ser ofte at den beste brukeropplevelsen som standard viser overordnet innsikt i forskningens fremdrift, samtidig som brukeren kan gå i dybden ved å utvide en sidestolpe eller lignende for mer informasjon.
Vi ser for oss en fremtid der alle ledende virksomheter har et skreddersydd system for dyp forskning bak de mest kritiske arbeidsflytene. Dette vil ta form som flere analytikere som alltid er tilgjengelige, pålitelig kan gå gjennom tusenvis av interne leveranser og produsere beslutninger og resultater som mennesker kan handle ut fra. Når banebrytende modeller hever taket for hva som kan gjennomføres, flyttes konkurransefortrinnet til det grunnleggende: å gjøre dataene tilgjengelige, gi systemet et kart og operasjonalisere pålitelighet gjennom evalueringer.
Forbedringene i modellkapasitet det siste året er det tydeligste signalet om hvor utviklingen går. Muligheten for ledere i 2026 ligger i å handle tidlig. Velg et inngangspunkt der verdien er tydelig, bygg tillit gjennom sporbarhet og sikkerhetsrekkverk, og gjør løsningen for dyp forskning om fra en pilot til en stadig mer verdifull kapasitet som virksomheten bruker hver dag.