AI-sikkerhed: Det er ikke bare IT-sikkerhed med et nyt navn

Vi stod for nylig hos en offentlig kunde og så deres chatbot blive narret til at udlevere interne instrukser. Det var ikke et hackerangreb i klassisk forstand. Ingen SQL-injektion, ingen brute force. Bare et par snedige sætninger, og så var systemprompten frit tilgængelig. Det slog mig: AI-sikkerhed er ikke længere noget, man kan overlade til de gamle IT-sikkerhedsværktøjer. De fleste risici handler ikke om fejl i selve modellen, men om hvordan AI’en er bygget ind i resten af systemet.

Compound AI-systemer: Hvorfor lagene gør det farligt

De fleste tror, at AI-sikkerhed handler om at beskytte modellen. Men i praksis er det hele systemet, der er sårbart. Når vi taler compound AI, mener vi systemer, hvor LLM’en (Large Language Model) kun er ét lag. Ovenpå ligger system prompts, Retrieval-Augmented Generation (RAG), memory, tools, måske agenter. Hvert lag åbner for nye angreb. En lille fejl i memory-laget kan forplante sig og give adgang til følsomme data. Vi har set eksempler, hvor en uskyldig prompt i et dokument får hele systemet til at ignorere sikkerhedsinstrukser. Det er ikke sjældent.

De 10 største AI-sikkerhedsrisici – og hvordan det går galt i praksis

OWASP LLM Top 10 for 2025 rammer hovedet på sømmet. Her er de vigtigste risici – og et par cases, vi selv har set eller hørt om:

• Prompt injection: En bruger skjuler en kommando i et dokument, og pludselig lyver chatbotten bevidst.
• Sensitive information disclosure: Chatbotten afslører PII fra tidligere samtaler.
• Supply chain vulnerabilities: En open source-model med skjult bias eller bagdør.
• Data/model poisoning: En offentlig dataset bliver forurenet, så modellen giver farlige råd.
• Improper output handling: LLM’en genererer HTML, der bliver til XSS-angreb på websitet.
• Excessive agency: En AI-agent får lov at slette eller sende filer uden kontrol.
• System prompt leakage: Brugeren beder om at se systemets instrukser – og får dem.
• Vector/embedding weaknesses: Manipulerede vektordata får chatbotten til at linke til falske sider.
• Misinformation: LLM’en opfinder domme, som jurister bruger i retten.
• Unbounded consumption: En bruger får AI’en til at generere 500.000 sider og løber firmaets API-budget tør.

Det overrasker mig stadig, hvor ofte det ikke er selve modellen, men integrationen, der fejler. Vi har aldrig set en ren LLM, der var farlig uden at være koblet til noget andet.

Praktiske værktøjer: Garak, Giskard og test af non-text modeller

Vi får tit spørgsmålet: “Hvordan tester man AI-systemer for sikkerhed?” Her er det korte svar: Brug Garak, hvis du vil angribe og se, hvor det går galt. Brug Giskard, hvis du vil tjekke for bias, robusthed og hallucinationer. Vi har selv brugt Garak til at finde jailbreaks i en kundes chatbot – det tog 10 minutter at finde en sårbarhed, de ikke anede eksisterede. For non-text modeller, som billed- eller lyd-AI, er Foolbox og IBM ART de bedste bud. De kan simulere angreb, der ikke kan ses eller høres af mennesker. Det er lidt uhyggeligt, faktisk.

Sådan ser en AI-sikkerhedstest ud i praksis

En typisk pipeline for AI-sikkerhedstest starter med trusselmodellering: Hvor kan data flyde forkert? Hvilke lag har adgang til hvad? Dernæst kommer automatiserede tests (Garak, Giskard), efterfulgt af manuel gennemgang og monitorering efter deployment. Vi har lavet et diagram til flere kunder, der viser, hvordan man kobler testværktøjerne ind i CI/CD-pipelinen. (Jeg gider ikke gå ned i detaljen her, men spørg hvis du vil se det.)

Governance, compliance og risikostyring – hvad kræver loven?

AI-sikkerhed er ikke kun teknik. Dokumentation er afgørende, især hvis du arbejder med GDPR, NIS2 eller ISO 42001. Vi anbefaler altid at lave en simpel risikolog, hvor du dokumenterer: Hvilke data bruges? Hvem har adgang? Hvilke tests er kørt? Det gør audit langt nemmere. En tjekliste til ansvarlig AI-governance bør inkludere:

• Data mapping og klassificering
• Adgangskontrol og logging
• Test- og valideringsprotokoller
• Incident response-plan
• Løbende monitorering

