I Spanien er det for første gang blevet anmeldt, at et angreb er udført med en AI-agent og har ført til et brud på persondatasikkerheden. Her beskrives, hvordan anmeldelsespligten ved et databrud med en AI-agent kan vurderes, hvornår de 72 timer løber, og hvilke forberedelser der bør være på plads, så man ikke skal improvisere under pres.
Den 14. september 2026 blev det offentligt kendt i Spanien, at et angreb med en AI-agent for første gang var blevet anmeldt til en databeskyttelsesmyndighed. Det rejser et praktisk spørgsmål: Hvem skal gøre hvad, når en AI-agent er involveret, enten som angrebsværktøj for fremmede gerningsmænd eller som virksomhedens eget værktøj? Det handler om anmeldelsespligt, frister, logfiler og procedurer i en nødsituation.
AEPD-sagen kort fortalt
I Spanien er et brud på persondatasikkerheden for første gang blevet anmeldt, hvor et angreb angiveligt er udført med en AI-agent baseret på en kendt sprogmodel. Angriberen skal først have ledt efter sårbarheder i offentligt tilgængelige filer og derefter have logget ind på målsystemet. Agenten fandt yderligere sårbarheder i applikationen, ændrede personoplysninger og fik adgang til fakturaer.
Rollefordelingen er vigtig. Den anmeldende virksomhed var offeret, og agenten var angribernes værktøj. Der er altså ikke tale om en fejl hos en agent, som organisationen selv drev. Hverken organisationen eller modellen er navngivet. Brugen af en kendt model betyder ikke, at udbyderen eller dens infrastruktur er kompromitteret, og det er ikke sagt, at værktøjet var bygget til skadelige formål. En enkelt sag siger desuden intet om en tendens.
AI skaber ikke grundlæggende nye trusler, men kan øge angrebenes tempo, omfang og tilpasningsevne. Det har praktiske konsekvenser: Angreb med AI hører hjemme i risikovurderingen, reaktionstider, der er tænkt til manuelle angreb, skal tages op til revision, adgangsoplysninger med for brede rettigheder skal beskyttes bedre, og det menneskelige tilsyn har brug for støtte fra hurtig opdagelse og inddæmning.
Hvornår en AI-agent udløser et anmeldelsespligtigt databrud
Anmeldelsespligten ved databrud forårsaget af AI-agenter knytter sig ikke til teknologien, men til resultatet. Efter art. 4, nr. 12, i GDPR foreligger et brud på persondatasikkerheden, når et sikkerhedsbrud fører til tilintetgørelse, tab, ændring, uautoriseret videregivelse af eller adgang til personoplysninger, hvad enten det sker ved en fejl eller ulovligt. Om det er et menneske, et script eller en agent, der står bag, er uden betydning for denne definition. To konstellationer kan alligevel skelnes tydeligt.
I konstellation A angriber en fremmed agent, som i den spanske sag. Den uautoriserede adgang og ændringen af data udgør bruddet, og anmeldelsespligten opstår med det. Det nye her er først og fremmest tempoet, ikke den juridiske vurdering. I konstellation B forårsager virksomhedens egen agent bruddet. Det kan være en kundeagent, der sender data til den forkerte person, en kodeagent med for brede rettigheder eller en mailagent, der videresender indhold efter en indsmuglet instruktion.
I konstellation B er vurderingen ikke altid oplagt. Har agenten gjort præcis det, den var sat op til, og har ingen uvedkommende fået adgang, mangler der ofte et sikkerhedsbrud. Strømmer data derimod til modtagere, der ikke måtte få dem, eller får agenten adgang til datasamlinger, som burde have været spærret for den, taler meget for et brud. Der findes endnu knap nok egne retningslinjer for agenter. Vurderingen er derfor et spørgsmål om det enkelte tilfælde og følger myndighedernes almindelige målestok.
| Scenarie | Brud? | Berørt beskyttelsesmål |
|---|---|---|
| Fremmed agent logger uautoriseret ind | Ja | Fortrolighed |
| Fremmed agent ændrer datasæt i applikationen | Ja | Integritet |
| Egen agent sender fakturaer til forkerte modtagere | Ja | Fortrolighed |
| Egen agent videresender postkasseindhold udad efter prompt injection | Ja | Fortrolighed |
| Egen agent sletter datasæt uden sikkerhedskopi | Ja | Tilgængelighed |
| Egen agent svarer forkert uden at data slipper ud | Oftest nej | Ingen, snarere et kvalitetsproblem |
Det centrale spørgsmål kan dermed besvares kort.
Skal et databrud med en AI-agent anmeldes efter art. 33 i GDPR?
Risikotærskel og undtagelse fra anmeldelse
Ikke ethvert brud skal anmeldes. Art. 33 i GDPR indeholder en undtagelse, når bruddet sandsynligvis ikke indebærer en risiko for fysiske personers rettigheder og frihedsrettigheder. Overliggeren er altså lav. Som regel anmeldes der allerede, når en risiko ikke kan udelukkes. Den, der undlader at anmelde, skal kunne begrunde godt, hvorfor der ikke var nogen risiko.
Ved angreb og uheld med agenter taler meget imod denne undtagelse. Agenter tilgår ofte mange datasæt på én gang, de arbejder hurtigt, og de har adgang til områder som fakturaer, kundekonti eller postkasser. Ændrer en angriber data, opstår der ved siden af tabet af fortrolighed et følgeproblem: Til at begynde med ved ingen, hvilke datasæt der stadig er korrekte. Det øger risikoen for de registrerede.
Til vurderingen har de europæiske databeskyttelsesmyndigheder udgivet retningslinjer. EDPB's retningslinjer om anmeldelse af brud på persondatasikkerheden nævner blandt andet bruddets art, dataenes følsomhed og mængde, hvor let de registrerede kan identificeres, alvoren af de mulige følger og antallet af registrerede som kriterier. Ved høj risiko kommer desuden underretningen af de registrerede efter art. 34 i GDPR. Dette trin er adskilt fra anmeldelsen til myndigheden og har sine egne krav.
Ansvaret ligger hos driftsherren
En agent er et værktøj og ikke et retssubjekt. Ansvarlig er fortsat den, der bestemmer formål og midler for behandlingen, altså den virksomhed, der anvender agenten. Det er ikke nok at pege på modellen, platformen eller fagafdelingen. Selv når en agent handler selvstændigt, tilregnes behandlingen fortsat driftsherren.
Agenten er et værktøj, ansvaret forbliver hos driftsherren.
Hvis en platform eller en modeludbyder driver agenten på vegne af virksomheden, handler den som regel som databehandler. Så gælder art. 33, stk. 2, i GDPR: Databehandleren skal underrette den dataansvarlige om et brud uden unødig forsinkelse, så snart det er blevet ham bekendt. Den dataansvarliges frist begynder dog først med dennes egen viden. Kontrakter bør derfor fastlægge, inden for hvilken tid og via hvilken kanal hændelser skal meldes. En besked, der først efter dage havner i en generel postkasse, hjælper ingen.
| Part | Rolle ved et agentuheld |
|---|---|
| Driftsherre for agenten | Dataansvarlig, anmelder til tilsynsmyndigheden og dokumenterer |
| Agentplatform | Ofte databehandler, underretter driftsherren uden unødig forsinkelse |
| Modeludbyder | Afhængigt af opsætningen databehandler eller underdatabehandler, ved egen kompromittering også underretningspligtig |
| Fagafdeling | Opdager og melder internt uden selv at træffe beslutning |
| Andre tjenesteudbydere | Leverer logfiler og oplysninger til vurderingen |
Angriber en angriber via en tjenesteudbyder, gælder de samme principper som ved ethvert uheld i leverandørkæden.
Sådan tæller du de 72 timer rigtigt
Fristen løber efter art. 33, stk. 1, i GDPR fra det tidspunkt, hvor den dataansvarlige bliver bekendt med bruddet. Der skal anmeldes uden unødig forsinkelse og om muligt inden for 72 timer. Efter EDPB's retningslinjer foreligger kendskab, når den dataansvarlige med rimelig sikkerhed ved, at et sikkerhedsbrud har ført til et brud på persondatasikkerheden. En kort undersøgelsestid for at afklare en mistanke er tilladt. Passivitet er det ikke.
Ved agenter flytter flaskehalsen sig. En agent kan på få minutter hente eller ændre tusindvis af datasæt. Om hændelsen opdages samme dag eller først efter en uge, afhænger så af overvågning og alarmering. Agenter, der kører om natten eller i weekenden, forværrer det. Den, der først bemærker uregelmæssigheder, næste gang vedkommende kigger på et dashboard, mister tid, som fristen ikke levner. Her er det især opdagelsestiden og spørgsmålet om, hvem der må reagere uden for arbejdstiden, der tæller.
De 72 timer er ved agenter først og fremmest et spørgsmål om opdagelsestid.
Loven tillader, at man anmelder i faser. Foreligger alle oplysninger endnu ikke, indsendes de efter art. 33, stk. 4, i GDPR uden unødig yderligere forsinkelse. Overskrides fristen, skal forsinkelsen begrundes. Som rettesnor kan følgende forløb tjene.
Tidsangivelserne er vejledende. Afgørende er, at hvert trin har en, der sætter det i gang, og at beslutningen om anmeldelse ikke afhænger af, om en enkelt person er til stede.
Log agenternes handlinger
Uden logfiler kan omfanget af et brud næppe opgøres. Netop ved agenter er det vanskeligt, fordi de udfører mange enkelthandlinger, der hver for sig ser harmløse ud. En brugbar log besvarer fire spørgsmål: Hvem har handlet, hvad er der gjort, hvilke data er der tilgået, og hvor er de endt? Dertil kommer dokumentationspligten efter art. 33, stk. 5, i GDPR, som gælder ethvert brud, også dem, der ikke anmeldes.
| Logfelt | Nytte for anmeldelsen | Bemærkning om dataminimering |
|---|---|---|
| Agentens identitet og version | Tilknytter hændelsen til system og konfiguration | Teknisk identifikator er nok |
| Opgave og udløser | Afklarer, om et menneske, en tidsplan eller fremmed input har igangsat handlingen | Kort beskrivelse frem for fuld ordlyd |
| Værktøjs- og dataadgange | Viser arten og omfanget af de berørte data | Kategorier og mængder frem for indhold |
| Tidsstempler | Grundlag for kendskab og fristberegning | Ukritisk |
| Målsystemer og modtagere | Viser, hvor data er havnet | Adresser kun, hvis nødvendigt |
| Fejl og afbrydelser | Tegn på angrebsforsøg og fejlfunktioner | Ukritisk |
| Godkendelser fra mennesker | Dokumenterer tilsynet og beslutningsvejene | Kun identifikator for den godkendende instans |
For logning af agenter gælder: Logfilerne indeholder selv personoplysninger og skal beskyttes. Adgangen bør begrænses til få personer, og posterne bør lagres manipulationssikkert, for eksempel på et separat system. Opbevaringstiden er en afvejning: lang nok til at kunne rekonstruere en hændelse, kort nok til ikke at skabe en datasamling. Foranstaltningerne hører under behandlingssikkerheden efter art. 32 i GDPR. De samme logfiler hjælper desuden ved anmodninger om indsigt. Hvordan overvågningen af AI-agenter kan udformes fornuftigt, uden at agenter selv sætter kontrollen ud af kraft, er et emne for sig.
Begræns adgangsrettigheder og adgangsoplysninger
Den spanske sag viser, hvordan en angriber med en agent går frem: Vedkommende leder efter kendte filer, standardadgange og hverdagssårbarheder. Det kan en agent gøre i maskinhastighed og uden træthed. Den, der lukker sådanne huller, tager meget af tempoet ud af angrebet. Myndigheden nævner udtrykkeligt konti, API-nøgler og tokens med for brede rettigheder som et svagt punkt.
I praksis har en håndfuld principper vist sig at virke:
- Hver agent får sin egen konto med de færrest nødvendige rettigheder.
- Nøgler og tokens er kortlivede og kan tilbagekaldes enkeltvis.
- Adgang til mange datasæt på kort tid begrænses og meldes.
- En nødafbryder stopper agenter og spærrer deres adgange uden først at kræve afklaring.
- Offentliggjorte filer, testadgange og standardadgangskoder eftersøges og fjernes med jævne mellemrum.
Disse foranstaltninger beskytter mod fremmede agenter og mod fejl fra ens egne. Hvor stor skaden bliver, afhænger i høj grad af de rettigheder, en agent har fået. Til en webapplikations angrebsflade hjælper automatiserede kontroller, der opdager synlige sårbarheder, før andre gør det.
Kontrollér angrebsfladen
Åbne filer, manglende beskyttelsesmekanismer og dataudsivning på din egen hjemmeside kan opspores automatisk.
Beredskabsplan for automatiserede angreb
Mange beredskabsplaner går ud fra en angriber, der bruger timer eller dage. Myndigheden opfordrer til at gennemgå reaktionstider, der er udformet til manuelle angreb. Menneskeligt tilsyn er fortsat vigtigt, men har brug for støtte fra mekanismer, der opdager, inddæmmer og reagerer hurtigt nok. Et automatiseret angreb tager ikke hensyn til fyraften.
En bæredygtig plan fastlægger få ting. Der er alarmer for usædvanlige adgangsmønstre, for eksempel mange hentninger fra samme konto eller logins på utypiske tidspunkter. Konti kan spærres automatisk, når tærskler overskrides. Uden for arbejdstiden er der nogen, der kan træffes. Det er klart, hvem der beslutter anmeldelsen, og hvem der sender den. Tilsynsmyndighedens anmeldelsesformular er forberedt, og kontaktoplysningerne på databeskyttelsesrådgiveren er ved hånden. Til hændelsens første timer er det værd at kigge på handlingsplanen for de første 60 minutter, som er opstået ved ransomware, men kan overføres til andre angreb.
Det er godt, hvis planen er blevet indøvet. En øvelse med en opdigtet agenthændelse, hvor en konto henter data i stort omfang, viser hurtigt, hvor det knirker: manglende vagtberedskab, uklare ansvarsområder, logfiler, der ikke kan analyseres. Sådanne huller kan lukkes i ro og mag, ikke i en nødsituation.
Forbered anmeldelsen til tilsynsmyndigheden
Art. 33, stk. 3, i GDPR fastsætter minimumsindholdet. Der beskrives bruddets art med det omtrentlige antal berørte personer og datasæt, navn og kontaktoplysninger på databeskyttelsesrådgiveren eller et andet kontaktpunkt, de sandsynlige følger og de trufne eller foreslåede foranstaltninger. Kompetent er som regel tilsynsmyndigheden i den stat, hvor virksomheden har sit hjemsted. De fleste myndigheder tilbyder en onlineformular, og Datenschutzkonferenz giver en oversigt.
Ved agenter er der typiske huller. Omfanget af adgangen kan ikke opgøres uden logfiler, og ved ændringer af data er det uklart, hvilke datasæt der faktisk er berørt. Det hjælper at afklare på forhånd, hvordan man ud fra logfiler, databasesikkerhedskopier og versionsstatus kan udlede et holdbart tal. Den, der kun kan anslå, angiver intervallet og markerer det som foreløbigt. Den supplerende anmeldelse udfylder hullerne senere.
En kort tjekliste til anmeldelsen:
- Tidspunkt for kendskab og hændelsens tidsrum
- Bruddets art: uautoriseret adgang, ændring, videregivelse, tab
- Berørte datakategorier og omtrentligt antal personer og datasæt
- Agentens rolle: fremmed angrebsværktøj eller egen agent
- Inddæmmede konti, nøgler og systemer
- Sandsynlige følger for de registrerede
- Beslutning om underretning af de registrerede
- Kontakt til databeskyttelsesrådgiveren
Om der desuden gælder anmeldelsespligter fra andre regelsæt, for eksempel for operatører af kritiske anlæg eller efter AI-forordningen, afhænger af det enkelte tilfælde og bør nævnes i beredskabsplanen, så ansvaret ikke først skal afklares under hændelsen.
Konklusion
Den første sag, der er anmeldt i Spanien, viser ikke noget nyt retligt begreb, men et nyt tempo. Om en fremmed agent angriber, eller den egne agent begår en fejl: Afgørende er, om der foreligger et brud på persondatasikkerheden, og om der er en risiko for de registrerede. Så gælder det om at handle uden unødig forsinkelse og om muligt anmelde inden for 72 timer.
Kort tjekliste:
- Fremmede agenter som angribere og egne agenter som årsag er forskellige konstellationer med samme vurdering.
- Ansvaret forbliver hos driftsherren, også når platforme og modeludbydere er involveret.
- Opdagelsestiden afgør, om fristen kan overholdes.
- Gode logfiler gør en mistanke til en holdbar anmeldelse.
- Få rettigheder, kortlivede nøgler og en nødafbryder tager tempo og skade ud af angrebet.
My name is Klaus Meffert. I have a doctorate in computer science and have been working professionally and practically with information technology for over 30 years. I also work as an expert in IT & data protection. I achieve my results by looking at technology and law. This seems absolutely essential to me when it comes to digital data protection. My company, IT Logic GmbH, also offers consulting and development of optimized and secure AI solutions.
