Fra pilotprojekt til drift: governance for AI i kommunerne

De fleste kommuner er forbi “vi har prøvet ChatGPT”-fasen — men det er her, de svære spørgsmål starter: Hvordan får man AI fra sporadiske eksperimenter og pilotprojekter over i en ansvarlig, sikker og stabil drift, der kan tåle revision, presse og borgernes forventninger?

I denne artikel får du en praktisk guide til, hvad der typisk skal på plads i en kommune, før AI kan skaleres. Du får en klar definition, konkrete styringsgreb, eksempler fra kommunale arbejdsgange, og en realistisk forståelse af omkostninger, faldgruber og best practices. Målet er, at du kan omsætte indsigterne til en plan — uanset om du sidder i IT, digitalisering, jura, sikkerhed, fagforvaltning eller ledelse.

Definition: Når vi taler om at flytte AI i kommuner fra eksperimenter til drift, mener vi overgangen fra ad hoc-brug (ofte uden faste processer og dokumentation) til kontrolleret, gentagelig og ansvarlig anvendelse, hvor data, risici, leverandører, lovkrav og kvalitet er styrret på samme måde som andre kritiske it-systemer. Det betyder noget, fordi AI kan påvirke både afgørelser, servicekvalitet og borgernes retssikkerhed — og fordi fejl typisk skalerer hurtigere end gevinster.

1) Hvorfor AI-piloter ofte går i stå — og hvad “drift” egentlig kræver

Mange AI-tiltag stopper ved proof-of-concept, fordi de er bygget som engangsprojekter: én afdeling, én leverandør, ét datasæt og begrænset opmærksomhed på drift, sikkerhed og ændringsstyring. Det føles som fremdrift, men mangler fundamentet til at blive hverdag.

Drift handler ikke kun om at “have en model”. Drift er evnen til at levere stabil værdi uge efter uge: med klare ejerskaber, logning, adgangsstyring, dokumentation, ændringskontrol, brugertræning og målepunkter for kvalitet. I praksis kræver det ofte samme disciplin som ved andre systemer med persondata og forvaltningskritiske processer.

Mini-konklusion: Hvis AI skal skaleres, skal den behandles som en driftsydelse — ikke som et innovationsprojekt uden bremser og sikkerhedssele.

2) Start med de rigtige use cases: høj værdi, lav risiko, tydelig ejer

Det mest undervurderede valg i en AI-rejse er, hvilke opgaver der overhovedet egner sig til AI. Kommuner har ofte hundrede idéer, men kun få kan tåle kravene til ansvarlighed og drift fra dag ét.

Et praktisk kriteriesæt til udvælgelse

Jeg anbefaler at score use cases på tre akser: værdipotentiale, risiko/kompleksitet og datagrundlag. En god “første drifts-case” har typisk høj volumen, gentagne mønstre og begrænset konsekvens ved fejl — samtidig med, at der findes tydelige kvalitetskriterier.

• Volumen: mange ensartede henvendelser, dokumenter eller sager.
• Konsekvens: fejl må ikke give retsvirkning uden menneskelig kontrol.
• Datakvalitet: tilstrækkelig struktur, ejerforhold og lovligt behandlingsgrundlag.
• Målelig kvalitet: klart hvad “godt nok” betyder (fx svartid, fejlrate, tilfredshed).
• Ejer: en konkret faglig procesejer, ikke “IT” som standard-ejer.
• Skalerbarhed: mulighed for at genbruge mønstre på tværs af forvaltninger.

Eksempler der ofte kan bringes i drift relativt hurtigt

Kommuner får ofte mest stabil drift ved AI, når anvendelsen ligger tæt på “assistive” opgaver: udkast, opsummering, klassifikation og søgning. Eksempler kan være:

1. Forslag til svarudkast til borgerservice (med menneskelig godkendelse).
2. Opsummering af lange dokumenter, referater eller aktindsigter til intern brug.
3. Automatisk kategorisering og routing af henvendelser i postkasser.
4. Intern vidensøgning i politikker, procedurer og retningslinjer med kildehenvisninger.
5. Støtte til sagsbehandleren: tjeklister og “mangler du disse bilag?”-anbefalinger.

Mini-konklusion: Vælg use cases hvor AI kan øge tempo og kvalitet, men hvor kommunen stadig har kontrol over det endelige output og kan dokumentere processen.

3) Governance og ansvar: hvem ejer hvad, og hvordan undgår man “skygge-AI”

Den klassiske kommunale udfordring er ikke mangel på idéer — det er uklart ansvar. Når AI først er let tilgængeligt, opstår “skygge-AI”: medarbejdere uploader data i uautoriserede værktøjer eller bygger små automatiseringer uden sikkerhedsvurdering. Det skaber både datarisiko og uens praksis.

