Frontier APIs are not always an option
Frontier-hosted APIs assume your data, your users, and your regulator are all comfortable with the data leaving the perimeter. For a growing share of regulated work, that assumption fails before the conversation starts.
Sovereign deployment is not a fallback. It is a parallel engineering practice with its own constraints, its own tradeoffs, and its own operating model. The earlier teams plan for that, the cheaper the first deployment lands.
Three constraints define the work
Model selection is the first. Open-weights candidates evaluated against your benchmarks beat the assumption that the biggest model wins. Infrastructure is the second: sizing, quantization, and the choice between on-prem hardware, private cloud, or air-gapped deployment. Security and access controls are the third: audit logging, prompt filtering, and data-residency controls that survive an audit.
The operations question is real on day two
A sovereign deployment that ships without an operations plan is a system that quietly degrades. Prompt rot, model updates, and data shifts hit private deployments the same way they hit frontier-hosted ones. The runbooks need to be part of the build, not a follow-up engagement.