När AI-säkerheten blir en extra kostnad – vem har råd att vara skyddad?

AI köps ofta in med ett enkelt löfte: mindre manuellt arbete, snabbare beslut och lägre kostnader. Men när systemen går från att svara på frågor till att söka i data, använda verktyg och utföra avgränsade uppgifter uppstår en annan kalkyl. Företaget köper inte bara en AI-tjänst. Det behöver också besluta vem som får använda den, vad den får nå, hur den ska övervakas och vem som tar hand om varningar när något ser fel ut.

En del av det skyddet följer med produkten. En del kan kräva en högre licensnivå, en separat skyddstjänst eller mer arbete av företagets egen IT- och säkerhetsfunktion. Det betyder inte automatiskt att en leverantör har sålt en osäker grundprodukt, eller att varje avancerad säkerhetstjänst borde vara gratis. Men det gör gränsen viktig: vilka skydd måste finnas från början för att produkten ska kunna användas rimligt säkert, och vilka är legitimt extra försvar på djupet?

Det som ingår är inte samma sak som allt som behövs

Det är lätt att blanda ihop två olika saker. Den första är grundläggande, produktinbyggd säkerhet: exempelvis säkra standardinställningar, identitet, behörighetsstyrning, loggning och tydliga kontroller där de behövs för normal användning. Den andra är försvar på djupet: extra övervakning, specialiserad hotdetektion, isolerade körmiljöer, avancerade analysfunktioner eller skydd i infrastrukturen.

Båda kan vara nödvändiga i en viss miljö. Men de är inte samma sak. En organisation med känsliga data, många externa kopplingar eller egna AI-agenter kan rimligen behöva mer än vad en vanlig kontorslicens ger. Samtidigt blir det ett problem om kunden först efter inköp upptäcker att skydd som är avgörande för den avsedda användningen ligger i en helt annan produkt, licens eller administrativ process.

Det är också därför det blir missvisande att jämföra olika leverantörer som om de sålde samma sak. Ett system för att styra och övervaka AI-agenter, ett filter för modellin- och utdata, en arbetsyta med identitetsstyrning och en hårdvarunära säkerhetsarkitektur har olika uppgifter. Prislistan säger något om paketeringen, men inte ensam om vilket skydd som är bäst.

Microsoft visar hur licensfrågan kan bli konkret

Microsoft Agent 365 är ett tydligt exempel eftersom tjänsten ska samla inventering, styrning och säkerhet för AI-agenter. Microsoft anger ett listpris på 15 amerikanska dollar per användare och månad med årsbindning för den fristående tjänsten. Den kan också ingå i Microsoft 365 E7. Licensen är kopplad till en användare, inte till agenten. Alla i ett företag behöver alltså inte automatiskt ha den.

Vissa grundfunktioner kan finnas på organisationsnivå för kvalificerade Microsoft Cloud-kunder, och minst en användare med kvalificerande licens behövs för att aktivera Agent 365. Företaget behöver ändå avgöra vilka personer och agentflöden som behöver de mer avancerade kontrollerna.

Den 1 juli 2026 ändrades också villkoren för vissa agentinriktade säkerhetsfunktioner i Copilot Studio och Microsoft Foundry. Microsoft anger att de då kräver en Agent 365-berättigad licens. Det gäller bland annat möjligheter att upptäcka agenter, se säkerhetsläge, få hotvarningar och undersöka agentaktivitet. För Foundry gäller det upptäckt, säkerhetsläge och hotskydd för molnhostade agenter.

Det är en verifierbar förändring, men bevisar inte att varje organisation måste köpa varje tillägg. För små och medelstora kunder anger Microsoft Business Premium som krav. För att låsa upp Agent 365-funktionalitet behövs också Defender Suite för SMB och Purview Suite för SMB, även om Microsoft uttryckligen säger att de två tilläggen inte är formella förutsättningar. Vilka delar som redan finns i kundens licensläge avgör vad som faktiskt behöver läggas till.

Hela kostnaden för Business Premium, Defender eller Purview är ändå inte en ren AI-säkerhetsavgift. Sviterna innehåller bredare funktioner för identitet, enheter, data och regelefterlevnad. Men för ett företag som vill använda agentfunktionerna säkert blir de en del av den praktiska frågan: vilka licenser finns redan, och vilka saknas?

Ett räkneexempel utan låtsaskostnader

Föreställ dig ett mindre företag som vill använda AI-agenter i flera arbetsflöden. Företaget har 25 personer som faktiskt behöver Agent 365-skydd enligt sin användning av agenterna. Med Microsofts dokumenterade listpris blir den fristående Agent 365-raden 375 amerikanska dollar per månad, eller 4 500 dollar per år, före skatt, valutaeffekter, avtal och eventuella rabatter.

Det är en användbar siffra, men den är inte en färdig budget. Företaget behöver först svara på frågor som:

