AI kan gøre sagsbehandling hurtigere, frigive tid i hjemmeplejen og give bedre overblik i drift—men uden styring kan samme AI-initiativ skabe nye og dyre risici, som først opdages, når en borger klager, Datatilsynet spørger, eller pressen ringer.
I denne artikel får du et praktisk overblik over, hvor kommunale AI-projekter typisk går galt, og hvordan du bygger governance, datagrundlag og ansvarskæder, der kan holde til virkeligheden. Du får konkrete eksempler fra kommunal praksis, typiske faldgruber og en tjekliste, du kan bruge i din egen organisation.
Hvad er et AI-initiativ i en kommune—og hvorfor betyder det noget?
Et AI-initiativ i en kommune er enhver løsning, hvor algoritmer (ofte machine learning eller generativ AI) bruges til at forudsige, anbefale, automatisere eller formulere noget, der påvirker kommunens arbejde—fx triagering af henvendelser, prioritering af tilsyn, udkast til afgørelsesbreve eller analyse af mønstre i social- og sundhedsdata.
Det betyder noget, fordi kommuner arbejder med højrisikoområder: borgeres rettigheder, følsomme oplysninger og afgørelser med store konsekvenser. Når AI flytter beslutningskraft—helt eller delvist—opstår nye risici: skævhed, fejl i data, manglende forklarlighed, uklare ansvar og brud på GDPR eller forvaltningsretlige principper.
Mini-konklusion: AI i kommuner er ikke “bare et IT-projekt”; det er forvaltningsudvikling med direkte effekt på borgere, økonomi og tillid.
De nye risici: Når governance, data og ansvar ikke følger med
Mange kommuner starter med en pilot: en chatbot, en model til at forudsige udeblivelser, eller generativ AI til at skrive udkast. Piloter er gode—men de skaber ofte en falsk tryghed, fordi de kører på “pæne” datasæt, små afdelinger og engagerede nøglepersoner. Når løsningen skaleres, dukker risiciene op.
Governance-risiko: Hvem bestemmer, og hvem stopper?
Uden governance ser jeg typisk tre problemer: (1) ingen fælles kriterier for, hvornår AI må bruges, (2) ingen beslutningslog for ændringer i modellen, og (3) ingen “stop-knap” med mandat. Det kan føre til, at en model fortsætter i drift, selv når fejl er kendte, fordi ingen ejer beslutningen om at pause.
Datarisiko: “Det stod jo i systemet” er ikke det samme som sandhed
Kommunale fagsystemer indeholder ofte registreringer, der er lavet til drift—ikke til statistiske modeller. Eksempel: En kode i et omsorgssystem kan afspejle en arbejdsgang, ikke en borgerstatus. Hvis AI trænes på den type data, kan den forveksle praksisvariation med borgerbehov. Resultatet bliver skæve anbefalinger, der ser “objektive” ud, men i praksis reproducerer lokale vaner.
Mini-konklusion: De største risici opstår sjældent i selve algoritmen—men i styring, datakvalitet og uklare beslutningsveje.
Ansvarskæden: Fra dataejer til sagsbehandler og leverandør
Et af de mest undervurderede spørgsmål er: Hvem har ansvaret, når AI tager fejl? I kommunal kontekst er svaret næsten altid “kommunen”—men internt kan ansvaret blive uklart, hvis man ikke designer en ansvarskæde.
Tre ansvar, der ofte flyder sammen
- Dataansvar: Hvem godkender, at data er relevante, lovlige og opdaterede til formålet?
- Modelansvar: Hvem dokumenterer performance, bias-tests, ændringer og versionsstyring?
- Procesansvar: Hvem sikrer, at sagsbehandlingen følger reglerne, og at AI kun bruges som besluttet?
Hvis én af disse mangler, ender man med “ansvarsvakuum”: Sagsbehandleren tror, IT har styr på det. IT tror, fagområdet har godkendt det. Leverandøren siger, at kommunen bestemmer anvendelsen.
Konkrete greb til tydelig ansvarlighed
Praktisk fungerer det godt at etablere en RACI-lignende rollefordeling (Responsible, Accountable, Consulted, Informed) pr. use case samt en fast driftsrytme: månedlig monitorering, kvartalsvis ledelsesreview og en klar procedure for incident-håndtering.
Mini-konklusion: Når ansvar er eksplicit, kan fejl opdages tidligere, og kommunen kan reagere hurtigt uden intern pegen-fingre.
Typiske use cases—og hvor de går galt i praksis
De mest udbredte kommunale AI-use cases falder ofte i tre kategorier: (1) service og kommunikation, (2) intern effektivisering, og (3) beslutningsstøtte i myndighedsopgaver. Risikoen stiger typisk, jo tættere man kommer på afgørelser og visitation.
En chatbot, der svarer på åbningstider, kan stadig være problematisk, hvis den hallucinerer og giver forkert vejledning. Men konsekvensen er ofte mindre end ved en model, der foreslår kontrolmål eller prioriterer borgere til indsats.
Midt i implementeringen støder mange på det, jeg vil kalde “AI’s skjulte regning”: ekstra tid til dataoprensning, juridisk afklaring, ændring af arbejdsgange og løbende drift. For en nøgtern gennemgang af typiske risici ved AI i kommunerne kan det være nyttigt at sammenholde jura, teknik og praksis i samme billede.
Eksempel: Generativ AI til brevudkast
Mange kommuner tester generativ AI til at skrive udkast til afgørelsesbreve. Det kan spare tid, men falder ofte på to klassiske fejl: (1) modellen “finder på” begrundelser eller henvisninger, og (2) sproget bliver ensartet på en måde, der skjuler faglige nuancer. Løsningen er ikke at forbyde værktøjet, men at afgrænse: AI må foreslå struktur og klarsprog—men aldrig udfylde faktiske forhold eller juridiske vurderinger uden faglig kontrol.
Eksempel: Risikoscorer i tilsyn eller social indsats
En risikoscore kan virke som en neutral prioritering, men hvis træningsdata afspejler historiske tilsynsmønstre, kan modellen komme til at “bekræfte” tidligere fokusområder og overses nye. Her bør man kræve dokumentation for, hvordan man har testet for skævhed, og hvordan man sikrer, at modellen ikke bliver selvforstærkende.
Mini-konklusion: Use cases er ikke lige risikable. Jo mere AI påvirker prioritering og afgørelser, jo mere skal governance og dokumentation være på plads.
Data og GDPR: Lovlighed, formål og “dataminimering i praksis”
“Hvordan kan det være ulovligt, når vi allerede har data?” er et typisk spørgsmål. Svaret er, at lovlighed ikke kun handler om at have adgang til data, men om formål, hjemmel, oplysningspligt, dataminimering og sikkerhed. Hvis data oprindeligt blev indsamlet til én opgave, kræver ny brug ofte en konkret vurdering.
De tre datafejl, jeg ser oftest
- Formålsglidning: Man bruger data til et nyt formål uden at beskrive og vurdere det tydeligt.
- For brede datasæt: “Vi tager alt, så modellen bliver bedre” i stedet for at dokumentere nødvendige variabler.
- Manglende dokumentation: Ingen kan forklare, hvorfor bestemte felter indgår, eller hvordan de opdateres.
Sådan gør du dataminimering konkret
Dataminimering bliver praktisk, når du oversætter det til designkrav: Hvilke felter er “must have”, “nice to have” og “no go”? Et godt greb er at lave en variabelliste med begrundelse pr. felt samt et “drop-kriterie”: Hvis feltet ikke forbedrer kvaliteten målbart, ryger det ud. Det tvinger projektet til at vælge til og fra—og gør senere kontrol langt lettere.
Mini-konklusion: GDPR-arbejdet bør ikke komme til sidst som et bilag; det er en del af selve designet af AI-løsningen.
Governance, der virker: Fra politikpapir til drift
Mange organisationer laver en AI-politik, men glemmer driften. Governance skal kunne håndtere hverdagen: ændringer i data, ny modelversion, medarbejdere der bruger værktøjet på nye måder, og leverandører der opdaterer funktioner. Hvis governance ikke kan følge med, bliver AI hurtigt “skygge-IT” i lovlig udgave.
Et minimumssetup for kommunal AI-governance
- AI-porteføljestyring: Hvilke use cases findes, hvem ejer dem, og hvilket risikoniveau har de?
- Godkendelsesflow: Klare gates før pilot, før drift og ved væsentlige ændringer.
- Model- og datadokumentation: Versionsstyring, datakilder, tests og kendte begrænsninger.
- Monitorering: KPI’er for kvalitet, bias-indikatorer, driftshændelser og brugerfeedback.
- Kompetencer: Uddannelse af nøglepersoner og et fælles sprog for risici.
- Incident-proces: Hvem gør hvad ved fejl, klager eller databrud—og hvor hurtigt?
Governance vs. tempo: Ja, det kan godt gå hurtigt
En udbredt bekymring er, at governance gør alting langsomt. Min erfaring er det modsatte: Når rammerne er klare, kan man eksperimentere hurtigere, fordi man ved, hvilke data man må bruge, hvem der godkender hvad, og hvordan man ruller tilbage. Det reducerer “frys” i organisationen, når der opstår tvivl.
Mini-konklusion: God governance er ikke bureaukrati; det er det, der gør skalering mulig uden at miste kontrol.
Hvad koster det at gøre det ordentligt—og hvad koster det at lade være?
Kommuner spørger med rette: “Hvad koster governance og dokumentation?” Det korte svar er, at prisen afhænger af modenhed og risikoniveau—men at den største udgift ofte er tid fra fagpersoner, ikke software.
Som tommelfingerregel ser jeg ofte, at et pilotprojekt undervurderer indsatsen til data, jura og drift med en faktor 2–4. Hvis der fx er afsat 100 timer til “data”, ender man let på 200–400 timer, når man medregner oprensning, mapping mellem fagsystemer, kvalitetstjek og løbende vedligehold.
Omkostningen ved at lade være viser sig typisk som:
- Ekstra sagsbehandlingstid, fordi output ikke kan bruges uden omfattende kontrol.
- Genudvikling, når man opdager, at data eller hjemmel ikke holder.
- Klager og omgjorte afgørelser, som spiser gevinsten.
- Tab af tillid internt og eksternt—som gør næste digitaliseringsprojekt sværere.
Mini-konklusion: Governance koster—men fraværet af governance koster som regel mere og rammer senere, når ændringer er dyrere.
De mest almindelige fejl—og bedste praksis til at undgå dem
Hvis du kun tager én ting med: Kommunale AI-initiativer fejler sjældent, fordi folk ikke vil det rigtige. De fejler, fordi man undervurderer kompleksiteten i data, jura og arbejdsgange.
Fejl 1: “AI’en rådgiver bare” uden at definere beslutningsrollen
Hvis sagsbehandleren i praksis følger AI’s anbefaling 9 ud af 10 gange, så er det reelt beslutningsstøtte med høj påvirkning. Bedste praksis er at beskrive, hvornår AI må bruges, hvornår den ikke må, og hvilke kontrolspørgsmål der altid skal stilles. Overvej også stikprøvekontrol og krav om begrundelse ved afvigelse eller følgning—så adfærden bliver synlig.
Fejl 2: For lidt fokus på ændringer over tid
Data ændrer sig. Praksis ændrer sig. Lovgrundlag ændrer sig. Det, der virkede i januar, kan være misvisende i september. Bedste praksis er at definere driftstærskler: Hvornår skal modellen genvalideres? Hvilke indikatorer udløser pause? Hvem har mandat?
Fejl 3: Leverandørkontrakter uden klare krav til transparens
Hvis kommunen ikke kan få indsigt i datagrundlag, testresultater, underleverandører og ændringslog, bliver styring umulig. Bedste praksis er at stille krav til dokumentation, auditmuligheder, databehandleraftaler og klare roller ved fejl. Det er ikke “nice to have”; det er forudsætningen for ansvarlig drift.
Mini-konklusion: Bedste praksis handler ikke om perfekte modeller, men om klare roller, målbar kvalitet og en robust ændringsproces.
En praktisk tjekliste før I sætter AI i drift
Brug tjeklisten som en sidste “go/no-go” før drift. Den virker især godt, hvis den gennemgås tværfagligt: fagområde, IT, DPO/jura og ledelse.
- Er formål og hjemmel dokumenteret, og er oplysningspligt afklaret?
- Er datasættet minimeret, og kan I forklare hvert felt?
- Er der lavet en risikovurdering, der matcher use casens påvirkning på borgere?
- Er der en navngiven Accountable ejer med mandat til at stoppe løsningen?
- Er modelperformance testet på repræsentative data—og gen-test planlagt?
- Er arbejdsgangen beskrevet, inkl. menneskelig kontrol og logning af brug?
- Er leverandørkrav, databehandleraftaler og ændringshåndtering på plads?
- Er monitorering, incident-proces og kommunikationsplan klar ved fejl?
Mini-konklusion: Når I kan sætte flueben ved tjeklisten, er sandsynligheden markant større for, at AI skaber gevinster uden at skabe nye uforudsete risici.
