AI-sikkerhed

AI-sikkerhed dækker to forskellige ting. Den ene side handler om at sikre, at en model ikke gør skade ved at opføre sig forkert eller give vildledende svar, det engelske "safety". Den anden side handler om at beskytte systemet, data og adgang mod angreb, prompt injection eller datalækage, det engelske "security". Virksomheder møder typisk security i hverdagen, mens safety-diskussionen ofte kommer fra store modelleverandører.

Hvad AI-sikkerhed dækker over

AI-sikkerhed rummer både tekniske og organisatoriske tiltag. "Safety" betyder arbejde med alignment, guardrails og red teaming for at undgå farlige eller ukorrekte output. "Security" betyder adgangsstyring, kryptering, logging og forsvar mod angreb som prompt injection, hvor en ond prompt kan få modellen til at lække data eller ændre adfærd. Begge sider handler om risiko, men de er forskellige opgaver med forskellige leverandører, kompetencer og pris.

Når leverandøren siger "sikker AI": spørg hvilken slags sikkerhed

Når en leverandør lover "sikker AI", så spørg direkte: Mener I safety eller security? Hvis de taler om guardrails og fine-tuning, er det safety. Hvis de taler om adgangsstyring, netværkssikkerhed og roles, er det security. Det er to forskellige regninger. Som leder skal du vide, hvem i organisationen der betaler og hvem der implementerer: IT til security, compliance eller ledelsen til safety-krav og ansvar.

Sådan virker AI-sikkerhed i praksis

I praksis begynder du med at skille arbejdet ad. Først: begræns hvad modellen kan se og gemme, det mindsker risikoen for datalækage. Andre tiltag er at lægge guardrails ind i prompts og brugergrænsefladen, så modellen ikke får lov at lave bestemte typer svar. Red teaming er en øvelse, hvor man forsøger at bryde systemet med ondsindede prompts for at finde svagheder. Samtidig sætter du adgangskontrol, kryptering og overvågning op, så et angreb opdages tidligt.

Eksempel: AI-sikkerhed hos en databeskyttelsesansvarlig

Den databeskyttelsesansvarlige på et rådgivningsfirma skulle udrulle en intern chatbot til sagsbehandlere midt i et kvartal med mange deadlines. Chatbotten skulle bruge 4.500 kundemails og 120 PDF-filer fra sagsmapper. Dagene efter lancering fandt en sagsbehandler en utilsigtet tekst, der afslørede en kundes følsomme noter, en klassisk datalækage. Databeskyttelsesansvarligens løsning var at stoppe adgangen til de originale dokumenter, indføre strammere adgangsstyring og få leverandøren til at køre red teaming for at finde andre svagheder. Det tog tre arbejdsdage og to eksterne konsulent-timer at få chatbotten sikkert tilbage i drift. Læringen var klar: sikkerhed kræver både organisatorisk kontrol og testerfaring; det virker ikke, hvis kun én person eller kun teknik er sat på opgaven.

Hvad du skal være opmærksom på

Undgå at tro, at én mærkat "sikker" løser alle problemer. Datalækage er en sikkerhedsopgave, den skal håndteres med adgangsstyring, kryptering og logging. Modellen derimod kan producere skadeligt output; det er en safety-opgave, der kræver test, guardrails og ofte dialog med modelleverandøren. Husk at tjekke krav til persondata og opbevaring i forhold til jeres konkrete brug. Hvis I skal bruge personoplysninger, kan det være relevant at læse vejledning fra Datatilsynet. Endelig: træn brugerne i, hvordan de skal formulere prompts for at undgå prompt injection og utilsigtet deling af følsomme oplysninger.

Skal I beslutte, hvor meget AI-sikkerhed må fylde hos jer, er det den slags valg, AI-rådgivning handler om. Vil I arbejde videre med AI-sikkerhed på jeres egne opgaver, er det dét, en AI-workshop går ud på.