AI i ledergruppen – sådan vælger I de første forsøg

Mange ledergrupper havner mellem to dårlige yderpunkter. Enten bliver AI til et stort strategiprojekt, før nogen har prøvet noget konkret. Eller også får hver afdeling lov til at eksperimentere på egen hånd uden fælles rammer. Begge dele kan undgås.

Start med et fælles nulpunkt

Jeg ville begynde med at få et fælles nulpunkt. Hvilke værktøjer bruger medarbejderne allerede? Hvilke data kan de møde i deres arbejde? Hvilke opgaver virker oplagte at afprøve? Og hvilke områder er så følsomme, at de kræver afklaring først?

Et nulpunkt er en kort, faktuel beholdningsliste. Det er ikke en modenhedsscore, der skal få organisationen til at se avanceret ud. Saml det på én side, og skriv “ukendt”, hvor ingen kan dokumentere svaret.

• Anvendelser: hvilke opgaver løses allerede helt eller delvist med AI – officielt og uofficielt?
• Værktøjer og konti: hvilke tjenester bruges, under hvilke aftaler, og hvem administrerer adgangen?
• Data: hvilke typer materiale indgår – offentligt, internt, fortroligt eller personoplysninger?
• Resultatets vej: bliver output i en kladde, eller kopieres det videre til mail, sagssystem eller beslutning?
• Ejerskab: hvem ejer opgaven, datakilden, den faglige kontrol og eventuelle hændelser?
• Erfaring: hvilke konkrete fejl, gevinster, klager eller ekstra kontroltrin er allerede registreret?

Kortlægningen bør kunne laves uden at indsamle unødige oplysninger om den enkelte medarbejders brug. Formålet er at se anvendelser og risici, ikke at finde en syndebuk. Foregår brugen gennem private konti eller med materiale, ingen har vurderet, er det et styrings- og sikkerhedsspørgsmål, som skal håndteres, før noget nyt sættes i gang.

Vælg få og afgrænsede forsøg

Derefter vælger man få forsøg. Ikke “indfør AI i kundeservice”, men noget afgrænset: Lav et første udkast til svar på én bestemt type henvendelse, som en medarbejder altid godkender. Eller brug AI til at strukturere et bestemt dokumentformat og mål, hvor ofte outputtet skal rettes.

Bedøm alle idéer med de samme fem spørgsmål, så meget forskellige forslag havner i den samme samtale. Værdi: hvilket konkret problem for hvem skal løses? Data: findes der et lovligt, relevant og vedligeholdt grundlag? Risiko: hvad sker der ved et forkert eller lækket resultat? Reversibilitet: kan forsøget og hvert output stoppes eller rulles tilbage? Ejer: hvem kan beslutte, måle, rette og stoppe? Brug gerne grøn, gul og rød frem for en totalscore med falsk præcision. En rød markering betyder ikke automatisk nej – den betyder, at forudsætningen skal håndteres først.

Vælg gerne én enkel produktionsopgave, én vidensopgave og én arbejdsgang, hvor I forventer at lære noget om kontrol. Undgå tre varianter af den samme lette skriveøvelse. Nye idéer kommer på en parkeringsliste med en dato for næste prioritering, så “nej, ikke nu” bliver en styret beslutning i stedet for en afvisning af medarbejdernes initiativ. Indgår der personoplysninger, kan de syv spørgsmål om AI og persondata bruges til den tidlige afklaring.

Giv hvert forsøg en ejer og en stopmulighed

For hvert forsøg skal der være en ejer, et konkret mål og et stopkriterium. Hvis ingen ved, hvem der kan lukke forsøget, når kvaliteten er dårlig, har man allerede bygget et styringsproblem.

Beskrivelsen skal kunne være på én side: problem og målgruppe, afgrænsning, udgangspunkt, hypotese, måling, kontrol, stopregel, ejer og reviewdato. Kræver den et helt programkontor, er forsøget for stort til at lære noget af.

Et konstrueret, men typisk eksempel: kommunikationsfunktionen prøver AI til første udkast af interne projektresuméer. Kun godkendte, ikke-fortrolige projektopdateringer indgår, tyve historiske eksempler bruges til en lukket prøve, og en navngiven redaktør kontrollerer mod kildeteksten. Stopreglen er, at forsøget pauses, hvis et udkast opfinder en beslutning, blander to projekter eller trækker materiale ind uden for den tilladte samling. Udfaldet kan blive fortsæt, ændr eller stop – ingen af de tre er et nederlag.

