Hvad er lokal AI?

Lokal AI er kunstig intelligens, der kører på brugerens egen enhed, server eller private infrastruktur i stedet for at sende hele opgaven til en ekstern cloudtjeneste. Valget kan give lavere latenstid og mere datakontrol, men kræver lokal hardware, drift, sikkerhed og modelstyring.

Hvordan adskiller lokal AI sig fra cloudbaseret AI?

Lokal AI adskiller sig først og fremmest ved, hvor modellen køres. I en cloudbaseret løsning sendes input typisk til en ekstern tjeneste, hvor modellen behandler opgaven og sender et svar tilbage. I en lokal løsning sker hele eller en væsentlig del af behandlingen på en computer, telefon, lokal server, intern GPU-maskine eller anden infrastruktur, som brugeren eller organisationen selv kontrollerer.

Forskellen handler ikke kun om geografi. En model kan køre i en privat cloud, i et datacenter tæt på brugeren eller på en bærbar computer. Det afgørende er, hvem der kontrollerer miljøet, hvor data behandles, og hvilke eksterne tjenester der indgår. Lokal AI kan derfor ligge på en skala fra ren on-device behandling til hybrid arkitektur, hvor følsomme trin holdes lokalt, mens mindre følsomme opgaver behandles eksternt.

Cloudbaseret AI giver ofte adgang til større modeller, højere beregningskapacitet og hurtigere produktopdateringer. Lokal AI giver til gengæld mere direkte kontrol over dataflow, netværksafhængighed, driftspolitik og modelversion. Derfor er valget sjældent et spørgsmål om, hvad der teknisk er bedst i alle tilfælde, men om hvilket driftsmønster der passer til opgaven.

Hvilke typer lokal AI findes der?

Lokal AI dækker flere tekniske mønstre. Den enkleste form er on-device AI, hvor modellen kører direkte på telefon, pc, tablet eller indlejret enhed. Det bruges for eksempel til billedklassifikation, talegenkendelse, tastaturforslag, oversættelse, dokumentanalyse eller mindre generative opgaver. Fordelen er, at systemet kan reagere tæt på brugeren og ofte fortsætte med begrænset netværk.

En anden type er lokal server-AI, hvor en organisation kører modeller på egne servere eller interne GPU-maskiner. Her kan flere brugere dele samme modelmiljø, mens data holdes inden for organisationens kontrollerede infrastruktur. Det kan være relevant til interne søgesystemer, dokumentanalyse, embeddings, kundesupportkladder, kodeassistenter eller automatiseret kategorisering.

En tredje type er specialiseret edge-AI, hvor modellen kører tæt på sensorer eller arbejdsprocesser. Det kan være kvalitetskontrol i produktion, kameraanalyse, lydklassifikation, energistyring eller andre opgaver, hvor data opstår uden for et klassisk kontormiljø. Begrebet overlapper med AI edge computing, men lokal AI kan også bruges på almindelige kontorcomputere uden at være et egentligt edge-projekt.

Der findes også lokale tilpasninger af modeller. En organisation kan bruge egne datasæt til evaluering, retrieval, embeddings eller fine-tuning af sprogmodeller. Lokal drift betyder dog ikke automatisk, at modellen er trænet lokalt. Mange lokale løsninger bygger på en model, der først er udviklet eksternt og derefter downloadet, tilpasset eller pakket til intern brug.

Hvornår giver lokal AI praktisk mening?

Lokal AI giver mest mening, når opgaven har et konkret behov for lav latenstid, høj tilgængelighed, datakontrol eller stabil pris pr. forespørgsel. Hvis en medarbejder skal have et svar uden mærkbar ventetid, eller hvis en sensor skal reagere i realtid, kan lokal behandling være mere robust end en rundtur til en ekstern tjeneste.

Den lokale tilgang kan også være relevant, når input indeholder følsomme dokumenter, kildekode, interne kundedata, produktionsdata eller oplysninger, som ikke bør sendes til en ekstern leverandør uden særskilt vurdering. Her kan lokal AI reducere mængden af data, der forlader organisationens miljø. Det erstatter ikke adgangsstyring, dataminimering eller databeskyttelsesvurdering, men det kan gøre dataflowet lettere at afgrænse.

Lokal AI kan desuden give mere forudsigelig drift i miljøer med ustabilt netværk. Det gælder for eksempel mobile arbejdssituationer, feltarbejde, fabriksgulve, undervisningslokaler, sundhedsudstyr, butikker, køretøjer og interne værktøjer, hvor forbindelsen ikke altid kan antages at være stabil. Hvis modellen ligger lokalt, er funktionens grundlæggende tilgængelighed mindre afhængig af en ekstern API.

