Data sovereignty

The luxury residence of a decade ago did not have to think hard about data sovereignty because the residence did not produce or consume the volumes of data that make the question consequential. The thermostat sent its setpoint to the manufacturer’s cloud; the security cameras recorded to a local DVR; the AV system operated locally with occasional firmware updates. The household’s data was small enough that the cloud dependencies were unremarkable, and the operational consequences of any of them failing were limited to the device that depended on them.

The sovereign estate today is different in both dimensions. The data volumes are substantial — the cameras alone produce terabytes per day, the substrate’s instrumentation produces continuous streams, the robotics platforms generate their own operational data, the autonomous fleet contributes telemetry. And the operational consequences of cloud dependency have grown commensurately — if the household’s reasoning layer depends on a vendor’s cloud service that becomes unavailable, the residence stops thinking on the family’s behalf. The data sovereignty question is no longer a privacy abstraction; it is an operational reality the residence depends on.

The principle the architecture commits to is straightforward to state: the residence operates fully on the estate’s own infrastructure, with external services used as resources where they add value rather than as backbones the residence depends on. The principle is straightforward; the engineering that delivers it is substantial.

The principle, more precisely

Data sovereignty is not the same as privacy, and the distinction matters because conflating them produces architecture that fails at both.

Privacy concerns who can observe the family’s information — the household, the operator, the integrators, the vendors, the various parties whose access to the residence’s data the family has authorized or not. Privacy is about who sees what. Sovereignty concerns where the residence’s capability comes from — what operates the household, what the operation depends on, who can disrupt the operation by choice or by failure. Sovereignty is about what the family depends on.

The two are related. A household whose information runs through cloud services has limited privacy from those services regardless of encryption claims; a household whose operation depends on cloud services has limited sovereignty regardless of the privacy posture of any individual provider. But the questions are distinct, and the architectural decisions that address one do not automatically address the other.

The local compute

The hardware foundation of data sovereignty is the local compute the estate operates. A serious deployment is meaningfully more substantial than the conventional residential server rack, and the architecture has converged on patterns the engineering community has worked out across the last several years.

GPU compute handles the AI workloads the substrate produces continuously — the reasoning layer’s inference, the security perception’s computer vision, the robotics platforms’ model execution, the natural-language interaction the household uses to engage with EstateAI. Current-generation NVIDIA enterprise GPUs (the H200, B200, and successors) are the established standard for serious local AI infrastructure; AMD’s MI300X family has become a credible alternative as the software stack has matured; specialized inference silicon handles specific workloads more efficiently than general-purpose GPUs for certain inference patterns. The deployment scale on a substantial sovereign estate is typically dozens of GPUs across the compute environment, with the count and configuration shaped by the household’s actual computational requirements.

Storage is engineered in tiers matched to the access patterns the data exhibits — NVMe arrays for the hot working data, SAS or SATA arrays for warm data with longer retention requirements, archival storage (tape libraries for the largest installations, or sovereign-controlled archival cloud) for cold data. The capacity at sovereign-estate scale is substantial; petabytes are not unusual when the camera retention, the operational history, the robotics training data, and the household’s own archives are accounted for. Networking within the compute environment uses 100, 200, or 400 Gigabit Ethernet engineered for the inference and data-movement patterns the workloads require.

Cooling is increasingly the constraining factor in serious local AI infrastructure. Current high-density GPU compute produces heat loads that air cooling cannot remove efficiently; liquid cooling (rear-door heat exchangers at moderate density, direct-to-chip at high density, immersion at the extreme) is the architectural commitment the equipment room has to support. Power for the infrastructure is substantial — a serious deployment can draw tens of kilowatts continuously — and is sized into the estate’s overall energy planning alongside the rest of the continuous-load infrastructure, with the resilience architecture (UPS, generator backup, the priority designation in islanded operation) treating substrate compute as the critical load it operationally is. On a substantial estate, the compute environment is a real data center — smaller than enterprise scale but engineered to the same standards rather than as an oversized network closet.

The models running on the infrastructure

The compute exists to run models. The architecture of what those models are, where they came from, and how they are maintained is part of the sovereignty discipline.

The foundation models that power most of the substrate’s capability were trained on cloud infrastructure at scales no household can match — the multi-billion-parameter language and multimodal models from frontier labs that have become the substrate of modern AI applications. The sovereign estate does not train these from scratch; it uses them. What it controls is which models, how they are deployed, and how they are kept current. Open-weights models from Meta (the Llama family), Mistral, Alibaba (Qwen), DeepSeek, and the broader open-source ecosystem can be downloaded and run on local infrastructure indefinitely, with no dependence on the originating organization’s continued cooperation or service availability. Closed-weights models from OpenAI, Anthropic, Google, and the other frontier labs are available through enterprise licensing relationships that typically involve private-tenant cloud deployments or hybrid arrangements; truly air-gapped on-premise deployments of frontier closed-weights models remain rare and primarily reach enterprise and government scale.

Fine-tuned and household-specific models are the layer that matters most for ongoing sovereignty. The foundation model that powers EstateAI is generic; the fine-tuned variant that has been adapted to the household’s patterns, preferences, and operational context is specific. The fine-tuning happens on local infrastructure (or on cloud infrastructure under the household’s control, with the model weights returning to local storage); the resulting customized model is a household asset that does not exist anywhere else. The same principle applies to the humanoid platforms’ learned behaviors, the security perception’s tuned thresholds, the automation’s scene programming, and the operational data that informs all of these. The household’s accumulated configuration is itself a sovereign asset.

The data architecture

