When I had this same discussion, the response I got was its not a matter of trust. But apparently in the terms & conditions (that consumers do not read anyways, including myself). There is a part of the data not being viewed by anyone not using it for diagnosis or treatment of the patient. Basically, only anyone with a medical degree and part of the team treating the patient can access the data & does not mention about the engineer using the data to build a better system to improve the system used for healthcare. So, ideally they want a candidate with a double degree in software and medicine. This term is applicable to other domains also.
I do not accept the reason, but that is what it is.
... what?
But I think in general the idea OP was dismissing was generating synthetic data rather than attempting to anonymize prod data. In that case you have a risk of modeling the generator rather than your users.
The bottom line that if you want to draw insights from data, that particular data must make its way to the engineer unadulterated. If you de-risk some fields in your data via removal/masking/entropy, then you are excluding those fields from ml.
You are not talking about blinded machine learning, you're talking about not doing machine learning on sensitive data in the first place. The whole discussion is moot.
The best they get are aggregations (sufficiently large enough that you can't identity a person). Specific user information is only available if the user explicitly opts in to share it, and is scoped to the specific case for analysis.
It makes training/diagnosing ML models a challenge, to be sure
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.
Source: worked there, on a ML focused team.
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.
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.
If developers don't have access to production data, then the solution is useless. How do people not understand this in 2019?
Millions of dollars have been dumped into various products centred around the idea of synthesizing 'production-like' data and all have failed. Because synthesizing fake data destroys the signal that makes the original data useful in the first place. If the engineers don't have access to it, then they can't extract the value from it, then what the hell are you doing in the first place?
You think if you give engineers a synthetic dataset and they build a blind solution around it, that the users will be extract value out of that data? That myth was dispelled a decade ago and there doesn't exist a single synthetic data success story since then.
I've had clients coming to us with the notion that they can give us fake imaging data and we can generate diagnostic insights from it. This crap needs to stop. If you can't trust engineers with your data to extract value out of it, then go ahead and munge it in excel.