Chatbot eller AI-agent – hva er forskjellen, og hva trenger bedriften?

Fire typer løsninger som ofte kalles «chatbot»

Det som i dagligtale kalles en chatbot, er i praksis fire ulike ting: en regelbasert chatbot, en språkmodell som svarer ut fra egne dokumenter (RAG), en AI-agent som utfører handlinger, og en automasjonsflyt med faste steg. De ligner på overflaten, men løser forskjellige problemer og har svært ulik risiko og byggekostnad.

Regelbasert chatbot

Den klassiske chatboten følger forhåndsdefinerte regler, beslutningstrær eller skriptede svar. Den fungerer godt når spørsmålene er forutsigbare, for eksempel åpningstider eller sporing av en pakke, men stopper opp så snart kunden formulerer seg annerledes enn skriptet forventer.

LLM-chatbot med RAG over egne dokumenter

En RAG-assistent (retrieval-augmented generation) kobler en språkmodell til bedriftens egen kunnskapsbase: håndbøker, vilkår, produktark, intranett. Når noen stiller et spørsmål, henter løsningen de mest relevante tekstbitene og lar modellen formulere et svar ut fra dem, gjerne med kildehenvisning. Det reduserer risikoen for oppdiktede svar, men fjerner den ikke helt. En RAG-assistent leser og svarer; den gjør ingenting i systemene deres.

AI-agent

En AI-agent er et system der språkmodellen selv styrer hvilke steg som tas og hvilke verktøy som brukes for å løse en oppgave. Anthropic skiller mellom arbeidsflyter, der modeller og verktøy følger forhåndsdefinerte kodestier, og agenter, der modellen dynamisk styrer egen prosess og verktøybruk. OpenAI beskriver agenter som systemer som selvstendig utfører oppgaver på dine vegne. I praksis betyr det at agenten kan slå opp en kunde i CRM, sjekke en ordre, opprette en sak og skrive et utkast til svar, i én og samme flyt.

Verktøyene kobles på via API-er, og stadig oftere via Model Context Protocol (MCP), en åpen standard for å koble AI-applikasjoner til eksterne systemer som databaser, filer og fagsystemer. Fordelen med en standard er at samme integrasjon kan gjenbrukes på tvers av modeller og klienter.

Automasjonsflyt

En automasjonsflyt bygget i f.eks. Make eller n8n kjører faste steg: når et skjema sendes inn, opprett en kontakt, send en e-post, varsle en kanal. Man kan legge inn et AI-steg underveis, for eksempel for å klassifisere eller oppsummere tekst, men rekkefølgen er bestemt på forhånd. Det gjør flyten forutsigbar, billig å drifte og enkel å feilsøke.

Hvor passer hver løsning i en norsk bedrift?

Riktig løsning avhenger av om oppgaven handler om å finne informasjon, ta beslutninger eller flytte data mellom systemer. Her er de vanligste bruksområdene vi ser.

Kundeservice

Mange kundeservicehenvendelser er kunnskapsspørsmål: Hva dekker forsikringen? Hvordan returnerer jeg en vare? Her holder ofte en RAG-assistent over vilkår og hjelpesider. Når kunden vil ha noe gjort, som å endre en levering eller få status på en sak, trenger du en agent med tilgang til ordresystemet, og en tydelig regel for når saken skal eskaleres til et menneske.

Dokumenthåndtering

Fakturaer, kontrakter og søknader som skal leses, sorteres og registreres, løses ofte best med en automasjonsflyt der et AI-steg trekker ut feltene. Prosessen er stort sett lik hver gang, og da gir faste steg mer kontroll enn en agent. Agenten blir aktuell når dokumentene er uensartede og krever vurdering, for eksempel å sjekke en kontrakt mot interne retningslinjer.

Interne assistenter

En intern assistent som svarer på spørsmål om rutiner, HR-regler eller teknisk dokumentasjon er et typisk RAG-prosjekt. Den viktigste jobben her er ikke modellen, men å rydde i kildene og sørge for at assistenten bare ser dokumenter brukeren selv har tilgang til. Om dere vurderer hyllevareverktøy i stedet, har vi skrevet om ChatGPT, Claude og Copilot i bedriften.

AI-agent for salg og prospektering

En AI-agent for salg er en agent som gjør forarbeidet rundt et salg: den researcher potensielle kunder, kvalifiserer leads, skriver utkast til oppfølging og holder CRM oppdatert, slik at selgerne bruker tiden på samtaler. Salg egner seg godt fordi arbeidet består av mange små steg på tvers av systemer, og fordi mye av det er research og registrering heller enn selve kundedialogen.

Typiske oppgaver en salgsagent kan ta:

• Leadkvalifisering: lese innkommende henvendelser, berike dem med offentlig tilgjengelig firmainformasjon og score dem mot kriterier dere har definert.
• Research før møter: sammenstille hva dere vet om kunden fra CRM, tidligere e-poster og nettsiden deres til en kort brief.
• Oppfølging: skrive utkast til oppfølgings-e-post etter et møte, basert på notater, som selgeren godkjenner før utsending.
• CRM-hygiene: oppdatere felt, logge aktivitet og foreslå neste steg i f.eks. HubSpot eller et annet CRM.

