AI og cybersikkerhet i 2026: sertifiseringer som faktisk teller

AI-sikkerhet i 2026 handler om å bruke AI til å oppdage, prioritere og styre risiko, samtidig som virksomheter må beskytte selve AI-systemene. Det betyr mer disiplinert sikring av modeller, treningsdata, integrasjoner og beslutningsprosesser.

En AI-sikkerhetssertifisering bør derfor forstås som dokumentasjon på kompetanse i skjæringspunktet mellom kunstig intelligens, sikkerhetsoperasjoner, skyarkitektur og risikostyring. Den viktigste vurderingen er ikke om en sertifisering har «AI security» i navnet, men om den dekker oppgavene en rolle faktisk skal løse: oppdage trusler raskere, sikre AI-løsninger, styre databruk eller dokumentere etterlevelse.

Oppdatert: juli 2026. Råd om rammeverk og regulering bør alltid kontrolleres mot gjeldende versjoner av NIST AI RMF, OWASP Top 10 for LLM Applications, MITRE ATLAS, GDPR, EU AI Act og NIS2 før de brukes i en produksjons- eller revisjonskontekst.

Det avgjørende skillet: AI for sikkerhet og sikkerhet for AI

Mange sertifiseringsvalg blir uklare fordi to ulike fagspor blandes sammen. AI for sikkerhet handler om å bruke maskinlæring, automatisering og generativ AI i sikkerhetsarbeid, for eksempel i SIEM-regler, anomali-deteksjon, phishing-triage, sårbarhetsprioritering og hendelsesrespons. Dette sporet passer særlig for SOC-analytikere, sikkerhetsingeniører og plattformteam som vil forbedre deteksjon og respons.

Sikkerhet for AI handler om å beskytte AI-systemene selv. Det omfatter tilgangsstyring til treningsdata, datakvalitet, modellstyring, logging, driftsovervåking, red-teaming av LLM-applikasjoner, model cards, data lineage og kontroll med endringer i MLOps-pipelinen. Dette sporet passer ofte bedre for skyarkitekter, sikkerhetsarkitekter, risikoteam, compliance-funksjoner og tekniske team som bygger eller drifter AI-løsninger.

Skillet har praktiske konsekvenser. En SOC-analytiker som skal bruke AI-støttet triage trenger andre ferdigheter enn en arkitekt som skal godkjenne en intern LLM-tjeneste med sensitiv kundedata. Den første må forstå signalstøy, alert-tuning, KQL, loggkilder og responsprosesser. Den andre må forstå datagovernance, modelltilgang, isolasjon, forsyningskjeder, tredjepartsrisiko og regulatoriske krav.

Hvilke sertifiseringer er mest relevante i 2026?

Markedet har få bredt anerkjente, leverandørnøytrale sertifiseringer som alene dekker hele feltet «AI-sikkerhet». I praksis bygger mange fagfolk en portefølje av etablerte sikkerhets-, sky- og AI-sertifiseringer, supplert med rammeverk og praktiske laboratorier. Det er mer troverdig enn å velge en uklar sertifisering med et lovende navn, men svakt faglig fotavtrykk.

For AI for sikkerhet er Microsoft AI-900 et naturlig grunnlag for begreper som maskinlæring, natural language processing, generativ AI og ansvarlig AI. Deretter gir SC-200 en mer operativ retning for sikkerhetsovervåking, hendelsesrespons og bruk av Microsoft Sentinel og Defender-verktøy. SC-100 passer når ansvaret dreier mot sikkerhetsarkitektur, styringsmodeller og beslutninger på tvers av identitet, data, applikasjoner og sky.

For sikkerhet for AI er CCSK et godt startpunkt for sky- og datasikkerhet, særlig fordi mange AI-løsninger bygges i skybaserte dataplattformer. CCSP gir mer dybde for arkitektur, risikostyring og kontroller i skyen. NIST AI RMF, OWASP Top 10 for LLM Applications og MITRE ATLAS bør brukes som praktiske referanser ved siden av sertifiseringene, fordi de beskriver risikoer og angrepsmønstre som ofte ikke dekkes dypt nok i tradisjonelle sikkerhetseksamener.

Microsoft Azure AI Engineer Associate, ofte knyttet til AI-102, er relevant for fagfolk som bygger AI-løsninger i Azure. Den er ikke en ren sikkerhetssertifisering, men Azure AI Engineer (AI-102) kan være nyttig for sikkerhetsarkitekter som trenger å forstå hvordan AI-tjenester faktisk designes, integreres og driftes. Sikkerhetsverdien kommer først når AI-kunnskapen kombineres med tilgangsstyring, logging, dataklassifisering og trusselmodellering.

Hvordan velge riktig læringssti

Et godt valg starter med rollen, ikke med kurskatalogen. SOC-analytikere får vanligvis mest igjen for AI-900 kombinert med SC-200, fordi de må forstå både AI-begreper og operativ sikkerhet. Sikkerhetsarkitekter bør se mot SC-100 og gjerne CCSK, fordi AI-risiko sjelden kan håndteres isolert fra identitet, dataflyt, skyarkitektur og governance. Sky-sikkerhetsroller får en tydeligere progresjon gjennom CCSK og deretter CCSP, mens risiko- og compliance-funksjoner bør kombinere CCSK med NIST AI RMF og juridiske rammer som GDPR, EU AI Act og NIS2.

Fagfolk som jobber nær MLOps eller model security trenger et mer teknisk bevisgrunnlag. De bør kunne forklare hvordan data flyter fra innsamling til trening og produksjon, hvilke miljøer som er separert, hvordan modellendringer godkjennes, og hvordan driftsavvik oppdages. OWASP Top 10 for LLM Applications er særlig nyttig når løsningen bruker prompt-baserte applikasjoner, retrieval-augmented generation eller eksterne verktøy som modellen kan kalle.

1. Velg først om hovedsporet er AI for sikkerhet eller sikkerhet for AI.
2. Bygg grunnmuren med én AI-sertifisering eller én sky-sikkerhetssertifisering.
3. Legg til en rollebasert sikkerhetssertifisering som matcher arbeidsoppgavene.
4. Dokumenter praktisk arbeid med logger, risikovurderinger og mitigasjoner.

En praktisk kombinasjon for SecOps kan være AI-900 før SC-200, med en hjemmelab som måler forbedring i triage og reduksjon av støy. For sky- og modellsikkerhet kan CCSK før CCSP gi bedre rekkefølge, supplert med grunnleggende maskinlæring og arbeid med model cards. Hos Readynez kan instruktørledet opplæring være nyttig når team må samordne sertifiseringsmål med praktiske øvelser, særlig der både Microsoft- og sikkerhetsspor inngår i samme kompetanseplan.

Hva arbeidsgivere ser etter utover sertifikatet

Sertifiseringer hjelper mest når de støttes av artefakter som viser hvordan kunnskapen brukes. Arbeidsgivere vurderer ofte om kandidaten kan beskrive dataflyt, kvalitet på loggkilder, feature engineering, alert-tuning, tilgangsstyring og kontrollpunkter for modellendringer. En kandidat som kan vise en enkel trusselmodell, en KQL-spørring, et model card og en kort risikovurdering fremstår mer relevant enn en kandidat som bare lister eksamener.

Dette gjelder særlig i AI-drevne sikkerhetsroller, fordi mange problemer først blir synlige i drift. En modell som fungerer godt i test kan få dårligere presisjon når angripernes teknikker endres, når loggformatet endres, eller når nye brukergrupper kommer inn i datagrunnlaget. Manglende overvåking av modelldrift er derfor en vanlig implementeringsfelle, sammen med datalekkasje mellom test- og produksjonsmiljøer, svak tilgangsstyring til treningsdata og utilstrekkelig testing mot adversarial angrep.

