Lesson 4 — Security, residency and compliance
"Can we send this data to an AI service?" deserves a precise answer rather than a shrug in either direction. This lesson is what you need to know to give one.
The questions to ask about any AI service
Ask all seven. The answers vary by provider, by service and by contract tier, and assuming them is how organisations discover problems during an audit.
1. Is my data retained, and for how long? Some services retain inputs for a period for abuse monitoring. Some retain nothing. Some retain differently depending on your contract.
2. Is my data used to train or improve the provider's models? For enterprise tiers of the major providers, generally no by default. For consumer tiers, frequently yes. This distinction has caused real incidents when employees used personal accounts for work data.
3. Which region processes the request? Distinct from where data is stored. A service can store in your region and process elsewhere, which breaks residency requirements in ways that are easy to miss.
4. Can I use a private network path? Private endpoints keep traffic off the public internet. Usually available, usually not the default.
5. Who at the provider can access it? Look for encryption with keys you control and for documented access controls on their side.
6. What certifications apply? ISO 27001, SOC 2, and sector-specific frameworks where relevant. Check they cover the specific service rather than the provider generally, which is a common gap.
7. What happens when the model changes? Providers update models. Your output will shift without any change on your side, and for a regulated process that is a change-control event you need notice of.
Data residency
Two things get conflated, and both matter.
Storage location — where the bytes sit at rest. Straightforward to control, since you choose the region.
Processing location — where computation happens. Harder, because managed AI services do not always process in the region you store in, and some capabilities are only available in a subset of regions.
Where it binds:
| Requirement | Typical implication |
|---|---|
| EU personal data | Keep storage and processing in the EU; document transfers |
| Health data | Sector rules plus data protection law; often an explicit agreement with the provider |
| Financial services | Regulator expectations on outsourcing and often on exit plans |
| Public sector | Frequently a national or sovereign cloud requirement |
| Defence and government | Isolated regions, and sometimes on-premises only |
When residency cannot be satisfied, the answer is a self-hosted open model inside your own boundary. This is a substantial part of why open models matter commercially rather than only ideologically, and it is a legitimate architecture rather than a fallback.
The AI-specific security surface
Beyond ordinary cloud security, machine learning systems add their own exposures.
Training data leakage. Models can memorise and reproduce content that appeared repeatedly in training, including personal data. If you fine-tune on data containing personal information, the model itself may become a disclosure risk, which has implications for how you classify and store the model artefact.
Model extraction. With enough queries to a prediction API, an attacker can train a copy that approximates your model. Rate limiting and monitoring for systematic querying patterns are the practical defences.
Membership inference. Determining whether a specific record was in the training set. Consequential when membership is itself sensitive — that someone was in a medical study, for instance.
Prompt injection. Covered in the LLM course, and the summary is that it cannot be filtered away, so the defence is limiting what a compromised model can reach.
Supply chain. Downloaded models, adapters and datasets are artefacts you are executing. Verify provenance, prefer signed and well-known sources, and scan what you pull. Malicious model files have been distributed through public hubs.
Model artefacts as secrets. A trained model represents investment and may encode information about its training data. Store it with access controls rather than in a public bucket, which happens more often than it should.
What regulation is asking for
The direction is consistent across jurisdictions even where the specifics differ: obligations scale with the consequence of the decision.
Low-risk uses — internal search ranking, ticket routing — need little beyond ordinary data protection compliance.
High-risk uses — employment, credit, education access, essential services, law enforcement, safety components — attract requirements that are increasingly explicit:
- Documented risk assessment before deployment
- Data governance: where training data came from, what it represents, what gaps it has
- Technical documentation of design, performance and limitations
- Logging sufficient to reconstruct a decision
- Human oversight with genuine authority to override
- Accuracy, robustness and security appropriate to the purpose
- Bias evaluation broken down by relevant group, repeated after retraining
- Transparency to affected people, including a right to an explanation in several frameworks
Notice how much of this is the MLOps course: versioned data, model cards, prediction logging, subgroup metrics. The engineering practices and the compliance requirements converge, which is convenient — build it properly and most of the documentation falls out.
A practical baseline
If you do nothing else on a new AI system:
- Classify the data before choosing a service. What is in it decides what is permitted.
- Read the retention and training terms for the specific service and tier you are using.
- Use enterprise tiers for work data, and prevent staff using consumer accounts for it. This is a policy and communication problem more than a technical one.
- Keep processing in the required region, verifying processing and not only storage.
- Encrypt with keys you control where the data warrants it.
- Log predictions and access so a question can be answered later.
- Write a one-page model card even for low-risk models. It costs an hour and answers most future questions.
Not a technical control — it is that nobody told employees which tools are approved for which data. The most common real-world leak is a person pasting confidential material into a consumer chat interface because no approved alternative existed. Provide the approved tool and say so clearly, and most of this risk disappears.
In three sentences
Answering "can we send this data to an AI service?" requires seven specific questions — retention, whether inputs train the provider's models, which region processes rather than merely stores, private network paths, provider-side access, certifications covering that specific service, and notice when the model changes — and the answers differ by service and contract tier rather than by provider. Residency binds on processing location as well as storage, and when it cannot be satisfied a self-hosted open model inside your own boundary is a legitimate architecture rather than a fallback. Machine learning adds its own security surface on top of ordinary cloud concerns — training data memorisation, model extraction, membership inference, supply chain risk in downloaded artefacts — while the compliance requirements for high-risk uses converge almost exactly with good MLOps practice, so the most common real failure is organisational: nobody told employees which tool is approved for which data.