• Vælg lokal AI, når dataflow, latenstid eller offline-lignende drift er vigtigere end adgang til de største modeller.
• Vælg cloud-AI, når opgaven kræver maksimal modelkapacitet, hyppige modelopdateringer eller skalerbar beregning uden lokal hardwaredrift.
• Vælg hybrid AI, når opgaven både har følsomme data og behov for stærkere ekstern modelkapacitet i udvalgte trin.

Hvilke begrænsninger følger med lokal kørsel?

Lokal AI er ikke en garanti for bedre kvalitet. Mindre modeller kan være hurtige og billige at køre, men de kan have sværere ved kompleks ræsonnering, lange dokumenter, nicheviden og flersprogede opgaver. Større lokale modeller kan give bedre svar, men kræver mere hukommelse, stærkere grafikkort, optimeret runtime og mere driftserfaring.

En lokal model kan også blive forældet. Cloudmodeller opdateres ofte centralt, mens lokale modeller typisk skal hentes, testes og udrulles på ny. Hvis en organisation kører mange forskellige lokale installationer, kan versionsstyring blive et reelt driftsproblem. To medarbejdere kan få forskellige svar, hvis de bruger forskellige modelversioner, embeddings, søgeindeks eller systemindstillinger.

Derudover er lokal AI ikke nødvendigvis billigere. Hardware skal købes, strøm skal betales, runtime skal vedligeholdes, og tekniske fejl skal løses. En lokal løsning kan være økonomisk attraktiv ved mange ensartede forespørgsler, men mindre attraktiv ved svingende eller meget komplekse opgaver. Den samlede pris afhænger derfor af belastning, modelstørrelse, supportbehov og levetid.

Hvordan påvirker lokal AI data og privatliv?

Lokal AI kan mindske behovet for at sende rådata til eksterne tjenester. Det kan være en fordel, når du arbejder med fortrolige dokumenter, interne analyser, personoplysninger eller forretningskritisk viden. Fordelen er størst, når både input, modelkørsel, søgeindeks, logning og output bliver inden for det kontrollerede miljø.

Datakontrol kræver dog mere end lokal inferens. Hvis modellen henter eksterne opdateringer, sender telemetri, bruger cloudbaseret søgning, kalder tredjeparts-API’er eller gemmer logfiler usikkert, er løsningen ikke fuldt lokal i praksis. En lokal model kan også lække oplysninger internt, hvis medarbejdere får for brede rettigheder til dokumenter eller værktøjer.

Derfor bør lokal AI vurderes sammen med dataklassifikation, adgangsstyring og logpolitik. Før en model får adgang til interne dokumenter, bør du afklare, hvilke data den må indeksere, hvem der må stille spørgsmål, hvor svar logges, og hvordan fejlrettelser håndteres. Det samme gælder, når en lokal løsning kombineres med eksterne API’er; her er principperne fra databeskyttelse ved brug af AI-API’er stadig relevante.

Hvad betyder hardware for ydeevne og pris?

Hardware afgør, hvor hurtigt og stabilt en lokal AI-model kan køre. En CPU kan håndtere mange mindre modeller og klassiske maskinlæringsopgaver, men generative sprogmodeller bliver ofte langsomme uden acceleration. En GPU kan øge hastigheden markant, især når modellen og dens kontekst kan ligge i grafikkortets hukommelse. En NPU er specialiseret til energieffektiv AI-inferens i nyere pc’er, telefoner og indlejrede enheder.

Modelstørrelse, kontekstlængde og kvantisering er centrale faktorer. En mindre eller kvantiseret model kræver mindre hukommelse og kan køre hurtigere, men kan også miste noget præcision eller nuancering. En større model kan håndtere flere opgavetyper, men bliver dyrere at køre og sværere at udrulle bredt. Lokal AI kræver derfor en teknisk afvejning mellem kvalitet, hastighed, energiforbrug og hardwareomkostning.

Hvordan vælger du mellem lokal, cloud og hybrid AI?

Valget bør begynde med opgavens data og risikoniveau. Hvis input er offentligt eller lavrisiko, og kvaliteten fra en stor cloudmodel er afgørende, kan cloud være det mest praktiske valg. Hvis input er følsomt, eller hvis systemet skal fungere uden stabil forbindelse, bør lokal eller hybrid arkitektur undersøges tidligt.

Dernæst bør du vurdere modelkravet. Klassifikation, udtræk, simple resuméer, embeddings, standardsvar og mønstergenkendelse kan ofte klares lokalt med mindre modeller. Lange juridiske, tekniske eller forskningsmæssige analyser kan kræve større modeller, flere værktøjer eller adgang til stærkere cloudinfrastruktur. Hybrid arkitektur kan her bruge lokal forbehandling og ekstern modelkørsel på afgrænsede, rensede eller pseudonymiserede input.

