Følsom tekst behøver ikke forlade jeres miljø. Vi kører sprogmodeller lokalt på infrastruktur I styrer, fx via Ollama, og bruger det selv i produktion. Det kræver stadig rigtig arkitektur, adgangsstyring og logging, og det bygger vi med.
Kort svar
En lokal AI-model kører på jeres egen server eller computer. Ingen data sendes til en ekstern tjeneste, og I kontrollerer hvilken model I bruger og hvordan den opdateres. Cloud-API'er som ChatGPT kører på udbyderens servere og betales pr. token. Lokal hosting kræver hardware-investering, men eliminerer løbende API-udgifter og datatransfer til tredjeparter.
Det vigtigste
Det afhænger af modelstørrelse og krav til svartid. Mindre modeller (7B-13B parametre) kan køre på en server med 16-32 GB RAM og en standard GPU. Større modeller kræver dedikeret GPU-kapacitet. Ollama gør det relativt enkelt at komme i gang på eksisterende server-hardware.
For mange brug: ja. Tekstopsummering, intern vidensøgning, klassificering og struktureret dataudtræk løses tilfredsstillende af moderne åbne modeller. Til opgaver der kræver avanceret ræsonnering eller bred verdensviden er de bedste cloud-modeller fortsat stærkere.
GGUF er et filformat der pakker en AI-model effektivt til lokal inferens. Kvantisering reducerer præcisionen i modelens vægte (fx fra 32-bit til 4-bit tal), hvilket halverer eller mere hukommelsesbehovet med begrænset kvalitetstab for de fleste opgaver.
Lokal model passer typisk dårligt til prototyper og tests, til opgaver der kræver de stærkeste ræsonneringsmodeller, eller når I ikke har kapacitet til at drifte og opdatere modellen internt.
Grundlag
Lokale AI-modeller betyder typisk, at I kører en lokal sprogmodel på egen hardware eller i et miljø, I selv kontrollerer, så prompts og dokumenter ikke sendes til en ekstern sky-API som standard. Det giver en klar privatlivsgrænse: I kan designe for, at følsom tekst forbliver internt, mens I stadig får generativ funktionalitet. Det er ikke magi: I skal stadig styre netværk, adgang, logging og opdateringer, ellers kan data stadig slippe ud eller gemmes forkert.
Hvad er lokale AI-modeller - og hvornår er de det rigtige valg?
En lokal AI-model er i praksis den samme type sprogmodel som bag en sky-tjeneste, men inference sker hos jer: modellen ligger som filer eller artefakter, og en runtime loader den og svarer på jeres forespørgsler. Forskel til en sky-API er primært kontrol og dataflow: ved en API sender I typisk tekst til en tredjepart, mens lokal inference kan begrænse den eksterne eksponering, fordi kernen kører internt.
Valget giver særligt mening, når dataklassen er høj, når politikker kræver korte dataveje, eller når I vil undgå vendor lock-in på prompt-niveau. Omvendt er sky ofte nemmere at skalere og kan give nyere modeller uden egen drift. Lokale AI-modeller er derfor et arkitekturvalg: I bygger et kontrolleret rum omkring modellen og accepterer mere egen drift til gengæld for bedre kontrol over data og grænseflader.
Korte punkter I kan bruge, når I taler internt om scope, risiko og drift. Sådan bygger vi det i produktion.
Følsom tekst kører på infrastruktur I styrer og forlader ikke jeres miljø. Vi kører Llama lokalt via Ollama på 127.0.0.1 i produktion, intet kundeindhold sendes til et SaaS-lag. Logs, backup og integrationer skal stadig styres.
Læs om teknologi-stackGGUF og kvantisering er almindelige valg, når modellen skal matche tilgængelig GPU- eller CPU-kapacitet. Ollama loader vægten og eksponerer et internt API til jeres applikationer.
Se lokal AI-infrastrukturLette lokale modeller løser opsummering, intern søgning og klassificering hvor privatliv og økonomi afgør. Til tungt ræsonnement vælger vi en tung model. Ingen leverandørlås, valget følger opgaven.
Sammenlign lokal og cloudIntern drift fjerner ikke dokumentations- og kontrolkrav alene. Vi koder reglerne ind som grænser systemet ikke kan bryde og kobler dem til jeres faktiske brugsscenarie, ikke som eftermontering.
AI, sikkerhed og GDPRSkift fokus mellem teknisk runtime, performance og typiske compliance-faldgruber.
Lokal inference starter med en modelvægt i et format, jeres runtime forstår. I open source-miljøer ser man ofte formater som GGUF sammen med kvantisering, så modellen kan køre på realistisk GPU- eller CPU-kapacitet uden at være fuld præcision på alle lag. Runtime-laget (for eksempel et self-hosted LLM-setup) står for at loade modellen, håndtere kontekstvindue, batching og streaming af tokens, og at eksponere et API til jeres applikationer.
Drift handler derefter om det kedelige, men afgørende: versionering af modeller, rollback, miljøer (test/produktion), backup af konfiguration og hemmeligheder, samt netværkssegmentering så inference ikke utilsigtet bliver et internt åbent endpoint. For enterprise LLM on-prem er containerisering almindeligt, fordi det gør reproducerbare builds og letter patch-cykler. Air-gapped AI er en skærpet variant, hvor netværket bevidst isoleres, men så skal I også have en plan for sikker modeldistribution og signering.
Kvalitet og hastighed afhænger først og fremmest af modelstørrelse, finjustering og hvor aggressiv kvantisering I accepterer: mindre og mere komprimerede modeller kan være hurtige, men miste nuance i komplekse opgaver. Hardware spiller ind via GPU-hukommelse og beregningsenheder til matrixoperationer; CPU-inference kan fungere til lettere opgaver, men tunge workloads belaster typisk GPU.
Omkostninger er ikke kun licenser: det er strøm, køling, rack, reserved capacity og tid til vedligehold. On-device inference på kraftfulde arbejdsstationer kan være fint til visse workflows, mens centraliseret hosting samler GPU-udnyttelse bedre. Når I sammenligner med cloud, er trade-offs anderledes: I betaler mindre pr. token til en ekstern API, men mere i intern drift og kapital til udstyr, hvis I går lokalt.
Den største misforståelse er at tro, at "lokalt" automatisk betyder "ingen data forlader virksomheden". Lokal inference reducerer eksponering mod tredjeparts-API, men integrationer til andre systemer, logging, backup, supportværktøjer og brugeradfærd kan stadig skabe dataflows. Datasuverænitet ved sprogmodeller handler derfor om hele kæden: identitet, adgang, netværk, retention og monitorering.
En anden fejl er at antage, at GDPR og EU AI Act-problemer forsvinder, fordi modellen kører internt. Dokumentation, risikovurdering, procedurer for menneskelig kontrol og korrekt databehandling kan stadig være påkrævet afhængigt af brugsscenariet. Endelig ser man ofte undervurdering af sikkerhed omkring selve modellaget: en stor modelfil kan indeholde rester af træningsdata og skal beskyttes som andre aktiver med høj værdi.
Start småt med ét scenarie og klare succeskriterier.
Skær miljøer til, og gør drift målbar.
Hold hub-indhold adskilt fra dybdegennemgang.
Playbook
Start med en afgrænset pilot: ét brugsscenarie, ét miljø, klare succeskriterier for kvalitet og latency, og en simpel governance-pakke (roller, nøgler, logning). Ollama kan fungere som et praktisk runtime- og komfortlag til lokale modeller i pilotfasen, fordi det sænker friktion for udviklere, men det løser ikke automatisk enterprise-krav til miljøseparation, observability og politikker.
Når piloten holder, flytter I typisk mod mere kontrolleret drift: segregerede netværk, secrets management, metrics og tracing på inference, samt faste processer for modelvalidering og opdatering. Herfra linker I naturligt videre til jeres bredere teknologiside for overblik og til dedikerede sider for sammenligning og infrastruktur, når læseren er klar til næste beslutning.
Vælg et format runtime forstår, og dokumentér version, checksum og hvor vægten må ligge. Modelfilen behandles som et aktiv med høj værdi.
Lokal inferens kører på infrastruktur I styrer, fx 127.0.0.1, ikke som et bredt internt endpoint. Segmentér og begræns adgang efter behov, så data ikke siver via integrationer.
Behandl secrets som produktionsdata: rotation, backup og adskilte miljøer for test og prod. Konfiguration versioneres så ændringer kan rulles tilbage.
Mål latency, fejl og ressourceforbrug, så I kan forklare drift og finde regressions hurtigt. Hver ændring verificeres før og efter.
Kobl brugsscenarie til dokumentation og kontrol: roller, logning og retention skal kunne forklares som grænser, ikke som standardindstillinger I arvede.
Brug kortene som tjekliste i workshoppen med juridisk, IT-sikkerhed og produkt. Lokal inferens er udgangspunktet, men hele kæden skal sidde rigtigt.
Lokal model holder følsom tekst internt og fjerner sky-API-eksponeringen, vi kører selv Llama via Ollama på 127.0.0.1 i produktion. Men integrationer, logs og backup kan stadig skabe dataforløb der skal styres.
Prompts og svar kan stadig logges eller replikeres, hvis I ikke styrer retention. Definer eksplicit hvad der gemmes og hvor længe.
Intern drift ændrer ikke automatisk dokumentations- og kontrolkrav. Reglerne kodes ind som grænser knyttet til det konkrete scenarie, ikke antaget løst af modelplaceringen.
Store modelfiler skal beskyttes som værdifulde aktiver, inklusive adgang og opbevaring. En vægt kan indeholde rester af træningsdata.
Ikke en garanti for jeres program, men et mønster enterprise-team ofte følger.
Vælg ét scenarie, definer kvalitetskrav og mål latency i et kontrolleret miljø.
Kør modellen med realistisk datavolumen, og dokumentér fejl, omkostninger og flaskehalse.
Indfør segregering, secrets management og observability, så drift kan gentages og auditeres.
Fastlæg hvordan modeller opdateres, rulles tilbage og testes før produktion.
Korte svar I kan bruge i sikkerheds- og arkitekturmøder.
Tre dybe sider plus teknologi-hubben, så I kan linke i stedet for at duplikere indhold.
Når I skal sammenligne arkitekturvalg, dataflow og omkostningsmodeller mellem lokalt og sky.
Når runtime, hosting og enterprise-krav skal omsættes til konkret setup og drift.
Når I skal koble dokumentation, kontrol og regulatoriske krav til jeres AI-brug.
Overblik over enterprise AI-stack og næste skridt, når læseren er klar til at zoome ud.
Korte updates om arkitektur, sikkerhed og drift - uden hype og uden fyld.
Vi sender en bekræftelses-e-mail. Du kan altid afmelde dig igen.
Vi bruger kun mailen til nyhedsbrevet. Afmeld når som helst.
Følsom tekst behøver ikke forlade jeres miljø. Vi bygger og driver lokal inferens på infrastruktur I styrer, fx Llama via Ollama, med den rigtige model til opgaven og compliance kodet ind fra start. Vi bruger det selv i produktion.