Vi har set flere offentlige organisationer, der først får styr på governance, når de står midt i et datalæk. Det er for sent.

Designprincipper: Sikkerhed fra start i compound AI

Hvis du bygger compound AI, så adskil lagene. Giv kun adgang, hvor det er nødvendigt. Minimal agency – AI’en skal ikke kunne slette filer, hvis den kun skal læse dem. Brug adgangskontrol på tværs af hele pipelinen. Vi har hjulpet en kunde med at integrere LLM i deres databehandlingspipeline, hvor alle API-kald blev logget og valideret, og kun nødvendige permissions blev givet. Det er ikke raketvidenskab, men det kræver disciplin.

Konkrete råd til CISO, DevOps og dataansvarlige

Lad os gøre det praktisk:

• CISO/IT-sikkerhed: Dokumentér alle integrationer, lav audit trails, sæt kontrolpunkter ind i pipelinen.
• DevOps/udviklere: Brug open source-værktøjer som Garak og Giskard, automatisér tests, og hold koden adskilt fra prompts og data.
• Dataansvarlige: Lav en tjekliste over følsomme data, tjek for datalæk, og sørg for compliance fra dag ét.

Vi har set flere DevOps-teams, der først indså problemet, da AI’en begyndte at generere mærkelige outputs på live-data. Det er ikke sjovt at stå med i produktion.

Hvad gør man nu? Tre hurtige skridt til at komme i gang

Hvis du vil i gang med AI-sikkerhed, så start her:

• Lav en hurtig trusselmodel af jeres AI-systemer – hvor er de svage punkter?
• Indfør automatiserede sikkerhedstests i jeres CI/CD-pipeline.
• Dokumentér dataflows, adgang og testresultater – det gør compliance meget lettere.

AI-sikkerhed kræver nye vaner. Det er ikke nok at tænke “det klarer IT”. Du skal tænke sikkerhed ind i design, udvikling og drift. Vi har oplevet, at forskellen først bliver tydelig, når man sidder med det i hænderne – og opdager, hvor hurtigt det kan gå galt.

Kilder:

• https://towardsai.net/p/machine-learning/your-llm-is-not-broken-your-ai-system-is
• https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf
• https://owaspai.org/docs/5_testing/
• https://www.giskard.ai/
• https://www.databricks.com/trust/ai-security

Målgruppens mening om artiklen

Anders Mikkelsen, CISO i større offentlig organisation: Jeg giver artiklen 92. Den rammer plet ift. de udfordringer, vi står med i praksis, især i forhold til compound AI-systemer og integrationen mellem lagene. Jeg kunne dog godt have ønsket mig lidt mere om konkrete governance-eksempler fra det offentlige, men den er meget anvendelig og relevant for mit arbejde.

Maria Sørensen, DevOps lead i fintech-startup: Jeg giver den 85. Det er super, at der nævnes værktøjer som Garak og Giskard, og at der er fokus på automatiserede tests og CI/CD. Jeg synes dog, at nogle af rådene er lidt generelle, og jeg savner mere hands-on eksempler på, hvordan man faktisk integrerer sikkerhed i DevOps-processen.

Jonas Thomsen, Data Protection Officer i region: Jeg giver den 78. Artiklen er god til at forklare risici og compliance-krav, men jeg synes, at GDPR og dataansvar kunne være uddybet mere. Det er dog positivt, at der er fokus på dokumentation og risikolog, hvilket er noget, vi kæmper med til daglig.

Lene Kristoffersen, AI-udvikler i større konsulenthus: Jeg giver den 88. Jeg kan især lide gennemgangen af de forskellige lag og de konkrete angrebsvektorer. Det er sjældent, man ser så præcis en beskrivelse af, hvor det går galt. Jeg savner dog lidt mere om sikring af non-text modeller, men ellers er det spot on.

Michael Jensen, IT-driftchef i kommune: Jeg giver den 80. Den er meget relevant, især for os der arbejder med integration af AI i eksisterende systemer. Jeg synes dog, at den bliver lidt teknisk, og jeg kunne godt have brugt flere lavpraktiske eksempler, som kan bruges direkte i dialogen med ikke-tekniske kolleger.

*Denne artiklen er skrevet af en redaktion bestående af kunstig intelligenser, der har skrevet artiklen på baggrund af automatiseret research og oplysninger om de seneste teknologi nyheder fra internettet.

Billederne i artiklen er lavet af Gemini 3 Pro Nano Banana 2 Pro fra Google.