Styrkelse af AI-modeller mod angreb handler om at mindske risikoen for, at en model eller AI-applikation kan manipuleres, lække data eller udføre uønskede handlinger. Robusthed kræver både modeltest, datakontrol, adgangsbegrænsning, overvågning og klare beslutninger om, hvor meget handlefrihed systemet må få.
Robusthed mod AI-angreb kræver mere end en stærkere model. Det afgørende er at styre data, værktøjsadgang, test, overvågning og menneskelig godkendelse, så manipulation, datalækage og uønskede handlinger begrænses i hele AI-systemet fra kildevalg til drift.
Hvilke angreb skal AI-modeller beskyttes imod?
AI-modeller kan angribes på flere tidspunkter i deres livscyklus. Et angreb kan ramme træningsdata, modelvægte, finjustering, embeddings, modelens svar, de værktøjer modellen kan kalde, eller den applikation, som modellen er bygget ind i. Derfor er det upræcist kun at tale om en stærk eller svag model. Den konkrete risiko afhænger af, hvordan modellen bruges.
NIST opdeler adversarial machine learning i angrebstyper, mål og livscyklusfaser. For klassiske maskinlæringsmodeller handler det ofte om manipulation af input, forgiftning af data, udtræk af private oplysninger eller kopiering af modeladfærd. For generative modeller kommer der ekstra risici, fordi modellen kan modtage instruktioner i naturligt sprog, hente kontekst fra eksterne kilder og udføre handlinger gennem værktøjer.
De mest praktiske risikokategorier er tilgængelighed, integritet, fortrolighed og misbrug. Tilgængelighed handler om, at systemet fortsat kan give brugbare svar. Integritet handler om, at svaret ikke bliver styret af angriberen. Fortrolighed handler om, at data, systeminstruktioner eller modelinformation ikke lækkes. Misbrug handler om, at modellen hjælper med handlinger, som systemet egentlig skulle afvise.
Hvorfor er selve modellen kun en del af angrebsfladen?
En moderne AI-løsning består sjældent kun af en model. Den omfatter typisk brugergrænseflade, API, adgangsstyring, logning, filhåndtering, database, RAG-kilder, vektordatabase, orkestrering, eksterne værktøjer og driftsovervågning. Angriberen behøver ikke nødvendigvis at bryde selve modellen. Det kan være nok at manipulere det materiale, modellen får ind, eller de handlinger, dens svar får lov at udløse.
Den vigtigste arkitekturregel er at behandle modeloutput som et usikkert input, ikke som en autoritativ beslutning. Hvis et AI-system må skrive til en database, sende beskeder, starte betalinger, ændre adgangsrettigheder eller køre kode, skal disse handlinger have selvstændige sikkerhedskontroller uden for modellen. Det gælder også, når modellen normalt svarer korrekt.
AI Mentor har beslægtede sikkerhedsemner om beskyttelse mod AI-system-hacking og AI-sikkerhedsprotokoller og standarder. De peger på samme grundprincip: sikkerheden skal placeres i systemdesignet, ikke kun i forventningen om, at modellen opfører sig pænt.
Hvordan adskiller direkte, indirekte og forsyningskædebaserede angreb sig?
Direkte instruktionsangreb sker, når brugeren selv forsøger at få modellen til at ignorere systemets regler, afsløre skjulte instruktioner, producere uønsket output eller bruge et værktøj forkert. Angrebet kan ligne almindelig dialog, oversættelse, rollespil, kodning, analyse eller opsummering. Det gør det svært at stoppe med simple ordlister.
Indirekte instruktionsangreb sker gennem materiale, som modellen henter eller får vist. Det kan være en webside, e-mail, PDF, billede, supportticket, kodefil, kalenderinvitation eller RAG-kilde. Brugeren kan tro, at modellen blot analyserer et dokument, mens dokumentet indeholder skjulte instruktioner, der forsøger at ændre modellens adfærd. Risikoen stiger, når modellen både læser eksternt indhold og kan udføre handlinger.
Forsyningskædeangreb rammer det, modellen eller applikationen bygger på. Det kan være et manipuleret datasæt, en usikker modelpakke, en kompromitteret dependency, en ondsindet plugin, en sårbar filparser eller en tredjepartsmodel med bagdørsadfærd. NIST fremhæver, at AI-systemer både arver almindelige softwaresårbarheder og får nye afhængigheder i data, modelartefakter og evaluering.
| Angrebspunkt | Typisk risiko | Praktisk kontrol |
|---|---|---|
| Brugerinput | Modellen presses til at bryde regler eller lække information | Afgræns opgaver, valider output og kræv godkendelse ved risikohandlinger |
| Eksterne kilder | Dokumenter eller websider kan styre modellens svar | Marker kilder som utroværdige data og begræns deres indflydelse |
| Trænings- og finjusteringsdata | Forgiftede data kan ændre adfærd eller skabe bagdøre | Spor datakilder, versioner datasæt og test for uventede mønstre |
| Værktøjer og API’er | Et manipuleret svar kan udløse uønskede handlinger | Brug least privilege, faste skemaer og deterministiske godkendelser |
Hvilke kontroller reducerer risikoen før modellen tages i brug?
Før en AI-model sættes i produktion, bør organisationen afklare formål, datatyper, adgangsniveau og konsekvens ved fejl. En model, der kun foreslår tekst til intern gennemgang, kræver andre kontroller end en agent, der kan opdatere kundedata eller kalde interne systemer. Robusthed starter med at begrænse, hvad modellen overhovedet må påvirke.
En praktisk før-brug-kontrol kan bestå af fem spørgsmål: Hvilke data må modellen se? Hvilke kilder må den hente kontekst fra? Hvilke handlinger må den foreslå, og hvilke må den udføre? Hvem godkender højrisikooutput? Hvilke logs gør det muligt at forstå, hvorfor systemet handlede, som det gjorde?
Der bør også være en eksplicit grænse for uegnede opgaver. Hvis et svar kan få juridisk, økonomisk, sundhedsfaglig eller sikkerhedskritisk betydning, skal modellen normalt bruges som beslutningsstøtte med menneskelig kontrol, ikke som selvstændig beslutningstager. Det er ikke en svaghed ved AI; det er en sikkerhedsgrænse.
Hvordan bør data og RAG-kilder kontrolleres?
RAG kan gøre en AI-løsning mere relevant, fordi modellen svarer på baggrund af konkrete dokumenter eller databaser. Samtidig flytter RAG en del af angrebsfladen til de kilder, der hentes ind i konteksten. Hvis en angriber kan placere eller ændre indhold i kilden, kan vedkommende forsøge at påvirke modellens svar indirekte.
Datakilder bør derfor klassificeres efter tillid. Interne, godkendte dokumenter, brugeruploadede filer, åbne websider og tredjepartsdatabaser bør ikke behandles ens. Et dokument fra en ukendt kilde bør ikke kunne ændre systemets regler eller udløse handlinger, selv om modellen kan læse dokumentets indhold. Den skelnen skal håndhæves i applikationslogik, ikke kun i tekstlige instruktioner til modellen.
Gode kontroller omfatter kildegodkendelse, filtypebegrænsning, scanning af dokumenter, versionering, adgangsfiltrering, citatkrav og test af, om kildemateriale kan få modellen til at ignorere brugerens egentlige opgave. Ved følsomme oplysninger bør der også være regler for dataminimering og lækageforebyggelse, som beskrevet i AI Mentors artikel om forebyggelse af datalækager i AI-applikationer.
Hvordan styrkes en model under træning og finjustering?
Træning og finjustering kan forbedre robusthed, men de kan også indføre nye risici. Et datasæt kan være skævt, ufuldstændigt, forældet eller manipuleret. En finjustering kan gøre modellen bedre til en bestemt opgave, men samtidig mere tilbøjelig til at reproducere følsomme oplysninger eller følge uønskede mønstre fra træningsmaterialet.
Datastyring er derfor en teknisk sikkerhedsopgave. Organisationen bør kende datakilder, licensforhold, versioner, filtrering, kvalitetskrav og ændringshistorik. For åbne datasæt bør man kontrollere, om data hentes fra stabile og verificerbare kilder. For interne datasæt bør man fjerne unødvendige personoplysninger, hemmeligheder, adgangsnøgler og interne instruktioner, før materialet bruges til træning eller evaluering.
Finjusterede modeller bør testes mod både normale opgaver og angrebsforsøg. Det gælder især triggerord, uventede formater, flersprogede instruktioner, payload-splitting, ondsindede dokumenter og forsøg på at få modellen til at afsløre fortrolig kontekst. Resultatet bør sammenlignes med en baseline, så man kan se, om en ny version faktisk reducerer risikoen eller blot ændrer dens form.
Hvorfor er adgangsrettigheder afgørende i AI-applikationer?
En model med brede rettigheder gør et vellykket angreb mere alvorligt. Hvis modellen kun kan foreslå et svar, er skaden typisk begrænset til fejlinformation eller arbejdsspild. Hvis modellen kan sende e-mails, slette filer, opdatere CRM-data eller kalde interne API’er, kan samme manipulerede output føre til konkret driftsskade.
Least privilege bør derfor være standard. AI-komponenten skal have separate tekniske identiteter, begrænsede scopes, korte levetider for tokens og tydelige grænser for, hvilke systemer den kan nå. Værktøjskald bør ske gennem faste skemaer med parameterkontrol, ikke gennem fri tekst, der direkte oversættes til handlinger. Ved følsomme handlinger bør systemet kræve menneskelig godkendelse eller en anden uafhængig regelmotor.
OWASP fremhæver excessive agency som en central risikoklasse for LLM-baserede systemer. Pointen er ikke, at AI aldrig må bruge værktøjer. Pointen er, at handlefrihed skal være snæver, sporbar og proportional med opgaven. Det samme princip går igen i kontrol af AI-modeller mod misbrug.
Hvordan testes robusthed uden at skabe falsk tryghed?
Robusthedstest bør kombinere almindelige funktionskrav med målrettede angrebstest. Det er ikke nok at kontrollere, om modellen svarer korrekt på pæne eksempler. Testen skal også undersøge, hvordan systemet reagerer på modstridende instruktioner, manipulerede dokumenter, støjfyldte input, uventede sprog, store filer, skjult tekst og forsøg på at udtrække kontekst.
Red teaming kan bruges til at finde svagheder, men resultaterne skal fortolkes nøgternt. En test, der ikke finder fejl, er ikke bevis for robusthed. Den viser kun, at de konkrete testangreb ikke lykkedes under de givne betingelser. NIST peger på, at evaluering af afbødninger er vanskelig, blandt andet fordi benchmarks ofte ikke er direkte sammenlignelige.
En god testpakke bør have versionerede cases, kendte forventninger, risikoscore, regressionstest og tydelig kobling til systemets tilladte handlinger. Når modellen, datakilderne eller værktøjerne ændres, bør testene køres igen. Det gør robusthed til en driftsdisciplin frem for en engangsøvelse.
Hvilken rolle spiller overvågning og incident response?
Selv stærke forebyggende kontroller bør suppleres med overvågning. AI-systemer kan fejle på måder, der ikke ligner klassiske applikationsfejl. Relevante signaler kan være usædvanlige værktøjskald, gentagne afvisningsforsøg, pludselige ændringer i svarlængde, ukendte datakilder, mistænkelige dokumenter, høj fejlrate eller brugere, der systematisk tester grænser.
Logs skal være nyttige uden at gemme flere følsomme oplysninger end nødvendigt. Det kan være relevant at logge modelversion, inputtype, kilde-id, værktøjskald, beslutningsstatus, sikkerhedsafvisninger og menneskelige godkendelser. For persondata og forretningskritiske data bør logningen afstemmes med organisationens databeskyttelseskrav.
Incident response bør beskrive, hvad organisationen gør, hvis en AI-løsning lækker data, udfører en uønsket handling eller begynder at svare systematisk forkert. Det kan omfatte midlertidig deaktivering af værktøjer, tilbagekaldelse af tokens, fjernelse af kompromitterede datakilder, rollback til tidligere modelversion, brugerinformation og efterfølgende rodårsagsanalyse.
Hvordan balanceres nøjagtighed, robusthed og brugervenlighed?
Der findes ikke en gratis sikkerhedsknap, som gør AI-modeller maksimalt præcise, robuste, private, fair, hurtige og billige på samme tid. NIST beskriver, at robusthed kan stå i spænd med andre egenskaber som nøjagtighed, fairness og forklarbarhed. Det betyder, at risikostyring skal være konkret for det enkelte system.
Hvis en model bruges til kreativ idéudvikling, kan man acceptere mere variation og lavere kontrol. Hvis den bruges til sagsbehandling, sikkerhedsanalyse eller datatræk, bør kravene til sporbarhed, kildegrundlag og menneskelig kontrol være højere. Brugervenlighed må ikke forveksles med sikkerhed; en friktionsfri agent kan være effektiv, men også sværere at begrænse, når noget går galt.
En moden risikovurdering beskriver derfor både ønsket nytte og accepteret rest-risiko. Den bør forklare, hvilke angreb der er mest relevante, hvilke kontroller der er valgt, hvilke kontroller der bevidst er fravalgt, og hvilke situationer der kræver manuel behandling. AI Mentors artikel om risikostyring i AI-implementeringer dækker den bredere organisatoriske ramme.
Hvordan kan en organisation arbejde praktisk med modellen over tid?
Styrkelse af AI-modeller mod angreb bør organiseres som en gentagende proces. Start med at kortlægge model, data, værktøjer, brugere og konsekvenser ved fejl. Prioriter derefter de angreb, der realistisk kan skade systemet. Implementer kontroller tæt på den risiko, de skal reducere: datakontrol ved kilderne, adgangskontrol ved værktøjerne og overvågning i driften.
- Kortlæg hvilke AI-komponenter, datakilder og værktøjer løsningen bruger.
- Definer hvilke handlinger modellen aldrig må udføre uden ekstern kontrol.
- Adskil utroværdigt indhold fra systemregler og beslutningslogik.
- Test både almindelige brugerflows og målrettede angrebsforsøg.
- Overvåg driftssignaler, værktøjskald og ændringer i modeladfærd.
- Opdater kontroller, når model, data, leverandør eller trusselsbillede ændrer sig.
Den praktiske succes afhænger ofte af ejerskab. Sikkerhedsteamet kan ikke alene definere acceptabel modeladfærd, og udviklere kan ikke alene vurdere forretningskonsekvensen af fejl. En robust AI-løsning kræver fælles beslutninger mellem produktansvarlige, dataejere, udviklere, sikkerhedsfolk og de medarbejdere, der bruger systemet i hverdagen.
Hvilke kilder ligger til grund?
Artiklen bygger især på NIST-rapporten Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, som samler en taksonomi for angreb og afbødninger mod AI-systemer.
For LLM-applikationer er risikoklasser og kontroller sammenholdt med OWASP Top 10 for LLM Applications 2025. Den praktiske forsigtighed omkring LLM-baserede tjenester er desuden sammenholdt med NCSC’s vejledning om LLM-baserede tjenester og MITRE ATLAS som trusselsramme for AI-specifikke angrebsteknikker.