Bakgrund – vad är ett API och vad är en MCP?

När vi pratar om digitalisering och AI dyker två förkortningar upp om och om igen: API och MCP. De hänger ihop, men löser olika problem. Här reder vi ut vad de faktiskt betyder, och varför just du som arbetar med arkitektur, strategi eller beslut inom offentlig sektor behöver ha koll på dem.

API – språket som låter system prata med varandra

API står för Application Programming Interface, ungefär "programmeringsgränssnitt". Det enklaste sättet att tänka på ett API är som en meny på en restaurang.

När du sitter på restaurangen går du inte själv in i köket och börjar laga maten. Du tittar i menyn, som beskriver exakt vad du kan beställa, och säger till servitören vad du vill ha. Servitören tar med din beställning till köket och kommer tillbaka med rätten. Du behöver aldrig veta hur köket är organiserat, vilka spisar de använder eller hur kocken arbetar, du behöver bara hålla dig till menyn.

Ett API fungerar likadant mellan två IT-system:

  • Menyn är det avtal (kontraktet) som beskriver vad du får be om och i vilken form.
  • Servitören är API:et som tar emot förfrågan, hämtar svaret och lämnar tillbaka det.
  • Köket är systemet bakom – databasen, affärslogiken, registret – som förblir dolt.

Det här ger fyra egenskaper som är värda att känna till:

  • Abstraktion – den som anropar ett API slipper förstå hur systemet bakom är byggt. En webbapplikation i en kommun kan hämta en folkbokföringsuppgift via ett API utan att veta något om hur det bakomliggande registret är konstruerat.
  • Stabilitet – så länge "menyn" är oförändrad kan köket som helhet bytas. Myndigheten kan modernisera sina bakomliggande system utan att alla anslutna tjänster går sönder, ett avgörande skäl till att API:er gör stora system förändringsbara över tid.
  • Kontroll och säkerhet – du exponerar bara det som står på menyn, inget annat. API:et blir en kontrollerad dörr in i systemet, där man kan styra behörighet, logga anrop och begränsa vad som får hämtas.
  • Interoperabilitet – eftersom API:er bygger på överenskomna format kan system från olika leverantörer och andra aktörer utbyta information utan att vara hårt sammankopplade. Det är hela grunden för en sammanhängande digital förvaltning, där en e-legitimation, ett register och en digital tjänst kan samverka.

Kort sagt, API:et är hur programvara pratar med programvara, och det har varit den bärande integrationsmekanismen i modern IT i decennier.

MCP – en standardiserad kontakt mellan AI och omvärlden

MCP står för Model Context Protocol. Det är en betydligt nyare företeelse, en öppen standard som beskriver hur en AI-modell eller AI-assistent ansluter till externa verktyg, datakällor och system. Den introducerades av Anthropic i november 2024 och överlämnades i december 2025 till en oberoende stiftelse under Linux Foundation, vilket gjort den leverantörsneutral. Sedan dess har den fått stöd av i princip alla stora AI-aktörer.

För att förstå varför MCP behövs, tänk på problemet det löser. En AI-assistent blir verkligt användbar först när den kan göra saker åt dig, som att läsa i ett ärendehanteringssystem, slå upp en uppgift, boka i en kalender, sammanställa data. Men varje sådan koppling behövde tidigare byggas specifikt, en skräddarsydd integration för varje kombination av AI-verktyg och system. Det innebär att 10 AI-tjänster som ska nå 100 olika system i värsta fall leder till 1 000 unika integrationer att bygga och underhålla.

MCP vänder på det. Liknelsen som ofta används är USB-C för AI. Förr hade varje apparat sin egen laddare och sin egen kontakt, men med USB-C räcker en standard för att koppla ihop nästan vad som helst. På samma sätt, när ett system väl erbjuder en "MCP-server", kan vilken MCP-kompatibel AI som helst använda den utan ny specialintegration. 1 000 kopplingar blir i stället 110. Var sida behöver bara byggas en gång.

En MCP-server exponerar tre saker för AI på ett standardiserat och självbeskrivande sätt:

  • Verktyg – handlingar AI kan utföra, till exempel "skapa ärende" eller "skicka påminnelse".
  • Resurser – data AI kan läsa, till exempel ett dokument eller en post i ett register.
  • Promptar – färdiga mallar som hjälper AI att använda systemet rätt.

Det viktiga är att beskrivningarna är skrivna så att AI-modellen själv kan förstå vad ett verktyg gör och när det ska användas, något ett vanligt API inte är utformat för.

Hur API och MCP hänger ihop

MCP ersätter inte API:er då en MCP-server är i praktiken ofta ett lager som tar befintliga API:er och presenterar dem på ett sätt som en AI-modell kan upptäcka och använda på egen hand.

Skillnaden i en mening:

Ett API är hur två system pratar med varandra. En MCP är en standardiserad väg för en AI-modell att hitta och använda de systemen oavsett vilken AI-leverantör man valt.