Et tredje trin er drift. Lokal AI kræver ejerskab over modelvalg, opdatering, overvågning, backup, incident response og brugerrettigheder. Cloud-AI flytter noget af driftsbyrden til leverandøren, men kræver leverandørstyring, kontraktkontrol og databehandleraftaler, når personoplysninger indgår. En praktisk løsning kan derfor kombinere AI og cloud computing med lokale kontroller for de mest følsomme trin.

1. Afklar data: Hvilke input må behandles hvor, og hvilke logge må gemmes?
2. Afklar kvalitet: Hvor stærk en model kræver opgaven, og hvor meget fejlrisiko kan accepteres?
3. Afklar drift: Hvem opdaterer modeller, rettigheder, sikkerhedsrettelser og dokumentation?
4. Afklar økonomi: Sammenlign hardware, strøm, support, API-forbrug og skaleringsbehov over tid.

Hvordan hænger lokal AI sammen med edge computing?

Edge computing betyder, at databehandling flyttes tættere på det sted, hvor data opstår. Lokal AI kan være en del af edge computing, når modellen kører på eller nær enheden, sensoren, maskinen eller brugeren. Det reducerer transporten af data og kan give hurtigere reaktioner, fordi systemet ikke behøver at vente på en fjern server for hvert trin.

Ikke al lokal AI er dog edge computing. En sprogmodel på en kontor-pc er lokal, men ikke nødvendigvis et edge-system. Omvendt kan edge-AI være meget specialiseret og ikke ligne de chatbaserede AI-værktøjer, mange forbinder med generativ AI. Det kan for eksempel være en model, der registrerer fejl på en produktionslinje eller sorterer signaler fra sensorer.

Fællesnævneren er arkitektur. Jo tættere modellen kører på datakilden, jo mere bliver hardware, energieffektivitet, opdateringsmekanismer og lokal sikkerhed en del af AI-designet. Derfor skal lokal AI ikke kun vurderes som et modelvalg, men som en teknisk infrastruktur med egne krav til vedligeholdelse.

Hvilke sikkerhedsrisici forsvinder ikke lokalt?

Lokal AI fjerner ikke risikoen for usikre output. En lokal sprogmodel kan stadig hallucinere, misforstå instruktioner, gengive bias, give forældede svar eller foreslå handlinger, der ikke bør udføres uden kontrol. Hvis modellen forbindes til filer, e-mail, databaser, kodeværktøjer eller automatisering, kan fejl få praktiske konsekvenser.

Lokale modeller kan også angribes gennem input. En bruger eller et dokument kan indeholde skjulte instruktioner, som forsøger at styre modellens adfærd. Det er især relevant, hvis modellen læser eksterne dokumenter, websider eller filer og derefter får adgang til værktøjer. AI-sikkerhed mod jailbreaking er derfor ikke kun et cloudproblem.

Model- og dataforsyningskæden er et andet kontrolpunkt. En lokal model kan være manipuleret, forkert pakket, forkert licenseret eller opdateret fra en usikker kilde. Lokale embeddings og vektordatabaser kan også indeholde følsomme data, som ikke er synlige i selve modellen, men stadig kan udtrækkes gennem søgning eller adgangsfejl.

• Begræns modellens adgang til værktøjer og data efter mindste privilegium.
• Test lokale modeller med realistiske fejlscenarier, før de bruges i kritiske arbejdsprocesser.
• Log hændelser uden at gemme flere personoplysninger eller fortrolige dokumentuddrag end nødvendigt.
• Brug menneskelig godkendelse ved handlinger, der kan ændre data, sende beskeder eller igangsætte betalinger.

Hvordan bør lokal AI styres i en organisation?

Lokal AI kræver governance, fordi ansvaret flyttes tættere på organisationen. Når en ekstern tjeneste udskiftes med en lokal model, skal nogen stadig beslutte, hvilke modeller der må bruges, hvilke data de må behandle, hvilke opgaver de må løse, og hvordan fejl opdages. Uden fælles regler kan lokale installationer vokse frem som uens værktøjer uden fælles sikkerhedsniveau.

God styring begynder med et modelregister. Det bør beskrive modelnavn, version, kilde, licens, formål, datatyper, kendte begrænsninger, ejer, teststatus og opdateringsplan. For generative modeller bør registret også beskrive, hvilke systeminstruktioner, retrieval-kilder og værktøjer modellen bruger. Det gør det lettere at gentage test og forklare, hvorfor et system opfører sig på en bestemt måde.

