Why data location matters before a firm uses an AI tool
For a professional services firm, the question is not only where the AI vendor is based. The practical question is where client data, prompts, uploaded files, outputs, logs and backups are processed, stored, reviewed and deleted across the whole service chain.
That matters because client data can carry confidentiality duties, privilege, personal data, special-category data, commercial sensitivity and regulatory evidence. A public AI chat tool, an enterprise workspace, a legal AI platform and a privately hosted workflow can all have different answers to the same question.
The safest starting point is to treat location as a control decision. Before a team enters client data, the firm should know which systems receive it, which country or region handles it, how long it is retained, whether it is used for model training, who can review it, and what audit trail is available if something goes wrong.
The direct answer for UK professional services firms
Client data should only be processed and stored in locations that your firm has checked against the purpose, contract, data protection obligations and client confidentiality risk. A vendor saying the tool is secure is not enough. You need written terms that show the processing locations, subprocessors, retention period, training restrictions, deletion process and access controls for the exact product tier you intend to use.
For low-risk internal material, a contracted enterprise AI service with clear UK GDPR terms may be proportionate. For client-confidential matters, regulated advice, claims, audit evidence or legal work, the threshold should be higher. The firm should prefer approved tools with a DPA, controlled tenancy, auditable access, role-based permissions and documented data residency.
Map AI data flows before client data is exposed
What to check in the vendor contract and security pack
Ask for the answer in writing, and tie it to the exact plan or workspace you will buy. Consumer accounts, team plans and enterprise agreements often have different retention, training and region controls. The review should cover:
- Processing locations: where prompts, files, outputs, metadata and support logs are handled.
- Storage locations: where live data, backups, vector indexes, analytics logs and audit logs are stored.
- Subprocessors: every third party that can touch the data, including infrastructure, model, support and monitoring providers.
- Training and improvement use: whether prompts, uploaded documents or outputs can be used to train, fine-tune, evaluate or improve models.
- Retention and deletion: how long each data type is kept and what happens when a file, workspace or contract is deleted.
- Human access: whether vendor staff or contractors can review prompts, files or flagged outputs, and under what approval process.
- Audit evidence: whether the firm can see who sent what, when, from which account, and what the system returned.
The source article used for this draft makes the same practical point: paid or enterprise plans can improve controls, but the firm still has to check the DPA, training terms, retention, residency and subprocessor chain for the specific tier. Certifications are useful evidence, but they do not answer every data-location question on their own.
How the answer changes by tool type
Free public AI tools normally offer the least contractual control. They may retain conversations for safety, abuse monitoring or service improvement, and the firm may have limited visibility over region, human review and deletion. These tools should be blocked for client-confidential data unless a specific approved configuration says otherwise.
Enterprise AI workspaces are stronger when they include a DPA, training opt-out or contractual training prohibition, administrator controls, SSO, audit logs and configurable retention. Even then, the firm still needs to check region coverage and subprocessors. A UK or EEA residency option helps, but it should be matched to the actual data types and workflows being used.
Legal-specific and professional-service-specific platforms may add matter controls, document handling, privilege-aware workflows and stronger procurement evidence. The firm should still ask whether the platform relies on foundation model providers, which subprocessors receive data, and what contract governs each layer.
Custom or privately hosted systems can give the firm more control over data location, retention and access. They also move more responsibility onto the firm. If you build a private AI workflow, you need your own logging, permissions, deletion process, model-use policy, monitoring and quality review.
Governance controls to put around data location
The operational answer should be an approved-tool register, not scattered vendor PDFs. For each AI tool, record the allowed use cases, banned data categories, approved user groups, processing locations, storage locations, retention period, model-training position, DPA status, subprocessor list, audit-log availability and review owner.
Then connect that register to day-to-day workflow controls. If a tool is approved only for internal marketing drafts, staff should not be able to upload client matter files. If a workspace is approved for client work, it should have SSO, role-based permissions, audit logging, documented retention and a named professional owner who can evidence review.
Turn AI vendor checks into an operating model
A practical review sequence
- List the workflow and data categories the team wants to use with the AI tool.
- Separate public, internal, client-confidential, privileged and special-category data.
- Confirm whether the vendor is a processor, controller, or both for each data flow.
- Read the DPA, subprocessor list, data residency terms, retention schedule and security pack.
- Check whether prompts, files, outputs or logs are used for training, evaluation or product improvement.
- Decide what evidence must be kept: approval record, DPIA, vendor assessment, contract extract, audit logs and human review notes.
- Approve or reject the use case, then document the decision in a register staff can actually follow.
What a good policy decision looks like
A useful policy does not say all AI is safe or all AI is banned. It says which AI tools may touch which data, under which contract, for which work, with which human review and which evidence trail. That gives staff a route to use automation responsibly while protecting client confidentiality and regulatory accountability.
For example, a firm might allow an enterprise AI workspace for internal knowledge drafting, prohibit free public tools for client documents, require partner approval before any privileged material is entered, and route regulated client outputs through a human review checklist. That is clearer than a broad warning that staff will work around.
Implement AI controls in live workflows
