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.

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.

Even anonymised date (which most healthcare data is btw.) has strict requirements on access control and copying.

As for “develop and test against”. There’s the entire field of data science and modeling that’s not focused with developing systems to expose the data, but doing analysis on the data.

That doesn't have to mean it's worse though. Testing with 10,000,000 fictitious accounts generated to cover lots of permutations of user data is a great idea even if the real data won't ever have some of those permutations. It's a testing technique called "fuzzing", and it's quite common.

Not necessarily, there is a lot of work done on synthetic data which closely matches the properties of the real data both in academia and increasingly in industry.

I see this particular development environment as an advantage for this particular situation. I work in health care, and in R&D we often have to help debug issues with a client implementation, which means having an anonymized snapshot of their data in our reporting system. Typically, we end up passing around DB backups and zip files of the client-specific code. It would be significantly easier to fire up a Docker container that was ready to go.

Have seen it quite a few times, but there needed to be a good reason and other options had to be exhausted. A few examples were due to zero-width characters which were sanitized by whatever tool that anonymized data, but broke something in the program.

There are brittle systems in healthcare.

I made the same mistake once. We should we glad we weren't fired.

On the other hand, you do need devs to be able to look at real data when it's absolutely necessary (generally with a code-enforced gatekeeper and an audit trail). And you need to make sure a dev can SSL into a node for repair/maintenance (again with an audit trail).

That's the argument for using one of the many Identity and Access Management tools/providers out there, including the systems that come baked into the cloud providers.