Jurisdiction, impact assessment and residual risk

An assistant serving users in the European Union routes inference to a provider region outside it. Transcripts contain personal data. The engineering team believes this is fine because nothing is stored in the destination region: the request goes out, the completion comes back, no database is involved. That belief is the most common jurisdictional error in AI deployments, and it rests on treating storage as the trigger. It is not. Making personal data available to be processed in another jurisdiction is a transfer whether or not anything comes to rest there, and remote access from another jurisdiction counts too.

So the obligation is the ordinary one: a valid transfer mechanism, such as a finding that the destination offers adequate protection or approved contractual terms between the parties, plus an assessment of whether the destination's legal regime undermines that mechanism in practice, plus supplementary measures where it does. Transport encryption does not satisfy this. TLS protects data from interception between endpoints; it does nothing about lawful access by authorities in the destination country, which is precisely the risk the assessment exists to evaluate, because the provider necessarily decrypts to run inference. Nor does a consent clause in the terms of service serve as a general substitute for a transfer mechanism.

Two practical extensions. First, the chain does not stop at your provider: subprocessors, model hosting partners, evaluation vendors and out-of-hours support teams with production access all extend the map, and each needs to appear in it. Second, region pinning is a contractual and architectural property that has to be verified rather than assumed, including for failover behaviour. A service that normally stays in region but spills over to another under load has an undocumented transfer, and load spikes are exactly when nobody is reading the architecture diagram.

When an impact assessment is required

A data protection impact assessment is triggered by risk to people, not by novelty of technology, though new technology is one of the signals. The recurring triggers are scale, sensitivity, systematic monitoring, and decisions that produce legal or similarly significant effects. Applying that to a portfolio of AI proposals gives fairly crisp answers.

• Automated triage of loan applications where the model's output materially determines whether an applicant is declined: an automated decision with a significant effect on individuals. Assessment required.
• Large-scale processing of health records to fine-tune a diagnostic support model: scale plus a special category of data. Assessment required.
• Continuous behavioural scoring of employees from communication metadata to flag insider risk: systematic monitoring, an imbalanced relationship, and consequential outputs. Assessment required.
• An internal code assistant trained only on the organisation's own synthetic test fixtures containing no personal data: no personal data, so no assessment trigger, though other governance still applies.
• A spelling and grammar suggestion feature operating on text the user is currently typing, with no retention: neither the scale nor the consequence that triggers an assessment.

The assessment is a process rather than a document, and its timing matters: it belongs before launch, when the design can still change in response to what it finds, and it should be revisited on material change. Adding a new data source, changing the model to one hosted in a different jurisdiction, expanding from a pilot cohort to the whole customer base, or moving an output from advisory to decisive are all material changes even when no code path looks different.

Writing down residual risk

The thread running through this course is that every control has a boundary: differential privacy does not cover population inference, k-anonymity does not cover homogeneous classes, de-identification does not reach anonymity, permission pre-filters do not stop an authorised user from asking a question they should not, and unlearning does not carry the guarantee that retraining does. A residual risk record states, for each material risk, what the control covers, what it does not, what the remaining exposure is, and who accepted it. Two failure modes to avoid: a register that lists only risks fully mitigated, which means the analysis stopped at the comfortable point, and a register where every residual risk is accepted by a job title rather than a named person, which means nobody accepted it. The value of this document is that it is the one artefact that survives staff turnover and tells the next team what the system's known limits are.