← Back to Blog

Data residency isn't one decision. It's eight.

Data residency shows up in nearly every procurement conversation, every security questionnaire, every RFP. It sounds responsible. It sounds like common sense. "Keep my data in the United States" — what could be more reasonable than that?

But according to Kisa Brostrom, who spends her days thinking about AI security and compliance for a living, that checkbox isn't the simple, costless promise most institutions think they're buying. It's an architectural decision, a reliability decision, an economic decision and, increasingly, an equity decision that lands hundreds of miles away from the person who checked the box.

Here are eight things she wants procurement teams, universities, and enterprises to actually reckon with.

1. "US-based" and "US-bound" are not the same promise.

Most vendors will tell you their infrastructure is based in the United States. That's a much weaker claim than the one most institutions think they're getting.

There's a huge difference between saying our infrastructure is based in the United States and saying we can guarantee that your data will never be stored, processed, or touched outside the United States.

US-based means the provider's infrastructure normally operates domestically. US-bound is a contractual commitment that the workload cannot leave a defined geography. Ask which one you actually signed up for, because your data touches your application layer, storage, logging, document processors, embeddings, model providers, moderation services, and every subprocessor underneath. "Based" doesn't cover any of that.

2. Every restriction shrinks the pool you're drawing reliability from.

Providers want global endpoints, access to a broader pool of infrastructure across approved regions, for reliability, economics, scale, latency, and capacity. When one region hits a wall, the fix is to fail over somewhere else with room to spare.

The moment you contractually say the workload cannot leave the United States, you've intentionally made the pool smaller and that can create a conflict.

Institutions want extreme high availability and a hard geography restriction, in the same breath. You can't maximize reliability while simultaneously restricting the infrastructure available to deliver it. Those two asks work against each other.

3. That compliance checkbox already has a price tag.

This isn't theoretical. It's already on the invoice.

A geography guarantee has a price. Anthropic prices US-only inference at 1.1x the cost of global inference. OpenAI applies a 10% uplift to regional processing.

Constrain the supply available to serve you and the cost of serving you goes up. Every "US-only, no exceptions" clause in a contract is a line item — most procurement teams just haven't been shown where it lives yet.

"A geography guarantee has a price."

4. Data residency isn't virtual. It's concrete, steel, and groundwater.

If the compute has to stay in the United States, the compute has to physically exist in the United States. That means data centers, the same ones making headlines, the same ones communities are organizing against.

That's right. The thing everybody's talking about in headlines, the things that people are organizing against and shutting down. Those data centers are the very things that are necessary to provide you the data residency that you're demanding.

The numbers: the US already has more than 3,000 operating data centers, with over 1,500 more planned. And the map is shifting. About 67% of planned facilities are going into rural areas, compared to roughly 13% of those operating today. Nearly 40% of planned sites are landing in counties that don't have a data center at all yet.

13%
of today's operating data centers are in rural areas
67%
of planned data centers are headed to rural areas

5. Your "keep my data in America" clause just raised someone's water bill.

This is the part of the conversation that almost never gets followed far enough.

The institution gets the benefit. It gets to check US-only data processing. But someone else has to physically host the compute. The electricity demand is local. The water demand is local. The transmission infrastructure is local. And so are the increases in utility costs.

It's not hypothetical. In Virginia, residential electricity bills are projected to rise as much as 13% as data center demand grows. In Prior, Oklahoma, residents have already seen utility and sewer rates climb, tied in part to infrastructure built for new data center development. A single Google data center used more than 1.1 billion gallons of water in one year.

The benefits of AI may be distributed globally. The physical costs of the infrastructure are extremely local.

6. This stopped being a compliance decision. It's an equity decision.

When the community absorbing the pressure on its grid, water system, and land has the fewest resources to negotiate, resist, or demand anything in return, that's no longer a security conversation.

We're constantly talking about AI democratizing access. But equity cannot stop at who gets access to the model. We also have to ask who is absorbing the cost of making that access possible.

I want to be clear, this isn't an anti-data center message. The infrastructure has to exist somewhere if we want the technology. The challenge is sharper than that: can the communities hosting it also get the grid investment, the broadband, the durable jobs — something beyond "we needed the compute, so we needed the data center"?

"The benefits of AI may be distributed globally. The physical costs of the infrastructure are extremely local."

7. A border is not a cybersecurity control.

Here's the assumption baked into almost every RFP that doesn't survive contact with how AI systems actually work.

A server does not become harder to attack because it's in Virginia. Encryption does not become stronger because it's running in Ohio. Access controls do not suddenly become better because the data center is in Texas. The border is not a cybersecurity control.

Geography changes jurisdiction. Whose laws apply, which government could compel disclosure, what legal process a provider has to answer to. That's data sovereignty and it's a real and legitimate concern. But it is not the same question as whether your data is technically secure, and treating US soil as an automatic security upgrade is, well, a little lazy.

"The border is not a cybersecurity control."

8. You're treating every byte like it's the same risk. It isn't.

A public marketing document is not protected student information. An anonymous brainstorming session is not export-controlled research. Yet procurement routinely flattens all of it into one rule: data must stay in the United States.

That is easy. It's easier to write into an RFP. But easier does not necessarily mean better.

Mature governance starts with classification — public, internal, confidential, regulated, student data, health data, financial data — then moves to risk, then to proportionate controls.

Sometimes that's US-only processing. Sometimes it's zero retention, customer-managed keys, or data minimization so sensitive information never reaches the model at all. Different workloads inside the same institution may need different answers. That's harder to write than one blanket policy. It's also what actually managing risk looks like.

The five-question test.

Brostrom's closing challenge is the one that should probably open every procurement conversation, not close it:

  • 01What data are we protecting?
  • 02What specific risks are we trying to reduce?
  • 03What control actually reduces the risk?
  • 04What trade-offs does that control create?
  • 05Are those trade-offs proportionate to the risk?

If you cannot answer those five questions, then I don't think you have a mature requirement. I think you have a habit.

The goal was never to accumulate as many restrictions as possible. It's to manage risk responsibly, which means understanding the full system well enough to make decisions that are proportional, not automatic.

"If you cannot answer those five questions, I don't think you have a mature requirement. I think you have a habit."

About the author

Kisa Brostrom | Chief Technology Officer, BoodleBox

Kisa Brostrom leads AI systems architecture, data strategy, and platform governance at BoodleBox. With over a decade of experience in data engineering, applied machine learning, and distributed systems design, she has spent her career building scalable, privacy-aligned AI infrastructure in startup and growth-stage environments — the kind of environments where the gap between what technology can do and what people actually use it for is most visible.

At BoodleBox, Kisa has led the development of a privacy-first AI platform serving 100,000+ learners across 1,300+ institutions, including a sustainability-focused token-reduction architecture that makes equitable access to AI practical at institutional scale. She works daily at the intersection of what AI can do and what it should do for the people trying to learn with it.

The perspective in this piece is drawn from her work on AI security, compliance, and data governance at BoodleBox.

More in this series

Not sure what your institution actually needs?

Every organization's data residency requirements are different. See our full security posture, then let's talk through yours.

Visit the Trust Center →

Book a free consultation and demo →

Want it straight from Kisa, in full? The recording below walks through everything above.

Find out what's in it for you.

Learn more about the ins and outs of the BoodleBox workspace from our team of experts.

Schedule a meeting

Looking for more information?