AI-sprawl i danske SMV’er er ikke et AI-problem. Det er et problem med ejerskab af økonomi og risiko.

Giv dygtige mennesker et stærkt tool, og de bruger det. Den del er forudsigelig.

Det, der også er forudsigeligt, men sjældnere bliver talt om, er hvad der sker bagefter: Ét tool bliver til ti tools. Så tyve. Licenser sniger sig ind på udgiftsrapporter. Følsom tekst bliver kopieret ind i prompts. Teams bygger små workflows, som ingen nogensinde reviewer. Ingen gør det for at være illoyal. Ingen laver “shadow IT” med vilje. De prøver bare at få arbejdet fra hånden.

Derfor overrasker det mig ikke, at hver anden dansk SMV har mistet kontrollen over sin egen AI-brug, eller at hver tredje virksomhed med en AI-strategi stadig ikke kan styre brugen. Overskriften rammer det som en ledelsesfejl. Enig. Bare ikke i moralsk forstand. Det er en designfejl.

De fleste virksomheder forsøger at løse AI-sprawl med politikker og træning. Det er nødvendigt, men ikke tilstrækkeligt. Flaskehalsen er operating model: Hvem ejer spend, hvem ejer risikoen, og hvad “godt” betyder i form af målbart output.

Mønstret bag AI-sprawl: mindste modstands vej vinder

AI-sprawl er ikke et mysterium. Det er et naturligt resultat af tre incitamenter, der rammer hinanden.

• Medarbejdere belønnes for tempo, ikke tool-hygiejne. Hvis en ny assistent sparer 30 minutter i dag, bliver den taget i brug i dag.
• Budgetter er fragmenterede. Hvert team har lidt råderum, så ingen ser totalen, før det bliver pinligt.
• Risiko er abstrakt, indtil den ikke er det. Datalæk og compliance-problemer føles teoretiske lige indtil første incident eller audit.

Læg det sammen, og du får præcis det, artiklen om danske SMV’er beskriver: Medarbejdere vælger deres egne tools, mens ledelsen ikke kan se, kontrollere eller standardisere brugen – selv når der på papiret findes en “strategi”.

Her er en enkel tommelfingerregel: Hvis du ikke kan svare på “hvem ejer regningen” og “hvem kan slukke for det” på fem sekunder, så har du ikke styret noget. Du har bare dokumenteret intentioner.

Stop med at kalde det “AI-strategi”, når det i praksis er procurement + sikkerhed + produktivitet

Mange AI-udrulninger fejler stille, fordi de behandles som et tech-valg eller et innovationsinitiativ. I praksis ligger daglig AI-brug meget tættere på tre funktioner, der skal arbejde sammen:

• Procurement: hvilke tools der er tilladt, på hvilke kontraktvilkår, og med hvilke fornyelses- og exit-betingelser.
• Sikkerhed og data governance: hvad der må deles, hvor det må behandles, og hvad der skal logges.
• Produktivitetsstyring: hvilke outcomes du forventer, og hvordan du måler, om tools fortjener deres plads.

Kører du de tre spor som separate samtaler, får du sprawl. Kører du dem som ét system, får du akkumulativ læring og lavere risiko.

Det er også derfor, jeg bedre kan lide rammen “tab af kontrol” end “manglende AI-adoption”. Adoption er ikke længere den knappe ressource. Sammenhængende brug er.

Jeg har tidligere skrevet, at sovereign compute er et operating model, ikke et vendor-swap. AI i SMV’er er samme type problem. Tools er den synlige overflade. Ejerskab og proces er maskineriet nedenunder.

Den enkleste løsning, der virker: udpeg en AI spend owner

Den største fejl, jeg ser, er at behandle AI-omkostninger som “for små til at styre”. Det var rigtigt, da det var ét pilotprojekt. Det holder op med at være rigtigt, når AI bliver den default måde, folk skriver, opsummerer, koder, designer og analyserer på.

Så her er min direkte anbefaling: udpeg en AI spend owner. Én person, der er accountable for den samlede regning og den samlede værdi. Ikke som gatekeeper for hver prompt, men som den person, der gør trade-offs synlige.

Denne ejer gør tre ting konsekvent:

1. Definerer det tilladte tool-sæt (og processen for at tilføje et nyt).
2. Definerer dataklasser og hvilke klasser der må bruges i hvilke tools.
3. Kører en månedlig review, hvor spend holdes op mod målbart output – samt security posture.

Det er det. Ingen teater. Intet “center of excellence”, medmindre I er store nok til reelt at retfærdiggøre det. Bare accountability koblet til penge og risiko.

Et konkret eksempel. Jeg har set et cloud tool-økosystem eksplodere i en product-organisation, fordi hvert team optimerede lokalt. Det tog et kvartal at opdage, at vi havde tre overlappende kontrakter, inkonsistent access control og nul fælles logging. Den tekniske del kunne løses på få uger. Oprydningen tog måneder, fordi ingen med troværdighed kunne sige: “Det her er den ene godkendte vej, og her er regningen, hvis vi ikke konsoliderer.” Den dag vi udpegede én ejer for spend og én ejer for data-grænsen, ændrede samtalerne sig. Ikke magisk. Men målbart.

