VILKA AI-VERKTYG ANVÄNDER NI EGENTLIGEN? BYGG ETT AI-REGISTER SOM GÅR ATT FÖRVALTA
En inköpslista visar vilka tjänster organisationen betalar för. Den visar inte vilka AI-funktioner som slagits på i andra system, vilka privata konton som används, vilket arbete som utförs eller vem som ska fatta nästa beslut. Här bygger ni ett register på användningsfallsnivå – med tillräckligt underlag för att godkänna, begränsa, utreda eller avveckla varje rad.
Vem står bakom innehållet?
Den här texten är redaktionellt framtagen av AI på svenska för verksamhetsansvariga, IT, inköp, informationssäkerhet och dataskydd som behöver en gemensam bild av organisationens AI-användning. Metoden tar stöd i NIST AI Risk Management Framework 1.0 (öppnas i ny flik), som bland annat pekar ut inventering, tydliga roller och periodisk granskning. NIST-ramverket är frivilligt; artikelns registerfält är en praktisk arbetsmodell och inte en officiell obligatorisk mall. Källorna öppnades och kontrollerades 2026-08-26.
En produktlista svarar på fel fråga
”Vi har tre AI-verktyg” kan betyda minst fyra olika saker: tre centralt upphandlade tjänster, tre leverantörer som syns på fakturor, tre produkter med generativa funktioner eller tre användningsfall som ledningen känner till. Under ytan kan ett mötesverktyg transkribera samtal, ett kontorspaket skriva sammanfattningar, en kundtjänstplattform föreslå svar och medarbetare använda egna konton för att bearbeta text.
Gör därför användningsfallet till registrets minsta enhet. Produkten är fortfarande ett fält, men raden beskriver arbetet: ”sammanfatta interna projektmöten inför protokoll”, ”föreslå svar på allmänna kundfrågor” eller ”klassificera inkommande supportärenden”. Samma produkt får tre rader om den används till tre ändamål med olika data, användare eller konsekvenser.
Skillnaden blir synlig när något ändras. Om leverantören byter modell påverkas kanske alla rader. Om ekonomiavdelningen börjar ladda upp fakturaunderlag påverkas bara deras användningsfall. Ett produktregister kan bara säga att tjänsten finns; ett användningsfallsregister kan peka ut vilket beslut som måste öppnas igen.
Leta i fem källor och be om arbetsmoment, inte produktnamn
Börja inte med ett tomt kalkylblad som skickas till hela organisationen. Då får ni varianter av samma produktnamn, tomma svar och välkända centrala avtal. Samla först en kandidatlista från fem håll:
- Inköp och ekonomi: avtal, kortköp, appbutiker och återkommande leverantörsbetalningar.
- Identitet och IT: inloggningskopplingar, godkända företagsappar, webbläsartillägg och administrerade mobilappar.
- Systemägare: AI-funktioner som aktiverats i kontorspaket, ärendehantering, CRM, möten och analysverktyg.
- Integrationer: API-nycklar, automatiseringsflöden och kopplingar där AI är en komponent snarare än ett synligt gränssnitt.
- Verksamheten: en kort intervju eller enkät om vilka arbetsmoment som utförs, vilket underlag som används och vart resultatet går.
Fråga ”När använde ni senast AI i ett arbetsmoment, vad matade ni in och vad gjorde ni med resultatet?”. Frågan ”Vilka AI-verktyg använder ni?” ger oftare ett varumärke än ett användningsfall. Be också om ett konkret exempel utan att samla in själva känsliga underlaget i inventeringen.
Registrera osäkra fynd. En fakturarad kan vara ett AI-verktyg eller en annan tjänst från samma leverantör. Skriv då ”kandidat – behöver verifieras”, ange vem som ska kontrollera och sätt ett datum. Ett osäkert fynd är användbart; en gissning som registreras som godkänd användning är det inte.
Tretton fält som gör nästa beslut möjligt
Registret behöver vara tillräckligt detaljerat för att skilja två användningar av samma tjänst, men inte försöka ersätta varje riskanalys och avtal. Använd följande fält per rad:
- Användningsfall: arbetsmomentet i en konkret mening.
- Ändamål och förväntat resultat: varför AI används och vad nyttan ska vara.
- Produkt, funktion och konfiguration: leverantör, tjänst, AI-funktion, modell eller plan när det är känt.
- Verksamhetsägare: personen som kan bekräfta behovet och acceptera verksamhetsbeslutet.
- Teknisk ägare: personen som förvaltar konto, integration, inställningar eller avveckling.
- Användare: avdelning, roll, extern part eller namngiven pilotgrupp – inte bara ”alla”.
- Indata och dataklass: vilka typer av uppgifter som får användas och vilken intern klassning som gäller.
- Utdata och mottagare: vad AI:n producerar, vart resultatet går och om en människa granskar det.
- Integrationer: källsystem, destinationer, webbläsartillägg, API:er och automatiseringar.
- Leverantörsunderlag: avtal, biträdesbilaga, säkerhetsunderlag och dokumenterad konfiguration.
- Beslutsstatus: kandidat, utreds, pilot, godkänd, begränsad, pausad eller avvecklas.
- Bevis: länk till beslut, testprotokoll, skärmbild av inställning eller annat daterat underlag.
- Nästa omprövning: datum, utlösande händelser och vem som öppnar raden igen.
Fältet ”bevis” motverkar ett vanligt problem: statusen säger ”godkänd”, men ingen hittar vad som faktiskt godkändes. Ett beslut om en företagsversion utan träning på kunddata bevisar inte att ett privat gratiskonto eller en ny integration omfattas. Länka till underlaget och skriv vilken konfiguration beslutet gäller.
En rad som går att fylla i
Fånga användningen även när inköpssystemet är tyst
Två kategorier faller lätt bort. Den första är privata eller individuellt betalda konton. Registrera användningsfallet och beslutsbehovet utan att göra medarbetarens lösenord, privata innehåll eller betalningsuppgifter till registerdata. Raden kan exempelvis säga att kommunikationsgruppen provar en privat AI-chatt för utkast, att kontotyp och villkor behöver verifieras och att fortsatt användning är pausad för visst underlag.
Den andra är AI som blivit en funktion i ett system ni redan har. Produktnamnet och avtalet kan vara oförändrade medan transkribering, sammanfattning eller beslutsstöd har slagits på. Skapa en ny användningsfallsrad när funktionen innebär ett nytt arbetsmoment eller dataflöde. Kontrollera funktionen enligt arbetssättet i Testa nya AI-funktioner före utrullning innan statusen ändras från kandidat eller pilot.
Registrera inte upptäckten som ett retroaktivt godkännande. ”Finns i organisationen” och ”får användas för detta ändamål” är två olika uppgifter. Statusfältet ska kunna bära den skillnaden.
AI-registret är en ingång, inte slutprodukten
En komplett registerrad avgör inte automatiskt om användningen är tillåten, säker eller lämplig. Den gör i stället rätt nästa kontroll möjlig. Om raden innehåller personuppgifter behöver den kopplas till dataskyddsarbetet. IMY anger att personuppgiftsansvariga och personuppgiftsbiträden ska föra register över sina behandlingar (öppnas i ny flik), med ett särskilt innehåll enligt artikel 30.
Det operativa AI-registret ersätter alltså inte registerförteckningen enligt artikel 30. Använd gärna samma inventeringsuppgifter som start, men låt dataskyddsspåret äga ändamål, kategorier av registrerade och personuppgifter, mottagare, tredjelandsöverföringar, gallring och säkerhetsåtgärder. Den praktiska ifyllnaden finns i Registerförteckningen enligt artikel 30 när ni infört AI.
AI-förordningens klassning är ett annat spår. EU-kommissionens aktuella tillsynstidslinje visar att bestämmelserna börjar tillämpas stegvis (öppnas i ny flik). En rad i AI-registret avgör därför varken riskklass eller skyldigheter. Använd uppgifterna om ändamål, användare, system och påverkan som underlag och gå vidare till checklistan för EU:s AI-förordning.
När ett verktyg är känt behöver ni också avgöra vem som äger den radvisa åtkomstkontrollen. Själva granskningen av användare, gäster och administratörer hör hemma i behörighetsgranskningen av AI-verktyget, inte i inventeringsregistret.
Ge varje rad två sätt att bli aktuell igen
Ett årligt utskick räcker inte för användningsfall som förändras mitt under perioden. Ge därför varje rad både ett kalenderdatum och händelser som öppnar den tidigare. Datumet gör att tysta och stabila rader ändå granskas. Händelserna fångar ändringar som inte kan vänta.
Öppna raden igen när något av följande ändras: ändamål, tillåten indata, användargrupp, leverantör, modell, abonnemang, lagrings- eller träningsinställning, integration, mottagare, mänsklig kontroll eller ägare. Lägg också in incidenter, återkommande fel och nya klagomål som utlösare. NIST AI RMF beskriver riskhantering som kontinuerlig över AI-systemets livscykel och pekar ut både periodisk granskning och tydligt ansvar; registret gör den principen konkret.
Sätt inte samma frekvens för allt av bekvämlighet. Ett begränsat internt skrivstöd med stabil konfiguration kan få ett längre intervall än ett pilotprojekt som bearbetar nya datatyper varje vecka. Dokumentera varför nästa datum valdes. Då kan intervallet granskas i stället för att bara ärvas.
Avsluta även rader. Status ”avvecklas” behöver en ägare, ett slutdatum och bevis på att åtkomst, integrationer och data har hanterats. Annars blir registret en katalog över historiska ambitioner. För själva avslutet finns en separat exitplan för AI-verktyg.
Fem rader som ska stoppas i egenpasset
- ”Copilot – används av kontoret – godkänd.” Arbetsmoment, data, konfiguration, beslutsomfattning och ägare saknas.
- ”Chatbot – inga personuppgifter.” Påståendet saknar bevis och säger inte vilken indata som faktiskt är tillåten eller förekommer.
- ”Marknad ansvarar.” En avdelning kan inte öppna raden på ett visst datum. Namnge en roll eller person enligt er förvaltningsmodell.
- ”Godkänd tills vidare.” Utan datum eller ändringshändelser blir statusen permanent även när förutsättningarna ändras.
- ”Leverantörens säkerhetssida.” En odaterad länk visar inte vilken inställning eller version ert beslut byggde på. Spara daterat bevis och beslutets omfattning.
Gör dessutom ett dubblettest: sortera på produkt och jämför användningsfallen. Slå inte ihop rader bara för att leverantören är densamma. Slå ihop dem först när ändamål, data, användargrupp, konfiguration, ägare och beslut faktiskt kan förvaltas tillsammans.
En första registerversion på fem arbetsmoment
- Samla kandidater från inköp, identitet, systemägare, integrationer och verksamheten.
- Välj fem verkliga arbetsmoment och skapa en separat rad per användningsfall.
- Fyll i ägare, användare, indata, dataklass, integrationer, status och bevis; markera obesvarade fält öppet.
- Sätt ett nära utredningsdatum för rader utan ägare eller beslut och skilj upptäckt från godkännande.
- Koppla varje rad vidare till den kontroll den behöver: dataskydd, AI Act-klassning, säkerhet, behörighet, inköp eller avveckling.
Målet för första passet är inte ett perfekt register över hela organisationen. Målet är fem rader som går att fatta beslut från och en insamlingsmetod som kan upprepas. När modellen fungerar kan ni utöka den utan att skapa en ny produktlista med fler kolumner men samma blinda fläckar.
Vanliga frågor om AI-register
Ska AI-registret ha en rad per verktyg eller per användningsfall?
Använd en rad per användningsfall och koppla raden till produkt och konfiguration. Samma verktyg kan användas för flera ändamål med olika data, användare, integrationer och beslut.
Ersätter AI-registret registerförteckningen enligt artikel 30?
Nej. AI-registret är ett operativt inventerings- och förvaltningsunderlag. Om användningen innebär personuppgiftsbehandling behöver den också hanteras i organisationens registerförteckning enligt dataskyddsförordningen.
Hur ofta ska AI-registret uppdateras?
Sätt ett konkret omprövningsdatum per rad utifrån förändringstakt och risk. Uppdatera dessutom raden när ändamål, data, leverantör, modell, integration, användargrupp eller beslutsstatus ändras.
Vad gör ni med AI-användning som saknar ägare?
Markera raden som obeslutad, utse vem som ska utreda den och sätt ett nära slutdatum. En upptäckt är inte ett godkännande, och avsaknad av ägare ska inte omvandlas till ett tyst ja.
Källor och vidare läsning
- NIST: AI Risk Management Framework 1.0 – Core (öppnas i ny flik) – frivilligt ramverk som bland annat behandlar inventering av AI-system, tydliga roller, användningskontext och periodisk granskning.
- IMY: Föra register över behandling (öppnas i ny flik) – skyldigheten och innehållet för registerförteckningen enligt artikel 30, som det operativa AI-registret inte ersätter.
- EU-kommissionen: The enforcement framework of the AI Act (öppnas i ny flik) – aktuell beskrivning av den stegvisa tillämpningen och tillsynen enligt AI-förordningen.