Where Does Your Agent Send Personal Data? An EU and UK Transfer Evidence Record

Decentralised News · Editorial by Heath Muchena · Evidence reviewed 11 November 2026. Original DN analysis and local instrument; field testing is claimed only where expressly reported.

An agent deployment can involve more than the model endpoint shown in its configuration. A request may pass through a tool provider, an observability system or a support process. The organization reviewing the deployment needs a record of the actual recipients and purposes. “Hosted in Europe” is useful information, but it does not fill in those other fields.

Start with one flow: a defined category of personal data moving from one actor to another for a specified purpose. Then document the legal roles, locations and access conditions. A broad architecture diagram is a useful overview; a transfer assessment needs enough detail to distinguish the individual flows it contains.

Claim versus evidence: follow the recipient, not just the server

DN has not tested those claims against any provider. The table identifies evidence to request. A missing record is an unresolved question, not proof that a transfer occurred unlawfully.

Use the EU transfer criteria at the right level

The EDPB’s final Guidelines 05/2021 identify three cumulative transfer criteria: the exporter is subject to GDPR for the processing; it makes personal data available to another controller or processor; and the importer is in a third country or is an international organization. The importer’s own GDPR coverage does not by itself remove the transfer question. Other GDPR obligations can remain relevant even when a flow does not meet these transfer criteria. Source: EDPB Guidelines 05/2021, version 2.0.

This makes the actor relationship important. “Someone can access the system abroad” is a prompt for investigation, not a complete legal analysis. Identify whether the person acts within the same organization or for another recipient, what information becomes available and which processing activity is involved. Avoid assigning a legal result from an IP address alone.

In an agent architecture, maintain separate rows for the model service, external tools and other recipients where their roles or purposes differ. A single contract may cover several rows, but that should be shown rather than assumed. The record should also explain whether a recipient can send the data onward to another actor.

Separate the transfer route from the security control

The European Commission’s SCC materials describe contractual safeguards for relevant EU-to-third-country transfers and distinguish the scope of its adopted clauses. A signed document is therefore a starting point for reviewing the parties and processing it covers. It should not be treated as a generic permission slip for every recipient in a changing architecture. Source: European Commission SCC materials.

Maintain separate evidence for the reported transfer route and for the controls supporting it. An adequacy route has a scope that needs checking. A safeguards route needs its relevant assessment and documentation. A proposed exception requires its own factual and legal basis. The DN worksheet allows a route to be recorded but never selects the route on the user’s behalf.

The EDPB’s final Recommendations 01/2020 are the primary reference for supplementary measures accompanying transfer tools. DN links to that official material rather than compressing it into a universal encryption rule. The effectiveness of a measure depends on the actual processing and the access it permits. Source: EDPB supplementary-measures recommendations.

For an operational review, ask what the recipient can see in usable form, who controls the relevant keys and whether the task requires access to identifiable data. A control should be described in terms of its actual behavior. A security feature in a product brochure does not establish that it was configured or effective for the reviewed flow.

Keep the UK assessment distinct

The ICO’s current guidance explains that the UK legislation uses the term “data protection test,” while its guidance continues to use transfer risk assessment, or TRA. The January 2026 update reflects the Data (Use and Access) Act changes. Preserve the version of the guidance used rather than assuming an older worksheet has unchanged terminology or requirements. Source: ICO TRA guidance.

For the UK appropriate-safeguards route, the ICO describes the assessment using the standard that protection is not materially lower after transfer. It distinguishes this from an adequacy route. Those UK materials should not be silently substituted for the EU analysis or its terminology. Source: ICO explanation of a TRA.

If the same technical flow requires both EU and UK review, keep separate legal conclusions and supporting references. The engineering inventory may be shared. The applicable instruments and assessments should remain attributable to their respective frameworks. Choosing “both” in DN’s tool raises that requirement for separate review; it does not merge the standards into one answer.

The ICO publishes its own TRA tool. DN’s record is not a replacement for it. Use the DN inventory to gather the relevant facts and identify missing references before the responsible reviewer carries out the actual assessment. Source: ICO TRA tool.

Use the DN Agent Data Transfer Evidence Record

