Scope around the data you are allowed to use

A compliance lead at a healthcare provider told me she used to be the person who killed AI projects. Not because she wanted to. Because of when she was invited. A team would spend months building something that used patient data, and the first time anyone asked her was at the security review, right before launch. She would read what they built, and she would have to say the data could not be used that way. Everyone would be furious, and they would be furious at her, when the real problem was that she had been asked the wrong question at the wrong time.

Her fix was to move herself to the front. Now she insists on one question in discovery, before design starts. Not “do we have the data.” The data almost always exists. The question is, “are we allowed to use this data, for this purpose, this way?”

Existence and permission are different things

The trap is that having the data feels like permission to use it. It is not. In her world the data sits right there, complete and clean, and a regulation or a consent form still forbids the specific use someone has in mind. The record exists. The right to point an AI model at it, for this reason, does not.

She gave me the shape of it. Data a patient gave for their treatment cannot be quietly repurposed to train a model that serves other patients, unless the consent covered that, which it usually did not. Data that is fine to use inside a clinical workflow may not leave the building to a vendor’s servers. Data you can read may not be data you can copy, retain, or send to a third party. Every one of those is a wall that stands even when the data is sitting in a table you own.

The reason this belongs in discovery, not at the review, is that the permission question reshapes the whole project. If the data cannot leave your environment, that rules out a whole class of external tools before you evaluate them. If the consent does not cover training, you scope a feature that uses the data at inference under a rule, not one that learns from it. Learn this early and it is a design constraint. Learn it late and it is a demolition.

Make legal scope part of the brief

Her habit now is to write the data permissions into the scope the same way she writes down the users and the decision. Before the team designs anything, they answer a short set of questions.

What data does this use, and what did the person who gave it agree to?
Can that data leave our environment, or must it stay inside?
Are we using it to run the feature, to train a model, or both, and is each allowed?
If a regulator asked us to explain this use tomorrow, could we?

If a project cannot answer those, it is not ready to design. A friend who leads data governance at a bank told me she runs the same play with a different word for the wall. For her it is consent and purpose limitation. Same lesson. The data existing is not the question. The question is whether the specific use is permitted, and that answer is cheapest to get before anyone builds around the wrong assumption.

None of this is about slowing projects down. It is about not building the version that has to be torn out. The legal scope is as real a constraint as latency or accuracy, and it is far more expensive to discover at the end.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week engagement at $2,500, we treat data permission as a discovery input, right next to data quality and access. We ask what the data may be used for, whether it can leave your environment, and whether the intended use matches the consent behind it. Sometimes that conversation narrows the design, and sometimes it sends the team toward an approach that keeps the data where it has to stay. Either way, you learn the wall exists while you can still design around it.

The data existing does not mean you are allowed to use it. Ask what you are permitted to do before you scope what you want to build.