Hvad kræver ansvarlig brug af AI i kommunale arbejdsgange?

Når AI flytter ind i kommunale processer, flytter ansvaret ikke ud af rådhuset.

Kommuner kan hente store gevinster med AI: hurtigere sagsoplysning, bedre prioritering af indsatser og mere ensartede afgørelser. Men uden styring og sikkerhed kan gevinsten hurtigt blive ædt op af fejl i afgørelsesgrundlag, brud på GDPR, skævheder i vurderinger eller manglende dokumentation over for borgere, tilsyn og politikere.

I denne artikel får du en praktisk guide til, hvilke styrings- og sikkerhedsmæssige forhold der bør være på plads, når AI bruges i kommunale arbejdsgange. Du får en tidlig definition, konkrete eksempler fra hverdagsprocesser, typiske faldgruber og en handlingsorienteret tjekliste, der kan bruges på tværs af forvaltninger.

Hvad betyder “AI i kommunale processer” egentlig?

AI i kommunale processer dækker over brugen af algoritmer og modeller (fx maskinlæring eller generativ AI) til at understøtte eller automatisere opgaver i sagsbehandling, visitation, drift, planlægning, borgerkommunikation eller intern administration.

Det er vigtigt, fordi AI i praksis påvirker borgerens møde med kommunen: hvilke sager der prioriteres, hvilke oplysninger der fremhæves, og hvordan medarbejdere træffer beslutninger. Selvom AI “kun” er et beslutningsstøtteværktøj, kan det flytte praksis markant, hvis styring, dokumentation og kontrol ikke følger med.

Mini-konklusion: AI handler ikke kun om teknologi, men om forvaltningspraksis, ansvar og dokumenterbarhed.

Styringsgrundlaget: hvem bestemmer hvad, og hvornår?

Den første store fejl, jeg ser i AI-projekter, er at man starter med et værktøj fremfor en styringsmodel. Kommunale AI-løsninger bør forankres i en klar governance, der matcher både lovgivning, it-arkitektur og den konkrete fagpraksis.

Rollefordeling og beslutningsrettigheder

Start med at definere, hvem der ejer processen og hvem der ejer modellen. I en kommune vil det ofte være delt mellem fagforvaltning, it, informationssikkerhed, jura/DPO og leverandør. Uden klare roller kan kritiske spørgsmål falde mellem stolene: Hvem godkender ændringer? Hvem stopper løsningen ved fejl? Hvem svarer på borgerhenvendelser?

• Systemejer (forretning): fastlægger formål, succeskriterier og acceptabel risiko.
• Modelansvarlig (ofte it/data): styrer versioner, træning, performance og drift.
• Faglig ansvarlig: sikrer at output giver mening i praksis og ikke skaber skævheder.
• DPO/jura: vurderer behandlingsgrundlag, oplysningspligt, DPIA og kontrakter.
• Informationssikkerhed: krav til adgang, logning, hændelser og leverandørstyring.
• Leverandør: dokumentation, support, ændringsstyring og sikkerhedsforanstaltninger.

Politikker, standarder og “stop-knap”

En praktisk standard er at indføre en enkel “AI-brugsmodel” med tre niveauer: 1) lav risiko (fx intern tekstopsummering), 2) medium (fx prioritering af sager), 3) høj (fx visitation eller afgørelsesnær beslutningsstøtte). For hvert niveau definerer man krav til test, godkendelse, dokumentation og kontrol.

Og ja: der skal være en stop-knap. Det kan være en driftsprocedure, hvor løsningen sættes på pause ved bestemte hændelser (fx pludseligt performancefald, databrud eller ændringer i lovgrundlag).

Mini-konklusion: God governance gør AI “kommunalt” ved at gøre ansvar, ændringer og kontrol tydelige.

Datasikkerhed og GDPR: data er ikke bare brændstof

I kommuner arbejder man ofte med følsomme personoplysninger, herunder helbredsoplysninger, sociale forhold og oplysninger om børn. Derfor skal AI-løsninger designes ud fra principper som dataminimering, formålsbegrænsning og sikker behandling.

Behandlingsgrundlag, DPIA og oplysningspligt

Hvis AI-løsningen indebærer ny type behandling eller øget risiko for borgeren, er en DPIA (konsekvensanalyse) ofte nødvendig. I praksis bør DPIA’en ikke være en skrivebordsøvelse: den skal kobles til arkitektur, datakilder og faktisk arbejdsgang. Spørg fx: Hvilke data hentes? Hvem ser output? Arkiveres output? Påvirker output en afgørelse?

