Integrera AI i affärssystem och Microsoft 365: fyra vägar

Att integrera generativ AI i affärssystem och Microsoft 365 innebär att en språkmodell får läsa, och ibland skriva, data i de system ni redan har, med samma krav på behörigheter, inloggning och loggning som andra integrationer. Det finns fyra vägar: den inbyggda AI-funktionen i systemet, en egen koppling mot systemets API, ett mellanlager som håller ihop flera system, och MCP, standarden som låter AI-agenter använda systemen som verktyg. Ingen av dem kräver ett systembyte. Valet avgörs av om systemets egen funktion räcker, hur många system flödet passerar och hur fritt AI:n ska få agera.

Behörigheter, tjänstekonton och loggar sätter ramarna för vad en AI-lösning får göra i era system och vad ni kan granska efteråt.

Uppgifterna om produkter, priser och villkor gäller oktober 2026 om inget annat datum anges.

Vad ger den inbyggda AI-funktionen?

Den inbyggda funktionen går snabbast: den sammanfattar, skriver utkast och svarar på frågor ur den data användaren redan når, och kräver licenser och inställningar men ingen utveckling. Copilot i Microsoft 365 visar enligt Microsofts dokumentation bara organisationsdata som användaren har minst läsbehörighet till, och för användare i EU stannar trafiken inom EU Data Boundary. Undantaget är Anthropics modeller, som per september 2026 ligger utanför EU Data Boundary och är avstängda från början för kunder i EU. Fortnox lanserar under 2026 successivt en AI-assistent som hjälper till med fakturor, kunder och artiklar.

För Copilot finns loggningen redan: med granskning påslagen registrerar Microsoft Purview vem som använde Copilot, när och vilka filer svaret byggde på. För andra system får ni fråga leverantören vad som loggas och var datan behandlas. Begränsningen är att logiken är leverantörens: funktionen känner inte era regler för vad som ska hända med svaret i nästa steg.

När behövs en egen koppling mot systemets API?

En egen koppling behövs när flödet följer era egna regler, till exempel när en order i ett mejl ska tolkas, kontrolleras mot kundens villkor och läggas in som orderförslag. En egen tjänst hämtar då via API:et exakt den data som behövs, låter modellen tolka och skriver tillbaka. Kraven skiljer sig mellan systemen:

• Fortnox kräver integrationslicensen, som kostar 189 kronor i månaden, och ansluts med OAuth 2.0. Med ett tjänstekonto, som bara er systemadministratör kan godkänna, är kopplingen inte knuten till någon enskild användare. Varje behörighetsområde ger både läs- och skrivrätt, och enbart läsning går inte att välja, så en läsande lösning måste begränsas i er egen kod. API:et tar emot högst 25 anrop per fem sekunder per integration och företag.
• Spiris Bokföring & Fakturering, tidigare Visma eEkonomi, har separata läsbehörigheter, så en läsande integration kan låsas redan i API:et. Varje token gäller där en kombination av app och användare, så integrationen arbetar med en användares åtkomst.
• Business Central kräver att appen registreras i Microsoft Entra och i Business Central med behörighetsuppsättningar för just integrationen. Den fullständiga behörigheten SUPER kan inte ges till en app.
• Microsoft 365 nås via Microsoft Graph. Delegerad behörighet ger appen aldrig mer än den inloggade användaren har. Applikationsbehörighet gäller i hela organisationen utan inloggad användare: Files.Read.All ger läsrätt till varje fil, och bara de högsta administratörsrollerna kan godkänna den.

Till det kommer nycklar som förvaras utanför koden och en egen logg. Systemets logg visar vad integrationen gjorde, men inte varför modellen föreslog det. Region för modellanropen väljer ni själva.

Varför ett mellanlager när flödet passerar flera system?

När en förfrågan ska tolkas, prissättas ur affärssystemet, stämmas av mot lagersaldot i ett annat system och loggas i CRM behövs ett mellanlager. Det gör om data till ett gemensamt format, anropar modellen, lägger skrivningarna i kö med omförsök och för en logg som följer ärendet genom alla steg. Mot varje system använder det en egen identitet med just de behörigheter som behövs. Enkla varianter kan byggas i Power Automate, Azure Logic Apps eller n8n och mer komplexa som egen tjänst, vilket jämförs i lågkod eller egen kod för AI-flöden.

Mellanlagret bör lyssna på händelser och inte fråga systemen hela tiden. Business Central skickar webhooks när en post ändras, och Fortnox händelseström går att spola tillbaka två veckor efter ett avbrott men kan leverera samma händelse mer än en gång. Mellanlagret måste därför tåla dubbletter, så att ingen faktura bokas två gånger, och det behöver köras i en molnregion inom EU och ha en namngiven ägare.

