Løftet om AI-agenter er overbevisende: Stil et spørgsmål i almindeligt sprog, og få svaret; fortæl agenten, hvad der skal ændres, og den ændrer det. Demoerne ser ubesværede ud, fordi demodataene er rene.
Det er virksomhedens rigtige data ikke. CRM-systemet er halvt sat op. Faktureringssystemet og CRM er uenige om, hvad en kunde betaler. Den samme konto findes tre gange under lidt forskellige navne. Fornyelsesdatoer ligger i et regneark, som én person vedligeholder. Produktforbruget ligger i en database, som ingen har koblet til den konto, det hører til.
Sæt en agent oven på det, og den vil stadig svare, selvsikkert. Den vil bare tage fejl på måder, der er svære at opdage.
Hvorfor skal datafundamentet komme før AI-agenterne?
Fordi en agent kun kan rapportere og handle på det, dine systemer registrerer. Hvis CRM-, fakturerings- og produktdata er uenige, er agentens svar gætværk, og dens handlinger spreder fejlene. Ved at strukturere dataene først får hver agent én fælles version af fakta, så dens rapporter er til at stole på, og dens handlinger er sikre.
Den korte version er den på vores forside: ingen data, ingen AI. Efter vores erfaring er det også her, mange AI-projekter går stille i stå. Rapporten “The GenAI Divide” fra MIT NANDA (2025) viste, at kun omkring 5% af pilotprojekter med generativ AI når i produktion med et målbart afkast. En pilot på et pænt udsnit kan se fremragende ud; den samme idé på de rigtige, rodede data overlever ofte ikke flytningen.
Hvad der går galt, når agenter sidder på rodede data
Fejlene er forudsigelige, og de bliver værre, når agenten kan handle og ikke kun svare:
- Rapporter, der ikke stemmer. Spørg efter ARR, og agenten lægger tallene i CRM sammen. Økonomi lægger fakturaerne sammen. Bestyrelsen får to tal og stoler på ingen af dem.
- Dubletter, der formerer sig. Tre poster for én kunde betyder tre sundhedsscorer, tre fornyelsespåmindelser og en account manager, der virker sjusket.
- Handlinger på de forkerte fakta. En agent, der får besked på at sende fornyelsespåmindelser, sender dem ud fra de datoer, der står i CRM. Hvis datoerne er forældede, er påmindelserne det også, og nu er de nået ud til kunderne.
- Svar, som ingen kan kontrollere. Når data er spredt, kan ingen spore, hvor et tal kommer fra, så ingen kan afgøre, om det er rigtigt.
At hente data fra dårlige kilder giver dårlige rapporter. At sende data ind i dårlige kilder gør dem værre. Begge halvdele af det, en agent gør, afhænger af fundamentet nedenunder.
Hvad et datafundament egentlig er
Et datafundament er ikke et datawarehouse-program eller en migrering, der varer et år. For en voksende virksomhed, og især en SaaS-virksomhed, handler det om nogle få ting gjort ordentligt:
- Et CRM sat op til, hvordan du sælger, fornyer og fakturerer. Pipelines, faser, objekter og felter designet ud fra, hvordan virksomheden faktisk arbejder, i stedet for ud fra en standardskabelon.
- Hver oplysning registreret én gang. Konti, kontakter og kontrakter uden dubletter; produkter, priser og fornyelsesvilkår samlet ét sted.
- Systemerne forbundet. Fakturaer og betalinger matchet til den rigtige kunde, produktforbrug koblet til den konto, det hører til, og en kunde, en kontrakt og en faktura, der betyder det samme i alle systemer.
- Noget, der holder dem enige. Data glider, medmindre noget vedligeholder dem. I vores løsninger er det Processoren, der kører arbejdsgangene mellem systemerne, prøver det, der fejler, igen og fører et komplet revisionsspor over hvert trin.
Detaljerne finder du på vores side om datafundamentet.
Sådan ser du, om dine data er klar
Nogle få spørgsmål giver et hurtigt og ærligt svar. Hvis et af dem tager mere end et par minutter eller giver to forskellige svar fra to forskellige personer, skal der arbejdes på fundamentet, før der kommer agenter ovenpå:
- Stemmer ARR fra CRM overens med ARR fra økonomi?
- Findes hver kunde præcis én gang i alle systemer?
- Ligger fornyelsesdatoer og -vilkår i CRM, og er de korrekte?
- Kan du se produktforbruget pr. konto ved siden af, hvad kontoen betaler?
- Når en aftale lukkes, får resten af virksomheden det så at vide, uden at nogen sender en besked?
Det tjekker vi som en del af vores AI Readiness Assessment: om CRM- og økonomisystemerne stemmer godt nok overens til, at AI kan stole på dem, før noget bliver bygget.
Den rækkefølge, der virker: data, så AI-laget, så agenter
Hvert forløb, vi kører, bygger de samme tre lag i samme rækkefølge:
- 1. Datafundamentet. CRM og systemerne omkring det sat op, struktureret og holdt i overensstemmelse.
- 2. AI-laget. De data koblet til den AI-assistent, teamet allerede bruger, via MCP (Model Context Protocol), den åbne standard for at forbinde AI med rigtige systemer. Alle med rettigheder kan hente data, sende data og udløse handlinger i almindeligt sprog.
- 3. Afdelingsagenter. Specialbyggede agenter til økonomi, salg og customer success, hver med de rapporter og handlinger, teamet har brug for, inden for dets rettigheder og med revisionsspor.
At springe det første lag over føles hurtigere. Det er det sjældent. Den tid, der spares i starten, bruges senere på at forklare, hvorfor agentens tal ikke stemmer med økonomis, og på at reparere poster, den har ændret. Bygget i rækkefølge gør hvert lag det næste billigere, og agenterne ovenpå kan man stole på fra første dag.
Bygget på denne måde forbliver fundamentet også dit, og i Europa. Dataene forbliver på EU-infrastruktur under udviklingen, AI-modellen er dit valg, og hvis du skifter model senere, forbliver fundamentet og alt, der er bygget på det, det samme.