AI sikkerhedsprotokoller og standarder er de fælles regler, kontroller og dokumentationskrav, der gør AI-systemer mere sikre gennem hele livscyklussen. De bør dække ledelse, risikovurdering, databeskyttelse, modeltest, leverandørstyring, adgangskontrol, logning, hændelseshåndtering og løbende overvågning efter idriftsættelse.
AI-sikkerhed kræver både klassiske informationssikkerhedsstandarder og AI-specifikke protokoller for data, modeller, test og drift. Fokus er at forbinde ISO-, NIST- og sikre udviklingsrammer med konkrete kontroller for adgang, logning, leverandører, agenthandlinger, hændelser og løbende risikovurdering.
Hvad er AI-sikkerhedsprotokoller og standarder?
AI-sikkerhedsprotokoller er de konkrete arbejdsgange og tekniske kontroller, der styrer, hvordan et AI-system må bygges, testes, tilsluttes og bruges. Standarder er de mere formelle referencekrav, som hjælper organisationen med at dokumentere, at kontrollerne er systematiske, gentagelige og forankret i ansvar.
En protokol kan for eksempel beskrive, hvordan træningsdata godkendes, hvordan en model må forbindes til interne systemer, hvordan fejl rapporteres, eller hvordan en ny modelversion testes før drift. En standard kan beskrive krav til ledelsessystem, risikostyring, adgangskontrol, hændelseshåndtering eller dokumentation.
Forskellen er praktisk: Standarden siger, hvilke krav der bør være dækket. Protokollen siger, hvordan organisationen faktisk gør det. En AI-løsning bliver først robust, når begge niveauer hænger sammen med sikkerhedsforanstaltninger for AI-drevne systemer, som kan testes og gentages.
Hvorfor kan almindelig it-sikkerhed ikke stå alene?
Almindelig it-sikkerhed er stadig nødvendig, men AI-systemer har risici, som ikke altid passer ind i klassiske kontroller. En database kan sikres med adgangsrettigheder og kryptering, men en AI-model kan også fejle gennem forkerte træningsdata, svage evalueringer, uventet adfærd i drift, manipulation af brugerinput eller output, der bruges ukritisk i en beslutning.
AI-systemer er ofte sammensatte. De kan bestå af model, datalager, embeddings, API’er, agenter, brugergrænseflade, værktøjskald, tredjepartsmodeller, integrationskode og menneskelig efterkontrol. Hver del kan være teknisk sikker isoleret, mens den samlede arbejdsgang stadig skaber risiko, hvis data flyder for bredt, modellen får for mange rettigheder, eller output bruges uden kontrol.
Derfor bør AI-sikkerhed koble klassisk cybersikkerhed med modelstyring, datastyring og menneskelig ansvarlighed. Det er ikke nok at beskytte serveren. Organisationen skal også vide, hvad modellen må gøre, hvilke data den må bruge, hvordan fejl opdages, og hvornår et menneske skal overtage.
Hvilke standarder dækker ledelse og risikostyring?
De mest relevante standarder og rammer kan opdeles i fire grupper. Først kommer ledelsesstandarder, som placerer ansvar, politikker og løbende forbedring. Dernæst kommer cybersikkerhedsrammer, som organiserer kontroller for identifikation, beskyttelse, detektion, respons og genopretning. Tredje gruppe er AI-risikostyring, hvor modeladfærd, data, måling og governance vurderes. Fjerde gruppe er applikationsnære sikkerhedsrammer for konkrete AI-sårbarheder.
ISO/IEC 27001 bruges til informationssikkerhedsledelse. ISO/IEC 42001 retter sig mod ledelsessystemer for AI og beskriver, hvordan organisationer kan etablere, vedligeholde og forbedre styring af AI-systemer. NIST AI Risk Management Framework giver en ikke-sektorspecifik struktur for at styre AI-risici gennem hele livscyklussen.
Ingen af rammerne er en færdig opskrift på en bestemt AI-løsning. De fungerer som referencepunkter. Organisationen skal stadig oversætte dem til interne roller, kontroller, test, leverandørkrav og beslutningsgrænser, der passer til den konkrete anvendelse.
Hvordan passer ISO/IEC 27001 og ISO/IEC 42001 sammen?
ISO/IEC 27001 handler om informationssikkerhedsledelse. Den passer til spørgsmål om fortrolighed, integritet, tilgængelighed, adgang, risikovurdering, leverandører, hændelser og forbedring. ISO/IEC 42001 handler om ledelsessystemer for AI. Den passer til spørgsmål om ansvarlig AI-udvikling, brug, governance og AI-relaterede risici.
For en organisation med AI i drift bør standarderne ikke ses som konkurrenter. ISO/IEC 27001 kan bære det generelle sikkerhedssystem, mens ISO/IEC 42001 kan tilføje de AI-specifikke processer: formål med systemet, roller i AI-livscyklussen, datakvalitet, modelovervågning, dokumentation, påvirkning af mennesker og kontroller for uforudset modeladfærd.
| Standard | Primært fokus | AI-relevant brug |
|---|---|---|
| ISO/IEC 27001 | Informationssikkerhedsledelse | Adgangskontrol, risikostyring, leverandører, hændelser og beskyttelse af data |
| ISO/IEC 42001 | AI-ledelsessystem | Styring af AI-systemer, ansvar, risici, dokumentation og løbende forbedring |
| Kombineret brug | Sikker AI-drift | Fælles kontroller for data, model, systemintegration, mennesker og drift |
En moden opsætning kan lade ISO/IEC 27001 definere det generelle sikkerhedsniveau og lade ISO/IEC 42001 udfylde hullerne omkring AI-specifik risikostyring. Det gør sikkerhedsarbejdet lettere at auditere, fordi AI ikke bliver et separat sideprojekt uden forbindelse til organisationens øvrige kontroller.
Hvordan omsættes NIST-rammer til AI-kontroller?
NIST AI RMF kan bruges til at sortere AI-sikkerhedsarbejdet i fire praktiske spørgsmål: Hvordan styres arbejdet? Hvad er systemets kontekst og risici? Hvordan måles og testes systemet? Hvordan håndteres og reduceres risiko i drift? Den opdeling hjælper især, når AI-systemet har mange aktører og skiftende datakilder.
NIST Cybersecurity Framework kan samtidig bruges til den klassiske sikkerhedsstruktur: identificer aktiver og risici, beskyt systemer, opdag hændelser, reager på hændelser og genopret normal drift. Når den kombineres med AI RMF, bliver resultatet en kontrolmodel, der dækker både software, infrastruktur, data, modeladfærd og menneskelig brug.
En praktisk oversættelse kan være at knytte hver AI-anvendelse til en risikoprofil. Profilen bør beskrive formål, datakilder, brugergrupper, modeltype, integrationer, beslutningskonsekvenser, evalueringsmetoder, logkrav og grænser for automatisering. Det gør det lettere at gentage en sikkerhedsaudit for AI- og machine learning-projekter uden at starte forfra hver gang.
Hvilke protokoller bør findes før udvikling?
Før udvikling bør organisationen have en protokol for formål, risikoklasse og datagrundlag. Protokollen bør afklare, hvilken opgave systemet skal løse, hvilke personer der kan blive påvirket, hvilke data der må bruges, hvilke data der er udelukket, og hvilke beslutninger systemet ikke må træffe uden menneskelig kontrol.
Der bør også findes en protokol for modelvalg. Den skal beskrive, om løsningen bruger en ekstern model, en lokal model, en specialtrænet model eller en kombination. Den bør dække modelversion, licens, kendte begrænsninger, evalueringsgrundlag, leverandørvilkår, databehandling, opbevaring og mulighed for at fravælge træning på organisationsdata.
Endelig bør udviklingsprotokollen definere godkendte miljøer. Testdata, træningsdata og produktionsdata bør holdes adskilt. Hemmeligheder, adgangsnøgler og personoplysninger bør ikke ligge i eksempelkode, testfiler eller delte notebooks. Den slags grundkontrol er mindre synlig end modeltest, men den afgør ofte, om AI-projektet kan drives sikkert.
Hvordan sikres data, modeller og leverandørkæder?
Data skal sikres fra indsamling til sletning. Det omfatter kildekontrol, adgangsstyring, dataklassifikation, dataminimering, kvalitetstjek, rettighedsafklaring og dokumenteret sletning. For AI bør datakontrollen også dække, om data kan afsløre personer, forretningshemmeligheder, sikkerhedsoplysninger eller ophavsretligt beskyttet materiale.
Modeller skal sikres som kritiske komponenter. Det gælder især modelvægte, konfigurationsfiler, evalueringssæt, systeminstruktioner, embeddings og forbindelser til værktøjer. En model kan være værdifuld, men også sårbar over for lækage, tyveri, manipulation eller utilsigtet adgang til data gennem output.
Leverandørkæden bør vurderes med samme alvor som softwareafhængigheder. Tredjepartsmodeller, datasæt, biblioteker, containerimages, plug-ins og integrationsservices kan hver især ændre risikobilledet. En AI-løsning bør derfor have en opdateret komponentoversigt, versionering og klare krav til leverandørens hændelsesrapportering.
Hvordan håndteres input, output og agenthandlinger?
Inputkontrol handler om at begrænse, validere og klassificere det, brugeren sender ind i systemet. Hvis et AI-system kan modtage fritekst, filer, billeder, mails eller dataudtræk, bør der være regler for størrelse, filtype, følsomme oplysninger, skadeligt indhold og instruktioner, der forsøger at få systemet til at omgå sine egne grænser.
Outputkontrol handler om, hvad systemet må returnere, og hvordan svaret må bruges. En model kan producere fejlagtige fakta, usikre anbefalinger, personoplysninger, kode med sårbarheder eller beslutningsstøtte, der virker mere sikker, end den er. Derfor bør kritiske output valideres, filtreres eller sendes til menneskelig gennemgang, før de får virkning.
Agenthandlinger kræver ekstra kontrol, fordi systemet ikke kun svarer, men også kan udføre handlinger. Det kan være at oprette sager, sende beskeder, ændre data, kalde API’er eller bestille ydelser. Jo mere handlekraft systemet har, desto strengere bør grænserne være for godkendelse, logning, rollback og adskillelse mellem foreslået handling og faktisk handling.
Hvilke test og evalueringer bør gentages?
AI-test bør ikke være en enkelt godkendelse før lancering. Modeller, data, brugsmønstre og trusler ændrer sig. Derfor bør evalueringer gentages ved nye modelversioner, nye datakilder, nye integrationer, nye brugergrupper og væsentlige ændringer i arbejdsgangen.
Testprogrammet bør mindst dække datalækage, adgangsgrænser, modstandsdygtighed mod manipulerede input, fejlagtige svar, usikker kodegenerering, bias, drift i modeladfærd, overforbrug af ressourcer, misbrug af værktøjskald og fejl i menneskelig efterkontrol. For højere risiko bør test også omfatte realistiske angrebsscenarier og uafhængig gennemgang.
Resultaterne bør dokumenteres med testdato, modelversion, datasæt, metode, fund, risikovurdering og beslutning. Dermed bliver styrkelse af AI-modeller mod angreb en løbende disciplin frem for en engangsopgave.
Hvordan dokumenteres ansvar, logning og hændelser?
Ansvar bør dokumenteres for hele AI-livscyklussen. Der bør være navngivne ejere for data, model, applikation, infrastruktur, leverandørrelation, sikkerhedsgodkendelse og forretningsbeslutning. Uden klare ejere bliver hændelser langsomme at håndtere, fordi ingen har fuldt mandat til at lukke adgang, ændre konfiguration eller stoppe en AI-funktion.
Logning bør vise, hvad systemet gjorde, ikke kun at en bruger var logget ind. Relevante logfelter kan være brugerrolle, datakilde, modelversion, værktøjskald, outputkategori, beslutningsstatus, fejl, afvisninger og efterfølgende menneskelig godkendelse. Logningen skal samtidig begrænses, så den ikke selv bliver et lager af unødvendige personoplysninger eller hemmeligheder.
Hændelsesprotokollen bør forklare, hvordan organisationen håndterer dataeksponering, modelmisbrug, fejlbehæftet output, leverandørhændelser, kompromitterede adgangsnøgler og uventede agenthandlinger. Den bør også beskrive, hvornår systemet skal sættes i begrænset drift, og hvordan brugere informeres om ændrede begrænsninger.
Hvordan påvirker EU’s AI Act standardarbejdet?
EU’s AI Act er ikke en teknisk standard, men den påvirker standardarbejdet, fordi den bruger en risikobaseret tilgang til AI-systemer. Højrisiko-AI kan kræve dokumentation, risikostyring, datastyring, logging, gennemsigtighed, menneskeligt tilsyn, robusthed, cybersikkerhed og nøjagtighed. Det gør interne standarder og protokoller lettere at knytte til konkrete regulatoriske krav.
For organisationer i eller med brugere i EU bør AI-systemer derfor klassificeres tidligt. En intern AI-standard bør mindst skelne mellem lavrisiko-værktøjer, generelle produktivitetsværktøjer, systemer med persondata, systemer der påvirker væsentlige beslutninger, og systemer der kan falde i højrisikokategorier. Klassifikationen bestemmer, hvor stærk dokumentation og kontrol der kræves.
AI Act ændrer ikke behovet for klassisk sikkerhed, men den øger behovet for sporbar dokumentation. Hvis en organisation ikke kan forklare formål, data, modelversion, risici, test, tilsyn og hændelser, bliver det svært at vise, at sikkerhedsprotokollerne faktisk virker.
Hvilken moden rækkefølge bør organisationen følge?
En moden rækkefølge begynder med overblik og ender med løbende drift. Det første trin er et AI-register, hvor alle kendte AI-systemer, datakilder, ejere, leverandører og integrationer registreres. Derefter kan organisationen klassificere risiko og vælge kontroller efter systemets faktiske konsekvenser.
- Opret et register over AI-systemer, modeller, datakilder og integrationer.
- Klassificér hvert system efter datafølsomhed, beslutningspåvirkning og handlekraft.
- Vælg relevante standarder og rammer for ledelse, sikkerhed og AI-risiko.
- Definér protokoller for data, modelvalg, udvikling, test, drift og hændelser.
- Indfør adgangsstyring, logning, leverandørkontrol og slettefrister.
- Test systemet mod realistiske fejl- og misbrugsscenarier.
- Gennemgå output, brugeradfærd og hændelser efter idriftsættelse.
- Opdater kontroller ved nye modelversioner, nye datakilder og ændrede regler.
Rækkefølgen gør standardarbejdet praktisk. Først skabes overblik. Derefter vælges kontroller. Til sidst bliver kontrollerne testet i drift. Det er også her, AI-sikkerhed mod jailbreaking og kontrol af AI-modeller mod misbrug bør indgå som konkrete test- og overvågningsområder.
Hvilke kilder ligger til grund?
Standarddelen bygger på ISO’s officielle sider om ISO/IEC 42001 og ISO/IEC 27001, som dækker henholdsvis AI-ledelsessystemer og informationssikkerhedsledelse.
Risikostyringen er afstemt med NIST AI Risk Management Framework og UK NCSC’s guidelines for secure AI system development, især livscyklus, logging, overvågning og vedligeholdelse.
De AI-specifikke applikationsrisici er holdt op mod OWASP Top 10 for Large Language Model Applications, mens regulatorisk kontekst er kontrolleret mod EU’s AI Act-overblik.