A supervisory authority does not ask whether you had a legal basis. It asks where a specific data subject's personal data went on a specific date, who could reach it, and how you know. Chapter V governs transfers of personal data outside the EEA, and after Schrems II the question moved from intent to fact. Not where the data was supposed to stay. Where it went.
Your architecture diagram says Frankfurt. The diagram is an intention. You can hand a regulator a data processing agreement, a sub-processor register, and that diagram, and still not be able to show where personal data actually moved at runtime, resolved to the job that moved it. That gap is where most teams sit right now and do not know it.
Sovereignty turns on movement, not posture
Residency is managed as configuration. You pick an EU region, set the residency flags, sign the standard contractual clauses, and consider the matter closed. The posture is necessary. It is not proof.
Your most valuable data leaves on access you granted on purpose. A replication job copies a table to a second region for resilience. An analytics pipeline pulls personal data into a warehouse a US-based team queries. A backup process ships an encrypted volume to a bucket whose region nobody re-checked after a migration. Each move was permitted. Every tool you own correctly let it through. None broke a policy. Some carried personal data across a border you told a regulator it would never cross.
Residency controls describe where data is supposed to sit. They go quiet the moment it moves, and personal data under GDPR is dangerous precisely when it moves.
The evidence you have today is inference
Watch how a team reconstructs a cross-border transfer now. Cloud provider flow logs say a connection happened between two endpoints. They do not say what data rode it or whose. Application logs say what a service meant to do. They do not say what crossed the kernel underneath it. The sub-processor register is a snapshot of contracts, not a record of behavior.
Stack those together and you get an argument: the transfer probably did not happen. Probably is the wrong word to say to an authority holding a named data subject and a date.
The cases that sink you are the ones nobody flagged, because nothing broke a rule. A failover that briefly served EU records from a US replica. An engineer who pulled a production dataset to a laptop outside the region to reproduce a bug. Each move defensible on its own. The pattern across them is the transfer you now have to explain in writing.
What runtime evidence looks like
The only place to see where personal data goes is at runtime, while it moves. Hilt watches data movement at the kernel, metadata only by default, off the path. It does not read your data to record that a move happened, from which workload, to which destination, in which region, behind which job.
Each move resolves to a probabilistic, source-dependent identity: which workload or user originated it, which job was running, where it went, whether the destination sits inside the boundary you committed to. That resolution separates "a connection occurred" from "this analytics job read personal data from the Frankfurt store and wrote it to a bucket in us-east-1." The first is a flow log. The second is what Chapter V asks for.
A move that crosses the EEA boundary deviates on several axes at once. The destination region sits outside the committed boundary. The volume is wrong for the job. The access pattern does not fit what that identity normally does. Any one axis alone is noise. Read together they are a pattern, and a pattern is a case, not an alert. The case names the data subject scope, the source, the destination region, the time, and the job. That is the shape of record an authority accepts.
Single-tenant, in your own region, by construction
Prove sovereignty with a tool that ships your telemetry to a vendor's SaaS and you have created the violation you set out to disprove: a fresh cross-border transfer, this time of the metadata that describes every personal data flow you have.
Hilt does not do that. The collector runs single-tenant inside your own cloud, in your own region: AWS, GCP, Azure, or Ali Cloud. The kernel events, the resolved identities, and the written cases stay in your account and your jurisdiction. Events never leave. The evidence that you kept personal data in-region is itself kept in-region.
That settles the objection a privacy team raises first. They are right to distrust a control that reads personal data to govern personal data. Metadata only is the default, so the system shows that a move went somewhere it should not have without inspecting what moved. Content-aware inspection is there when an investigation calls for it. It is never the price of admission.
The response stays off the path
When a move warrants action, the response is host-level network isolation, quarantine, from the control plane. The collector never sits inline. It does not block, drop, or alter traffic. Under GDPR that matters for a concrete reason. An inline control that mediates personal data flows becomes a processor of that data and a new point of exposure, plus a latency tax and a single point of failure on systems that move regulated data all day. Staying off the path keeps the governance layer out of the path it governs. Hilt observes the move instead of standing in it, at negligible overhead, on the order of 0.1% of one core and 4 to 8 MB of memory per host. The record gets collected without becoming part of the thing it records.
What to ask of any sovereignty control
Four questions separate a residency posture from a runtime record:
Does it observe movement or describe configuration? A residency flag states an intention. Ask whether the system records where personal data actually went, resolved to the job behind the move, not where it was configured to stay.
Where does the evidence live? Telemetry that proves in-region processing has to stay in-region and single-tenant, or the proof becomes the violation. Ask whether events leave your account at any point.
Does it have to read personal data to govern it? Metadata only by default lets the system see a move cross a boundary without inspecting content. Ask what the default vantage is, and whether content inspection is optional rather than mandatory.
Can it name the move, not just the connection? A flow log says a connection happened. A defensible record says which identity moved which class of data to which region at which time. Ask which one you would hand a supervisory authority, and whether it watches off the path so governance does not become a new point of exposure.
Posture versus proof
GDPR sovereignty is decided by where personal data goes, and the moves that decide it are the ones you permitted on purpose. Residency configuration tells a regulator where you intended the data to stay. Runtime data movement evidence, kept single-tenant in your own region, tells them where it went, resolved to the job that moved it. One is a posture. The other is a record. After Schrems II, that is the distance between an argument and an answer.
Ask your current stack which job moved this data subject's personal data, to which region, on this date, and how it knows the data stayed inside the boundary you committed to. If the answer is a diagram, you are missing evidence. If you want to see how the runtime record gets built without your telemetry ever leaving your region, that is a 30-minute, engineer-to-engineer call.