Forebyggelse af datalækager i AI-applikationer

Forebyggelse af datalækager i AI-applikationer handler om at styre, hvilke data modellen, logningen, værktøjerne og leverandørerne kan se. Den vigtigste beskyttelse er dataminimering kombineret med adgangsstyring, isolering, hemmelighedshåndtering, outputkontrol, løbende test og en klar plan for hændelser.

Hvad er en datalækage i en AI-applikation?

En datalækage i en AI-applikation opstår, når oplysninger bliver gjort tilgængelige for personer, systemer eller leverandører, der ikke burde have adgang. Det kan være personoplysninger, forretningshemmeligheder, adgangsnøgler, kundedata, interne dokumenter, modelinstruktioner eller data fra en vektordatabase.

AI-applikationer skaber særlige lækageveje, fordi de ofte samler flere datalag i samme arbejdsproces. Brugerinput sendes til en model. Modellen kan hente dokumenter fra en database. Et værktøj kan kalde et eksternt system. Logs kan gemme hele samtaler. Et output kan afsløre oplysninger, der egentlig kun lå i baggrundsmateriale.

Forebyggelse begynder derfor med dataflow, ikke med modellen alene. Du skal vide, hvilke data der kommer ind, hvor de behandles, hvor de gemmes, hvem der kan se dem, og hvad der kan komme ud igen.

Hvor opstår lækager typisk?

Datalækager opstår typisk i overgangen mellem komponenter. En model kan være hosted sikkert, mens applikationen omkring den lækker data gennem logning, fejlhåndtering, integrationer, cache, testmiljøer eller dårlig adgangsstyring. Det gør arkitekturen lige så vigtig som valg af model.

De mest almindelige risikopunkter er brugerinput, systeminstruktioner, API-kald, dokumentuploads, embeddings, vektordatabaser, værktøjsintegrationer, output, eksportfunktioner og driftslogs. Hvis en AI-løsning bruges på tværs af teams, kan delte arbejdsrum og genbrugte adgangsnøgler også blive en lækagevej.

Hvorfor er brugerinput og logning særligt følsomt?

Brugerinput kan indeholde mere end det, brugeren tror. En medarbejder kan indsætte kundedata, kontrakter, regneark, supporthistorik eller interne nøgletal for at få et bedre svar. Hvis applikationen sender hele inputtet videre, gemmer det i lange logs eller bruger det til senere analyse, kan data sprede sig langt ud over det oprindelige formål.

Logning er nødvendig for fejlfinding, sikkerhed og misbrugsdetektion, men logs bliver hurtigt et sekundært datalager. En sikker logstrategi bør skelne mellem tekniske hændelser, sikkerhedshændelser og indhold fra brugere. Kun det nødvendige bør gemmes, og følsomme felter bør maskeres eller fjernes, før de når almindelige driftslogs.

Hvis personoplysninger indgår, skal logning vurderes efter databeskyttelsesregler og organisationens egen risikoprofil. GDPR artikel 32 peger på tekniske og organisatoriske foranstaltninger efter risiko, herunder pseudonymisering, kryptering, fortrolighed, integritet, tilgængelighed og regelmæssig test af sikkerhedsforanstaltninger.

Hvordan minimeres data før modellen kaldes?

Dataminimering er den mest effektive første barriere, fordi data, der aldrig sendes, ikke kan lække fra modelkaldet. Før applikationen kalder en model, bør den afgøre, hvilke dele af inputtet der faktisk er nødvendige for opgaven. En oversættelse kræver måske tekstindhold, men ikke kundenummer, CPR-lignende identifikatorer eller interne sagsnoter.

En praktisk proces er at klassificere data før afsendelse. Applikationen kan markere personoplysninger, hemmeligheder, adgangsnøgler, kontraktvilkår og andre følsomme felter. Derefter kan den fjerne, maskere, generalisere eller erstatte oplysninger, før de bruges i modelkaldet. Samme princip bør bruges på dokumenter, der uploades til analyse.

For AI-API’er bør organisationen også kontrollere leverandørens databrug, retention, region, adgangsmodel og eventuelle indstillinger for træning eller forbedring af tjenesten. AI Mentor har en særskilt forklaring af, hvordan data beskyttes ved brug af AI API’er.

Hvordan adskilles systeminstruktioner, brugerdata og hemmeligheder?

AI-applikationer bør adskille systeminstruktioner, brugerdata og hemmeligheder teknisk og organisatorisk. Systeminstruktioner beskriver, hvordan AI-komponenten skal opføre sig. Brugerdata er det indhold, brugeren arbejder med. Hemmeligheder er adgangsnøgler, tokens, certifikater og andre værdier, som aldrig bør være synlige for modellen som almindelig tekst.

