Blogg | Knowit

Effektiv regelefterlevnad – om sambanden mellan regelverk för produktutvecklande bolag

Skriven av Nora Kajo och Simon Jonasson | Oct 30, 2025 10:50:22 AM

I takt med att fler regelverk träder i kraft i syfte att hantera riskerna med den digitala transformation som vi är mitt uppe i, ställs en mängd krav på utvecklare av produkter med digitala element. Bland dessa regelverk hittar vi AI-förordningen (AI Act) och Cyber Resilience Act (CRA). Trots att regelverken har olika tillämpningsområden, finns det gemensamma nämnare i de krav de ställer. För att möta dessa krav på ett effektivt sätt krävs en samordnad strategi. Genom att förstå sambanden mellan de olika regelverken minskar komplexiteten och det blir lättare att förena regelefterlevnad och innovation.

I detta blogginlägg reder vi ut några av sambanden mellan AI-förordningen och CRA och hjälper dig att ta de första stegen mot en mer effektiv hantering av de krav som ställs på dig som både är leverantör av AI-system och tillverkare av produkter med digitala element.

Krav från AI-förordningen

Många har nog hört talas om AI-förordningen, vi har i tidigare blogginlägg skrivit om förordningen som du kan läsa här. AI-förordningen är ett riskbaserat regelverk, vilket innebär att det ställer olika krav beroende på vilken riskklass ett AI-system faller inom. Det finns fyra olika riskklasser och för att avgöra vilka krav som ställs på just ditt AI-system krävs en riskklassificering. I detta inlägg kommer vi inte gå närmare in på hur en sådan klassificering genomförs, men vi kan konstatera att flest krav åläggs leverantörer av AI-system som klassas som hög risk.

Kraven på AI-system med hög risk varierar. Det finns både organisatoriska och mer teknikfokuserade krav. Nedan följer ett urval av de krav som ställs på leverantörer av AI-system som klassas som hög risk:

  • Riskhantering: Etablera ett riskhanteringssystem för att identifiera, analysera och minska risker med AI-systemet under hela systemets livscykel. (Art. 9 AI-förordningen)
  • Teknisk dokumentation: Upprätta utförlig dokumentation om bland annat systemets konstruktion, syfte, begränsningar. (Art. 11 AI-förordningen)
  • Loggning: Systemet ska logga relevanta händelser för att göra det möjligt att spåra systemets funktion, identifiera risker, ändringar och avvikelser. (Art.12 AI-förordningen)
  • Transparens och användarinformation: Utveckling av AI-system behöver utföras på ett sätt som gör dess funktion tillräckligt transparent. Du behöver också upprätta tydliga instruktioner till användare av systemet. (Art. 13 AI-förordningen)
  • Riktighet, robusthet och cybersäkerhet: I utvecklingsfasen krävs att man säkerställer att AI-systemet utvecklas på ett sätt som uppnår en lämplig nivå av riktighet, robusthet och cybersäkerhet. Det ska finnas skydd mot fel, manipulation och attacker. (Art. 15 AI-förordningen)

Krav som dessa är viktiga för högrisksystem, men beroende på sammanhanget som systemet implementeras i kan helt nya krav tillkomma för leverantören att hålla koll på.

Ett sårbart AI-system, ett föremål för annan lagstiftning?

Förutom AI-förordningen finns det en mängd andra regelverk som påverkar produkter utifrån ett riskperspektiv. Ett exempel på detta är Cyber Resilience Act. CRA är ny lagstiftning som ställer krav på tillverkare, importörer och distributörer av produkter som innehåller så kallade digitala element, som släpps ut på den europeiska marknaden. Kortfattat påverkar regelverket inte bara produktens design och tillverkning, utan ställer även krav på att produkten ska vara säker under hela dess livslängd.

