Riskbedömning av AI: mall med riskmatris och exempel
En riskbedömning av AI är ett strukturerat dokument där ni beskriver vad ett AI-system gör, hur AI-förordningen klassar det, vilka skador det kan orsaka, hur sannolika och allvarliga de är, vilka åtgärder som minskar dem och vem som accepterar restrisken. Gör en bedömning per användningsfall och uppdatera den när något väsentligt ändras.
Det viktigaste i korthet
- En bra mall för riskbedömning av AI har tolv avsnitt: från systembeskrivning och ändamål till riskklassning, sannolikhet × konsekvens, åtgärder, restrisk, mänsklig kontroll, beslut och översyn.
- Artikel 9 i AI-förordningen kräver ett formellt riskhanteringssystem av leverantörer av AI-system med hög risk. Tillhandahållare har ingen skyldighet enligt artikel 9, men behöver ett eget riskarbete för att klara artikel 26 och i vissa fall artikel 27.
- ISO/IEC 23894 ger vägledning om riskhantering för AI, och ISO/IEC 42001 kräver riskbedömning, riskbehandling och konsekvensbedömning av AI-system inom ett ledningssystem.
- Använd en enkel 5 × 5-matris, men skriv ned resonemanget. Motiveringen väger tyngre än siffran.
- Kraven för högrisksystem enligt bilaga III gäller från 2 december 2027 – per oktober 2026 är det dags att bygga vanan nu.
Varför behövs en särskild riskbedömning för AI?
De flesta svenska organisationer gör redan riskbedömningar för informationssäkerhet och konsekvensbedömningar enligt GDPR. AI-system tillför risker som de processerna inte är byggda för att fånga: en modell som rangordnar kvinnor lägre i ett urval, en chattbott som hittar på en returpolicy, en kodassistent som får en kunds API-nyckel i en prompt, eller en leverantör som i tysthet börjar träna på era data. En riskbedömning av AI synliggör de riskerna och ger varje risk en ägare.
Den är också grunden för arbetet med AI-förordningen (EU AI Act). Ni kan inte avgöra vilka skyldigheter som gäller förrän ni vet vad systemet är, vad det används till och vilken roll ni har. Har ni inte kartlagt det ännu förklarar vår guide till AI-förordningen hur regelverket fungerar. Vill ni ha en mall anpassad efter er verksamhet direkt kan ni ta Opsios kostnadsfria AI-förordningsbedömning: den skriver en mall för riskbedömning av AI utifrån era svar, tillsammans med tre andra styrdokument. Frågorna ställs på svenska; dokumenten levereras på engelska som redigerbara Word-filer.
Vill ni ha expertstöd med riskbedömning av ai: mall med riskmatris och exempel?
Våra molnarkitekter hjälper er med riskbedömning av ai: mall med riskmatris och exempel — från strategi till implementation. Boka ett kostnadsfritt 30-minuters rådgivningssamtal utan förpliktelse.
Artikel 9 – leverantörens riskhantering och tillhandahållarens riskarbete
Artikel 9 i förordning (EU) 2024/1689 kräver att leverantörer av AI-system med hög risk inrättar, dokumenterar och underhåller ett riskhanteringssystem som löper över hela livscykeln. Det ska identifiera kända och rimligen förutsebara risker för hälsa, säkerhet och grundläggande rättigheter, uppskatta risker vid avsedd användning och vid rimligen förutsebar felaktig användning, utvärdera risker som framkommer vid övervakning efter utsläppandet på marknaden och leda till riktade åtgärder. Restrisken ska bedömas som godtagbar, och systemet ska testas mot fastställda mått innan det släpps ut på marknaden.
Tillhandahållare – den som använder ett AI-system under eget ansvar i yrkesmässig verksamhet, ofta kallad ”användare” – omfattas inte av artikel 9. Deras skyldigheter för högrisksystem finns i artikel 26: följa bruksanvisningen, ge uppgiften att utöva mänsklig kontroll till kompetenta personer, se till att indata är relevanta, övervaka driften, spara loggar i minst sex månader, informera arbetstagarrepresentanter före användning på arbetsplatsen och informera berörda personer. Vissa tillhandahållare ska också göra en konsekvensbedömning avseende grundläggande rättigheter enligt artikel 27. Inget av det går att göra väl utan en dokumenterad bild av riskerna. Därför lönar det sig att ha en mall även när lagen inte nämner den vid namn. Vilka skyldigheter som gäller för högrisksystem beskrivs i kraven för AI-system med hög risk.
| Aspekt | Leverantör (artikel 9) | Tillhandahållare (riskarbete för artikel 26) |
|---|---|---|
| Rättslig grund | Obligatoriskt riskhanteringssystem för AI med hög risk | Ingen namngiven riskbedömning; behövs för att uppfylla artikel 26 och 27 |
| Omfattning | Design, data, testning, övervakning efter utsläppande | Er kontext: användare, indata, berörda personer, mänsklig kontroll |
| Viktigaste underlag | Träningsdata, testresultat, avsett ändamål | Leverantörens bruksanvisning, er process, era medarbetare |
| Resultat | Teknisk dokumentation, bedömning av restrisk | Post i riskregistret, åtgärder, plan för mänsklig kontroll, konsekvensbedömning där den krävs |
Standarder som formar mallen: ISO/IEC 23894, ISO/IEC 42001 och NIST AI RMF
Tre ramverk är bra att känna till. ISO/IEC 23894:2023 är vägledning om riskhantering för AI och anpassar processen i ISO 31000 – fastställ sammanhang, identifiera, analysera, värdera, behandla, följ upp – till AI. ISO/IEC 42001:2023 är den certifierbara standarden för ledningssystem för AI. I avsnitt 6.1 kräver den en riskbedömning för AI, en riskbehandling där valda åtgärder ställs mot kontrollerna i bilaga A i ett uttalande om tillämplighet, och en konsekvensbedömning av AI-systemets påverkan på individer, grupper och samhället. Mer om standarden finns i vad ISO 42001 är. Det frivilliga NIST AI Risk Management Framework delar in arbetet i fyra funktioner: Govern, Map, Measure och Manage. Mallen nedan fungerar med alla tre, men ingen av dem ersätter AI-förordningens krav.
Mall för riskbedömning av AI – avsnitt för avsnitt
1. Dokumentstyrning
Bedömnings-ID, systemets namn, version av bedömningen, datum, författare, riskägare och nästa översyn. Lägg en ändringslogg sist.
2. Systembeskrivning
Vad systemet är, på klarspråk: leverantör eller internt team, typ av modell (regler, maskininlärning, stor språkmodell), eventuell underliggande AI-modell för allmänna ändamål, driftform (SaaS, privat moln, lokalt), integrationer, indata och utdata samt vilka som använder det. Koppla posten till ert AI-register så att de två inte glider isär.
Exempel: ”Urvalsmodulen är en del av vårt rekryteringssystem (SaaS). Den använder en maskininlärningsmodell från leverantören för att poängsätta CV:n mot en kravprofil och ger rekryterarna en rangordnad lista.”
3. Avsett ändamål och användningssammanhang
Det ändamål leverantören anger, det ändamål ni faktiskt använder systemet för, vilka beslut det påverkar, vilka som berörs och vad som ligger utanför. Skriv också ned rimligen förutsebar felaktig användning, till exempel att rekryterare behandlar poängen som ett slutligt beslut.
4. Klassning enligt AI-förordningen och er roll
Ange risknivå – förbjuden, hög risk, transparensrisk eller minimal risk – och motiveringen. För hög risk anger ni punkten i bilaga III eller lagstiftningen i bilaga I. Nivåerna förklaras i riskklassificering enligt AI-förordningen. Ange sedan er roll: leverantör, tillhandahållare, importör eller distributör, och notera allt som kan göra er till leverantör, som att sätta ert namn på systemet eller ändra det väsentligt.
5. Riskidentifiering
Gå igenom varje kategori och formulera konkreta risker i formen orsak – händelse – konsekvens. ”Partiskhet” säger ingenting. ”Modellen ger lägre poäng till sökande med luckor i cv:t, vilket missgynnar personer som varit föräldralediga” går att åtgärda.
| Kategori | Frågor att ställa |
|---|---|
| Hälsa och säkerhet | Kan ett svar leda till fysisk skada eller osäkert agerande, direkt eller via en person som litar på det? |
| Grundläggande rättigheter och diskriminering | Kan utfallen skilja sig orättvist efter kön, ålder, etnicitet, funktionsnedsättning eller annan diskrimineringsgrund? Finns en väg att ifrågasätta beslutet? |
| Dataskydd | Behandlas personuppgifter eller känsliga personuppgifter? Rättslig grund, minimering, lagringstid, automatiserade beslut enligt artikel 22 i GDPR? |
| Säkerhet | Promptinjektion (direkt och via dokument eller webbinnehåll), dataläckage via svar, leverantörskedjan för modeller och tillägg, för breda behörigheter för AI-agenter, hemligheter i prompter. |
| Noggrannhet och robusthet | Felfrekvens på era data, påhittade svar, drift över tid, beteende i ovanliga fall och vid avsiktligt vilseledande indata. |
| Transparens | Vet människor att de har kontakt med AI (artikel 50)? Kan personalen förklara ett utfall för den som berörs? |
| Leverantör | Tränar leverantören på era data, byter modell utan förvarning, lagrar data utanför EU eller saknar rutin för incidentrapportering? |
| Verksamhet och anseende | Överdrivet förtroende, förlorad kompetens, avbrott, pinsamma svar i publika kanaler. |
6. Sannolikhet och konsekvens – riskmatrisen
Använd en skala från 1 till 5 för båda och multiplicera. Definiera skalorna i mallen, så att två bedömare ger samma risk samma poäng.
| Sannolikhet ↓ / Konsekvens → | 1 Försumbar | 2 Liten | 3 Måttlig | 4 Stor | 5 Allvarlig |
|---|---|---|---|---|---|
| 5 Nästan säker | 5 | 10 | 15 | 20 | 25 |
| 4 Trolig | 4 | 8 | 12 | 16 | 20 |
| 3 Möjlig | 3 | 6 | 9 | 12 | 15 |
| 2 Osannolik | 2 | 4 | 6 | 8 | 10 |
| 1 Sällsynt | 1 | 2 | 3 | 4 | 5 |
En vanlig indelning är 1–4 låg (acceptera och följ upp), 5–9 medel (åtgärda inom en bestämd tid), 10–16 hög (åtgärda före driftstart eller fortsatt användning) och 20–25 kritisk (stoppa eller gör om). Konsekvensen för människors rättigheter ska väga minst lika tungt som den ekonomiska. En ”liten” kostnad för företaget kan vara ett allvarligt utfall för den som blir bortsorterad från en tjänst.
7. Befintliga och planerade åtgärder
Ange för varje risk vilka åtgärder som redan finns och vilka som ska tillkomma, med ansvarig och datum. Typiska AI-åtgärder: test av partiskhet på representativa data, tröskelvärden för säkerhet i svaren, mänsklig granskning av negativa beslut, filtrering av svar, sökning begränsad till godkända källor, minsta möjliga behörighet för kopplingar, pseudonymisering innan data når modellen, loggning, utbildning och avtalsklausuler med leverantören.
8. Restrisk
Poängsätt igen efter åtgärderna. Ange uttryckligen om restrisken ligger inom er riskaptit och, om inte, vad som händer härnäst. Artikel 9 kräver att leverantörer bedömer restrisken som godtagbar; tillhandahållare gör klokt i att tillämpa samma disciplin.
9. Mänsklig kontroll
Vem kan ingripa, vad ser de, vilken befogenhet har de att ändra eller stoppa systemet och vilken utbildning har de fått? För högrisksystem hänger det ihop med leverantörens åtgärder för mänsklig kontroll enligt artikel 14 och er skyldighet enligt artikel 26 att utse personer med nödvändig kompetens, utbildning och befogenhet.
10. Koppling till dataskydd
Hänvisa till konsekvensbedömningen enligt artikel 35 i GDPR om en sådan behövs, den rättsliga grunden och lagringstiden.
11. Beslut och underskrift
Riskägare, verksamhetsägare, dataskyddsombud, säkerhetsansvarig och, vid hög eller kritisk restrisk, någon i ledningen. Ange datum och beslut: godkänt, godkänt med villkor eller avslaget.
12. Utlösare för översyn
Årlig översyn som minimum, plus händelser: ny modellversion från leverantören, nytt användningsfall eller ny användargrupp, nya datakällor, en allvarlig incident eller ett tillbud, klagomål från en berörd person, ändrade regler eller ny vägledning, eller nyckeltal som passerar en gräns.
Ifyllda exempelrader
Poängen nedan är illustrativa och gäller ett tänkt svenskt företag.
| System och klassning | Risk | S × K före åtgärder | Åtgärder | Restrisk |
|---|---|---|---|---|
| CV-sortering i rekryteringssystemet. Hög risk, bilaga III punkt 4 (anställning). Ni är tillhandahållare. | Modellen ger lägre poäng till sökande med luckor i cv:t, vilket indirekt missgynnar kvinnor och personer som varit föräldralediga; rekryterare litar på rangordningen utan granskning. | 4 × 4 = 16 | Leverantörens testresultat för partiskhet begärda och granskade; kvartalsvis kontroll av utfall på egna data; rekryterare granskar varje bortsortering; sökande informeras om AI-användningen och hur de begär mänsklig prövning; loggar sparas i 12 månader; facket informerat. | 2 × 4 = 8 (medel, accepterad av HR-chef med kvartalsvis uppföljning) |
| Kundtjänstchattbott på webbplatsen. Transparensrisk, artikel 50.1. Ni är tillhandahållare. | Botten anger fel villkor för ångerrätt och kunden agerar på det. Indirekt promptinjektion via inklistrad text får den att avslöja interna instruktioner. | 3 × 3 = 9 | Svar bara från godkänd kunskapsbas; vägrar svara utanför sitt område; tydlig upplysning ”Du chattar med en AI-assistent”; överlämning till människa; härdade systeminstruktioner och injektionstester före varje release. | 2 × 2 = 4 (låg) |
| Microsoft 365 Copilot för alla tjänstemän. Minimal risk enligt AI-förordningen; GDPR och informationssäkerhet gäller. | Assistenten visar dokument som användaren inte borde se eftersom behörigheterna i SharePoint är för breda; medarbetare klistrar in kunders personuppgifter i prompter. | 4 × 4 = 16 | Behörighetsstädning och känslighetsetiketter före utrullning; AI-policy och utbildning; DLP-regler; loggning av användning; stegvis utrullning per avdelning. | 2 × 3 = 6 (medel) |
| Generativ AI för bilder i marknadsföring. Transparensrisk, artikel 50.4 vid deepfakes. | En realistisk AI-bild av en verklig person publiceras utan märkning eller samtycke. | 3 × 3 = 9 | Regel i varumärkesmanualen om märkning; samtycke krävs för verkliga personer; granskning före publicering. | 1 × 3 = 3 (låg) |
Lägg märke till att Copilot får lika hög poäng som CV-verktyget före åtgärder, trots att AI-förordningen räknar det som minimal risk. Regulatorisk risknivå och verksamhetsrisk är två olika frågor, och mallen ska besvara båda.
Så genomför ni riskbedömningen i praktiken
- Utgå från AI-registret. Lista alla AI-system och användningsfall, även AI-funktioner som slagits på i befintliga SaaS-tjänster.
- Sortera. Gör en kort screening av allt och en fullständig bedömning av högrisksystem, kundnära system och system med mycket data först.
- Hämta leverantörens underlag. För högrisksystem: bruksanvisning, mått på noggrannhet och kända begränsningar. Ställ frågorna i checklistan för leverantörsbedömning av AI.
- Håll en workshop. Samla verksamhetsägaren, en användare, dataskydd, säkerhet och gärna någon som företräder de berörda.
- Poängsätt, åtgärda och besluta. För sedan in åtgärderna i ert vanliga projekt- eller riskverktyg så att de följs upp.
- Följ upp. Välj två eller tre nyckeltal per system, till exempel andel överprövade beslut, antal klagomål och felfrekvens i stickprov, och agera när de rör sig.
Är ni osäkra på var bristerna finns i helheten sätter en gap-analys för AI-förordningen riskbedömningen i sammanhang med AI-policy, inventering, AI-kunnighet och leverantörsstyrning, så att ni kan prioritera.
Vanliga frågor
Måste vi göra en riskbedömning av AI enligt AI-förordningen?
Leverantörer av AI-system med hög risk måste enligt artikel 9 ha ett dokumenterat riskhanteringssystem under hela livscykeln. Tillhandahållare har ingen skyldighet med samma namn, men kraven i artikel 26 på mänsklig kontroll, övervakning och indata, och konsekvensbedömningen enligt artikel 27 för vissa tillhandahållare, är mycket svåra att uppfylla utan en dokumenterad riskbedömning.
Vad är skillnaden mellan en riskbedömning av AI och en konsekvensbedömning avseende grundläggande rättigheter?
Riskbedömningen täcker alla relevanta risker, även säkerhet, noggrannhet, leverantör och verksamhet. Konsekvensbedömningen enligt artikel 27 är smalare och lagstadgad för vissa tillhandahållare av högrisksystem, till exempel offentliga organ och den som gör kreditprövning. Den fokuserar på de berörda, de specifika skadorna och åtgärderna om riskerna inträffar. Många gör den som en förlängning av riskbedömningen.
Hur ofta ska riskbedömningen uppdateras?
Minst en gång per år och när något väsentligt ändras: en ny modellversion, ett nytt användningsfall, nya data, en incident, ett klagomål eller ny vägledning från tillsynsmyndigheter. För generativa AI-tjänster bör ni följa leverantörens versionsinformation, eftersom modelluppdateringar kan ändra beteendet utan att ni gjort något.
Kan vi använda ISO/IEC 23894 eller NIST AI RMF i stället för en egen mall?
De är ramverk, inte ifyllnadsmallar. ISO/IEC 23894 beskriver riskhanteringsprocessen för AI och NIST AI RMF ger funktioner och föreslagna åtgärder. En praktisk mall som den ovan omsätter principerna i ett format som era team kan fylla i per system, och som kopplar till rollerna och skyldigheterna i AI-förordningen.
Vem ska godkänna en riskbedömning av AI?
Riskägaren, normalt verksamhetsägaren för användningsfallet, godkänner med underlag från dataskydd, säkerhet och juridik eller compliance. Höga eller kritiska restrisker ska accepteras av någon i ledningen med befogenhet att stoppa systemet. Dokumentera beslut och villkor så att godkännandet går att spåra i efterhand.
Få er mall för riskbedömning skriven
Ni kan bygga mallen ovan från grunden, eller svara på frågorna en gång och få den skriven för er. Gör en gratis bedömning av er AI-styrning: fjorton steg med frågor på svenska, cirka 40 minuter. När ni skickar in skrivs fyra styrdokument utifrån era svar – mall för riskbedömning av AI, AI-policy för medarbetare, ramverk för AI governance och checklista för AI-leverantörer – plus en mognadsbild över tio områden. Dokumenten levereras på engelska som redigerbara Word-filer och är era att behålla. Vill ni ha hjälp att bedöma en större portfölj av AI-system, se vår rådgivning inom AI governance.
Den här artikeln är allmän information, inte juridisk rådgivning. Kontrollera den konsoliderade texten till förordning (EU) 2024/1689 i dess lydelse enligt förordning (EU) 2026/1744. Datum och standardernas status anges per oktober 2026.
Om författaren
Group COO & CISO
Fredrik är koncernens COO och CISO på Opsio. Han fokuserar på operationell excellens, styrning och informationssäkerhet och arbetar nära leverans- och ledningsteamen för att samordna teknik, risk och affärsresultat i komplexa IT-miljöer. Han leder Opsios säkerhetspraktik, inklusive SOC-tjänster, penetrationstester och compliance-ramverk.
Redaktionella riktlinjer: Artikeln är skriven av en certifierad praktiker och granskad av vårt ingenjörsteam. Vi uppdaterar den när tekniken eller regelverket den handlar om förändras; datumen ovan visar den senaste uppdateringen. Opsio är redaktionellt oberoende — vi rekommenderar lösningar utifrån tekniska meriter, inte kommersiella relationer.