Sikkerhedsforanstaltninger for AI-drevne systemer er tekniske og organisatoriske kontroller, der beskytter data, modeller, integrationer og beslutningsflow. De bør dække hele livscyklussen fra design og udvikling til deployment, overvågning, hændelseshåndtering og løbende ændringskontrol.
Sikkerhedsforanstaltninger for AI-drevne systemer bør beskytte data, modeller, API'er, integrationer og drift som én samlet kæde. De centrale kontroller er adgangsstyring, dataminimering, input- og outputkontrol, supply chain-styring, logning, hændelseshåndtering, ansvarlig dokumentation og løbende teknisk ændringskontrol.
Hvad er sikkerhedsforanstaltninger for AI-drevne systemer?
Sikkerhedsforanstaltninger er de kontroller, der reducerer risikoen for uautoriseret adgang, datalækage, manipuleret modeladfærd, usikre output og svigt i drift. For AI-drevne systemer omfatter de både klassisk cybersikkerhed og kontroller, der tager højde for, at modellen kan påvirkes af data, input, kontekst og eksterne komponenter.
Et AI-system består sjældent kun af en model. Det kan også omfatte datakilder, embeddings, søgeindeks, API’er, brugerrettigheder, værktøjsadgange, logfiler, feedbackmekanismer og downstream-systemer. Derfor skal sikkerhedsforanstaltningerne beskytte hele kæden, ikke kun modelkaldet.
En praktisk tilgang er at behandle AI som et system med særlige risici, men ikke som et system uden almindelige sikkerhedskrav. Adgangsstyring, kryptering, sårbarhedsstyring, netværkssegmentering og backup er stadig grundlæggende. Det nye lag er kontrol af modeladfærd, dataproveniens, misbrugsscenarier og løbende drift.
Hvor bør sikkerheden begynde i designfasen?
Sikkerheden bør begynde med en afklaring af, om AI overhovedet er den rigtige løsning til opgaven. Hvis en regelbaseret proces, søgefunktion eller almindelig automatisering kan løse problemet med lavere risiko, bør den mulighed vurderes, før et mere komplekst AI-system bygges.
NCSC’s internationale vejledning for sikker AI-udvikling placerer trusselsmodellering, risikoforståelse og sikre designvalg tidligt i livscyklussen. Det betyder, at systemet bør designes med sikkerhed, funktionalitet, performance, brugeroplevelse, tilsyn og lovmæssige krav som samtidige hensyn.
I designfasen bør du definere systemets formål, godkendte brug, forbudte brug, datatyper, brugerroller, integrationspunkter og stopkriterier. Hvis AI-komponenten kan udløse handlinger, ændre filer, sende beskeder eller kalde eksterne systemer, bør disse handlinger begrænses fra starten.
Hvordan bør data beskyttes?
Data er ofte den mest følsomme del af et AI-drevet system. Beskyttelsen bør begynde med dataklassifikation: hvilke data må indsamles, hvilke må behandles af modellen, hvilke må gemmes i logs, og hvilke må aldrig sendes til eksterne tjenester?
Dataminimering er en central foranstaltning. Systemet bør kun sende de oplysninger, der er nødvendige for den konkrete opgave. Følsomme værdier kan i nogle tilfælde maskeres, pseudonymiseres eller filtreres, før de bruges i modelkald, søgeindeks eller testmiljøer.
Der bør også være klare regler for data i feedbacksløjfer. Brugerfeedback, rettelser og produktionsdata kan forbedre et system, men kan også indføre fejl, fortrolige oplysninger eller manipulerede eksempler. AI Mentors artikel om forebyggelse af datalækager i AI-applikationer uddyber dette kontrolområde.
Hvordan styres adgang til modeller og funktioner?
Adgangsstyring bør følge princippet om mindst mulige rettigheder. Brugere, udviklere, driftspersoner og eksterne integrationer skal kun have de adgange, de faktisk har brug for. Det gælder både data, modelkonfiguration, systeminstruktioner, API-nøgler, logfiler og administrative funktioner.
Rolleopdeling er særligt vigtig, når et AI-system kan påvirke beslutninger eller handlinger. Den person, der udvikler modellen, bør ikke nødvendigvis kunne ændre produktionsdata, godkende outputpolitikker og deaktivere overvågning. Kritiske ændringer bør kræve godkendelse, versionsspor og mulighed for rollback.
Adgangen til modelkald bør også begrænses teknisk. Rate limits, kvoter, brugerbinding, tokenstyring og overvågning af usædvanlige forespørgsler kan reducere risikoen for misbrug, modeludtræk, datalækage og denial of service-lignende belastning.
Hvilke kontroller reducerer model- og inputangreb?
Model- og inputangreb handler om at få systemet til at opføre sig anderledes end tilsigtet. OWASP beskriver blandt andet inputmanipulation, data poisoning, model inversion, membership inference, model theft, supply chain-angreb og model poisoning i sin liste over machine learning-risici.
For store sprogmodeller beskriver OWASP yderligere risici som instruktionsinjektion, usikker outputhåndtering, træningsdataforgiftning, læk af følsomme oplysninger, usikkert plugin-design, overdreven handlefrihed og modeltyveri. Kontrollerne bør derfor både se på input, modeladgang, output og de systemer, der bruger outputtet.
Praktiske foranstaltninger kan være inputfiltrering, kontekstafgrænsning, sikker outputvalidering, adskillelse mellem brugerdata og systeminstruktioner, test med manipulerede dokumenter, begrænsede værktøjsrettigheder og manuelle godkendelser for handlinger med høj konsekvens.
Hvordan beskyttes API’er og integrationer?
AI-drevne systemer er ofte forbundet til API’er, databaser, dokumentlagre, cloudtjenester og interne arbejdsgange. Hver integration øger angrebsfladen. Derfor bør systemet have stærk autentifikation, tydelig autorisation, hemmelighedshåndtering, netværksbegrænsning og separat logging for kald til eksterne systemer.
En AI-komponent bør ikke få bredere adgang, end dens opgave kræver. Hvis den kun skal læse et bestemt dokumentlager, bør den ikke kunne skrive til samme lager. Hvis den kan sende e-mails, oprette tickets eller køre kode, bør handlingerne være eksplicit begrænset, logget og i mange tilfælde godkendt af en bruger.
Ved brug af eksterne AI-API’er bør organisationen kontrollere, hvilke data der sendes ud, hvordan svar håndteres, og hvad der gemmes lokalt. AI Mentors forklaring af databeskyttelse ved brug af AI-API’er beskriver flere af de praktiske kontrolpunkter.
Hvordan håndteres supply chain-risiko?
AI-supply chain omfatter modeller, datasæt, softwarebiblioteker, containere, cloudtjenester, evalueringsværktøjer, tredjeparts-API’er og open source-komponenter. En sikkerhedsforanstaltning er derfor at have et samlet inventar over, hvilke komponenter systemet bygger på, hvem der vedligeholder dem, og hvordan ændringer godkendes.
NCSC anbefaler, at organisationer vurderer og monitorerer sikkerheden i AI-supply chains gennem hele livscyklussen og kræver, at leverandører følger relevante sikkerhedsstandarder. Ved eksterne modeller bør due diligence omfatte leverandørens sikkerhed, dokumentation, hændelseskanaler, databehandling og mulighed for alternative løsninger, hvis sikkerhedskrav ikke opfyldes.
Modelfiler, datasæt og artefakter bør behandles som aktive risikokilder. Hashes, signaturer, versionslåsning, sårbarhedsscanning og kontrollerede downloadkilder kan reducere risikoen for manipulerede komponenter. Det gælder især, når modeller eller serialiserede vægte hentes fra åbne repositories.
Hvordan bør logning og overvågning indrettes?
Logning skal gøre det muligt at forstå, hvad systemet gjorde, uden at skabe nye datalækager. En god logstrategi angiver, hvilke hændelser der logges, hvilke data der maskeres, hvor længe logs opbevares, hvem der må se dem, og hvordan de bruges ved hændelser.
Overvågning bør dække både tekniske og modelrelaterede signaler. Tekniske signaler kan være fejl, svartider, rate limit-brud, adgangsforsøg og ændringer i konfiguration. Modelrelaterede signaler kan være usædvanlige inputmønstre, afviste handlinger, stigende fejlrate, brug af risikofyldte funktioner eller tegn på ændret outputkvalitet.
NIST Cybersecurity Framework 2.0 placerer cybersikkerhed i funktionerne Govern, Identify, Protect, Detect, Respond og Recover. For AI-drevne systemer betyder det, at logning og overvågning ikke kun skal opdage angreb, men også støtte ansvar, prioritering, respons og genopretning.
Hvordan sikres drift og vedligeholdelse?
AI-systemer bør vedligeholdes som levende systemer. Modeller, datasæt, afhængigheder, sikkerhedskrav og brugsmønstre kan ændre sig. Derfor bør der være faste processer for patching, genvalidering, ændringsgodkendelse, modelrollback, sårbarhedsopfølgning og teknisk gæld.
Driftskontroller bør også omfatte modeldrift og datadrift. Hvis inputdata ændrer karakter, kan modellen blive mindre pålidelig. Hvis brugerne begynder at anvende systemet til nye formål, kan de oprindelige sikkerhedsantagelser ikke længere være dækkende. Monitorering bør derfor knyttes til både systemets tekniske tilstand og dets faktiske anvendelse.
En enkel ændringsregel er nyttig: ændringer i data, model, rettigheder, integrationspunkter eller formål bør udløse en risikovurdering. Små ændringer i et AI-system kan få stor betydning, hvis de påvirker beslutningsflow eller adgang til følsomme oplysninger.
Hvordan forberedes hændelseshåndtering?
Hændelseshåndtering for AI bør dække mere end almindelig nedetid. Planen bør beskrive, hvordan organisationen reagerer på datalækage, manipuleret input, usikre output, kompromitterede modelartefakter, leverandørhændelser, uventet modeladfærd og misbrug af integrationsrettigheder.
En brugbar plan angiver, hvem der kan sætte systemet i begrænset tilstand, stoppe modelkald, fjerne en datakilde, tilbagekalde nøgler, rulle en model tilbage og informere relevante interessenter. For kritiske funktioner bør der også være en alternativ proces, så organisationen ikke er tvunget til at fortsætte med et usikkert AI-system.
Hændelsesøvelser bør inkludere AI-specifikke scenarier. Det kan være en forgiftet vidensbase, et eksternt model-API med ændret adfærd, en bruger der forsøger at udtrække fortrolige oplysninger, eller en agentisk funktion der forsøger at udføre en handling uden tilstrækkelig godkendelse.
Hvilken rolle spiller dokumentation og ansvar?
Dokumentation er en sikkerhedsforanstaltning, fordi den gør systemet kontrollerbart. Uden dokumentation af data, modelvalg, integrationspunkter, rettigheder, test, begrænsninger og ændringer bliver det vanskeligt at opdage fejl, forklare beslutninger og placere ansvar.
NIST AI Risk Management Framework bruger funktionerne Govern, Map, Measure og Manage til at strukturere AI-risikostyring. Oversat til praksis betyder det, at organisationen bør kunne vise, hvem der ejer risikoen, hvilken kontekst systemet bruges i, hvordan risiko måles, og hvordan fund håndteres.
Dokumentation bør være detaljeret nok til drift og revision, men ikke fyldt med følsomme hemmeligheder. API-nøgler, adgangstokens og interne sikkerhedsvagter skal ikke ligge i åbne dokumenter. Der bør være klare regler for, hvad der dokumenteres, hvor det gemmes, og hvem der kan ændre det.
Hvordan hænger sikkerhedsforanstaltninger sammen med EU AI Act?
EU AI Act, Regulation (EU) 2024/1689, er relevant, fordi bestemte højrisiko-AI-systemer skal opfylde krav til blandt andet risikostyring, data governance, teknisk dokumentation, logning, menneskeligt tilsyn, nøjagtighed, robusthed og cybersikkerhed.
Forordningen gør ikke alle AI-drevne systemer til højrisiko-systemer. Alligevel kan kravene fungere som en nyttig tjekliste, når et system bruges i følsomme processer, påvirker borgere, medarbejdere eller kunder, eller integreres i beslutninger med væsentlig konsekvens.
Sikkerhedsforanstaltninger bør derfor kobles til systemets faktiske risikoniveau. En intern tekstassistent kræver andre kontroller end et system, der understøtter rekruttering, kredit, sundhed, kritisk infrastruktur eller offentlig sagsbehandling. AI Mentors artikel om sikkerhedsudfordringer ved generativ AI beskriver flere af de praktiske risici.
Hvordan prioriteres foranstaltningerne i praksis?
Prioriteringen bør begynde med risiko, ikke med en lang generisk tjekliste. De vigtigste spørgsmål er, hvilke data systemet behandler, hvilke handlinger det kan udløse, hvem der kan bruge det, hvilke eksterne komponenter det afhænger af, og hvad konsekvensen er, hvis output er forkert eller manipuleret.
| Risikotype | Første foranstaltning | Opfølgende kontrol |
|---|---|---|
| Følsomme data | Dataklassifikation og dataminimering | Maskering, adgangsrevision og logkontrol |
| Manipuleret input | Inputvalidering og kontekstafgrænsning | Test med kendte misbrugsscenarier og afvisningslog |
| Eksterne komponenter | Leverandør- og komponentinventar | Versionslåsning, sårbarhedsscanning og alternativ plan |
| Automatiske handlinger | Begrænsede rettigheder og brugerbekræftelse | Overvågning, rollback og hændelsesøvelser |
En moden kontrolpakke er trinvis. Start med data, adgang, integrationer og logning. Tilføj derefter AI-specifik test, leverandørstyring, modelovervågning og hændelsesøvelser. Når systemet ændrer formål eller konsekvensniveau, bør foranstaltningerne løftes med.
Hvilke kilder ligger til grund?
Artiklen bygger især på NCSC’s Guidelines for secure AI system development, NIST Cybersecurity Framework 2.0, NIST AI Risk Management Framework, OWASP Top 10 for Large Language Model Applications og EU AI Act.