En sund tilgang til lokal AI i virksomheder starter med arbejdet. Lokal behandling passer bedst, når arbejdet afhænger af nærliggende data, kræver hurtigt svar, skal fortsætte ved begrænset forbindelse eller er så følsomt, at behandling på en administreret enhed er berettiget. Cloud-AI passer som regel bedre, når en opgave kræver stærkere modeller, elastisk kapacitet, bred ekstern viden eller centrale tjenester. De fleste organisationer bør ikke træffe ét valg for alt. De har brug for en routingpolitik, der sender hver arbejdsbelastning det rette sted hen.

Den praktiske beslutning handler om arbejdet, ikke om hvor ny modellen er. Start med datafølsomhed, nødvendig kapacitet, latenstid, tilgængelighed, omkostningsindsigt og driftskontrol. Test derefter den mindste nyttige arbejdsgang. Et hybridt design kan holde udvalgt kontekst og rutinebehandling lokalt og kalde en cloudtjeneste ved sværere ræsonnement, forudsat at rettigheder, logs og fejladfærd er klare.

Hvad Microsoft mener med hybrid intelligens

I sit indlæg på Windows Experience Blog , offentliggjort den 7. oktober 2026, beskrev Microsoft Windows som en platform, hvor agenter kan køre lokalt, når det giver mening, og bruge skyen, når det er nødvendigt. Virksomheden præsenterede det som »hybrid intelligens«, understøttet af lokale modeller, routing, runtime-funktioner og enhedens hardware. Det er Microsofts påstande og produktretning, ikke bevis for, at enhver forretningsarbejdsbelastning bør flyttes til en pc.

Microsoft oplyste også, at Microsoft Execution Containers nu er generelt tilgængelige på Windows 11. Ifølge indlægget kan disse containere håndhæve politikker, der fastlægger, hvilke filer og netværk en agent må tilgå. Microsoft placerede indkapsling side om side med agentidentitet og administrerbarhed: begræns agentens rækkevidde, adskil dens aktivitet fra brugerens, og knyt styringen til organisationens kontroller.

Samme skelnen gælder for Copilot. Microsoft sagde, at lokal kontekst, lokale handlinger og lokale modeller vil kræve brugerens tilladelse, med cloudintelligens tilgængelig efter behov. For en virksomhed rammer det det rigtige spørgsmål ind: ikke »lokalt eller cloud?« i det abstrakte, men »hvilken kontekst, handling og model skal tillades til denne opgave?«

Hvor lokal AI i virksomheder gør nytte

Lokal behandling giver mening, når nærhed skaber en reel driftsfordel. En enhed kan allerede indeholde de filer, den applikationstilstand eller de sensordata, opgaven kræver. At holde det første behandlingstrin der kan reducere unødig dataflytning og gøre en interaktion mindre afhængig af en tur frem og tilbage over netværket. Det kan også give begrænset drift, når forbindelsen er ustabil.

Gode kandidater er afgrænsede, gentagelige opgaver med begrænsede input og output. Eksempler er klassificering af dokumenter, der allerede ligger på en administreret maskine, udtræk af felter til menneskelig gennemgang, søgning i en godkendt lokal vidensbase, opsummering af arbejdsnoter eller hjælp til en arbejdsgang på enhedsniveau. Det er eksempler på typer af arbejdsbelastning, ikke løfter om, at en bestemt model når den krævede kvalitet.

Lokalt betyder ikke automatisk privat, sikkert eller billigt. Data kan stadig eksponeres via for brede rettigheder, usikker adgang til værktøjer, dårlige logs, kopierede resultater eller et ikke-administreret endpoint. Hardware, udrulning, modelopdateringer og support koster også. Business casen bør omfatte hele systemet, ikke kun undgået cloudforbrug.

Hvornår cloud-AI er det fornuftigste valg

Cloud-AI er fortsat nyttig, når opgaven overstiger kapaciteten eller hukommelsen på administrerede enheder, efterspørgslen svinger kraftigt, eller teams har brug for én centralt vedligeholdt tjeneste. Det kan forenkle adgangen til stærkere modeller og mindske behovet for at distribuere modelfiler og runtimes til en hel flåde af enheder. Central drift kan også gøre versionsstyring og overvågning mere ensartet, selvom fordelene afhænger af tjenesten og implementeringen.

