Hvordan beskyttes data ved brug af AI API’er?

Data beskyttes ved brug af AI API’er ved at begrænse, hvilke oplysninger der sendes, sikre adgangen teknisk, kontrollere leverandørens datavilkår og overvåge, hvor input, output, logs og afledte data opbevares. Beskyttelsen er både en teknisk arkitektur og en løbende styringsopgave.

Hvad betyder databeskyttelse i en AI API?

En AI API er et programmatisk adgangspunkt til en AI-model eller en AI-tjeneste. Når en applikation sender tekst, filer, billeder, metadata eller brugerhandlinger til API’et, forlader oplysningerne ofte den oprindelige applikationsgrænse. Databeskyttelse handler derfor ikke kun om selve modellen, men om hele kæden fra brugerinput til svar, logning, fejlhåndtering, lagring og eventuelle værktøjskald.

Den centrale skelnen er, om data bruges midlertidigt til at levere et svar, om de gemmes som applikationstilstand, om de indgår i leverandørens sikkerhedsovervågning, eller om de kan bruges til produktforbedring eller modeltræning. De muligheder varierer mellem leverandører og aftaletyper. En sikker løsning kræver derfor både tekniske kontroller og en konkret læsning af dokumentation, databehandleraftale og konfiguration.

For en organisation begynder beskyttelsen med en dataklassifikation. Almindelige produkttekster, aggregerede målinger og tekniske fejlbeskrivelser har ikke samme risiko som kundehenvendelser, helbredsoplysninger, forretningshemmeligheder, adgangsoplysninger eller dokumenter med persondata. AI API’en bør kun få det informationsniveau, der er nødvendigt for opgaven.

Hvilke data sendes typisk til en AI API?

En AI API modtager sjældent kun den synlige tekst, brugeren har skrevet. En moderne integration kan også sende systeminstruktioner, samtalehistorik, bruger-id’er, sprogangivelse, tidsstempler, filuddrag, søgeforespørgsler, værktøjsresultater, vektorhits, funktionsparametre og tekniske metadata. Noget af det er nødvendigt for kvalitet og kontekst, men hvert ekstra felt udvider datafladen.

Det praktiske spørgsmål er ikke kun, om data er følsomme i sig selv. Kombinationer kan også blive følsomme. En kort tekst uden navn kan blive personhenførbar, hvis den sendes sammen med kunde-id, e-maildomæne, lokation eller en intern sagstitel. Derfor bør integrationen dokumentere, hvilke felter der sendes i normal drift, fejltilstande, testmiljøer og analytiske målinger.

Hvis du arbejder med større datasæt, hænger API-sikkerhed tæt sammen med almindelig data-processering. Data skal være forstået, minimeret og sporbar, før de bliver sendt videre til en ekstern eller intern modeltjeneste.

Hvordan begrænser du data, før de sendes?

Den mest robuste beskyttelse er at undlade at sende data, der ikke er nødvendige. Det lyder enkelt, men i AI-løsninger opstår risikoen ofte, fordi udviklere sender hele samtaler, hele dokumenter eller brede databaseudtræk for at give modellen mest mulig kontekst. Mere kontekst kan forbedre svaret, men det kan også sende oplysninger, som modellen ikke behøver.

En praktisk tilgang er at indføre et dataminimeringslag mellem applikationen og AI API’en. Laget kan fjerne direkte identifikatorer, erstatte navne med interne pseudonymer, beskære dokumenter til relevante afsnit, udelade adgangsnøgler og stoppe input, der ligner hemmeligheder. Det bør ske før data rammer leverandørens endpoint, ikke bagefter i loganalysen.

Minimering må ikke forveksles med fuld anonymisering. Hvis en organisation senere kan koble et pseudonym tilbage til en person, er der stadig tale om personoplysninger i mange sammenhænge. Det betyder ikke, at pseudonymisering er værdiløs. Den reducerer konsekvensen ved utilsigtet eksponering, men den fjerner ikke behovet for hjemmel, adgangsstyring, sletning og risikovurdering.

• Send kun de felter, der er nødvendige for svaret.
• Beskær dokumenter efter relevans i stedet for at sende hele filer.
• Erstat direkte identifikatorer med stabile, interne referencer, hvis opgaven tillader det.
• Bloker adgangskoder, API-nøgler, private nøgler og sessionsdata i input.
• Adskil testdata fra produktionsdata og brug syntetiske eller maskede data i udvikling.

Hvordan bruges kryptering, adgangsstyring og netværkskontrol?