What data the estate produces, where it lives, how long it persists, and what crosses the boundary to external services is the data architecture. The decisions are made deliberately and form the operational foundation of the sovereignty posture.

The hot operational data — current substrate state, active inference results, the working data the cognitive layer operates against in real time — lives on local NVMe storage. The warm historical data — camera footage retained for operational review, the substrate’s longitudinal data the analytical layer uses for pattern recognition, the operational history that informs ongoing optimization — lives on the warm storage tier with retention periods matched to actual operational value rather than vendor defaults. The cold archival data — long-term records, the family’s archives, operational history beyond active retention — lives in archival storage engineered for durability rather than access speed, with multi-site backup that protects against the failure of any single storage system or location.

The data that crosses the boundary is the explicit category whose handling matters most for sovereignty. Some data legitimately crosses — queries to external knowledge services, synchronization with vendor services the household chose to engage with, cloud backup of selected archival data. The architecture is explicit about what crosses, why, where it goes, and what the household’s recourse is if the external service becomes unavailable or its terms change. The implicit cloud dependence that consumer technology produces — data uploaded to vendor clouds without the household’s awareness — is the failure mode the architecture exists to prevent.

Backup follows the 3-2-1 discipline: three copies of important data, on two different media, with one off-site. The off-site copy may live on a sovereign-controlled cloud archive (encrypted such that the cloud provider cannot read the contents), at a second property the family maintains, or at a sovereign-controlled colocation facility — the discipline is that the data persists through the loss of any single storage system or location.

The privacy architecture

Above the connectivity and data architectures sits the privacy posture — the architectural commitments that determine who can observe the household’s information and from where the family appears to operate.

Encrypted DNS and VPN architecture determine what the household’s domain lookups and traffic origins expose. DNS over HTTPS (DoH) and DNS over TLS (DoT) route all household DNS through encrypted resolvers under the family’s control rather than through the ISP’s default. VPN and encrypted tunnel architecture routes the household’s traffic through endpoints chosen for legal posture and operational requirements rather than through whatever the consumer-grade default produces, with the encrypted overlay network that connects the family’s mobile workspaces back to the residence’s substrate.

Compartmentalization separates the household’s digital domains so a compromise of any single domain does not propagate. Personal devices, staff and operator workstations, the guest network, the operational technology that runs the residence, the robotics and humanoid platforms — each operates with the access it requires and no more, with the failure or compromise of any single domain bounded to that domain.

The vendor relationship discipline addresses what the integrators, platform vendors, and various commercial parties whose products operate on the estate can see. Modern smart-home and automation products often default to substantial cloud-side data collection; the architectural discipline is to configure these deliberately, disable the data collection that does not serve the household’s purposes, use on-premise deployment options where they exist, and maintain the relationship with vendors whose privacy posture matches the household’s. The jurisdictional dimension matters in ways the conventional residence does not have to think about — where the data lives determines who can compel its disclosure, where the cloud services are operated determines whose legal process applies, and the family’s travel and operational patterns interact with the jurisdictional posture of the various services the household engages with. These are factors to be deliberate about, with architectural decisions made in awareness of the legal and operational implications rather than as the result of choosing whatever vendor was convenient.

What cloud is genuinely good for

The architecture is local-first; it is not anti-cloud. Honest treatment of where cloud belongs is part of the sovereignty discipline.

The cloud is genuinely good for capabilities the household cannot replicate locally at reasonable cost — foundation model training at frontier scale, the broadest knowledge queries against the universe of public information, the specialized services whose value depends on aggregation across many users. The cloud is genuinely good for capabilities whose interruption is acceptable — entertainment, casual queries, consumer services whose unavailability would be inconvenient but not operationally consequential. The cloud is genuinely good for archival redundancy as part of the 3-2-1 backup architecture rather than as primary storage. What cloud is not for is the substrate’s continuous operation. The reasoning layer, the automation, the security analysis, the robotics platforms’ runtime, the household’s operational data — these run on local infrastructure because their interruption is operationally unacceptable. The architecture uses cloud as a resource where its strengths apply and treats it as exactly that: a resource, not a backbone.

The accumulation thesis

What gives the local-first architecture its long-term value is what accumulates within it across the years the family lives in the residence. The fine-tuned models that have learned the household’s patterns. The operational data that informs the analytical layer’s continued optimization. The humanoid platforms’ learned behaviors and household-specific competence. The security perception’s calibrated thresholds. The automation’s scenes refined through occupancy. The substrate’s longitudinal record of how the residence actually operates.

This accumulated configuration is itself an asset, and its disposition matters. On cloud-dependent architecture, the appreciation goes to the vendors whose services have learned the household’s patterns — the value accrues to their cloud, on their terms, with the household having no control over its disposition. On local-first architecture, the accumulation lives on the estate’s own infrastructure, under the household’s control, as a sovereign asset that increases in operational value the longer the residence operates. A residence that has been operating its cognitive layer for five years has accumulated configuration a brand-new deployment cannot replicate — the patterns learned, the thresholds tuned, the behaviors developed, the historical context the analytical layer operates against. On the local-first foundation, this accumulation is sovereign; on cloud-dependent architecture, it is rented.

Data sovereignty is the foundation the rest of the cognitive layer operates on. The local compute, the data architecture, and the privacy posture are the three threads that compose it, and the engineering that delivers all three is substantial. What it produces, when done well, is a residence whose intelligence is genuinely the family’s — running on the family’s infrastructure, against the family’s data, under the family’s control, accumulating in value as a sovereign asset across the decades the household lives with it.