Let's be really clear here. It doesn't just make ML solutions a challenge. It makes them impossible.

Even with all the compute power and automation of google, you can't blindly create an ML model and say yes it works without a data scientist actually looking at the guts with row-wise access to the training/validation data.

You can't do analytics without giving engineers access to prod data. Not at even at Google.

And yet, they do.

Source: worked there, on a ML focused team.

Go on, tell us how it works so we can all start doing the same and save millions of dollars in risk/compliance crossing enablement.

https://cloud.google.com/solutions/sensitive-data-and-ml-dat... has some high level guidance on different techniques that can be applied, depending on the type of data you're working with.

I actually know this article, so I'll summarise it for the readers.

It covers de-risking data if it isn't required for ML models or is of low impact. Through removal of it, masking of it, or entropy injection to it. Every single one of these approaches is detrimental to an ML model and just make it useless unless the fields being controlled are't correlated to the outcome in the first place.

This article is an acknowledgement of the issue and the fact that solutions don't exist. Only risk management strategies which disable potential solutions.

Their ultimate answer is 'protect the data and give it to only a small restricted set of people'. Right back where we started.

Injecting entropy into your data in order to generate differentially private access actually typically improves model performance, rather than degrades it.

This behaviour is counterintuitive, but effectively you're enforcing a degree of regularization in a way similar to how data augmentation works. You'll get reduced training set performance and improved test set performance, as with other forms of regularization until you make it too strong.