En enkel governance-model, der virker i praksis

Du behøver ikke et tungt råd med 20 personer for at komme i gang, men du skal have tre tydelige funktioner:

• Forretningsejer (fagchef/procesejer): definerer formål, kvalitet og acceptkriterier.
• Data- og compliance-ejer (DPO/jura/informationssikkerhed): vurderer lovgrundlag, risici, DPIA, leverandørforhold.
• Drifts- og platformsejer (IT): styrer adgang, logning, integration, ændringer og incident-håndtering.

I midten af det hele står behovet for fælles spilleregler og beslutningsveje. Mange kommuner samler det under en ramme for governance for AI i kommunerne, så use cases behandles ensartet, og det bliver tydeligt, hvornår noget er “til eksperiment” og hvornår det er “til drift”.

Stop skygge-AI med klare grænser og gode alternativer

Et forbud alene virker sjældent. Hvis medarbejdere ikke får et sikkert, godkendt værktøj, finder de et andet. Et mere effektivt greb er at kombinere politik med praksis:

• Gør godkendte værktøjer lette at tilgå (SSO, klare retningslinjer, korte kurser).
• Definér datakategorier: hvad må aldrig ind, hvad må under betingelser, og hvad er frit.
• Indfør “hurtig vurdering” af nye use cases, så innovation ikke drukner i ventetid.

Mini-konklusion: Governance er ikke bureaukrati; det er måden, du gør AI sikkert skalerbart uden at kvæle initiativet.

4) Datasikkerhed, GDPR og risikovurdering: fra mavefornemmelse til dokumenteret kontrol

AI i drift kræver, at kommunen kan forklare: hvilke data bruges, hvorfor, hvor de ligger, hvem der har adgang, og hvordan man opdager misbrug eller fejl. Det er især kritisk, når der behandles personoplysninger, fortrolige sager eller oplysninger om børn og udsatte borgere.

DPIA og risikomodel i øjenhøjde

En DPIA bliver ofte opfattet som en stopklods, men den kan bruges som et designværktøj. En pragmatisk tilgang er at lave en standardiseret risikoscreening først og kun gå i fuld DPIA, når tærskler nås (fx følsomme data, nye teknologier, profilering eller stor skala).

Som tommelfingerregel: Hvis AI-output kan påvirke borgerens rettigheder eller adgang til ydelser, skal risikovurderingen være ekstra skarp, og menneskelig kontrol skal være tydeligt designet ind.

De typiske sikkerhedskrav i drift

I praksis ser jeg især disse krav gå igen, når AI skal i produktion:

• Adgangsstyring efter mindste privilegium, helst via rollebaseret tilgang.
• Logning af brug, prompts, output, datakilder og ændringer (hvad skete hvornår).
• Dataminimering: brug kun det nødvendige, og undgå kopier af komplette sagsmapper.
• Kryptering og klare regler for lagring, retention og sletning.
• Leverandørkontrol: databehandleraftaler, underdatabehandlere, og hvor data behandles.

Mini-konklusion: Drift kræver, at du kan bevise kontrol — ikke bare føle, at “det nok går”.

5) Teknisk platform: fra enkeltværktøjer til en kontrolleret AI-stak

Mange kommuner starter med et enkelt chat-værktøj. Det er fint til læring, men drift kræver typisk en platformstankegang: hvordan kobler vi AI sikkert til viden, fagsystemer og arbejdsgange, uden at data flyder ud eller forsvinder i manuelle copy-paste-processer?

Arkitekturvalg: køb, byg eller kombiner

Der findes groft sagt tre veje:

• Standardværktøj (SaaS): hurtigt i gang, men begrænset tilpasning og afhængighed af leverandørens roadmap.
• Komponent-baseret (API’er + egen styring): mere fleksibilitet og bedre integration, men højere kompetencekrav.
• Hybrid: standardværktøj til generelle opgaver og en kontrolleret API-platform til følsomme eller integrerede use cases.

Et konkret driftstegn: Kan I skifte model/leverandør uden at genopfinde alt? Hvis ikke, er I ofte låst i et setup, der bliver dyrt at vedligeholde.

RAG, vidensbaser og “hallucinationer” i kommunal kontekst

Kommuner bliver hurtigt ramt af problemet med forkerte eller forældede svar. En effektiv modgift er at bruge retrieval-augmented generation (RAG), hvor modellen kun svarer med støtte i kommunens egne dokumenter. Men RAG er ikke magi: dokumenterne skal versionstyres, kilder skal vises, og der skal være en proces for, hvem der godkender opdateringer i vidensbasen.

