Byg kun den AI-styring du faktisk har brug for

– Drop jagten på den perfekte AI-governance-model
– Få styr på få, klare roller og hvem der siger ja/nej
– Stil de samme 8 spørgsmål til alle AI-ideer
– Indfør et lille sæt kontroller, der kan håndteres i hverdagen
– Start med 30-60-90 dage, ikke en 3-årig masterplan

Det er sådan, jeg selv ville gribe det an, hvis jeg sad i en mellemstor virksomhed med en håndfuld AI-piloter, lidt bekymrede jurister og en IT-chef, der allerede har for mange systemer at holde i live.

Jeg har efterhånden set en del AI-initiativer indefra. Fællesnævneren er ofte ikke mangel på idéer, men mangel på styring. Enten får man kaos med 30 forskellige værktøjer og ingen overblik. Eller også bliver governance så tung, at ingen tør prøve noget som helst.

Det her er min pragmatiske opskrift på “minimum viable AI governance”: Det mindste, du kan slippe afsted med, hvis AI både skal være nyttig og nogenlunde sikker.

Forstå hvad AI governance skal løse (og hvad det ikke er)

Jeg oplever tit, at “AI governance” bliver til et projekt, der handler mere om powerpoint-strukturer end om reel brug. For mig handler det om tre ting, der skal hænge sammen:

• Værdi: Bliver de vigtigste AI-tiltag faktisk til noget, og skaber de målbar effekt?
• Risiko: Har I et realistisk greb om datasikkerhed, bias, fejl og regulering (NIS2, kommende AI Act osv.)?
• Drift: Er der nogen, der holder øje med modellerne, når de først er i brug?

AI governance er ikke:

• Et legal-styret compliance-monster, der dræber alle eksperimenter
• En fancy AI-komité, der mødes hver anden måned og laver referater, men ingen reelle beslutninger
• En kopi af finansiel model governance, hvis I hverken er bank eller forsikringsselskab

AI governance er en aftale om roller, risici og kontroller, der gør det muligt at bruge teknologien uden at miste nattesøvnen. Ikke mere, ikke mindre.

Definér en enkel AI operating model: hvem bestemmer hvad?

Hvis jeg kun måtte gøre én ting i en virksomhed med AI-kaos, ville jeg få styr på rollerne. Ikke nye titler. Bare en klar fordeling af ansvar.

Et minimum, der faktisk fungerer, ser typisk sådan ud:

Product owner: Ejeren af forretningsværdien

Product owner er personen, der:

• Ejer use casen: Hvem er brugerne, og hvad er succeskriteriet?
• Forpligter sig på gevinst: Tager ansvar for, at AI-løsningen faktisk bliver brugt
• Prioriterer backlog og ændringsønsker

Det er sjældent IT. Det er oftere en leder eller faglig ansvarlig i den del af forretningen, hvor AI skal bruges.

Data owner: Ejeren af datakilderne

Data owner har ansvaret for:

• Hvilke datakilder må bruges til use casen
• Datakvalitet, opdateringsfrekvens og rettigheder
• At persondata og følsomme data behandles korrekt

Det kan være en data manager, en systemejer eller en forretningsansvarlig for det område, data stammer fra.

Risk/compliance: Den, der må sige “nej, ikke sådan”

Risk/compliance skal ikke bygge modellen, men:

• Definerer enkle krav til dokumentation, databrug og godkendelse
• Godkender use cases i de højeste risikokategorier
• Er kontaktpunkt til eksterne krav (revisor, tilsyn, regler som NIS2 osv.)

Det behøver ikke være et stort team. For mange mindre virksomheder er én erfaren profil med sikkerheds- og regulatorisk forståelse nok – hvis vedkommende bliver koblet tidligt på.

IT/security: Den tekniske vagtpost

IT/security sikrer:

• At AI-værktøjer ikke underminerer eksisterende sikkerhed
• At integrationer, adgangsstyring og logning etableres
• At leverandører lever op til samme sikkerhedskrav som øvrige systemer

