# AI i Azure eller lokalt: kostnader, säkerhet och drift

Valet mellan Azure och egen hårdvara för AI avgörs av tre faktorer: hur jämn er last är, vilka säkerhetskrav som faktiskt gäller er verksamhet och vilken driftkapacitet ni har. Vi går igenom kostnadsstrukturerna i båda spåren, brytpunkten där egen hårdvara blir billigare än betala-per-användning, vad Patientdatalagen och försvarsnära krav innebär i praktiken, och avslutar med en beslutsmatris och en checklista inför beslutet.

- Published: 2026-09-06 · Category: Business & Strategy · Tags: Svenska, On-Premise AI, Azure, Kostnad, Säkerhet
- Author: Technspire AB, Stockholm (https://technspire.com)
- Canonical: https://technspire.com/en/blog/ai-i-azure-eller-lokalt-kostnader-sakerhet-drift

Tre faktorer avgör var era AI-arbetslaster hör hemma: lastprofilen, säkerhetskraven och er egen driftkapacitet. Det är det korta, ärliga svaret på frågan som varje svensk organisation med känslig data ställer sig just nu. Molnleverantören tjänar på att ni köper tokens. Hårdvaruleverantören tjänar på att ni köper GPU-servrar. Ingen av dem tjänar på att säga att rätt val beror på hur er verksamhet faktiskt ser ut, och därför får ni sällan höra det.

Kostnadsstrukturerna kommer först och driftansvaret sist, eftersom driftansvaret nästan alltid är den mest underskattade posten. Rätt svar beror på er verksamhet, inte på någon leverantörs åsikt.

## Kostnadsstrukturen i molnet: kostnaden följer trafiken

I Azure betalar ni för användning. Antingen per token i standarddeployments, eller via provisionerad kapacitet där ni reserverar genomströmning i förväg och betalar för reservationen oavsett hur mycket av den ni utnyttjar. Ni gör ingen hårdvaruinvestering och binder inget kapital i servrar som åldras.

Kostnaden följer trafiken. Skickar ni få anrop en månad blir fakturan låg. Skickar ni många blir den hög. Vid låg eller ojämn last är det svårslaget: ni betalar bara för det ni förbrukar och kan i praktiken skala ner till noll mellan topparna. Vid hög och jämn last vänds logiken. Varje token kostar, dygnet runt, år efter år, och det finns ingen punkt där infrastrukturen är färdigbetald.

Två detaljer förtjänar särskild uppmärksamhet i kalkylen. EU Data Zone-deployments, där bearbetning och lagring hålls inom EU, kan vara prissatta högre än globala deployments av samma modell. Suveränitetsvalet har alltså en prislapp även i molnet. Och provisionerad kapacitet ger förutsägbar prestanda men flyttar er närmare en fast kostnadsstruktur: ni betalar för reserverad kapacitet även de timmar då trafiken uteblir.

En praktisk svårighet i molnkalkylen är att tokenförbrukning är svår att uppskatta i förväg. Antalet tokens per ärende beror på hur långa dokument som skickas in, hur mycket kontext varje anrop bär med sig och hur ofta användarna ställer följdfrågor. Organisationer som budgeterar utifrån antal användare i stället för utifrån uppmätt tokenvolym brukar bli överraskade åt något av hållen. Kör en begränsad pilot och mät, innan ni skriver in en siffra i budgeten.

## Kostnadsstrukturen lokalt: samma pris vid 10 och 90 procents last

Lokalt ser strukturen helt annorlunda ut. GPU-servrarna är en investering som skrivs av över 3 till 5 år, och till investeringen kommer löpande poster som inte syns i något molnprisblad:

- El och kyla, som för GPU-laster är en betydande löpande post och inte en fotnot.
- Rackutrymme, i egen hall eller hos en colocation-leverantör.
- Driftpersonalens tid för patchning, övervakning och felsökning.
- Hårdvaruuppgraderingar när nästa modellgeneration kräver mer GPU-minne än dagens kort levererar.

Kör ni öppna modellvikter, till exempel serverade via vLLM, finns inga tokenavgifter alls. Samma server kostar lika mycket vid 10 procents last som vid 90 procents. Det är hela poängen med egen hårdvara, och det är samtidigt hela risken. Fyller ni servern med arbete sjunker kostnaden per anrop för varje anrop ni lägger till. Står den halvtom betalar ni ändå fullt pris för kapacitet som ingen använder.

Dimensioneringen är den lokala kalkylens svåraste fråga. Köper ni hårdvara för topplasten står kapaciteten oanvänd resten av tiden. Köper ni för genomsnittslasten får användarna köa vid topparna, och köer i ett AI-verktyg märks direkt i svarstiderna. Molnet slipper den avvägningen genom att skala elastiskt. Lokalt måste ni göra den medvetet, och helst innan beställningen läggs, eftersom leveranstider på GPU-servrar kan räknas i månader.

## Brytpunkten: utnyttjandegraden avgör ekonomin

Föreställ er två organisationer med samma totala anropsvolym över ett år. Den första kör jämn last dygnet runt: dokumentflöden som bearbetas kontinuerligt och batchjobb som fyller nätterna. Den andra har nästan all trafik under kontorstid på vardagar, med toppar kring månadsskiften. För den första arbetar en egen server nästan hela tiden, och den fasta kostnaden slås ut över en stor volym. För den andra står samma server stilla under merparten av veckans 168 timmar, medan molnets mätare bara tickar när trafiken faktiskt går.

Exakt var brytpunkten ligger beror på vilka modeller ni kör och vilka priser ni förhandlar fram, och den flyttar sig när marknadspriserna gör det. Men kurvans form är stabil. Molnkostnaden växer i takt med användningen, den lokala kostnaden är i stort sett platt, och någonstans korsar linjerna varandra. Er uppgift före beslutet är inte att gissa var korsningen ligger, utan att mäta er faktiska last och räkna på båda spåren med egna siffror. En organisation som gissar sin utnyttjandegrad gissar i praktiken hela kalkylen.

## Säkerhetskraven: vad som kräver lokalt, och vad Azure klarar

Vissa krav pekar entydigt mot egen infrastruktur. Patientdata som omfattas av Patientdatalagen, försvarsnära verksamhet och uttryckliga krav på att data aldrig lämnar era egna nät gör ofta diskussionen kort. Men var noga med vad lokal drift faktiskt bevisar. Ett luftgapat system är inte isolerat bara för att det står i er egen serverhall. Isoleringen är något ni designar och dokumenterar: kontroll över utgående trafik och telemetri, över hur modellvikter och uppdateringar tas in, och över hur supportåtkomst går till. Den verifieras på nätverksnivå. En auditlogg som visar att inget lämnade systemet bevisar inte isolering. Det gör en nätverksdesign där trafiken inte kan lämna systemet.

Åt andra hållet är Azure varken automatiskt otillåtet eller automatiskt compliant. Med privata nätverk, EU-datazoner och kundstyrda krypteringsnycklar klarar Azure-baserade lösningar i dag krav som för några år sedan ansågs omöjliga utanför den egna hallen. Men dataresidensen beror på vilken tjänst, vilken modell, vilken deployment-typ och vilken region ni väljer. En EU-fokuserad lösning kräver att ni verifierar varje tjänsts bearbetnings- och lagringsplatser: var dokumentextraktionen sker, var inferensen körs, var sökindexet ligger och var loggar och backuper hamnar. Att all data stannar i Sverige är aldrig ett automatiskt utfall. Det är ett påstående som ska beläggas tjänst för tjänst.

GDPR och Patientdatalagen reglerar var och hur data får behandlas. Det är implementationen som etablerar regelefterlevnaden, inte plattformsvalet. En slarvigt konfigurerad lokal miljö kan bryta mot samma paragrafer som en slarvigt konfigurerad molnmiljö.

Ansvarsfördelningen skiljer sig också åt. I molnet delar ni ansvaret med Microsoft: de står för fysisk säkerhet, hårdvara och plattformens grundnivå, medan ni står för konfigurationen, åtkomststyrningen och er data. Lokalt äger ni hela stacken själva, från skalskydd och firmware till operativsystempatchar och modellservering. Det är en frihet och en arbetsbörda på samma gång.

## Driftansvaret: den mest underskattade faktorn

Att köra egen inferens i produktion är inte ett projekt. Det är ett åtagande som löper varje vecka så länge tjänsten finns. I praktiken innebär det:

- Modellversioner: utvärdera nya vikter, rulla ut dem kontrollerat och kunna backa när något går fel.
- Säkerhetspatchar för operativsystem, GPU-drivrutiner och serveringslager, i takt med att sårbarheter publiceras.
- Övervakning av GPU-hälsa, minnesanvändning, latens och köbildning, med larm som någon faktiskt agerar på.
- Jour och incidenthantering när tjänsten går ner utanför kontorstid.
- Kompetens att felsöka fel som uppstår i gränslandet mellan hårdvara, drivrutin och modell, vilket är en smal specialitet på svensk arbetsmarknad.

Molndrift är inte gratis den heller, men arbetet ser annorlunda ut. Där handlar det om kostnadsövervakning så att fakturan inte överraskar, om kvothantering, om val av deployment-typ och region, och om uppföljning när Microsoft pensionerar modellversioner. Skillnaden är att den kompetensen är bredare tillgänglig på marknaden och att ansvaret för själva järnet ligger hos någon annan.

Ställ er en ärlig fråga: har ni i dag personer som kan felsöka en GPU-server en söndagsnatt, och som stannar hos er de kommande tre åren? Om svaret är nej väger det tyngre mot egen drift än de flesta kostnadskalkyler, såvida ni inte tar in en partner som bär det ansvaret åt er.

## Beslutsmatris

Ingen matris ersätter en analys av era egna laster och krav, men riktningarna nedan håller i de flesta situationer vi möter hos svenska organisationer.

| Situation | Riktning | Varför |
| --- | --- | --- |
| Jämn, hög last dygnet runt och höga krav på datasuveränitet | Lokalt | Servern arbetar nästan hela tiden och den fasta kostnaden slås ut över stor volym. Data lämnar aldrig era nät, förutsatt att isoleringen är designad och verifierad. |
| Ojämn eller låg last och standardkrav på säkerhet | Azure | Betala per användning är billigast när en egen server annars skulle stå stilla. Ingen investering att försvara om behovet ändras. |
| Patientdata eller försvarsnära verksamhet | Lokalt eller hybrid | Regulatoriska krav pekar mot egna nät för de känsliga flödena. Verifiera kraven med paragraf, inte med antaganden. |
| Snabb pilot eller proof of concept | Azure | Igång på dagar utan kapitalbindning. Flytta senare om piloten bär och lasten visar sig bli jämn och hög. |
| Blandad portfölj med både känsliga flöden och volymtrafik | Hybrid | Känsliga flöden körs lokalt, övriga i molnet. Kräver tydlig dataklassning så att gränsen mellan spåren håller över tid. |

Hybridspåret förtjänar en egen kommentar, eftersom det ofta avfärdas som dubbel komplexitet. I praktiken är det tvärtom det som gör helheten hanterbar: patientjournaler eller annan skyddsvärd information bearbetas av en öppen modell på egna servrar, medan mindre känsliga volymflöden går mot Azure där lasten är ojämn och betala-per-användning lönar sig. Förutsättningen är en dataklassning som avgör vilket flöde som hör hemma var, och en arkitektur där gränsen går att verifiera tekniskt, inte bara i en policy.

## Checklista före beslutet

- Mät er faktiska last per timme över minst en representativ månad, inklusive toppar, helger och nätter.
- Lista era regulatoriska krav med paragraf och källa, inte som antaganden från ett möte.
- Inventera driftkompetensen: vem patchar, vem övervakar, vem har jour, och vad händer när den personen slutar.
- Räkna på 3-årskostnaden i båda spåren med era egna volymer, inklusive personal och uppgraderingar lokalt samt EU-datazoner och provisionerad kapacitet i molnet.
- Kräv verifierbara dataflöden oavsett val: nätverksdesign och dokumenterade lagringsplatser, inte enbart leverantörslöften.
- Planera för modellbyten från dag ett. I molnet pensioneras modellversioner, lokalt växer nya modeller ur er hårdvara.
- Utred hybridspåret innan ni väljer allt eller inget. Ofta är det bara ett eller två flöden som faktiskt kräver lokal drift.

**Osäkra på vilket spår som är rätt för er?** Vår [AI-kostnadsanalys](/sv/services/azure-openai-integration#offers) räknar på era faktiska arbetslaster, och vår [on-premise-tjänst](/sv/services/on-premise-ai-solutions) täcker det lokala spåret. Ett inledande samtal ger en fast offert.

---

Technspire AB builds AI agents, Azure OpenAI solutions, and production web platforms for Swedish and EU enterprises. Book a call: https://calendly.com/technspire · hello@technspire.com · More articles: https://technspire.com/en/blog · Site overview for agents: https://technspire.com/llms.txt