# Hva skiller en AI-demo fra en løsning som fungerer i drift? En god demo viser at teknologien kan svare på et spørsmål. En løsning i drift må også vite hvilke data som gjelder, hvem som får se hva, og hva som skjer når svaret er feil. - **Type:** Artikkel - **Tema:** AI i praksis - **Publisert:** 26\. oktober 2026 - **Les hvis:** Dere har sett en overbevisende AI-demo og vurderer å gå videre. - **Hovedpoenget:** Demoen viser at teknologien kan svare. Drift krever riktige data, tilgang, håndtering av feil og unntak, et ansvarlig menneske og en plass i arbeidsflyten. - **Artikkelen tar opp:** Hva en demo viser, Seks lag bak ett svar, Når det faktisk er enkelt, og Hva dere bør undersøke. - **Nettside:** Det tar under et minutt. Leverandøren laster opp en leiekontrakt, skriver et spørsmål i vanlig språk, og svaret kommer tilbake i hele setninger, med henvisning til riktig punkt. Noen rundt bordet ler litt, slik man gjør når noe går lettere enn det burde. Etter møtet er stemningen klar: dette må vi få til. Den reaksjonen er rimelig. Det dere så, var ekte. Språkmodeller kan lese, oppsummere og svare på spørsmål om tekst på en måte som tidligere krevde mye skreddersøm. Men demoen svarte på ett spørsmål: kan teknologien dette? Før dere bestemmer dere, trenger dere svar på et annet: hva må være sant hos oss for at svaret kan brukes, hver dag, av folk som har annet å gjøre? ## Hva en demo er laget for å vise En demo skal bevise at noe er mulig. For å gjøre det, fjerner den alt som ikke hører til beviset. Dataene er valgt ut på forhånd. Spørsmålene er de som viser teknologien fra sin beste side. Ingen logger inn med sine egne rettigheter, og ingen svar sendes videre til en kunde. Det er ikke uærlig. Det er slik en demo skal være. Problemet oppstår når vi leser den som en beskrivelse av hvordan løsningen vil fungere hos oss. Det meste av arbeidet i en løsning som skal i drift, ligger nettopp i det demoen kunne se bort fra. > En demo viser at teknologien kan svare. Drift handler om alt som må være på plass for at svaret kan brukes. ## Et eksempel: kontraktsassistenten > **Hypotetisk eksempel: En forvalter av næringseiendom** > > Se for dere et selskap som forvalter næringsbygg for flere eiere. Kundesenteret får daglig spørsmål fra leietakere: Hvem skal betale for en reparasjon? Når kan vi si opp? Får vi sette opp skilt på fasaden? Svarene står i leiekontraktene, men det tar tid å finne dem, og de mest erfarne saksbehandlerne blir spurt om alt. > > Selskapet ser en demo av en assistent som leser kontrakter og svarer på slike spørsmål. Den får et utvalg kontrakter, svarer presist og viser hvilket punkt svaret bygger på. Ledelsen vil gjerne ta den i bruk. Eksempelet er oppdiktet, men situasjonen er vanlig. La oss følge det samme spørsmålet ut av demoen og inn i en vanlig arbeidsdag. ## Det samme spørsmålet, en vanlig tirsdag En leietaker ringer og spør hvem som skal dekke reparasjonen av ventilasjonsanlegget. I demoen var dette ett spørsmål og ett svar. I drift ligger det seks lag bak det samme svaret, og hvert av dem kan få svaret til å bli feil eller ubrukelig. ### Riktige data Assistenten er aldri bedre enn dokumentene den får. I demoen var kontraktene rene, digitale og oppdaterte. I virkeligheten har mange kontrakter tillegg og endringer i egne filer, noen er skannet, og noen avtaler er bare bekreftet på e-post. > **Hypotetisk eksempel: Tillegget ingen visste om** > > Hovedkontrakten sier at utleier dekker ventilasjonen. Et tillegg fra noen år senere flytter ansvaret for filterbytte til leietaker. Hvis assistenten ikke finner tillegget, gir den et svar som høres riktig ut, og er feil. Spørsmålet er derfor ikke bare om dataene finnes. Det er om noen vet hvilken versjon som gjelder, og hvem som holder den oppdatert når neste tillegg signeres. ### Å finne riktig tekst Med et utvalg dokumenter er det lett å finne riktig avsnitt. Med alle kontraktene i porteføljen må løsningen først finne riktig leietaker, riktig kontrakt og siste gjeldende tillegg, før den i det hele tatt begynner å formulere et svar. Mange feil som ser ut som dårlige svar, er egentlig at løsningen har lest feil dokument. ### Tilgang I demoen hadde alle tilgang til alt. I drift må løsningen følge de samme reglene som gjelder ellers i bedriften: hvem som får se hvilke kontrakter, hvilke eiere og hvilke personopplysninger. Det gjelder også hvor dokumentene sendes for å bli lest, og hva leverandøren gjør med dem. Virksomheten har ansvaret for personvernet også når verktøyet er kjøpt inn \[2\]. > **Hypotetisk eksempel: Én saksbehandler, flere eiere** > > En saksbehandler som jobber for én eier, skal ikke nødvendigvis se kontraktene til en annen. Henter assistenten svar fra alle kontraktene, kan den vise opplysninger saksbehandleren aldri skulle hatt. Tilgangen må styres i løsningen, ikke bare i en instruks. ### Feil som ser riktige ut Språkmodeller kan gi feil svar formulert like sikkert som de riktige. Det kan reduseres, men ikke fjernes helt \[1\]. En løsning i drift må derfor gjøre feil synlige: vise hvor svaret kommer fra, si fra når den er usikker, og gjøre det enkelt å melde fra når noe er galt. Det nyttige spørsmålet til en leverandør er ikke om løsningen gjør feil. Det er hvordan dere vil oppdage dem, og hvor raskt. ### Unntakene Demoen fikk spørsmål den kunne svare på. Virkeligheten sender også de andre: spørsmål som ikke står i kontrakten, spørsmål som krever skjønn, og saker der svaret avhenger av noe som aldri ble skrevet ned. En god løsning vet når den ikke skal svare, og sender saken videre til riktig person. > **Hypotetisk eksempel: Den muntlige avtalen** > > En leietaker viser til en avtale med en tidligere forvalter. Den står ingen steder. Her bør assistenten si nettopp det, og ikke fylle hullet med et svar som høres rimelig ut. ### Ansvar og arbeidsflyt Når et svar går til en leietaker, er det selskapet som svarer, ikke verktøyet. Noen må eie svaret, og noen må eie løsningen: holde dokumentene oppdatert, følge med på kvaliteten og bestemme hva den skal og ikke skal brukes til. Og svaret må komme der arbeidet skjer. I demoen sto assistenten alene i et eget vindu. Må saksbehandleren kopiere spørsmålet over fra saksbehandlingssystemet og svaret tilbake, blir løsningen brukt de første ukene og så glemt. > **Hypotetisk eksempel: Svaret er ikke slutten på saken** > > Hos forvalteren lager assistenten et utkast, og saksbehandleren sender svaret. Skal utleier dekke reparasjonen, må det også opprettes en arbeidsordre. Gevinsten ligger i at svaret og neste handling henger sammen, ikke i svaret alene. ## Ikke alt er et stort prosjekt Dette betyr ikke at alle AI-løsninger er tunge å innføre. Mye kan tas i bruk raskt, fordi flere av lagene enten er små eller allerede løst. Tre kjennetegn går igjen: - **Et menneske leser alltid resultatet.** Utkast til e-post, oppsummering av møtenotater eller første versjon av en tekst. Feil fanges av den som bruker det, og et dårlig utkast koster lite. - **Kilden er avgrenset og har en eier.** Søk i én samling dokumenter som noen allerede holder oppdatert, for eksempel en personalhåndbok eller interne rutiner. - **Funksjonen finnes i verktøy dere har.** Mange systemer har fått AI-funksjoner innebygget. Da er tilgang, lagring og arbeidsflyt ofte allerede løst, og jobben handler mest om hvordan dere vil bruke dem. En enkel tommelfingerregel: jo lavere konsekvens et feil svar har, og jo nærmere løsningen ligger arbeidet folk allerede gjør, desto mindre skiller demoen seg fra drift. Jo mer svaret brukes til å avgjøre noe for andre, desto mer av arbeidet ligger i lagene rundt. > **Hypotetisk eksempel: En mindre start** > > Forvalteren kunne begynt med å la saksbehandlerne bruke assistenten internt, som et raskere oppslag de selv kontrollerer, før noe svar går direkte til en leietaker. ## Bruk demoen til å stille bedre spørsmål En demo er fortsatt nyttig. Den viser hva som er mulig, og den gir dere noe konkret å snakke om. Dere får mest ut av den ved å flytte den nærmere virkeligheten. Be om å se løsningen på deres egne dokumenter, også de rotete. Still spørsmål den ikke har fått på forhånd, og noen den ikke bør kunne svare på. Be om å se hva som skjer når svaret er feil. Det sier mer om løsningen enn alle spørsmålene som gikk bra. ## Før demoen blir et prosjekt Dere trenger ikke svar på alt før dere går videre. Men dere bør vite hvilke av disse spørsmålene dere ikke har svar på ennå: 1. Hvilken oppgave skal dette løse, og hvem gjør den i dag? 2. Hvor ligger dataene, hvilken versjon gjelder, og hvem holder dem oppdatert? 3. Hvem skal få se hva, og følger løsningen de tilgangene som gjelder i dag? 4. Hva er konsekvensen av et feil svar, og hvordan oppdager vi det? 5. Hva skal skje med spørsmålene løsningen ikke kan svare på? 6. Hvem eier svaret, og hvem eier løsningen etter at den er levert? 7. Hvor i arbeidsdagen skal den brukes, og hva skjer etter svaret? Har dere gode svar på de fleste, er avstanden fra demo til drift kortere enn den ser ut. Har dere ikke det, er det ikke et tegn på at dere bør la være. Det er en beskrivelse av hva det første prosjektet egentlig handler om. ## Kilder Sist vurdert 25. oktober 2026. - [Anthropic: «Reduce hallucinations», Claude-dokumentasjonen]() - [KI Norge (Digitaliseringsdirektoratet): «Personvern og KI»]() ## Les videre - [Velg det første AI-prosjektet](): Fem steg fra en liste med ideer til ett valgt AI-prosjekt med mål og stoppunkt. ## Vil dere prøve en demo mot virkeligheten? I en AI-kartlegging går vi gjennom lagene sammen med dere, med deres egne data og arbeidsflyt. Dere kan også ta en kort samtale først. - [AI-kartlegging]()