The record contains seven areas: the flow, processing roles, recipient access, transfer route, assessment, contractual terms and ongoing review. Select the relevant framework and whether personal data is involved. Record the route only if a reference supports the assessment. “Unknown” is a valid result and is preserved in the output.

The tool asks for aliases rather than the data itself. Do not paste client records, prompts containing personal information, private contract links or names into it. A label such as “support-access-review-A” is enough to connect the worksheet to a controlled internal evidence file.

Constructed example: an organization has references for the purpose, parties, deployment region and contract, but does not know where an external support provider can access logs. The record should show an unresolved access question even if the main model endpoint is located in the selected region. It should not infer a prohibited transfer or declare the system compliant.

When the safeguards route is selected, the output asks for the applicable assessment and supplementary-measure evidence. When adequacy is selected, it asks for current scope and recipient coverage. Selecting “no personal data” does not run an anonymity test; it prompts the reviewer to retain the assessment supporting that classification.

The JSON export includes the framework selection, route, reference aliases, documentation counts and unresolved questions. Its timestamp records when the worksheet was created. It does not assert that any source or transfer was independently verified, and its approval field remains null.

Review the parts of an agent system that change

An agent may acquire a new tool without changing its main model deployment. That new tool can introduce a new recipient, data category or purpose. DN recommends tying the evidence review to those architecture changes, rather than assuming that the initial cloud-region assessment covers every later integration.

Review observability separately. A team may carefully constrain the main request while allowing debugging output to contain the same information elsewhere. Identify the fields collected, who can access them and the applicable retention process. The worksheet does not inspect logs, so the reference should point to an actual review or documented configuration.

Include support and incident response in the flow inventory. The people who can access a system during a fault may differ from those involved in ordinary processing. Record the authorized path and the evidence used to assess it. A theoretical emergency procedure should not be presented as an observed access event.

DN’s runtime portability article asks what moves when a platform changes. This record asks what personal-data flows and legal evidence need review during that move. A portable application is not automatically an assessed transfer architecture.

Build an update process that preserves uncertainty

Give each flow a stable internal identifier. When a recipient, location, purpose or safeguard changes, create a new version and identify the difference. Keep the prior decision record so a reviewer can understand what the earlier assessment covered. A current diagram should not erase the historical facts behind an earlier deployment.

Assign unresolved items to the appropriate reviewer. Engineering may establish what data is transmitted; procurement may obtain terms; privacy or legal reviewers assess the applicable route. DN’s record does not imply that one team’s evidence answers another team’s question. It makes those dependencies visible without inventing a percentage of legal readiness.

Automated checks can flag a new recipient or an unexpected region value. They should not manufacture a legal conclusion from an unfamiliar vendor name. A useful alert states the changed fact, the affected record and the review that has not yet occurred. That is a stronger operational result than a green badge based on incomplete metadata.

Methodology and limitations

The article uses primary EU and UK sources and keeps their scopes separate. It does not cover China’s data laws, every localization requirement, sector-specific rules or the law of every recipient country. It does not publish an adequacy-country list, because a real assessment must check the current decision and its scope for the actual recipient and flow.

DN’s original method counts seven documentation areas. The counts are not a probability of lawful processing or a measure of privacy protection. A reference may be insufficient or contradicted by the implementation. The instrument does not analyze a contract, inspect network traffic, test anonymization or execute any transfer.

Frequently Asked Questions

Does an EU cloud region settle the transfer question?

No. Record the relevant actors, access and onward flows as well as deployment geography. Apply the appropriate legal assessment to those facts.

Can the same record cover EU and UK processing?

The technical facts may be shared, but keep the applicable legal assessments and references separate. The tool explicitly flags a selection of both frameworks.

Do signed clauses mean the review is finished?

Check their scope and the applicable assessment and safeguards. A contract reference alone does not establish how the system operates.

Does DN’s export authorize a transfer?

No. It is an evidence inventory containing self-reported references and unresolved questions. It is not an official assessment tool or legal approval.

Corrections and change log

Send corrections with the official source, jurisdiction, version and affected passage to press@decentralised.news. Do not send personal data or private contracts. 11 November 2026, version 1.0: introduced the flow-level evidence record, separated EU and UK assessment and preserved the current ICO terminology. No global restriction score is published.