Kort svar: integrasjonen bør bygges rundt én arbeidsflyt
Start ikke med «vi må koble CRM til AI». Start med jobben: for eksempel «når et nytt lead kommer inn, vil vi hente historikk, strukturere behovet og opprette et forslag til neste oppgave». Da vet dere hvilke data som må leses, hva som skal skrives tilbake og hvor et kontrollpunkt trengs.
Denne avgrensningen gjør integrasjonen enklere å sikre, teste og måle.
En typisk AI-integrasjon har fem lag
- Kilde: CRM, database, e-post, dokument, nettskjema, ERP eller annen autoritativ datakilde.
- Normalisering: faste regler gjør data entydig før AI tolker fritekst eller ustrukturerte signaler.
- AI-behandling: oppsummering, klassifisering, matching, forslag eller annen oppgave der modellen faktisk gir verdi.
- Validering og kontroll: schema, regler, tillatelser og eventuelt menneskelig godkjenning.
- Handling: opprett oppgave, lagre felt, generer kladd, send til publiseringskø eller varsle riktig person.
API, webhook eller filutveksling?
Det finnes ikke én riktig integrasjonstype. Vi velger den enkleste robuste forbindelsen som passer arbeidsoppgaven.
Minst mulig tilgang er et designkrav
Hvis en arbeidsflyt bare trenger å lese kundens navn og opprette en oppgave, bør integrasjonen ikke få lov til å slette kunder, endre faktura eller hente alle dokumenter. Dette er minste-tilgang-prinsippet i praksis.
- Skill lese- og skrivetilganger.
- Bruk scoped nøkler og servicekontoer der plattformen støtter det.
- Hold utvikling/test separat fra produksjon.
- Ikke send flere person- eller forretningsdata til en modell enn oppgaven krever.
- La høy-konsekvens handlinger kreve eksplisitt godkjenning.
Fakta og AI-vurdering bør lagres forskjellig
En integrasjon bør aldri gjøre et modellforslag om til «sannhet» uten at systemet vet forskjellen. I RealtyFlow/Nexus skiller vi derfor mellom registrerte fakta og AI-genererte vurderinger, scorer eller anbefalinger.
Et CRM-felt som «budsjett 500 000 euro» kan være et eksplisitt kundeutsagn. En AI-score som «høy kjøpsintensjon» er en vurdering og bør kunne forklares, revideres og erstattes.
Logging og idempotens hindrer stille feil
Når systemer kobles sammen må vi kunne se hva som skjedde dersom noe går galt. En god integrasjon logger minst hendelse, tidspunkt, resultat og relevant teknisk status uten å lagre mer sensitiv informasjon enn nødvendig.
Handlinger som kan mottas flere ganger bør også være idempotente der det er mulig. En betalingswebhook som leveres to ganger skal for eksempel ikke opprette to abonnementer bare fordi den samme hendelsen ble forsøkt igjen.
Feil bør få en tydelig vei videre
Integrasjonen bør vite forskjellen på «prøv igjen», «data mangler» og «menneske må se på dette». Ellers ender automasjon ofte med at feil bare forsvinner i en logg ingen ser.
- Midlertidig nettverksfeil → kontrollert retry.
- Ugyldig data → stopp og avvik.
- Usikker AI-vurdering → be om mer kontekst eller eskaler.
- Høy-konsekvens handling → vent på godkjenning.
Supabase i våre arbeidsflyter
Supabase brukes som database- og autentiseringslag i flere av løsningene våre. Det viktigste er ikke leverandørnavnet, men mønsteret: sentrale entities og historikk ligger i en strukturert datakilde mens AI får begrenset tilgang til det den trenger for oppgaven.
Det gjør at et system kan bruke språkmodeller uten at modellen blir selve databasen.
Stripe: betaling skal være deterministisk
I kjøps- og abonnementsflyter kan AI hjelpe før eller etter betalingen, men selve betalingsstatusen skal komme fra betalingssystemet. DemoSites og appflyter bruker derfor betalingshendelser som verifiserbare signaler i stedet for at AI «tolker» om en kunde har betalt.
Vercel og publiseringsflyt
Flere ChatGenius-webprodukter ligger på Vercel. I en publiseringsflyt er prinsippet at bygge- og deploystatus skal være maskinelt kontrollerbar. En tekstgenerator kan lage innhold, men den bør ikke få lov til å erklære en publisering vellykket før deploysystemet faktisk rapporterer det.
YouTube og medieproduksjon
Re-Master Freddy er et eksempel på en kjede der lyd, metadata, video og publisering henger sammen. Her kan AI støtte metadata og produksjonssteg, mens opplasting, kanal-ID, planlegging og status behandles som eksplisitte systemhendelser.
RealtyFlow og interne API-er
RealtyFlow fungerer både som produkt og som motor for flere arbeidsflyter. Leads, eiendomsdata, innhold, meldinger og signaler kan eksponeres gjennom avgrensede API-er i stedet for at hvert prosjekt kopierer logikken.
Det er en viktig del av Shared Core-tankegangen: gjenbruk robuste tjenester, men la hver vertikal ha sin egen fagmodell og brukerreise.
Integrasjoner i Olivia og Corporate Intelligence
Olivia viser en annen type integrasjon: GEO-data, bilder, sensorer, vær og dokumentasjon må knyttes til fysisk lokasjon og sesong. Corporate Intelligence trenger i stedet firmadata, tilbud, research og kommersielle signaler.
Begge kan dele tekniske mønstre for autentisering, hendelser og oppgaver, men datakildene og betydningen av signalene er helt forskjellige.
Hvordan vi vurderer en ny integrasjon
- Definer hvilken arbeidsoppgave som skal forbedres.
- Finn den autoritative kilden for hvert faktum.
- Bestem hvilken informasjon AI faktisk trenger.
- Velg minste nødvendige lese- og skriverettighet.
- Definer validering, retry og avvikshåndtering.
- Bestem hvilke handlinger som krever menneskelig godkjenning.
- Mål om integrasjonen forbedrer oppgaven – ikke bare om API-kallet fungerer.
Vanlige spørsmål
Hva er en AI-integrasjon?
En kobling mellom AI-funksjonen og bedriftens data eller systemer slik at informasjon kan hentes, behandles og leveres tilbake i en kontrollert arbeidsflyt.
Må alle systemer ha et API?
Nei. API er ofte best, men webhooks, filer eller andre godkjente grensesnitt kan være riktige avhengig av frekvens, datakvalitet og sikkerhet.
Bør AI få skrive direkte til CRM?
Bare når feltene og konsekvensene er tydelige. For viktige data er forslag + validering eller godkjenning ofte tryggere.
Hva hvis API-et feiler?
Arbeidsflyten bør skille midlertidige feil fra ugyldige data og avvik som trenger menneskelig behandling.
Kan dere integrere eksisterende systemer i stedet for å erstatte dem?
Ja. Det er ofte bedre å bygge et avgrenset lag mellom systemer enn å bytte ut verktøy som allerede fungerer godt.
Hvordan reduseres sikkerhetsrisiko?
Med minste-tilgang, separate nøkler og miljøer, dataminimering, logging og tydelige godkjenningsporter.