Your Privacy Policy Drifts Every Time You Ship.

Twice this year I’ve audited my own legal pages against what the site actually does, and both times I found the policy describing a site that no longer existed. Nobody was hiding anything. The site kept shipping and the words stayed where they were.

The first catch was in June, and it was the bad kind. My privacy policy described Ask Sage, my retrieval demo, as in development and not yet accepting users. True when the sentence was written. By June the demo was live on the site, and every question a visitor typed into it was traveling through a Vercel-hosted backend to OpenAI to generate the answer. A real data flow, involving a processor the policy never named, described in writing as something that didn’t exist yet. The gap between those two states is exactly the gap a privacy policy exists to close, and mine had it.

The second catch was this month, and it cut the other direction. The policy claimed Cloudflare Turnstile, the human-check widget, runs on my contact form. It doesn’t. The contact form blocks bots with a hidden honeypot field and a timing check, and Turnstile actually runs on two of the AI demos. The protection I claimed was stronger-sounding than the protection I had. Overstating your security posture isn’t a neutral error either. It’s a written claim someone can hold you to.

Neither of these came from carelessness with the legal pages. The June version was accurate the day it went up. I checked. That’s what makes this failure mode sneaky. Legal pages don’t break when they drift. There is no failing test and no 500. The build stays green while the words describe last quarter’s site. Every feature you ship, every demo you wire to a provider, every form you add quietly moves the ground out from under sentences you wrote months ago.

The mental shift that fixed it for me was treating the legal pages as documentation, because that’s what they are. Documentation of what data comes in, where it goes, who processes it, and how long it lives. And everybody knows what happens to documentation nobody re-reads. It rots. The docs for a codebase drift when the code changes, and a privacy policy drifts when the product changes, for identical reasons, on an identical schedule.

Documentation problems have documentation answers, so here’s the process that caught both drifts. Map the actual flows first, from the code, ignoring what the policy says. Which endpoints accept visitor input. Which of those calls a third party, and which third party. What lands in a database, what gets emailed, what sits in localStorage. Then read the legal pages against that map, line by line, and every mismatch goes one of two ways. Reality is fine and the words are stale, so fix the words. Or the words describe something reality should be doing, and now you’ve found a real gap wearing a proofreading costume.

The second audit found less than the first. That’s the direction the trend should point.

Two disclaimers worth making. I’m not a lawyer and none of this is legal advice. My pages say so themselves, and they say a real attorney reviews things before paying customers come aboard, which is a disclosure worth keeping in plain sight. This post is about accuracy, which sits upstream of legal sufficiency. A lawyer can’t bless a policy that misdescribes the system, so keeping the description true is the part a builder can and should own.

And the stakes scale with attention. A portfolio site with drifted legal copy is embarrassing. A product taking payments with legal copy that misdescribes its data flows is a real liability. I’d rather build the re-check habit now, while the site is small enough that an audit takes an afternoon, than discover the habit’s value later in a conversation I didn’t get to schedule.

Ship the feature, then read your own policy like a stranger would. The words were true when you wrote them. That was then.