Data sovereignty is a design decision
Where your data lives and who can move it is settled in the architecture. Finding out in the audit is the expensive way.
Global companies operating in China tend to meet data sovereignty twice. First in a legal memo, which everyone reads and agrees with. Then in an audit, when it turns out the architecture never heard about the memo.
PIPL, CSL and DSL are not unusual in what they ask. Know what personal and important data you hold. Keep certain data in the country. Control and document how anything leaves. GDPR, the EU AI Act and a growing list of U.S. state laws ask related questions in different words.
Put it in the drawing
The questions are architectural, so the answers have to be too:
- Residency is a property of where a service is deployed, not a clause in a contract.
- Cross-border transfer is a data flow with an owner, a legal basis and a log, not an email attachment.
- Model training and inference are data flows as well. Training data and prompts have a location.
When we wrote the China Digital Playbook for a precision-optics group, the point was to translate global data-governance and security standards into controls an engineer could build against. Later, at an industrial machinery group, the same thinking went into a single Global Infosec Platform covering 170+ regulations across 60+ countries, where each jurisdiction is a delta on one baseline instead of its own project.
The cost curve
Designing residency in costs a few architecture reviews. Retrofitting it costs a migration, a delay and an awkward conversation with a regulator. The work is the same either way. Only the timing, and the price, change.
Treat sovereignty as a requirement in the design review, and it stops being a surprise in the audit.