An AI incident can trigger several workflows, but not every bad output is legally reportable. First contain harm and preserve evidence. Then determine whether the event is an EU AI Act serious incident, a GDPR personal-data breach, both, or neither. The applicable clock depends on the business’s role and facts: GDPR can require notification within 72 hours, while AI Act serious-incident periods include two, 10, and 15 days.
Playbook
An AI incident can trigger several workflows, but not every bad output is legally reportable. First contain harm and preserve evidence. Then determine whether the event is an EU AI Act serious incident, a GDPR personal-data breach, both, or neither. The applicable clock depends on the business’s role and facts: GDPR can require notification within 72 hours, while AI Act serious-incident periods include two, 10, and 15 days.
Scope, Dates, and Legal Warning
This article is educational information, not legal advice. Incident-reporting duties depend on jurisdiction, system classification, organisational role, affected people, sector, and consequences. Engage privacy and regulatory counsel immediately when a material incident may be reportable.
The two regimes ask different questions:
• The GDPR addresses a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.
• The EU AI Act defines a serious incident by consequences including death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of obligations protecting fundamental rights, or serious harm to property or the environment.
Under GDPR Article 33, a controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware of a personal-data breach, unless the breach is unlikely to result in risk to people’s rights and freedoms. Processors must notify controllers without undue delay. High-risk cases can also require communication to affected people without undue delay under Article 34.
Under AI Act Article 73, providers of high-risk systems placed on the Union market report serious incidents to the relevant market-surveillance authority. The outer periods in the original text are:
• No later than 15 days after the provider or, where applicable, deployer becomes aware, after the provider establishes a causal link or reasonable likelihood of one.
• No later than two days for a widespread infringement or the specified serious and irreversible critical-infrastructure disruption.
• No later than 10 days in the event of death, after the provider or deployer establishes or suspects a causal relationship.
Deployers of high-risk systems also have immediate information duties to the provider and then other listed parties when they identify a serious incident.
The July 2026 AI Omnibus Regulation delayed relevant high-risk Chapter III rules to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I product-related systems. The interaction of application dates, system type, market placement, transitional provisions, and incident duties requires legal review. Do not publish a universal statement that every AI failure currently has a 15-day EU deadline.
The Four-Way Triage Decision
Decision 1: Did an incident occur?
Start with observable facts, not legal labels:
• What did the system receive, infer, output, or do?
• Was data exposed, lost, altered, or made unavailable?
• Did the agent take an external action?
• Who was affected?
• Is the action reversible?
• Is the system still operating?
A hallucinated internal draft may be a quality defect. The same hallucination sent to customers and used to deny service may create a different risk.
Decision 2: Is personal data involved?
Map the data touched by the incident, including prompts, retrieved records, tool parameters, generated outputs, logs, and backups. Ask whether confidentiality, integrity, or availability was compromised.
Examples that may require GDPR breach analysis include:
• An agent sends one customer’s account summary to another.
• Prompt-injection causes extraction of personal records.
• A workflow overwrites or deletes customer data.
• Logs expose employee prompts containing health information.
• An agent makes records unavailable during an automated cleanup.
Not every personal-data breach is reportable to the authority, but every breach should be documented. The EDPB breach guidance distinguishes authority notification and communication to affected individuals.
Decision 3: Does the AI Act serious-incident definition fit?
Do not equate “serious to our company” with the statutory definition. Record the consequence, affected right, causal evidence, and system classification. Determine whether the business is a provider, deployer, importer, or distributor and which authority would receive a report.
An incorrect marketing email normally does not become an AI Act serious incident. A high-risk employment system producing discriminatory outcomes that infringe EU fundamental-rights obligations may require a different analysis.
Decision 4: Are other regimes or contracts triggered?
Sector rules, cybersecurity law, employment law, product safety, consumer law, professional duties, insurance policies, and customer contracts may create additional clocks. An incident can be non-reportable under one regime and still require action under another.
Maintain a jurisdiction and contract matrix before an incident rather than searching for notice clauses while the timer runs.
The First 72 Hours
Hour 0 to 4: Stabilise and start the record
1. Open an incident record and assign an incident commander.
2. Stop or constrain the unsafe workflow without destroying evidence.
3. Revoke exposed credentials and tokens.
4. Preserve prompts, outputs, tool calls, logs, model and workflow versions.
5. Record when each responsible function became aware.
6. Contact privacy, security, legal, business, and communications owners.
The 72-hour GDPR clock runs from awareness, not from completion of a forensic investigation. The ICO’s small-business guide is UK guidance rather than EU regulator guidance, but its operational advice to start the timer and record facts is useful.
Hour 4 to 24: Establish impact and roles
• Identify affected systems, people, records, and jurisdictions.
• Determine controller and processor roles.
• Ask vendors when they became aware and what they can evidence.
• Assess likely harm to individuals.
• Test whether unauthorised actions continue.
• Establish whether the system may be high-risk and who provided it.
Do not wait for perfect certainty. Record assumptions and confidence.
Hour 24 to 48: Make provisional legal decisions
Prepare separate decision records for GDPR and the AI Act. A single checkbox titled “reportable” loses the reasoning each framework requires.
Draft notifications with known information and mark unknowns. Both GDPR and the AI Act allow information to be supplied in phases in relevant circumstances. Counsel should approve the approach.
Hour 48 to 72: Notify where required
Submit required GDPR authority notification within the applicable clock even if some details remain under investigation. Record the authority, submission time, content, reference number, and follow-up commitment.
AI Act notification timing must be calculated independently. Two days can expire before a 72-hour GDPR window, while other AI Act periods are longer. The safest operational design raises all potential serious incidents immediately.
Evidence and Artifacts
Maintain:
• Incident ID, owner, severity, and status.
• Detection and awareness timeline.
• System, model, prompt, workflow, and tool versions.
• Source data and affected records.
• Agent identities, credentials, and delegated users.
• Proposed and executed actions.
• Human approvals and overrides.
• Containment and recovery steps.
• Personal-data breach assessment.
• AI Act serious-incident assessment.
• Other regulatory and contractual assessments.
• Notifications, acknowledgements, and follow-ups.
• Customer or employee communications.
• Root-cause analysis and corrective actions.
• Re-enable approval and post-incident tests.
Protect the record from alteration by the system or administrator under investigation. Recommended practice is to preserve original evidence and record corrections as new events.
Common Failure Modes
The team debates terminology before containment. Stop continuing harm first while preserving evidence.
Vendor notification is treated as the customer’s legal decision. Controllers and deployers must perform their own role-specific analysis.
Every AI error is called a breach. This overwhelms the process and obscures genuinely reportable events.
Only confidentiality is checked. GDPR breaches can involve integrity and availability.
The team waits for a root cause before starting the clock. Awareness can precede forensic certainty.
One clock is used for all regimes. The GDPR and AI Act have different triggers and reporting periods.
Logs contain results but not side effects. Investigators cannot determine which records, messages, or payments changed.
The workflow is restarted after a patch without regression tests. The original failure can recur through another tool or path.
SMB Incident Reporting Checklist
• [ ] Publish one internal route for reporting AI incidents.
• [ ] Name incident, privacy, legal, security, and business owners.
• [ ] Keep provider and authority contacts current.
• [ ] Preserve an accurate awareness timeline.
• [ ] Contain actions without erasing evidence.
• [ ] Revoke or constrain agent credentials.
• [ ] Assess confidentiality, integrity, and availability of personal data.
• [ ] Record controller and processor roles.
• [ ] Assess the AI Act serious-incident definition separately.
• [ ] Calculate every applicable clock independently.
• [ ] Document non-reporting decisions as well as reports.
• [ ] Prepare phased notification templates.
• [ ] Reconcile every external action the agent took.
• [ ] Require tested corrective action before restart.
• [ ] Feed lessons into permissions, evals, and training.
The wider permission and rollback model belongs in the AI agent governance guide.
FAQs
Does every AI hallucination need to be reported?
No. A hallucination is a quality failure, not automatically a personal-data breach or AI Act serious incident. Assess its consequences, data exposure, system classification, and applicable law.
When does the GDPR 72-hour clock begin?
The clock begins when the controller becomes aware of a personal-data breach. Do not delay starting the incident record until the investigation is complete.
What if the business does not have all the facts within 72 hours?
GDPR permits information to be provided in phases where it cannot be supplied at the same time. The initial decision and notification should be handled with counsel and the relevant authority’s guidance.
Does the EU AI Act always give 15 days?
No. Article 73 includes shorter outer periods for specified events, and applicability depends on the high-risk system, role, consequence, and current application provisions.
Can one incident trigger both laws?
Yes. For example, a high-risk system incident could also expose personal data. Run separate analyses and clocks rather than choosing one regime.
Get a 20-Minute AI Workflow Audit
AI Operator can run a tabletop exercise against one live workflow, identify missing evidence and owners, and produce an incident control plan.