I read the forms at the doctor’s office. All of them. The HIPAA notice, the financial responsibility page, the one about where my records go after I leave. By page three there’s a line behind me and the receptionist has stopped making eye contact. I sign most of them anyway. But I know what I signed, which puts me in a club so small it may just be me and a handful of privacy lawyers who can’t turn it off either.
I come by this honestly. For a long stretch of my career, those forms were my job.
Consent happens at the front desk
My work at the New York eHealth Collaborative was getting medical records to the people who needed them, and keeping them from the people who didn’t. The consent form was the gate between those two.
And all of it funneled down to a clipboard at a front desk, handed across by a person who was also checking insurance cards and answering two phones. That’s where consent happens. Not in the document. In the thirty seconds after a patient looks up and asks, wait, what is this one?
So at my own doctor’s visits, I became the patient who asked the front desk what the form meant, and then, when they weren’t sure, annoyingly explained it to them: here’s what this one does, here’s what happens if someone says no, here’s the one-sentence version for the next person who asks. The staff wanted to get it right, genuinely. The form gave them nothing to work with. It was written to satisfy auditors, and it was being asked to do a job it was never designed to do: explain itself to a human being in a hurry.
Years later, at Particle Health, we ran an experiment to see whether the new information-blocking rules meant people could finally pull their own medical records. The first thing we did, before a single request went out, was write up exactly what employees would be signing up for, in plain language, optional, with notarized authorizations because that was the highest bar for proving identity. The experiment itself was a bust. One employee got one file from one provider. But nobody walked away confused about what they’d agreed to. You can’t always control whether the system works. You can control whether people understood the form.
Why the forms read like that
It’s not malicious. It’s two forces.
The first is audience. A privacy policy is written for regulators, for opposing counsel in a lawsuit that hasn’t happened yet, for the diligence team at whatever company might buy this one someday. You, the person the policy is about, come in around fourth. The document isn’t trying to inform you. It’s trying to survive everyone else.
The second is optionality. When a policy says your data may be used to “improve our services,” that isn’t a lawyer failing to be specific. That’s a lawyer succeeding at not being specific. Every fuzzy verb is an option the company keeps. Nobody wants to have written the sentence that ruled out a business model three years too early, so the sentences stretch until they can hold anything.
I’ve spent the past few weeks reading the privacy policies and terms of the major AI products, because I’m building one and wanted to know what everyone else’s answers were. The way to do this without losing your mind is to stop reading and start searching. Search the verbs: train, improve, develop, evaluate, personalize. Each is a separate right, and “we don’t train on your data” leaves “improve” fully intact. Search “de-identified”: one policy I read says de-identified data isn’t subject to the privacy policy at all, which means every right you have stops at that word while the data keeps going. Search “feedback”: one product pulls your whole conversation into training when you click thumbs-down, opted out or not. Search “delete”: deleting a chat and deleting what the system remembers from the chat are two different operations, and only one of them is on the button. Twenty minutes, no law degree.
De-identification has a specific legal meaning, and it was built for a different kind of data. HIPAA’s Safe Harbor method says: strip 18 categories of identifiers (name, address, dates, Social Security number) and what’s left is no longer personal. The Expert Determination method says: have a statistician certify that the re-identification risk is very small. California’s CCPA uses nearly the same definition and the same exemption: once data is called de-identified, your rights to delete it or opt out stop applying. And the track record for that word is bad even on the data it was designed for. The New York Times re-identified people from a supposedly anonymous set of location records. Researchers matched Netflix’s “anonymous” movie ratings against public reviews and worked out who the raters were. That was structured, tabular data — the identifying fields were columns, and someone had dropped them — and it fell anyway. Conversational data doesn’t even have columns. A back-and-forth with an AI product can contain your writing style, your workplace, the names of your children, a rare medical condition mentioned once in passing, the combination of your job title and your city and the project you described. None of those are on the list of eighteen. The identifying information is the conversation itself, not a field you can strip out.
What ours will say
We’re writing THE WHEEL’s privacy policy and terms of service right now, with the team at Soxton, who have been great about working through it with me. The version I want is the unusual version, and it takes more lawyering, not less.
Standard policy language keeps a company’s options open. Broad verbs, general categories, room for whatever the business does next. Ours needs to do the opposite: describe what the product actually does, and cross out the rest. Before we started, I audited our own codebase to trace what data flows where, so the policy can be written against what the code does instead of what a company like ours might someday want to do.
So ours will say we hash IP addresses in server logs, and that’s what happens to them. It will say telemetry can’t contain user content, and describe the mechanism: a denylist of forbidden fields that throws an error before anything containing them gets written. It will say we use invite codes, because we do.
It will say that improvement is opt-in, twice over: helping the system get better and contributing to model training are two different choices, made separately, and you can use the product without making either one. If you opt into system improvements, you preview a synthetic version of the pattern, approve it or edit it or decline it, and your original content never leaves your record. And it will say the hard limit out loud: once an approved contribution has taught the system something, that effect can’t be pulled back out.
When the product connects to your Google Drive, your Slack, your GitHub, the policy will describe how consent works for that too. You authorize each connector once, through the provider’s own OAuth screen, and that standing consent covers ongoing syncs until you revoke it. Revoking a connector revokes the consent immediately.
And remember the word that ends your rights in other policies, the one where everything you were promised stops applying? Ours will close that loophole instead of using it: no de-identified datasets built from your content, nothing shared under that label.
My favorite part so far is the acquisition clause. Standard language says a company may share personal information with prospective buyers. Ours will say that a buyer inherits your content the way we hold it: encrypted, not readable without your participation, and covered by the same promises. That paragraph is only writable because the architecture earns it. No template will ever produce it, because it only exists if you built it.
The difference isn’t generosity. It’s specificity. A privacy promise is only as strong as it is specific: where the architecture makes something impossible, the policy should say impossible, and where we’ve built a consent gate, the policy should describe the gate. Broad language leaves room for readings that don’t match the product. Specific language is checkable, by anyone, against the thing itself.
I do this in meetings too
I’ve been doing some work in person lately with Samm Sacks and Jocelyn Aframe, and when the phones came out on the table to record our meetings, I did my thing there too. Asked which app. Pulled up its privacy policy and its terms. Read them before we went on. A recorder on the table catches everyone in the room, and its terms, not our intentions, decide where that audio goes, whether a transcript lives on some server, and what it gets used for.
Nobody blinked. Samm has spent over a decade on data governance. But even in that room, checking the recorder’s policy felt like an event, when it should be about as remarkable as asking whether something’s off the record.
The front desk test
I’m not arguing for a world where everyone reads the way I do. The searching and the redlining are survival skills for a bad arrangement. I wrote in Privacy Is Not Protection that we built an entire infrastructure around protecting data and almost none around the owner deciding what happens to it. An unreadable policy is what that looks like up close: a document that manages the company’s risk, handed to you as if it managed yours.
The standard I’m holding our documents to is the one from the front desk. If the person handing you the form can’t explain it in thirty seconds, the form fails. Not the person. The form. Ours are being written, and rewritten, and argued over with very patient lawyers, until they pass.
And the next time someone hands you a clipboard, or you’re one checkbox away from a new product: read the terms. Ask what they mean. Be nice, it’s not the receptionist’s fault. But if nobody in the building can tell you what you’re signing, that’s your answer.