Många delar i CRA överlappar med de krav som följer av AI-förordningen. I stället för att tänka att var lagstiftning har sitt eget utvecklingsspår är det fördelaktigt att kartlägga hur de överlappar varandra och skapa en gemensam process för att kunna hantera båda. Syftet med CRA är att se till att tillverkare har rätt processer för att kunna utveckla säkra produkter, och genom dessa se till att sårbarheter inte introduceras i produkten under hela produktens livscykel. Detta perspektiv återfinns även i AI-förordningen. Eftersom ett AI-system som klassas som hög risk enligt AI-förordningen också kan omfattas av CRA är det viktigt att förstå sambanden mellan de två regelverken.

Nedan ger vi konkreta exempel där överlapp kan identifieras, och där en gemensam process kan vara fördelaktig:

AI-förordningen Cyber Resilience Act  Tips
Riskhantering: Etablera riskhanteringssystem för att identifiera, analysera och minska risker (art 9) Riskanalysmetod: Produkter med digitala element ska utformas, utveckas och produceras på ett sådant sätt att de säkerställer en lämplig cybersäkerhetsnivå baserat på riskerna (bil I).  Skapa en gemensam process för riskhantering och utforma en riskanalysmetodik som täcker in flera olika slags produktrisker. 
Teknisk dokumentation: Utförlig dokumentation om systemets konstruktion, syfte, begränsningar m.m. (art 11). Information till användaren: Produkten ska åtföljas av dokumentation om det avsedda syftet, begränsningar i användningen m.m. (bil II). Skapa en process för gemensam produktdokumentation för användaren som täcker kraven i båda regleringarna.
Loggning: System ska logga relevanta händelser under användning (art 12).  Loggning: Produkten ska kunna registgrera relevant intern verksamhet relaterat till obehörig tillgång eller ändring av data m.m. (bil I). Skapa en process som låter er designa loggnings-funktionalitet för att kunna registrera olika typer av händelser som uppfyller kraven i båda regleringarna. 
Transparens och användarinformation: Beskriv hur systemet fungerar och ge tydliga instruktioner till användare (art 13).  Information till användaren: Produkten ska åtföljas av dokumentation om produktens väsentliga funktioner, rimligen felaktig användning som kan leda till betydande cybersäkerhetsrisker (bil II).  Skapa en gemensam process för produktdokumentation åt användaren som täcker kraven i båda regleringarna. 
Robusthet och säkerhet: Skydd mot fel, manipulation och attacker (art 15).  Produkter ska säkerställa skydd mot obehörig åtkomst genom lämpliga kontrollmekanismer som till exempel innefattar system för autentisering och rapporter om obehörig åtkomst (bil I).  Skapa en process för att kunna designa produkter som innefattar skydd mot oavsiktlig obehörig påverkan. 


"One process to rule them all”

När vi nu har etablerat att det finns flera överlappande krav mellan regelverken blir nästa fråga – var ska man börja någonstans? Vi förstår att gemensamma processer mellan regelverken måste skapas. För att effektivt kunna göra det måste vi arbeta systematiskt med att analysera alla krav i förhållande till nuvarande processer, dokumentera gapen och sedan täppa igen dem med nya processaktiviteter. Inom säker produktutveckling brukar begreppet Secure Development Lifecycle (SDLC) användas. SDLC tillämpas för att säkerställa att en produkt är designad, byggd, testad och säker, inte bara när produkten säljs på den europeiska marknaden utan, under hela produktens livslängd. En SDLC-process kan bli ett kraftfullt verktyg även för kraven i AI-förordningen och CRA.

Avslutning

Sammanfattningsvis kan vi konstatera att nyckeln till ett mer effektivt regelefterlevnadsarbete blir förmågan att identifiera och samordna likheter mellan dessa regelverk. Knowit har tidigare arbetat med både klassning av AI-system enligt AI-förordningen och hjälpt produktutvecklande bolag i sin regelefterlevnad i enlighet med lagkrav från EU. Hör gärna av dig till oss så berättar vi mer!