EU Data Governance Act AI Audit Evidence: When a Prompt Leaves the Secure Processing Environment

Article 5 of the Data Governance Act lets a public sector body require that protected data be re-used inside a secure processing environment it controls and supervises. In practice that means a locked-down analysis space with no general outbound route, where a researcher works on health or statistical records that carry commercial confidentiality, intellectual property, or personal data, and only aggregate results leave.

Then someone inside that environment wires up a model endpoint. The records now leave in the body of an HTTPS POST, one prompt at a time, and the containment that the whole arrangement rested on is gone without a single firewall rule changing in a way anybody would notice. Regulation (EU) 2022/868 entered into force on 23 June 2022 and has applied since 24 September 2023. I want to walk the obligations an AI deployment touches and name what a competent authority asks you to produce for each.

Article 5: conditions for re-use of protected public sector data

Article 5 sets the conditions attached to re-use of protected data held by public sector bodies, including the option of a secure processing environment, technical measures preserving confidentiality, and a prohibition on re-identifying data subjects. Paragraphs 9 to 14 add conditions on transferring non-personal confidential or intellectual-property-protected data to third countries, including notification of the data holder.

The artifact is a per-request record showing which principal sent which content category to which endpoint in which country, retained across the re-use period. Without it, an authority asking whether protected records left the environment gets an answer describing the environment's design rather than its traffic. The re-identification prohibition sharpens this, because a prompt that combines a pseudonymised record with surrounding context is a re-identification attempt whether or not anyone intended one.

Article 12: conditions data intermediation services operate under

Article 12 sets the conditions for providing data intermediation services, including that the provider shall not use the data it intermediates for purposes other than putting them at the disposal of users, that the service sits in a separate legal entity from other services the provider offers, and that adequate measures protect the data during transmission and storage. Article 11 requires notification to the competent authority before the service starts.

Adding an AI feature to a data intermediation service is where the purpose-limitation condition bites. Content passing through the intermediary and into a model prompt is being used, and the artifact that resolves the question is a per-request record naming the purpose the policy permitted for that route and caller. A structural separation on the corporate register does nothing to establish that separation held in the request path.

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 data held by the organisation, together with their contact details, the dates of processing, the purposes, and any fees paid. It also requires an annual activity report to the competent authority.

An AI system processing that data is one of those entities, and the record has to name the human or service on whose behalf it acted. The artifact is an identity-bound processing record per request, which is what identity-aware AI gateway architecture produces at the boundary. A model endpoint reached through a shared service key generates a record naming the key, which answers none of Article 20's fields.

Article 21: safeguarding the rights of data subjects and data holders

Article 21 requires data altruism organisations to inform data subjects and data holders about the purposes of processing and, where the data are processed outside the Union, about that fact. Notification duties of this shape need a source of truth about where processing actually happened.

The artifact is a destination and region record per request. Routing libraries select endpoints on health and latency, which means the country a payload reached is a runtime property rather than a configuration one, and AI gateway data residency covers making that property an enforced choice.

Article 31: international access and transfer of non-personal data

Article 31 requires public sector bodies, natural and legal persons re-using data, recognised 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 would conflict with Union law, unless the conditions in the article are met.

The artifact is the same destination and region log, retained. This provision runs closely parallel to Article 32 of the Data Act, and one record answers both, as the Data Act audit-evidence view sets out.

The evidence map

Why the application's own logs answer none of these

Every row above asks a question with the same shape: which principal, sending what category of content, reached which endpoint, under which permitted purpose, at what time. An application that makes the model call and also writes the record is attesting to itself, and that arrangement fails in three specific ways. It logs the successful paths and misses the edge cases that generate findings. The record can be modified by the same component whose behaviour is in question. A crash between the model response and the log commit leaves the processing done with no account of it.

My honest view: the DGA is the regime where this gap is most likely to go unnoticed for longest, because the frameworks around public-sector data re-use are written in the vocabulary of environments and access approvals rather than requests. An environment can be perfectly specified and still have an outbound route that nobody described, and the specification will keep reading as accurate until someone asks for the traffic. The property that closes it is set out in AI audit log immutability.

DeepInspect

All six rows resolve to records produced 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, records the destination endpoint and its region, and writes a signed decision record before the response returns.

For a secure processing environment, that turns the containment claim into something checkable: a query showing every request that reached an external endpoint, what it carried, and who sent it. Book a technical deep dive at deepinspect.ai.