EU Data Governance Act AI Incident Reporting: The Duties Are Role-Specific

The Data Governance Act contains a narrow incident communication duty with large consequences for AI traffic. Article 12(k) requires a data intermediation services provider to inform data holders without delay after unauthorised transfer, access or use of shared non-personal data. Article 21(5) gives recognised data altruism organisations the same duty. A prompt sent to an unapproved model endpoint can meet that operational description even when the model returns a normal answer.

The official text of Regulation (EU) 2022/868 has applied since 24 September 2023. Its notification path depends on the organization's DGA role and the affected data. That is where an incident playbook should begin.

TL;DR

• The DGA creates no universal AI or cybersecurity incident-reporting rule. Its express incident duty here is role-specific.
• Data intermediaries and recognised data altruism organisations must inform data holders without delay after unauthorised transfer, access or use of shared non-personal data.
• Competent-authority reporting follows separate monitoring, annual-report and national enforcement paths.
• Preserve caller, content category, purpose, endpoint, region, policy decision and time for each affected model request.

Scope the DGA role before opening the clock

The DGA governs several different arrangements. Chapter II concerns re-use of protected data held by public sector bodies. Data intermediation services sit under Chapter III. Recognised data altruism organisations fall within Chapter IV. Article 31 reaches those roles with safeguards against conflicting international transfer or governmental access to non-personal data held in the Union.

The express "without delay" incident language appears in Article 12(k) for data intermediation services providers and Article 21(5) for recognised data altruism organisations. It requires notice to data holders, a recipient choice that keeps the duty distinct from a general instruction to report every AI incident to an EU authority.

Create a scoping card for each service before an incident. Name the role, competent authority, data holders, data subjects, approved purposes, transfer conditions, response owner and adjacent regimes. The DGA compliance checklist covers the underlying role determination and preventive controls.

The trigger is unauthorised transfer, access or use

An AI incident can fit the DGA trigger through ordinary application behaviour. A data intermediary adds summarisation and sends shared non-personal records to a model for a purpose outside putting those records at the disposal of users. A routing fallback sends a payload to an unapproved third-country endpoint. An internal support account retrieves prompt history beyond its assigned purpose.

For data intermediaries, Article 12(a) limits use of intermediated data to making it available to data users. Article 12(e) permits specified additional tools only at the explicit request or approval of the data holder or data subject and confines third-party tools to that purpose. Article 12(j) addresses unlawful transfer or access to non-personal data, while Article 12(l) requires an appropriate level of security.

The incident trigger should therefore be tested against authority, purpose, recipient and destination. A generic severity label cannot answer those four facts.

"Without delay" requires a prepared data-holder route

Articles 12(k) and 21(5) say the organization shall inform data holders without delay. The regulation supplies no fixed hour count in those clauses. Legal should define an internal escalation target that leaves enough time for verification, recipient identification and an accurate first notice while preserving the statutory standard.

Build the recipient map before the alert. A data intermediation platform may serve hundreds of holders, while one request touches records supplied by only two. The incident record needs a reliable link between each payload and the holder whose data it contains. Shared API credentials and aggregate token logs make that attribution difficult.

At 02:17, the useful screen shows the caller, holder, purpose, policy, endpoint and country on one line. A dashboard showing "model request succeeded" gives the response team almost nothing it needs for the notice.

The first notice should state verified facts

The DGA clauses specify the trigger and recipient rather than a prescribed notice form. A defensible first communication should include:

• the affected data holder and the service relationship;
• the detected unauthorised transfer, access or use;
• the time window, systems and non-personal data categories known to be involved;
• the destination or actor, where verified;
• containment completed, current exposure and the next update time.

Keep verified facts separate from hypotheses, and record who approved the notice plus the evidence behind every statement. Later updates can add cause, affected request count, corrective action and remaining uncertainty.

