Hvorfor danske virksomheder begynder at trække AI hjem igen

I de sidste par ar 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, ogsa 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 losning.

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

Nar du sender data til en ekstern AI-tjeneste, afgiver du ikke nodvendigvis ejerskab, men du afgiver kontrol.

Sporgsmalene 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 sporger?

I en dansk kontekst er det ikke teoretisk.

Offentlige organisationer og mange private virksomheder arbejder med personfolsomme oplysninger, kontraktuel fortrolighed og regulatoriske krav, ofte pa samme tid.

Selv hvis leverandoren 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-losning er afhængig af en amerikansk leverandor, 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 sporgsmalet ikke:

"Virker det?"

Men:

"Har vi kontrol, ogsa om 3 ar?"

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 foresporgsler. Dokumentbehandling med store mængder tekst. Lobende automatisering. Samlet kan det nemt lobe op i et fem- eller sekscifret belob om maneden, for noget der startede som en POC. Med lokale modeller eller dedikeret infrastruktur ændrer okonomien sig: hojere 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 leverandoren.

For ikke-kritiske use cases er det acceptabelt.

Men nar AI bliver en del af kerneprocesser, som sagsbehandling, kundeservice og interne beslutningsværktojer, er det et andet billede. Du kan ikke bygge stabile systemer oven pa noget, du ikke kan kontrollere.

Problem 5: Strategisk afhængighed

Den mest oversete faktor er lock-in.

Nar du forst har bygget workflows, integrationer, prompts og datamodeller omkring en leverandor, er det dyrt at skifte. Ikke teknisk svært, men organisatorisk tungt.

Og i en europæisk kontekst er sporgsmalet ved at blive uundgaeligt:

Skal en central del af vores forretning afhænge af en ekstern AI-leverandor?

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 nodvendigvis, at alt skal kore 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 folsomme 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 gore 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 ma forlade organisationen?
• Hvilke use cases kræver lav latency?
• Hvor er omkostningerne kritiske?
• Hvor er afhængighed acceptabel?

Nar du svarer pa de sporgsmal, bliver losningen tydelig.

Konklusion

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

Men det er ikke nodvendigvis den rigtige langsigtede losning 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 sta pa mal for, ikke kun hvad der virker i dag.