Etiske overvejelser i AI sikkerhed handler om at beskytte mennesker, data og organisationer uden at skjule ansvar bag tekniske kontroller. En sikker AI-løsning bør derfor vurderes på både robusthed, privatliv, bias, gennemsigtighed, menneskelig kontrol og proportionalitet, før den bruges i praksis.
Etisk AI-sikkerhed handler om at beskytte mennesker, data og ansvarlige beslutningsprocesser, ikke kun om tekniske angreb. Uddraget giver overblik over privatliv, bias, menneskelig kontrol, dokumentation og risikostyring, så AI-systemer kan vurderes mere forsvarligt før og efter drift.
Hvad betyder etik i AI sikkerhed?
Etik i AI sikkerhed betyder, at sikkerhedsarbejdet vurderer konsekvenserne af et AI-system, ikke kun om systemet er teknisk beskyttet mod angreb. Det omfatter spørgsmål om, hvem der kan blive påvirket, hvilke data der bruges, hvilke fejl der kan skade, og hvem der kan ændre, standse eller forklare systemets beslutninger.
En AI-model kan være godt beskyttet mod uautoriseret adgang og stadig give skadelige resultater, hvis den anvendes uden tydeligt formål, uden rimelige begrænsninger eller med data, der skaber systematiske skævheder. Omvendt kan et system være transparent, men stadig uforsvarligt, hvis det ikke er robust mod manipulation, datalækage eller misbrug.
Den praktiske pointe er, at sikkerhed og etik skal behandles som samme beslutningsrum. Når en organisation vurderer AI, bør spørgsmålet ikke kun være, om modellen virker, men om den virker under de betingelser, hvor mennesker faktisk skal stole på den.
Hvorfor er almindelig cybersikkerhed ikke nok?
Almindelig cybersikkerhed beskytter typisk fortrolighed, integritet og tilgængelighed i systemer, netværk og data. AI-systemer arver de risici, men tilføjer særlige problemer: modeller kan manipuleres gennem input, træningsdata kan forgiftes, output kan misforstås, og automatiserede handlinger kan få konsekvenser uden samme kontrol som klassisk software.
NIST beskriver troværdig AI som et samspil mellem validitet, pålidelighed, sikkerhed, resiliens, ansvarlighed, transparens, forklarbarhed, privatliv og fairness. Den afgrænsning viser, at teknisk beskyttelse kun er én del af et samlet sikkerhedsbillede.
Et AI-system bør derfor vurderes gennem både traditionelle sikkerhedskontroller og AI-specifikke kontroller. Det kan være test af modeladfærd, logging af kritiske beslutninger, adgangsstyring for værktøjer, dokumenteret datagrundlag, sikker håndtering af brugerinput og klare regler for, hvornår menneskelig godkendelse kræves.
Hvilke værdier skal sikkerhedskontroller beskytte?
Sikkerhedskontroller bør beskytte mere end systemets tekniske drift. De bør også beskytte de personer, organisationer og beslutningsprocesser, som AI-systemet påvirker. Det betyder, at kontroller skal kobles til værdier som privatliv, retfærdig behandling, forklarlighed, ansvar, proportionalitet og mulighed for at rette fejl.
En praktisk måde at arbejde på er at formulere hver sikkerhedskontrol som et beskyttet hensyn. Dataminimering beskytter privatliv. Adgangsstyring beskytter mod misbrug. Bias-test beskytter mod systematisk forskelsbehandling. Dokumentation beskytter ansvarlighed. Overvågning af modeldrift beskytter både brugere og organisation mod skjulte fejl over tid.
| Hensyn | Sikkerhedsspørgsmål | Praktisk kontrolpunkt |
|---|---|---|
| Privatliv | Indsamler systemet flere oplysninger end nødvendigt? | Dataminimering, kort opbevaringstid og begrænset adgang. |
| Fairness | Får bestemte grupper dårligere eller mere risikable resultater? | Test på relevante datasegmenter og dokumenterede afvigelser. |
| Ansvar | Kan en beslutning forklares og placeres hos en ansvarlig rolle? | Beslutningslog, modelkort, ejerskab og eskalationsvej. |
| Robusthed | Kan systemet manipuleres til farlige eller uønskede handlinger? | Red-teaming, inputfiltre, værktøjsbegrænsning og fail-safe. |
Hvordan afvejes sikkerhed mod privatliv?
AI-sikkerhed kan skabe et privatlivsproblem, hvis organisationen indsamler for mange data for at overvåge, analysere eller forbedre systemet. Logfiler, prompts, brugerprofiler, dokumentuploads og outputhistorik kan være nyttige til fejlfinding, men de kan også indeholde personoplysninger, forretningshemmeligheder eller følsomme oplysninger.
Afvejningen bør starte med formålet. Hvis en log bruges til sikkerhed, bør den kun indeholde de oplysninger, der er nødvendige for at opdage misbrug, rekonstruere hændelser og forbedre kontroller. Den bør ikke blive et sekundært datalager, hvor flere personer end nødvendigt kan læse brugernes indhold.
Ved brug af AI-API’er er adgang til data et centralt kontrolpunkt. Relevante valg kan være pseudonymisering, fravalg af træning på kundedata, begrænsning af promptindhold, kryptering, databehandleraftaler, udløbsdatoer for logs og særskilte miljøer til test og produktion. Se også AI Mentors forklaring af, hvordan data beskyttes ved brug af AI API’er.
Hvornår bliver overvågning en etisk risiko?
Overvågning er nødvendig i mange AI-systemer, fordi modeller kan ændre praktisk adfærd, når data, brugsmønstre eller integrationer ændrer sig. Risikoen opstår, når overvågningen bliver bredere end formålet, eller når den gør det uklart for brugere og medarbejdere, hvad der registreres og hvorfor.
En etisk forsvarlig overvågningsmodel bør skelne mellem sikkerhedslogning, performanceovervågning og personovervågning. Sikkerhedslogning kan registrere tekniske hændelser, adgangsforsøg og usædvanlig systemadfærd. Performanceovervågning kan måle fejltyper og outputkvalitet. Personovervågning kræver en særlig begrundelse, fordi den kan påvirke tillid, autonomi og arbejdsforhold.
Du kan bruge tre kontrolspørgsmål: Hvilket konkret problem skal overvågningen opdage? Hvem må se data? Hvornår slettes eller aggregeres oplysningerne? Hvis svarene er uklare, er overvågningen sandsynligvis ikke moden nok til drift.
Hvordan håndteres bias som sikkerhedsproblem?
Bias er ikke kun et kvalitetsproblem. I AI-sikkerhed kan bias blive en sikkerhedsrisiko, fordi systematiske fejl kan ramme bestemte grupper, forværre beslutninger eller skjule svagheder i testgrundlaget. NIST skelner blandt andet mellem systemisk bias, statistisk bias og menneskelig-kognitiv bias, hvilket gør det utilstrækkeligt kun at kigge på modeloutput i gennemsnit.
Bias bør vurderes i den kontekst, hvor AI-systemet bruges. Et system til intern videnssøgning kræver andre test end et system, der prioriterer henvendelser, filtrerer ansøgere eller markerer sikkerhedshændelser. Jo mere konsekvens et output kan få for mennesker, desto mere dokumenteret bør vurderingen være.
Konkrete kontroller kan være segmenteret performanceanalyse, gennemgang af datakilder, test for skæve fejltyper, menneskelig appelvej og løbende evaluering efter drift. AI Mentor har en særskilt gennemgang af håndtering af bias i AI, som passer naturligt ind i sikkerhedsarbejdet.
Hvordan bør ansvar placeres i AI-systemer?
Ansvar bør placeres hos konkrete roller, ikke hos modellen som abstrakt teknologi. En model kan generere forslag, klassificere data eller udføre handlinger gennem værktøjer, men organisationen skal stadig definere, hvem der ejer formålet, datagrundlaget, sikkerhedskontrollerne, beslutningsreglerne og hændelseshåndteringen.
Et brugbart ansvarsbillede skelner mellem systemejer, dataejer, risikoejer, teknisk driftsansvarlig, sikkerhedsansvarlig og den rolle, der må godkende brug i produktion. I mindre organisationer kan samme person have flere roller, men rollerne bør stadig beskrives, så ansvar ikke forsvinder mellem udvikling, drift og forretning.
Ansvar kræver også sporbarhed. Hvis et AI-system træffer eller understøtter en væsentlig beslutning, bør det være muligt at se inputtype, systemversion, væsentlige regler, menneskelig godkendelse og tidspunkt. Sporbarhed er ikke det samme som fuld modelindsigt, men den gør det muligt at undersøge fejl og forbedre kontroller.
Hvilke risici kræver tekniske sikkerhedstiltag?
OWASP’s arbejde med LLM-applikationer viser, at generativ AI har velkendte tekniske risici, som bør behandles direkte. Det omfatter blandt andet instruktionsinjektion, usikker outputhåndtering, forgiftede træningsdata, model denial of service, sårbar forsyningskæde, lækage af følsomme oplysninger, usikkert plugin-design, for høj autonomi, overafhængighed og modeltyveri.
Den etiske dimension er, at disse risici ikke kun handler om tab af systemkontrol. De kan føre til lækage af private data, fejlagtig automatisering, uretmæssig adgang, vildledende beslutningsgrundlag eller skjult manipulation. Derfor skal tekniske kontroller knyttes til konsekvensen for mennesker og organisation, ikke kun til sandsynligheden for et angreb.
Relevante sikkerhedstiltag kan være begrænset værktøjsadgang, adskillelse mellem systeminstruktioner og brugerdata, outputvalidering, sikker policyhåndtering, rate limits, sandboxing, hemmelighedsscanning, modelmonitorering og krav om menneskelig godkendelse ved irreversible handlinger. For generelle standarder og protokoller kan du også se AI-sikkerhedsprotokoller og standarder.
Hvordan testes et AI-system etisk forsvarligt?
Etisk forsvarlig test handler om at finde de fejl, der har betydning i den konkrete anvendelse. Det er ikke nok at teste, om modellen svarer pænt i en demonstrationssituation. Testen bør dække kendte angrebstyper, forventede brugsscenarier, grænsetilfælde, misbrug, databeskyttelse, bias, forklarbarhed og systemets reaktion, når det ikke bør svare eller handle.
En praktisk testplan kan opdeles i fire lag. Først testes datagrundlag og adgang. Dernæst testes modeladfærd med normale og fjendtlige input. Tredje lag tester integrationer, værktøjer og outputhåndtering. Fjerde lag tester drift, logging, hændelser og rollback. Hvert lag bør have kendte acceptkriterier og stopkriterier.
Test bør også gentages efter væsentlige ændringer. En ny modelversion, et nyt plugin, ændrede datakilder eller en ny brugergruppe kan ændre risikobilledet, selv om den tekniske arkitektur ser uændret ud. Derfor bør test kobles til releaseprocessen og til periodiske audits. AI Mentor beskriver samme disciplin i konteksten sikkerhedsaudit for AI og machine learning-projekter.
Hvad skal en organisation dokumentere?
Dokumentation bør gøre det muligt at forstå, hvorfor AI-systemet bruges, hvilke risici der er accepteret, hvilke kontroller der er valgt, og hvem der kan ændre beslutningen. Den bør være praktisk nok til drift og præcis nok til revision, hændelseshåndtering og ledelsesbeslutninger.
For et AI-system kan dokumentationen typisk omfatte formål, forventede brugere, datakilder, model- og leverandøroplysninger, kendte begrænsninger, sikkerhedskontroller, testresultater, menneskelig kontrol, databeskyttelse, incident-proces, ændringslog og kriterier for at stoppe eller nedskalere systemet. ISO/IEC 42001 beskriver AI-ledelse som et ledelsessystem, hvor organisationen etablerer, vedligeholder og løbende forbedrer styringen af AI.
EU’s AI Act gør dokumentation særlig central for højrisikosystemer, men dokumentationsdisciplinen er nyttig også uden for formelle højrisikokategorier. Den reducerer risikoen for, at en AI-løsning bliver afhængig af enkeltpersoners tavse viden eller uformelle antagelser.
Hvordan bruges menneskelig kontrol uden symbolsk ansvar?
Menneskelig kontrol virker kun, hvis mennesket har tid, kompetence, information og reel mulighed for at ændre resultatet. Hvis en medarbejder blot trykker godkend på et AI-output uden indblik i datagrundlag, modelbegrænsninger eller konsekvens, er kontrollen mere symbolsk end reel.
God menneskelig kontrol kræver en klar opgavefordeling. AI-systemet kan sortere, foreslå eller fremhæve usikkerhed, mens mennesket vurderer kontekst, undtagelser og konsekvens. I risikofyldte processer bør mennesket også kunne se, hvorfor systemet foreslår en handling, hvilke begrænsninger der gælder, og hvordan en sag kan eskaleres.
Kontrollen bør designes ind i arbejdsgangen. Det kan være krav om ekstra godkendelse ved høj konsekvens, automatisk blokering ved lav sikkerhedsscore, adgang til relevante kilder, mulighed for at markere fejl og en proces for at ændre systemet, når fejl gentager sig.
Hvordan omsættes principper til drift?
Principper bliver først nyttige, når de omsættes til beslutninger i hverdagen. En organisation kan starte med at kortlægge AI-systemer, datakilder, brugere, værktøjsadgange og mulige konsekvenser. Derefter bør hvert system placeres i en risikokategori, så kontrollerne passer til konsekvensen ved fejl eller misbrug.
En enkel driftsmodel kan følge rækkefølgen: afklar formål, kortlæg påvirkede personer, vælg dataminimering, test modeladfærd, begræns adgang, dokumentér ansvar, etabler overvågning, definer stopkriterier og gentag vurderingen efter ændringer. Det svarer til den iterative tankegang i NIST’s Govern, Map, Measure og Manage-funktioner.
AI-sikkerhed bør også kobles til eksisterende sikkerhedsarbejde. Incident response, leverandørstyring, adgangskontrol og change management behøver ikke opfindes på ny, men de skal udvides til AI-risici som modeladfærd, hallucinationer, dataafledning, instruktionsangreb, for høj autonomi og uklare menneskelige godkendelser. Se også AI Mentors gennemgang af risikostyring i AI-implementeringer.
Hvornår bør et AI-system ikke sættes i drift?
Et AI-system bør ikke sættes i drift, hvis organisationen ikke kan forklare formålet, afgrænse databrugen, placere ansvar, måle centrale fejltyper eller stoppe systemet ved uacceptabel adfærd. Det gælder især, hvis systemet påvirker adgang til ydelser, ansættelse, økonomi, sundhed, sikkerhed eller andre væsentlige forhold.
Stopkriterier bør defineres før lancering. Eksempler kan være uacceptabel fejlrate i en kritisk brugergruppe, dokumenteret datalækage, gentagne brud på værktøjsgrænser, manglende forklaring i højkonsekvenssager, uafklaret leverandørrisiko eller manglende evne til at håndtere indsigelser fra berørte personer.
Et nej til drift er ikke nødvendigvis et nej til AI. Det kan være en beslutning om at begrænse brugen, flytte systemet til intern test, fjerne automatiske handlinger, reducere datatilgang eller kræve yderligere dokumentation. Den etiske opgave er at vælge det laveste risikoniveau, der stadig løser den konkrete opgave.
Hvilke kilder ligger til grund?
Artiklen bygger især på NIST’s beskrivelse af AI-risici og troværdighed og NIST AI RMF Core, hvor risikostyring organiseres gennem Govern, Map, Measure og Manage.
De tekniske LLM-risici er kontrolleret mod OWASP Top 10 for Large Language Model Applications. Regulerings- og ledelsesperspektivet er holdt op mod Regulation (EU) 2024/1689 og ISO/IEC 42001.