Vælg ud fra eksplicitte kriterier frem for antagelser:

• Data: Hvilke oplysninger kræves, hvor stammer de fra, og må de forlade enheden eller regionen?

• Kapacitet: Kan en godkendt lokal model nå den målte kvalitetstærskel, eller kræver opgaven en stærkere cloudmodel?

• Hastighed: Hvilken løsning når svartidsmålet fra ende til ende under realistisk netværks- og enhedsbelastning?

• Kontinuitet: Hvad skal der ske, når netværket, cloudtjenesten eller den lokale accelerator ikke er tilgængelig?

• Økonomi: Hvordan forholder omkostningerne til enheder, udrulning, support og energi sig til forbrug af tjenesten og dataoverførsel?

• Kontrol: Kan organisationen tildele rettigheder, indkapsle handlinger, identificere den handlende agent, føre brugbare logs og tilbagekalde adgang?

En opgave kan skifte rute, når dens kontekst ændrer sig. En lokal model kan forberede eller anonymisere materiale, mens en cloudmodel håndterer en vanskelig inferens. Omvendt kan en cloudapplikation uddelegere en handling til enheden, men først når brugeren har godkendt den. Grænsen skal være designet og synlig, ikke gemt i en leverandørs standardindstilling.

Lav en routingpolitik, før du vælger produkter

Kortlæg én arbejdsgang fra input til handling. Markér hver datakilde, hvert modelkald, værktøj, brugergodkendelse og gemt resultat. Vurder konsekvensen af et forkert svar og konsekvensen af en uautoriseret handling hver for sig. Et udkast, der blot foreslår tekst, har en anden risikoprofil end en agent, der redigerer filer, sender beskeder eller ændrer et forretningssystem.

Definér derefter tre ruter: lokal, cloud og stop. »Stop« er afgørende, når intet miljø er godkendt, tilliden er for lav, nødvendig kontekst mangler, eller den ønskede handling ligger uden for politikken. Angiv, hvad brugeren ser, når routingen fejler. Et stille skift fra lokal til cloud kan undergrave en beslutning om databehandling, mens et stille skift fra cloud til en svagere lokal model kan undergrave kvaliteten.

Gennemfør en repræsentativ evaluering før udrulning. Mål opgavekvalitet, latenstid, ressourceforbrug, genopretning efter fejl og operatørernes indsats. Gennemgå de rettigheder, agenten faktisk beder om, ikke kun modellens output. Hvis arbejdsgangen udfører handlinger, så test indkapslingen og bekræft, at logs viser, hvad agenten gjorde. Microsofts fokus på indkapsling, identitet og administrerbarhed er her en nyttig tjekliste, også selvom den endelige stack ikke er begrænset til Windows.

Gør til sidst ejerskabet tydeligt. Sikkerhed bør godkende adgangsgrænser, drift bør eje overvågning og genopretning, og procesejeren bør definere acceptable resultater. Indkøb har brug for en sammenlignelig omkostningsmodel. Hvis organisationen skal afgøre, om komponenterne skal udvikles, købes eller integreres, giver Vexols ramme for bygge, købe eller forbinde en praktisk måde at strukturere valget på.

Er lokal AI altid sikrere end cloud-AI?

Nej. Lokal behandling kan reducere visse dataoverførsler, men sikkerheden afhænger af endpoint-beskyttelse, rettigheder, indkapsling, modellens oprindelse, logning og driftsdisciplin. Sammenlign de komplette lokale og cloudbaserede løsninger med de samme kontroller.

Bør alle AI-arbejdsgange understøtte begge ruter?

Nej. Hybrid routing tilføjer udviklings- og styringsarbejde. Brug det, når de målte fordele retfærdiggør kompleksiteten. En fast lokal eller fast cloudbaseret rute er ofte tydeligere for en stabil, veldefineret opgave.