What should we do first in an AI data incident?

Contain further data flows and establish reliable facts: preserve the affected tool, account, workspace, timing, inputs, sharing, integrations and possible follow-on actions. Do not delete blindly before securing the evidence needed for the incident.

Does an upload to an AI tool automatically mean model training?

No. Whether and how inputs are used for training, retention or other internal processing depends on the specific product, plan, account and settings. Check the concrete incident against configuration and provider information.

Is deleting the chat or file enough?

Not necessarily. A visible deletion may remove access in the UI, but does not automatically prove complete technical removal from logs, retention processes, backups or other systems. Preserve the relevant evidence first and document the provider information that is available.

Does every AI incident have to be reported within 72 hours?

No. The 72-hour rule concerns a potentially required notification of a personal data breach under GDPR Art. 33, not every AI incident. Technical triage starts immediately; privacy and qualified legal counsel assess deadlines and possible notification or communication duties for the concrete incident.

AI Data Incident: Technical Triage

A confidential prompt, a customer list in the wrong workspace or a document uploaded to an unapproved AI tool: in the first hours, the key question is not whether a notification is required. It is whether you can limit further impact and establish reliable facts: What was transferred, through which account, to where, through which follow-on paths — and what can still be controlled?

Technical triage starts immediately. Privacy, incident management and, where needed, legal counsel assess the legal implications in parallel. An upload is not automatically model training. A visible deletion is not automatically complete technical removal. And a visible chat history is not automatically the complete audit trail.

Do not speculate. Preserve evidence.

This article is about the concrete incident that has already happened. For recurring use outside approved paths, see Shadow AI in the workplace.

What matters in the first hours

The quality of the first response does not depend on reaching an immediate legal conclusion. It depends on stabilising the situation and building a traceable factual record. Technical owners, incident management, privacy and legal teams need that record for different decisions.

Technical triage for an AI incident

01
Incident identified
Which tool, account and time are known so far?
Record initial facts and owners
02
Containment
Which uploads, sharing paths, connectors or automations could still move further data?
Limit active data paths
03
Evidence
Which logs, IDs, timestamps and settings substantiate the sequence of events?
Traceable factual record
04
Scope
Which data, recipients, systems and tenants are actually affected?
Technical incident scope
05
Technical effects
Was there sharing, export, indexing, integration or a triggered action?
Side effects checked
06
Escalation
Which open facts, owners and decisions need to be handed over?
Coordinated next steps

Technical triage creates the factual basis for subsequent incident, privacy and legal decisions.

Phase 1: Stabilise and contain further data flows

Start by limiting further spread, not with a general clean-up. The right action depends on the setup:

Stop further uploads or sharing in the affected tool.
Identify the affected account, workspace or tenant and check current access.
Check public or shared links and disable them where necessary.
Check active connectors, plugins and API integrations on the affected data path.
Pause running automations or write paths if they can transfer data into further systems or trigger follow-on actions.
Rotate or revoke tokens, API keys or credentials only when they were exposed or remain relevant to execution on the affected path.

Credential rotation can stop further use. It does not reverse data already transferred. Equally important: do not blindly delete chats, files, logs or accounts before preserving the evidence needed for the incident.

If there is no clear technical owner internally, AI incident response can help contain the incident, preserve technical facts and define the next owners and escalation paths.

Phase 2: Preserve evidence without duplicating sensitive data unnecessarily

Incident documentation should substantiate the sequence of events, not create additional copies of the data that leaked. Where available in the concrete system, preserve a concise factual record:

tool or provider, product, plan and account type,
workspace or tenant,
user, identity and roles,
time of input, upload, sharing and discovery,
files, prompts or inputs as references — such as filename, ID, hash or timestamp rather than full content,
sharing, permissions, links and known recipients,
admin, audit, identity and access logs,
connectors, plugins, API access and related configuration,
observed follow-on actions or write operations,
visible retention and deletion settings,
relevant provider information, support cases and export options.

Where possible, IDs, log references, hashes, filenames and timestamps are preferable to complete sensitive content in screenshots, tickets or new documents. If a screenshot is necessary, it should contain only the information needed to substantiate the sequence of events.

Phase 3: Determine scope

The technical scope question is not “How serious is this?” It is: Which systems, data and access paths are demonstrably affected — and which points remain open?

Data

Establish whether personal data, special categories, customer or employee data, trade secrets, internal documents, or secrets and credentials were involved. A single file may contain more than one of these categories.