RACI-avklaringer er også undervurdert. AI-sikkerhet krever at noen eier datagovernance, noen overvåker drift, noen godkjenner modellendringer, og noen beslutter når en modell skal rulles tilbake. Uten tydelige roller kan team ende opp med gode tekniske kontroller, men uklart ansvar når modellen begynner å gi feil prioriteringer eller eksponerer sensitiv informasjon.

Praktiske scenarier sertifiseringene bør forberede deg på

Et realistisk scenario er en LLM-basert supportassistent som får tilgang til interne kunnskapsartikler. Risikoen er ikke bare at modellen svarer feil, men at en angriper bruker prompt-injection til å hente ut informasjon, omgå systeminstruksjoner eller få modellen til å kalle et verktøy på feil måte. OWASP Top 10 for LLM Applications hjelper teamet å strukturere slike tester, men den praktiske verdien ligger i å dokumentere testfunn, begrense verktøykall, filtrere kilder og logge mistenkelige mønstre.

Et annet scenario er datapoisoning i en modell som brukes til anomali-deteksjon. Hvis treningsdata påvirkes av angriperaktivitet, kan modellen lære at ondsinnede mønstre er normale. Mitigasjonen ligger i datakvalitetskontroller, separasjon av trenings- og valideringssett, sporbarhet på datasett, manuell gjennomgang av uvanlige perioder og en prosess for å stoppe utrulling når inputdata endrer karakter.

Modelldrift er en tredje utfordring. Sikkerhetsmodeller taper verdi når normalatferd endrer seg, for eksempel etter en større sky-migrering, en reorganisering eller innføring av nye identitetsrutiner. Derfor bør team måle falske positiver, falske negativer og endringer i datadistribusjon, og knytte funnene til konkrete justeringer i deteksjonslogikk og responsprosesser.

En enkel hjemmelab kan gjøre dette konkret. Bruk åpne eller interne testdata, bygg en hypotese om normal atferd, skriv en spørring som markerer avvik, og dokumenter hvilke hendelser som var nyttige eller støy. Målet er ikke å lage en perfekt modell, men å vise at sikkerhetsanalytikeren forstår sammenhengen mellom data, terskler, drift og respons.

Følgende eksempel viser en enkel KQL-tilnærming for å finne avvik i påloggingsvolum. Den kan brukes i en lab for å diskutere hvorfor terskler må justeres etter miljø, rolle og normal bruk.

Example — KQL for enkel anomali i pålogginger

SigninLogs
| where TimeGenerated > ago(14d)
| summarize SignInCount = count() by UserPrincipalName, bin(TimeGenerated, 1h)
| summarize AvgSignIns = avg(SignInCount), MaxSignIns = max(SignInCount) by UserPrincipalName
| where MaxSignIns > AvgSignIns * 3
| project UserPrincipalName, AvgSignIns, MaxSignIns
| order by MaxSignIns desc

Spørringen sammenligner høyeste registrerte timevolum med brukerens gjennomsnitt i perioden. I en reell lab bør funnene valideres mot kjente endringer, tjenestekontoer, reiseaktivitet og eksisterende alarmer før de brukes som grunnlag for automatisert respons.

Rammeverk, regulering og etikk hører hjemme i samme diskusjon

AI-sikkerhet kan ikke reduseres til modellhardening alene. NIST AI RMF gir språk for risiko, styring og måling av AI-systemer. MITRE ATLAS beskriver teknikker og taktikker knyttet til angrep mot AI-systemer. OWASP Top 10 for LLM Applications gir et praktisk startpunkt for applikasjonssikkerhet rundt generativ AI. Samtidig setter GDPR, EU AI Act og NIS2 rammer for databruk, ansvar, risikohåndtering og rapportering.

