Part 2 of a series on data residency, by Kisa Brostrom, CTO at BoodleBox
"Keep my data in the United States" sounds like a costless request.
It isn't.
It just moves some of the cost somewhere you can't see it.
When an institution requires US-only data processing, it's doing more than setting a compliance requirement. It's limiting where the compute behind that service can run, reducing the infrastructure capacity available to the provider and potentially increasing the cost of delivering it.
That's the tradeoff we explored in Part 1. But there's another cost that doesn't necessarily show up in the vendor's pricing.
And it starts with where that compute has to live.
When a workload is contractually required to stay in the United States, the infrastructure supporting that commitment has to be available within those geographic boundaries.
That means data centers. The same ones making headlines, and the same ones communities are organizing against as new facilities are proposed across the country.
The US already has more than 3,000 operating data centers, with over 1,500 more planned. Nearly 40% of planned facilities are in counties without an existing data center and increasingly, that expansion is moving into rural communities.
Source: Pew Research Center, April 2026
Those numbers represent more than a shift in where infrastructure gets built.
They represent a shift in who is being asked to support it.
A data center needs land, electricity, cooling, transmission infrastructure, and water. None of those resources are abstract to the community hosting it.
The institution gets the benefit of a US-only processing guarantee. But someone else has to physically host the infrastructure that makes that guarantee possible.
The electricity demand is local. The water demand is local. And the infrastructure required to support both has to be built and maintained somewhere.
In Virginia, growing electricity demand from data centers has raised concerns about future residential utility costs. In Pryor, Oklahoma, where Google operates a major data center, utility records documented more than 1.1 billion gallons of water consumed by the facility over a twelve-month period.
The impact varies depending on how facilities are designed and how infrastructure costs are allocated. But the demand for those resources doesn't disappear just because the institution consuming the compute is somewhere else.
A university checks a box. A rural county absorbs the grid pressure, the water demand, and potentially some of the utility costs.
"The benefits of AI may be distributed globally. The physical costs of the infrastructure are extremely local."
A university can require US-only data processing, sign the contract, and consider the compliance requirement satisfied.
But the communities hosting the infrastructure behind those guarantees are dealing with a different set of questions.
Can the local grid support the demand? Where does the water come from? Who pays for the infrastructure upgrades? And what does the community get in return?
Those aren't questions that typically appear on an institution's data residency checklist.
And that's the part of equity in AI we don't talk about nearly enough.
We spend a lot of time asking who gets access to the technology. We spend far less time asking who bears the cost of making that access possible.
That doesn't mean institutions should stop requiring US data residency. There are legitimate regulatory, contractual, security, and institutional reasons to require it.
And it doesn't mean we should stop building data centers. The infrastructure has to exist somewhere.
But we should recognize that these decisions don't happen in isolation.
A single institution's residency requirement doesn't determine where a data center gets built. But collectively, demand for geographically constrained compute influences where infrastructure capacity is needed, where investments are made, and which communities are asked to accommodate that growth.
When we demand that data stay within a particular geography, we're participating in a much larger set of infrastructure decisions, whether we acknowledge them or not.
And if we're willing to ask what a data residency guarantee costs our institution, shouldn't we also be willing to ask what it costs everyone else?
That's the part of the conversation we've been leaving out.
In Part 3, we'll bring that responsibility back to the procurement process with five questions that separate a data policy from a data habit.
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.
Every organization's data residency requirements are different. See our full security posture, then let's talk through yours.
Book a free consultation and demo →
Want to hear Kisa unpack the equity side of this in her own words? Watch the full talk below.
Learn more about the ins and outs of the BoodleBox workspace from our team of experts.
Schedule a meetingLooking for more information?