Styringen bør kobles til AI governance, informationssikkerhed og almindelig ændringsstyring. En lokal model, der bruges i HR, økonomi, kundeservice eller produktionsstyring, bør ikke behandles som et privat skriveværktøj. Den er en del af en arbejdsproces og bør have ejer, risikovurdering, adgangsregler og en vej til at stoppe eller rulle tilbage ved fejl.

Hvad betyder lokal AI for compliance i EU?

Lokal AI kan gøre nogle databeskyttelsesspørgsmål lettere at håndtere, fordi færre data behøver at forlade organisationens miljø. Det ændrer dog ikke ved, at behandling af personoplysninger stadig skal have et lovligt grundlag, et tydeligt formål, passende sikkerhed og passende rettigheder for de registrerede. Lokal drift er derfor et teknisk valg, ikke en juridisk fritagelse.

EU’s AI Act er også relevant at holde adskilt fra selve driftsformen. Forordningen regulerer AI-systemer efter rolle, anvendelse og risikoniveau, ikke kun efter om modellen kører lokalt eller i cloud. Hvis et lokalt system bruges i en højrisikokontekst, kan krav til dokumentation, risikostyring, datakvalitet, overvågning og menneskelig kontrol stadig blive relevante.

For organisationer i Europa er den praktiske konsekvens, at lokal AI bør dokumenteres som en del af den samlede tekniske og organisatoriske kontrol. Du bør kunne forklare, hvorfor lokal drift er valgt, hvilke data systemet behandler, hvilke leverandører eller open source-komponenter der indgår, og hvordan systemet testes for fejl, bias, sikkerhed og misbrug.

Hvilke eksempler viser lokal AI i praksis?

Et typisk eksempel er billedgenkendelse på en telefon eller pc. Modellen kan finde objekter, sløre baggrund, læse tekst i billeder eller beskrive en scene uden at sende hele billedet til en ekstern tjeneste. Det kan give hurtig respons og mere datakontrol, men kvaliteten afhænger af model, enhed og den konkrete billedtype.

Et andet eksempel er lokal dokumentassistance. En organisation kan indeksere interne vejledninger, manualer eller politikker og lade en lokal sprogmodel svare ud fra dem. Det kan begrænse dataoverførsel og gøre svar hurtige, men kræver styring af dokumentrettigheder. Hvis modellen får adgang til dokumenter, som brugeren ikke selv måtte læse, bliver lokal drift en adgangsrisiko.

Et tredje eksempel er udviklerværktøjer, hvor kodeforslag eller forklaringer køres lokalt. Det kan være relevant, når kildekode ikke må sendes til en ekstern tjeneste. Kvaliteten afhænger dog af modellens kodeforståelse, kontekstlængde og adgang til projektets dokumentation. Der bør stadig være kodegennemgang, test og kontrol af licensforhold.

Et fjerde eksempel er lokal transskribering eller talegenkendelse. Her kan lyd behandles tæt på brugeren, hvilket kan reducere dataoverførsel og give stabil funktion ved ustabil forbindelse. Resultatet skal stadig kontrolleres, hvis teksten bruges til beslutninger, kundedata, sundhedsoplysninger eller dokumentation.

Hvordan ser en enkel beslutningsmodel ud?

En enkel beslutningsmodel begynder med at klassificere opgaven. Hvis opgaven kun kræver et kort resumé af offentligt materiale, er lokal drift måske ikke nødvendig. Hvis opgaven behandler interne kontrakter, kundedata, kildekode eller følsomme lydfiler, bør lokal eller hybrid behandling vurderes mere grundigt.

Næste trin er at teste kvaliteten på egne eksempler. Lokal AI bør ikke vælges ud fra generelle modelrygter eller demonstrationsvideoer. Brug repræsentative dokumenter, realistiske fejlscenarier og konkrete acceptkriterier. Mål ikke kun svarets sproglige kvalitet, men også om modellen siger fra, når den ikke har nok grundlag.

Til sidst bør du beslutte, hvordan løsningen skal leve videre. En lokal model, der kun virker på én medarbejders maskine, er ikke det samme som et stabilt organisationssystem. Drift kræver opdateringer, adgangsstyring, backup, overvågning, brugertræning og klare grænser for, hvilke beslutninger modellen må støtte.

Hvilke kilder ligger til grund?

Artiklen bygger på officiel dokumentation fra Google AI Edge, Microsoft Learn om Windows AI, NIST AI Risk Management Framework, OWASP GenAI Top 10 og Regulation (EU) 2024/1689.