Her giver det ofte mening at bruge nogle af de rammer, I måske allerede har arbejdet med i fx arbejdet med NIS2-krav.

Model owner: Ejeren af selve modellen

Model owner er personen, der:

• Forstår, hvordan modellen virker og er trænet
• Har ansvar for løbende monitorering og performance
• Godkender modelændringer, retraining og decommissioning

I en lille organisation kan model owner og data scientist være samme person. Det vigtige er, at der er en navngiven ansvarlig, ikke bare “data teamet”.

Hvis du vil sætte det i system, kan du passende få det lagt ind sammen med den måde, I arbejder med organisering og governance på i forvejen, så AI ikke bliver et særprojekt, men en del af den samlede styringsmodel.

Lav en fast AI use case intake: 8 spørgsmål før I går i gang

Det næstmest effektive greb er at indføre en simpel intake. Samme spørgsmål hver gang nogen vil bygge eller købe en AI-løsning. Det behøver ikke være fancy.

Her er et bud på 8 spørgsmål, som faktisk virker i praksis:

1. Problem: Hvilket konkret problem skal løses, og hvordan løses det i dag?
2. Værdi: Hvad er den forventede effekt (tid, kvalitet, omsætning, risiko)? Kan den måles?
3. Brugere: Hvem skal bruge løsningen, og hvor ofte?
4. Data: Hvilke datakilder bruges, og hvem ejer dem?
5. Risiko: Hvad er værste realistiske fejl (forkerte anbefalinger, datalæk, diskrimination osv.)?
6. Human-in-the-loop: Hvor og hvordan tjekker mennesker output, før det får konsekvenser?
7. Tekniske rammer: Bygger vi selv, bruger vi cloud-tjenester, eller køber vi fra tredjepart?
8. Tidsramme og scope: Hvad er et minimums pilot-scope på 8-12 uger?

Det her er ikke et ekstra excelark “for governance skyld”. Det er den naturlige foranalyse, der alligevel bør laves. Forskellen er bare, at den bliver standardiseret, så I kan sammenligne og prioritere på tværs af forslag.

Indfør et lille, fast kontrolsæt: data, adgang, logging, mennesker, dokumentation

Nu kommer den del, mange springer over. Nemlig at bestemme hvilke kontroller der altid skal være på plads, før noget går i drift.

Jeg vil anholde ideen om, at der skal 40 kontroller til. De fleste mellemstore virksomheder kommer langt med 5 områder:

1. Data: Hvad må modellen se, og hvor længe?

• Definér, hvilke datatyper der ikke må indgå (fx helbredsoplysninger, fagforeningsforhold osv.)
• Lav en enkel klassifikation: grøn (ufølsomme data), gul (almindelige persondata), rød (følsomme data)
• Aftal, hvor længe trænings- og logdata må gemmes, og hvordan de slettes igen

En typisk fejl er, at man logger alt “for en sikkerheds skyld”, og pludselig ligger der måneders følsom adfærd i en vendor-løsning uden klar aftale.

2. Adgang: Hvem må bruge og ændre modellen?

• Definér roller: almindelig bruger, superbruger, udvikler, administrator
• Kobl adgange til jeres eksisterende IAM/AD, så offboarding også rammer AI-værktøjerne
• Lav to-faktor på alle administrator- og udviklerroller

Det her er ikke særligt eksotisk. Det er klassisk cyber og informationssikkerhed overført til AI.

3. Logging: Kan I se, hvad modellen har gjort?

• Log hvem der har brugt løsningen, og hvornår
• Log centrale output, især i high-risk brugssituationer
• Sørg for, at logning ikke i sig selv bliver et nyt datarisiko-problem

Pointen er ikke at overvåge medarbejderne. Pointen er at kunne efterspore fejl og hændelser, hvis noget går galt.

4. Human-in-the-loop: Hvor stopper modellen, og mennesket starter?