• Vilka baslicenser har vi redan, och uppfyller de kraven för de Agent 365-funktioner vi vill använda?
• Vilka av de 25 användarna eller agentägarna behöver faktiskt premiumskydd?
• Vilka säkerhetsfunktioner ingår redan, och vilka kräver Agent 365, Defender eller Purview?
• Vem bestämmer behörigheter, konfigurerar policyer och granskar agenternas åtkomst?
• Vem följer upp varningar, utreder incidenter och ser till att policyn fortfarande passar när arbetssätten förändras?
• Hur tränas medarbetare att förstå både verktygets nytta och dess begränsningar?

De sista frågorna har ofta inga offentliga prislistor. Det vore ohederligt att hitta på timmar, löner eller incidentkostnader. Men de är ändå en del av den faktiska driftskostnaden: konfigurering, administration, övervakning, utbildning, återkommande utbildning och incidentberedskap använder tid och ansvar. AI som verkar billig per användare kan bli betydligt mindre billig om företaget saknar kapacitet att göra den säker i vardagen.

Skydd som mäts per användare, per anrop eller per nivå

Andra leverantörer visar andra modeller. AWS tar betalt för Amazon Bedrock Guardrails utifrån vilka skydd som aktiveras. Tjänsten kan bestå av flera skydd, som innehållsfilter, kontroller mot promptattacker och filter för känslig information. AWS definierar en textenhet som högst 1 000 tecken; längre text delas upp i flera enheter.

Det är därför missvisande att tala om ”ett guardrail-pris”. Skydden har olika funktioner och kan prissättas olika. AWS beskriver kontrollen mot promptattacker som ett sätt att hjälpa till att upptäcka och filtrera jailbreaks, prompt injection och läckage. Det minskar risk, men är ingen garanti för att angrepp aldrig lyckas. AWS säger också att kunder bör fortsätta testa och validera sina guardrails.

Google erbjuder ett annat exempel. Google Cloud beskriver Model Armor som ett skydd för in- och utdata till generativ AI. I Gemini Enterprise anges tjänsten kunna användas utan extra avgift i alla utgåvor. Som fristående tjänst anges en fri nivå på upp till två miljoner tokens per månad, och därefter 0,10 dollar per ytterligare miljon tokens. Dokumentationen beskriver bland annat screening för prompt injection, känslig data och skadliga länkar.

Men även här spelar driften roll. I Gemini Enterprise kan kunden välja om interaktioner ska tillåtas eller blockeras när screeningtjänsten inte är tillgänglig. Google dokumenterar också begränsningar för vilka agenttyper som screenas. Att Model Armor ingår i en Gemini Enterprise-prenumeration gör därför inte modellen direkt jämförbar med Microsoft Agent 365 eller med en specialistprodukt från CrowdStrike. De hanterar olika delar av ett större säkerhetsarbete.

OpenAI och Anthropic: produktytan måste vara tydlig

Hos OpenAI är det särskilt viktigt att inte blanda ihop ChatGPT-arbetsytan med API-plattformen. ChatGPT Business innehåller enligt OpenAI bland annat SAML SSO, MFA, central administration och standardinställningen att affärsdata inte används för träning. Enterprise lägger till dokumenterade organisationskontroller som SCIM, Enterprise Key Management, rollbaserad åtkomststyrning, Compliance Logs Platform och IP-listning.

Det betyder inte att ”IP-listning kräver Enterprise” i varje OpenAI-sammanhang. OpenAI dokumenterar en separat IP-listning för API-anrop, tillgänglig för API-kunder, och den gäller inte åtkomst till ChatGPT-arbetsytan eller inloggning. På samma sätt är API-RBAC en kontroll för API-organisationer och Dashboarden. En korrekt jämförelse måste alltså fråga vilken produkt som används innan den drar en slutsats om vilka kontroller som ingår.

Anthropic har också en tydlig nivåskillnad. Claude Team är för grupper med två till 150 användare. En Standard-plats kostar enligt Anthropics aktuella prislista 20 dollar per månad med årsbetalning eller 25 dollar månadsvis. Team omfattar bland annat central administration och SSO. Claude Enterprise har ett angivet pris på 20 dollar per plats och månad med årsbetalning, med minst 20 platser vid självbetjäning och 50 vid säljstöd. Användning av Claude, Claude Code och Cowork debiteras där utöver platsavgiften till ordinarie API-priser.

Enterprise innehåller, utöver Team, bland annat finfördelade rollbaserade behörigheter, SCIM, audit logs, Compliance API, anpassad datalagringstid, nätverksstyrd åtkomst och IP-listning. Det gör Enterprise till ett exempel på ytterligare organisationskontroller, men innebär inte att Team är osäkert. Planerna har olika målgrupp, användningsmodell och kontrollnivå.

Claude Code illustrerar en annan form av inbyggd produktarkitektur. Anthropic beskriver ett behörighetsläge där verktyget normalt är läsbehörigt tills användaren godkänner ändringar, kommandon eller annan åtkomst. Bolaget beskriver också sandboxing med filsystems- och nätverksisolering. Anthropic kopplar det till problemet med approval fatigue: många upprepade godkännanden kan göra att användaren slutar granska dem ordentligt. Det är Anthropics egen produkt- och observationsbeskrivning, inte ett generellt bevis för hur alla AI-agenter fungerar. Men det visar varför säkerhet kan behöva byggas in i hur ett verktyg får agera, inte bara läggas ovanpå i efterhand.

