Hvorfor infrastrukturen afgør succes eller fiasko
Det kender du sikkert: Direktøren kommer begejstret tilbage fra det nyeste AI-foredrag. “Vi skal også have sådan en chatbot!”, lyder det. Marketingafdelingen drømmer om automatiseret indholdsgenerering. Og du som IT-ansvarlig? Du stiller det egentlige, vigtige spørgsmål: “Kører det overhovedet stabilt på vores nuværende infrastruktur?”
Et helt legitimt spørgsmål. For mens standardbrug af værktøjer som ChatGPT eller Microsoft Copilot ofte er ret ukompliceret, bliver det hurtigt komplekst, hvis der skal bygges individuelle AI-løsninger. Hovedudfordringen? Det handler som regel om den eksisterende IT-infrastruktur.
Årsagen er klar: AI-applikationer stiller helt andre krav end klassiske software-systemer. Hvor et ERP-system håndterer strukturerede transaktioner, arbejder et AI-system med enorme mængder ustrukturerede data – ofte næsten i realtid.
Endnu tydeligere: Den veletablerede IT-landskab, der hidtil har fungeret upåklageligt, når hurtigt sine grænser med AI-workloads. Det skyldes ikke dårlig arkitektur – men at der gælder andre spilleregler.
I en aktuel Bitkom-undersøgelse (2024) angiver to tredjedele af adspurgte virksomheder – i SMV-segmentet endda over 70 procent – at manglende tekniske forudsætninger forsinker eller blokerer deres AI-projekter. Det bør ikke overraske, når man ser på kravene.
Men hvad er egentlig så anderledes? Der er især tre faktorer, der skal gøre din infrastruktur klar til AI:
Beregningstunge workloads: Moderne AI-modeller kræver enorm parallelt regnekraft. Med CPU-optimerede servere rammer du hurtigt fysiske grænser.
Datahungrende systemer: Jo flere data, desto bedre lærer AI-systemet. Det kræver avancerede lagrings- og overførselsveje – langt udover klassiske databaskrav.
Krav om realtid: Brugere forventer svar på få sekunder – helst øjeblikkeligt. Høj latenstid er som grus i maskineriet – irriterende og ineffektivt.
Den gode nyhed: Du behøver ikke udskifte hele infrastrukturen. Med fokus på de reelle krav – og nogle målrettede justeringer – kan du få langt mere AI-kompetence ud af dine eksisterende systemer, end du måske tror i dag.
De fire søjler i et AI-klar IT-infrastruktur
En stabil AI-infrastruktur hviler på fire søjler. Hver søjle er essentiel – overses én, bliver den hurtigt en flaskehals for projektet. Lad os se nærmere på dem:
Beregningseffekt og hardwarekrav
I modsætning til klassisk software er AI-workloads massivt paralleliserede. Mens regnskabet stille og roligt behandler datasæt for datasæt, fyrer machine learning-algoritmer tusindvis af beregninger af på én gang.
Det gør grafikkort (GPU’er) uundværlige. Markedsledere som NVIDIA sætter standarten med modeller som A100, H100 eller RTX-serien. En enkelt NVIDIA A100 giver beregningseffekt, som tidligere krævede hele serverracks.
Men vær opmærksom: Ikke alle GPU’er er ens! Til inference (model-afvikling) rækker entry-level GPU’er (fx NVIDIA T4), mens træning af egne store modeller som regel kræver high-end kort som H100. Edge-løsninger fra fx Google (Coral TPU) eller Intel (Movidius) har desuden effektive specialtræk til decentral brug.
Hvad med RAM? Store modeller kræver sit: For eksempel har et lokalt LLM som Llama 2 med 70 milliarder parametre brug for nemt 140 GB RAM – og det er vel at mærke kun for tekstbehandling.
CPU’en er stadig arbejdshesten til data-forberedelse, -efterbearbejdning samt systemadministration. Specielt CPU’er med mange kerner og rigeligt PCIe-lanes anbefales i AI-sammenhæng – fx AMD EPYC eller Intel Xeon Scalable.
Dataarkitektur og storage-systemer
AI er datahungrende – og på sin helt egen måde. Klassiske ERP-systemer gemmer strukturerede tabeller i databaser; AI-modeller sluger alle slags information: Tekst, billeder, lyd, video.
Det kræver mere fleksible storage-arkitekturer. Object storage (fx Amazon S3 eller Azure Blob) har etableret sig som ny standard. On-premise miljøer vælger ofte løsninger som MinIO. Vigtigt: Arkitekturen skal være praktisk talt ubegrænset skalerbar og kunne håndtere eksplosiv vækst.
Hastigheden er også kritisk: Moderne NVMe-SSD’er yder meget, men kan ikke altid følge med i massetræning. Distributed filesystems som Ceph eller GlusterFS samler ydeevne på tværs af mange drev og servere – og mangedobler dermed AI-parallelberegninger.
Hvordan ser det ud i praksis? En maskinproducent med et predictive maintenance-projekt genererer hurtigt terabytes af sensordata. Klassiske storage-løsninger får sved på panden ved store datamængder og hurtig adgang. Med objektbaserede arkitekturer og distribuerede systemer undgås disse flaskehalse.
Data-forbehandling er centralt. Data gøres AI-venlige via ETL-pipelines (Extract, Transform, Load) – Apache Kafka bruges ofte til streaming, Elasticsearch til hurtig søgning og indeksering.
En gammel AI-regel gælder stadig: “Garbage in, garbage out.” Sæt standarder for datakvalitet, typisk via data governance eller automatiserede tjekrutiner. Ethvert AI-system er afhængigt af kvaliteten i inputdata.
Netværk og konnektivitet
Det gamle server-til-bruger-princip rækker ikke langt med AI. Al slags realtids-AI – fra chatbot til dokumentanalyse – sætter netværket på prøve.
Et eksempel? Et RAG-system (Retrieval Augmented Generation) gennemgår millioner af dokumenter ved hver brugerforespørgsel. Ligger data på et NAS eller måske distribueret, bryder et klassisk netværk hurtigt sammen.
Derfor har moderne AI-infrastruktur mindst 10-gigabit Ethernet, ofte mere (25GbE op til 100GbE). InfiniBand er stadig high-performance-standarden, men ikke til hvert budget eller behov.
Kravene til lav latenstid er høje ved krævende interaktioner. Moderne switches og redundant kabling (f.eks. med LACP) er et must, ligesom systematisk overvågning. Har du geografisk spredte teams? Overvej edge-servere – det dæmper latenstid og sparer WAN-båndbredde.
Stabilitet og performance forstærkes yderligere ved lokal datalagring (edge computing) og med fokus på netværksstrukturens fejlrobusthed. Redundans er ikke kun en bonus – det er helt afgørende i AI-sammenhænge.
Sikkerhed og compliance
Med AI øges angrebsfladen. Mange af de mest spændende brugscases involverer persondata eller integreres direkte i forretningsprocesser – sikkerhed bliver altså en hovedsøjle.
GDPR kræver forklarlige beslutninger – blackbox-AI er især i regulerede segmenter kritisk. Du bør derfor sikre sporbare modeller (“Explainable AI”), eller som minimum sikre dokumentation og auditmuligheder.
Et moderne angrebsvektor: Manipulation af træningsdata (“model poisoning”). Det kan føre til alvorlige fejlafgørelser. Beskyt træningsdata med adgangsstyring og overvåg datastrømme nøje.
Obligatorisk: Kryptering både “at rest” og “in transit”. Hardware-sikkerhedsmoduler (HSM) er standard i mange datacentre. Moderne AI-GPU’er understøtter “confidential computing” – et plus, især når følsomme data er i spil.
Zero Trust er ikke blot et buzzword: Minimer adgangsrettigheder, hold produktionsdata og AI-services adskilt og kontroller alle datastrømme detaljeret. Container-orchestration (Kubernetes) og network policies kan hjælpe.
Regelmæssige sikkerhedskurser er prikken over i’et: Falske vedhæftede filer og målrettede angreb er fortsat de største adgangsveje – social engineering bør aldrig undervurderes.
AI-anvendelsestilfælde og deres specifikke krav
Der findes ikke “den ene” AI-anvendelse. Hvert use case har sine egne krav til infrastrukturen. Lad os se nærmere på de vigtigste scenarier i SMV-segmentet – og hvad du især skal holde øje med:
Chatbots og Conversational AI
Chatbots er for mange indgangen til AI – de virker simple, men gemmer på masser af kompleksitet. Flaskehalsen er typisk latenstid: Brugere forventer øjeblikkelige svar, og hver sekunds forsinkelse koster tillid.
En Google-undersøgelse viser, at sidens indlæsningstid over 3 sekunder får brugere til at forlade. For chatbots kan selv mindre forsinkelser koste konverteringer.
(Bemærk: Den nævnte Google-undersøgelse gælder for websider, ikke specifikt chatbots, men analogien er brugbar.)
Til simple FAQ-bots rækker moderne CPU’er ofte fint. Værktøjer som BERT eller DistilBERT fungerer allerede med cloud-instanser eller god serverhardware – fx er Azure D4s_v3 tilstrækkelig til mellemstore behov.
Til mere kompleks conversational AI – f.eks. med store modeller som GPT-4 – er GPU’er som NVIDIA T4 eller kraftigere et must. Et enkelt kort kan håndtere snesevis af samtidige samtaler – afhængigt af model og kontekst.
Skalering undervurderes ofte: En chatbot, der hopper fra 10 til 200 parallelle samtaler, kan overraske infrastrukturen. Auto-scaling med Kubernetes eller lignende er afgørende – og rate limiting beskytter backend-systemerne.
Klassisk udfordring: Session management. Konteksten skal bevares; Redis eller lignende in-memory stores gør hurtig adgang mulig. Problemet: Tabte chatforløb ender med frustrerede brugere og flere supporthenvendelser.
RAG-systemer (Retrieval Augmented Generation)
Hvad er RAG egentlig? Retrieval Augmented Generation kombinerer store sprogmodeller med virksomhedens egen ekspertiseviden. Arkitekturen er mere finurlig end ved traditionelle chatbots: Først finder en retrieval-engine relevante dokumenter, så genererer LLM’et et svar ud fra disse fakta.
Kernen: En vektordatabse (fx Pinecone, Weaviate, Qdrant), der gemmer tekstpassager som såkaldte “embeddings” – altså komprimerede vektorrepræsentationer. Én million embeddings kræver ca. 5 GB lager, og ved store datamængder langt mere.
Generering af embeddings kræver solid beregningskraft – normalt GPU-accelereret. I drift skal databasen kunne søge millioner vektorer på millisekunder – algoritmer som HNSW eller IVF leverer den nødvendige performance.
Eksempel fra praksis: En maskinfabrik indlæser tusindvis af tekniske dokumenter til vidensbasis. Uden specialiseret søgning tager det fem sekunder at svare brugeren. Med optimeret vektordatabse? Under 200 millisekunder.
Anvendelse: Skifter dokumenterne hyppigt? Automatiserede ETL-processer til løbende opdatering af vektorer er uundværlige – ideelt så nye og ændrede data kun delvist opdateres, fremfor at hele arkivet skal genindekseres hver gang.
En vigtig udfordring er “context window limits” for sprogmodeller. GPT-4 kan pt. maksimalt behandle 128.000 tokens på én gang – så ved større dokumentsamlinger skal du arbejde smart med “chunking” og opsummering.
Målet er, at hastighed og aktualitet ikke udelukker hinanden. Caching-løsninger øger performance og nedsætter omkostninger – Redis er også velegnet hertil.
Dokumenthåndtering og OCR
Det papirløse kontor handler ikke blot om digitaliserede arkivmapper, men om intelligent dokumentforståelse via AI. Moderne OCR-systemer (Optical Character Recognition) kombinerer fremragende tekstanalyse med strukturoverblik – tabeller, formularer og signaturer hentes automatisk.
Pointen: Computer vision-modeller kræver tung GPU-ydeevne. Et standarddokumentscanningsbillede i 300 DPI er hurtigt flere megapixel stort. Her rækker simple grafikkort ikke langt.
Tænk i workloads: Batchbehandling (fx bilag natten over) kan køres billigt på standard-GPU’er; realtidsanalyser for kunder kræver high-end-model.
Praxistip: God OCR bliver for alvor god med effektiv forbehandling. Skævheder, skygger og dårlig belysning? OpenCV-baserede pipelines retter det op. Modeller som LayoutLM analyserer endda struktur og kontekst i dokumentet – men har tilsvarende høje hardwarekrav.
Husk storage: Til både originals og udtræk passer object storage bedst – og helst med automatiseret arkivering og sletning. Virksomheder med GDPR-krav bør altid have sporbarhed og datamanagement på plads.
Predictive analytics og business intelligence
Med predictive analytics bringer du data fra i går ind i beslutningerne i dag – fra salgsprognoser til predictive maintenance. Ofte anvendes LSTM- eller transformer-modeller til tidsserier. Træningen foregår sjældent på få timer: Uger er ikke unormalt afhængig af datamængde.
Kritisk: Feature engineering – det rette udtræk og præsentation af relevante egenskaber for modellerne. Parallelisering er en fordel: Med Apache Spark kan selv meget store datamængder bearbejdes hurtigt.
Realtids-inference på fx børsdata kræver latenser under ti millisekunder – og ikke alle systemer kan det uden videre. Her kræves specialiseret infrastruktur og forståelse for, hvilke processer der skal automatiseres nu eller senere.
Praktisk eksempel: En logistiker benytter predictive analytics til miljø- og kørselsplaner. Træningen af nye modeller tager få timer på stærk hardware; den daglige drift er dog altid latenser-optimalt.
Vigtigt: Modeller mister over tid nøjagtighed, hvis datagrundlaget ændrer sig (“model drift”). Overvågning og regelmæssig retræning er et krav. Pålæggende ressourcer må også planlægges til brug af forklarbare AI-værktøjer som SHAP eller LIME – de øger transparens, men kræver egne regneressourcer.
Cloud vs. On-Premise: Tag den rigtige beslutning
For virksomheder et klassisk dilemma: Cloud eller on-prem? Begge har deres tilhængere – og gode argumenter. Det, der tæller, er din konkrete use case og risikoprofil.
Point for cloud: Du skalerer fleksibelt, betaler kun for brugen og får adgang til moderne hardware – uden store investeringer. AWS, Azure & co. tilbyder GPU-instanser fra få euro i timen – perfekt til tests og pilotprojekter.
Pas dog på omkostningseksplosioner: Konstant drift i cloud kan blive bekosteligt. En stor GPU-instans kan koste lige så meget per måned som køb af en ny server – ved høj, kontinuerlig belastning kan on-premise svare sig over tid.
Latenstid og databeskyttelse vejer tungt. Selv den bedste GPU-instans hjælper ikke, hvis dine data befinder sig i et andet land eller ikke må ud pga. GDPR. Tjek tilgængelighed og compliance-scenarier tidligt.
Hybride løsninger giver fleksibilitet: Sårbare applikationer kører internt, spidsbelastninger flyttes dynamisk til cloud (“cloud bursting”). Det gør dog orkestreringen mere kompleks.
Edge computing giver AI-svar direkte, hvor de opstår – fx på virksomhedsområdet eller hos kunden. Det sænker latenstid og øger sikkerheden. For visse virksomheder er edge den skjulte favorit.
Ønsker du maksimal kontrol og forudsigelighed? Så er on-premise ofte vejen – inklusive ansvar for strøm, vedligehold og hardware. Moderne løsninger bruger mere og mere containerteknik, så flytning mellem cloud og egne systemer bliver lettere.
Integration med eksisterende legacy-systemer
Mange AI-projekters hæl er integrationen til eksisterende (ældgamle) systemer. Din AI kan være nok så moderne – uden data fra ERP, MES eller andet forbliver den blot et papirprojekt.
Udfordringen: Mange legacy-applikationer har ingen moderne API’er. Dataene ligger dybt i gamle databaser. Data-adgang uden at forstyrre driften kræver præcision og omtanke.
Gennemprøvet er ETL-pipelines (fx med Apache Airflow), som henter nødvendige data periodisk og kontrolleret. Læse-adgange til databasen beskytter produktionssystemerne, mens message queues som Apache Kafka skaber asynkron kobling mellem gammelt og nyt.
Praxistip: Brug af veldefinerede grænseflader og foretræk gradvise, små moderniseringsskridt (mikroservice-arkitektur) fremfor et stort lift-and-shift. Change Data Capture (CDC) kan overføre data i realtid – også fra ældre databaser.
Mellemlagring af ofte brugte data via Redis eller Memcached aflaster legacy-verdenen. Overvågning og rollback-mekanismer er et must – nedbrud og overraskelser er hverken små eller store virksomheder glade for.
Og glem ikke: Mange gamle systemer er “datablandemaskiner”! Tjek datakvalitet og -struktur i forbehandlingen – ellers løber AI’en forgæves.
Skalering og performance-optimering
Succes for AI-projektet kræver planlægning af dets vækst. Udfordringerne er særlige: GPU-skalering er markant anderledes end for klassiske webservere.
Horisontal skalering – flere små i stedet for få store instanser – går nærmest automatisk for CPU’er. Med GPU’er er det mere komplekst og dyrere: Instanser er ikke altid klar med det samme, opstartstider kan forsinke, og “sharing” af ressourcer på én GPU er tricky.
Kubernetes og andre orkestreringsværktøjer hjælper ved at samle GPU-noder i egne puljer. Node-autoscaling styrer dynamikken, NVIDIA’s multi-instance GPU giver ressourceisolering.
Klog model-serving er alfa og omega for performance. Forudindlæste modeller på stateless services er lettere at skalere. TensorFlow Serving og TorchServe er etablerede løsninger i mange virksomheder.
Intelligent caching og load balancing er vigtigt: Round robin rækker ikke altid – routing baseret på responstid fordeler arbejdet bedre.
Batch-workloads og realtidsservices kræver forskellige optimeringer – undgå at fravige et klart driftskoncept for tidligt. Kvantisering (8/16 bit i stedet for 32) sænker både RAM-forbrug og latenstid.
Til sidst teller overblikket: GPU-belastning, model-nøjagtighed og RAM-forbrug bør overvåges kontinuerligt – fx med Prometheus og Grafana. Circuit breaker-mønstre beskytter mod dominoeffekter ved overload. Edge-caching bringer AI-svar tæt på brugeren og sænker latenstid yderligere.
Omkostnings-/nytteanalyse og budgetplanlægning
Planlægger du et AI-projekt, skal du ikke kun tænke på det mulige, men også på det betalbare. Selv små projekter kan i praksis hurtigt ramme fem- eller sekscifrede beløb – især hvis cloud-tjenester eller egen hardware er i spil.
Hardwaren er kun toppen af isbjerget: Top-GPU’er (fx NVIDIA H100) koster let 25.000 euro eller mere, men ekstraudgifter til strøm, køling og netværk løber hurtigt op (erfaring: 40–60 procent ekstra er realistisk).
Cloud-omkostninger kan eksplodere uden loft – auto-skalering bør derfor altid styres med budgetter og alarmer. On-premise udbygning kræver investerings- og afskrivningsplan, men giver mere langsigtet omkostningskontrol.
Udvikling og knowhow er andre omkostningsdrivere. Specialister er sjældne og dyre; ekstern konsulentbistand kan hjælpe – 1.000 til 2.000 euro pr. dag for erfarne folk er almindeligt, men giver hurtigere resultater og færre fejl.
Husk også licensomkostninger! TensorFlow m.fl. er open source, men licenser som NVIDIA AI Enterprise vejer tungt. Samlede omkostninger bør derfor regnes ud på mindst tre år (Total Cost of Ownership, TCO).
Satse på en trinvist tilgang – pilotprojekter med overskueligt scope (“minimum viable product”) giver hurtigt læring og sparer penge. Så bevarer du fleksibiliteten og undgår ubehagelige overraskelser.
Implementering: En praktisk køreplan
Lyder det indviklet? Det er håndterbart – med en struktureret, faseopdelt køreplan. Her er de fire vigtigste trin for at komme godt fra start med AI:
Fase 1: Assessment og proof of concept (4–8 uger)
Afprøv alle data, processer og infrastruktur: Hvad findes allerede, hvad mangler, hvor ligger de klare forretningspotentialer? Ofte er den største barriere datakvaliteten.
Et mini-proof-of-concept med hurtigt tilgængelige cloud-værktøjer (fx AWS SageMaker, Azure ML) giver omgående indblik i, om use casen fungerer.
Fase 2: Pilotimplementering (8–12 uger)
Nu gælder det: Kun en klart defineret use case med målbar målestok (fx kundeservice-chatbot) undgår ressourcespild. Managed services reducerer den indledende kompleksitet og giver erfaring, uden at investere i egen (dyr) hardware.
Implementer overvågning og succesmåling fra start: Uden brugsdata og feedback famler du i blinde.
Fase 3: Skalering og optimering (12–24 uger)
Næste skridt er målrettet udbygning. På baggrund af pilotresultater beregner du hardware og træning præcist – for store eller små systemer skader projektet på sigt.
Machine learning operations (MLOps) bliver nu afgørende. Automatisér model-deployment, backups og overvågningsprocesser. Værktøjer som MLflow eller Kubeflow giver dig overblik.
Fase 4: Drift og vedligehold (løbende)
I den sidste fase står løbende retræning og team-undervisning øverst. AI-projekter er dynamiske: Data og anvendelsesområder udvikler sig konstant. Change management og god dokumentation er nødvendigt nu.
Forretningsimpact og ROI bør løbende indsamles og kommunikeres – kun sådan undgår du, at AI-projektet ender som et mål i sig selv.
Ofte stillede spørgsmål
Hvilke minimumskrav til hardware gælder for AI-applikationer?
Til simple AI-applikationer – fx chatbots – er moderne CPU’er med 16–32 GB RAM ofte nok. Machine learning-workloads får dog et stort løft med GPU: Startniveauet er modeller som NVIDIA RTX 4090 eller tilsvarende – produktive systemer bruger typisk T4-klassen eller kraftigere. Til Large Language Models er high-end GPU’er som A100 eller H100 samt 64+ GB RAM nærmest uundværlige.
Bør vi køre AI i cloud eller on-premise?
Begge dele kan være fornuftigt: Cloudmiljøer er ideelle til eksperimenter eller varierende belastning. On-premise betaler sig ofte ved varig høj udnyttelse og hvis datakontrol er afgørende. Hybridmodeller giver fleksibilitet – fx hvis følsomme data skal forblive internt, mens tunge beregninger flyttes til cloud.
Hvordan integrerer vi AI med eksisterende legacy-systemer?
Ofte benyttes ETL-pipelines og eventbaseret messaging (fx Apache Kafka). API-grænseflader er optimale, men mangler tit i ældre systemer. Som mellemtrin kan man bruge database-replikering eller event-streaming. På lang sigt anbefales en mikroservice-arkitektur, der skiller gamle systemer og nye AI-komponenter ad.
Hvilke sikkerhedsrisici medfører AI-systemer?
AI øger angrebsfladen – fx ved angreb på træningsdata eller målrettet manipulation (“model poisoning”). Adversarial attacks er en reel risiko, især for billeddata. Zero trust-principper, kryptering af alle dataflows og regelmæssige audits af anvendte modeller og datagrænseflader er afgørende. GDPR kræver, at beslutninger forbliver gennemsigtige.
Hvilke omkostninger skal vi forvente?
Proof-of-concepts starter ofte i området 10.000–20.000 euro. Et produktivt system kan hurtigt runde 50.000–200.000 euro – afhængigt af hardware, licenser og ekspertbemanding. En high-end GPU som H100 koster fra 25.000 euro og op; strøm, køling og licenser skal også medregnes.
Hvor lang tid tager AI-implementering?
Proof of concepts kan laves på 4–8 uger, pilotprojekter tager typisk 2–3 måneder. Komplekse machine learning-systemer kræver – især ved omfattende dataforberedelse – seks måneder eller længere. Datakvaliteten er ofte den afgørende faktor for tidsplanen, ikke selve udviklingen.
Hvilke medarbejderkompetencer er nødvendige?
I starten rækker ofte eksterne eksperter eller eksisterende IT-specialister med data- og API-erfaring. Python-kundskaber er en fordel, men ikke et krav fra begyndelsen. På sigt er erfaring med anvendte cloud-platforme, dataarkitektur og MLOps vigtig – men AI-specialister behøver ikke nødvendigvis være til stede fra dag ét.