Scale

Distinguish between a single text, one document, multiple files, and datasets, people or tenants. Record what is known and what remains an assumption.

Account and recipients

Was a private consumer account, a managed Business or Enterprise workspace, or a shared access path involved? Were there public links, external recipients or other people with access?

Systems

Capture source systems, downstream systems and active integrations. It matters not only where the data came from, but whether connectors, APIs or automations could have moved it across further system boundaries.

This does not simulate a legal risk assessment. It defines the technical incident scope and makes missing facts visible.

Phase 4: Check technical effects beyond the chat window

An AI incident can have side effects beyond the visible chat history. That does not mean they occur in every setup. It means they need to be checked in the concrete setup.

Was content only entered or uploaded, or also shared?
Do active or historical links, exports or permissions exist?
Were connectors, plugins or APIs active?
Was data written into external systems, such as tickets, messages, records or files?
Did automations, agents or tool calls trigger follow-on actions?
Could embeddings, indexes or caches have been created, and is there evidence or configuration data for them?
Which exports, audit records or additional logs are available?

The visible chat is therefore only one possible starting point. Technical assessment also needs identity data, admin and audit logs, integration configuration and demonstrable state changes in connected systems.

Phase 5: Trigger provider and account actions deliberately

Once the tool, account and data path are bounded, actions can be triggered deliberately. Check and document what is actually available in the specific product:

visible deletion functions and their result,
retention controls and documented retention rules,
admin controls, workspace policies and roles,
revocation of connectors and API or token access,
audit or account exports,
a support request using the preserved references,
documented provider data controls where applicable.

“Deleted” in the UI is not automatic proof of complete technical removal. Conversely, an unanswered question about provider processing is not a reason to speculate. Document the available facts, the specific request to the provider and its substantiated response.

Classify provisionally, do not speculate

A compact classification is not a score and does not make an automatic notification decision. It makes priority, owners and open questions visible:

data type,
scale,
accessibility,
recipients,
known persistence or retention,
secrets or credentials,
triggered system actions,
reversibility: what can demonstrably be stopped, revoked or removed — and what cannot yet?

“Unclear” is a valid result. It shows precisely which evidence is missing next and who can obtain it.

What not to do now

Do not speculate about model training or internal provider processes.
Do not blindly delete chats, files or logs before preserving necessary evidence.
Do not overwrite evidence through rushed changes or uncoordinated admin actions.
Do not label every incident reportable by default.
Do not change passwords only when the actual problem is data already transferred.
Do not rely on the visible chat history alone.
Do not blame employees before the sequence, tooling and control gaps are understood.

72 hours: a legal deadline, not a technical waiting period

The 72-hour rule does not concern every AI incident. It concerns a potentially required notification of a personal data breach to the competent supervisory authority under GDPR Art. 33. Whether that condition is met must be assessed professionally on the facts of the specific incident.

Seventy-two hours are not a grace period for technical analysis. Containment and evidence preservation start immediately, even where the nature, scope and legal consequences of the incident are still open. Privacy and qualified legal counsel assess deadlines and possible notification or communication duties. This article does not make a final notification decision; it provides the technical factual basis.

Handover to privacy, incident management and legal counsel

Technical, organisational and legal work run in parallel, but have different responsibilities:

Technical triage provides

facts, scope and open technical questions,
logs, evidence and a traceable timeline,
active data paths, containment status and possible side effects.

Privacy and legal assess

legal classification,
possible notification or communication duties,
communications and further legal documentation.

Incident management coordinates

owners and measures,
escalation and decision points,
timeline and communication between the teams involved.

A technical handover is useful when it does not rest on assumptions: what is evidenced, what has been contained, what remains active and which information is still missing?

After the incident: from one-off event to a controlled AI working path

A concrete incident is not automatically a governance programme. But if it reveals recurring use outside approved paths, Shadow AI in the workplace is the next step: a structural adoption and offering problem, not a retrospective analysis of this individual incident.

Where data, control or operating boundaries need to be reconsidered for the long term, GDPR-compliant AI covers the architecture question. Missing incident paths, observability or runbooks can also be a reason to use the Enterprise AI Architecture Checklist.

AI incident response remains the direct path when the concrete incident now needs to be contained, documented and turned into clear next steps.

AI Data Breach: What Really Counts in the First 72 Hours