With AI and Sensitive Data, Trust the Architecture, Not the Policy

In any company, the risk and business-continuity planning are built from its most sensitive internal data - incident histories, dependency maps, the things that you’d never want outside your walls. So for a risk and resilience professional, an AI capability that could reason across all these sensitive data is an invaluable tool, but it could ultimately become a liability.

That tension now sits in front of every risk professional and executive weighing whether to build or buy an AI capability. Most of the reassurance from vendors on offer is either the wrong kind or inadequate.

When a risk compliance leader hears “AI” they carry two fears. The first is exposure: that private data sent to a model provider gets retained, seen, or used to train the next model. The second is hallucination: that the answer comes back fluent, confident, and wrong. Vendors answer the first fear with policy - a privacy toggle, a data-processing agreement, a line in terms that reads something like “we don’t train your data”. In fact, the major providers like OpenAI, Anthropic, and Google’s enterprise and API tiers do say exactly that today.

But a policy statement is just a promise. It can change with the next version of the terms. Regardless of a policy statement that reassures privacy and “no model training”, your data still routes through someone else’s systems, where it may be retained for a time, and under defined conditions, be seen by a human. So you are trusting an intention with a policy statement. For a company whose downside is a leaked trade secret or a market moving document read out of context, an intention is inadequate.

Here’s the distinction that I propose for executive weighing their options when adopting AI: There’s a difference between a vendor promising not to look and a system built so the vendor can’t.

I learned this by building Egret AI this past year. Egret is a solo B2B product that gives regulated teams a compliance-and-advisory assistant grounded in their own documents. The first version of the product was a single chat interface wired directly into OpenAI, Claude, Gemini, and a few open models. There were some operational problems: every provider had a different API, models were deprecated, rate limits throttled a small operator. But the bigger problem wasn’t the operational one: every one of those calls sent data out to a provider, and the only thing between my customers’ data and that provider was a policy.

So I rebuilt on Amazon Bedrock. The reason wasn’t performance, though that improved. It was that Bedrock changed who has to be trusted. On Bedrock, model providers run inside isolated deployment accounts they can’t reach into; prompts and outputs aren’t shared with them and aren’t used to train their models. The provider is removed from the trust equation by architecture, not by agreement. That’s a different kind of guarantee.

The organizations that most need private-data AI - big, regulated, capital-rich - often have the IT muscle to build it themselves. But for smaller companies, the build-vs-buy question still stands. If you’re that executive, the lesson isn’t “buy mine”, it’s the architectural guarantee - not a policy promise. This standard is achievable, so demand it, whether you build or buy.

Ask these questions, before your data touches any AI systems:

1. Does my data ever reach the model provider? With an isolated setup like Bedrock, the answer can be a flat no - by design, not by promise.
2. Who can see my raw data - and is that list short, named, and in my contract? Every system has a boundary. A credible vendor tells you exactly where it is instead of pretending there isn’t one.
3. Is that guaranteed by architecture, or promised by policy? Architecture survives a change of ownership and a change of heart. Policy doesn’t.
4. Can the vendor prove it? I can log into my environment and show a customer their own private data, where it’s stored, and - when they leave - evidence it was destroyed. Evidence beats a promise.

The AI conversation has been stuck on capability: which model is smartest. For anyone sitting on data they can’t afford to lose, that’s the second question. The first is where the data goes - and who you have to trust to believe the answer. So make it a system you can inspect, not a sentence in a policy document that you have to take on faith.