Oplysningspligten er et andet sted, hvor kommuner ofte undervurderer behovet: Borgeren skal kunne forstå, at AI er involveret, hvad den bruges til, og hvilke rettigheder borgeren har. Det kan kræve opdaterede breve, hjemmesidetekster og sagsbehandlingsnotater.

Adgang, logning og miljøadskillelse

Min tommelfingerregel: Hvis løsningen kan påvirke en borgers sag, skal logning og adgangsstyring være på niveau med fagsystemer. Det betyder typisk:

1. Role-based access (mindste privilegium), også for superbrugere.
2. Sporbarhed: hvem har kørt hvad, hvornår, på hvilke data, med hvilken modelversion.
3. Adskillelse af miljøer (test/udvikling/produktion) og styr på “prøvedata”.
4. Sikker nøgle- og hemmelighedshåndtering (API-nøgler, tokens).
5. Klare slettepolitikker og retention for input/output.

Mini-konklusion: GDPR og sikkerhed er ikke en fase til sidst; det er designkrav, der skal ligge før første pilot.

Leverandørstyring og kontrakter: få det ned på papir

Mange kommuner bruger AI via leverandørplatforme eller standardsoftware med AI-funktioner. Her er det afgørende at gøre krav konkrete og kontraktuelle: Hvad leveres, hvordan dokumenteres det, og hvad sker der ved hændelser?

Midt i arbejdet med politikker og proceskrav kan det være nyttigt at orientere sig mod praksisnære rammer for ansvarlig AI i kommunerne og omsætte principperne til kontraktkrav og driftsprocedurer.

• Databehandleraftale: underdatabehandlere, lokationer, overførsler og sletning.
• Sikkerhedskrav: hændelsesrespons, tidsfrister for varsling, auditmuligheder.
• Dokumentation: modelkort, datakilder, kendte begrænsninger, ændringslog.
• SLA: oppetid, support, fejlretning, og hvad “kritisk” betyder.
• Exit: mulighed for at migrere data, skifte leverandør og lukke løsningen ned.

Mini-konklusion: Leverandørdialogen skal oversættes til målbare krav, ellers ender kommunen med ansvaret uden styringen.

Kvalitet, bias og faglig validitet: når modellen møder virkeligheden

AI kan være imponerende i demoer og skuffende i drift. Især i kommuner, hvor datasæt ofte er ujævne, praksis ændrer sig over tid, og sager ikke ligner hinanden. Derfor skal man arbejde systematisk med kvalitet og fairness.

Test før drift: mere end “det ser rigtigt ud”

Indfør acceptkriterier, der giver mening i fagligheden. Et klassisk eksempel: En model, der skal prioritere byggesager, kan måles på træfsikkerhed. Men i praksis er det ofte vigtigere at minimere “farlige fejl” (fx at hastesager ikke overses), end at optimere gennemsnitlig præcision.

Brug også simple sammenligninger: Hvor lang tid bruger medarbejdere i dag? Hvis AI sparer 10 minutter pr. sag i en enhed med 8.000 årlige sager, svarer det til ca. 1.333 timer om året. Men hvis 2% af sagerne bliver misprioriteret og kræver dobbeltarbejde, kan gevinsten hurtigt udhules. Den slags regnestykker er gode at have med i beslutningsgrundlaget.

Bias og skævheder: find dem, før borgerne gør

Skævheder opstår ofte, fordi data afspejler historisk praksis. Hvis der fx er forskelle i, hvordan sager dokumenteres på tværs af lokalområder, kan modellen lære mønstre, der ikke er saglige. Derfor bør man teste output på undergrupper (fx alder, køn, geografi) i det omfang det er lovligt og relevant, og man bør dokumentere, hvilke fairness-kriterier der er valgt.

Mini-konklusion: En fagligt “god” model er en model, der er dokumenteret robust og rimelig i den konkrete kommunale kontekst.

Transparens og forklarlighed: borgeren skal kunne forstå konsekvenserne

Kommunale afgørelser kræver begrundelser, og borgeren har ret til indsigt i sagens oplysninger og vurderinger. Derfor skal AI-output kunne forklares og indgå meningsfuldt i journalisering og notatpligt.

Det betyder ikke, at alle modeller skal være fuldt “forklarlige” matematisk. Men man skal kunne forklare: hvilke input der indgår, hvad output betyder, og hvordan medarbejderen skal bruge det. For generativ AI (fx udkast til afgørelsestekster) handler forklarlighed ofte om at kunne dokumentere kilder, sikre korrekt jurasprog og tydeliggøre, at det er et udkast.