Kryptering er nødvendig, men den beskytter ikke alene. Transporten mellem applikation og API bør ske via HTTPS/TLS, og lagrede data bør krypteres, hvis de gemmes i leverandørens systemer, egne logs, vektordatabaser eller analyseværktøjer. Kryptering skal kombineres med nøglestyring, rotationsrutiner og adgangsbegrænsning.

Adgangsstyring bør bygges efter mindst privilegium. En intern applikation, der kun skal opsummere supportsager, bør ikke bruge en API-nøgle med adgang til alle modeller, alle projekter, alle filer og alle administrative handlinger. Hvor platformen understøtter projekter, servicekonti, scopes, private endpoints, IP-begrænsning eller særskilte miljøer, bør de bruges til at adskille opgaver og risikoniveauer.

Netværkskontrol reducerer risikoen for, at API-adgang misbruges fra uventede miljøer. Det kan være faste udgående IP-adresser, egress-regler, private netværksforbindelser, DNS-kontrol og begrænsning af, hvilke tredjepartsværktøjer AI-komponenten må kalde. Særligt agentlignende integrationer skal kontrolleres, fordi modellen kan udløse værktøjskald, der flytter data videre end den oprindelige API-transaktion.

De samme principper går igen i bredere sikkerhedsforanstaltninger for AI-drevne systemer: adgang, netværk, logning, overvågning og rettighedsstyring skal ses som samlet drift, ikke som en enkelt indstilling hos leverandøren.

Hvordan håndteres API-nøgler og servicekonti sikkert?

API-nøglen er ofte den svageste del af en AI API-integration. Hvis nøglen ligger i frontend-kode, mobilapps, delte dokumenter, fejlrapporter eller offentlige repositories, kan den misbruges til både datatilgang og uventede omkostninger. Nøgler bør ligge i en hemmelighedshåndteringstjeneste og kun være tilgængelige for de services, der faktisk bruger dem.

En sikker nøglepraksis omfatter separate nøgler pr. miljø, korte rotationsintervaller, automatisk scanning for hemmeligheder, forbrugsgrænser, alarmer og hurtig spærring. Det gør hændelser mindre skadelige, fordi en lækket nøgle kan isoleres uden at lukke hele AI-løsningen. Servicekonti bør navngives efter formål, ikke efter personer, så ejerskab og ansvar kan overdrages.

Du bør også begrænse, hvad nøglen kan. Hvis leverandøren understøtter projektbaserede tilladelser, bør en nøgle til klassifikation ikke kunne læse filer, oprette lagrede assistenter eller ændre organisatoriske indstillinger. Hvis leverandøren ikke tilbyder finmaskede rettigheder, bliver kompenserende kontroller som gateway, proxy, budgetgrænser og intern rate limiting vigtigere.

Hvad skal du undersøge i leverandørens datavilkår?

Leverandørens datavilkår afgør, hvad der sker med input og output efter API-kaldet. Du bør skelne mellem data til modelberegning, misbrugsmonitorering, midlertidig cache, filopbevaring, fine-tuning, evalueringsdata, tredjepartsværktøjer og data, der gemmes for at give applikationen hukommelse eller historik. Disse kategorier kan have forskellige retentionperioder.

En leverandør kan for eksempel dokumentere, at API-data ikke bruges til modeltræning som standard, men samtidig gemme visse data til misbrugsdetektion eller applikationstilstand. En anden leverandør kan have forskel på gratis udvikleradgang, betalt cloudkonto og enterprise-kontrakt. Derfor er det utilstrækkeligt at skrive i en intern politik, at data “ikke trænes på”. Spørgsmålet er, hvilken tjeneste, konto, region, funktion og aftale udsagnet gælder for.

Leverandørgennemgangen bør mindst afklare:

• om input og output bruges til modeltræning eller produktforbedring, og om det kræver aktivt tilvalg
• hvor længe data opbevares i logs, cache, filer, samtaler og applikationstilstand
• om data kan placeres i en bestemt region, og hvilke underleverandører der indgår
• om kunden kan slette data, eksportere logs og deaktivere lagring
• hvilke funktioner der ikke er dækket af samme databeskyttelse som standard-API’en

Leverandørens dokumentation bør gemmes sammen med arkitekturbeslutningen, fordi vilkår og funktioner ændrer sig. En ændring i API-funktioner, hukommelse, webadgang, filværktøjer eller tredjepartsforbindelser kan ændre den oprindelige risikovurdering.

Hvordan mindskes risikoen for instruktionsmanipulation og datalæk?