Det agenten ikke bør gjøre, er å sende masseutsendelser eller kontakte personer på egen hånd uten at et menneske har godkjent det. Utsendelse av e-post til privatpersoner og behandling av personopplysninger om kontaktpersoner er regulert, og et feilsteg her rammer omdømmet direkte. Den beste salgsagenten er derfor ofte halvautomatisk: den gjør research og utkast, mennesket trykker send.

Risiko og sikkerhetstiltak

Jo mer en løsning kan gjøre i systemene deres, desto viktigere er det å begrense hva den har lov til og å kunne se hva den har gjort. En chatbot som svarer feil er et problem; en agent som utfører feil handling kan være et større problem. De viktigste tiltakene er:

• Menneske i loopen: sensitive, irreversible eller kostbare handlinger, som refusjoner, kontraktsendringer eller utsendelser, skal godkjennes av et menneske, i det minste til dere har dokumentert at agenten er pålitelig. OpenAI anbefaler også å eskalere når agenten gjentatte ganger ikke forstår oppgaven.
• Tilgangsstyring: agenten skal bare ha de rettighetene oppgaven krever, og bare se data brukeren den handler på vegne av har tilgang til.
• Logging: hvert verktøykall, hver kilde og hver beslutning bør logges, slik at dere kan feilsøke, revidere og forbedre.
• Hallusinasjoner: språkmodeller kan formulere feil svar med stor selvsikkerhet. Svar bør forankres i kilder, og løsningen bør kunne si «jeg vet ikke» og sende videre.
• Personvern: avklar behandlingsgrunnlag, databehandleravtale og hvor data lagres før dere bygger. Les mer i AI og GDPR.
• Åpenhet: brukere skal vite at de snakker med en AI. EUs AI-forordning, som Norge innfører gjennom EØS-avtalen, stiller krav om at personer informeres når de samhandler direkte med et AI-system.

Slik velger du riktig løsning

Velg den enkleste løsningen som faktisk løser problemet, og gå bare videre til en agent når oppgaven krever vurderinger og steg som ikke kan bestemmes på forhånd. Disse spørsmålene hjelper deg å plassere behovet:

1. Handler det om å svare eller å gjøre? Bare svar: chatbot eller RAG-assistent. Handlinger i systemer: automasjonsflyt eller agent.
2. Er stegene de samme hver gang? Ja: automasjonsflyt. Nei, de avhenger av innholdet i saken: agent.
3. Finnes kunnskapen skriftlig? Hvis svarene ligger i dokumenter, er RAG et naturlig utgangspunkt. Hvis kunnskapen sitter i hodene på folk, må den dokumenteres først.
4. Hva koster en feil? Høy kostnad betyr mer menneskelig godkjenning og smalere tilganger, uansett løsning.
5. Har systemene API-er? En agent er bare så god som verktøyene den får. Uten API-er eller integrasjoner blir den en chatbot.

Hva det krever å bygge

Det som avgjør om en AI-løsning fungerer i praksis er sjelden modellen, men data, integrasjoner og evaluering. Tre ting må være på plass:

• Data: oppdaterte, strukturerte kilder med tydelig eierskap. En RAG-assistent over utdaterte dokumenter gir utdaterte svar.
• Integrasjoner: tilgang til systemene agenten skal jobbe i, via API-er eller MCP, med egne tjenestebrukere og begrensede rettigheter.
• Evaluering: et testsett med reelle spørsmål og saker med fasit, som kjøres hver gang løsningen endres. Anthropic anbefaler grundig testing i isolerte miljøer før agenter slippes løs i produksjon.

Erfaringen fra Gjensidiges AI-plattform peker i samme retning: der lå mye av arbeidet i å gjøre kjernedata AI-klare og bygge inn governance, logging og compliance fra start, før modellene kunne leveres i produksjon.

Slik måler du effekt og ROI

Effekten av en chatbot eller AI-agent måles best ved å sammenligne en konkret nullmåling før lansering med de samme målene etterpå. Uten nullmåling blir ROI en følelse. Nyttige mål er:

• Spart tid per sak: mål hvor lang tid oppgaven tar manuelt i dag, og hvor lang tid som gjenstår når løsningen er i bruk, inkludert tid til kontroll.
• Løsningsgrad: andelen henvendelser som løses uten at et menneske må overta, sammen med andelen som eskaleres.
• Kvalitet: andel riktige svar eller handlinger mot fasit i evalueringssettet, og stikkprøver av reelle saker.
• Kundeopplevelse: svartid, gjenåpnede saker og tilbakemeldinger fra brukerne.
• Salgseffekt: for salgsagenter, tid fra lead til første kontakt og antall kvalifiserte møter per selger.
• Totalkostnad: utvikling, modellbruk, drift og vedlikehold, satt opp mot verdien av tiden som frigjøres.

Fra idé til drift, steg for steg

Den tryggeste veien er å starte smalt, bevise verdien på ekte data og først deretter bygge ut. Vi jobber etter samme rekkefølge i prosessen vår: Discover, der vi kartlegger prosessen og velger hvilken løsningstype som passer; Proof of Concept, der vi tester på reelle data og måler mot nullmålingen; MVP, der løsningen settes i drift for en avgrenset brukergruppe med logging og eskalering; og Scale, der vi utvider til flere prosesser og systemer når tallene støtter det.