You Don't Have to Choose Between Using AI and Protecting Client Data

The ban-it-or-leak-it binary is false. One architectural idea kills it.

By John Margerison · Sun, 31 May 2026 · 1022 words

The conversation in most regulated firms goes one of two ways. Either someone in leadership says "we can't use AI, the risk is too high," and the team quietly uses it anyway on personal devices. Or someone says "we're enabling AI," and the compliance officer spends the next six months trying to write a policy that nobody reads.

Both paths share the same hidden assumption: that using AI means sending your client data to someone else's servers. That assumption is wrong. And it's costing firms real productivity while solving a problem that doesn't have to exist.

The false binary looks like this: ban AI and stay safe but fall behind, or allow AI and expose confidential client data. Pick one.

The actual choice is different. You don't have to change whether you use AI. You change what the AI receives.

That shift, from "should we use AI" to "what do we feed it," is where the whole problem dissolves.

Here's the mechanism, plainly.

Sensitive identifiers, client names, account numbers, patient IDs, deal terms, matter references, policy numbers, are detected and replaced with neutral tokens directly in the browser, on the user's own device, before the request travels anywhere. The AI model receives the tokens and the surrounding non-identifying text. It does its work. The response comes back. The original values are restored locally, on the device, so the user sees the real names and numbers in the output.

The model never receives the identifiable content in readable form. Neither does the AI provider's infrastructure.

A concrete example. A lawyer types: "Draft a settlement letter for Sarah Chen regarding the Meridian matter, account reference 7741-B, settlement amount $240,000." What actually leaves the device looks like this: "Draft a settlement letter for [CLIENT_NAME] regarding [MATTER_REF], account reference [ACCOUNT_ID], settlement amount [FINANCIAL_AMOUNT]." The AI drafts a perfectly usable letter. The real names and numbers live only on the user's screen.

This is called tokenisation, or client-side redaction. The key word is client-side. The detection and replacement happen before transmission, not after.

Why does this matter right now?

Courts are clarifying the exposure. In February 2026, Judge Jed Rakoff of the U.S. District Court for the Southern District of New York ruled that documents a defendant created using a commercial AI tool were not protected by attorney-client privilege, in part because the applicable privacy policy stated that inputs could be used to train the model and disclosed to third parties. The court found the user had, in effect, voluntarily disclosed the content to a third party. Separately, in the OpenAI copyright litigation, a federal court in January 2026 affirmed an order requiring OpenAI to produce roughly 20 million ChatGPT conversation logs, the overwhelming majority belonging to ordinary users who were never parties to the case. The pattern is consistent: text you type into a consumer AI tool is not automatically confidential, and it can be produced.

Regulators are watching the same thing. FINRA's 2025 Annual Regulatory Oversight Report flagged third-party AI vendor risk explicitly, encouraging firms to assess whether their supervisory procedures for outsourced AI functions are sufficient under existing rules including SEC Regulation S-P. The exposure that regulators and courts are circling is precisely the identifiable content sitting in a third party's logs. Tokenisation keeps that content out of those logs.

Ask yourself: do you actually know what your team is typing into AI tools today? Do you know which client names, matter details, or patient identifiers have already passed through a third-party server? Most compliance officers, if they're honest, don't.

That's not a failure of policy. It's a failure of architecture.

Now for the honest part, because overclaiming here is its own risk.

Tokenisation materially reduces exposure. It is not a compliance certification, not legal privilege, and not a guarantee of safety. It protects the identifiers that are actually detected and tokenised, so coverage depends on the quality of the detection layer. The surrounding context, the non-identifying text, still reaches the model. A regulated business still needs its own AI policy, a data processing agreement with the AI provider that includes no-training and limited-retention terms, and human review of AI outputs before they go to clients. Tokenisation is a strong technical control, not a substitute for governance.

What it does do is solve the hardest part of the problem: it keeps your most sensitive identifiers, the names, numbers, and references that make data identifiable, off third-party servers. That's the exposure that matters most. That's what courts and regulators are focused on.

The productivity case is real. A compliance officer who can use AI to draft regulatory correspondence, summarise examination findings, or review policy language is materially more effective than one who can't. The same is true for a healthcare administrator, a financial adviser, a government contractor reviewing procurement documents. The productivity gap between firms that use AI well and firms that don't is already visible. It will widen.

The question isn't whether to use AI. The question is whether you've built the architecture to use it safely.

Here's what a private-AI setup for a regulated business should include:

• Client-side redaction/tokenisation: sensitive identifiers are detected and replaced with tokens on the user's device before any request is transmitted. The AI model never receives the real values.
• Bring-your-own-key: prompts run under your own provider contract and API key, not a shared consumer account, so your retention terms, data processing agreement, and no-training clauses actually apply.
• Local rehydration: tokens are mapped back to real values on the user's device after the response returns, so the output is fully usable without the identifiable data ever leaving the device in readable form.
• Audit trail plus contractual no-training/limited-retention: every tokenised prompt is logged locally for compliance review, and your provider contract explicitly prohibits training on your inputs and limits retention to the minimum necessary.

That's the architecture. It doesn't require banning AI. It doesn't require trusting that your team won't use it. It requires building the right layer between your people and the model.

The binary was always false. The fix was always about what you feed the AI, not whether you feed it at all.