The narrative that's shaping AI adoption in regulated industries
There is a dominant answer circulating in healthcare, legal, and financial services about how to adopt AI responsibly: get a BAA with your AI vendor, confirm they have the right security controls, and you're covered.
This answer is legally defensible in many contexts. It is not, however, what a careful security reviewer hears when they ask “where does our data go?”
The BAA narrative and the data-never-leaves narrative are different claims. Understanding the difference — and which one your organization actually needs — is one of the most consequential architecture decisions you'll make.
What a BAA actually does
A Business Associate Agreement is a contract that creates a legal relationship between a covered entity and a vendor handling protected health information on its behalf. It defines what the vendor can do with the data, requires specific security and breach-notification obligations, and establishes liability in case something goes wrong.
A BAA does not prevent your data from leaving your environment. It does not encrypt your data in a way that the vendor cannot access. It does not mean the vendor's systems are built the way yours are. It means the vendor has agreed to handle your data according to defined standards, and you have recourse if they don't.
That is meaningful. It is also a different claim than “no outside AI ever sees your data.”
The two risk postures
Regulated organizations handling sensitive data have two genuinely different options when it comes to AI:
Cloud AI with a BAA. Your sensitive data travels to the vendor's infrastructure. The vendor processes it there. A contract governs what they do with it and what happens if they mishandle it. You retain recourse. You do not retain custody.
Private AI in a private, audited environment under a BAA. Your sensitive data is processed in a private, audited environment. No outside AI sees it. Nothing is transmitted to a third-party AI service. You retain both recourse and control over the outcome.
Neither is inherently wrong. But they are different risk postures, and presenting them as equivalent — or as the same posture described at different security levels — obscures a decision that organizations should be making deliberately.
Why this distinction is gaining urgency
Three things are converging to make the data-never-leaves posture more relevant than it has ever been.
Security reviewers are getting more specific
Organizations that have been through a security incident, a regulatory examination, or a sophisticated due diligence process have learned to ask more precise questions. “Do you have a BAA with your AI vendors?” is an early-stage question. “Does your AI vendor’s infrastructure have access to the actual data, or only to a representation of it?” is the question that follows.
Data-residency requirements are tightening
Financial services organizations under SOC 2, state-level data-residency laws, or their own customers’ contractual requirements are increasingly in environments where “the data went to a cloud vendor” is a reportable event, not an acceptable answer. The BAA framework was designed for healthcare PHI; it does not map cleanly onto every regulated-data context.
The AI development phase is a new exposure surface
The conversation about data boundaries has historically focused on production systems. But the development phase — where engineers build, evaluate, and iterate on AI systems — introduces a new set of exposures that BAAs rarely address cleanly. What data touched the dev environment? Was it sent to a third-party tool for testing? Does the BAA cover the vendor’s development infrastructure as well as their production infrastructure?
What the stronger answer looks like
For organizations where the data-never-leaves posture is the right one — and that's more organizations than the current market narrative suggests — the architecture looks different from the cloud-AI-with-BAA model.
The AI and analytics run inside a private, audited environment the organization can audit. Sensitive data is processed there. Only the outputs — insights, analytics, decisions — come out. The data itself never goes to the public cloud.
This approach changes the security-review conversation. Instead of a negotiation over contract language and vendor questionnaires, the conversation becomes about what you're building and what you need it to do.
It also extends to the development phase. When AI systems are built and evaluated inside the same controlled environment, the question of “what data touched the dev tools?” has a clean answer.
We work through this architecture on the → Sovereign AI Clean Room page. If your organization is evaluating the distinction between these two postures, that’s where to start.