• Gør det tydeligt i brugerfladen, når noget er AI-genereret, og hvornår det senest er opdateret.
• Vis hvilke datakilder der er brugt, og om noget er mangelfuldt.
• Undgå “sort boks” i afgørelsesnære flows: kræv menneskelig vurdering og notat af begrundelse.
• Træn medarbejdere i at afkræfte modellen: hvad gør man, når AI tager fejl?

Mini-konklusion: Transparens er både en retssikkerhedsdiciplin og en driftsdisciplin: det gør fejl nemmere at opdage.

Drift, monitorering og hændelseshåndtering: AI er ikke “sæt og glem”

AI-løsninger ændrer sig i praksis, selv hvis man ikke opdaterer dem. Data kan skifte (nye blanketter, nye praksisser), og brugerne kan ændre adfærd. Derfor skal man etablere monitorering, som minder om det, man kender fra informationssikkerhed og it-drift.

Monitorering: hvad måler man?

Mål både tekniske og faglige indikatorer. Tekniske: svartider, fejlrate, tilgængelighed. Faglige: andel af sager, hvor medarbejdere tilsidesætter AI-anbefalinger, stikprøver af kvalitet, og udvikling i klager eller genåbninger (selv om det er “lagging indicators”).

Incident response: når noget går galt

Hændelser kan være alt fra datalæk til “silent failures”, hvor modellen gradvist bliver dårligere. Hav en procedure for triage, kommunikation og korrigerende handlinger. Det bør også være afklaret, hvornår man orienterer ledelse, DPO, tilsyn eller berørte borgere.

Mini-konklusion: Den reelle risiko ligger ofte i driften: små fejl over tid kan give store konsekvenser i borgerforløb.

Økonomi og ressourcer: hvad koster ansvarlig AI i praksis?

Spørgsmålet “hvad koster det?” bør besvares bredt. Licenser og udvikling er kun en del. Der kommer udgifter til sikkerhed, uddannelse, governance, test, ændringsstyring og drift.

Som pejlemærke ser jeg ofte, at den løbende drift og kontrol kan udgøre 15–30% af den samlede årlige omkostning ved løsningen, afhængigt af risikoniveau og kompleksitet. For generativ AI kan omkostninger også være forbrugsbaserede (tokens/brug), hvilket kræver budgetstyring og eventuelt “rate limits”.

• Engangsomkostninger: afklaring af formål, DPIA, dataklargøring, integrationer, pilot.
• Løbende: monitorering, audits, retræning/kalibrering, support, sikkerhedstest.
• Organisatorisk: træning af medarbejdere, superbrugernetværk, opdatering af arbejdsgange.

Mini-konklusion: Den billigste AI er sjældent den bedste; den ansvarlige AI er den, der også har budget til kontrol og vedligehold.

Typiske faldgruber og bedste praksis: en kort tjekliste til kommuner

De samme problemer går igen på tværs af kommuner, uanset om det handler om socialområdet, teknik og miljø eller borgerservice. Her er de mest almindelige faldgruber og konkrete måder at undgå dem på.

1. Uklart formål: Definér præcist, hvilken beslutning eller proces AI skal støtte, og hvad der ikke må ske.
2. Data uden kontekst: Dokumentér datakilder, kvalitet, mangler og hvad der kan påvirke output.
3. Ingen menneskelig kontrol: Design arbejdsgangen, så medarbejderen aktivt kan godkende, afvise og begrunde.
4. Manglende dokumentation: Kræv model- og ændringslog, og gem relevant beslutningsgrundlag i sagen.
5. Shadow AI: Lav klare retningslinjer for brug af åbne chatværktøjer og håndhæv dem med tekniske kontroller.
6. For lidt test i virkelige sager: Kør pilot på repræsentative sager, og mål effekter og fejltyper.
7. Ingen plan for drift: Etabler monitorering, incident response og faste review-møder.

Hvis du kun gør én ting i morgen: få beskrevet arbejdsgangen med AI som et procesdiagram i ord (hvem gør hvad, med hvilke data, og hvor ligger ansvaret). Det er ofte den hurtigste vej til at opdage risici, før de bliver til sager.

Mini-konklusion: Bedste praksis er at behandle AI som en kritisk del af forretningen, ikke som et eksperiment ved siden af.