• Definér tydeligt: Er AI’en et beslutningsstøtteværktøj eller et beslutningssystem?
• Beskriv, hvordan mennesker skal godkende eller korrigere output
• Træn brugerne i både at stole nok på systemet og udfordre det, når noget ser forkert ud

Jeg har set sager, hvor en simpel tekstgenerator pludselig får de facto beslutningsmagt, fordi ingen tør modsige “det systemet siger”. Det er governance-problem, ikke kun teknik.

5. Dokumentation: Minimal, men konsekvent

• Lav en kort modelbeskrivelse (1-2 sider): formål, data, algoritmetype, vigtigste antagelser
• Gem versionshistorik: hvornår modellen er ændret, og hvorfor
• Dokumentér ansvar: hvem er product owner, data owner og model owner?

Hvis dokumentation kræver 30 sider, bliver den aldrig vedligeholdt. Hvis den kun er i hovederne, kan I ikke forklare jeres valg for ledelse, revisorer eller myndigheder.

Gør vendor-AI mindre sort boks: krav til kontrakter og ændringer

Virkeligheden er, at mange AI-løsninger kommer udefra. Det er CRM-moduler, chatbots, HR-værktøjer, cloud-tjenester med indbygget model osv.

Her går det ofte galt, fordi man køber en “smart AI-feature” uden at få oversat kravene til kontrakt og leverandørstyring.

Tre ting jeg altid ville have med i AI-kontrakter

• Datahåndtering: Klarhed om, hvad leverandøren må bruge jeres data til (kun drift, eller også modeltræning til andre kunder?)
• Subleverandører: Hvem bruger de under motorhjelmen (store cloud-aktører, tredjeparts-modeller osv.)?
• Ændringsvarsling: Varslingspligt, hvis leverandøren ændrer model, dataplacering eller sikkerhedsniveau

Hvis I allerede arbejder med skabeloner og principper for it-kontraktpraksis, så lad AI-kravene lande dér, ikke i et separat dokument, ingen læser.

Få styr på AI i drift: monitorering og modelændringer

Den lidt kedelige sandhed er, at de fleste AI-problemer ikke opstår i pilotfasen. De opstår 6-18 måneder senere, når:

• Data har ændret sig
• Brugerne har ændret adfærd
• Leverandøren har justeret modellen uden at fortælle det tydeligt

Et minimum af driftsstyring bør indeholde to ting: monitorering og ændringsstyring.

Monitorering: Få en månedlig temperaturmåling

For hver model bør I have 3-5 simple indikatorer, der kan tjekkes månedligt:

• Brug: Hvor ofte anvendes løsningen? Af hvem?
• Kvalitet: Få en indikator på præcision, fejlrate eller brugertilfredshed
• Risiko: Antal hændelser, klager eller manuelle overstyringer

Det behøver ikke være et stort MLOps-setup. Et simpelt dashboard eller et fast udtræk, som model owner gennemgår, er langt bedre end ingenting.

Model change management: Hvornår er en ændring “stor nok”?

Definér på forhånd:

• Hvilke ændringer kræver fornyet godkendelse (nye datakilder, ændret formål, ny modeltype)
• Hvem skal godkende (typisk product owner + model owner, og i højrisiko også risk/compliance)
• Hvordan ændringer dokumenteres, så I kan forklare dem bagefter

Tænk på det som en enkel version af change management på øvrige IT-systemer, bare med fokus på modeladfærd.

Sæt KPI’er for AI: værdi, adoption, kvalitet, risiko

AI uden måling bliver hurtigt enten hype eller skuffelse. Jeg plejer at gruppere KPI’er i fire felter, der tilsammen giver et realistisk billede.

1. Værdi: Skaber det faktisk noget?

• Tidsbesparelse per transaktion eller sagsbehandling
• Forbedret konvertering, mersalg eller fastholdelse
• Reduceret fejlrate eller omarbejde

