The US does not have one privacy law. It has a growing patchwork of them, and almost all of them turn on the same thing: not whether you held personal data, but what you did with it. Where it went. Who you shared it with. Whether you sold it. Whether you let a consumer stop a flow they were entitled to stop.
That is a movement question, not a storage question. And most privacy programs are built to answer storage questions.
CCPA and its CPRA amendments in California, the Colorado Privacy Act, Connecticut, Virginia, Texas, Oregon, and the dozen-plus state laws that have followed all share a structure. They grant consumers rights over how their personal data is used and disclosed. They draw legal lines around "sale" and "sharing" of personal information. They require you to honor opt-outs, including a global signal a browser can send on a consumer's behalf. Each of those obligations is a claim about a data flow. The regulator, the plaintiff's attorney, and your own privacy counsel will all eventually ask the same question: can you prove the flow behaved the way your privacy notice says it does.
The gap between the policy and the plumbing
Privacy programs are usually strong at the policy layer and thin at the evidence layer.
You have a data map. You have a privacy notice that discloses categories of personal information and the purposes for which you use them. You have data processing agreements with your vendors. You have a consent management platform that records opt-out preferences. All of this is real work, and it is necessary.
None of it observes the actual movement of personal data through your systems at runtime. The data map is a description, usually built from interviews and refreshed on a schedule, of how data is supposed to move. The gap between how data is supposed to move and how it actually moves is exactly where state privacy enforcement now lives.
A concrete version: your notice says a category of personal information is used for service delivery and is not sold or shared for cross-context behavioral advertising. A new analytics SDK gets added to a service. It begins sending a personal identifier to an ad-tech endpoint. No engineer set out to violate the privacy notice. The integration was approved, the access was granted on purpose, the traffic is permitted by every control you own. The privacy claim is now false, and nothing in your stack flagged the move, because every control you have checks whether the move was allowed, not whether it matched what you told consumers you do.
Every move was permitted. The pattern is the breach.
What the laws actually ask you to prove
It helps to translate the obligations into the evidence each one demands.
Sale and sharing. California, Colorado, Connecticut, and others define "sale" and "sharing" broadly, and the definitions hinge on a transfer of personal information to a third party. To stand behind a claim that you do not sell or share a category, you need to show where that category of personal data actually flows and to whom. That is a movement record resolved to a destination and an identity, not a contract on file.
Opt-out and the Global Privacy Control. When a consumer opts out, the obligation is that their personal data stops flowing to the relevant recipients. Recording the preference in a consent platform is the front of the system. Proving the downstream flows changed is the back of it, and the back is where audits find the failures.
Purpose limitation and minimization. The newer state laws restrict processing to disclosed, reasonably necessary purposes. Enforcing that means knowing which jobs touch a category of personal data and where the data goes afterward, so a use that drifts outside the disclosed purpose is visible as a change in behavior rather than discovered in a deposition.
Vendor and processor flows. Your contracts bind your processors. They do not show you, in real time, that a processor integration started moving more personal data, or a different category, or to a new endpoint. The Vercel-style third-party incident is the template here: the permission was right, only the behavior changed.
In every case the asset you are missing is the same one. A faithful, runtime record of how personal data actually moved, resolved to the job and the destination behind each move.
Where runtime data movement evidence comes from
This is the layer Hilt is built for. Not the policy, not the consent record, the movement itself.
Hilt runs one lightweight collector that watches data movement at the kernel, metadata only by default, off the path. It does not inspect content to do this, and it does not have to read your data to record that a personal identifier left for a new destination. Each move is resolved to a probabilistic, source-dependent identity: which workload, which job, which destination, and whether this fits what that identity normally does. The collector is single-tenant inside your own cloud, on AWS, GCP, Azure, or Ali Cloud, and the events never leave your account, which matters when the data in question is the regulated personal information itself.
For a privacy program that produces three things a policy layer cannot.
A faithful map. Because the record is built from observed movement rather than from interviews, it reflects how personal data moves today, not how someone described it last quarter. When the analytics SDK starts shipping an identifier to an ad-tech endpoint, that flow appears as a new pattern against months of history, and a new pattern is a case, not a line item discovered in an audit.
Proof a flow changed. When a consumer opts out, or a disclosed purpose is supposed to constrain a use, the question is whether the downstream movement actually changed. Runtime evidence answers that with behavior rather than with a screenshot of a settings page.
A response that fits a regulated environment. When a move is genuinely dangerous, an exfiltration of a category of personal data through a permitted channel, Hilt responds with host-level network isolation, quarantine, from the control plane. It never sits inline, never blocks or alters traffic in the path of your application, and never becomes a point of failure between your service and your users.
What this does not replace
Runtime evidence is a layer, not a privacy program. Your consent management platform is still the system of record for preferences and the interface a consumer interacts with. Your data processing agreements still allocate legal responsibility to processors. Your privacy counsel still maps obligations to the specific state statutes that apply to your business, and the list of those statutes is still changing every legislative session.
Hilt adds the layer underneath all of that: the observed truth of how personal data moved, so the claims your program makes are claims you can prove. It closes the gap between the privacy notice and the plumbing, which is the gap state enforcement walks straight into.
The question to take to your own program
The useful test is the one a regulator or a plaintiff's attorney will eventually pose. Pick a category of personal information and a claim in your privacy notice, say that you do not share it for cross-context behavioral advertising. Then ask whether you can show, from runtime evidence rather than from policy, every destination that category of data actually reached last month, resolved to the job behind each move, and whether any of those destinations is one your notice does not allow.
If the honest answer is that you would have to reconstruct it from logs and interviews after the fact, that is the gap. It is the same gap whether the law is California's or one passed next session, because they all turn on movement, and movement is the one thing a policy document cannot observe.
If that question is live for your team, the fastest way to see what runtime evidence looks like against your own flows is a short, engineer-to-engineer technical call. Thirty minutes is usually enough to know whether the layer fits.