# Stop Selling a Privacy Policy
*Published: 2026-05-18*
*Tags: ai, insights, product-work*
*Source: https://chrislema.com/stop-selling-privacy-policy-ship-privacy-protocol*
---A salesperson sits at her laptop. The pitch is open in a new tab. Deal size: $480K. Prospect: the VP of Operations at a company she's been working for six months to crack. The strategy section names two of her champions internally and the political dynamic she's been managing around their CFO.

She wants help with the pitch. AI is the obvious move. She's used it for a hundred other things.

There's a vendor that makes a product called PitchCoach, a real rules engine built by people who've studied thousands of B2B conversion outcomes. Not a generic chatbot. An actual scoring system that knows what makes a pitch land.

She'd pay for it. She'd pay a lot for it.

But to use it, she has to upload her pitch. The deal size, the prospect's name, the company's strategy, all of that has to land on PitchCoach's server. Even if their privacy policy is perfect, her legal team will not allow this. Her security team will not allow this. Honestly, she won't allow this.

Here's the crazy part. From PitchCoach's side, they have the same problem in reverse. The rules that make their product valuable took years to build. Those rules are the company. If they ship her a copy of the engine to run locally (which sounds like the obvious privacy fix), they've handed her the entire product.

So she sits there with her laptop open. The work doesn't happen.

## The Pattern I Keep Seeing

This scene plays out across different domains, and the structural shape is the same every time.

A contract review service has proprietary heuristics about compliance traps in commercial agreements. The customer has contracts containing trade secrets and named counterparties. Both sides have IP. Neither will share. The product doesn't get built.

A code review service has detection rules accumulated from years of production incidents. The customer's codebase is their core IP. Both sides have IP. Neither will share. The product doesn't get built.

A medical second-opinion service has clinical decision rules tuned on real cases. The patient's records legally can't leave specific systems. Both sides have IP. Neither will share.

A financial analysis service has scoring models. The customer has positions, strategies, and trade history.

A content quality service for a major publication has scoring rubrics. The publication has unpublished editorial content.

Five domains. Same shape. Every time, two parties with real IP. Every time, the conventional privacy story has nothing useful to say because that story was built for a one-sided problem.

When the AI industry talks about privacy, it almost always means *the customer's* privacy. "We don't train on your data." "We encrypt at rest." "We delete after thirty days." That's fine as far as it goes. It just doesn't help with the scene I described. In that scene there are two parties with IP, and either one sharing means losing.

This isn't a niche edge case. It's most of the high-value B2B AI category. The products don't get built. The customers don't get the help. Whole categories sit empty because the structural problem underneath them hasn't been solved.

## Why the Standard Answers Keep Failing

I've watched smart founders try every standard answer. Here's why each one breaks.

*Encryption.* Doesn't help. The vendor still processes plaintext in their own memory. The customer's IP is on someone else's server during processing. The thing the customer is trying to prevent has nothing to do with interception. The vendor receives the plaintext legitimately, in order to process it, and that legitimate exposure is exactly what the customer's security team is worried about.

*Privacy policies and SOC 2.* A privacy policy is a promise. A customer's security team doesn't want promises. They want guarantees that exist independent of vendor goodwill. The policy doesn't stop a breach, a subpoena, a change of ownership, or a future product manager deciding to "improve the service by analyzing usage patterns."

*Self-hosting.* Solves the customer's problem by destroying the vendor's. The rules engine is now inside customer environments where it can be inspected, copied, or reverse engineered. No serious vendor with real IP will offer this.

*Redaction.* Pushes all the work onto the customer. They have to know what to redact, do it consistently, and trust their redaction is complete. The redacted version often loses the signal that made the service useful, since you can't get good coaching on a pitch where you've redacted the prospect.

*Local models.* Same problem as self-hosting. Either it's a thin wrapper around an API (in which case the customer's data is going back anyway), or it's the actual model (in which case the IP is in the customer's hands).

*Differential privacy, homomorphic encryption, trusted enclaves.* Real techniques. Real partial answers. Heavy, slow, expensive, and require both sides to invest in infrastructure that exists today only in niche cases.

What you're left with in practice is this. Enterprise legal teams negotiate for six months. The deal goes through with carve-outs. The customer's security team writes a memo expressing residual concern. And then somewhere in the company, an engineer pastes a sanitized version into ChatGPT anyway because the official tool was too painful to use. The work happens. The privacy story is a polite fiction. The legal team's heartburn never goes away.

## What This Has Cost Us

It's worth naming the cost in concrete terms.

We've lost the entire category of B2B AI products where two parties both have IP. That category is enormous, and the vendors mostly don't exist. The customers don't get the help. The market sits empty.

We've lost months on every deal that does try. Security reviews. DPAs. Custom contractual carve-outs. The cost of selling AI into a regulated industry is now mostly the cost of negotiating around the privacy problem rather than the cost of building or selling the actual product.

We've lost honest user behavior. Knowledge workers who genuinely want help end up either avoiding AI for high-value work or using it furtively against policy. The shadow IT problem in 2026 is mostly an AI problem, and it exists because the official answer has been "trust us" and that answer doesn't survive the conversation with legal.

We've lost the credibility of the privacy story itself. When every privacy promise sounds like "trust us, we don't log it," and the customer has heard ten of those, they stop listening.

This is what's gated behind the unsolved problem. It's a lot.

## The Move

Here is the design move that changes everything downstream. I'm going to spend some words developing it because it matters, and because compressing it into a single sentence is exactly the mistake the industry has been making.

