Sikkerhedsudfordringer ved generativ AI

Sikkerhedsudfordringer ved generativ AI opstår, når modeller kan skabe tekst, kode, billeder eller beslutningsstøtte ud fra følsomme data, eksterne kilder og værktøjsadgang. De største risici handler om datalækage, instruktionsangreb, hallucinationer, supply chain, overdreven autonomi og manglende driftsovervågning.

Hvilke sikkerhedsudfordringer gør generativ AI anderledes end almindelig software?

Generativ AI er software, men den opfører sig ikke som klassisk deterministisk software. En traditionel applikation følger normalt faste regler, mens en generativ model producerer sandsynlige svar ud fra træningsmønstre, brugerinput og den kontekst, applikationen stiller til rådighed. Det gør sikkerhedsvurderingen mere afhængig af data, adfærd og anvendelsessituation.

Risikoen ligger ikke kun i modellen. Den ligger også i dokumenterne, modellen får adgang til, værktøjerne den kan kalde, rettighederne i brugerens konto, den vektordatabase den søger i, og de logs organisationen gemmer. En generativ AI-løsning er derfor bedst forstået som et system med mange sikkerhedsgrænser, ikke som en enkelt chatbot.

Den praktiske udfordring er, at generativ AI kan lyde sikker og korrekt, mens den stadig tager fejl, afslører data eller følger en angribers skjulte instruktioner. Det kræver kontroller, der ikke kun ser på kodefejl, men også på modeladfærd, dataflow, adgangsrettigheder og menneskelig godkendelse ved handlinger med høj konsekvens.

Hvor opstår risikoen i en generativ AI-løsning?

Risikoen opstår i hele livscyklussen. I designfasen handler den om, hvilke opgaver modellen må løse, og hvilke data den må se. I udviklingsfasen handler den om afhængigheder, modelvalg, testdata, evalueringssæt og sikker kode. I deployment handler den om adgangskontrol, netværk, logging og rollback. I drift handler den om overvågning, hændelser og løbende ændringer.

En model, der virker ufarlig i et testmiljø, kan blive risikabel, når den får adgang til interne dokumenter, e-mail, kundedata, tickets, kodebaser eller automatiserede værktøjer. Risikoen ændrer sig også, når systemet forbindes med retrieval, plugins, browseradgang, filsystem, API’er eller agentfunktioner.

En enkel måde at strukturere vurderingen på er at skelne mellem fire lag:

• Model laget, hvor fejl, hallucinationer, bias og uønsket adfærd kan opstå.
• Data laget, hvor følsomme oplysninger kan indsamles, gemmes, udledes eller deles.
• Applikationslaget, hvor input, output, værktøjer og brugerroller styres.
• Driftslaget, hvor logs, overvågning, opdateringer og incident response afgør, hvor hurtigt fejl opdages.

Hvis ét lag mangler kontrol, kan de andre lag ikke alene bære sikkerheden. En sikker model kan misbruges af en usikker integration, og en god integration kan svækkes af for brede datarettigheder.

Hvordan kan instruktionsangreb påvirke systemets handlinger?

Instruktionsangreb forsøger at få en generativ AI-løsning til at ignorere sine oprindelige regler, afsløre skjulte instruktioner, udlevere data eller bruge værktøjer på en måde, udvikleren ikke havde tænkt. Angrebet kan komme direkte fra en bruger eller indirekte fra en tekst, et dokument, en webside eller en e-mail, som modellen bliver bedt om at behandle.

Den indirekte variant er særlig relevant i løsninger med retrieval eller dokumentanalyse. Hvis et dokument indeholder skjulte instruktioner til modellen, kan systemet forveksle dokumentindhold med styrende instruktioner. Det er en anden type risiko end klassisk SQL-injektion, men princippet ligner: data og instruktioner blandes på en måde, angriberen kan udnytte.

Modforanstaltningen bør ikke være at stole på modellen alene. Applikationen bør adskille systemregler fra brugerdata, validere handlinger uden for modellen, begrænse værktøjsrettigheder, kræve godkendelse ved risikable handlinger og logge forsøg på omgåelse. AI Mentors forklaring af AI-sikkerhed mod jailbreaking uddyber denne type angreb og forsvar.

Hvad betyder datalækage og fortrolighed i praksis?

Datalækage ved generativ AI kan ske, når følsomme oplysninger sendes til en model, gemmes i logs, indgår i fine-tuning, indekseres i en vektordatabase eller gengives til en bruger uden korrekt rettighed. Risikoen afhænger derfor både af modelleverandør, deploymentform, dataklassifikation og adgangsstyring.

