GDPR Is Live. Your Model Is a Data Processor.

GDPR came into force on Friday. Judging by my inbox, most of the industry’s preparation went into consent emails and cookie banners.

That was the easy part, and it was mostly theatre. The hard questions are about machine learning, and I’ve seen very little serious work on them.

Four Questions Nobody Has Answered

What does erasure mean for a trained model?

A customer exercises their right to be forgotten. You delete their rows from the database. Straightforward.

But you trained a model on those rows six months ago. Their data shaped the weights. It is in there, diffused across millions of parameters, unrecoverable as a record but genuinely present as an influence.

Have you erased it? Nobody knows. There’s no established answer, no case law, and the technical options are all bad: retrain from scratch on every deletion request, which is absurd at any volume, or argue the weights aren’t personal data, which is a position I’d rather not defend to a regulator.

“The regulation was written for databases. A model is not a database, it’s a compressed opinion about a population, and nobody has decided what your customers’ rights are over an opinion.” — Sameer Gupta

What counts as an explanation?

Article 22 gives people rights around decisions made solely by automated processing with legal or similarly significant effects. There’s ongoing argument about how far a “right to explanation” extends, but the direction of travel is clear enough.

“The gradient boosted model assigned a score of 0.34” is not an explanation. Neither is a feature importance chart. An explanation has to be something a person can understand and, crucially, act on. If the honest answer is that four hundred weak signals combined to produce a number, you have a system you cannot explain to the person it affected.

Is your training data lawfully held for that purpose?

You collected customer data to deliver a service. Then you used it to train a model that does something else. Purpose limitation says the second use needs its own lawful basis, and “it was in our database” isn’t one.

I’d bet most companies have models trained on data collected for an unrelated purpose, with no documented basis, and have never asked the question.

Where does the data go?

If you’re calling an external API to score records, personal data is leaving your infrastructure and going to a processor, possibly in another jurisdiction. That needs contracts, records, and in some cases a transfer mechanism. A great deal of machine learning experimentation happens on laptops, with production extracts, sent to services signed up for on a corporate card.

What I’d Do Now

Not panic, and not stop. But do the following:

Inventory your models. Which exist, what they decide, what they were trained on, when, and by whom. Most companies cannot produce this list, and producing it is the prerequisite for everything else.
Record the lawful basis for each training set, and if you can’t establish one, that model has a problem you need to know about now rather than during an investigation.
Set a retraining cadence that gives erasure requests a bounded effect. If you retrain quarterly on current data, you can at least say deleted records stop influencing the model within a quarter. That’s a defensible position and it’s better than having no answer.
Decide where humans sit. Article 22’s protections are strongest for decisions made solely by automated processing. Meaningful human review changes the analysis, but it has to be meaningful. A person clicking approve on a queue of two thousand is not review, and a regulator will say so.
Prefer interpretable models where the stakes are legal. The simplest thing that works is usually right, and there’s now a compliance argument on top of the engineering one. A logistic regression whose coefficients you can print may be worth two points of accuracy in a regulated decision.

The Opportunity Nobody Is Framing

Here’s the part I’d put positively, because the compliance conversation is relentlessly negative and I think that’s a mistake.

Everything above is good engineering practice regardless of the regulation.

Knowing which models you run and what they do is basic operational hygiene. Most companies genuinely don’t know, and that’s a risk with or without a regulator.
Documenting where training data came from is what lets you debug a model two years later when the person who built it has left.
Being able to explain a decision is what lets you improve it. A model you can’t interrogate is a model you can’t fix.
Retraining on a schedule catches drift, which is a business problem long before it’s a legal one.

“Every control this regulation forces on you is something a careful team would have done anyway. The regulation just moved it from good practice to a deadline.” — Sameer Gupta

Final Thoughts

I don’t think GDPR will stop anyone doing machine learning. I think it will make the sloppy version considerably more expensive, and that’s largely a good outcome.

The companies that struggle will be the ones who treated Friday as a deadline that has now passed. The questions above don’t have deadlines. They’ll arrive as a subject access request, a complaint, or an investigation, at a moment you don’t choose.

I’d rather have the inventory ready.