A team wants to add a third-party AI provider hosted in another country to a feature your European customers use. What has to be true before that first request goes out?

The request is the transfer

The first thing to get right is that nothing needs to be stored abroad for this to be a cross-border transfer. Personal data leaving your boundary in the body of an HTTPS request to a provider that processes it in another country is the transfer, whether or not they retain a byte. Teams frequently reason about residency as a property of databases and are surprised that a stateless inference call raises the same questions, and it is a reliable indicator of how much of this a candidate has done before.

Transfer restrictions of the kind European law imposes are not a prohibition, they are a requirement that a recognised mechanism be in place before data moves — an adequacy determination covering the destination, or contractual clauses of the approved form, plus an assessment of whether the protections survive in that specific destination in practice. Which mechanism applies to which country changes over time, and mechanisms have been challenged and withdrawn before, so the honest engineering position is that you identify who owns that determination in your organisation, get it in writing before you build, and design so that a change in the mechanism's status does not require rewriting the feature. Naming the mechanism family is enough; asserting which one covers a particular country today is not an architect's call and the answer moves.

Read your own contracts before you read the provider's

The step candidates miss is that you are almost certainly a processor to your own customers, and your data processing agreements with them constrain you independently of what the law permits. Those agreements typically list your approved sub-processors, require notice before you add one, and give the customer a right to object — sometimes with a termination remedy attached. Notice periods and objection rights vary from contract to contract, which is precisely why this is a question for whoever holds the contract repository rather than something to assume.

The consequence for planning is uncomfortable and worth stating plainly in an interview: the earliest date the feature can be enabled for a given customer may be set by a notice period in their contract rather than by your release train. That is not a legal detail to be tidied up later, it is a dependency on the delivery plan, and discovering it after the feature has shipped means either disabling it for your largest accounts or being in breach of an agreement you signed.

What must be settled	Who answers it	What you keep as evidence
Which transfer mechanism applies to this destination	Legal or privacy function	The written determination, dated, naming the provider and destination
Whether the assessment of that destination is current	Privacy function	The assessment and its review date
Whether customer contracts permit this sub-processor	Contract owner, per customer	Notices sent, objections received and how resolved
What data the provider may receive	Engineering, with privacy sign-off	The field list, enforced in code, and the test that proves it
What the provider does with it	Vendor assessment	Their contractual commitments on retention, logging and training
Which customers are enabled	Engineering	Per-tenant configuration and its change history

Minimise the payload, and be honest about pseudonymisation

The engineering work that reduces the exposure most is deciding what leaves at all. Send the text that needs processing and not the record around it. Strip identifiers that the provider has no function for. Replace your internal customer key with a per-request token you can reverse locally, so the provider holds no stable identifier linking requests to a person.

Then resist the overclaim that ruins this argument. Removing direct identifiers does not make the data anonymous; if you retain the mapping needed to reattach it, the data is pseudonymised and remains personal data, and a transfer mechanism is still required. Free-text content is the worse problem, because whatever a user typed is going regardless of your field discipline, and users type identifiers, names and health details into fields designed for none of that. If the payload is free text, your minimisation story rests on content filtering and on the provider's commitments rather than on schema control, and saying so is stronger than pretending the field list covers it.

The provider's defaults are part of your design

Vendor assessment for this kind of integration comes down to a short list of behaviours that determine whether your architecture is coherent. Where is inference actually performed, as distinct from where the endpoint resolves, and does a regional endpoint mean regional processing or only regional ingress. What is retained, for how long, and is that configurable per request or only per account. What lands in their logs, since a prompt logged for abuse monitoring is retained content whatever the retention setting on the primary path says. Whether your data can be used to train or improve their models, and whether that is a contract term or a dashboard toggle someone can flip. And what their own sub-processors are, because they are yours too, transitively, and your customer's notice obligation does not stop at the first hop.

Every one of those needs to be a contractual commitment rather than a screenshot of a settings page, for the ordinary reason that a settings page is not evidence and can change without telling you.

The prototype that quietly became the data flow

The failure mode to name is not a bad decision, it is a decision nobody made. Somebody builds a spike with a personal API key against a copy of production data to prove the feature is possible. The demo goes well, the spike is the fastest path to shipping, and the integration reaches production carrying the boundary properties of an experiment: no field discipline, retention at the provider's default, no per-tenant gate, and no record anywhere that a transfer began.

What makes this the recurring case rather than an unlucky one is that the review gates are all attached to procurement and architecture milestones, and the spike passed through neither. The controls that actually catch it are unglamorous — egress restrictions that mean an unapproved endpoint is unreachable from production networks, credential issuance that goes through a request rather than a signup, and a rule that production data is not available in a development environment in the first place. If the answer to this question is only a policy stating that new processors must be approved, the policy will lose to the prototype every time.

Being able to prove where the data went

Finally, design for the question you will be asked later: show that no European customer's data reached that endpoint before the approval date. That is a claim about the past, which means it needs per-tenant gating that is configuration with a change history rather than a code path someone can reason about, egress logs that survive long enough to be examined, and a deployment record tying the enabling change to a date and an approver. The residency architecture and the evidence architecture are the same work, and teams that treat the second as documentation to be written afterwards find they cannot write it.

An outbound API call is a transfer, and adding a provider is simultaneously a legal question your privacy function owns, a contractual question your customer agreements own, and an engineering question about how little you can send. The one thing that is entirely yours is making the unapproved path unreachable.