Hvis disse lag blandes, kan en manipuleret forespørgsel få systemet til at afsløre interne instruktioner, ignorere adgangsgrænser eller sende fortrolige oplysninger videre. Derfor bør hemmeligheder ligge i sikre secret stores, værktøjer bør kaldes gennem en kontrolleret backend, og modellen bør kun se den minimale kontekst, den behøver for at løse opgaven.

Adskillelsen bør også gælde udvikling og test. Testmiljøer bør ikke bruge produktionsdata uden klar begrundelse, maskering og adgangskontrol. Fejlmeddelelser bør ikke vise nøgler, rå API-svar eller interne databasestier til brugere.

Hvordan sikres RAG og vektordatabaser mod lækager?

Retrieval-augmented generation og vektordatabaser kan give gode svar på interne data, men de kan også give brugere adgang til dokumenter, de ikke burde se. Lækagen opstår ofte ikke i selve modellen, men i hentningen af kontekst: systemet finder relevante tekststykker uden at kontrollere, om brugeren har ret til dem.

Sikker RAG kræver rettighedsfiltrering ved søgningen, ikke kun i brugerfladen. Hvis en medarbejder ikke må se et dokument i kildesystemet, bør AI-applikationen heller ikke hente dokumentets tekststykker som kontekst. Metadata som afdeling, rolle, dokumenttype, klassifikation og ejer bør følge indholdet ind i vektordatabasen.

Vektordatabaser bør også have livscyklusstyring. Når et dokument slettes, ændres eller får nye rettigheder, skal de afledte embeddings og tekststykker opdateres eller fjernes. Ellers kan gamle versioner blive ved med at dukke op i svar. Se også AI Mentors gennemgang af sikkerhedsudfordringer ved generativ AI.

Hvordan begrænses værktøjer og integrationer?

Moderne AI-applikationer kan ofte bruge værktøjer: søge i databaser, sende e-mails, ændre billetter, kalde interne API’er eller skrive til dokumenter. Lækager opstår, når AI-komponenten får for brede rettigheder eller kan flytte data mellem systemer uden en klar godkendelsesgrænse.

Least privilege bør være standard. Hvert værktøj bør have en snæver rolle, en begrænset adgangsnøgle, en defineret datascope og tydelige regler for, hvilke handlinger der kræver menneskelig godkendelse. Et værktøj til kundesupport bør ikke automatisk kunne læse HR-data, økonomidata eller tekniske hemmeligheder.

NCSC’s retningslinjer for sikker AI-udvikling anbefaler blandt andet at anvende passende kontroller for data, der sendes uden for organisationens kontrol, og at begrænse AI-komponenters mulige handlinger. I praksis betyder det korte adgangstokens, godkendelse før følsomme handlinger, separeret værktøjsrouting og auditlog for alle kald.

Hvordan testes for lækager før drift?

Test for datalækager bør begynde før drift og gentages efter ændringer. Testen skal ikke kun vise, at applikationen kan svare korrekt. Den skal også vise, at applikationen afviser uautoriserede forespørgsler, ikke afslører systeminstruktioner, ikke lækker data på tværs af brugere og ikke sender unødvendige oplysninger til leverandører.

En testplan kan dække manipulerede input, adgang på tværs af roller, fejlmeddelelser, dokumenthentning, eksportfunktioner, logindhold, værktøjskald, rate limits og forsøg på at få modellen til at gengive fortroligt materiale. Testen bør bruge syntetiske følsomme data, så selve testen ikke skaber en reel lækage.

Resultaterne bør dokumenteres med fund, alvorlighed, berørte data, afhjælpning og retest. Hvis testen viser, at adgangsgrænser kun ligger i brugerfladen, men ikke i backend eller datalag, bør systemet ikke gå i produktion. AI Mentor beskriver samme kontroltænkning i sikkerhedsaudit for AI og machine learning-projekter.

Hvordan overvåges drift uden at skabe nye datarisici?

Driftsovervågning skal opdage misbrug, fejl og datalækager, men den må ikke selv blive en ukontrolleret samling af følsomme data. En god løsning registrerer hændelser på et niveau, der gør analyse mulig, uden at gemme hele dokumenter, samtaler eller personprofiler, medmindre det er nødvendigt og begrundet.

Overvågningen bør blandt andet se efter usædvanlige datamængder, mange afviste forespørgsler, forsøg på at hente begrænsede dokumenter, usædvanlige værktøjskald, output med mønstre for adgangsnøgler og pludselige ændringer i brugeradfærd. Samtidig bør adgang til sikkerhedslogs være begrænset og adskilt fra almindelig drift.

NIST Cybersecurity Framework 2.0 kan bruges som generel ramme for govern, identify, protect, detect, respond og recover. For AI-applikationer betyder det, at forebyggelse, detektion og hændelseshåndtering skal forbindes med modeladfærd, datalag og leverandørkald, ikke kun med servere og netværk.

Hvordan håndteres tredjepartsleverandører?

