Most privacy programs I've seen are a PDF. A well-written one, sometimes — reviewed by counsel, blessed by a committee, version-controlled in a SharePoint folder nobody opens. It describes, in confident future tense, what the company does with personal data. And it is almost entirely disconnected from what the company actually does with personal data.
That gap is the whole problem. Privacy is not a document you renew once a year. It's an operating program you run every day, with the same rigor you'd apply to uptime or change management. The regulation tells you the outcome; nobody hands you the machine that produces it. You have to build and run the machine.
The regulation is a spec, not a system
CCPA and GDPR read like requirements documents, and that's how I treat them. A consumer has the right to know what you hold on them, to get a copy, to delete it, to opt out of the sale or sharing of it. Fine. Now ask the operator's question: when a request comes in, what happens? Who receives it. How do you verify the person is who they claim to be without collecting more sensitive data to do it. Which of your forty systems hold that person's records. How do you pull them, redact what belongs to other people, and return them inside a legal deadline — repeatedly, reliably, when you're getting hundreds of these and not three.
That is a workflow with SLAs, owners, intake, escalation, and an audit trail. It looks far more like an incident-response runbook than like a policy clause. If your answer to a deletion request is a person hand-searching databases under deadline pressure, you don't have a privacy program. You have a privacy intention, and a future incident.
The same logic applies to the data map underneath it. You cannot honor a "right to know" if you don't know yourself. The boring discipline — knowing what personal data you collect, where it lives, who it flows to, and why — is the foundation everything else stands on. It's also the work most often skipped, because it never ships a feature and never closes a deal. It just quietly determines whether any of your privacy claims are true.
Retention is a decision, and silence is a decision
Retention is where good intentions go to rot, literally. Data you keep is data you have to protect, produce, and delete on request. Every record past its useful life is pure liability with no offsetting value — a bigger breach blast radius and a bigger pile to search every time a request lands. Yet the default in almost every system is to keep everything forever, because deletion is work and storage is cheap. Cheap storage is the trap. The storage is cheap; the obligation attached to it is not.
An operating program makes retention an enforced default, not an aspiration. Classes of data get a clock. The clock runs automatically. Deletion is a scheduled job with logging, not a quarterly cleanup somebody volunteers for. When you can show an auditor — or a customer's security team — that data ages out on a defined schedule by default, you've converted a paragraph of policy into a control that actually exists.
DLP is the part that tells you the policy is fiction
Data loss prevention is the most honest tool in the privacy stack, because it watches what people and systems actually do with data rather than what the policy says they should. It's also where most programs lose their nerve, because DLP that's tuned wrong is a firehose of false positives that teams learn to ignore. The instinct is to either block everything (and break the business) or alert on everything (and train everyone to dismiss alerts). Both are failures of operations, not policy.
Run well, DLP is the feedback loop that keeps the rest of the program honest. It tells you personal data is leaving through a channel nobody documented, that a well-meaning analyst exported a customer table to a spreadsheet, that an integration is shipping more fields than its contract allows. None of that shows up in the PDF. All of it shows up in the logs, if you're actually watching them and tuning the rules like the living thing they are.
This is the work every AI privacy claim quietly stands on
Here's the part I most want leaders to internalize. Every confident statement a company makes about AI and privacy — we don't train on your data, we minimize what the model sees, you can have your data removed from the system — is a claim that resolves to ordinary, non-AI privacy plumbing. "We can delete your data from the model's reach" means you have a working deletion workflow and a data map good enough to find every copy. "We don't over-collect for the model" means you have classification and DLP that can actually tell. "We honor opt-outs for automated decisioning" means your consumer-rights program routes that signal to the systems that act on it.
The AI layer is new and gets all the attention. The thing holding it up is the same unglamorous operations work that's been load-bearing for a decade. You cannot bolt a credible AI privacy posture onto a privacy program that's still a document. The AI promises inherit every weakness of the plumbing beneath them — and regulators, auditors, and your customers' security teams will eventually test the plumbing, not the prose.
Serving 1,500-plus financial institutions taught me the unglamorous version of this lesson early: the institutions doing real diligence don't ask to see your privacy policy. They ask you to walk a request through the system, end to end, and watch what happens. That's the right test, and it's the one to apply to yourself first.
So here's the challenge. Pull your own consumer-rights process and time it. File a deletion request against your own production data and see if it completes, cleanly, with an audit trail, inside the legal window. If it does, you have an operating program. If what you find instead is a PDF and a heroic individual, you have your roadmap — and you have it before a regulator or a prospect finds it for you.