När separat specialistförsvar kan vara rimligt

Det går för långt att använda varje separat säkerhetsprodukt som bevis för att AI-leverantören har lämnat kunden oskyddad. CrowdStrike och NVIDIA visar varför. Den 21 oktober 2026 meddelade bolagen att CrowdStrikes Falcon Guardian, som CrowdStrike beskriver som AI Detection and Response, integreras med NVIDIAs OpenShell. Samma meddelande beskriver en Sentry-integrering på BlueField-4 som ett kommande steg, inte som en redan utbyggd kundfunktion.

Skillnaden spelar roll. OpenShell beskrivs av NVIDIA som en referensarkitektur och säker runtime-miljö. Sentry och BlueField-4 beskrivs som ett ytterligare lager för övervakning utanför själva agentmiljön och för att stoppa eller isolera hot nära infrastrukturen. Det är inte samma sak som att en färdig Sentry-integrering redan är driftsatt hos kunder. Och det är bolagens egen beskrivning av arkitekturen, inte en oberoende säkerhetsgranskning.

Just den typen av specialiserat försvar på djupet kan vara legitim att köpa separat. Ett företag med högre risk, egen infrastruktur eller mycket känsliga agentflöden kan ha andra behov än ett litet team som använder en AI-assistent i en begränsad arbetsyta. Frågan är inte om alla ska få samma avancerade lösning. Frågan är om den grundnivå som krävs för den utlovade användningen är tydlig, möjlig att administrera och rimligt åtkomlig.

CISA:s princip: lägg inte allt ansvar på kunden

Här finns en användbar princip utanför leverantörernas egna prislistor. CISA och andra myndigheter har i sin vägledning om secure by design argumenterat för att leverantörer bör ta ett större ansvar för säkerhet från början. Vägledningen nämner bland annat MFA för privilegierade användare, SSO enligt moderna standarder och högkvalitativa audit logs utan extra kostnad. I en senare insats lyfte CISA fram att Microsoft gjorde utökad loggning tillgänglig för federala kunder oavsett licensnivå.

Det betyder inte att varje avancerad säkerhetsprodukt måste vara gratis. Myndighetsprincipen gör ingen sådan generell prissättningsregel. Den ger däremot en skarp fråga att ställa: om en funktion är nödvändig för att en kund ska kunna upptäcka, förstå och hantera allvarliga risker i en produkt, bör den då vara en dyr extrarad eller en del av den säkra standarden?

NextNet-analys: säkerhetsklyftan kan börja i driften

Det är ännu inte bevisat att företag i stor skala avstår nödvändig AI-säkerhet därför att den är för dyr. Därför ska ”vem har råd att vara skyddad?” läsas som en öppen fråga, inte som ett fastslaget marknadsresultat. Men risken för en klyfta är begriplig: stora organisationer har oftare specialistroller, etablerade identitets- och loggplattformar samt tid att testa nya kontrollmodeller. Mindre företag kan sakna samma marginaler.

ENISA:s undersökning om små och medelstora företags beredskap för EU:s Cyber Resilience Act handlar inte om AI-säkerhetsköp. Den kan alltså inte bevisa att små företag väljer bort AI-skydd av kostnadsskäl. Men den påminner om ett relevant sammanhang: krav på cybersäkerhet möter i praktiken begränsningar i kunskap, resurser och genomförandekapacitet.

Det finns också en mänsklig dimension. Snabb AI-införing kan kräva återkommande utbildning, förändrade arbetsflöden och uppmärksamhet på nya risker. NextNet avser att undersöka separat hur sådan omställning påverkar arbetsbelastning och stress. Den här artikeln gör inte påståendet att AI redan har bevisats orsaka en allmän ökning av arbetsstress.

Artikeln har inte visat att små och medelstora företag redan avstår nödvändigt AI-skydd för att det är för dyrt. Den har däremot visat att säkerheten kan vara inbyggd, ligga i en högre plan, prissättas efter användning eller köpas som ett separat specialistlager. Oavsett prismodell tillkommer dessutom internt arbete som sällan syns i abonnemangspriset.

Därför bör ett företags AI-kalkyl börja med säkerhet och drift, inte lägga till dem i efterhand. Frågan är inte bara vad AI kostar, utan vad det kostar att använda den på ett sätt företaget faktiskt kan lita på.

Även när ett företag har betalat för ytterligare skydd återstår nästa fråga: vad händer när skyddet ändå brister? Den frågan hör hemma i nästa artikel i serien.

💬 Vad tycker du?

Vilka säkerhetsfunktioner bör ingå från början när ett företag köper AI som kan arbeta i riktiga system?

Dela gärna dina tankar i kommentarerna.

📚 Relaterade artiklar