Tredjepartsleverandører kan være modeludbydere, cloudmiljøer, vektordatabaser, monitoreringsværktøjer, annotationsleverandører, integrationsplatforme og supportværktøjer. Hver leverandør kan få adgang til data direkte eller indirekte. Derfor bør leverandørstyring være en del af AI-sikkerheden fra starten.

Konkrete kontrolpunkter er databehandlerrolle, datalagring, region, underleverandører, adgang for leverandørpersonale, kryptering, retention, logging, mulighed for sletning, incident-notifikation, eksport af data og dokumentation for sikkerhedsforanstaltninger. Hvis leverandøren bruger data til modeltræning, evaluering eller produktforbedring, bør det fremgå tydeligt af aftaler og tekniske indstillinger.

Leverandørrisiko handler også om forsyningskæden. OWASP fremhæver supply chain vulnerabilities som en central risiko for LLM-applikationer. Det dækker ikke kun softwarepakker, men også datasæt, modeller, plugins, værktøjer og afhængigheder, som kan påvirke fortrolighed og integritet.

Hvad gør du ved en mistænkt datalækage?

Ved en mistænkt datalækage bør organisationen først stoppe den mulige spredning. Det kan være midlertidig deaktivering af en integration, rotation af adgangsnøgler, blokering af en eksportfunktion, isolation af en vektordatabase eller sænkning af adgangsniveauer, mens hændelsen undersøges.

Derefter bør hændelsen afgrænses: hvilke data er berørt, hvilke brugere eller systemer havde adgang, hvornår begyndte hændelsen, hvilken komponent var årsagen, og om data blev sendt til en ekstern leverandør. Logs kan være afgørende, men de skal håndteres forsigtigt, hvis de selv indeholder følsomme oplysninger.

Hvis hændelsen omfatter personoplysninger, kan GDPR’s regler om persondatasikkerhedsbrud blive relevante. Forordningen definerer et brud som et sikkerhedsbrud, der fører til utilsigtet eller ulovlig destruktion, tab, ændring, uautoriseret videregivelse af eller adgang til personoplysninger, og artikel 33 beskriver anmeldelse til tilsynsmyndigheden, når betingelserne er opfyldt. Det er ikke en erstatning for konkret juridisk vurdering, men det viser, hvorfor hændelsesplanen bør være klar før drift.

Hvilke minimumskontroller bør være på plads?

Minimumskontroller afhænger af systemets formål og datatyper, men nogle kontroller bør normalt være på plads, før en AI-applikation får adgang til interne eller følsomme data. De skaber ikke fuld sikkerhed alene, men de reducerer risikoen for de mest oplagte lækageveje.

• Dataklassificering før modelkald og dokumentuploads.
• Maskering eller fjernelse af følsomme felter, når de ikke er nødvendige.
• Adgangsstyring på dokument-, bruger- og værktøjsniveau.
• Rettighedsfiltrering i vektordatabaser og søgelag.
• Separat hemmelighedshåndtering uden nøgler i modelkontekst eller logs.
• Kort og begrundet opbevaringstid for brugerindhold og driftslogs.
• Outputkontrol for personoplysninger, adgangsnøgler og fortrolige mønstre.
• Hændelsesplan med ansvar, eskalation, leverandørkontakt og retest.

For bredere tekniske sikkerhedstiltag kan du sammenholde minimumskontrollerne med AI Mentors forklaring af sikkerhedsforanstaltninger for AI-drevne systemer.

Hvordan kobles privatliv og sikkerhed i praksis?

Privatliv og sikkerhed bør behandles som gensidige krav. En AI-applikation kan ikke beskytte privatliv uden sikker adgangsstyring, kryptering, logkontrol og leverandørstyring. Omvendt kan en sikkerhedsløsning skabe privatlivsrisiko, hvis den gemmer for meget brugerindhold eller gør data tilgængelige for for mange interne roller.

En praktisk model er at lave en dataflowanalyse for hver AI-funktion: indsamling, behandling, modelkald, dokumenthentning, værktøjskald, output, logning, opbevaring og sletning. For hvert trin bør du beskrive datatyper, formål, adgang, retention, kryptering, leverandører og kendte fejlscenarier.

På den måde bliver privatliv ikke et separat dokument ved siden af sikkerhedsarbejdet. Det bliver en del af arkitekturen. AI Mentor har en relateret gennemgang af AI og privatlivets fred, som uddyber beskyttelsesstrategierne.

Hvilke kilder ligger til grund?

Artiklen bygger på NCSC’s retningslinjer for sikker AI-systemudvikling, især anbefalingerne om secure design, secure development, secure deployment og secure operation and maintenance.

De AI-specifikke lækagerisici er kontrolleret mod OWASP Top 10 for Large Language Model Applications. Den generelle sikkerhedsramme er holdt op mod NIST Cybersecurity Framework 2.0, og persondatarelaterede brud er afgrænset med GDPR på EUR-Lex.