Definér “allowed tools” og “data classes”, som om du mener det

De fleste AI-politikker fejler, fordi de enten er for vage (“vær forsigtig med følsomme data”) eller for restriktive (“brug aldrig AI”). Du har brug for noget, der kan håndhæves.

1) Allowed tools (en kort liste – ikke et leksikon)

Lav en tiered liste:

• Tier A (default): godkendt til generel brug, integreret med SSO, logget og med klare kontraktvilkår.
• Tier B (restricted): tilladt for specifikke roller eller projekter med ekstra kontroller.
• Tier C (blocked): ikke tilladt pga. datahåndtering, manglende enterprise controls eller uklare vilkår.

Sig ikke “perfekt”. Sig “tydeligt”. Folk følger regler, de kan huske.

2) Data classes (fem er typisk nok)

Definér et lille antal kategorier. For eksempel:

• Public: marketingtekster, publicerede dokumenter.
• Internal: ikke-følsom driftsinformation.
• Confidential: kundedetaljer, priser, kontrakter, interne tal.
• Regulated: alt med særlige juridiske forpligtelser.
• Secrets: credentials, private keys, sikkerhedsdetaljer.

Lav derefter en klar matrix: Hvilken dataklasse er tilladt i hvilken tier af tool. Hvis “confidential” kun er tilladt i Tier A, bliver det enkelt at kommunikere og håndhæve.

Hvis du vil have en mental model: Tænk på det som jeres AI-version af “hvad der må stå i en email”. Alle forstår allerede, at nogle ting ikke hører hjemme i den forkerte kanal.

Mål output, ikke entusiasme: produktivitetskontrakten

AI-adoption er nem at fejre, fordi det ligner aktivitet. Det, du har brug for, er en produktivitetskontrakt, der omsætter brug til outcomes.

Vælg få workflows, der betyder noget, og mål dem før og efter. Ikke alt. Bare de steder, hvor tid og kvalitet er synlige.

• Salg: tid til første udkast af et tilbud, konvertering på outbound-sekvenser, tid fra lead til kvalificeret opportunity.
• Kundeservice: tid til første svar, løsningstid, deflection rate, eskaleringsrate.
• Engineering: cycle time for små ændringer, defect leakage, tid brugt i code review.
• Finance og ops: tid til closing, afstemningsindsats, exception handling-rater.

Målet er ikke at bevise, at AI “virker”. Målet er at lære, hvor det betaler sig, hvor det skaber nye risici, og hvor det i praksis bare er underholdning med et abonnement.

Det er også her, mange virksomheder går i demo-fælden. En demo viser mulighed. Et workflow viser accountability. Hvis du vil have et dybere mønster for at omsætte AI til leveret capability, så slår en playbook en demo.

Kør det månedligt: en let governance-kadence

Governance behøver ikke være tungt. Det skal være hyppigt nok til, at drift bliver fanget tidligt.

Her er en månedlig kadence, der virker for mindre virksomheder uden at kvæle initiativ:

• Spend review: samlet AI spend pr. tool og pr. team, nye abonnementer, fornyelser de næste 60 dage.
• Tool exceptions: hvem bruger ikke-godkendte tools og hvorfor; beslut om at godkende, erstatte eller blokere.
• Data boundary incidents: rapporterede policy-brud, near misses eller uklare cases, der kræver en bedre regel.
• Output metrics: 2 til 5 workflow-metrics, trendlinjer, hvad ændrede sig, og hvad testes næste måned.
• Kill list: tools eller pilots der skal lukkes, med en konkret dato.

Det er den del, de fleste virksomheder undgår. At lukke ting føles som at indrømme fiasko. I praksis er det sådan, du holder læring billig.

Endnu et link til samme tema fra en anden vinkel: procurement uden exit-ramper er sådan AI-omkostninger bliver permanente, selv når værdien aldrig materialiserer sig.

Min holdning: fri leg er fint i to uger – derefter skal der et system til

Jeg er ikke imod eksperimenter. Lad folk afprøve. Det er sådan, du finder de overraskende use cases.

Men udforskning har en halveringstid. Efter den første bølge bliver ustyret brug til tre reelle omkostninger:

• Finansielt: dobbeltabonnementer, uklare fornyelser og en regning, ingen kan forklare.
• Sikkerhed og compliance: data ender steder, det ikke burde, og du kan ikke dokumentere, hvad der skete.
• Organisatorisk: folk lærer forskellige tools, bygger inkompatible arbejdsformer, og I mister genbrug.

Så ja, kald det en ledelsesfejl, hvis du vil. Jeg vil kalde det noget mere handlingsorienteret: en ejerskabsfejl.

Udpeg en AI spend owner. Definér allowed tools. Definér data classes. Review månedligt. Mål output. Luk det ned, der ikke fortjener sin plads.

Sådan holder du AI nyttigt, sikkert og økonomisk forsvarligt. Ikke ved at bede medarbejdere om at selv-govern et procurement- og sikkerhedsproblem med gode intentioner.