Et mål som “bedre kvalitet” er ikke nok. Definér, hvad der tælles eller bedømmes: manglende felter, faktuelle fejl, tid til faglig kontrol, antal omskrivninger. Tid kan være relevant, men må ikke stå alene, hvis hurtigheden bare flytter arbejdet fra at skrive til at kontrollere. Præcis den forskel er omdrejningspunktet i artiklen om hvad AI ikke kan.

Aftal de vigtigste rammer

Ledergruppens vigtigste arbejde er heller ikke at vælge modelnavn. Det er at sætte rammer: hvilke værktøjer må bruges, hvilke typer data må ind, hvilke resultater skal kontrolleres, og hvornår skal en fagperson eller specialist overtage. De tekniske detaljer kan ændre sig hurtigt. De spørgsmål gør ikke.

Rammerne skal passe til risikoen. Offentligt eller syntetisk materiale i et internt idéudkast uden automatisk handling kan klares af opgaveejeren og en almindelig faglig kontrol. Interne dokumenter, kundekommunikation eller gentagen klassifikation bør involvere systemejer, informationssikkerhed og dataejer. Følsomme data, væsentlig påvirkning af mennesker eller handlinger på tværs af systemer kræver juridisk, sikkerhedsmæssig og faglig vurdering, før der overhovedet piloteres. Det er en praktisk styringsmodel og ikke en juridisk klassifikation efter AI-forordningen; den retlige status afhænger af system, rolle og anvendelse.

Får et system lov til at handle selv – sende, ændre, bestille – skifter spørgsmålene igen. Forskellen på en assistent, en fast arbejdsgang og en agent er værd at have på plads, før nogen underskriver noget.

Brug erfaringen før I skriver den store strategi

En måned er nok til at komme hele vejen rundt, hvis rækkefølgen ligger fast:

1. Dag 1–5: Kortlæg anvendelser, værktøjer, data, outputveje, ejere og kendte hændelser. Pause kun det, der kræver akut afklaring.
2. Dag 6–10: Beskriv idéerne ens, bedøm dem med de fem spørgsmål, og vælg tre. Navngiv en ejer og en kontrollør for hver.
3. Dag 11–15: Skriv forsøgsbeskrivelse, testmateriale, acceptkriterier og stopregel. Bekræft tilladte data, adgang, logning og sletning.
4. Dag 16–25: Kør en lukket prøve på et begrænset, repræsentativt sæt. Registrér både gode resultater, fejl, kontroltid og de tilfælde, hvor systemet burde have stoppet.
5. Dag 26–29: Sammenlign med udgangspunktet, og undersøg grænsetilfældene. Lad ikke et pænt gennemsnit skjule en alvorlig fejltype.
6. Dag 30: Beslut: fortsæt i næste afgrænsede trin, ændr forsøget eller stop. Dokumentér begrundelse, nye betingelser, ejer og næste reviewdato.

Efter nogle få uger har I noget bedre end en AI-strategi på 30 sider: erfaring. I ved, hvilke opgaver der faktisk gav mening, hvor kontrollen blev dyr, hvilke medarbejdere der havde brug for hjælp, og hvilke regler der mangler. Det er et langt bedre grundlag for den næste beslutning.

Ledergruppen får med andre ord hul på AI ved at gøre færre ting mere efterprøvelige. Flere tekster om det står under temaet AI på arbejdet. Skal prioriteringen laves sammen med et team, er workshoppen Hvor giver AI mening hos os? formatet, og skal ledergruppen selv have overblikket først, er AI for ledere det korte forløb.

Kilder og videre læsning

• NIST: Artificial Intelligence Risk Management Framework 1.0, den frivillige ramme bag funktionerne Govern, Map, Measure og Manage.
• NIST AI RMF Playbook, med forslag til roller, målinger, acceptable grænser, overvågning og afvikling.
• NIST AI RMF Core, især om inventar, ansvar, kontekstnær evaluering og løbende review.
• EUR-Lex: Konsolideret AI-forordning pr. 27. juli 2026, herunder den gældende artikel 4 om at støtte udviklingen af AI-færdigheder.