Does the DGA prescribe an AI risk-assessment form?

The regulation establishes duties for re-use of protected material, intermediation services, altruistic sharing and certain international access. It leaves organizations to translate applicable duties into governance and technical controls. The method here uses those duties as risk criteria for AI services that process covered data.

Does every AI deployment fall inside the DGA?

Scope follows the organization's role and the data-sharing arrangement. An ordinary enterprise LLM deployment may sit outside these DGA chapters. Counsel should document the role analysis before the team labels an assessment "DGA." Other regimes can still govern the same system.

Which evidence matters first?

Start with one production request. Retrieve the authenticated caller, holder, data category, approved purpose, destination endpoint, policy version, decision and timestamp. That record exposes missing joins faster than a generic control questionnaire.

EU Data Governance Act AI Risk Assessment: Scope the Data Route

Regulation (EU) 2022/868 has applied since 24 September 2023. For an AI deployment, its operational pressure lands on a specific data route: who supplied the data, which DGA role handles it, what purpose was approved, and where the prompt went. The official Data Governance Act text creates different conditions for public-sector data re-use, data intermediation services and recognised data altruism organisations. A single score labelled "DGA risk" hides those distinctions.

I would build the assessment around request scenarios and evidence. The useful result is a list of model routes that a legal owner, security architect and data holder can test together.

TL;DR

Establish the DGA role and affected data before scoring an AI risk.
Test purpose, recipient, destination and holder approval on real model requests.
Treat Articles 12, 21 and 31 as separate control tracks with different actors and evidence.
Preserve identity, data category, purpose, model route, policy version and decision for each tested call.

Role determines the assessment boundary

The European Commission's DGA overview describes four policy areas. They cover protected public-sector information, intermediation services, altruistic sharing and coordination through the European Data Innovation Board. Each area creates different obligations. An organization re-using protected material under Chapter II faces conditions set by the competent public-sector body. A data intermediation services provider operates under Chapter III. A recognised data altruism organisation sits under Chapter IV.

Create a role card for every AI-enabled service. Record the legal entity, DGA role and competent authority. The same card should name holders, affected subjects, permitted purposes, storage locations and approved processors. Add the production model endpoints and retrieval stores used by that service. The DGA compliance checklist provides the companion scope questions.

At 08:35, the architecture review should show one sheet with the holder, purpose and destination beside each route. A deck containing three generic cloud boxes gives the reviewer too little to assess.

Purpose risk sits inside the model request

Article 12(a) limits a data intermediation services provider's use of intermediated data to putting that data at the disposal of data users. Article 12(e) permits specified additional tools or services at the explicit request or approval of the data holder or data subject. The provision also confines third-party tools to the agreed purpose.

Turn that language into a request test. Select an approved summarisation flow and capture the data holder, declared purpose, calling identity, prompt category, tool, model endpoint and response handling. Then change one attribute: ask the same service to train an internal classifier, enrich a sales profile or route to a different provider. The policy decision should reflect the changed purpose before data leaves the controlled path.

Purpose belongs in the enforcement context rather than a paragraph inside the procurement file. A model request can remain technically valid while its purpose drifts beyond the approval recorded under Article 12(e). The risk statement should name that failure: "Shared mobility data reaches an LLM for product training outside the holder-approved analytics purpose."

Holder and recipient risk need request-level attribution

Articles 12 and 21 repeatedly anchor duties to data holders and data subjects. That makes attribution an assessment input. A shared service credential may identify the application while obscuring the holder whose material appears in the prompt. Aggregated vector retrieval can make the problem harder by pulling passages supplied under different permissions into one context window.

Test the join between a model request and its source records. The assessment should retrieve the holder identifier, permission record, purpose, data category and destination using one request ID. Where a prompt combines material from three holders, the system should preserve all three relationships or stop the request under the organization's rule.

Article 12(o) requires a data intermediation services provider to maintain a log record of the intermediation activity. The DGA audit-evidence guide describes how request records can support that broader activity log. My view is that a risk assessment deserves a failing grade when the team can identify the model but cannot identify the holder behind the payload.

Security risk includes unauthorised transfer, access and use

Article 12(j) addresses unlawful transfer of or access to non-personal data. Under Article 12(k), the provider must inform data holders without delay after unauthorised transfer, access or use of the non-personal data it has shared. The next clause requires an appropriate level of security for storage, processing and transmission. Recognised data altruism organisations receive the same holder-notification concept in Article 21(5).

Build at least four scenarios into the risk assessment:

an authenticated analyst sends shared non-personal data to an unapproved model route;
a fallback changes the configured EU endpoint to another region;
a retrieval tool exposes records beyond the caller's approved purpose;
a support identity accesses prompt history tied to a different holder.

For each scenario, record the preventive control, detection signal, containment action, holder-mapping method and evidence owner. The DGA incident-reporting guide covers the notification path after the trigger. The assessment's job is to expose the route before an event starts that clock.

Article 31 requires a separate transfer scenario

Article 31 reaches public-sector bodies, Chapter II re-users, data intermediation services providers and recognised data altruism organisations. It requires 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.

Assess provider entity, endpoint location, storage region, support access, routing fallback and contract commitments as separate facts. A region selected in an administration screen states the intended design. Request-level destination evidence shows the route that actually carried the data. Preserve DNS resolution or endpoint identity, provider account, region, request time and policy outcome for the tested call.

Article 31 also addresses qualifying third-country decisions and notice to the data holder before compliance, subject to its law-enforcement exception. Counsel owns that legal analysis. The technical assessment supplies the route, custody and access facts counsel needs. The DGA controls mapping connects those facts to control owners.

The register should name events and treatments

One row per service rarely gives enough resolution. Use one row per credible failure event and include:

the DGA role, article and reason the provision applies;
the holder, data category, approved purpose and model route;
the failure event and likely consequence;
the preventive, detective and corrective controls;
the evidence source, owner, decision and retest date.

A treatment can restrict a model route, require holder approval, split retrieval indexes, add purpose metadata, change a provider contract or accept a bounded risk through the designated owner. Link each treatment to a repeatable test. Article 14 gives competent authorities powers to request information necessary to verify compliance by data intermediation services providers, so an unsupported "low" rating offers little value.

Review the register after onboarding a new holder, materially redesigning a service, switching the model provider, rerouting traffic or responding to an incident. A yearly calendar review can miss the exact Tuesday when a fallback endpoint entered production.

DeepInspect

DeepInspect can enforce and record a defined part of this assessment: authenticated HTTP traffic deliberately routed between users or agents and LLM endpoints. The calling application supplies identity and purpose context. DeepInspect classifies prompt content, evaluates per-role and per-route policy, constrains model destinations, inspects responses and writes a per-decision audit record outside the calling application.

That boundary can support purpose, destination, holder-attribution and Article 31 route tests when upstream systems provide the required identifiers. Legal role classification, holder consent, contracts, third-country legal analysis, local model execution, STDIO traffic, stolen credentials and direct calls that bypass the proxy remain with their respective owners.

Book a technical deep dive at deepinspect.ai.