Varför det här angår offentlig sektor

För dig som fattar beslut eller sätter arkitektur är poängen inte tekniken i sig, utan vad standardiseringen möjliggör och kräver:

  • Minskad inlåsning – eftersom MCP är leverantörsneutralt och modellagnostiskt kan en organisation byta AI-leverantör utan att bygga om alla integrationer. Det är en strategiskt viktig egenskap för en sektor som ska undvika beroenden av enskilda leverantörer.
  • Återanvändning – en MCP-server byggd för ett verksamhetssystem kan användas av flera olika AI-tjänster och agenter. Investeringen i en bra integration får bredare nytta.
  • Nya säkerhetskrav – när AI-agenter kan utföra handlingar i verkliga system uppstår nya risker, där obehörig åtkomst och manipulerade verktyg ("tool poisoning") ofta nämns. Här saknar protokollet ännu inbyggda svar på allt som krävs i en hårt reglerad miljö, exempelvis fullständiga revisionsspår, dataresidens och stark behörighetsstyrning. Att amerikanska NSA i maj 2026 gav ut särskild säkerhetsvägledning för MCP säger något om hur seriöst frågan tas. För offentlig sektor betyder det att MCP bör införas planerat, med styrning, loggning och åtkomstkontroll på plats, inte som en reflex driven av branschens tempo.

Med andra ord, API:et är den mogna, beprövade grunden för integration och MCP är det snabbt framväxande lagret som låter AI använda den grunden, med stora möjligheter men med ansvarsfrågor som offentlig sektor behöver äga själv.

Från teknik till strategi – API-strategi och MCP-strategi för offentlig sektor

I förra avsnittet konstaterade vi att API:er och MCP inte bara handlar om teknik, utan något som påverkar inlåsning, återanvändning och säkerhet. Men teknik som inte styrs blir sällan till nytta. Det är därför allt fler kommuner och myndigheter formulerar strategier – dokument som beskriver inte bara hur man kopplar ihop system, utan varför och i vilken ordning. Här tittar vi närmare på vad en API-strategi för offentlig sektor faktiskt är, och vad vi i dag vet om hur en MCP-strategi kan komma att se ut.

Vad är en API-strategi för offentlig sektor?

En API-strategi är inte en lista över vilka API:er en organisation ska bygga. Det är ett synsätt på hur man designar och utvecklar sin digitala infrastruktur över tid. Ett av de tydligaste och mest spridda exemplen i Sverige är Sundsvalls kommuns API-strategi, som är värd att läsa i sin helhet. Den bygger på en handfull bärande idéer som är lärorika oavsett var man själv som organisation befinner sig.

  • Designa utifrån och in, med processen som utgångspunkt – i stället för att börja i de system man råkar ha, börjar man i de processer där kommunen möter sina intressenter, alltså sina medborgare, företagare, föreningar, m. fl. En process kan spänna över flera förvaltningar och bolag, men ska upplevas som en sammanhängande kontakt med kommunen. Processen bryts sedan ner i information och tjänster som exponeras via API:er.
  • Ett API är en produkt, inte ett projekt – det här är kanske den viktigaste tankevändningen. Ett projekt tar slut, men en produkt har en livscykel, en ägare och användare som ska vårdas. I Sundsvalls strategi ägs API:ets livscykel optimalt av verksamheten, inte av IT-avdelningen, och den är medvetet frikopplad från de underliggande systemen. Det betyder att man kan modernisera eller byta ut ett bakomliggande system – ta hand om sitt "digitala arv" – utan att de tjänster som använder API:et går sönder.
  • Återanvändning före specialbyggen – en funktion ska designas så att den kan återanvändas i alla processer där samma behov dyker upp. Det är så man undviker att bygga samma sak tio gånger i tio olika förvaltningar.
  • Federation i stället för flaskhalsar – ett centraliserat API-team som ska godkänna allt blir snabbt en propp. Strategin förespråkar i stället en federerad modell, där ansvar och kompetens finns ute i verksamheterna men inom gemensamma ramar.

Till detta kommer ett par framgångsfaktorer som låter självklara men sällan är det i praktiken; säkerhet som grund snarare än påklistrad i efterhand, stöd från ledningen eftersom en sådan här omställning är ett uthålligt program och inte en quick fix, och devisen starta smått, skala fort, växa stort – börja med de lågt hängande frukterna och visa konkret nytta innan man ger sig på det komplexa.

En API-strategi på kommunnivå står inte heller ensam. Den vävs ihop med regeringens digitaliseringsstrategi 2025–2030, nya lagkrav på interoperabilitet vid datadelning i offentlig förvaltning, och uppbyggnaden av Ena – Sveriges digitala infrastruktur. Poängen med en egen API-strategi är att vara redo att haka i den utvecklingen, inte att uppfinna den på egen hand.

En API-strategi besvarar en enkel men avgörande fråga – hur gör vi vår kärnverksamhet säkert och kontrollerat åtkomlig för oss själva, för andra myndigheter och för medborgaren utan att låsa fast oss i dagens system?

