Does the Data Act require an AI risk assessment?

The regulation contains no general requirement to produce an "AI risk assessment" comparable to a named assessment under an AI-specific regime. The method here uses Data Act obligations as risk criteria for the services around an AI deployment. It helps an organization find operational failure before a switching request, contract dispute or international-access question exposes it. The European Commission's Data Act page confirms the regulation's cross-sector focus on connected-product data, contractual fairness, public-sector access and switching between data processing providers.

Which risks sit outside this assessment?

Model accuracy, prohibited AI practices, high-risk AI classification and model safety belong under other laws and governance frameworks. Credential theft belongs in IAM and incident response. Local model execution and STDIO agent traffic bypass an HTTP gateway. The Data Act assessment should stay tied to applicable data access, contract, switching, interoperability and international governmental access duties. That boundary prevents a broad AI risk register from being mislabelled as Data Act compliance.

EU Data Act AI Risk Assessment: Test Switching, Export and Transfer Exposure

The EU Data Act has applied since 12 September 2025. For an AI programme, its sharpest operational question is usually simple: can the organization move its data and digital assets away from a data processing service without losing security, continuity or usable records? The official regulation answers that through Chapter VI switching duties, contractual terms, export requirements and interoperability rules. Its text contains no generic AI risk-assessment template.

I would treat that absence as permission to build the assessment around failure scenarios. The useful unit is a service, a switch and a piece of evidence, rather than a broad score labelled "Data Act risk."

TL;DR

Start by deciding which AI components qualify as data processing services and record the reasoning.
Test switching as an engineering event, including exports, continuity, retrieval and erasure.
Assess Article 32 separately because it concerns conflicting third-country access to non-personal data held in the Union.
Keep model safety and AI accuracy in their proper regimes. The Data Act focuses here on data access, service switching and related safeguards.

Scope comes before scoring

Article 2 defines a data processing service as a digital service offering on-demand network access to a shared pool of configurable, scalable and elastic computing resources. Hosted inference, managed vector storage, model fine-tuning platforms and AI observability services may fit that definition according to their delivery model. Counsel should confirm the classification for each service.

Create one register row per component. Record the provider, service type, contract, data categories, exportable data, digital assets, regions and production status. Article 31 matters at this stage. Its Chapter VI exclusions cover certain custom-built services and non-production services supplied for testing and evaluation for a limited period. A proof-of-concept label taped to a production endpoint at 16:40 on a Friday is poor scope evidence. The actual service facts control the assessment.

The Data Act compliance checklist provides a companion inventory sequence. The risk assessment adds scenarios, likelihood, impact, owners and treatment decisions to that inventory.

Switching risk belongs to an exit scenario

Article 23 requires providers to remove commercial, technical, contractual and organisational obstacles that inhibit switching, porting exportable data and digital assets, or moving to on-premises infrastructure. Article 25 then makes the contract operational. The maximum notice period is two months. An ordinary transition can run for up to 30 calendar days, followed by at least 30 calendar days for retrieval.

Assess this by running a bounded exit exercise. Select one month of prompt and response history, policy configuration, evaluation material and audit records. Request an export, load it into a neutral environment and record every field that vanished or changed meaning. Then test access during the transition and deletion after retrieval.

The risk statement should name the consequence: "Policy decision records lose route and identity fields during export, preventing reconstruction after a provider change." That supports a treatment. "Portability risk: medium" supports very little.

Continuity and security need separate tests

Article 25 requires the source provider to act with due care to maintain business continuity during switching and to maintain a high level of security during transfer and the retrieval period. A continuity failure and a security failure need separate tests.

For continuity, document the functions the destination service must support and the maximum acceptable interruption. Exercise authentication, policy loading, model routing and record retrieval against the destination. Article 30 limits the express functional-equivalence duty to services concerning scalable and elastic computing resources limited to infrastructural elements, so avoid extending that duty to every SaaS or hosted LLM service. For other services, Article 30 focuses on open interfaces and machine-readable export when the stated conditions apply.

