EU Data Governance Act AI Controls Mapping: Re-use, Intermediation and Altruism at One Request

Three regimes sit inside the Data Governance Act, and they ask unrelated questions. Chapter II asks a re-user of protected public sector data whether the conditions attached to that data held. A data intermediation service under Chapter III has to show it used what passed through it for nothing beyond making it available. Under Chapter IV, a recognised data altruism organisation names every entity that processed the data it holds, with dates and purposes attached.

For AI traffic all three converge on one moment: an HTTPS POST carrying a context window to a model endpoint. That request is where the principal is still known, where the protected category is still identifiable, where the purpose is still declarable, and where the destination country is still a choice. Regulation (EU) 2022/868 has applied since 24 September 2023. This maps its articles onto controls that fire in that request.

Article 5: conditions attached to re-use of protected data

Article 5 lets a public sector body attach conditions to re-use, including requiring the work to happen inside a secure processing environment it controls, applying technical measures that preserve confidentiality, and prohibiting re-identification of data subjects. Paragraphs 9 to 14 condition transfers of non-personal confidential or intellectual-property-protected data to third countries.

The control is classification of prompt content against the protected categories the conditions name, with per-role policy deciding whether that category may enter a payload bound for an external endpoint. It fires after payload assembly and before transmission. The evidence is a per-request classification decision joined to the policy outcome, produced by prompt-level DLP.

Article 5 again: the re-identification prohibition

The prohibition on re-identifying data subjects is a separate control from category classification, because the risk arises from combination rather than content. A pseudonymised record plus a job title plus a date of admission, all present in one context window, is a re-identification vector that each fragment passes individually.

The control is a policy rule on which categories may co-occur in a single payload for a given route. It fires in the same evaluation pass as classification, on the assembled object rather than on its parts. The evidence is a blocked-combination record naming the categories the rule rejected.

Article 12: purpose limitation for data intermediation services

Article 12 sets the conditions for providing data intermediation services, including that the provider shall not use the data for purposes other than putting it at the disposal of users, that the service is provided through a separate legal entity from the provider's other services, and that adequate measures protect the data in transmission and storage. Article 11 requires notification to the competent authority before the service begins.

The control is per-purpose policy evaluated at the request boundary, so a route serving an internal AI feature carries a different permitted purpose from a route serving intermediation itself. It fires at request admission alongside identity. The evidence is a purpose-tagged policy decision record, which demonstrates the separation held in the traffic rather than only on the corporate register.

Article 20: transparency records for data altruism organisations

Article 20 requires recognised data altruism organisations to keep accurate records of the persons and entities given the opportunity to process the data, their contact details, the dates and purposes of processing, and any fees paid, plus an annual activity report to the competent authority.

The control is identity binding at the boundary, carrying the end user or agent identity into the record for each inference call. It fires at request admission, ahead of payload assembly. The evidence is an identity-bound per-request processing record, produced by identity-aware AI gateway architecture. A shared service key generates a record naming the key, which populates none of the fields Article 20 lists.

Article 21: informing subjects and holders about processing outside the Union

Article 21 requires data altruism organisations to inform data subjects and data holders about the purposes of processing and, where processing happens outside the Union, about that fact. A notification duty of this shape needs a source of truth for where processing occurred.

The control is region-scoped destination routing with the region recorded per request. It fires at routing, before the connection opens. The evidence is a destination and region log, and the enforcement side is covered in AI data residency controls.

Article 31: preventing unlawful international transfer and governmental access

Article 31 requires public sector bodies, re-users, data altruism organisations, and data intermediation services providers to take reasonable technical, legal, and organisational measures to prevent international transfer of, or governmental access to, non-personal data held in the Union where that conflicts with Union law, unless the article's conditions are met.

The control is the same region-scoped allowlist, failing closed when no compliant endpoint answers rather than retrying against the nearest healthy one. It fires at routing, in the same evaluation as Article 21. The evidence is the enforced allowlist plus a decision log showing what happened when the constraint could not be satisfied.

The mapping at a glance

The row nobody instruments

Article 5's re-identification prohibition is the control that most DGA programmes handle with a training module and an acceptable use policy. Both are worth having. Neither produces an artifact, and neither fires at the moment a researcher assembles a prompt from three sources that are individually harmless.

My frank opinion: this is the requirement AI deployments will breach most often and detect least often, because the breach leaves no trace in any system designed to notice it. A document-level classification scheme reports clean, the network sees TLS, and the model provider's dashboard shows a token count. The only place the combination is visible is the assembled payload, one hop before it leaves, which is why the control has to live there and write down what it saw.

Three regimes, one record

The six rows above read different fields out of the same per-request record. Identity and purpose answer Chapter III and Chapter IV, classification and combination rules answer Chapter II, and destination with region answers Article 31 alongside Article 32 of the EU Data Act. The DGA compliance checklist covers the build order and the DGA audit-evidence view covers what each artifact looks like under questioning.

DeepInspect

Each row above resolves to an enforcement point in the request path, and DeepInspect is that point. It sits inline between your users or agents and the LLM APIs they call as a stateless proxy, evaluates identity, classification, purpose, and destination on every request, enforces per-role and per-route policy with a fail-closed default including region constraints, and writes a signed decision record before the response returns.

Because the record is written outside the application making the call, an Article 20 activity report becomes a query and an Article 5 question about whether protected records left the secure processing environment has an answer with timestamps on it. Book a technical deep dive at deepinspect.ai.