Regulated Data and Where It Cannot Go

General orientation, not legal advice; requirements differ substantially by jurisdiction and sector, and are changing quickly.

The recommendations in “Regulated Data and Where It Cannot Go” become easier to sustain when implementation work has visible owners, dates and review time. Teams evaluating the official page can use it to coordinate the operational side of AI adoption and identify where governance tasks are being missed, without treating activity data as evidence of misconduct or as a substitute for asking people why they chose a tool.

For an independent benchmark, compare the local approach with ICO artificial-intelligence guidance; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.

Most of this subject is a balance of risk and benefit. Some of it is not, and the hard constraints should be identified first so that everything else can be proportionate.

The categories that usually bind

Personal data of identifiable people, which in several regimes requires a lawful basis, a processing record and controls on transfers.

Special-category data: health, biometric, and in several regimes more.

Regulated financial and client data in sectors with specific supervision.

Material covered by professional obligations: legal privilege, medical confidentiality.

And contractual confidentiality where a client agreement names permitted processors.

The client contract point specifically

Frequently the sharpest constraint and the one least considered.

Many client agreements specify who may process their data and require approval for new subprocessors.

Putting client material into an AI service is adding a subprocessor, and doing it without notice may breach the agreement regardless of how safe the service is.

Check your largest client contracts before writing policy.

Where the line is drawn

Not "AI is prohibited for regulated data" as a blanket.

But: regulated data goes only where there is a contract covering it, with the terms the regulation requires, and where the processing has been recorded.

That usually means an enterprise agreement with specific terms, or a tool deployed inside your own environment.

Cross-border transfer

Processing location matters in several regimes, and the default for consumer services is wherever the provider chooses.

Regional processing commitments exist on enterprise tiers.

If you have transfer obligations, this is the clause that decides the tool, more than any capability comparison.

Sector-specific rules

Health, financial services, legal practice, education and the public sector all have their own layers, and several regulators have issued specific guidance.

Find yours rather than reasoning from general principles.

And expect it to have changed since you last looked, because this area is moving faster than most.

The practical approach

List your regulated data categories.

For each, state where it may and may not go, in one line.

Put that list at the front of the policy, before the general guidance.

Everything else can then be proportionate, which is the argument of the whole collection.

What to check

Do you know which regulated categories your organisation holds?

Have you read what your largest client contracts say about subprocessors?

Does your regulator have specific guidance, and have you read the current version?

And is the hard list separate from the general policy?

The point

Client contracts frequently name permitted processors.

Putting client material into an AI service adds a subprocessor, which may breach the agreement regardless of how safe the service is.

Underlying all of this

Everything in this collection reduces to four habits: find out what people are doing and why before deciding anything, provide something good enough that the approved route is the easy one, write rules about information rather than about tools, and monitor the destination rather than the content. None requires a product, and a programme doing all four controls more than one built on prohibition.

The recurring pattern

The recurring pattern across every section here is the same: the response that feels like control reduces it. A ban removes visibility rather than use. Content inspection drives activity to personal devices. A discovery exercise with consequences produces quiet answers. In each case the organisation ends up knowing less about a risk it believes it has handled.