»Privat AI« bruges om alt fra »vi har slået træning fra på vores SaaS-konto« til »vi kører åbne modeller på egne GPU’er i et aflåst netværk«. Det er ikke det samme.
For SMV’er afhænger den rigtige private AI-arkitektur af dataene, opgaven, kvalitetskravet og teamets evne til at drive infrastrukturen. Den mest private løsning er ikke altid den bedste. Den løsning, der har flest funktioner, er ikke altid acceptabel til de pågældende data. Den billigste løsning kan blive dyr, hvis den konstant kræver ingeniørarbejde.
Denne artikel giver et praktisk overblik.
Begynd med dataklassificering, ikke med en foretrukken model. En svag model inden for den rigtige databeskyttelsesgrænse er bedre end en frontier-model, der modtager data, den ikke bør få adgang til.
De fem udrulningsmønstre
| Mønster | Hvad det er | Egner sig bedst til | Vigtigste begrænsning |
|---|---|---|---|
| Forbruger-SaaS | Personlige konti til ChatGPT, Claude eller Gemini | Offentlige eller personlige opgaver med lav risiko | Svage virksomhedskontroller |
| Virksomheds-SaaS | Erhvervsløsning med administration, SSO, opbevaring og fravalg af træning | De fleste almindelige arbejdsopgaver | Data forlader stadig jeres miljø |
| VPC eller privat cloud | Administreret modelendpoint inden for en kontrolleret cloudgrænse | Fortrolige workloads, der kræver stærkere isolation | Højere omkostninger og mere opsætning |
| Selvhostet inferens | I kører åbne modeller på egen infrastruktur | Data med begrænset adgang, tilpassede modeller og stordriftsøkonomi | Driftsbyrde |
| Modeller på lokale enheder | Modellen kører på en bærbar computer, arbejdsstation eller edge-enhed | Smalle opgaver, der er offline, følsomme eller kræver lav latenstid | Mindre modeller og enhedernes begrænsninger |
De fleste virksomheder har brug for mere end ét mønster. Målet er ikke at vælge ét mønster for altid. Målet er at dirigere hver anvendelse til den rigtige sikkerhedsgrænse.
Klassificer dataene først
Brug fire kategorier:
| Data | Eksempler | Standardsikkerhedsgrænse for AI |
|---|---|---|
| Offentlige | Webstedstekst, udgivne dokumenter, offentlig forskning | Ethvert godkendt værktøj |
| Interne | Procesnoter, anonymiserede eksempler, ikke-følsomme udkast | Virksomheds-SaaS |
| Fortrolige | Kundedata, kontrakter, kildekode, finansielle data, strategi | Virksomheds-SaaS med kontroller, VPC eller selvhostet |
| Adgangsbegrænsede | Sundhedsdata, oplysninger omfattet af juridisk fortrolighed, HR-undersøgelser, regulerede registre, legitimationsoplysninger | Juridisk og sikkerhedsmæssig gennemgang; ofte lokalt, i VPC eller uden AI |
Klassificeringen forebygger en almindelig fejl: at bruge den samme assistent til offentlige blogudkast og fortrolige kunderegistre, blot fordi det er bekvemt.
Mønster 1: Virksomheds-SaaS som standard
For mange SMV’er er virksomheds-SaaS det rigtige standardvalg. ChatGPT Enterprise/Business, Claude for Work, Microsoft Copilot, Gemini for Workspace og lignende værktøjer tilbyder typisk:
- Kontraktmæssigt fravalg af træning.
- Administrationskontroller.
- SSO og adgangsstyring.
- Kontroller for opbevaring.
- Revisionslogfiler.
- Sikkerhedsdokumentation.
- Leverandørsupport.
Det er tilstrækkeligt til en stor del af arbejdet: skrivning, opsummering, research, mødenoter, interne analyser og godkendt anvendelse af kundekontekst.
Konfigurationen er afgørende. Det er ikke nok at købe en teamplan. Konfigurer opbevaring, deling, connectoradgang, godkendte arbejdsområder og dataregler.
Mønster 2: VPC eller privat cloud
VPC- og private cloudmønstre er nyttige, når data må forlade applikationen, men skal forblive inden for en kontrolleret cloudgrænse. Eksempler:
- Kundesupportassistent til fortrolige supportsager.
- Intern vidensassistent til følsomme dokumenter.
- Dokumentudtræk fra kontrakter eller fakturaer.
- Domænespecifik assistent, hvor I har brug for stærkere dataisolation end i SaaS.
Fordele:
- Bedre isolation.
- Mere kontrol over netværk og logfiler.
- Enklere indkøbsproces hos kunder med følsomme data.
- Mindre driftsbyrde end fuld selvhosting.
Begrænsninger:
- Dyrere end SaaS.
- Mere integrationsarbejde.
- Udvalget af modeller kan være mindre.
- I er stadig afhængige af leverandørens infrastruktur.
For mange seriøse SMV-systemer er dette den praktiske mellemvej.
Mønster 3: Selvhostet inferens
Ved selvhosting driver I selv modellens runtime: vLLM, TGI, SGLang, llama.cpp, Ollama eller en anden serving-stack. Det giver mening, når:
- Data ikke må forlade jeres miljø.
- I har brug for en tilpasset eller finjusteret åben model.
- Inferensmængden er stor nok til at retfærdiggøre infrastrukturen.
- Krav til latenstid eller tilgængelighed kræver direkte kontrol.
- I har medarbejdere, der kan drive løsningen.
Vælg ikke selvhosting alene, fordi det føles mest rent. Driftsomkostningen er reel: GPU-kapacitet, overvågning, opgraderinger, sikkerhedsrettelser, modelevaluering, skalering og hændelseshåndtering.
Selvhosting er et stærkt valg for den rigtige organisation. For et lille team uden erfaring med ML-infrastruktur kan det blive et skrøbeligt sideprojekt.
Mønster 4: Modeller på lokale enheder
Lokale modeller bliver ofte undervurderet til individuelt arbejde med følsomme data:
- Opsummering af lokale noter.
- Udarbejdelse af udkast fra private dokumenter.
- Klassificering af interne tekstuddrag.
- Feltarbejde uden netforbindelse.
- Edge-workflows, hvor latenstiden har betydning.
Afvejningen gælder kvalitet. En lille lokal model kan være tilstrækkelig til opsummering, klassificering, udtræk og første udkast. Den kan ikke måle sig med hostede frontier-modeller til vanskelig ræsonnering, kompleks skrivning eller bred anvendelse af værktøjer.
Brug lokale modeller, når opgaven er smal, og databeskyttelsesgrænsen er vigtigere end kvaliteten fra en frontier-model.
Mønster 5: Hybrid dirigering
Det modne mønster er hybridt:
- Offentlige opgaver og opgaver med lav risiko går til virksomheds-SaaS.
- Retrieval fra fortrolige data sker i et privat RAG-system.
- Udtræk fra adgangsbegrænsede data kører lokalt eller i en VPC.
- Den endelige formulering kan anvende en frontier-model, efter at følsomme felter er fjernet.
- Logfiler og evalueringer afgør, om hver rute fungerer.
Hybrid dirigering gør det muligt at anvende stærke modeller uden at behandle alle data ens. Det kræver disciplin:
- Dataklassificering før dirigering.
- Maskering, hvor det er muligt.
- En tydelig positivliste over modeller og værktøjer.
- Logfiler, der registrerer, hvilken sikkerhedsgrænse der blev anvendt.
- Fallback, når den private model ikke kan løse opgaven.
Beslutningsramme
Stil seks spørgsmål:
- Hvilke data sendes til modellen? Offentlige, interne, fortrolige eller adgangsbegrænsede.
- Hvilken indvirkning har outputtet? Udkast, anbefaling, beslutning eller kundevendt handling.
- Hvilken kvalitet kræves? Tilstrækkelig, på ekspertniveau eller ræsonnering på frontier-niveau.
- Hvilken latenstid kræves? Interaktiv, batch, realtid eller offline.
- Hvilken driftskapacitet findes? Intet infrastrukturteam, applikationsteam, platformsteam eller ML-drift.
- Hvilken dokumentation kræver kunder eller myndigheder? Leverandørdokumenter, logfiler, dataplacering, revisionsspor eller isolation.
Vælg derefter det mindst komplekse mønster, der opfylder behovene for databeskyttelse og kvalitet.
Gør ikke dette endnu
Vælg ikke selvhosting, før I har målt workloadet og kvalitetskravet.
Send ikke adgangsbegrænsede data til forbrugerværktøjer.
Antag ikke, at »open source« betyder privat. Løsningen er kun privat, hvis udrulning, logfiler, adgang og datastrøm er private.
Byg ikke én stor AI-gateway uden dataklassificering. Den vil dirigere følsomme data forkert.
Ignorer ikke evalueringer. En privat løsning, der giver forkerte svar, er stadig forkert.
Et praktisk udgangspunkt for SMV’er
For de fleste SMV’er:
- Godkend én virksomheds-SaaS-assistent til generelt arbejde.
- Skriv en regel for dataklassificering.
- Bloker adgangsbegrænsede data, medmindre anvendelsen er gennemgået.
- Byg ét privat RAG- eller VPC-workflow til den mest værdifulde fortrolige anvendelse.
- Brug lokale modeller til smalle, følsomme opgaver, hvor kvaliteten er acceptabel.
- Genovervej først selvhosting, når databeskyttelse, tilpasning eller omkostninger klart retfærdiggør det.
Det giver organisationen en private-by-design-vej uden at foregive, at enhver AI-anvendelse kræver en GPU-klynge.
Konklusion
Privat AI er en arkitektur, der er tilpasset dataene. Det rigtige svar er sjældent »alt i SaaS« eller »alt selvhostet«. Det er typisk en portefølje: virksomheds-SaaS til normalt arbejde, private systemer eller VPC-systemer til fortrolige workflows, lokale modeller til smalle opgaver med følsomme data og selvhosting, når skala eller kontrol reelt kræver det.
Vælg ud fra data, indvirkning, kvalitet, latenstid, drift og dokumentationskrav. Det er den kedelige version. Det er også den version, der overlever mødet med produktion.
