EU AI Act vs GDPR Breach Notification: When One AI Incident Triggers Both

Why one incident can fall under two regimes

The AI Act states that it is without prejudice to existing Union law, in particular on data protection, and that it is complementary to it. In practice the two regimes run in parallel. Neither replaces the other, and satisfying one does not discharge the other.

The difficulty is organizational. Security teams often own a breach process built around GDPR, while product or AI teams own the system that failed. Each process asks different questions, uses different vocabulary and may be run by different people. When a model or agent discloses personal data in an output or tool call, both processes can start at the same moment, and both depend on the same underlying facts: what the system did, which data was involved, and when the organization became aware.

Whether a given event meets the legal definition of a personal data breach or of a serious incident is a legal determination for counsel. The comparison below focuses on what each regime requires once that determination is being made.

Side-by-side comparison

The table compares the notification mechanics as of November 2026, based on the text of the two regulations.

• Who must notify: GDPR: the controller. AI Act: the provider of a high-risk AI system placed on the Union market. A deployer that identifies a serious incident must inform the provider first.
• Clock start: GDPR: when the controller becomes aware that a personal data breach has occurred. AI Act: when the provider or, where applicable, the deployer becomes aware of the serious incident.
• Timeline: GDPR: without undue delay and, where feasible, within 72 hours. AI Act: immediately after a causal link, or its reasonable likelihood, is established, and in any event within 15 days. The period must take account of severity.
• Recipient: GDPR: the supervisory authority, and data subjects without undue delay where high risk is likely. AI Act: market surveillance authorities of the Member States where the incident occurred. Deployers inform the provider, then the importer or distributor and the relevant authorities.
• Exception or threshold: GDPR: notification does not apply if the controller can demonstrate that the breach is unlikely to result in a risk to individuals. AI Act: reporting is tied to a causal link, or its reasonable likelihood, between the system and the incident.
• Partial reporting: GDPR: information may be provided in phases, with reasons for any delay. AI Act: an initial incomplete report may be followed by a complete report. After reporting, the provider must investigate, assess risk and take corrective action.

A worked scenario: an agent discloses personal data

Consider a customer-facing agent that can call internal tools. A crafted prompt causes it to retrieve a record containing personal data and include it in a response to a user who should not see it. The system is a high-risk AI system, and the organization is both the controller of the data and the deployer of a system built by a vendor.

On the GDPR side, the organization as controller must decide whether the exposure is a personal data breach and whether it is likely to result in a risk to individuals. If it cannot demonstrate that risk is unlikely, the 72-hour target applies where feasible, and a high-risk finding brings in communication to the affected individuals.

On the AI Act side, the organization as deployer must decide whether the event is a serious incident. If so, it informs the provider first, then the importer or distributor and the relevant market surveillance authorities. The provider's own report turns on the causal link between the system and the incident, with the 15-day limit running from the point the provider or deployer became aware.

The roles matter. The same organization can be controller and deployer, or controller and provider, and each role carries different duties. A role map per AI system, agreed before an incident, prevents the first hours being spent on who owns which notification.

The evidence gap is the practical constraint

Neither regime asks for a particular log format, but both decisions depend on facts that only interaction-level records can supply. The GDPR text expects a controller to be able to demonstrate that a breach is unlikely to result in risk. That conclusion is hard to defend without knowing what data left the system. The AI Act report turns on a causal link between the system and the incident, which requires knowing what the system output or did in the specific interaction.

For a coordinated assessment, a shared record should be able to answer five questions within the first 72 hours: which interaction or tool call was involved, what the system output or did, which categories of personal data were present, which policy decisions applied at that moment, and when each event occurred.

The gap most regulated enterprises face is not the absence of application logs. It is the difference between knowing that a request was made and being able to show what the AI was permitted to do, what it actually did, and what data it handled. Without that, teams either over-notify on uncertainty or cannot support a no-notification decision. Aggregate dashboards rarely resolve this, because the facts needed sit at the level of a single interaction or tool call.

Where policy enforcement in the execution path fits

Detection and notification are downstream of the incident. Controls in the execution path act earlier. Trussed enforces policy inside the AI execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. Policy decisions are allow, redact, block, rate limit, or escalate for human approval. In the worked scenario, a policy that redacts personal data from a tool response, or escalates the call for human approval, can prevent the disclosure from reaching the user.

The same enforcement produces audit-ready evidence, mapped to the EU AI Act among other frameworks. Each decision is recorded as it is made, so the question of what the AI was allowed to do and what it did can be answered from the record rather than reconstructed after the fact. Enforced at runtime, not reviewed after the fact, these controls reduce the likelihood of an incident and give the compliance team material for the notification decision.

Enforcement does not remove notification duties. Whether an event must be reported remains a legal determination, and the evidence supports that determination rather than replacing it. Trussed deploys self-managed in the customer cloud, with configurable retention and data residency, which lets a regulated enterprise keep incident evidence within its own environment.