Her er det vigtigt at aftale baseline, før I går i gang. Ellers bliver diskussionen hurtigt mavefornemmelse.

2. Adoption: Bliver løsningen brugt?

• Andel af relevante processer, hvor AI bliver brugt
• Aktive brugere per uge/måned
• Andel af beslutninger, hvor AI-output indgår

En AI-løsning med flot modellering, men lav adoption, er i praksis en fancy prototype.

3. Kvalitet: Gør den det rimeligt godt?

• Præcision, recall, F1 eller tilsvarende tekniske mål, hvor det giver mening
• Brugervurderet kvalitet (simpel skala: “hjælper dette mig i mit arbejde?”)
• Andel af output, der kræver manuel korrektion

4. Risiko: Hvor tit går noget galt?

• Antal hændelser eller klager relateret til AI-output
• Antal kritiske overstyringer (mennesker stopper systemet)
• Eventuelle regulatoriske eller tilsynsmæssige observationer

Hvis I allerede rapporterer på andre risici og projekter til ledelsen, så fold AI-ind i de eksisterende rapporteringsveje. Det gør governance mindre fremmed og mere en del af den samlede forretningsstrategi og ledelse.

Planlæg 30-60-90 dage: sådan kommer I realistisk i gang

Hvis jeg skulle hjælpe en virksomhed i gang uden at gøre det til et årslangt projekt, ville jeg sætte en 90-dages horisont og dele den op sådan her.

De første 30 dage: Overblik og minimumsramme

• Kortlæg nuværende AI-brug (værktøjer, use cases, “skygge-AI” i teams)
• Udpeg roller for 2-3 vigtigste AI-initiativer (product owner, data owner, model owner)
• Enig om de 8 intake-spørgsmål og lav en enkel skabelon
• Beslut det lille kontrolsæt: data, adgang, logging, human-in-the-loop, dokumentation

Målet her er ikke at gøre det perfekt. Målet er at få sat det første, fælles hegn op omkring AI-aktiviteterne.

Dag 30-60: Prøv modellen af på 1-2 konkrete cases

• Vælg 1-2 use cases, der allerede er i gang eller på vej
• Anvend intake-spørgsmål, roller og kontroller fuldt ud på dem
• Tilpas kontrolsættet, hvis noget viser sig helt urealistisk i praksis
• Sæt de første KPI’er op: værdi, adoption, kvalitet og risiko

Det er her, governance-modellen går fra papir til virkelighed. Forvent, at noget ikke virker første gang. Det er okay. Juster.

Dag 60-90: Skalér stille og roligt

• Gør intake-processen obligatorisk for alle nye AI-ideer
• Udpeg en lille AI-governance-kreds (2-4 personer) der mødes månedligt
• Etabler enkel rapportering til ledelsen på status for AI-aktiviteter
• Lav en kort intern guide til teams: “Sådan arbejder vi med AI i vores virksomhed”

Hvis I når hertil efter 90 dage, har I et fungerende minimum. Ikke perfekt, men langt bedre end enten total fri leg eller total stilstand.

Hvad det her betyder for din virksomhed

Hvis jeg skal koge det ned til et par stykker køleskabsmagneter, så er det her pointen:

• AI governance handler ikke om at blive “færdig”, men om at have en ramme, der gør det muligt at bruge teknologien klogt
• Et lille sæt klare roller og kontroller slår store, uigennemskuelige rammeværk hver gang
• Intake-spørgsmål og simple KPI’er er det hurtigste skridt fra hype til konkret værdi

Hvis du sidder med ansvaret for digitalisering eller AI-tiltag, og det hele føles lidt som at holde styr på 12 åbne browserfaner samtidigt, så er mit bedste råd: start småt, men struktureret. Få lavet det mindste sæt aftaler om roller, risici og kontroller, som I kan holde ud at arbejde efter.

Og ja, du kommer til at justere undervejs. Men det er faktisk et godt tegn. Det betyder, at I ikke kun designer governance, men også bruger den.