The sovereign work management playbook

Sovereignty gets used loosely. For a work-management platform it comes down to two concrete questions: where does your data physically live, and who can technically or legally reach it? Everything else - encryption, access logs, retention - sits on top of those two answers.

A platform can be 'EU-hosted' and still be operated by a vendor subject to foreign disclosure law. It can be 'encrypted at rest' while the vendor holds the keys. Sovereign work management means narrowing both the location and the reachability until they match your obligations.

• Location: the region and infrastructure your data sits on, including backups and logs.
• Reachability: which parties - vendor staff, sub-processors, governments - can compel or perform access.
• Control: whether you can inspect, restrict, and revoke that access yourself.

The deployment model is the load-bearing decision. It determines your residency story, your audit surface, and which procurement hurdles you'll face. Choosing features first and hosting later is how teams end up re-platforming a year in.

Three postures, in increasing control

1. 1Managed sovereign cloud - fastest to start; the vendor runs it in a region you choose.
2. 2Local cloud / your tenancy - runs in your cloud account or a national provider you already trust.
3. 3On-premise - fully inside your perimeter, for the strictest residency and air-gapped cases.

The US CLOUD Act lets US authorities compel US-headquartered providers to hand over data they control - regardless of where that data is stored. So 'data in Frankfurt' does not, by itself, settle the question if the operating vendor is reachable under that law.

This is why vendor posture belongs on the evaluation checklist next to region. A provider operating outside US jurisdiction changes who can legally compel access. It is not a guarantee against every legal process, but it removes one of the most common ones regulated buyers worry about.

The usual assumption is that sovereignty and AI are at odds - that to get agents you must send work to someone else's cloud. Homany is built the other way: agents operate against your workspace inside your deployment, and you decide which model provider keys they use.

That means you can bring your own keys, route to a model endpoint in your region, and keep the structured work data where it already lives. Agent-first design and sovereign hosting are not a trade-off in this model; they are designed to coexist.

1. 1Write down your residency and jurisdiction obligations before looking at tools.
2. 2Decide your deployment posture (managed, local cloud, or on-prem) against those obligations.
3. 3Put vendor jurisdiction and sub-processors in the RFP, not just region.
4. 4Confirm the AI/agent model keeps data inside your boundary and supports your own keys.
5. 5Pilot in the real posture you'll run in production - not a hosted demo that hides the hard parts.