AI API’er behandler naturligt sprog som instruktioner, data og kontekst på samme tid. Det skaber en særlig risiko: En bruger, et dokument, en webside eller et hentet tekststykke kan indeholde formuleringer, der forsøger at få modellen til at ignorere regler, afsløre skjult kontekst eller sende data videre. Risikoen findes især, når modellen får adgang til værktøjer, databaser eller eksterne dokumenter.

Beskyttelsen kræver adskillelse mellem instruktioner og data. Brugerindhold og dokumentuddrag bør mærkes som data, ikke som styrende instruktioner. Modellen bør ikke selv beslutte, hvilke hemmelige systemoplysninger der må vises. Output bør valideres, før det bruges til e-mails, databaseændringer, kundesvar eller automatiske handlinger.

En god kontrol er at behandle modeloutput som forslag, ikke som sandhed eller kommando. Hvis output kan udløse en handling, bør handlingen have en separat autorisation. Hvis output kan indeholde persondata, bør det filtreres. Hvis output bruges i HTML, SQL, regneark eller kommandoer, skal det renses efter den relevante kontekst. Flere datalæk opstår ikke i selve modellen, men når applikationen ukritisk bruger modellens svar i et andet system.

Risikoen er beslægtet med generelle datalækager i AI-applikationer, men AI API’er gør kontrolpunktet mere komplekst, fordi tekst både kan være brugerdata, styringssignal og input til automatiserede handlinger.

Hvordan bør logs, cache og embeddings behandles?

Mange organisationer fokuserer på selve API-kaldet og overser de data, der skabes omkring kaldet. Logs kan indeholde fulde input, output, bruger-id, fejlbeskeder, dokumentnavne og interne referencekoder. Cache kan indeholde gentagne tekststykker eller modelinterne mellemresultater. Embeddings kan repræsentere tekst på en måde, der gør semantisk søgning mulig, men de kan stadig være afledt af følsomme oplysninger.

Driftslogs bør som udgangspunkt ikke gemme fuld fritekst, medmindre der er et klart formål og en kort retentionperiode. Fejllogs kan gemme fejlkoder, længder, modelnavne og korrelations-id’er uden at gemme hele kundesamtalen. Hvis fulde input er nødvendige for fejlsøgning, bør adgang begrænses, og data bør maskes eller slettes automatisk efter en kort periode.

Vektordatabaser kræver særskilt styring. Hvis du bruger retrieval, gemmes dokumentuddrag ofte som embeddings og metadata, så modellen kan finde relevante kilder. Det kan være sikkert, men kun hvis adgangsrettighederne fra de oprindelige dokumenter følger med ind i søgelaget. Ellers kan brugere få svar baseret på dokumenter, de ikke måtte se. Derfor bør vektordatabaser behandles som et datalager med egne rettigheder, sletterutiner og auditspor.

Hvordan testes sikkerheden før produktion?

Test af en AI API-integration bør kombinere klassisk applikationssikkerhed og AI-specifik misbrugstest. Klassisk test dækker adgangskontrol, nøgler, inputvalidering, rate limits, logging, sletning, kryptering og fejlbeskeder. AI-specifik test dækker forsøg på at få modellen til at afsløre skjult kontekst, ignorere regler, udtrække data fra hentede dokumenter eller udføre uønskede værktøjskald.

Testmiljøet bør bruge data, der afspejler produktionens struktur uden at kopiere følsomme produktionsoplysninger unødigt. Det er bedre at teste med realistiske syntetiske data og kontrollerede eksempler end at sende faktiske kundesager gennem en ufærdig integration. Hvis produktionsdata bruges, skal formål, adgang og sletning være dokumenteret.

En nyttig testplan omfatter både positive og negative cases. Positive cases viser, at API’en kan løse opgaven med mindst mulige data. Negative cases viser, hvad der sker, når brugeren indsætter hemmeligheder, når dokumenter indeholder manipulerende instruktioner, når svar bliver for lange, når API-nøglen misbruges, eller når vektorsøgning returnerer materiale fra en forkert rettighedsgruppe.

Hvordan passer GDPR ind i brugen af AI API’er?

Når en AI API behandler personoplysninger, skal organisationen kunne forklare formål, datatyper, behandlingsgrundlag, dataminimering, opbevaring, sikkerhed og eventuelle overførsler. Det gælder uanset om modellen bruges til kundeservice, intern analyse, dokumentudtræk, klassifikation eller automatisering. AI ændrer ikke grundkravet om kontrol over persondata.