Fortrolighed handler ikke kun om, hvorvidt en ekstern leverandør træner på data. Det handler også om, om medarbejdere indsætter personoplysninger i en offentlig tjeneste, om interne dokumenter bliver tilgængelige gennem retrieval, om sessionsdata kan ses på tværs af brugere, og om logs opbevares længere end nødvendigt.

Før generativ AI bruges med følsomme data, bør du kortlægge dataflowet. Hvem sender data ind, hvor behandles de, hvor lagres de, hvem kan søge i dem, og hvordan slettes de igen? En mere specifik gennemgang findes i AI Mentors artikel om generativ AI og datafortrolighed.

Hvordan skaber hallucinationer en sikkerhedsrisiko?

Hallucinationer er ikke kun et kvalitetsproblem. De kan blive en sikkerhedsrisiko, når en model opfinder kildehenvisninger, fejlagtige procedurer, usikre kommandoer, forkerte adgangsregler, opdigtede sårbarheder eller misvisende opsummeringer af interne dokumenter. Risikoen stiger, når output bruges direkte i beslutninger eller automatiserede arbejdsgange.

Et eksempel er en generativ AI-assistent, der skal hjælpe et supportteam. Hvis den blander to kundesager sammen, kan den give en medarbejder et forkert svar, afsløre oplysninger fra en anden sag eller foreslå en handling, der ikke er godkendt. Problemet er ikke kun, at svaret er forkert; problemet er, at svaret kan se plausibelt ud.

Kontroller bør derfor omfatte kildevisning, begrænsning af modelens frihed ved faktuelle svar, menneskelig kontrol af risikable output og test med realistiske fejlscenarier. AI Mentors artikel om AI hallucinationer forklarer, hvorfor fejltypen ikke kan fjernes fuldstændigt, men kan reduceres og håndteres.

Hvilke risici følger med retrieval, embeddings og interne dokumenter?

Retrieval-augmented generation kan gøre generativ AI mere nyttig, fordi modellen kan søge i dokumenter i stedet for kun at svare ud fra generelle træningsmønstre. Samme arkitektur kan skabe nye sikkerhedsproblemer, hvis dokumenter indekseres for bredt, hvis adgangsrettigheder ikke følger med ind i søgelaget, eller hvis for mange tekstudsnit sendes til modellen.

Embeddings og vektordatabaser bør behandles som følsomme informationssystemer. Selvom embeddings ikke altid kan læses som almindelig tekst, kan de repræsentere betydning fra dokumenter, kundesager eller interne notater. De bør derfor beskyttes med adgangskontrol, slettepolitik, segmentering og logging på linje med andre datasystemer.

Den tekniske kontrol bør sikre, at brugeren kun kan hente dokumentudsnit, som vedkommende allerede har ret til at se. Derudover bør systemet kunne forklare, hvilke kilder et svar bygger på, og hvornår der ikke findes tilstrækkelig dokumentation. Uden den kontrol bliver retrieval-laget en mulig genvej rundt om organisationens almindelige adgangsmodel.

Hvordan kan generativ AI udvide angrebsfladen?

Generativ AI udvider angrebsfladen, når den kobles til systemer uden for selve chatvinduet. Det kan være e-mail, kalender, CRM, dokumentstyring, kodeværktøjer, økonomisystemer, kundeserviceplatforme eller cloud-administration. Jo flere systemer modellen kan læse fra eller skrive til, jo større bliver konsekvensen af en fejl.

Angrebsfladen består også af nye inputtyper. En bruger kan sende tekst, billeder, lyd, regneark eller dokumenter, og hvert format kan indeholde skadelig eller vildledende information. En angriber behøver ikke nødvendigvis bryde ind i serveren, hvis systemets normale inputkanaler kan få modellen til at udføre en uønsket handling.

Derfor bør generativ AI have mindst mulige rettigheder. Hvis en assistent kun skal opsummere dokumenter, bør den ikke kunne sende e-mails. Hvis den skal skrive udkast til kode, bør den ikke automatisk kunne deploye. Hvis den skal foreslå ændringer i et system, bør en bruger med passende rolle godkende ændringen uden for modellen.

Hvad betyder model- og datasupply chain for sikkerheden?

Model- og datasupply chain handler om alle komponenter, der påvirker systemets output: basis model, træningsdata, finjusteringsdata, modelartefakter, evalueringssæt, biblioteker, container-images, tokenizere, plugins og deployment-konfiguration. Et svagt led kan påvirke fortrolighed, integritet eller tilgængelighed.

For generativ AI er supply chain-risikoen mere omfattende end almindelig dependency-risiko. En model kan være trænet på problematiske data, et evalueringssæt kan være for smalt, et modelartefakt kan kræve usikker indlæsning, eller en tredjepartsintegration kan få for mange rettigheder. Derfor bør modelvalg dokumenteres som en del af sikkerhedsarbejdet.

