Vad är ett AI-systemregister?

Ett AI-systemregister är en strukturerad lista över alla AI-system som en organisation använder eller utvecklar. AI-förordningen kräver inte ordet register explicit, men praktiken kräver det.

Art. 26 förutsätter ett Art. 26-paket per system, vilket bara går att producera om systemen är listade. Art. 4 kräver kompetensmatris per roll och system. Art. 27 kräver FRIA per högrisk-system. Art. 16 kräver loggning vid GPAI-användning. Allt detta hänger på att registret existerar och uppdateras kontinuerligt.

Vilka fält ska ett AI-register innehålla?

Det finns ingen formell minimi-fältlista i AI-förordningen, men kombinationen av Art. 4, 26 och 27 ger en praktisk lägstanivå. Tabellen visar de fält som ett register behöver för att producera Art. 26-paketet utan ytterligare datainsamling.

FältSyfteLagstöd
System-ID och namnUnik referens i loggar och rapporterPraktisk grund
Provider och versionSpårbarhet vid uppdateringar och incidenterArt. 16, Art. 26
Syfte och användningsområdeKlassificering enligt Bilaga IIIArt. 6
RisknivåAvgör vilka skyldigheter som gällerArt. 6, Art. 6.3
FRIA-statusKrävs för högrisk per Bilaga III i offentlig och kreditsektorArt. 27
Ansvarig systemägareInternt accountability vid tillsynArt. 26.6
AI-kompetenskrav per rollKopplar systemet till Art. 4-matrisenArt. 4
GDPR DPIA-kopplingParallell rättslig analys där personuppgifter behandlasGDPR Art. 35
Drift-statusAktiv, pausad, avveckladArt. 26.1
Senast granskad datumStöd för kontinuerlig övervakningArt. 26.5

Skillnaden mellan provider-register och deployer-register

AI-förordningen skiljer mellan två typer av register som ofta blandas ihop. Provider-registret är offentligt och centralt på EU-nivå. Deployer-registret är internt och företagsspecifikt.

  • Provider-registret enligt Art. 71 är EU:s offentliga databas över högrisk-AI-system. Providers (de som släpper ut AI-system på marknaden) är skyldiga att registrera sina högrisksystem där innan de tas i drift.
  • Deployer-registret är internt. Det krävs inte explicit men är nödvändigt för att uppfylla Art. 4, 26 och 27. Innehåller alla AI-system som bolaget använder, inklusive sådana som inte är högrisk.
  • Svenska bolag är typiskt deployers för det mesta de använder (Microsoft Copilot, ChatGPT Enterprise, AI i HR-system) men kan vara providers för egenutvecklade modeller. Dubbla register kan behövas.

Vilka AI-system ska ingå?

AI-förordningens definition av AI-system i Art. 3.1 är bred. Den omfattar maskinbaserade system som kan generera output (innehåll, beslut, rekommendationer eller förutsägelser) som påverkar fysiska eller virtuella miljöer, med varierande grad av autonomi. Många system som inte historiskt kallats AI faller in.

  • SaaS-AI-funktioner. Microsoft Copilot, Google Gemini i Workspace, ChatGPT Enterprise, Salesforce Einstein, Notion AI. Räknas som separata AI-system per funktion.
  • Embedded AI i HR-system. Rekryteringsverktyg som filtrerar CV, performance review-verktyg som scorar prestation, lönesättningsverktyg.
  • Egenutvecklade modeller. Interna LLM-installationer, ML-pipelines för bedrägeridetektion, prediktiva modeller för churn eller kreditbedömning.
  • Branschspecifika AI-verktyg. AI-stöd i diagnostik (vård), kreditbedömningsmodeller (bank), AI-baserad övervakning (säkerhet).
  • Shadow AI. Den mest underskattade kategorin. Verktyg som anställda använder utan central upphandling.

Hur upptäcker ni shadow AI?

Shadow AI är AI-system som används utan central upphandling eller dokumentation. För registreringen är detta den största risken eftersom dessa system per definition inte syns i normala IT-inventarier. Tre vanliga gömställen är värda att leta i på första passet.

  • SaaS med inbäddade AI-features. Verktyg som teamet redan har men där en AI-funktion aktiverats: Slack AI, Atlassian Intelligence, Hubspot AI, smart-summarize i e-postklienter.
  • Browser-tillägg och desktop-appar. ChatGPT-tillägg, Grammarly, Otter, transkriberings-appar och AI-baserade research-verktyg.
  • API-anrop till externa LLM:er i kodbasen. Sök efter OPENAI_API_KEY, ANTHROPIC_API_KEY, AZURE_OPENAI_KEY i repositories och CI-secrets.

Tre vanligaste registerfelen

Felen är samma oavsett bransch och upptäcks typiskt först när tillsynen frågar eller när FRIA ska produceras. Alla tre går att förebygga med tydlig ägarstruktur och automation.

  • Excel-blad utan ägarskap. Fungerar tillfälligt men stelnar inom månader. Ingen vet vem som ansvarar för uppdatering, och kopplingen till FRIA, kompetensmatris och leverantörsbedömning bryts.
  • Missar SaaS-AI. Bolag fokuserar på egenutvecklade modeller men glömmer att Microsoft Copilot, ChatGPT Enterprise och liknande är AI-system enligt definitionen i Art. 3.1.
  • Inget revisionsdatum per system. Kontinuerlig övervakning enligt Art. 26.5 går inte att visa när det inte finns datum för senaste granskning per system.

Så hjälper CyberKlar AI-systemregister-modulen

Plattformens AI-systemregister-modul (M1) är basen för alla andra AI Act-funktioner i CyberKlar. Modulen hanterar upptäckt, klassificering och löpande dokumentation utan att kräva manuell synkronisering mellan flera verktyg.

  • Automatisk upptäckt av shadow AI via integration mot SaaS-katalog och OAuth-loggar.
  • Klassificeringsguide enligt Art. 6 och Bilaga III, med audit-trail på varje beslut.
  • Direkt koppling till FRIA-modulen för högrisk-system enligt Art. 27.
  • Kompetensmatris per system och roll genereras automatiskt från Art. 4-modulen.
  • Art. 26-paket plockas fram per system vid tillsynsfråga, exporterbar som PDF.
  • Tio års arkivering enligt Art. 18 ingår.

Koppling till NIS2 leverantörskedja

AI-förordningen och NIS2 (Cybersäkerhetslagen, SFS 2025:1506) överlappar i leverantörsbedömningen. NIS2 Art. 21(2)(d) kräver att väsentliga och viktiga entiteter bedömer leverantörskedjans cybersäkerhet, inklusive AI-leverantörer. AI-förordningens Art. 26.4 kräver i sin tur att deployers verifierar att providern uppfyller sina skyldigheter.

För bolag som omfattas av båda regelverken (vilket de flesta NIS2-entiteter med AI-användning gör) bör AI-systemregistret kopplas direkt till NIS2-leverantörsbedömningen så att samma analys täcker båda kraven.