EU Data Governance Act LLM Requirements Follow the Data-Sharing Role

The EU Data Governance Act regulates data-sharing arrangements rather than model technology. An LLM enters the analysis when its prompt, retrieval context, output or training workflow touches data handled under one of those arrangements. The official text of Regulation (EU) 2022/868 has applied since 24 September 2023. Its requirements follow the organization's role, the data holder's terms and the purpose of the processing.

I want to translate that structure into an LLM control specification. The first task is role classification. The second is proving what happened on each production route.

TL;DR

• The DGA creates role-specific data duties rather than a separate LLM rulebook.
• Map every model workflow to its holder, purpose, data category, endpoint and DGA role.
• Data intermediaries need purpose controls, security and an intermediation activity log.
• Article 31 adds safeguards for conflicting third-country access to non-personal data held in the Union.

Protected public-sector data sets the first boundary

Chapter II addresses re-use of certain protected data held by public-sector bodies. The European Commission's DGA page explains that the Act creates a mechanism for re-use of protected public-sector data that remains subject to rights of others, including commercial confidentiality, statistical confidentiality, intellectual property and personal-data protection.

An LLM workflow used by a re-user should inherit the conditions imposed by the competent public-sector body. Record the approved purpose, permitted users, protected categories, processing environment, export restrictions, retention and any prohibition on re-identification. Then attach those facts to the application route that calls the model.

A retrieval system can turn a seemingly narrow query into a broader disclosure. One prompt may pull five passages from a protected dataset and send them to an external endpoint. The risk sits in the payload and destination, not in the label "assistant." The DGA compliance checklist covers the scope and approval artifacts that should exist before that route enters production.

Data intermediaries need purpose-bound LLM tools

Article 12(a) limits a data intermediation services provider's use of intermediated data to putting the data at the disposal of data users. Article 12(e) allows the provider to offer specified additional tools or services that facilitate exchange, such as temporary storage, curation, conversion, anonymisation and pseudonymisation, when the data holder or data subject explicitly requests or approves them. Third-party tools must serve that purpose.

An LLM summariser, classifier or transformation service is one of those tools according to the facts. The implementation should record which holder approved it, the exact purpose, permitted data categories, model route and output handling. A policy engine can then compare the live request with that record.

The requirement is concrete at 14:12 when a developer changes a route from an approved EU-hosted model to a general provider endpoint. A pull request may show the code change. The enforcement record should show which requests encountered the new route and which rule permitted or denied them.

Neutrality and separation affect architecture

Article 12 separates the intermediation service from other services supplied by the same legal person and requires the service to operate through a separate legal person. It also places conditions on data use and metadata. Those provisions matter when the intermediary wants to use shared data to improve its own model, tune a classifier or create a secondary analytics product.

Build architectural separation into the LLM design. Keep holder data, model-evaluation material, provider telemetry and internal product-training corpora under distinct purposes and access paths. Route policy should distinguish an approved exchange function from internal model development. Procurement records should identify each model provider and subprocessor that receives payload content.

My blunt opinion is that "we use the data to improve the service" is an unusable purpose statement for a DGA intermediary. It combines several processing goals and gives engineering no rule to enforce. A useful statement names the tool, data, user, output and retention period.

The DGA controls mapping links separation, purpose and route constraints to specific evidence owners.

Security requirements reach prompts and responses

Article 12(j) addresses unlawful transfer of or access to non-personal data. Under Article 12(l), storage, processing and transmission require an appropriate level of security. The preceding clause adds data-holder communication without delay after unauthorised transfer, access or use of shared non-personal data. Recognised data altruism organisations receive a parallel holder-notification duty in Article 21(5).

Translate those duties into LLM controls on identity, content, destination and record integrity. The calling application should propagate the authenticated principal and approved purpose. Content classification should identify protected categories before transmission. Destination policy should restrict model providers and regions. Response inspection should apply the organization's output handling rules. Every permit, block or redaction should create a time-stamped decision record.

Security also includes bypass analysis. Inventory direct provider SDK calls, browser-based model access, batch jobs and agent routes. An HTTP gateway sees traffic deliberately sent through it. Network, endpoint and cloud controls must address alternate paths.

Activity logs need decision context

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. For an LLM workflow, a provider status code gives weak evidence because it omits the holder, purpose, caller and policy.

The request record should include:

• a unique request and correlation ID;
• the authenticated human or workload identity;
• the data holder and approved purpose reference;
• prompt and response classifications;
• model provider, endpoint and destination region;
• policy version, decision, reason and timestamp;
• an integrity reference and retention class.

Raw prompt retention deserves a separate decision. Some teams can satisfy evidence needs with classifications, hashes and protected content references. Others require controlled excerpts for incident reconstruction. The DGA audit-evidence guide explains the trade-off. Keep the write path independent of the application making the model call so a crash or code change cannot erase the only account of the decision.

Article 31 adds international-access safeguards

Article 31 requires covered public-sector bodies, 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 access would conflict with Union or member-state law.

For an LLM route, capture the provider legal entity, processing region, storage behavior, support access, subprocessors, fallback routing and contract safeguards. Evaluate each fact with counsel. A provider's regional configuration records intended placement. Per-request endpoint and region evidence records actual routing.

Article 31 also sets conditions around third-country court or administrative decisions and holder notice before compliance, subject to the law-enforcement exception. A gateway supplies routing evidence for that review. It cannot decide the validity of a foreign order. Keep those responsibilities separate in the control matrix.

Operational requirements belong in a route specification

Create one specification per model route. Name the DGA role, holder, purpose, model, region, permitted identities, data classes, retention, incident owner and evidence sink. Add tests for approved and rejected requests. Re-run them after a provider change, policy update, retrieval-source change or material contract revision.

The specification should also say what happens when context is missing. A request carrying protected data with no holder or purpose reference should fail closed under the organization's policy. Log that denial with the same schema used for permitted calls. Denials prove that the control operated and often reveal integration gaps before protected data moves.

Keep adjacent regimes in separate rows. GDPR can govern personal data in the same prompt. The EU AI Act can govern a high-risk AI use. NIS2 can add cybersecurity duties. The DGA analysis remains attached to the data-sharing role and its provisions.

DeepInspect

DeepInspect operates on authenticated HTTP traffic deliberately routed between users or agents and LLM endpoints. It consumes identity and purpose context supplied by the application, classifies prompt content, applies per-role and per-route policy, constrains destinations, inspects responses and writes a per-decision audit record outside the calling application.

That mechanism can support purpose-bound model access, route restrictions and activity evidence. DeepInspect leaves legal role classification, holder approval, contracts, foreign-order analysis, local model execution, STDIO, stolen credentials and direct bypass traffic with the teams that own them.

Book a technical deep dive at deepinspect.ai.