Personal data changes the analysis. GDPR breach assessment and notification may run beside the DGA path. NIS2, sector rules, contract clauses and national law can add authority notices or fixed deadlines. One incident can therefore produce several notices with different triggers and recipients. The DGA's data-holder duty remains its own row in the matrix.

Data intermediaries need an activity log before the incident

Article 12(o) requires a data intermediation services provider to maintain a log record of intermediation activity. Article 14 allows the competent authority to request information necessary to verify compliance. Those provisions make record quality part of incident readiness even though Article 12(k) sends the immediate notice to the holder.

For model traffic, the log should connect the authenticated principal with the holder, content classification, declared purpose, model route, destination region, policy version, decision and timestamp. Preserve allowed and blocked requests. A blocked request can show that a control worked during the same window in which another route failed.

Write the incident evidence outside the component under investigation where possible. Application-only logging creates a custody problem when the application selected the purpose, made the call and wrote the account of its own conduct. The DGA audit-evidence guide sets out the independent artifacts an authority or holder can inspect.

Data altruism has a second reporting path

Article 20 requires recognised data altruism organisations to keep full and accurate records of persons and entities given the opportunity to process held data, processing dates or duration, declared purposes and fees. An annual activity report must also go to the relevant competent authority.

Immediate data-holder communication after unauthorised transfer, access or use of shared non-personal data comes from Article 21(5). Article 20 supplies the standing record and annual authority report. Under Article 24, the competent authority receives monitoring powers and may request information necessary to verify compliance.

Keep these paths separate in the runbook. The immediate holder notice addresses the event. The annual report and supervisory response address transparency and compliance oversight. A serious event may also prompt the authority to exercise Article 24 powers under national procedure, but the regulation's incident clause itself names the holder as recipient.

Article 31 adds transfer evidence

Article 31 requires public sector bodies, Chapter II re-users, data intermediation services providers and recognised data altruism organisations to take reasonable technical, legal and organisational measures against international transfer of or governmental access to non-personal data held in the Union where that would conflict with Union or member-state law.

When an AI incident involves a third-country endpoint, preserve the exact destination, provider entity, region-selection logic, request time and content category. The route may have changed because a health check marked the approved endpoint unavailable. That mechanical fact belongs in the timeline.

Article 31 also requires notice to the data holder before compliance with a qualifying third-country administrative request, subject to the law-enforcement exception. That is a separate notification event from unauthorised model routing. The DGA controls mapping distinguishes the purpose, classification and destination controls involved.

The runbook should divide detection, notice and correction

A practical DGA AI incident workflow has four phases:

1. Triage: confirm the organization's DGA role, affected holder, non-personal data, authorization, purpose and destination.
2. Containment: stop the route, revoke the session or change the policy while preserving logs and payload references.
3. Communication: inform affected data holders without delay where Article 12(k) or Article 21(5) applies, and open parallel legal tracks for other regimes.
4. Correction: repair the control, test it with the incident scenario, preserve the result and update the Article 12 log or Article 20 record.

My view is that recipient mapping is the neglected control. Teams rehearse containment and discover during the incident that nobody can map a prompt fragment back to the data holder who supplied it.

DeepInspect

DeepInspect can support detection, containment and evidence for authenticated HTTP traffic deliberately routed between users or agents and LLM endpoints. The application supplies identity and purpose context. DeepInspect classifies prompt content, evaluates per-role and per-route policy, enforces destination constraints, inspects the response, and writes a per-decision audit record outside the calling application.

That record can show which principal sent which protected category to which model endpoint, under which purpose and policy, at what time. It can block a disallowed route before transmission and preserve the denied decision alongside allowed traffic. DeepInspect does not decide the legal notification trigger, identify every data holder without upstream mapping, send notices, cover local execution or STDIO, respond to stolen credentials, or observe direct traffic that bypasses the proxy. Legal, incident response, application and identity teams retain those duties.

Book a technical deep dive at deepinspect.ai.