Etikk er også praktisk sikkerhetsarbeid når AI brukes i beslutningsstøtte. Feil datagrunnlag kan gi skjev prioritering av hendelser, feil klassifisering av brukere eller unødvendig innsamling av persondata. En grunnleggende forståelse av AI-etikk gjør det lettere å stille riktige spørsmål om formål, dataminimering, forklarbarhet og menneskelig kontroll.

Opplæring som faktisk bygger anvendbar kompetanse

Selvstudium kan fungere godt for begreper og rammeverk, men AI og cybersikkerhet læres best når teori kobles til praktiske beslutninger. En god opplæringsplan bør inneholde labarbeid med loggdata, enkel modellovervåking, trusselmodellering av en LLM-applikasjon, tilgangsdesign for treningsdata og dokumentasjon som kan deles med sikkerhetsledelse eller revisjon.

Instruktørledet opplæring kan være relevant når team trenger en felles progresjon og rask avklaring av vanskelige begreper. Det gjelder særlig når en virksomhet bygger rollebaserte løp på tvers av Microsoft-sikkerhet, Azure AI og sky-sikkerhet. Lesere som vurderer bredere Microsoft-kompetanse kan sammenligne format og dekning i instruktørledet Microsoft-opplæring, mens de som er nye i sikkerhetsfaget kan ha nytte av en mer grunnleggende karrierevei inn i cybersikkerhet før de spesialiserer seg.

Ofte stilte spørsmål om AI-sikkerhetssertifisering

Hvilken AI-sikkerhetssertifisering passer best for en SOC-analytiker?

En SOC-analytiker bør vanligvis prioritere AI-900 for AI-grunnbegreper og SC-200 for operativ sikkerhet, deteksjon og respons. Verdien øker når sertifiseringene kombineres med en lab som viser KQL, alert-tuning, triage og måling av falske positiver.

Hva bør en sikkerhetsarkitekt velge?

En sikkerhetsarkitekt bør vurdere SC-100 for arkitektur- og styringsperspektivet, gjerne kombinert med CCSK dersom AI-løsninger bygges i skyen. For LLM-applikasjoner bør arkitekten også bruke OWASP Top 10 for LLM Applications og NIST AI RMF som arbeidsreferanser.

Finnes det én sertifisering som dekker all AI-sikkerhet?

Det finnes ikke én etablert sertifisering som alene dekker hele feltet på en tilfredsstillende måte. De mest solide profilene bygges ofte gjennom en kombinasjon av AI-grunnlag, sikkerhetsoperasjoner, sky-sikkerhet, risikostyring og dokumenterte praktiske prosjekter.

Trenger man programmering for å jobbe med AI-sikkerhet?

Ikke alle roller krever dyp programmering, men teknisk forståelse er viktig. SOC-roller trenger ofte spørringer, automasjon og logikkforståelse, mens MLOps- og model security-roller krever mer innsikt i dataflyt, API-er, modelltesting og pipeline-kontroller.

Hvordan bør en virksomhet starte med kompetansebygging?

Virksomheten bør først avklare hvilke AI-systemer som brukes, hvilke data de behandler, og hvilke roller som eier drift, risiko og godkjenning. Deretter kan teamet velge et spor for AI for sikkerhet eller sikkerhet for AI, og knytte sertifiseringene til konkrete leveranser som trusselmodeller, logger, data lineage og model cards.

Veien videre for AI-sikkerhetskompetanse

Den mest robuste kompetanseplanen kombinerer sertifiseringer, praktiske laboratorier og rammeverk som kan brukes i reelle beslutninger. Sertifikatet viser at grunnlaget er på plass, mens artefakter som KQL-spørringer, risikovurderinger, model cards og testfunn viser at kompetansen kan brukes når AI møter produksjonsdata, angripere og regulatoriske krav.

Et godt neste steg er å velge ett spor, én plattform og én konkret lab. Den som vil samle sikkerhetsopplæring i en mer fleksibel modell, kan se nærmere på Unlimited Security Training hos Readynez og vurdere hvordan det passer inn i en rollebasert plan for AI og cybersikkerhet.