Mini-konklusion: En robust platform handler om integration, udskiftelighed og kontrol med viden — ikke om at vælge “den smarteste model”.

6) Kvalitet, test og monitorering: sådan gør du AI målbart og driftsklart

AI fejler på nye måder: den kan lyde overbevisende og stadig tage fejl. Derfor er “virker det?” ikke et ja/nej-spørgsmål, men et spørgsmål om kvalitet under kendte rammer, med løbende kontrol.

Teststrategi: før, under og efter idriftsættelse

Et praktisk set-up kan bestå af:

• Baseline-tests med et fast sæt realistiske cases (fx 100 typiske henvendelser).
• Acceptkriterier: fx maks. fejlrate, krav om kildehenvisning, eller at svaret altid skal foreslå næste skridt.
• Red teaming: prøv at få systemet til at lække data, give ulovlige råd eller ignorere politikker.
• Canary release: start med én afdeling eller en lille brugergruppe før fuld udrulning.

Monitorering i drift: hvad skal du holde øje med?

Monitorering bør ikke kun være oppetid. I kommunal drift er de vigtigste signaler typisk kvalitet og risiko:

1. Andel svar der kræver korrektion eller eskalering.
2. Hyppige fejlkategorier (fx misforståede regler, manglende bilag, forældede politikker).
3. Databrud eller mistænkelig brug (fx usædvanlige prompts, masse-udtræk).
4. Model- eller datadrift (pludselig ændret adfærd efter opdatering).

Mini-konklusion: Du kan ikke styre det, du ikke måler — og AI uden monitorering bliver hurtigt et ansvar frem for en gevinst.

7) Mennesker og arbejdsgange: kompetencer, ændringsledelse og “human in the loop”

AI i drift er lige så meget organisationsudvikling som teknologi. Den største produktivitetsgevinst kommer ofte, når arbejdsgange ændres, ikke når man “lægger AI ovenpå” den gamle måde at arbejde på.

Human in the loop som designprincip

I mange kommunale use cases bør AI ikke stå alene. En god tommelfingerregel er at placere menneskelig kontrol der, hvor konsekvensen af fejl er størst. Eksempel: AI kan lave et udkast til et svar, men en medarbejder godkender og justerer, før det sendes til borgeren. Det giver både sikkerhed og læring.

Kompetencer der ofte mangler — og hvordan du lukker hullerne

Det er sjældent nok at træne medarbejdere i “prompting”. Drift kræver også forståelse for dataklassifikation, kildekritik og ansvar. En effektiv kompetencepakke kan bestå af:

• Korte scenariebaserede kurser (30–60 min) pr. målgruppe.
• “Gør/lad være”-eksempler med kommunens egne datasituationer.
• Superbrugere i hver afdeling, der kan støtte og opsamle feedback.
• En fælles praksis for, hvordan AI-output dokumenteres i sagen, når relevant.

Mini-konklusion: Når AI lykkes i drift, er det fordi medarbejderne ved, hvornår de kan stole på systemet — og hvornår de ikke kan.

8) Økonomi og ressourcer: hvad koster det at sætte AI i drift i en kommune?

Spørgsmålet “hvad koster det?” kan ikke besvares med ét tal, men der er nogle tilbagevendende omkostningsposter, som ofte undervurderes. Mange piloter ser billige ud, fordi de låner tid og data fra driften uden at bogføre det.

Typiske omkostningselementer er:

• Licenser og forbrug (SaaS eller API-kald): varierer med volumen og krav til databeskyttelse.
• Implementering: integration, opsætning af vidensbase, rettighedsmodel og logning.
• Compliance: DPIA, kontrakter, sikkerhedsvurderinger og evt. revision.
• Drift: monitorering, incident-håndtering, opdateringer og løbende forbedringer.
• Forandring: træning, superbrugere, procesjusteringer og kommunikation.

Som sammenligning: En simpel “assistent til udkast” kan ofte bringes i kontrolleret drift med relativt lav implementeringsindsats, mens løsninger der påvirker sagsbehandling eller afgørelsesnære vurderinger kræver væsentligt mere dokumentation, test og governance — og dermed højere totalomkostning.

Mini-konklusion: Regn på totalomkostningen over 12–24 måneder, ikke på prisen for at “komme i gang” i denne måned.

9) De hyppigste fejl — og best practices der gør AI driftsmodent

Når AI-projekter går galt i kommunal kontekst, er det sjældent fordi teknologien ikke kan noget. Det er oftere fordi ansvar, data og kontrol ikke er