Who does the Data Governance Act actually bind?

Public sector bodies making protected data available for re-use, natural and legal persons re-using that data, providers of data intermediation services, and recognised data altruism organisations. Article 31 names re-users, intermediaries, altruism organisations, and public sector bodies together as owing measures against unlawful international transfer of non-personal data, which is why item 1 on this list exists.

Does the DGA replace the GDPR?

The DGA sits alongside it. Personal data in scope stays governed by the GDPR, and the DGA adds conditions on re-use, intermediation, and altruistic sharing, including for non-personal data that carries commercial confidentiality or intellectual property. An organization running GDPR AI compliance work already produces part of the record set this checklist needs.

How does this differ from the EU Data Act?

The EU Data Act became applicable on 12 September 2025 and covers access to connected-product data, contract fairness, switching between data processing services, and international governmental access under its Article 32. The DGA covers re-use of protected public sector data, data intermediation, and data altruism. Article 31 of the DGA and Article 32 of the Data Act ask for the same destination evidence.

Which item matters most if protected data is already reaching prompts?

Item 2, then item 4. The route inventory tells you whether the containment you documented still exists, and protected-category classification is what stops the next payload from leaving while the rest of the programme is being built. Item 3 follows immediately, since a blocked request with no named principal behind it generates a statistic rather than an account.

Do these controls require changing the model or the provider?

They operate at the HTTP boundary between the application and the model endpoint, which keeps them model-agnostic and free of provider-specific work. The application keeps supplying identity and purpose context, while classification, routing, enforcement, and recording happen in the request path. That independence is also what lets the same records answer the DGA, the Data Act, and the EU AI Act from one store.

EU Data Governance Act AI Compliance Checklist: Ten Items for Protected Data in Prompts

The Data Governance Act reaches three groups: anyone re-using protected data held by a public sector body, anyone providing a data intermediation service, and any recognised data altruism organisation. Regulation (EU) 2022/868 entered into force on 23 June 2022 and has applied since 24 September 2023, and each of those groups now has staff with a model endpoint one API key away from the data they are supervised over.

Work out which group you occupy first, because it decides which chapter of the Act binds you and removes the rest from scope. This checklist assumes protected or intermediated content can reach a prompt. Each item names the article it serves, the action at the AI request boundary, and the artifact it produces, because a competent authority reads artifacts rather than architecture diagrams.

1. Record which DGA role you occupy and under which conditions

Write down whether you are a re-user under Chapter II, a data intermediation services provider under Chapter III, or a data altruism organisation under Chapter IV, and attach the re-use conditions or the Article 11 notification that applies. Evidence is a scoping statement with the conditions quoted. It is the document an authority reads before anything else and the one that prevents a Chapter III answer to a Chapter II question.

2. Find the outbound routes from the secure processing environment

Article 5 allows a public sector body to require re-use inside a secure processing environment it controls. Enumerate every route out of that environment, including package registries, telemetry endpoints, and model APIs. Evidence is a route inventory with the model endpoints named. A locked-down analysis space with an unmanaged HTTPS egress is a locked-down analysis space in name only.

3. Bind a named principal to every inference request

Article 20 requires data altruism organisations to record which persons and entities processed the data, with contact details, dates, and purposes. A shared API key produces a record naming the key. Evidence is an identity-bound per-request record, produced by the pattern in identity-aware AI gateway architecture, which is also what makes every later item on this list answerable.

4. Classify protected categories before the payload leaves

Article 5 conditions attach to specific categories: commercially confidential data, data protected by intellectual property rights, and personal data. A context window assembled from a case file carries those categories with no label attached. Evidence is a per-request classification decision plus the block or redaction that followed, produced by prompt-level DLP.

5. Tag the permitted purpose onto each request

Article 12 prohibits a data intermediation services provider from using intermediated data for purposes other than putting it at the disposal of users. Encode the permitted purpose per route and per caller, and evaluate it in the request path. Evidence is a purpose-tagged policy decision record, which is what converts the condition from a statement in a notification into a control an authority can test.

6. Enforce and record the destination country

Article 5 paragraphs 9 to 14 condition transfers of non-personal confidential or intellectual-property-protected data to third countries, and Article 31 requires measures against unlawful international transfer of and governmental access to non-personal data held in the Union. Evidence is a region-scoped allowlist with a per-request destination and region record, covered in AI gateway data residency.

7. Fail closed when the constraint cannot be met

Configure the request path to reject rather than fall back when no compliant endpoint is available, the classification is unresolved, or the purpose is unrecognised. Evidence is a policy decision record showing the fail-closed outcome. My candid take: this is the item where compliance and uptime genuinely disagree, and a team that has not decided which way it goes has decided in favour of uptime by default, as fail-open versus fail-closed sets out.

8. Treat re-identification as a request-time risk

Article 5 prohibits re-identifying data subjects in protected data made available for re-use. Combining a pseudonymised record with surrounding context inside a prompt is a re-identification attempt regardless of intent. Evidence is a policy rule blocking the joining of identifier-adjacent categories in one payload, with the decisions recorded.

9. Move the record off the component that makes the call

The record backing every item above has to survive a question about the component that produced it. An application that makes the model call and writes its own log is attesting to itself. Evidence is an independently written, signed decision record, and the property is set out in AI audit log immutability.

10. Set retention against the reporting and re-use periods

Article 20 requires an annual activity report to the competent authority, and re-use agreements set their own durations. Records referenced in either inherit a retention expectation. Evidence is a written retention policy with the periods stated, compared across regimes in AI audit log retention requirements.

The checklist at a glance

What the sequence buys you

Items 3, 4, and 9 carry the weight. Identity binding makes a record answer the question Article 20 asks, classification makes it describe what actually left, and write-path independence makes it evidence rather than assertion. Items 5 through 8 are configuration once those three exist and stay unbuildable while any of them is missing.

The DGA controls mapping covers where each control fires in the request path, and the DGA audit-evidence view covers what each artifact looks like when a competent authority asks.

DeepInspect

Items 3 through 9 produce their evidence at one place: the boundary between your users or agents and the LLM APIs they call. DeepInspect sits inline at that boundary as a stateless proxy. It binds identity to each request, classifies prompt content before transmission, enforces per-role, per-route, and per-purpose policy with a fail-closed default including region constraints, and writes a signed decision record before the response returns to the caller.

For a secure processing environment, that replaces a containment claim with a query: every request that reached an external endpoint, what it carried, who sent it, and under which permitted purpose. Book a technical deep dive at deepinspect.ai.