Slik kobler du AI til egne data: RAG og MCP forklart

Hvorfor vet ikke modellen noe om akkurat din bedrift?

En AI-modell kan mye om verden generelt, men ingenting om fakturaene, avtalene eller prosjektene i din bedrift. Den ble trent på offentlig tilgjengelig materiale frem til et gitt tidspunkt og har aldri sett de interne dokumentene dine. Skal modellen svare på noe som gjelder deg, må informasjonen ligge foran den i det øyeblikket den svarer, i det som kalles kontekstvinduet: modellens arbeidsminne, all teksten den kan se mens den jobber.

Den nærliggende ideen er å lime inn alt bedriften har i dette arbeidsminnet og la modellen finne ut av resten. Det fungerer dårligere enn folk tror. Etter hvert som mengden tekst vokser, faller både presisjonen og evnen til å hente frem det relevante, et fenomen som kalles «context rot». I skrivende stund har flere av de nyeste modellene et kontekstvindu på rundt en million tekstenheter (tokens), mens andre ligger på rundt 200 000, men selv et stort vindu løser ikke problemet. Jobben er å legge inn akkurat det riktige, og det er den jobben RAG gjør.

Hva er RAG i praksis?

RAG er en fremgangsmåte der systemet henter frem relevant informasjon fra bedriftens egne kilder og legger den i konteksten før modellen svarer. Nøkkelen er hvordan systemet finner frem. Vanlig søk leter etter de nøyaktige ordene du skrev; RAG leter etter mening. Skriver en ansatt «hvordan sier jeg opp abonnementet», kan systemet finne frem til et avsnitt om «avslutning av avtale» selv om ingen av ordene er de samme. Dette kalles semantisk søk, og det bygger som regel på embeddings: numeriske representasjoner av tekst som gjør det mulig å måle hvor like to tekstbiter er i betydning. Både RAG, MCP og flere av begrepene i denne artikkelen har egne oppslag i AI-ordboken vår.

Anthropic, som lager Claude-modellene, tilbyr i skrivende stund ingen egen embeddings-modell, og viser i stedet til den eksterne leverandøren Voyage AI. Et RAG-oppsett settes med andre ord ofte sammen av komponenter fra flere leverandører. Det er helt vanlig, og greit å vite når noen presenterer «sin» RAG-løsning i leverandørmøtet.

Et beslektet grep handler om å kunne stole på svaret. Noen oppsett forankrer svaret i kildedokumentene og returnerer de eksakte passasjene som støtter hver påstand, slik at svaret kan verifiseres og kilden vises til brukeren. For en bedrift er det ofte forskjellen mellom et svar man kan bruke og et man ikke tør å stole på.

Hva er MCP, og hvilket problem løser det?

RAG henter inn informasjon. Men ofte vil du at AI-en skal gjøre noe også: slå opp en ordrestatus, søke i en database, hente en fil. Da må modellen kobles til systemene dine, og det er her MCP kommer inn.

MCP står for Model Context Protocol og er en åpen standard for å koble AI-applikasjoner til eksterne systemer: datakilder som filer og databaser, verktøy som søkemotorer og kalkulatorer, og ferdige arbeidsflyter. Standarden ble laget hos Anthropic, er åpen kildekode og forvaltes i dag under en Linux Foundation-struktur.

Problemet MCP løser, er fragmentering. Uten en felles standard må hver kobling mellom en AI-applikasjon og et system spesialbygges: én integrasjon mot e-posten, en annen mot CRM-et, en tredje mot filarkivet. Koblingene går i praksis gjennom systemenes API-er, grensesnittene programmer bruker for å snakke med hverandre. MCP erstatter ikke API-ene, men standardiserer hvordan AI-applikasjonen bruker dem. MCP-dokumentasjonen bruker selv bildet av en USB-C-port for AI-applikasjoner: én standardisert kobling i stedet for en egen ledning til hver dings. Tanken er «bygg én gang, koble til overalt», og samme standard støttes på tvers av klienter som Claude, ChatGPT, Visual Studio Code og Cursor.

Rent praktisk fungerer det etter en klient-server-modell: AI-applikasjonen oppretter en forbindelse til én eller flere MCP-servere. Hver server kan tilby tre ting: verktøy (konkrete handlinger modellen kan be om å få utført, som filoperasjoner eller databasespørringer), ressurser (datakilder som gir kontekst) og maler for gjenbrukbare arbeidsflyter.

