Hvorfor danske virksomheder begynder at trække AI hjem igen

I de sidste par år har standardtilgangen været simpel: Vil du arbejde med AI? Brug en cloud-API.

Det er hurtigt. Det virker. Og det kræver minimal intern opbygning.

Men noget er ved at ændre sig, også i Danmark.

Flere virksomheder og offentlige organisationer revurderer nu den model. Ikke fordi cloud-AI ikke fungerer. Men fordi den, i praksis, ikke passer til de krav, de faktisk opererer under.

Det handler ikke om principper. Det handler om kontrol.

Cloud-first AI var det oplagte valg

Det giver mening, hvorfor cloud blev default:

• Ingen infrastruktur
• Hurtig time-to-value
• Adgang til de bedste modeller
• Lav initial investering

For mange use cases er det stadig den rigtige løsning.

Men det er en optimering for hastighed, ikke for drift. Og det er præcis der, problemerne begynder at vise sig.

Problem 1: Data forlader din kontrol

Når du sender data til en ekstern AI-tjeneste, afgiver du ikke nødvendigvis ejerskab, men du afgiver kontrol.

Spørgsmålene bliver hurtigt konkrete:

• Hvor bliver data behandlet?
• Bliver de brugt til træning?
• Hvordan dokumenterer du det?
• Hvad siger du til en kunde eller en myndighed, der spørger?

I en dansk kontekst er det ikke teoretisk.

Offentlige organisationer og mange private virksomheder arbejder med personfølsomme oplysninger, kontraktuel fortrolighed og regulatoriske krav, ofte på samme tid.

Selv hvis leverandøren giver gode svar, er det stadig dig, der hæfter.

"Vi sender det til en API" er ikke et tilstrækkeligt svar, hverken til en tilsynsmyndighed eller en kunde.

Problem 2: Data residency er ikke bare en formalitet

EU og Danmark har en tydelig retning: data skal kunne kontrolleres.

Det handler ikke kun om, hvor data fysisk ligger, men om jurisdiktion, adgang og afhængigheder.

Hvis din AI-løsning er afhængig af en amerikansk leverandør, er det ikke kun et teknisk valg. Det er et strategisk valg.

Det bliver især tydeligt i offentlige udbud, finansielle virksomheder og virksomheder med kritisk infrastruktur. Her er spørgsmålet ikke:

"Virker det?"

Men:

"Har vi kontrol, også om 3 år?"

Problem 3: Omkostninger skalerer forkert

Cloud-AI ser billigt ud i starten.

Men omkostningsmodellen er designet til at skalere med brug: pris per token, pris per request, pris per feature.

Det er fint til eksperimenter. Men i drift bliver det uforudsigeligt.

En intern chatbot med tusindvis af daglige forespørgsler. Dokumentbehandling med store mængder tekst. Løbende automatisering. Samlet kan det nemt løbe op i et fem- eller sekscifret beløb om måneden, for noget der startede som en POC. Med lokale modeller eller dedikeret infrastruktur ændrer økonomien sig: højere upfront cost, men lav og forudsigelig marginal cost. Det giver kontrol over budgettet og eliminerer afhængigheden af en prismodel, du ikke bestemmer.

Problem 4: Latency og stabilitet

Cloud-AI introducerer en afhængighed, du ikke styrer: netværk, rate limits, API-ændringer, nedetid hos leverandøren.

For ikke-kritiske use cases er det acceptabelt.

Men når AI bliver en del af kerneprocesser, som sagsbehandling, kundeservice og interne beslutningsværktøjer, er det et andet billede. Du kan ikke bygge stabile systemer oven på noget, du ikke kan kontrollere.

Problem 5: Strategisk afhængighed

Den mest oversete faktor er lock-in.

Når du først har bygget workflows, integrationer, prompts og datamodeller omkring én leverandør, er det dyrt at skifte. Ikke teknisk svært, men organisatorisk tungt.

Og i en europæisk kontekst er spørgsmålet ved at blive uundgåeligt:

Skal en central del af vores forretning afhænge af en ekstern AI-leverandør?

Flere danske organisationer begynder at svare "nej", eller i det mindste "ikke alene".

Hvad det konkret betyder at trække AI hjem

At tage kontrol over sin AI-infrastruktur betyder ikke nødvendigvis, at alt skal køre i eget datacenter, eller at man bygger egne modeller fra bunden.

Det betyder mere kontrol over dataflow, mulighed for at vælge, hvor computation sker, og fleksibilitet i arkitekturen.

Typisk ser man hybride setups: lokale modeller til følsomme data, cloud-modeller til generelle opgaver og klare grænser mellem de to. Det er ikke ideologisk. Det er pragmatisk, og det er præcis den type arkitektur, vi hos Liviate hjælper med at bygge og drifte.

Hvor det giver mening i Danmark

Denne bevægelse er særligt tydelig i tre segmenter:

Fællesnævneren er ikke teknologi. Det er ansvar.

Den rigtige tilgang er ikke enten/eller

Det er let at gøre det til et ideologisk valg: "Cloud er fremtiden" eller "Alt skal være lokalt." Begge dele er forsimplet.

Den rigtige tilgang er arkitektonisk:

• Hvilke data må forlade organisationen?
• Hvilke use cases kræver lav latency?
• Hvor er omkostningerne kritiske?
• Hvor er afhængighed acceptabel?

Når du svarer på de spørgsmål, bliver løsningen tydelig.

Konklusion

Cloud-AI var, og er, en vigtig accelerator.

Men det er ikke nødvendigvis den rigtige langsigtede løsning for alle.

I Danmark begynder flere organisationer at indse, at kontrol er vigtigere end hastighed, at forudsigelighed er vigtigere end fleksibilitet, og at ansvar ikke kan outsources.

Det betyder ikke, at man skal droppe cloud. Det betyder, at man skal tage arkitekturen alvorligt.

Og infrastruktur vælger man ud fra, hvad man kan stå på mål for, ikke kun hvad der virker i dag.