GDPR’s sikkerhedskrav er risikobaserede. Det betyder, at kontrollerne skal passe til sandsynlighed og konsekvens. En simpel klassifikation af offentlige produkttekster kræver ikke samme kontrolniveau som en integration, der behandler helbredsoplysninger, børnedata, ansættelsesforhold eller fortrolige kundesager. Kryptering, pseudonymisering, adgangsstyring, gendannelsesevne og løbende test er relevante værktøjer, men de skal vælges efter risiko.

For danske og europæiske organisationer bør AI API’en derfor vurderes sammen med databehandleraftale, underleverandører, region, sletning og dokumentation. En generel gennemgang af AI og GDPR i kundevendte processer kan give samme grundstruktur, men hver API-integration skal stadig vurderes ud fra sit konkrete dataflow.

Hvilken praktisk proces kan en organisation følge?

En sikker proces begynder før den første integration. Start med at beskrive formålet: Hvilket problem skal AI API’en løse, og hvilke data er nødvendige for netop den opgave? Derefter bør dataflowet tegnes, så du kan se, hvor data opstår, sendes, gemmes, slettes og kan læses af mennesker eller systemer.

En enkel beslutningsrækkefølge kan bruges i både små og store projekter:

1. Klassificer data efter følsomhed, forretningskritikalitet og personhenførbarhed.
2. Fjern eller pseudonymiser unødvendige oplysninger før API-kaldet.
3. Vælg leverandør, region og funktioner efter dokumenteret databehandling.
4. Afgræns nøgler, rettigheder, netværk og værktøjskald efter mindst privilegium.
5. Definer retention for logs, filer, cache, embeddings og fejlrapporter.
6. Test misbrug, datalæk, rettighedsbrud og fejltilstande før produktion.
7. Overvåg drift, forbrug, nøgler, ændrede leverandørvilkår og nye API-funktioner.

Processen bør ejes af både teknik, sikkerhed, dataansvarlige og forretning. Teknik kan bygge kontrollerne, men forretningen skal afgøre, hvilke oplysninger der faktisk er nødvendige. Sikkerhed kan teste misbrug, men driftsansvarlige skal kunne opdage afvigelser, når integrationen kører.

Hvilke fejl går ofte igen ved AI API’er?

Den første fejl er at sende for meget kontekst. Det sker, når en udvikler sender hele dokumentpakker, komplette samtalehistorikker eller brede databasefelter, fordi modellen ellers svarer dårligere. En bedre løsning er målrettet udvælgelse: find de relevante afsnit, fjern uvedkommende data og send kun den kontekst, der understøtter opgaven.

Den anden fejl er at stole på leverandørens generelle sikkerhedsudsagn uden at læse den konkrete API-dokumentation. Chatprodukter, udvikler-API’er, cloud-hostede modeller, enterprise-aftaler og beta-funktioner kan have forskellige regler. Sikkerheden bør vurderes på funktionsniveau, ikke kun på leverandørnavn.

Den tredje fejl er at lade modeloutput styre handlinger uden efterkontrol. Hvis et svar kan oprette en ordre, sende en mail, ændre en sag eller hente ekstra data, skal der være rettighedskontrol uden for modellen. Modellen kan foreslå handlingen, men applikationen skal kontrollere, om brugeren, dataene og situationen giver lov til den.

Hvordan kan beskyttelsen vedligeholdes over tid?

AI API’er ændrer sig hurtigt. Nye modeller, værktøjer, hukommelsesfunktioner, filformater, søgefunktioner og integrationsmuligheder kan ændre dataflowet uden at selve applikationens brugerflade ændrer sig meget. Derfor bør databeskyttelse ikke være en engangsafklaring ved lancering.

En vedligeholdelsesrutine bør omfatte periodisk gennemgang af leverandørvilkår, API-konfiguration, logretention, nøglebrug, adgangsrettigheder, outputfiltre og sikkerhedshændelser. Ved større ændringer bør organisationen gentage risikovurderingen: Sender vi nye datatyper, gemmer vi data længere, giver vi modellen flere værktøjer, eller flytter vi behandlingen til en anden region?

Der bør også være en hændelsesplan. Hvis en API-nøgle lækkes, en forkert rettighedsgruppe får adgang til vektordata, eller en model begynder at afsløre uventede oplysninger, skal teamet kunne rotere nøgler, stoppe integrationen, slette data, undersøge logs og kommunikere internt. Den plan skal testes, før der er en hændelse.

Hvilke kilder ligger til grund?

Artiklen bygger på risikobaseret databeskyttelse i EU’s databeskyttelsesforordning, AI-specifikke risici i OWASPs LLM-risikoliste for 2025, styringsanbefalinger i NISTs profil for generativ AI-risikostyring og leverandørspecifikke datakontroller i OpenAI Platforms dokumentation om data.