Kører I selv en sprogmodel, flytter en række sikkerhedsopgaver fra udbyderen til jer: kontrol af modelfilerne, adgangen til modellens interface, beskyttelse af logs, forsvar mod skjulte instruktioner i indholdet og styring af modellens forbindelser til andre systemer. Opgaverne skal være besluttet, før modellen tages i brug, og de hører med i valget mellem egen drift og en købt tjeneste.
Denne artikel er en tjekliste til den, der skal vurdere, hvad egen drift kræver af sikkerhed. Kilderne her er skrevet til udviklere og driftsfolk. Vi har oversat dem til spørgsmål, en ledelse kan stille.
1. Modelfilerne
En model hentes som filer fra et arkiv, og visse filtyper kan starte kode i samme øjeblik, de åbnes. Platformen med flest modelfiler oplyser selv, at det almindelige vægtformat kan misbruges til at afvikle hvilken som helst kode, og at den interne scanning efter skadelig kode gælder filer under en vis størrelse. Store vægtfiler er efter vores læsning af teksten ikke omfattet.
Spørgsmål: Henter vi kun fra kendte udgivere? Bruger vi et format, der kun indeholder vægte? Har vi fastlåst versionen til én revision i arkivet? Kræver modellen, at vi tillader kode fra arkivet, og har nogen set koden igennem? Mere i modelfiler er software.
2. Interfacet
Serversoftware til sprogmodeller stiller typisk et programmeringsinterface til rådighed på netværket. Står det åbent, kan alt på netværket bruge modellen, og står det på internettet, kan alle.
Spørgsmål: Kræver interfacet en nøgle? Er det kun tilgængeligt fra de systemer, der skal bruge det? Har hver nøgle en ejer og en udløbsdato?
3. Logs og samtaler
Prompter og svar kan rumme netop det, egen drift skulle beskytte. Logger I dem, er logningen selv et følsomt lager.
Spørgsmål: Hvad logges, hvor ligger det, hvem kan læse det, og hvornår slettes det? Er logningen med i jeres sortering af data?
4. Skjulte instruktioner i indholdet
Sikkerhedsorganisationen OWASP har prompt-injektion som første punkt på sin liste over risici ved sprogmodeller. Direkte injektion er, når brugerens eget input får modellen til at gøre noget uønsket. Indirekte injektion er, når indhold udefra, en webside, en mail eller et dokument i et søgeindeks, gør det. OWASP skriver, at det ikke står klart, om angrebet overhovedet kan forhindres helt. Organisationen anbefaler blandt andet at begrænse modellens rolle, kontrollere svarets format, filtrere ind- og uddata, adskille og markere indhold udefra og teste med angreb, hvor modellen betragtes som en utroværdig bruger.
Spørgsmål: Behandler vores løsning modellens svar som utroværdige, indtil de er kontrolleret? Er indhold udefra markeret, så modellen kan skelne det fra instruktioner? Har vi prøvet med en skjult instruktion i et testdokument? Se prøv tjenesten for prompt-injektion.
5. Forbindelser og rettigheder
Får modellen adgang til mail, filer eller systemer, kan en skjult instruktion blive til en handling. OWASP anbefaler at holde modellens rettigheder på et minimum og lade et menneske godkende risikable handlinger. Den åbne standard for forbindelser, MCP, beskriver i sine sikkerhedsanbefalinger, der er et udkast, risici som servere, der springer brugerens samtykke over, og lokale servere, der er kompromitteret.
Spørgsmål: Hvilke rettigheder har hver forbindelse? Hvilke handlinger kræver en godkendelse? Mere i agenter og forbindelser.
6. Software og drivere
Serversoftwaren, bibliotekerne, driverne til grafikkortene og operativsystemet får sikkerhedsrettelser. De skal lægges på inden for en fast frist og testes mod modellen først.
Spørgsmål: Hvem følger rettelserne, og hvad er fristen?
7. Hændelser
En model kan blive misbrugt, lække indhold fra sine logs eller handle forkert gennem en forbindelse. Det skal kunne opdages og stoppes.
Spørgsmål: Hvem kan slå modellen eller en forbindelse fra, og hvor hurtigt? Indgår modellen i jeres plan for hændelser?
Hvad der ikke flytter
Udbyderens sikkerhed for maskinerne, hvis I lejer dem, og jeres eksisterende sikkerhed for netværk, brugerstyring og backup gælder fortsat. Egen drift lægger nye opgaver oven på dem. Hvad driften kræver i øvrigt, står i de driftsopgaver, ingen regner med.
Hvad det kræver, og hvad det koster at lade være
Tjeklisten kræver en gennemgang med den, der skal drive modellen, og den, der har ansvaret for sikkerhed. Lav vurdering: en dag for en model uden forbindelser til andre systemer. Høj vurdering: et par uger, når modellen har forbindelser og bruges af mange. Herefter kræver punkt 1, 4 og 6 tid ved hver ny version.
Springes gennemgangen over, er modellen et nyt system med adgang til følsomme data, som ingen har vurderet. En åben adgang, en fil fra en ukendt kilde eller en skjult instruktion i et dokument kan give et brud, der skal håndteres som alle andre brud, med de timer, forklaringer og eventuelle anmeldelser, det kræver.
Det skal I lade være med
- At stole på modellens svar som på jeres egen kode · kontrollér formatet, og behandl svaret som input udefra.
- At lade interfacet stå åbent på netværket · kræv nøgler, og begræns, hvem der kan nå det.
- At give modellen rettigheder, fordi det er praktisk · start med mindst mulig adgang.
Det skal valget kunne vise
- ☐ En regel for, hvor modelfiler hentes fra, i hvilket format og med låst version.
- ☐ Adgangskontrol på interfacet og en liste over nøgler med ejer.
- ☐ En test med en skjult instruktion i et testdokument, med resultat.
- ☐ Modellen og dens forbindelser med i planen for hændelser.
Kilder
- OWASP Gen AI Security Project, LLM01:2025 Prompt Injection, https://genai.owasp.org/llmrisk/llm01-prompt-injection/, læst 8. november 2026.
- Model Context Protocol, Security Best Practices (udkast), https://modelcontextprotocol.io/specification/draft/basic/security_best_practices, læst 8. november 2026.
- Dokumentation fra en stor platform for modelfiler om filformater og scanning efter skadelig kode, læst 8. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Gå de syv punkter igennem med den, der skal drive modellen, før den får sine første brugere.
Læs også: Modelfiler er software · Fejl i svarene: hvem tjekker, og hvem hæfter?
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