For ten years, the entire privacy conversation has been about *protecting what crosses the wire*. Encrypt it. Anonymize it. Process it in a secure enclave. Delete it after. Promise not to look at it. Every standard answer I just listed is some variation on this theme. The data moves from customer to vendor, and we try to protect it once it's in transit or once it arrives.

That whole frame assumes the data has to make the trip.

But what if it doesn't? What if you start from a different question entirely: *what's the minimum information that needs to cross the wire for the service to do its job?*

Take PitchCoach. To evaluate a pitch, do they need the prospect's name? No. Do they need the deal size? No. Do they need the pitch text itself? Surprisingly, also no. What they need is a *structural description* of the pitch: how long is it, does it have a call to action, what's the opening style, what's the tone register, who's the audience segment, where are the transitions. That's a compact set of counts, booleans, and enumerated categories. It carries enough signal to evaluate. It carries none of the content.

You define a *shape*. The shape goes up to the cloud. The rules engine evaluates against the shape and produces verdicts. But the verdicts are in the rule author's voice, which is the vendor's IP. So before the response comes back, a translation layer rewrites the verdicts as symptom-level coaching. A raw verdict like "rule INTRO_HOOK_STRENGTH below threshold" gets rewritten on the way out as something the customer can actually act on, like "your opening feels generic for this audience." The customer sees coaching they can act on. The rule never leaves the cloud.

The wire contract between the two parties has no field for raw content. Not because anyone promised. Because the schema literally doesn't define a field that could carry it.

That's the move. There's a name for it that helps it stick: *the schema is the contract*. The schema is public. Anyone can read it. The fields are obviously not content. The wire contract is short enough to audit in an afternoon. Privacy is enforced by the structure of what's allowed to cross, not by promises about behavior.

This isn't a cryptographic protocol or a trusted enclave. It's a design discipline that anyone willing to think carefully about their schema can apply, and it's almost embarrassingly simple looking at it now.

I call this *privacy by absence*, because the strongest privacy guarantee is the one where the content was never on the wire to begin with.

[Video: Double Blind IP Protection](https://www.youtube.com/watch?v=ywTlVP86N2I)



## What Becomes Possible

This is the part of the conversation that's been missing, and it's the part that should be exciting.

**Security reviews collapse from months to an afternoon.** Today, a customer's security team spends weeks on a vendor's privacy posture. Under this pattern, the team reads the schema. The schema is one page. It declares every field allowed to cross. Anything not in the schema can't cross. By construction, not by promise. The review is finished in an afternoon, and the answer is auditable forever after.

**The "trust us" frame goes away.** The customer no longer has to trust the vendor's intentions, policies, storage practices, or future behavior under acquisition. They look at the protocol. If the protocol doesn't allow raw content to cross, no amount of bad-faith vendor behavior matters. The content is already absent from the channel. And the vendor benefits too: they're no longer selling a promise that's hard to make credible. They're selling a protocol the customer can verify.

**Whole product categories become buildable.** Contract review. Code review. Medical analysis. Financial scoring. Editorial coaching. The vendor keeps their rules. The customer keeps their content. Both get the value of the collaboration. The B2B AI market expands into domains it's been locked out of, not because something got faster or cheaper, but because something got possible.

**Multi-turn collaboration keeps the same guarantee on every round.** Real consulting work is iterative. Most privacy stories degrade across rounds. What about the cumulative information after five interactions? Under this pattern, every round is a fresh shape going up, a fresh response coming back, no shared state. The conversation can run for fifty rounds and the audit doesn't get harder. It's the same audit, fifty times, all of which pass.

**Compliance becomes architectural rather than contractual.** Today, GDPR, HIPAA, SOX, financial-services regulations are enforced through documentation, audits, and contractual promises. Under this pattern, the shape can't carry PII. The shape can't carry PHI. The shape can't carry trade secrets. The compliance posture is a property of the wire format, which is genuinely a different argument than the one regulators are used to hearing, and a stronger one.

**The pattern composes.** Once you have one shape-based service, you can chain another. A document gets shaped, sent to a quality service, the response feeds into a tone service, that response feeds into an audience-fit service. None of them see the document. All of them produce useful guidance. Multi-vendor collaboration where every vendor protects their IP and every customer protects their content. That's a market structure that didn't exist before.

## What to Do With This

If you build B2B AI products, the shift is concrete. Stop selling a privacy policy and start shipping a privacy protocol. Publish your schema. Let customers read the contract. Move the conversation from "trust us" to "look at this."

That's a different sales motion. A different procurement cycle. A different security review. A different category of product you can credibly ship into regulated industries.

If you're a customer trying to use AI for high-stakes work, the question to start asking vendors is simple: *show me the schema*. If their API has a free-text "context" field or a "raw content" parameter, their privacy posture is exactly whatever they promise it is. No more, no less. If their API takes only counts, enums, and booleans, with a translation layer between their engine and the response, their guarantee exists independent of their behavior. That's worth paying for.

If you're in a regulated industry, this is a structural answer to questions you've been getting structural-sounding answers about for years. The protocol either has a field for the regulated data or it doesn't. That's a question your engineers can answer by reading the API spec. It can be inspected, tested, and re-verified at every release without anyone in legal having to renegotiate a thing.

If you're an engineer building AI agents that need to call specialty services, this is how to wire them up. The local agent shapes the work. The remote service evaluates the shape. The response comes back already laundered. You get the specialty service's expertise without either side losing anything.

The whole conversation about AI privacy has been about protecting what crosses the wire. The reframe is to design what's allowed to cross in the first place, and then notice how many systems could be redesigned around that question, and how many entire product categories have been waiting for someone to redesign them.

The whole industry has been asking those parties to trust each other. The protocol I'm describing makes trust beside the point. The guarantee lives in the wire format, not in anyone's good intentions.
