Løftet om KI-agenter er forlokkende: Still et spørsmål i klarspråk og få svaret; fortell agenten hva som skal endres, og den endrer det. Demoene ser uanstrengte ut fordi demodataene er rene.
Det er ikke selskapets ekte data. CRM-et er halvveis satt opp. Faktureringssystemet og CRM-et er uenige om hva en kunde betaler. Den samme kontoen finnes tre ganger under litt ulike navn. Fornyelsesdatoer ligger i et regneark som én person vedlikeholder. Produktbruken ligger i en database som ingen har koblet til kontoen den hører til.
Legg en agent oppå det, og den vil fortsatt svare, selvsikkert. Den vil bare ta feil på måter som er vanskelige å oppdage.
Hvorfor må datafundamentet komme før KI-agentene?
Fordi en agent bare kan rapportere og handle på det systemene dine registrerer. Hvis CRM-, fakturerings- og produktdata er uenige, er agentens svar gjetning, og handlingene sprer feilene. Når dataene struktureres først, får hver agent én omforent versjon av fakta, slik at rapportene kan stoles på og handlingene er trygge.
Kortversjonen er den på forsiden vår: ingen data, ingen KI. Etter vår erfaring er det også her mange KI-prosjekter stille stopper opp. Rapporten «The GenAI Divide» fra MIT NANDA (2025) fant at bare rundt 5% av pilotene med generativ KI når produksjon med en målbar avkastning. En pilot på et ryddig utvalg kan se utmerket ut; den samme ideen på de ekte, rotete dataene overlever ofte ikke flyttingen.
Hva som går galt når agenter sitter på rotete data
Feilene er forutsigbare, og de blir verre når agenten kan handle og ikke bare svare:
- Rapporter som ikke stemmer. Be om ARR, og agenten summerer CRM-et. Økonomi summerer fakturaene. Styret får to tall og stoler på ingen av dem.
- Duplikater som formerer seg. Tre oppføringer for én kunde betyr tre helseskårer, tre fornyelsespåminnelser og en account manager som ser slurvete ut.
- Handlinger på feil fakta. En agent som får beskjed om å sende fornyelsespåminnelser, sender dem ut fra de datoene CRM-et har. Hvis datoene er utdaterte, er påminnelsene det også, og nå har de nådd kundene.
- Svar ingen kan kontrollere. Når dataene er spredt, kan ingen spore hvor et tall kommer fra, og da kan ingen si om det er riktig.
Å hente data fra dårlige kilder gir dårlige rapporter. Å sende data inn i dårlige kilder gjør dem verre. Begge halvdelene av det en agent gjør, avhenger av fundamentet under.
Hva et datafundament faktisk er
Et datafundament er ikke et datavarehusprogram eller en migrering som tar et år. For et selskap i vekst, og særlig et SaaS-selskap, handler det om noen få ting gjort ordentlig:
- Et CRM satt opp for hvordan du selger, fornyer og fakturerer. Pipelines, faser, objekter og felt utformet etter hvordan selskapet faktisk jobber, i stedet for etter en standardmal.
- Hvert faktum registrert én gang. Kontoer, kontakter og kontrakter uten duplikater; produkter, priser og fornyelsesvilkår samlet på ett sted.
- Systemene koblet sammen. Fakturaer og betalinger knyttet til riktig kunde, produktbruk koblet til kontoen den hører til, og en kunde, en kontrakt og en faktura som betyr det samme i alle systemer.
- Noe som holder dem samstemte. Data glir fra hverandre med mindre noe vedlikeholder dem. I det vi bygger, er det Prosessoren, som kjører arbeidsflytene mellom systemene, prøver på nytt det som feiler, og holder et fullstendig revisjonsspor for hvert steg.
Detaljene finner du på siden vår om datafundamentet.
Slik ser du om dataene dine er klare
Noen få spørsmål gir et raskt og ærlig svar. Hvis noen av dem tar mer enn et par minutter, eller gir to ulike svar fra to ulike personer, trenger fundamentet arbeid før agenter legges oppå:
- Stemmer ARR fra CRM-et med ARR fra økonomi?
- Finnes hver kunde nøyaktig én gang, i alle systemer?
- Ligger fornyelsesdatoer og -vilkår i CRM-et, og er de riktige?
- Kan du se produktbruken per konto, ved siden av hva kontoen betaler?
- Når en avtale lukkes, får resten av selskapet vite det uten at noen sender en melding?
Å sjekke dette er en del av vår AI Readiness Assessment: om CRM- og økonomisystemene stemmer godt nok overens til at KI kan stole på dem, før noe bygges.
Rekkefølgen som fungerer: data, så KI-laget, så agenter
Hvert oppdrag vi gjennomfører, bygger de samme tre lagene, i samme rekkefølge:
- 1. Datafundamentet. CRM-et og systemene rundt det satt opp, strukturert og holdt samstemt.
- 2. KI-laget. Dataene koblet til KI-assistenten teamet allerede bruker, via MCP (Model Context Protocol), den åpne standarden for å koble KI til ekte systemer. Alle med tilgang kan hente data, sende data og utløse handlinger i klarspråk.
- 3. Avdelingsagenter. Spesialbygde agenter for økonomi, salg og kundesuksess, hver med rapportene og handlingene teamet trenger, innenfor teamets tilganger og med revisjonsspor.
Å hoppe over det første laget føles raskere. Det er det sjelden. Tiden som spares i starten, brukes senere på å forklare hvorfor agentens tall ikke stemmer med økonomis, og på å reparere oppføringer den har endret. Bygget i riktig rekkefølge gjør hvert lag det neste billigere, og agentene på toppen kan stoles på fra første dag.
Bygget på denne måten forblir fundamentet også ditt, og i Europa. Dataene blir værende på EU-infrastruktur under byggingen, KI-modellen velger du selv, og hvis du bytter modell senere, forblir fundamentet og alt som er bygget på det, det samme.