Alessia Gilardi
Regional Product Compliance Consultant
Alessia Gilardi is a GRC manager with extensive international experience in compliance, data protection, audit, and risk management. She specializes in turning complex legal requirements into practical solutions that support the business. She is certified by the International Compliance Association (ICA).
Key takeaways:
On 14 September 2026, the Spanish Data Protection Agency (AEPD) reported its first personal data breach notification in which an AI agent reportedly searched for vulnerabilities, logged in, modified personal data, and accessed invoices.
The AEPD is careful with conclusions: the case is still being analyzed, the organization hasn't been named, and a single notification doesn't establish a trend.
The GDPR's obligations stay the same, including the 72-hour notification deadline. What an AI agent changes is the speed of an attack, and with it the time available to understand one.
The EU AI Act doesn't regulate the attacker. It can become relevant when organizations deploy AI agents of their own, which is exactly where access and permissions need the closest governance.
A GRC platform won't stop an attack. It helps make sure the risk assessments, controls, and decisions around one are in place and documented.
The attack itself sounds almost ordinary. Something scanned generic files for weaknesses, found a way in, and logged in successfully. Then it kept going: it searched the application for further vulnerabilities, exploited them, changed personal data, and opened invoices. What set this notification apart was who, or what, did the searching. According to the affected organization, it was an AI agent using a well-known language model.
The AEPD was quick to add caveats when it published the case. The information comes from the organization's own notification and still has to be analyzed. The use of a particular model doesn't mean that the model, or its provider's infrastructure, was compromised. And one notification isn't a statistical trend. It is, in the Agency's view, a signal that AI-assisted attacks are starting to appear in incidents involving real personal data.
What made this attack different
AI has been part of cyberattacks for some time: in phishing emails, in translated scam messages, in code analysis. An agent adds something else. It can take a goal, break it into steps, use tools, look at the results, and adjust what it does next, with little or no human input between those steps.
In this case, that meant one system chained the whole sequence, from finding a weakness to changing personal data. The AEPD points to a specific risk behind that: an agent that gets hold of an account, an API key, or a token with broader permissions than it needs can move between services before anyone notices unusual activity. The notable detail in the Spanish case is how unremarkable the entry was: the agent logged in.
That shifts attention from perimeter defense to a less glamorous question: which accounts, keys, and tokens exist in your organization, what can each of them reach, and how fast can you revoke one?
The GDPR clock doesn't change. The time to understand does.
The GDPR is technology-neutral, and the AEPD case doesn't alter a single obligation. Article 32 still requires security appropriate to the risk. Article 33 still requires controllers to notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless it's unlikely to result in a risk to individuals.
The difference lies in the gap between becoming aware and understanding. A team may know that an attacker accessed an application while still working out which records were touched, whether data was copied, and, as in this case, whether it was altered. Modified data turns a confidentiality question into an integrity question too, which makes the investigation harder. If the agent used valid credentials, it may also be difficult to separate its actions from legitimate activity.
Two things follow for the people who handle incidents. The legal assessment has to start while the technical investigation is still running, not after the forensic report arrives. And the GDPR already anticipates that: where not all information is available at once, Article 33 allows it to be provided in phases, without undue further delay. A plan that treats notification as a single, final document will struggle with an attack that develops at machine speed.
Depending on the organization, the same incident may also trigger reporting under NIS2, DORA, or the Cyber Resilience Act, each with its own thresholds, deadlines, and authorities. The first hour is where those decisions get made.
See how your incident process holds up
Bring your current incident response plan and risk assessment, however informal they are today. We'd rather walk through an AI-agent scenario with you than describe it in the abstract.
What the AI Act has to do with it
It's tempting to read this case as an AI Act story. For the organization that was attacked, it mostly isn't. The EU AI Act regulates how AI systems are built, placed on the market, and used. It doesn't govern the attacker, and nothing in the AEPD case suggests the victim was running the AI involved.
The AI Act can become relevant on the other side: when your organization deploys AI agents of its own. Agents that read customer records, update a CRM, send emails, or trigger payments hold exactly the kind of access the AEPD warns about. If one of them, or its credentials, were compromised, the same chain of events could run through your systems, started from the inside.
That's where privacy and AI governance meet:
Under the GDPR, what your own agents do with personal data needs a legal basis, often a data protection impact assessment, and safeguards where decisions are automated.
Under the AI Act, high-risk AI systems must achieve appropriate levels of accuracy, robustness, and cybersecurity under Article 15. Following the Digital Omnibus on AI, these obligations apply from 2 December 2027 for stand-alone systems and from 2 August 2028 for AI embedded in regulated products. Providers of the most capable general-purpose AI models already have cybersecurity and serious-incident obligations today.
In both cases, the practical questions are the same: which agents do you run, who owns each one, what data and systems can it reach, and who approved that access?
Our view: organizations that handle the GDPR and the AI Act as separate projects will answer those questions twice, in different places, and probably differently. They're one set of questions.
What to review now
The AEPD asks controllers and processors to update their risk analyses to account for AI-assisted attacks. In practice, we'd start with five questions:
Does your risk assessment cover AI-assisted attacks? Faster, more persistent attackers change the likelihood of some scenarios, especially those involving exposed credentials.
Do you know your non-human identities? Service accounts, API keys, and tokens need an owner, a documented purpose, the minimum access they require, and a way to revoke them quickly.
Which AI agents do you run, and what can they reach? The same inventory and least-privilege rules apply to your own agents, including those embedded in third-party tools.
Does your incident response plan involve legal early? It should define when the legal assessment starts, who makes the notification decision, and how that decision gets revisited as the investigation develops.
Could you reconstruct what happened? Logs need to be good enough to trace automated actions, and every decision taken during an incident, including the decision not to notify, should be recorded with its reasoning.
A tabletop exercise built around an AI-agent attack is a quick way to find out where the answers are weakest.
How Formalize supports this
A GRC platform doesn't detect or block an AI agent. That's the job of security tooling, from identity management to monitoring. What a GRC platform does is make sure the organizational side holds up when an incident happens, and that you can show it did.
In Formalize, that means:
Risk assessments with owners, updated as threats like AI-assisted attacks change the picture.
Controls as recurring, evidenced work, such as access reviews for service accounts and API keys, instead of good intentions in a policy document.
Incident workflows that record who assessed what, when, and why, from the first alert to the notification decision.
GDPR and AI Act work in the same system, with blueprints for both, so your processing records and your AI systems are governed side by side.
When a regulator later asks what you knew, when you knew it, and what you did, the answer should already exist. See how Formalize approaches GDPR compliance and the AI Act.