RAG eller MCP: hva trenger du?

Det er lett å tro at RAG og MCP er to konkurrerende svar på samme spørsmål. Det er de ikke. Slik vi vurderer det, løser de to forskjellige deler av «koble AI til egne data», og de fleste reelle oppsett bruker begge.

RAG handler om å hente inn riktig kunnskap, altså å finne de relevante avsnittene i dokumentene dine og legge dem foran modellen før den svarer. MCP handler om å koble modellen til systemer den kan hente fra eller handle i, på en standardisert måte. En grov tommelfingerregel: trenger AI-en å vite noe som står i dokumentene deres, peker det mot RAG. Trenger den å gjøre noe i et system, eller hente ferske tall fra det, peker det mot en MCP-kobling. Ofte er svaret begge deler, der en MCP-server er selve mekanismen som gir modellen tilgang til å søke, mens RAG-tenkningen avgjør hva som hentes frem og legges i konteksten.

En godt bygget løsning kaller bare et verktøy når en handling eller et oppslag trengs. Det holder både kostnad og risiko nede. Hva verktøybruk og tokens gjør med regningen, går vi nærmere inn på i artikkelen om hva AI koster for en liten bedrift.

Hva skjer med sikkerheten når AI får tilgang til systemene?

Dette er det viktigste spørsmålet å stille en leverandør, og det fortjener et nøkternt svar. Når en modell kan kalle verktøy, kan den i prinsippet utføre handlinger i systemene dine. MCP-spesifikasjonen slår selv fast at verktøy i praksis representerer kjøring av vilkårlig kode og må behandles med tilsvarende varsomhet.

Standarden bygger på noen klare prinsipper. Brukeren skal eksplisitt samtykke til og forstå all datatilgang og alle operasjoner, beholde kontroll over hva som deles og gjøres, og få tydelige grensesnitt for å gjennomgå og godkjenne aktivitet. I praksis leveres det gjennom noen konkrete kontrollmekanismer:

• Godkjenningsdialog før verktøykall, slik at et menneske sier ja før noe skjer.
• Forhåndsgodkjenning av operasjoner som er trygge, så du slipper å bekrefte det ufarlige hver gang.
• Aktivitetslogg over alle verktøykall og resultatene deres, så du i ettertid kan se hva som ble gjort.
• Skille mellom lese- og skrivetilgang: skrivende eller destruktive verktøy kan sperres for assistenter som bare skal lese, eller kreve menneskelig bekreftelse før noe endres.

Hva bør være på plass før dere kobler AI til egne data?

Ett forbehold bør du høre fra en seriøs leverandør uoppfordret: MCP kan ikke selv håndheve sikkerhetsprinsippene på protokollnivå. Standarden beskriver hvordan det bør gjøres, men det er den som bygger løsningen som må implementere samtykke, godkjenning og logging. Sikkerheten ligger ikke i at noen sier «vi bruker MCP». Den ligger i hvordan løsningen er bygget. Be leverandøren vise hvordan samtykke, tilgangsstyring og logging er løst i akkurat deres oppsett.

Utover teknologien er det tre spørsmål som avgjør om dette blir vellykket, de samme tre vi bruker i vurderingen av når en AI-agent lønner seg: Hvilket problem skal løses? Hvilket datagrunnlag finnes, og holder det mål? Og hvem eier dataene og ansvaret? Å koble AI til egne data er nettopp der datagrunnlagsspørsmålet avgjøres. Er informasjonen spredt, utdatert eller motstridende, blir svarene deretter, uansett hvor god modellen er.

Starten med lav risiko følger av kontrollmekanismene over: begynn med lesetilgang fremfor skrivetilgang, hold et menneske i godkjenningssløyfen for handlinger som endrer noe, og sørg for at all aktivitet logges fra dag én. Velg et avgrenset første bruksområde der dataene er ryddige og konsekvensen av en feil er liten.

Slik jobber vi i Agnito også. Vi bygger agenter og automasjon integrert med systemene deres, med tilgangsstyring og logging på plass, og all databehandling skjer innenfor rammer dere kontrollerer, med GDPR og datasuverenitet fra starten. Før vi bygger noe, vurderer vi problemet, datagrunnlaget og eierskapet, og vi sier fra tidlig hvis en idé ikke bør bygges.