Finns det en MCP-strategi för offentlig sektor?

Det korta och ärliga svaret är; inte ännu i någon mogen form. Det finns i skrivande stund ingen publicerad MCP-strategi för svensk offentlig sektor som motsvarar Sundsvalls API-strategi. MCP är fortfarande ungt, och de flesta organisationer befinner sig i utforskande faser snarare än i förvaltning. Men konturerna av hur en sådan strategi kommer att se ut börjar bli synliga, och de ritas upp från tre håll samtidigt.

Från industrin kommer de första ramverken för hur man bygger en MCP-strategi i praktiken. Återkommande är en uppdelning i tre delar: 1) hur man designar de verktyg man exponerar för AI, 2) hur man driftar MCP-servrar säkert, och 3) hur man styr helheten. Just styrningen lyfts fram som det avgörande eftersom utan central styrning kan man inte svara på de frågor en granskning ställer; vilken agent kom åt vilka data, med vilken behörighet, och när. En vanlig rekommendation är ett register över godkända MCP-servrar, så att inte "skugg-servrar" smyger sig in i produktion utan granskning.

Från säkerhetsorganisationer har frågan börjat tas på stort allvar. Att amerikanska NSA i maj 2026 gav ut särskild säkerhetsvägledning för MCP säger något om mognadsgraden. Genomgående är slutsatsen att man inte kan luta sig mot enbart vanlig API-säkerhet, utan behöver tänka i termer av åtkomstkontroll, spårbarhet, validering av indata och en "anta ingenting"-hållning, samt koppla kontrollerna till etablerade ramverk som NIST AI RMF samt ISO/IEC 42001 och 27001.

Från svensk offentlig sektor finns ännu inget MCP-specifikt styrdokument, men den styrlogik en MCP-strategi måste leva inom är redan formulerad. DIGG är tydliga med att AI-agenter som agerar självständigt i en myndighets namn medför särskilda risker, inte minst när de kopplas till externa system eller får utföra åtgärder. Grundprincipen, enligt DIGG, är att agenter bara får användas när nyttan tydligt överstiger risken och när spårbarhet, ansvar och mänsklig kontroll kan säkerställas, och alltid efter en riskbedömning med fokus på rättssäkerhet, kontrollförlust och informationshantering. Statskontoret beskriver samma rörelse; utvecklingen går från AI-assistenter till självständigt arbetande agenter, vilket ställer nya krav på riktlinjer, kontroll och gemensamma standarder mellan myndigheter. Lägg därtill offentlighetsprincipen, GDPR, AI-förordningen och NIS2, och man ser konturerna av det regelverk en svensk MCP-strategi behöver förhålla sig till.

En MCP-strategi är API-strategin in i agenternas tid

Det fina, och kanske mest användbara, är att en MCP-strategi inte behöver uppfinnas från grunden. I mångt och mycket är den API-strategins DNA fört vidare ytterligare ett steg.

Tänk på likheterna. Produkt, inte projekt gäller en MCP-server lika mycket som ett API. Återanvändning är om möjligt ännu starkare här då en bra MCP-server kan användas av flera olika AI-tjänster och agenter, så investeringen får verkligt bred nytta. Federation, säkerhet som grund och stöd från ledningen är samma framgångsfaktorer. Och eftersom en MCP-server i praktiken ofta är ett lager ovanpå befintliga API:er, blir en mogen API-strategi den naturliga grunden att bygga MCP på – den som redan gjort sitt API-arbete har ett rejält försprång.

Skillnaderna handlar om det som är nytt när det inte längre är kontrollerat av en människa, utan en AI-agent, hur man använder gränssnittet:

  • Ett register över godkända MCP-servrar och tydlig behörighetsstyrning, så att man vet och kan visa vad agenterna får göra.
  • Spårbarhet och loggning byggd för granskning – vem gjorde vad, på vems uppdrag – inte minst med tanke på offentlighetsprincipen och rättssäkerheten.
  • Leverantörsoberoende som ett medvetet val – eftersom MCP är modellagnostiskt kan man byta AI-leverantör utan att bygga om sina integrationer, vilket går hand i hand med strävan efter digital suveränitet.
  • Riskbedömning före åtgärd, enligt DIGG:s princip att nyttan tydligt ska överstiga risken och att mänsklig kontroll ska kunna säkerställas.

Med andra ord, om API-strategin handlar om att göra kärnverksamheten säkert åtkomlig för system och människor, handlar MCP-strategin om att göra samma verksamhet säkert användbar för AI-agenter med den extra aktsamhet som följer av att något nu kan agera på egen hand. Den offentliga sektor som redan tänker i API-strategiska termer har inte bara en bra start. Den har, om man uttrycker sig så, redan skrivit första utkastet till sin MCP-strategi, det återstår bara att läsa det i ljuset av agenterna.

Källor

← Tillbaka till bloggen