How We Handle Your Data During an ML Project
Last updated:
The question we ask before asking for any data
Machine learning runs on data, and the natural instinct on a new project is to ask for all of it. We try hard to do the opposite. The first question on any SpiderHunts ML project is what the model actually needs to see, field by field, to make the prediction. It is almost always less than the full customer record.
A late-payment model needs invoice amounts, dates, terms and payment history. It does not need the customer's name, email address or phone number. A demand forecast needs product codes and quantities, not who bought them. Removing what the task does not need removes most of the privacy risk before any other control is required.
Pseudonymise first, then share
Where identities are not needed, we ask for data with them replaced by stable codes before it leaves you. Customer 48213 remains customer 48213 across every table, so the model can learn from their history, but we never learn who they are. Your system keeps the key that links codes back to real people.
We provide a simple script to do this on your side if that helps, so the identifying data never has to be sent anywhere. Pseudonymised data is still personal data under UK and EU GDPR if it can be re-identified, so the other controls below still apply. It is one layer, not the whole answer.
The safest customer record is the one that never leaves your building. The second safest is the one that leaves without a name attached.
Where the data lives
| Arrangement | When we use it | What it means for you |
|---|---|---|
| Your cloud account | Our preference for most projects | Data never leaves your environment; we get scoped access you can revoke |
| A project environment we set up for you | When you have no cloud account yet | Created in your name and transferred to you at handover |
| On-premise or private cloud | When rules or contracts require it | We work through your VPN or on your infrastructure |
| Exports sent to us | Small, pseudonymised samples during scoping | Stored in a restricted project store and deleted at the end |
Wherever possible, we choose the region to match your obligations, so training data for a UK or EU client stays in the UK or EU. Our wider approach to privacy in AI systems is in keeping your data private in AI systems.
Who can see it
- Only the named engineers on your project, listed in the proposal
- Access granted per person, never through shared accounts
- No data copied onto laptops; work happens in the controlled environment
- Access removed when someone leaves the project, and at the end for everyone
- No subcontractors, so nobody outside our own team is ever involved
We sign your NDA before the discovery workshop, and where we act as a processor of personal data we put a data processing agreement in place before any data moves. Both are routine and neither should take more than a few days.
When a language model is part of the project
Some ML projects include a large language model, for example to read free-text notes and turn them into fields a classical model can use. Here the rules tighten. We send the model only the text the task needs, redact identifiers before sending where we can, and use enterprise API arrangements under which your data is not used to train the provider's models.
If the text is too sensitive for a hosted model at all, which occasionally applies to health, legal or financial records, we look at a smaller model hosted inside your environment instead. We will tell you which provider and which arrangement applies to your project, in writing, so you can check the terms yourself.
Logs, copies and the places data hides
The data you carefully minimised can quietly reappear in debugging logs, notebook outputs, test fixtures and model artefacts. We treat each of those as sensitive too.
- Logs record identifiers and outcomes, not full records
- Notebooks are cleared of outputs before they are committed to the repository
- Test data is synthetic or pseudonymised, never a raw production extract
- Model files are stored with the same access controls as the data they came from
- Every data copy is listed, so it can be deleted rather than forgotten
What happens at the end
At handover, any data held outside your environment is returned or deleted, and we confirm that in writing. Access to your systems is removed unless you have asked us to stay on for support. You own the code from the first commit and, where agreed, the trained model and its training pipeline, so another team can retrain it without us.
If your data cannot be handled any of these ways, tell us at the start. We would rather design around a constraint in week one than discover it in week six, and it is part of the machine learning service we scope, not an extra. For the legal basics that sit underneath all this, GDPR basics for software projects is a useful companion.
Frequently asked questions
Do you need our customers' personal details to build a model?
Can the model be trained without the data leaving our cloud?
Is our data used to train anyone else's AI?
Do you sign a data processing agreement?
What happens to our data if we stop the project early?
Worried about sharing data for a model?
Tell us what the data is and what rules apply to it. We will explain exactly what we would need, where it would live and how little of it has to leave your control.