En praktisk kontrol er at kræve provenance for modeller og data: hvor kommer komponenten fra, hvilken version bruges, hvilke ændringer er lavet, og hvilke kendte begrænsninger er dokumenteret? Sammen med hashværdier, signerede releases, scanning og isoleret testmiljø giver det et bedre grundlag for at opdage uventede ændringer.

Hvordan bør adgang til værktøjer og agenter begrænses?

Når generativ AI får adgang til værktøjer, bliver den ikke længere kun et svarsystem. Den kan foreslå, udløse eller forberede handlinger. Det kan være nyttigt i arbejdsgange med support, analyse, kodning eller rapportering, men det betyder også, at fejl kan få direkte konsekvenser i andre systemer.

Adgangen bør begrænses efter handlingens konsekvens. Læsning af offentlige oplysninger kræver få kontroller. Læsning af interne dokumenter kræver rollebaseret adgang. Ændring af data, udsendelse af beskeder, kørsel af kode eller sletning af indhold kræver stærkere godkendelse, auditspor og mulighed for at fortryde.

Generativ AI bør heller ikke få en generel servicekonto med brede rettigheder. Den bør bruge brugerkontekst, scoped tokens, korte sessioner og værktøjskald med tydelige parametre. Hvis modellen misforstår en instruktion, bør applikationen stadig kunne forhindre handlingen, fordi adgangsmodellen ligger uden for selve modellen.

Hvilke kontroller bør organisationer indføre før brug?

Før generativ AI bruges bredt, bør organisationen have en konkret kontrolramme. Den behøver ikke være tung for lavrisikoopgaver, men den skal være tydelig nok til, at medarbejdere, udviklere og ledere forstår, hvad systemet må bruges til, og hvilke data der ikke må indgå.

Kontrollerne bør kobles til AI-governance, så systemejer, risikoejer, datakrav og driftsansvar er tydelige. AI Mentors gennemgang af AI-governance beskriver den bredere styringsramme.

Hvordan bør drift, logging og incident response planlægges?

Drift af generativ AI kræver mere end oppetid. Organisationen skal kunne se, hvilke versioner der bruges, hvilke datakilder der er tilsluttet, hvilke værktøjer modellen kan kalde, og hvilke fejl eller uønskede handlinger der opstår. Uden den synlighed bliver det svært at skelne mellem brugerfejl, modelsvaghed, misbrug og egentlig sikkerhedshændelse.

Logging bør dække relevante hændelser uden at skabe ny datarisiko. Det kan være nødvendigt at logge tidspunkt, brugerrolle, modelversion, datakilde, værktøjskald og afviste handlinger, men ikke nødvendigvis hele brugerens indhold. Logdesignet bør derfor balancere fejlfinding, audit og dataminimering.

Incident response bør beskrive, hvordan systemet deaktiveres, hvordan en modelversion rulles tilbage, hvordan følsomme logs sikres, hvem der vurderer berørte brugere, og hvordan nye regler eller blokeringer deployes. AI Mentors artikel om AI-beredskabsplaner giver et praktisk udgangspunkt for den type forberedelse.

Hvordan vurderes risikoen i Danmark og EU?

For organisationer i Danmark og EU bør sikkerhedsarbejdet kobles til almindelige krav om databeskyttelse, cybersikkerhed, dokumentation og ansvarlig systemdrift. Det betyder ikke, at alle generative AI-systemer er højrisko-systemer, men at brugen bør vurderes efter data, formål, brugergruppe og mulig konsekvens.

EU-relevansen er særlig tydelig, når generativ AI bruges med personoplysninger, kritiske processer, medarbejderdata, uddannelse, offentlig forvaltning eller beslutningsstøtte. Her er det ikke nok at spørge, om modellen er teknisk imponerende. Du skal også kunne forklare, hvilke data den behandler, hvordan output kontrolleres, og hvem der ejer risikoen.

En forsigtig tilgang er at starte med lavrisikoopgaver, dokumentere erfaringer og udvide adgangen gradvist. Sikkerhed bør følge systemets faktiske betydning: jo mere modellen kan læse, beslutte eller gøre, jo stærkere skal kontrollerne være.

Hvilke kilder ligger til grund?

Artiklen bygger især på NISTs Generative AI Profile, NISTs taksonomi for adversarial machine learning, OWASPs Top 10 for LLM Applications, NCSC/CISA’s retningslinjer for sikker AI-systemudvikling og ENISAs rapport om AI-cybersikkerhedsudfordringer.