Tillbaka till bloggen
·Tom Honig

Er data är det AI:n saknar

AI och Er data kopplade via MCP

De flesta har vid det här laget testat en AI-assistent. Den skriver, sammanfattar och resonerar imponerande bra. Men fråga den hur mycket ni har i lager, vilka kunder som ligger efter med betalningar eller varför marginalen sjönk i mars – och den har ingen aning.

En generisk modell kan allt utom just er verksamhet. Det som saknas är er data.

Kopiera och klistra är ingen strategi

Det som händer i många organisationer i dag är att medarbetare själva löser problemet: de exporterar ett utdrag, klistrar in det i en chatt och ställer sin fråga. Det fungerar, på sitt sätt. Men datan är inaktuell i samma stund som den kopieras, ingen vet vad som har lämnat huset och svaret går inte att spåra tillbaka till någon källa.

Frågan är alltså inte om AI ska få tillgång till er data. Frågan är hur – så att det blir både snabbt och säkert.

MCP – en standardkontakt för AI

MCP, Model Context Protocol, är en öppen standard för hur en AI-assistent pratar med ett system. Tänk på det som en standardkontakt: systemet beskriver vilka frågor det kan besvara och vilka verktyg det erbjuder, och assistenten väljer själv vad den behöver för att lösa uppgiften.

Samma kontakt fungerar i Claude, i ChatGPT och i egna agenter. Bygger man den en gång kan den användas överallt.

Därför ökar tempot

När datan väl går att nå förändras vem som kan pröva en idé och hur lång tid det tar.

En controller kan ställa frågor om utfallet utan att beställa en rapport. En inköpare kan be assistenten jämföra leverantörer över tid. En projektledare kan bygga en liten automatisering på en eftermiddag och se om den håller. Idéer som förr krävde ett utvecklingsprojekt för att ens testas kan nu prövas av den som har idén.

Det är där innovationstakten sitter. Inte i att AI:n är smart, utan i att vägen från fråga till svar – och från idé till prototyp – blir kort.

Säkert från början

Att ge en AI tillgång till affärskritisk data kräver samma omsorg som att ge en ny medarbetare det. I de system vi bygger följer vi några enkla principer:

  • Samma API som appen. AI:n går aldrig direkt mot databasen. Den ställer samma frågor som gränssnittet, genom samma affärsregler, och får därför exakt samma siffror som användaren ser på skärmen.
  • Användarens egna behörigheter. Inloggningen sker med OAuth, som vilken app som helst. AI:n ser bara det användaren själv får se – inget mer.
  • Läsa först. Vi börjar med läsrättigheter. Skrivande åtkomst kommer senare, och då med en människa som bekräftar.
  • Inga eviga nycklar. Åtkomsten ges med korta tokens som löper ut inom en timme – inga API-nycklar som ligger och skräpar.
  • Data stannar där den hör hemma. Varje kund har sin egen data, och åtkomsten gäller bara den.
MCP på egen data
AI:n och appen frågar samma API
Användare
I webbappen
Inloggning
Session och roller
AI-assistent
Claude, ChatGPT eller egen agent
MCP-server
OAuth · endast läsning
Samma API
Samma frågor och behörigheter som gränssnittet
Databas
En per kund

AI:n ser exakt samma siffror som användaren – och bara det användaren får se.

I ett av logistiksystemen vi bygger har varje bolag en egen MCP-server ovanpå samma API som webbappen.

Kunskap, inte bara åtkomst

Åtkomst till datan är halva jobbet. Den andra halvan är att AI:n förstår den: vad kolumnerna betyder, hur ni räknar marginal, vilka undantag som alltid gäller. Det är där skills kommer in – paketerad kunskap som assistenten plockar fram när den behövs. Och för det som måste göras på exakt samma sätt varje gång finns workflows. Om skillnaden mellan skill och workflow.

Samma sak gäller hur vi själva jobbar: det mesta av det en AI behöver veta om ett system går att skriva ner, en gång, på ett ställe som både människor och agenter läser. Om hur vi delar kunskap med AI.

Från prototyp till produktion

Här finns en fälla. När det blir lätt att bygga en prototyp blir det också lätt att tro att prototypen är klar. Men avståndet från något som fungerar på en skärm till ett system som tål produktion, integrationer, behörigheter och revision har inte krympt.

Det som däremot har ändrats är att prototypen redan finns när vi börjar. Den visar vad som behövs, vilka frågor som ställs och vilken data som faktiskt används. Det gör det betydligt enklare att bygga rätt sak. Om varför prototypen är den bästa specen.

Och ibland är frågan inte bara hur, utan var. För en del data är svaret att modellen ska köras på egen hårdvara. Om när öppna modeller är rätt val.

Så kommer ni igång

  1. Kartlägg var datan finns. Vilka system, vilka ägare, vilka känsligheter.
  2. Börja med läsning. Det ger mest värde med minst risk.
  3. Bygg på befintliga API:er. Då ärver AI:n reglerna som redan finns.
  4. Låt medarbetarna experimentera. De vet var skon klämmer.
  5. Ta det som fungerar vidare på riktigt. Det är här det avgörs – mer om det nedan.

Från prototyp till något verksamheten kan lita på

Medarbetarnas prototyper är den bästa specen som finns. De visar vilka frågor som faktiskt ställs, vilken data som behövs och var nyttan sitter. Men en prototyp som fungerar för den som byggde den är något helt annat än ett system som hela verksamheten kan luta sig mot. Det är där vår erfarenhet gör skillnad.

Vägen till drift handlar om det som inte syns i en demo:

  • Säkerhet. Rätt person ska se rätt data – inget mer. Det gäller inloggning, behörigheter per användare, skydd mot att AI:n luras att lämna ut sådant den inte ska, och korta nycklar som går att dra tillbaka.
  • Regelefterlevnad. Personuppgifter ska hanteras enligt GDPR, AI-användningen ska uppfylla kraven i EU:s AI-förordning, och för vissa verksamheter tillkommer krav på informationssäkerhet och spårbarhet. Var behandlas datan? Hur länge sparas den? Vem kan se vad som hänt? [BEKRÄFTA att vi vill nämna AI-förordningen specifikt]
  • Skala. Det som fungerar för en person ska fungera för hundra – med större datamängder, fler samtidiga frågor och svarstider som håller.
  • Kostnadskontroll. Varje fråga kostar pengar. Rätt modell för rätt uppgift, cachning, begränsningar per användare och uppföljning av kostnad per fråga gör skillnaden mellan en budget som håller och en faktura som överraskar.
  • Verifiering. Svaren ska gå att lita på. Det kräver tester och löpande utvärdering, svar som hänvisar till sina källor och loggning som gör det möjligt att i efterhand se vad som hände och varför. Så gör vi i Svensk Galopps Handbok.
  • Drift och förvaltning. Modeller byts, API:er ändras och behoven växer. Någon måste övervaka, uppdatera och ta ansvar – även år tre.
Prototyp → I drift
Från prototyp till produktion
Fungerar för den som byggde den
Fungerar för alla, med rätt behörigheter
Personuppgifter i en chatt
GDPR, AI-förordningen och spårbarhet på plats
Kostar vad det kostar
Kostnad per fråga under kontroll
Verkar stämma
Testat, mätt och med källa
Ett verktyg
Ett system som tål fler användare och mer data

Det är inget skäl att vänta med att experimentera – tvärtom. Men det är ett skäl att ha en plan för det som visar sig fungera.

Vi håller gärna en halvdagsworkshop där vi tillsammans hittar var AI och automation gör störst skillnad hos er. Hör av er.