AI Act, NIS2, DORA & GDPR – vilka krav påverkar företagets AI-lösning?
Så skiljer sig AI Act, cybersäkerhetslagen/NIS2, DORA och GDPR – och vilka frågor företag bör ställa om risk, data, leverantörer och ansvar.
Alex Rivera
Founder
AI Act, NIS2 och DORA nämns ofta tillsammans, men de reglerar olika saker. AI-förordningen fokuserar på risker och ansvar i AI-system. NIS2 och den svenska cybersäkerhetslagen gäller cybersäkerhet i berörda verksamheter. DORA ställer krav på digital operativ motståndskraft i finanssektorn. GDPR gäller när personuppgifter behandlas.
En plattform kan ge tekniskt stöd för behörighet, loggning och datakontroll, men det innebär inte automatiskt att kunden uppfyller regelverken. Den konkreta användningen, organisationens roll och ansvarsfördelningen måste bedömas.
Observera: Artikeln ger en översikt och är inte juridisk rådgivning. Regelverk och vägledning förändras. Senast sakgranskad den 26 augusti 2026.
Fyra regelverk med olika syften
AI Act
AI Act är riskbaserad och skiljer bland annat mellan förbjudna användningar, högriskssystem, transparenskrav och låg- eller minimalriskssystem.[1]
NIS2 och cybersäkerhetslagen
NIS2/cybersäkerhetslagen fokuserar på riskhantering, säkerhetsåtgärder, ledning och incidentrapportering i samhällsviktiga och andra berörda sektorer.[2]
DORA
DORA harmoniserar krav på digital operativ motståndskraft för finansiella aktörer, inklusive IKT-risk, incidenter, tester och tredjepartsrisk.[3]
GDPR
GDPR reglerar behandling av personuppgifter och kräver bland annat rättslig grund, ändamålsbegränsning, dataminimering och lämplig säkerhet.[4]
Samma lösning kan omfattas av flera regelverk, men av olika skäl.
Att stödja ett krav är inte samma sak som att en kund automatiskt uppfyller regelverket.
AI Act: risk, transparens och ansvar
AI-förordningen trädde i kraft den 1 augusti 2024. Merparten av reglerna började tillämpas den 2 augusti 2026, medan vissa bestämmelser började gälla tidigare och andra omfattas av särskilda övergångsregler.[1] Kontrollera alltid den aktuella tidslinjen och den rättsliga texten.
Först behöver organisationen fastställa om lösningen är ett AI-system enligt förordningen och vilken roll organisationen har, exempelvis leverantör eller tillhandahållare/deployer. Därefter bedöms användningen.
System inom bland annat rekrytering, utbildning, kritisk infrastruktur och tillgång till vissa väsentliga tjänster kan vara högrisk beroende på funktion och sammanhang. Kraven kan omfatta riskhantering, datakvalitet, dokumentation, loggning, information till användare, mänsklig kontroll, robusthet och cybersäkerhet.
Transparensregler kan kräva att personer informeras när de interagerar med vissa system eller när visst innehåll är genererat eller manipulerat. AI-kunnighet är också en organisatorisk fråga: personalen behöver relevant kompetens för sin roll.
NIS2 och den svenska cybersäkerhetslagen
NIS2 har införlivats i Sverige genom cybersäkerhetslagen, som gäller sedan den 15 januari 2026. Den exakta omfattningen beror bland annat på sektor och verksamhetens storlek. NCSC:s vägledning beskriver vilka verksamheter som berörs och kraven på bland annat riskhantering och incidentrapportering.[2]
En AI-lösning blir del av organisationens informations- och systemlandskap. Relevanta frågor är därför:
Ingår lösningen i en samhällsviktig eller kritisk process?
Vilka leverantörs- och molnberoenden finns?
Hur hanteras identitet, sårbarheter, kontinuitet och backup?
Kan incidenter upptäckas, bedömas och rapporteras i tid?
Är ledningens ansvar och uppföljning tydliga?
ENISA:s tekniska vägledning kan användas för att omsätta NIS2-krav till kontroller, men organisationen behöver anpassa dem till sin riskbild.[5]
DORA för finansiella verksamheter
DORA började tillämpas den 17 januari 2025 och gäller de finansiella entiteter som omfattas av förordningen. Fokus ligger på styrning av IKT-risk, incidenthantering, tester, informationsdelning och tredjepartsrisk.[3]
För en AI-lösning behöver en finansiell verksamhet bedöma om den stödjer en kritisk eller viktig funktion, vilka IKT-tredjeparter som ingår och hur kontinuitet och exit kan säkerställas. En modell-API-leverantör kan vara en del av en längre kedja tillsammans med plattform, moln och loggtjänster.
Avtal behöver ge tillräcklig information, åtkomst, säkerhetskrav och stöd för incidenter och avslut. DORA är inte ett AI-regelverk, men AI-tjänster som används i verksamheten omfattas av organisationens IKT-riskhantering.
GDPR gäller när personuppgifter behandlas
Om promptar, dokument, loggar eller utdata innehåller personuppgifter gäller GDPR. Organisationen behöver definiera ändamål och rättslig grund, minimera data, säkerställa transparens och hantera rättigheter.
Automatiserade beslut med rättsliga eller liknande betydande effekter kan aktualisera särskilda regler. En DPIA kan krävas när behandlingen sannolikt leder till hög risk. IMY:s vägledning betonar att dataskydd ska integreras i hela livscykeln.[4]
GDPR-bedömningen är separat från AI-förordningens riskklassning. Ett system kan vara låg risk enligt AI Act men ändå behandla känsliga personuppgifter.
Vilka krav bör ställas på plattform och leverantör?
Dokumenterat dataflöde, regioner, retention och underleverantörer.
Federerad identitet, minsta behörighet och separerade administratörsroller.
Loggning och spårbarhet som stödjer revision utan onödig persondata.
Versionshantering för modell, prompt, datakällor och agentverktyg.
Testning av kvalitet, robusthet, cybersäkerhet och rätt avslag.
Rutiner för incidenthantering med kontaktvägar, tidslinje och kundinformation.
Kontinuitets-, backup- och exitplan.
Dokumentation av ansvar mellan kund, plattform och modellleverantör.
Begär bevis i arkitektur, avtal och process. Certifieringar kan vara relevanta men ersätter inte bedömningen av den faktiska lösningen.
Dokumentation och ansvar
Skapa ett register över användningsfall med ändamål, ägare, data, modell, användare, riskbedömning och beslut. Dokumentera ändringar och testresultat. För högriskssystem kan mer omfattande dokumentation krävas.
Ledningen ska förstå risk och ansvar. Verksamheten äger användningen, IT äger systemlandskapet, informationsägare ansvarar för data och säkerhet/juridik ger krav och kontroll. Leverantören ansvarar för sina avtalade delar.
När behövs juridisk bedömning?
Involvera juridisk expertis och dataskyddskompetens när lösningen påverkar individer, behandlar känsliga personuppgifter, används inom en reglerad sektor eller kan omfattas av reglerna för AI-system med hög risk.
Gör bedömningen före pilot med verkliga data, inte efter utvecklingen.
Kontrollfrågor:
Vilka lagar och sektorsregler gäller för organisationen och processen?
Vilken roll har vi enligt AI Act?
Kan systemet vara högrisk eller omfattas av transparenskrav?
Behandlas personuppgifter och krävs DPIA?
Omfattas verksamheten av cybersäkerhetslagen eller DORA?
Vilka tredjeparts- och överföringsrisker finns?
Vem fattar beslut om godkännande och förändring?
Källor
Europeiska kommissionen, AI Act:
https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-aiNationellt cybersäkerhetscenter, Det här är cybersäkerhetslagen:
https://www.ncsc.se/sv/radgivning-och-stod/cybersakerhetslagen-nis2/det-har-ar-cybersakerhetslagen/Europeiska kommissionen, Cyber resilience – DORA:
https://finance.ec.europa.eu/digital-finance/cyber-resilience_enIMY, Vägledning om GDPR och AI:
https://www.imy.se/verksamhet/dataskydd/innovationsportalen/vagledning-om-gdpr-och-ai/ENISA, NIS2 Technical Implementation Guidance:
https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance


