Når en sprogmodel kører hos jer, flytter otte opgaver ind, som en købt tjeneste ellers løser i det skjulte: adgang, logning, overvågning, kapacitet, opdatering af software, skift af modelversion, kontrol af modelfiler og fordeling af udgiften internt. De bestemmer, hvor mange timer egen drift kræver, og de er grundlaget for økonomien.
Vi har ikke fundet en samlet, uafhængig kilde til driftsopgaverne for en sprogmodel. Listen her er en metode bygget på dokumentation fra udgivere, sikkerhedsorganisationer og de værktøjer, modellerne køres med. Brug den som tjekliste, før I vælger egen drift eller lejede maskiner, og som grundlag for timerne i folkene bag en sprogmodel i drift.
1. Adgang
Hvem må bruge modellen, og gennem hvilken brugerflade? En model, der kører på en server, har typisk et programmeringsinterface, som alt på netværket kan kalde, hvis ingen lukker for det. Adgangen skal kobles til jeres eksisterende brugerstyring, så en fratrådt medarbejder mister adgangen samme dag. Systemer, der kalder modellen, skal have egne nøgler med en ejer og en udløbsdato.
2. Logning
Hvad skal gemmes, hvor længe og hvem må læse det? Prompter og svar kan indeholde netop de oplysninger, I valgte egen drift for at beskytte. Logger I det hele, har I skabt et nyt lager med følsomme data. Logger I intet, kan I ikke undersøge en fejl eller et misbrug. Beslut niveauet på forhånd, skriv det ind i jeres sortering af data, og lad DPO’en se det.
3. Overvågning
Kører modellen, og svarer den inden for den grænse, I har sat? Overvågning af en sprogmodel er mere end at se, om serveren er tændt. Svartid, kø, fejlede forespørgsler og brug af grafikkortets hukommelse skal følges, fordi en model kan være oppe og alligevel for langsom til at bruge. Hvad der skal måles, står i svartid og kø.
4. Kapacitet
Hvornår er der for lidt? Når mellemlageret til igangværende forespørgsler løber fuldt, må serveren skubbe forespørgsler til side og regne dem forfra. Det ses som stigende svartider længe før noget går i stå. Nogen skal se tallene hver måned og beslutte, om der skal mere til, eller om grænser for brugen er nok. Hvad der afgør behovet, står i artiklen om maskiner til en sprogmodel.
5. Opdatering af software
Serversoftware, drivere til grafikkort, operativsystem og de biblioteker, modellen køres med, får sikkerhedsrettelser som al anden software. Rettelserne skal testes mod modellen, før de lægges på, fordi en ny driver eller en ny version af serverprogrammet kan ændre ydelse eller adfærd.
6. Skift af modelversion
Ingen udbyder varsler udfasning af en model, I selv kører. Til gengæld kommer der nye versioner, og licensen kan ændre sig fra version til version. Opgaven er at følge med, læse licensen for den nye version, køre jeres prøvesamling mod den og beslutte, om I skifter. Beslutningen er jeres, og uden en ansvarlig bliver den aldrig taget. Prøvesamlingen er beskrevet i byg jeres egen prøvesamling.
7. Kontrol af modelfiler
En model hentes som filer, og nogle filformater kan køre kode, når de indlæses. Den største platform for modelfiler skriver selv, at det almindelige format for vægte kan bruges til at køre vilkårlig kode, og anbefaler et format, der kun indeholder vægtene. Modeller med egen modelkode kræver, at man aktivt tillader kode fra arkivet. Hent fra kendte udgivere, foretræk sikre formater, og lås versionen til en bestemt revision, så filerne ikke kan ændre sig under jer. Mere i modelfiler er software.
8. Fordeling af udgiften
Når flere afdelinger bruger samme model, spørger nogen før eller siden, hvem der betaler. Uden måling af brugen pr. afdeling eller opgave kan spørgsmålet ikke besvares, og så ender udgiften som en samlet post hos IT, som ingen føler ansvar for. Mål forbruget pr. nøgle eller pr. brugergruppe fra første dag. Det er også den måling, der viser, om modellen bruges nok til at bære driften.
Når modellen kobles til andre systemer
Får modellen adgang til mail, filer eller forretningssystemer, kommer en niende opgave til: rettighederne for hver forbindelse. Sikkerhedsorganisationen OWASP anbefaler mindst mulige rettigheder for modellen og menneskelig godkendelse af handlinger med høj risiko. Det er beskrevet i agenter og forbindelser.
Hvad det kræver, og hvad det koster at lade være
Opgaverne kræver timer hver måned, også når intet går galt, og to personer, der kender opsætningen, hvis driften ikke må stoppe ved sygdom og ferie. Skriv for hver af de otte opgaver navnet på den ansvarlige, hyppigheden og tidsforbruget, med en lav og en høj vurdering. Summen hører med, hver gang egen drift sammenlignes med en købt tjeneste, fordi en tjeneste har de samme opgaver gemt i prisen.
Lader I opgaverne ligge, bliver de løst alligevel, bare uden plan. Adgangen står åben, logningen er tilfældig, versionen skiftes aldrig eller skiftes uden test, og den første kapacitetsplan bliver lavet, efter brugerne har klaget. Hver af dem er billigere at sætte op før start end at rydde op efter.
Det skal I lade være med
- At regne driften som et spørgsmål om maskiner · timerne til de otte opgaver er en fast post.
- At logge alt for en sikkerheds skyld · logningen bliver selv et lager med følsomme data.
- At hente modelfiler uden låst version · filerne kan ændres, efter I har testet dem.
Det skal valget kunne vise
- ☐ En ansvarlig og en stedfortræder for hver af de otte opgaver.
- ☐ Et besluttet niveau for logning, godkendt af DPO’en.
- ☐ Grænser for svartid og kø, som overvågningen måler mod.
- ☐ En fast rytme for software, modelversion og licens.
Kilder
- OWASP Gen AI Security Project, LLM01:2025 Prompt Injection, https://genai.owasp.org/llmrisk/llm01-prompt-injection/, læst 8. november 2026.
- Dokumentation fra en stor platform for modelfiler om filformater og scanning, læst 8. november 2026.
- Dokumentationen til en udbredt server til sprogmodeller med åben kildekode, afsnit om hukommelse og ydelse, læst 8. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Skriv de otte opgaver op med navn og timer, før I sammenligner egen drift med en købt tjeneste.
Læs også: Sikkerhed, når I selv kører modellen · Egen drift af en sprogmodel
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
