En sikkerhedsaudit for AI og machine learning projekter er en systematisk kontrol af data, modeller, kode, infrastruktur, adgangsstyring og drift. Formålet er at finde tekniske og organisatoriske svagheder, før systemet giver fejlagtige, usikre eller ulovlige beslutningsgrundlag.
En sikkerhedsaudit for AI og machine learning bør dække data, model, integrationer, adgangsstyring og drift samlet. Den giver overblik over trusselsmodel, leverandørrisici, robusthedstest, logning og dokumentation, så tekniske fund kan omsættes til konkrete prioriterede handlinger.
Hvad er en sikkerhedsaudit for AI og machine learning?
En sikkerhedsaudit undersøger, om et AI-system er bygget, trænet, integreret og drevet på en måde, der passer til den risiko, systemet skaber. Den adskiller sig fra en almindelig it-revision ved også at se på datasæt, modeladfærd, modelversioner, evalueringer, feedbacksløjfer og de mennesker, der kan påvirke systemets output.
I et machine learning-projekt kan en fejl opstå længe før softwaren sættes i drift. Træningsdata kan være ufuldstændige, en model kan være for følsom over for bestemte input, eller en leverandørkomponent kan ændre adfærd uden at resten af systemet ændres. Auditens værdi ligger derfor i at samle sikkerhed, data governance og driftskontrol i samme vurdering.
En moden audit ser både på intention og bevis. Det er ikke nok, at projektet har en politik for adgang, test eller overvågning. Auditsporet skal vise, hvem der havde adgang til data og modeller, hvilke kontroller der blev udført, hvad resultaterne viste, og hvordan fund blev prioriteret.
Hvornår bør auditten gennemføres?
Auditten bør ikke placeres som en enkelt afsluttende kontrol. For AI-projekter giver det mere mening at arbejde med flere auditpunkter: før data bruges, før modeltræning eller finjustering, før integration i et produktionsmiljø og efter væsentlige ændringer i data, model, leverandør eller brugsmønster.
Et tidligt auditpunkt kan afsløre, at datasættet indeholder personoplysninger, forretningshemmeligheder eller licensbelagt materiale, som projektet ikke har styr på. Et senere auditpunkt kan vise, om modellen reagerer stabilt på kanttilfælde, om logningen kan bruges til fejlfinding, og om beredskabsplanen faktisk kan gennemføres.
Auditten bør også gentages, når systemet lærer videre, når en ekstern model opdateres, eller når løsningen får nye brugergrupper. AI-systemer kan ændre risikoprofil, selvom brugergrænsefladen ser uændret ud.
Hvilket scope skal en AI-audit have?
Scope bør beskrive hele systemet, ikke kun selve modellen. Det omfatter datakilder, databehandling, feature engineering, træningsmiljø, modelartefakter, instruktionslag, API’er, adgangsrettigheder, logning, monitorering, brugerroller og integrationer til andre systemer.
Hvis systemet bruger en ekstern model, skal auditten også dække leverandørafhængigheder. Det gælder modelvilkår, databehandling, ændringshistorik, rate limits, sikkerhedsdokumentation, incident-kanaler og tekniske muligheder for at begrænse, hvad modellen må modtage og returnere. Se også AI Mentors forklaring af databeskyttelse ved brug af AI-API’er.
Et klart scope forhindrer to typiske fejl. Den ene er en for snæver kodegennemgang, hvor model- og datarisici overses. Den anden er en for bred modenhedsvurdering, hvor ingen konkrete sårbarheder bliver testet.
Hvordan adskiller AI-sikkerhed sig fra traditionel applikationssikkerhed?
Traditionel applikationssikkerhed handler ofte om kendte mønstre som adgangskontrol, inputvalidering, kryptering, patching og sikker konfiguration. De kontroller er stadig nødvendige, men AI-systemer tilføjer risici, som kommer fra data, statistisk usikkerhed, modeladfærd og samspil med brugere.
OWASP Machine Learning Security Top Ten beskriver blandt andet inputmanipulation, data poisoning, model inversion, membership inference, model theft, supply chain-angreb og model poisoning. For store sprogmodeller tilføjer OWASP kategorier som instruktionsinjektion, usikker outputhåndtering, excessive agency og overreliance.
Det betyder, at en audit skal teste både systemets tekniske angrebsflade og modellens beslutningsadfærd. En model kan være hostet i en sikker infrastruktur og stadig lække følsomme mønstre, reagere ustabilt på manipulerede input eller blive brugt til handlinger, som projektet ikke har godkendt.
Hvilke data- og modelspor skal dokumenteres?
En audit bør kunne følge data fra kilde til output. Det omfatter oprindelse, tilladelse til brug, klassifikation, datarensning, mærkning, transformationer, frasortering, opdeling i træning og test samt dokumentation for væsentlige datasætændringer. Uden dette spor bliver det vanskeligt at forklare, hvorfor en model opfører sig, som den gør.
Modelsporet bør beskrive modeltype, version, træningskørsel, hyperparametre, evalueringsresultater, kendte begrænsninger og godkendte anvendelser. Hvis organisationen bruger finjustering, retrieval augmented generation eller en agentisk integration, bør disse lag dokumenteres særskilt, fordi de kan ændre risikoen uden at grundmodellen ændres.
Data- og modelspor er også et kontrolpunkt for datalækager. Interne dokumenter, personoplysninger eller adgangsnøgler må ikke ende i træningsdata, brugerinput, logfiler eller fejlbeskeder. AI Mentors artikel om forebyggelse af datalækager i AI-applikationer uddyber denne del af risikobilledet.
Hvordan bør trusselsmodellen bygges?
Trusselsmodellen bør tage udgangspunkt i systemets konkrete brug, ikke i en generisk liste over AI-risici. Først beskrives aktiverne: data, model, instruktionslag, API-nøgler, brugerrettigheder, beslutningsflow og downstream-systemer. Derefter beskrives mulige aktører, herunder eksterne angribere, uautoriserede brugere, fejlkonfigurerede integrationer og leverandørhændelser.
For AI-systemer bør trusselsmodellen også beskrive angreb, hvor input ikke ligner klassisk malware. Eksempler er manipulerede brugerforespørgsler, forgiftede dokumenter i en vidensbase, ændrede træningsdata, forsøg på at udtrække modelinformation eller systeminstruktioner, og output, der får et andet system til at udføre en uønsket handling.
EU AI Act nævner i kravene til højrisiko-AI, at tekniske løsninger efter omstændighederne skal adressere data poisoning, model poisoning, adversarial examples eller model evasion, confidentiality attacks og model flaws. Det gør ikke alle AI-systemer til højrisiko-systemer, men det viser, hvilke sårbarhedstyper en seriøs audit bør tage stilling til.
Hvilke kontroller bør auditten teste?
Kontrollerne bør vælges efter systemets risiko, men en praktisk audit vil typisk dække identitet og adgang, dataklassifikation, hemmelighedshåndtering, modeladgang, input- og outputfiltrering, sikker konfiguration, logging, monitorering, sårbarhedsstyring og change management.
| Kontrolområde | Hvad auditten undersøger | Typisk bevis |
|---|---|---|
| Data | Om data er lovligt, relevant, klassificeret og beskyttet gennem hele pipeline | Datakatalog, adgangslog, rensningsregler og datasætversioner |
| Model | Om modellen er evalueret mod kendte risici, begrænsninger og misbrugsscenarier | Modelkort, testresultater, red-team-fund og godkendt anvendelsesområde |
| Applikation | Om integrationen validerer input, håndterer output sikkert og begrænser handlinger | Kodegennemgang, konfiguration, adgangsregler og sikkerhedstest |
| Drift | Om ændringer, hændelser og modeldrift opdages hurtigt nok | Logpolitik, alarmer, dashboards, runbooks og incident-øvelser |
Kontrollerne bør være testbare. En formulering som “systemet er sikkert” er ikke et auditbevis. En bedre formulering er, at kun navngivne roller kan ændre modelkonfiguration, at ændringer logges, og at uautoriserede ændringsforsøg udløser en alarm.
Hvordan testes robusthed og modeladfærd?
Robusthedstest undersøger, om systemet reagerer stabilt på forventede, uventede og manipulerede input. I et klassifikationssystem kan det være støj, kanttilfælde, skæve datagrupper eller forsøg på at omgå modellen. I en sprogmodelapplikation kan det være instruktionsinjektion, skjulte instruktioner i dokumenter eller output, der forsøger at påvirke et downstream-system.
Testen bør knyttes til systemets formål. En chatbot med adgang til interne dokumenter skal ikke evalueres på samme måde som en billedmodel, der sorterer fejl i produktion. Auditspørgsmålet er, om testen dækker de risici, systemet faktisk har, og om fejl fører til begrænsning, menneskelig gennemgang eller sikker afvisning.
Robusthed er ikke kun et tal. Nøjagtighed kan se høj ud i et samlet gennemsnit, mens modellen fejler i en bestemt brugergruppe, datakilde eller situation. Auditrapporten bør derfor skelne mellem samlet performance, kendte svagheder, sikkerhedstest og resterende risiko.
Hvordan vurderes leverandører og open source-komponenter?
Mange AI-projekter bygger på eksterne modeller, open source-biblioteker, datasæt, vector databases, cloudtjenester og API-integrationer. Auditten bør derfor undersøge software bill of materials, model- og datasætlicenser, afhængigheder, kendte sårbarheder, opdateringsrutiner og hvem der kan ændre komponenter i værdikæden.
NISTs generative AI-profil fremhæver behovet for leverandørinventar, godkendte teknologilister, hændelsesplaner for tredjepartssystemer og løbende monitorering af generative AI-systemer i drift. Det er relevant, fordi en ændring hos en leverandør kan påvirke output, databehandling eller tilgængelighed uden en traditionel kodeændring i eget repository.
Open source kan være sikkert og gennemsigtigt, men auditten bør ikke sidestille offentlig kildekode med kontrolleret risiko. Der bør være styr på versionslåsning, vedligeholdelse, sårbarhedsfeeds, downloadkilder og hvem der må godkende nye model- eller biblioteksversioner.
Hvordan hænger audit sammen med governance og standarder?
NIST AI Risk Management Framework beskriver AI-risikostyring gennem funktionerne Govern, Map, Measure og Manage. Det giver en nyttig ramme for auditten: hvem har ansvar, hvad er konteksten, hvordan måles risikoen, og hvordan styres den efter fundene?
ISO/IEC 42001:2023 beskriver krav til et ledelsessystem for kunstig intelligens for organisationer, der leverer eller bruger AI-baserede produkter eller services. Standarden kan bruges som organisatorisk referencepunkt, men en audit bør stadig teste konkrete tekniske kontroller og faktiske beviser i projektet.
For organisationer, der arbejder med AI i regulerede eller kritiske processer, bør auditten også kobles til intern risikostyring. Det kan omfatte godkendelsesfora, modelregistre, ændringsråd, databeskyttelsesvurderinger og klare stopkriterier, når modellen ikke længere opfører sig inden for aftalte grænser. Se også AI Mentors oversigt over AI-sikkerhedsprotokoller og standarder.
Hvilken betydning har EU-regler for auditten?
EU AI Act, Regulation (EU) 2024/1689, er relevant for auditplanlægning, fordi forordningen opstiller krav til bestemte højrisiko-AI-systemer. Kravene omfatter blandt andet risikostyring, datastyring, teknisk dokumentation, logning, transparens, menneskeligt tilsyn samt nøjagtighed, robusthed og cybersikkerhed.
En sikkerhedsaudit er ikke i sig selv en juridisk compliance-vurdering. Den kan dog levere tekniske og organisatoriske beviser, som senere kan bruges i compliancearbejde: risikoregister, testprotokoller, adgangslog, modeldokumentation, hændelsesplaner og dokumenterede beslutninger om restrisiko.
Hvis du auditerer et system, der kan være højrisiko efter EU AI Act, bør scope afklares tidligt med de ansvarlige for jura, informationssikkerhed, data protection og forretning. AI Mentors artikel om sikkerhedsforanstaltninger for AI-drevne systemer giver en praktisk vinkel på kontrollerne.
Hvordan ser en anvendelig auditrapport ud?
En anvendelig auditrapport er kort nok til at blive brugt og præcis nok til at kunne efterprøves. Den bør beskrive scope, metode, systemafgrænsning, datakilder, modelversioner, testmiljø, fund, risiko, anbefalet handling, ansvarlig ejer og frist.
Fund bør prioriteres efter konkret risiko, ikke efter hvor teknisk interessante de er. En manglende adgangsbegrænsning til træningsdata kan være mere alvorlig end en lav score i en modeltest, hvis datasættet indeholder følsomme oplysninger. Omvendt kan en tilsyneladende lille modelsvaghed være kritisk, hvis output automatisk udløser handlinger.
Rapporten bør også dokumentere, hvad der ikke er testet. Det beskytter mod falsk tryghed og gør næste audit mere effektiv. Hvis leverandørens modelvægte, træningsdata eller interne sikkerhedstest ikke er tilgængelige, bør det stå som en begrænsning, ikke skjules i en generel godkendelse.
Hvordan omsættes fund til bedre AI-sikkerhed?
Auditten skaber først værdi, når fund bliver omsat til beslutninger. En enkel handlingsplan bør beskrive, hvilke risici der lukkes straks, hvilke der accepteres midlertidigt, hvilke der kræver arkitekturændringer, og hvilke der gør, at systemet ikke bør sættes i drift endnu.
Gode opfølgninger har en tydelig ejer og et beviskrav. Hvis fundet handler om instruktionsmanipulation, kan beviset være nye testcases, ændret dokumenthåndtering, begrænset værktøjsadgang og logning af afviste instruktioner. Hvis fundet handler om datalækage, kan beviset være dataminimering, maskering, adgangsrevision og en test af, at følsomme værdier ikke sendes til modellen.
AI-sikkerhed bør behandles som løbende drift. Når data, brugere, modeller eller integrationer ændrer sig, bør risikoregister, testpakker og monitorering ændres med. AI Mentors oversigt over risikostyring i AI-implementeringer uddyber forbindelsen mellem tekniske fund og organisatoriske beslutninger.
Hvilke kilder ligger til grund?
Artiklen bygger især på NIST AI Risk Management Framework, NISTs Generative AI Profile, OWASP Machine Learning Security Top Ten, EU AI Act og ISO’s oversigt over ISO/IEC 42001.