”AI-cybersäkerhet” är ingen enskild befattning i någon arbetsgivares organisationsschema. Begreppet betecknar en grupp roller som under de senaste åren har vuxit fram inom befintliga säkerhetsteam, och var och en bygger på en annan del av den traditionella disciplinen: att testa AI-system på samma sätt som en penetrationstestare undersöker en applikation, att säkra programvaran och de flöden som omger en driftsatt modell, att använda AI-verktyg i detektions- och incidentarbete, och att styra hur en organisation över huvud taget inför tekniken. Ingen av de standardiseringsorgan eller arbetsmarknadsstudier som citeras nedan behandlar dessa som en och samma roll, och det gör inte heller den här artikeln.
Bakgrund
Den referenspunkt som de flesta amerikanska arbetsgivare och utbildningsaktörer använder för att beskriva cybersäkerhetsyrken i allmänhet är NICE Workforce Framework for Cybersecurity, som förvaltas av NIST och publiceras av CISA. Ramverket delar in yrket i kategorier av arbetsroller – Oversight and Governance, Design and Development, Implementation and Operation, Protection and Defense samt Investigation – som var och en bryts ned i påståenden om uppgifter, kunskaper och färdigheter snarare än fasta yrkestitlar [1]. När detta skrivs har det publicerade ramverket ingen egen AI-specifik kategori; rollerna som beskrivs i artikeln ryms inom dess befintliga kategorier och lånar begrepp från nyare, AI-specifikt referensmaterial där ramverket är tyst.
Det nyare materialet kommer främst från tre håll: OWASP:s Gen AI Security Project, som publicerar Top 10 for LLM Applications, en lista över riskkategorier som promptinjektion, röjande av känslig information, risker i leveranskedjan och överdriven handlingsfrihet [2]; MITRE ATLAS, en öppen kunskapsbas över angripares taktiker och tekniker riktade mot AI-system, byggd som ett komplement till MITRE:s ramverk ATT&CK [3]; och NIST AI Risk Management Framework, som strukturerar arbetet med AI-risker i fyra funktioner – Govern, Map, Measure och Manage [4]. Den som arbetar i någon av de fyra rollerna nedan förväntas i praktiken känna till minst ett av dessa tre dokument.
På arbetsmarknadssidan registrerade CyberSeek – ett samarbete mellan NICE, CompTIA och analysföretaget Lightcast – 514 359 platsannonser för cybersäkerhetstjänster på den amerikanska marknaden mellan maj 2024 och april 2025, mot en uppskattad global cybersäkerhetsarbetskraft på omkring 4 970 000 personer. Av dessa annonser fann CyberSeek att 10 procent uttryckligen angav AI-kunskaper som krav [5]. Det är en minoritet av annonserna, och det påverkar hur resten av artikeln bör läsas: AI-säkerhetsarbete är i dag ett tillägg till en cybersäkerhetskarriär, lagt ovanpå en grund, och ännu ingen egen arbetsmarknad.
Underlag
AI-red teaming är den mest offentligt dokumenterade av de fyra. Microsofts AI Red Team, som bildades 2018, beskriver sitt uppdrag som att testa AI-system för både avsiktligt missbruk och vanliga fel, och teamets egen redogörelse lyfter fram två sätt på vilka arbetet skiljer sig från testning av konventionell programvara: generativa system är probabilistiska, så ”samma indata två gånger kan ge olika utdata”, vilket kräver upprepade försök i stället för ett enda deterministiskt test; och applikationerna som byggs ovanpå modellerna ”förändras i snabbare takt” än traditionell programvara, så en bedömning som görs en gång blir inaktuell fortare [6]. De som arbetar i rollen använder MITRE ATLAS som arbetsreferens för att katalogisera angreppstekniker mot maskininlärningssystem, på samma sätt som en konventionell red teamer använder ATT&CK [3].
Modell- och agentsäkerhet är en smalare och mer ingenjörsinriktad roll: att säkra applikationslagret runt en driftsatt modell snarare än modellens egna vikter eller träningsdata. OWASP:s Top 10 for LLM Applications är det närmaste detta delområde har en gemensam kursplan, och dess kategorier fungerar samtidigt som en ungefärlig arbetsbeskrivning – promptinjektion, osäker hantering av utdata, förgiftning av data och modeller, överdriven handlingsfrihet för en autonom agent, och risker i leveranskedjan för de bibliotek och tredjepartsmodeller som en applikation är beroende av [2]. De som gör det här arbetet kommer oftare från applikationssäkerhet än från datavetenskap, eftersom den underliggande färdigheten är att granska hur obetrodd indata flödar genom ett system, tillämpad på en nyare sorts system.
Detektionsutveckling med AI hör hemma i NICE-kategorin Protection and Defense och överlappar i hög grad med befintligt arbete inom säkerhetsdrift: att bygga de regler, modeller och flöden som omvandlar rå telemetri till larm som en människa kan agera på, numera med AI-genererade eller AI-stödda signaler bland indata [1]. MITRE D3FEND, en kunskapsgraf över defensiva motåtgärder som MITRE har tagit fram tillsammans med NSA:s Cybersecurity Directorate, är den närmaste publicerade referensen för denna sida av arbetet: den ordnar försvar i sex taktiker – Model, Harden, Detect, Isolate, Deceive och Restore – och kopplar specifika motåtgärder till de offensiva tekniker de motverkar, vilket ger detektionsutvecklare ett gemensamt språk för vad en viss kontroll faktiskt gör [7]. Inget i D3FEND är AI-specifikt; rollen består i att tillämpa det på flöden som numera innehåller AI-härledda signaler.
AI-styrning är det nyaste området och, enligt tillgängliga underlag, för närvarande det enskilt största område som arbetsgivare och yrkesverksamma uttrycker oro kring. NIST:s eget ramverk behandlar styrning som en av sina fyra kärnfunktioner, som omfattar organisatorisk tillsyn, ansvarsstrukturer och policy innan någon teknisk kontroll tillämpas [4]. ISC2 genomförde i september 2026 en enkät bland fler än 500 cybersäkerhetsexperter på LinkedIn och frågade vad som mest behöver definieras när AI omformar yrket; 68 procent valde ”AI governance and compliance”, före ramverk för hotmodellering av AI (16 procent), säkring av dataflöden för AI (11 procent) och försvar mot adversariella angrepp (5 procent) [8]. En enkät av den storleken och formen är inget vetenskapligt urval av hela yrkeskåren, vilket artikeln återkommer till under Begränsningar, men resultatets riktning – att styrning väger tyngre än alla tekniska kategorier tillsammans – är svår att tolka på något annat sätt.
| Roll | Vad den gör | Kommer från | Referensmaterial |
|---|---|---|---|
| AI-red teaming | Undersöker driftsatta AI-system efter fel och missbruk, upprepade gånger eftersom utdata är probabilistiska | Penetrationstestning, forskning om adversariell ML | MITRE ATLAS [3] |
| Modell-/agentsäkerhet | Säkrar applikationslagret och leveranskedjan runt en driftsatt modell eller agent | Applikationssäkerhet | OWASP LLM Top 10 [2] |
| Detektionsutveckling | Bygger och finjusterar flöden som omvandlar telemetri, inklusive AI-härledda signaler, till larm | Säkerhetsdrift, SOC-analys | MITRE D3FEND [7] |
| AI-styrning | Fastställer policy, ansvar och riskkontroller för hur en organisation inför AI | Riskhantering, regelefterlevnad | NIST AI RMF [4] |
Analys
Två saker framträder när rollerna ställs bredvid varandra. För det första är ingen av dem ett tydligt brott med befintligt cybersäkerhetsarbete – var och en är en traditionell disciplin (red teaming, applikationssäkerhet, säkerhetsdrift, styrning) tillämpad på en nyare sorts mål. Det stämmer med vad CyberSeeks data antyder: när bara 10 procent av annonserna uttryckligen nämner AI-kunskaper anställer de flesta arbetsgivare ännu inte en särskild ”AI-säkerhetsroll”, utan ber snarare befintliga roller att täcka mer [5]. För det andra går vägen in i var och en av de fyra fortfarande först via allmänna grunder i cybersäkerhet. NICE-ramverkets påståenden om uppgifter, kunskaper och färdigheter för de befintliga kategorierna – inte ett separat AI-spår – är fortfarande den grund som arbetsgivare och utbildningsaktörer beskriver [1], och ISC2:s certifiering på grundnivå, Certified in Cybersecurity (CC), som inte förutsätter någon tidigare yrkeserfarenhet, omfattar fortfarande allmänna säkerhetsprinciper, styrning, identitets- och åtkomsthantering, nätverk och säkerhetsdrift innan något AI-specifikt [9].
Människor kommer in i dessa roller via ett fåtal väl upptrampade vägar snarare än en enda rekryteringskanal: en grund i cybersäkerhet (självstudier, ett intensivprogram eller en examen) följd av specialisering inom ett team; en bakgrund inom programvaruutveckling eller datavetenskap som rör sig mot säkerhet när ett team behöver någon som säkrar det de har byggt; och praktisk övning genom capture-the-flag-tävlingar, som numera innehåller moduler om AI-säkerhet. Carnegie Mellon Universitys CyLab Security Academy driver picoCTF, en kostnadsfri plattform som har vidgats ”från grundläggande säkerhet till avancerade områden som AI-säkerhet”, och som betraktar uthålligt deltagande, inte ett enskilt certifikat, som det kompetensbevis den följer över tid [10]. Det arbetsgivare efterfrågar, sett över källorna ovan, är oftast praktisk kännedom om ett eller flera av NICE, OWASP:s LLM Top 10, MITRE ATLAS eller D3FEND och NIST AI RMF, tillsammans med de allmänna säkerhetsgrunder som alla fyra rollerna vilar på.
- Grunderna i cybersäkerhet först: CIA-triaden, skillnaden mellan hot, sårbarheter och risk, samt social manipulation – det begreppsförråd som alla fyra rollerna förutsätter. FireAI Universitys Foundations of cybersecurity täcker detta.
- Därefter hotmodellering: att lära sig resonera om vem som skulle angripa ett system och varför, innan man specialiserar sig på en teknik. Se Threat modelling and risk.
- Sedan ett spår: offensivt arbete mot AI-red teaming via Offensive security: how the red team thinks och Adversarial AI and threat hunting; defensivt arbete mot detektionsutveckling via Defensive operations: how the blue team works och, för den värdbaserade sidan av problemet, AI-driven desktop defense.
Rekommendationer
- Bygg den allmänna grunden före specialiseringen: NICE-ramverkets befintliga kategorier, inte ett rent AI-spår, är fortfarande vad de flesta arbetsbeskrivningar utgår från [1].
- Läs OWASP:s Top 10 for LLM Applications och skumma åtminstone igenom fallstudierna i MITRE ATLAS; båda är kostnadsfria och offentliga, och yrkesverksamma i dessa roller förväntas redan känna till dem [2] [3].
- Öva på en CTF-plattform som innehåller AI-säkerhetsuppgifter, till exempel picoCTF, i stället för att betrakta teori som tillräcklig [10].
- Om styrning intresserar dig, studera de fyra funktionerna i NIST AI RMF direkt; ISC2:s enkät tyder på att arbetsgivare i dag värderar detta område högre än någon enskild teknisk specialisering [4] [8].
- Följ hur de underliggande hoten och verktygen faktiskt utvecklas, i stället för att förlita dig på en enda statisk källa, genom en löpande forskningslogg som FireAI Radar.
Begränsningar
NICE-ramverket definierar i sin publicerade form ännu inga AI-specifika arbetsroller; de fyra grupperingarna i artikeln är denna publikations syntes av närliggande standarder, inte en officiell taxonomi, och yrkestitlarna för samma arbete varierar kraftigt mellan arbetsgivare [1]. ISC2:s enkät om styrning fick fler än 500 svar från en enda LinkedIn-publik som själv valde att svara; det är en verklig signal om stämningen bland yrkesverksamma, inte ett sannolikhetsurval av yrkeskåren, och felmarginalen anges inte [8]. CyberSeeks siffra på 10 procent räknar varje annons som över huvud taget nämner AI-kunskaper, vilket kan omfatta allmän AI-kunnighet snarare än just AI-säkerhetsarbete, och gäller endast den amerikanska marknaden [5]. Om lön: den enda hämtade källan med konkreta lönesiffror, ISC2:s globala certifieringsdata från 2024, är inte specifik för AI-säkerhetsroller – den redovisade globala genomsnittslöner från 94 948 dollar för certifieringen SSCP, nära grundnivå, till 119 577 dollar för CISSP per maj 2024 – och ingen källa som använts för artikeln anger en separat, tillförlitlig siffra för specialister inom AI-säkerhet [11].
Var FireAI och HisnLabs kommer in
Ingen av de fyra roller som artikeln beskriver är något en brandvägg utför; FireAI är ett smalare verktyg som körs på datorn, och den ärliga kopplingen till en karriär inom området går via praktik och referensmaterial, inte via produkten själv.
FireAI är HisnLabs eget verktyg: en AI-brandvägg som körs direkt på din Mac. Den visar varje anslutning dina appar gör, på klarspråk, och låter dig avgöra vad som lämnar din Mac — AI:n körs lokalt, så din trafik skickas aldrig till oss eller någon annan. HisnLabs säkerhetsforskningsteam är de som håller de bedömningarna tillförlitliga: de katalogiserar vilka domäner som är vanlig telemetri och vilka som är en riktig tjänst, spårar land och nätverk bakom en anslutning och tränar den lokala modellen (FireAI Pilot-funktionen) på verkliga trafikmönster — utan att något av det lämnar din Mac.
Du kan läsa om de tekniska besluten bakom, eller prova FireAI i 17 dagar, på FireAI, från HisnLabs.