For security, test the temporary paths created by migration. Identify who can initiate an export, how the bundle is encrypted, where it lands, who can retrieve it and when credentials expire. A switch often creates a second copy, a second administrator group and a temporary bucket. Each deserves its own owner and closure date.

Export risk starts with the contract's data categories

Article 25 requires an exhaustive specification of categories that can be ported, including all exportable data. It also requires the contract to specify categories tied to the provider's internal functioning that are exempt where export would risk exposing the provider's trade secrets, provided the exemption does not impede or delay switching.

Compare the contract's list with the actual AI service. Prompts and completions are only the visible layer. The deployment may also depend on embeddings, evaluation sets, policy versions, tool definitions, safety configuration, fine-tuning artifacts and per-request decision records. Mark each item as customer input, generated output, configuration, provider-internal material or disputed.

Article 26 requires information about switching methods, formats, restrictions and technical limitations, plus an online register of data structures, formats and relevant standards. The Data Act audit-evidence guide shows the artifacts to retain when this comparison finds a gap.

Interoperability risk is measurable

Article 30 requires providers outside the infrastructure-only category to make open interfaces available free of charge for switching. Where the relevant common specifications or harmonised standards have yet to appear in the Union repository, the provider must export all exportable data in a structured, commonly used and machine-readable format at the customer's request.

Test semantic portability, not just file delivery. A JSON export can be machine-readable while carrying undocumented status codes, missing policy relationships or identifiers that collide at the destination. Load a sample and reconstruct ten decisions, then compare timestamps, caller identity, model destination, action and policy version with the source.

My blunt view is that a successful download deserves zero credit until another system can read it. The Data Act controls mapping ties each switching requirement to a technical control and a concrete artifact.

Article 32 needs its own legal and routing track

Article 32 requires providers of data processing services to take adequate technical, organisational and legal measures, including contracts, against third-country governmental access to or transfer of non-personal data held in the Union where that would conflict with Union or member-state law. It also sets conditions for responding to third-country decisions and requires customer notice before compliance, subject to the law-enforcement exception.

Keep this legal and routing track tied to Article 32's conditions. The article addresses governmental access and transfer rather than imposing a general data-residency mandate for every AI request. Assess provider entity, storage location, support access, legal commitments, request-handling procedure and technical routing as separate facts.

For HTTP model traffic, retain the destination endpoint and region for each request. A configured EU region says what should happen. A per-request record says what happened. AI data residency controls covers the enforcement design.

The risk register should drive treatment

Use one entry per scenario and include these fields:

Asset and service: the exportable data or digital asset plus the provider involved.
Applicable provision: the Data Act article and the reason it reaches the service.
Failure event: a specific switching, continuity, export, erasure, security or access failure.
Evidence: contract clause, export test, destination log, deletion confirmation or provider response.
Owner and treatment: the person accountable, the chosen action and the retest date.

Treatments can include contract amendments, retention changes, a neutral export schema, a second-provider rehearsal, region-scoped routing or acceptance signed by the risk owner. Legal interpretation stays with counsel. Platform engineering owns migration mechanics, while security owns transfer controls and independent traffic evidence. Procurement remains accountable for provider commitments.

Review the register after material contract changes, service redesigns and failed export exercises. A calendar-only review misses the events that alter the risk.

DeepInspect

DeepInspect contributes evidence and enforcement at a defined boundary: authenticated HTTP traffic deliberately routed between users or agents and LLM endpoints. It evaluates the identity and policy context supplied by the application, classifies prompt content, applies per-role and per-route decisions, records the selected destination, and writes a per-decision audit record outside the calling application.

That record can remain available when the model provider changes, which reduces dependency on the provider for traffic history and gives Article 32 assessments request-level destination evidence. DeepInspect does not supply contract terms, move model weights, export provider-owned fine-tuning systems, assess third-country court orders, or cover local execution, STDIO traffic, stolen credentials and direct requests that bypass the proxy. Those risks stay with their respective legal, platform and identity owners.

Book a technical deep dive at deepinspect.ai.