AI och molntjänster utreds mot offentlighetsprincipen – kartlägg informationsflödet nu
Regeringen utreder hur offentlighetsprincipen ska tillämpas när myndigheter använder AI och externa molntjänster. Det ger inget färdigt rättssvar. Men du kan redan nu kartlägga ett konkret informationsflöde, utse ägare och visa exakt var de öppna frågorna finns.
Det här ska utredningen analysera
Regeringens pressmeddelande den 3 september 2026 (öppnas i ny flik) beskriver ett uppdrag att analysera offentlighetsprincipens tillämpning när myndigheter använder AI och externa molntjänster. Regeringen pekar på att information kan hanteras, lagras och genereras på sätt som bland annat kan innebära att den passerar myndighetsgränsen. Formuleringen är en möjlighet, inte ett besked om att varje AI-tjänst eller varje uppgift lämnar myndigheten.
Kommittédirektiv 2026:116 (öppnas i ny flik) anger två centrala delar: utredaren ska beskriva hur berörda aktörer använder AI, inklusive verktyg i externa molntjänster, och analysera i vilken utsträckning upptagningar som genereras eller lagras genom verktygen utgör allmänna handlingar. Uppdraget ska redovisas senast den 15 november 2027. Lisa Englund Krafft är utsedd till särskild utredare.
Detta är alltså början på en analys, inte ny lag eller ett avgörande för din myndighets verktyg. Artikeln ger en arbetsmodell för nuläget och är inte juridisk rådgivning. Frågor om allmän handling, sekretess, registrering, bevarande och gallring behöver bedömas av behöriga funktioner i det konkreta fallet.
Välj ett användningsfall, inte hela molnmiljön
Börja med en avgränsad arbetsuppgift. Exemplet här är en handläggare som använder en godkänd extern AI-tjänst för att ta fram ett utkast till svar på en påhittad fråga om kommunens öppettider och blanketter. Underlaget består av tre publicerade webbsidor och en internt beslutad rutin utan personuppgifter. Utkastet granskas av handläggaren innan något svar skickas.
Avgränsningen är viktig. ”Vi använder AI i kundservice” säger inte vilken information som kommer in, vad modellen får som kontext, vilken utdata som sparas eller var loggarna finns. Ge användningsfallet ett ID, exempelvis KS-AI-07, och ange start och slut: från att handläggaren klistrar in frågan tills det slutliga svaret och eventuellt underlag har förts till rätt verksamhetssystem.
Använd syntetiskt material när du provar kartan. Kartläggningen ska visa var verkligt innehåll senare kan förekomma; den ska inte bli ett skäl att lägga skyddade uppgifter i en tjänst som ännu inte är godkänd. För bestående regler om tillåten användning, roller och stoppunkter kan du koppla användningsfallet till myndighetens AI-policy.
Gör informationsflödeskartan i nio delar
Samla verksamhetsansvarig, systemägare, registrator, arkivfunktion, informationssäkerhet och juridik runt samma tabell. Fyll först i observerbara fakta: systemnamn, inställningar, avtalsbilagor, exportvägar och verkliga arbetssteg. Skriv därefter de rättsfrågor som behöver avgöras. Blanda inte ihop de två kolumnerna.
| Del | Faktiskt flöde att dokumentera | Öppen fråga och ägare |
|---|---|---|
| 1. Indata | Påhittad invånarfråga samt tre publicerade webbadresser. Ange exakt vad som klistras in eller hämtas automatiskt. | Vilka uppgiftstyper får användas? Verksamhetsägare och informationssäkerhet. |
| 2. Prompt | Instruktionen, dess version och vem som kan ändra den. Spara exempelprompten utanför chattfältet. | Är prompten själv en del av dokumentationen som ska hanteras? Juridik och registrator. |
| 3. Kontext | Webbsidor, uppladdade filer, sökindex, systeminstruktion och eventuell tidigare chatthistorik. | Vilket material görs tekniskt tillgängligt för tjänsten? Systemägare och informationsägare. |
| 4. Utdata | AI-utkast, källhänvisningar och handläggarens ändringar fram till skickat svar. | Vilka versioner behöver finnas kvar och när kan en upptagning vara allmän handling? Juridik, registrator och arkivfunktion. |
| 5. Loggar | Händelseloggar, användar-ID, tidsstämpel, promptlogg, säkerhetslogg och administratörens exportmöjlighet. | Vilka loggar finns faktiskt, vem kommer åt dem och hur ska de bedömas? Systemägare och juridik. |
| 6. Lagringsplats | Region eller plats för chatt, filer, loggar, säkerhetskopior och leverantörens underbiträden enligt verifierat underlag. | Var sker behandling och lagring för just avtalet och inställningen? Avtalsägare och informationssäkerhet. |
| 7. Systemägare | Namnge ansvarig funktion, tjänsteadministratör, avtalsägare och ersättare. Skriv beslutsreferens för godkännandet. | Vem kan stoppa åtkomst, göra export och svara på en begäran? Förvaltningsledning. |
| 8. Diarieföringspunkt | Ange den konkreta händelse där underlag eller svar förs till ärende- eller verksamhetssystem, samt vem som gör det. | Vad ska registreras och vid vilken tidpunkt i detta fall? Registrator och juridik. |
| 9. Arkivflöde | Följ materialet från AI-tjänsten till verksamhetssystem, arkivredovisning, bevarande eller beslutad gallring. | Vilket beslut styr bevarande och gallring för varje informationsmängd? Arkivfunktion och juridik. |
Fältet lagringsplats får inte fyllas med en leverantörs allmänna marknadsföring. Ange dokumentnamn, avtalsversion, inställning och kontrolldatum. Om uppgiften inte går att verifiera skriver du ”inte verifierat” och utser den som ska hämta underlaget.
Rita också övergångarna mellan ytorna
En tabell visar innehållet, men pilarna visar när ansvaret byter hand. Rita minst följande kedja för KS-AI-07: handläggarens webbläsare → AI-tjänstens gränssnitt → modell- och loggmiljö → handläggarens granskning → e-post eller e-tjänst → ärende- eller verksamhetssystem → arkivflöde. Markera varje teknisk kopia och varje manuell överföring.
Sätt en ägare och en kontrollfråga på varje pil. Mellan webbläsare och AI-tjänst: skickas bara den markerade texten eller även bilagor och tidigare samtal? Mellan AI-tjänst och verksamhetssystem: kopieras bara det slutliga svaret eller också prompt, källor och utkast? Mellan verksamhetssystem och arkiv: vilket lokalt beslut styr bevarande eller gallring?
Regeringens beskrivning säger att information bland annat kan passera myndighetsgränsen. Din karta ska visa om och var det sker i detta användningsfall. Det kräver tekniskt och avtalsmässigt underlag; en ruta med ordet ”molnet” räcker inte. Kartan är samtidigt smalare än en full juridisk analys av offentlighet, sekretess och GDPR.
Håll fakta, antaganden och rättsfrågor isär
Märk varje uppgift med en av tre statusar: verifierad, inte verifierad eller fråga för bedömning. ”Administratören kan exportera en händelselogg” kan vara verifierat genom dokumentation och ett lokalt prov. ”Loggen är en allmän handling” är däremot en rättslig slutsats som denna kartläggning inte ska sätta på egen hand.
Undvik också att dra slutsatsen att det som inte syns i användargränssnittet inte finns. En chatt kan försvinna från handläggarens lista samtidigt som andra loggar eller kopior hanteras i andra delar av tjänsten. Omvänt visar en dokumenterad lagringsfunktion inte att varje fält i varje körning sparas. Be systemägaren verifiera den faktiska konfigurationen.
Lägg ett kontrollbevis efter varje verifierad rad: skärmbild från syntetiskt prov, utdrag ur administratörsvy, avtalsbilaga, teknisk dokumentation eller lokalt beslut. Ange datum och vem som gjorde kontrollen. Då går det att se vad som behöver göras om när leverantören ändrar funktioner eller myndigheten byter inställning.
Gör en begäran-övning innan skarp drift
Avsluta nulägeskartan med en bordövning. En person spelar registrator och frågar efter allt material som rör KS-AI-07 under ett bestämt datum. Systemägaren visar vilka exporter som kan göras. Handläggaren visar vad som förts till verksamhetssystemet. Arkivfunktionen följer materialet vidare. Juridiken bedömer frågorna; övningen ska inte automatiskt lämna ut eller undanhålla något.
Protokollet kan ha fem kontrollpunkter: hitta användningsfallet, identifiera system och ägare, ta fram kända informationsmängder, redovisa luckor och skicka varje rättsfråga till behörig bedömare. Sätt ingen generell tidsutfästelse i artikeln. Mät i stället hur lång tid det tog i övningen och vilken åtkomst eller dokumentation som saknades.
Om promptar kan hittas men inte loggar, skriv just det. Om leverantörens export ger chattrubriker men inte källkontext, registrera en separat lucka. Resultatet är inte ett juridiskt facit; det är ett konkret besked om myndigheten kan beskriva sin egen informationshantering och vilka frågor som fortfarande är öppna.
Besluta vad som händer med varje lucka
Ge varje lucka en ansvarig, en åtgärd och ett datum för återkontroll. En okänd lagringsplats går till avtalsägaren. En oklar loggexport går till systemägaren. En oklar diarieföringspunkt går till registrator och juridik. En saknad koppling till arkivredovisningen går till arkivfunktionen. Pausa skarp användning om den ansvariga lokala bedömningen kräver det; den här artikeln bestämmer inte tröskeln.
Versionera kartan när prompt, datakälla, modell, integration, avtal eller lagringsinställning ändras. Behåll det tidigare versionsnumret så att en senare fråga kan kopplas till det flöde som faktiskt gällde vid körningen. Knyt även kartans ägare och nästa granskningsdatum till organisationens AI-register.
Ett användbart slutresultat är kort: ett diagram, tabellen med nio delar, en lista över kontrollbevis och en åtgärdslista. Det viktiga är att varje informationsmängd har en känd väg eller en tydligt namngiven lucka. Då går det kommande utredningsarbetet att möta med ett beskrivet nuläge i stället för antaganden om vad AI-tjänsten gör.
Källor
- Regeringskansliet: Tillämpningen av offentlighetsprincipen analyseras med anledning av ökad användning av AI (öppnas i ny flik) – uppdragets bakgrund, bredare analysfrågor, utsedd utredare och deadline.
- Regeringskansliet: Dir. 2026:116 (öppnas i ny flik) – uppdraget att beskriva AI-användningen och analysera upptagningar som genereras eller lagras.