VEM HAR FORTFARANDE ÅTKOMST TILL AI-VERKTYGET? GÖR BEHÖRIGHETSGRANSKNINGEN RAD FÖR RAD
AI-tjänsten infördes med rätt användare, men listan har vuxit genom rollbyten, projektgäster, konsulter, testkonton och tillfälliga administratörer. Nu behöver varje rad jämföras med ett aktuellt arbetsbehov och en ansvarig person. Här får ni ett arbetssätt som slutar i fyra tydliga beslut: behåll, sänk, ta bort eller tidsbegränsa.
Vem står bakom innehållet?
Den här texten är redaktionellt framtagen av AI på svenska för systemägare, IT-ansvariga, dataskyddsombud och chefer som behöver granska åtkomsten till en aktiv AI-tjänst. Den bygger på Integritetsskyddsmyndighetens vägledning om behörighetsstyrning (öppnas i ny flik) och kompletterande IMY-vägledning om säkerhetsåtgärder och obehörig åtkomst. Samtliga källor öppnades och kontrollerades 2026-08-24. Texten ger en arbetsmodell, inte ett besked om en viss behörighet är laglig eller om en viss händelse ska incidentanmälas.
Teknisk behörighet är inte samma sak som befogenhet
En användare kan tekniskt komma åt en AI-tjänst utan att längre ha ett arbetsuppdrag som motiverar åtkomsten. IMY skiljer därför mellan behörighet – vilka uppgifter och funktioner användaren tekniskt kan nå – och befogenhet – om, hur och när personen faktiskt får behandla uppgifterna. När den tekniska behörigheten är vidare än den egentliga befogenheten kan åtkomsten bli obehörig även om inloggningen fungerar precis som den ska.
Det gör granskningen till mer än licensstädning. Frågan är inte bara ”används kontot?” utan ”vilken arbetsuppgift kräver just den här rollen, vilka data kan personen möta och vem bekräftar behovet i dag?”. En konsult som loggade in i går kan sakna ett pågående uppdrag. En medarbetare som inte loggat in på tre månader kan ha en sällanaktiverad men legitim beredskapsuppgift. Båda raderna behöver ett beslut.
Det här är också gränsen mot två närliggande processer. När en viss person slutar behöver ni följa en händelsestyrd offboarding för personens AI-konton och innehåll. När hela tjänsten ska stängas behöver ni i stället avveckla verktyget, exportera det som ska bevaras och avsluta åtkomsten. Den återkommande granskningen här gäller alla som fortfarande står kvar i en tjänst som ska fortsätta användas.
Bygg en granskningslista som går att fatta beslut från
Börja med en export från AI-tjänstens administrationsvy. Ta med aktiva och avstängda användare, väntande inbjudningar, gäster, grupper, tjänste- och testkonton samt samtliga administrativa roller. Komplettera sedan exporten med uppgifter från er identitetskälla, HR eller konsultregister. Leverantörens lista visar vad tjänsten känner till; den visar sällan aktuell chef, uppdragsslut eller varför en roll behövs.
En användbar granskningsrad innehåller minst följande fält:
- Identitet och kontotyp: person, gäst, konsult, tjänstekonto, testkonto eller reservkonto.
- Nuvarande teknisk roll: vanlig användare, gruppansvarig, faktureringsadministratör, innehållsadministratör eller full administratör. Använd leverantörens exakta rollnamn men skriv en kort svensk förklaring.
- Arbetsbehov och omfattning: konkret arbetsmoment, vilken data eller funktion som behövs och om behovet är löpande eller tillfälligt.
- Ansvarig: chef för en anställd, uppdragsägare för en konsult och systemägare för tekniska konton.
- Signaler: senaste inloggning, skapandedatum, inbjudningsstatus, grupptillhörighet och senaste rolländring.
- Beslut och bevis: behåll, sänk, ta bort eller tidsbegränsa; beslutsdatum, beslutsfattare, skäl och planerat genomförandedatum.
Exportera så nära granskningstillfället som möjligt och skriv klockslag och tidszon i underlaget. En lista som hämtades för två veckor sedan kan redan vara fel efter nyanställningar och rollbyten. Spara även tjänstens organisations- eller tenant-id. Det förebygger den förvånansvärt vanliga missen att rätt lista granskas i fel test- eller produktionsmiljö.
Ställ fem frågor och landa i ett av fyra beslut
Gå igenom varje rad tillsammans med den som kan bekräfta arbetsbehovet. Massgodkänn inte en hel avdelning: två personer med samma befattning kan ha olika uppdrag, och gruppmedlemskap kan ge mer åtkomst än rollnamnet antyder.
- Är identiteten fortfarande giltig? Kontrollera att personen eller kontot finns, att konsultuppdraget pågår och att en väntande inbjudan fortfarande ska användas.
- Finns ett konkret arbetsbehov nu? ”Bra att ha” och ”kan behövas senare” är inte ett avgränsat behov. Beskriv arbetsmomentet i en mening.
- Är rollen den minsta som räcker? Jämför inte bara ”åtkomst eller ingen åtkomst”. En vanlig användarroll kan ersätta administratör, och en avgränsad grupp kan ersätta åtkomst till hela arbetsytan.
- Vem tar ansvar för behovet? En rad utan chef, uppdragsägare eller systemägare är en okänd risk, inte ett automatiskt godkännande.
- När ska beslutet prövas igen? Sätt nästa ordinarie kontroll eller ett tidigare slutdatum för tillfälliga behov.
Översätt svaren till ett av fyra utfall:
- Behåll när identitet, arbetsbehov, ansvarig och teknisk roll stämmer.
- Sänk när arbetsbehovet finns men nuvarande roll eller gruppmedlemskap ger mer än vad uppgiften kräver.
- Ta bort när identiteten, uppdraget eller arbetsbehovet inte längre är giltigt.
- Tidsbegränsa när en vidare åtkomst behövs under en bestämd period och har en namngiven ägare och ett slutdatum.
Exempel: ”Anna – workspace admin – marknadschef” är inget beslutsunderlag. ”Anna behöver skapa projekt för marknadsgruppen men ska inte hantera identitetskoppling eller säkerhetsinställningar” visar däremot att arbetsbehovet finns men att full administratör sannolikt är för vid. Beslutet blir att sänka till den roll som bara kan hantera gruppens arbetsyta och kontrollera resultatet efter ändringen.
Granska administratörerna som en egen kö
Administratörsrättigheter ska inte döljas bland hundratals vanliga användare. IMY lyfter uttryckligen att privilegierade åtkomsträttigheter ska begränsas och kontrolleras. Gör därför en separat lista över fulla administratörer, grupp- och innehållsadministratörer, faktureringsroller, integrationsägare och konton som kan exportera historik eller ändra säkerhetsinställningar.
För varje sådan rad: skriv vilka administrativa åtgärder som behöver kunna utföras, hur ofta, i vilken miljö och vem som granskar användningen. Om en person administrerar tjänsten men också använder den i vardagen kan två separata konton eller en tidsstyrd upphöjning minska risken för att privilegier används av misstag. Om leverantören inte stöder det, dokumentera begränsningen och vilka kompenserande kontroller ni använder.
Reserv- eller nödkonton kräver särskild disciplin. De kan vara nödvändiga när den vanliga identitetskopplingen ligger nere, men ”ska aldrig användas” är inget försvar för ett okontrollerat konto. Utse ägare, skydda inloggningsuppgifterna, aktivera stark autentisering där det går, logga användning och testa återställningen utan att lämna kontot permanent öppet för vardagsbruk.
Senaste inloggning hjälper, men bevisar inte behovet
Sortera gärna listan på senaste inloggning för att hitta uppenbara kandidater, men låt inte ett tal fatta beslutet. Aktivitet kan komma från en integration eller en kvarvarande session. Ett sällananvänt konto kan höra till incidentberedskap. En inbjudan som aldrig accepterats kan ändå ligga öppen till en privat adress. Signalen berättar vad ni ska fråga om, inte vad svaret måste bli.
Fyra rader förtjänar omedelbar manuell kontroll:
- Okänd ansvarig: pausa en eskalerad roll och utred vem som äger den; godkänn inte genom tystnad.
- Privat eller extern e-postdomän: verifiera avtal, uppdrag och slutdatum samt om gästen kan bjudas in genom en styrd identitet i stället.
- Dubbletter: kontrollera vilket konto som innehåller material eller äger integrationer innan något tas bort.
- Tjänste- och testkonton: kräv systemägare, dokumenterat syfte och en metod för autentisering som inte är knuten till en tidigare medarbetare.
Kontrollera också grupparv och identitetskoppling. En roll kan se begränsad ut i AI-tjänsten men återtilldelas automatiskt från en kataloggrupp efter att ni sänkt den manuellt. Åtgärden måste då göras i den auktoritativa källan, annars återkommer behörigheten vid nästa synkronisering.
Ändra i en kontrollerad kö och verifiera efteråt
Gör beslutslistan färdig innan ni börjar klicka. Sortera sedan åtgärderna efter risk och beroenden. Säkerställ först att minst en kontrollerad administratör finns kvar och att integrationsägare kan flyttas. Sänk eller ta bort därefter omotiverade privilegier, avsluta externa och inaktuella konton och hantera vanliga användare. För ett konto som äger arbetsytor, botar eller gemensamma instruktioner kan ägarskapet behöva överföras före avstängning.
En borttagen licens är inte alltid samma sak som avslutad åtkomst. Kontrollera vad tjänsten gör med aktiva webbsessioner, API-nycklar, gruppmedlemskap och inbjudningslänkar. Verifiera resultatet från en ny export eller administrationsvy och notera genomförandedatum, vem som gjorde ändringen och eventuella fel. Om en ändring misslyckas ska raden vara öppen – inte markerad som klar för att beslutet var fattat.
Dokumentationen behöver inte vara ett tungt protokoll. En granskningsfil med källexportens tidpunkt, ansvariga, beslut, skäl, utförandestatus och nästa kontroll räcker långt. Begränsa åtkomsten även till själva filen: den kan avslöja konton, roller, konsulter och säkerhetsupplägg som inte ska spridas brett.
Sätt nästa kontroll efter risk – inte efter en påhittad lagregel
IMY skriver att behörigheter ska följas upp regelbundet men anger ingen generell frekvens för alla verksamheter eller tjänster. Intervallet behöver därför motiveras av er riskbedömning. Fler användare, känsligare eller mer omfattande personuppgifter, många externa gäster, snabb personalomsättning och vida administratörsfunktioner talar för tätare kontroll. En liten, stabil grupp med begränsad data kan kontrolleras mer sällan.
Som intern startpunkt, inte som lagkrav, kan ni överväga månatlig kontroll av fulla administratörer och öppna undantag, kvartalsvis kontroll av en tjänst med känsligt innehåll eller många externa användare och halvårsvis kontroll av en stabil tjänst med lägre risk. Dokumentera varför intervallet valdes och justera det när utfallet visar många felaktiga rader.
Vänta inte på kalendern efter en större förändring. Gör en extra granskning när tjänsten får nya roller eller datakällor, när identitetskopplingen ändras, efter en omorganisation, efter ett större konsultprojekt och när en incident visar att åtkomsten varit vidare än avsett. Kalendern fångar återkomsten; händelserna fångar förändringen.
Avsluta granskningen med nio ja eller ett öppet ärende
- Exporten omfattar användare, gäster, väntande inbjudningar, grupper, tekniska konton och alla administratörsroller.
- Varje identitet har en kontotyp och en verifierad ansvarig.
- Varje kvarvarande åtkomst har ett konkret, aktuellt arbetsbehov.
- Den tekniska rollen är den minsta som räcker för arbetsuppgiften.
- Administratörer och reservkonton har granskats separat.
- Tidsbegränsade undantag har ägare, skäl och slutdatum.
- Ägarskap för arbetsytor och integrationer har flyttats före borttagning där det behövs.
- Genomförda ändringar har verifierats i tjänsten eller i en ny export.
- Nästa kontroll är daterad och motiverad utifrån risken.
Om en punkt inte kan bekräftas, skapa ett öppet ärende med ansvarig och tidsfrist. ”Saknar svar” är ett tillstånd som går att styra. En tom ruta som ändå passerar som godkänd är det inte.
Vanliga frågor om behörighetsgranskning av AI-verktyg
Hur ofta ska behörigheterna granskas?
IMY anger regelbunden uppföljning men ingen generell kalenderfrekvens. Bestäm intervallet efter risk, antal användare, datainnehåll och förändringstakt. Lägg dessutom in extra kontroller efter större förändringar.
Räcker det att chefen godkänner listan?
Nej. Chefen kan bekräfta arbetsbehovet, men systemägaren behöver översätta det till rätt teknisk roll och kontrollera vilka funktioner och data rollen faktiskt öppnar. Administratörsrättigheter bör prövas separat.
Kan vi ta bort alla som inte har loggat in på 90 dagar?
Använd senaste inloggning som en signal, inte som enda regel. Ett nyligen använt konto kan sakna befogenhet, medan ett sällananvänt beredskaps- eller tjänstekonto kan ha ett dokumenterat behov.
Vad gör vi med en tillfällig åtkomst?
Dokumentera ett tidsbegränsat undantag med namngiven ägare, konkret skäl, minsta nödvändiga roll och slutdatum. Bevaka slutdatumet så att undantaget omprövas eller tas bort.
Källor och vidare läsning
- IMY: Behörighetsstyrning (öppnas i ny flik) – behovs- och riskanalys, privilegierade rättigheter, rutiner, regelbunden uppföljning och dokumentation av förändringar.
- IMY: Säkerhetsåtgärder (öppnas i ny flik) – riskbaserad säkerhetsnivå samt tekniska och organisatoriska kontroller.
- IMY: Vad innebär obehörig åtkomst? (öppnas i ny flik) – skillnaden mellan teknisk behörighet och faktisk befogenhet.