Sikkerhedsrisici ved open source AI handler især om modelprovenance, usikre modelartefakter, datalækage, misbrug, sårbare integrationer og svag drift. Open source kan give gennemsigtighed og kontrol, men risikoen falder kun, hvis modellen, dataene, koden, licensen og deployment-miljøet vurderes systematisk.
Open source AI kan give gennemsigtighed og lokal kontrol, men sikkerheden afhænger af provenance, modelartefakter, dataflow, integrationer og drift. Overblikket viser, hvordan åbne modelvægte, supply chain-risici, instruktionsinjektion og datalækage bør vurderes før en model bruges i produktion.
Hvad betyder open source AI i en sikkerhedskontekst?
Open source AI betyder ikke automatisk, at en model er sikker. I en sikkerhedskontekst beskriver begrebet først og fremmest graden af adgang til systemets komponenter: trænings- og inferenskode, modelparametre, dokumentation, dataoplysninger og licensvilkår. Jo mere der kan inspiceres, jo bedre kan svagheder opdages, men samme åbenhed kan også gøre det lettere at ændre eller misbruge modellen.
En praktisk vurdering bør derfor begynde med at skelne mellem open source, open weights og kilde-tilgængelige modeller. En model kan have offentlige vægte uden at give fuld indsigt i træningsdata, filtrering, evalueringer eller sikkerhedsarbejde. Det er relevant, fordi sikkerhedsrisikoen ikke kun ligger i selve modellen, men i hele kæden omkring den.
Hvis du sammenligner åbne og lukkede modeller, bør du ikke antage, at den ene kategori altid er mere sikker. Åbne modeller kan give lokal kontrol, reproducerbarhed og uafhængig audit. Lukkede tjenester kan give centraliseret patching, adgangskontrol og leverandørstyret misbrugsdetektion. Valget afhænger af datafølsomhed, use case, driftskompetence og krav til dokumentation. En mere grundlæggende begrebsafklaring findes i AI Mentors gennemgang af forskellen på open og closed source AI.
Hvorfor er åbne modelvægte ikke nok som sikkerhedsgaranti?
Modelvægte viser, hvad modellen bruger til at producere output, men de forklarer ikke i sig selv, hvordan modellen er trænet, hvilke data den har set, hvilke toksicitets- eller sikkerhedsfiltre der er brugt, eller om kendte evalueringsfejl er håndteret. Åbne vægte kan derfor være nyttige for transparens, men de er kun én del af sikkerhedsbilledet.
For en organisation er forskellen praktisk. Hvis du henter en model med åbne vægte, kan du måske køre den lokalt og begrænse datadeling med en ekstern API. Til gengæld overtager du ansvaret for versionsstyring, adgangskontrol, opdateringer, overvågning, misbrugsforebyggelse og håndtering af sårbare afhængigheder. Risikoen flytter sig fra leverandørens platform til din egen tekniske og organisatoriske kontrol.
Et sikkert valg kræver derfor mere end spørgsmålet om, hvorvidt vægtene er offentlige. Du bør vurdere, om projektet dokumenterer dataoprindelse, arkitektur, evalueringsmetoder, kendte begrænsninger, licensvilkår, udgivelsesproces, sikkerhedsrapporter og ændringer mellem versioner. Manglende dokumentation gør det svært at afgøre, om modellen er egnet til følsomme arbejdsgange.
Hvilke risici følger med AI-supply chain?
AI-supply chain omfatter alt det, der indgår i et AI-system: modelvægte, kode, træningsdata, fine-tuning-data, tokenizere, embeddings, afhængigheder, container-images, biblioteker, evalueringssæt, instruktioner, vektordatabaser og deployment-infrastruktur. En svaghed i ét led kan påvirke hele systemets sikkerhed.
For open source AI er supply chain-risikoen særlig praktisk, fordi mange modeller distribueres gennem offentlige modelhubs, Git-repositorier og tredjepartsbiblioteker. Det giver hurtig adgang til innovation, men øger også behovet for provenance: hvem har udgivet modellen, hvad er ændret, er filerne signerede, og kan versionshistorikken spores?
En enkel risikokæde kan se sådan ud:
- En organisation downloader en populær model uden at fastlåse version og filhash.
- Modellen pakkes ind i et internt værktøj, der får adgang til dokumenter, tickets eller kundehenvendelser.
- En senere model- eller dependency-opdatering ændrer adfærd, introducerer usikker kode eller svækker en sikkerhedsbarriere.
- Fejlen opdages først efter deployment, fordi der mangler test, logging og rollback-plan.
Kontrollen bør derfor ligne moderne software supply chain-sikkerhed, men med AI-specifikke ekstra lag. Du bør fastlåse versioner, gemme checksums, bruge isolerede miljøer, scanne afhængigheder, dokumentere modelkort, teste outputadfærd og have en klar proces for at stoppe eller rulle en model tilbage.
Hvordan kan modelartefakter blive en teknisk angrebsvej?
Modelartefakter er ikke kun passive datafiler. Mange machine learning-formater og frameworks kan indlæse filer på måder, der eksekverer kode eller aktiverer komplekse afhængigheder. Det gælder især artefakter, der bygger på Python-serialization eller kræver custom model code ved loading.
Hugging Face dokumenterer, at pickle-baserede filer kan medføre arbitrary code execution, når de indlæses fra en upålidelig kilde. Risikoen er ikke, at alle offentlige modeller er ondsindede, men at en modelpakke kan fungere som software, ikke kun som statistik. Et download fra et offentligt repository bør derfor behandles som kode fra en ekstern leverandør.
Praktiske kontroller omfatter isoleret testmiljø, ingen produktionsnøgler i testmiljøet, begrænsede rettigheder, scanning af filer, brug af mere sikre tensorformater hvor muligt, kontrol af signerede commits og afvisning af modeller, der kræver ukendt remote code. Hvis modellen kræver specialkode, bør koden gennemgås og afhængighederne låses, før den bliver en del af en intern løsning.
Hvordan påvirker finjustering og fri ændring af modellen risikoen?
En af fordelene ved open source AI er, at modellen kan tilpasses. Samme egenskab kan skabe sikkerhedsproblemer, hvis fine-tuning svækker sikkerhedsadfærd, indlærer følsomme data, fjerner afvisningsmønstre eller gør modellen bedre til en risikabel opgave. Når modellen kan ændres frit, bliver sikkerheden afhængig af den konkrete variant, ikke kun af den oprindelige udgivelse.
Finjustering kan også gøre modelstyring vanskelig. To teams kan starte fra samme basisvægt, men ende med forskellige modeller, forskellige instruktioner, forskellige embeddings og forskellige fejlmønstre. Hvis versionerne ikke registreres tydeligt, kan organisationen miste overblik over, hvilken model der gav et bestemt output, og hvilke tests der gjaldt for den variant.
Du bør derfor behandle en finjusteret model som et nyt system. Den skal have egen dokumentation, egne evalueringsresultater, egen adgangsstyring og egen beslutning om anvendelsesområde. Det gælder også små tilpasninger, fordi ændringer i træningsdata eller instruktioner kan ændre modellens adfærd i uforudsete situationer.
Hvordan spiller instruktionsinjektion og jailbreaks ind?
Instruktionsinjektion og jailbreaks er relevante for både åbne og lukkede modeller. Forskellen er, at open source AI ofte indgår i løsninger, hvor organisationen selv bygger instruktionslag, retrieval, værktøjsadgang og outputhåndtering. Dermed skal sikkerheden ikke kun vurderes i modellen, men i hele applikationen omkring den.
Instruktionsinjektion opstår, når en angriber forsøger at få modellen til at ignorere instruktioner, afsløre data, bruge værktøjer forkert eller følge skjulte instruktioner fra dokumenter, websider eller brugerinput. Jailbreaks forsøger at omgå modellens sikkerhedsadfærd gennem sproglige, logiske eller kontekstuelle tricks. En introduktion til netop den type risici findes i AI Mentors artikel om AI-sikkerhed mod jailbreaking.
Kontrollen bør bygges lagdelt. Modellen bør ikke alene afgøre, om en handling er tilladt. Applikationen bør validere input, begrænse værktøjsrettigheder, adskille brugerdata fra systeminstruktioner, filtrere output, logge risikable handlinger og kræve menneskelig godkendelse ved handlinger med høj konsekvens. Det reducerer risikoen for, at én instruktionsfejl bliver til en systemfejl.
Hvad betyder datalækage og privatliv for åbne AI-modeller?
Open source AI kan mindske datadeling med eksterne tjenester, hvis modellen køres lokalt eller i en kontrolleret privat cloud. Det er en reel sikkerhedsfordel for arbejdsgange med fortrolige dokumenter, kundedata eller interne analyser. Fordelen forsvinder dog, hvis organisationen gemmer brugerforespørgsler, fine-tuning-data, embeddings eller logs uden tilstrækkelig adgangskontrol.
Datalækage kan opstå flere steder. Følsomme oplysninger kan indgå i fine-tuning-sæt, blive indekseret i en vektordatabase, ligge i debug-logs, blive sendt til en ekstern inference-tjeneste eller blive gengivet i output, hvis retrieval-laget henter for brede dokumentudsnit. Risikoen er derfor ikke begrænset til selve modelvægtene.
En praktisk kontrol er at kortlægge dataflowet før deployment. Hvilke data må modellen modtage, hvor lagres de, hvem kan søge i dem, hvor længe opbevares logs, og kan en bruger få adgang til andre brugeres data gennem retrieval eller manipulerede instruktioner? For governance-arbejde er AI Mentors forklaring af AI governance et relevant supplement.
Hvornår kan open source AI forbedre sikkerheden?
Open source AI kan være et sikkerhedsplus, når åbenheden bruges aktivt. Offentlig kode og dokumentation kan gøre det lettere at inspicere arkitektur, reproducere fejl, opdage sårbarheder, teste bias, validere claims og undgå afhængighed af én lukket leverandør. Lokalt deployment kan også give bedre kontrol med data, netværk og adgangsrettigheder.
Fordelen kræver dog kompetence og proces. Hvis ingen gennemgår koden, tester modellen eller følger med i sikkerhedsrettelser, bliver åbenheden mest en mulighed, ikke en beskyttelse. Åbenhed reducerer ikke risiko af sig selv; den giver flere parter mulighed for at finde og rette problemer.
Open source AI er typisk stærkest i miljøer, hvor organisationen har teknisk kapacitet til at styre deployment, evaluere modeller og dokumentere ændringer. For mindre teams kan en velstyret lukket tjeneste nogle gange være sikrere end en lokalt hostet model uden overvågning, patching eller adgangsstyring.
Hvilke kontrolpunkter bør du bruge før deployment?
Før en open source AI-model bruges i produktion, bør vurderingen være konkret og use case-baseret. En model til intern idégenerering kræver ikke samme kontrol som en model, der opsummerer kundesager, skriver kode, søger i fortrolige dokumenter eller kalder eksterne værktøjer.
| Kontrolpunkt | Hvad skal afklares? | Typisk risiko ved at springe over |
|---|---|---|
| Provenance | Udgiver, version, hash, licens, modelkort og ændringshistorik | Ukendt oprindelse eller uforudsete ændringer |
| Artefakter | Filformat, custom code, scanning og isoleret indlæsning | Kodeeksekvering eller kompromitteret miljø |
| Dataflow | Inputdata, logs, embeddings, fine-tuning-data og adgangsrettigheder | Datalækage eller uautoriseret adgang |
| Adfærdstest | Jailbreaks, instruktionsinjektion, hallucinationer og risikable output | Upålidelige eller skadelige svar i drift |
| Drift | Overvågning, rollback, incident response og opdateringsrutine | Langvarig fejl uden tydelig ejer |
Tabellen bør bruges som en minimumsramme, ikke som en fuld certificering. Hvis modellen indgår i beslutninger med høj konsekvens, bør testen udvides med faglige evalueringssæt, red teaming, sikkerhedslogning og en klar beslutning om, hvornår modellen ikke må anvendes.
Hvordan kan drift og overvågning reducere risikoen?
Risikoen ved open source AI ændrer sig efter deployment. Nye sårbarheder opdages, modelhubs opdateres, afhængigheder ændres, brugere finder uventede instruktioner, og integrationer får nye rettigheder. Drift er derfor en del af sikkerheden, ikke en afsluttende teknisk opgave.
Overvågning bør dække både teknisk drift og modeladfærd. Teknisk drift handler om adgangslogning, ressourceforbrug, fejl, netværkskald, filændringer og dependency-opdateringer. Modeladfærd handler om usædvanlige output, afvisningsmønstre, forsøg på instruktionsinjektion, retrieval-fejl og brug af værktøjer uden for det forventede formål.
En beredskabsplan bør beskrive, hvem der kan deaktivere modellen, hvordan du ruller tilbage til en tidligere version, hvordan brugere informeres, og hvordan logs gennemgås uden at sprede følsomme oplysninger. AI Mentors artikel om AI-beredskabsplaner giver en bredere ramme for den del af arbejdet.
Hvilke misforståelser fører ofte til dårlig risikovurdering?
Den første misforståelse er, at open source AI altid er mere sikker, fordi flere kan kigge med. Mange kan kigge med, men det betyder ikke, at nogen faktisk har gjort det for din specifikke model, version, dataopsætning og deployment. Offentlighed er ikke det samme som audit.
Den anden misforståelse er, at lukkede modeller altid er sikrere, fordi leverandøren styrer platformen. Centraliseret drift kan give stærke kontroller, men brugeren har mindre indsigt i træningsdata, modelændringer, logik, evalueringer og nogle typer fejl. Mindre indsigt kan gøre risikovurderingen sværere, især ved følsomme eller regulerede arbejdsgange.
Den tredje misforståelse er, at en model er et enkeltstående værktøj. I praksis bliver den del af et system med instruktioner, dokumenter, plugins, databaser, brugerroller, netværk, logs og processer. De fleste alvorlige fejl opstår ikke kun i modellen, men i samspillet mellem modellen og de rettigheder eller data, den får adgang til.
Hvordan bør organisationer vælge mellem åbenhed, kontrol og ansvar?
Valget bør begynde med risikoniveauet i den konkrete brug. Hvis modellen kun hjælper med lavrisiko-udkast uden følsomme data, kan en standardiseret open source-model være tilstrækkelig med almindelig teknisk kontrol. Hvis modellen derimod bruges til kodegenerering, sagsbehandling, sikkerhedsanalyse eller dokumenter med personoplysninger, kræver den en mere formel risikovurdering.
Et modent valg ser på tre forhold samtidig: hvad organisationen får adgang til, hvad den selv kan kontrollere, og hvilket ansvar den overtager. Open source AI kan give stærk kontrol, men kun hvis organisationen kan vedligeholde den. En lukket tjeneste kan reducere driftsbyrden, men øger afhængigheden af leverandørens dokumentation, databehandling og ændringsstyring.
Den sikreste beslutning er ofte ikke et enten-eller. Nogle organisationer bruger åbne modeller til lokale, datatunge eller kontrollerede arbejdsgange og lukkede tjenester til opgaver, hvor leverandørens sikkerhed, support og skalerbarhed er vigtigere. Det afgørende er, at sikkerheden følger systemets reelle adgang til data, værktøjer og beslutninger.
Hvilke kilder ligger til grund?
Artiklen bygger især på OSI’s Open Source AI Definition, NISTs Generative AI Profile, OWASPs Top 10 for LLM Applications, NCSC/CISA’s retningslinjer for sikker AI-systemudvikling og Hugging Faces dokumentation om pickle scanning.