Vad tillför MCP för AI-agenter?

MCP, Model Context Protocol, är en öppen standard för hur AI-agenter når verktyg och data. Anthropic lanserade den i november 2024, och i december 2025 överlämnades den till Agentic AI Foundation under Linux Foundation, med bland andra AWS, Google, Microsoft och OpenAI som platinummedlemmar. Den stöddes då av bland annat Claude, ChatGPT, Microsoft Copilot och Gemini.

En MCP-server står framför ett system och beskriver verktyg som "hämta kund" eller "skapa orderförslag", och agenten anropar dem när uppgiften kräver det. Samma server fungerar i alla assistenter som stöder MCP. Microsofts MCP-server för Business Central ger i grundinställningen bara läsåtkomst till de API:er användaren redan har rätt till. Administratören väljer vad agenter får ändra, och alla åtgärder sker med användarens identitet, så att agenten aldrig får mer behörighet än användaren och loggen visar vem som gjorde vad. Spiris har en MCP-server i beta för Bokföring & Fakturering som administratören slår på per användare (juni 2026).

Säkerheten ligger utanför protokollet. Specifikationen behandlar verktyg som godtycklig kodkörning och kräver att användaren uttryckligen samtycker innan ett verktyg anropas, men protokollet kan inte tvinga fram det. Börja med läsande verktyg, lägg till skrivande ett i taget med godkännande där det rör pengar eller personer, och räkna med att en agent som läser mejl kan luras av instruktioner gömda i texten, det som OWASP kallar prompt injection. Datan passerar också AI-plattformen som agenten körs i, så plattformens avtal och region gäller. Styrningen i övrigt beskrivs i AI-agenter i drift.

Hur väljer ni väg?

• Gäller uppgiften det den inbyggda funktionen är byggd för, som att sammanfatta, skriva utkast eller svara ur egna dokument: börja där och lägg arbetet på behörigheterna.
• Följer flödet era egna regler, ser likadant ut varje gång och behöver ingen gemensam kö eller logg mellan systemen: bygg en egen koppling mot API:et.
• Ska flera system hållas i takt med köer, omförsök och en gemensam logg: bygg ett mellanlager.
• Varierar frågorna, och ska agenten själv avgöra vad den behöver slå upp: använd MCP med läsande verktyg först. En fast process behöver ingen agent, och en vanlig integration är lättare att testa.

Vägarna går att kombinera, och kostnaden skiljer sig: den inbyggda vägen betalas genom licenserna, de byggda med utveckling och förvaltning, se vad AI kostar. Hur en hel process tas från förstudie till drift beskrivs i automatisera processer med AI.

Vilka fel är lätta att bygga in?

• Integrationen hänger på en person. En Fortnox-koppling utan tjänstekonto gör sina anrop för en användares räkning, med en förnyelsenyckel som gäller i 45 dagar. Har den gått ut måste en användare aktivera integrationen igen. Ge varje integration en egen identitet.
• Behörigheten är bredare än uppgiften. Applikationsbehörigheten Mail.Read ger åtkomst till alla postlådor. Exchange Online kan ge appen behörighet till utvalda postlådor, men en organisationsövergripande behörighet som redan getts i Entra gäller parallellt och måste tas bort. I SharePoint ger Sites.Selected åtkomst till en utvald webbplats.
• Copilot hittar det som redan var för öppet. En gammal webbplats som delats med hela företaget kan dyka upp i svaren. Microsofts vägledning för Copilot börjar med att åtgärda överdelning, och Restricted Content Discovery kan tillfälligt hålla utvalda webbplatser utanför svaren medan behörigheterna ses över.
• Modellen körs i fel region. I Microsoft Foundry kan en global driftsättning behandla data i vilken Azure-region som helst, och det är den typ Microsoft föreslår att börja med, eftersom den är billigast. En driftsättning av typen Data Zone i EU håller behandlingen inom EU. Vad reglerna säger om var personuppgifter får behandlas tas upp i EU AI Act och GDPR.
• Nycklar går ut i tysthet. En klienthemlighet i Entra gäller högst 24 månader, och Microsoft rekommenderar under 12 månader och certifikat i produktion. Bevaka utgångsdatum och larma när ett anrop nekas.

Ska AI in i de system ni redan har?

Byron Calles bygger integrationer med tjänstekonton, avgränsade behörigheter och loggning från första versionen, som en del av AI-utveckling för företag. Vilken väg som passar ert flöde avgörs i förstudien, den första fasen i varje bygge, som beskrivs under AI-förstudie. Boka ett samtal för att gå igenom ert systemlandskap och var en första integration passar.