Can You Safely Use ChatGPT or Claude on Client Files?
Banning ChatGPT doesn't work — professionals use it anyway. Here's what a properly engineered redaction layer actually requires, and why it isn't a checkbox feature.
Every practice we talk to has the same quiet reality: someone on the team is already using ChatGPT or Claude, officially sanctioned or not, because the productivity gain is real — faster first drafts, faster summarization, faster research. Telling people to stop hasn't worked anywhere it's been tried. It just pushes the behavior underground, off any system anyone can audit. The more useful question isn't "how do we ban this" — it's "what would it actually take to do it safely."
Why "just don't paste names" isn't a policy
The instinctive fix — tell staff to manually strip identifying details before pasting into a chat window — fails for the same reason manual compliance usually fails: it depends on a person remembering to do it correctly, every time, under deadline pressure, across every document type they touch. A rushed edit misses a name in paragraph six, a case number in a footer, a date of birth buried in an intake form. There's no audit trail showing what was or wasn't caught, and no way to prove after the fact what actually left the building.
What a real redaction layer looks like
Done properly, this isn't a manual step you hope people remember — it's an automated pipeline:
- Detection — an entity-recognition system finds names, case numbers, medical record numbers, dates of birth, and whatever else is defined as sensitive for that practice, and replaces each with a placeholder token.
- Consistency — the same entity gets the same token everywhere it appears, so a 40-page contract stays coherent after redaction instead of turning into a jumble of mismatched placeholders.
- The mapping never leaves — the token-to-real-value map is the only thing that can re-identify the data, so it's stored separately, encrypted, on infrastructure that never touches the external AI call.
- Re-hydration — once the external model responds, the tokens are swapped back for real values before a human ever sees the output.
- A record of what happened — every redaction and every outbound call gets logged, so there's an actual answer to "what left this building, when, and in what form" — not a best guess.
What it doesn't solve on its own
Two things worth being honest about. First, redacting personal identifiers protects people, not necessarily content — a contract's real sensitivity is often the deal terms, not anyone's name, so what gets redacted has to be defined around what's actually confidential for that document type, not just names and dates. Second, keeping the re-identification key on Canadian infrastructure meaningfully reduces exposure, but it doesn't automatically settle every legal question a given matter might raise. Whether this approach is right for a specific case is a conversation with your own counsel — not something software can certify on its own.
Built when it's actually needed
This isn't something we bolt onto every deployment by default. It's the kind of thing that comes out of an actual conversation about what a practice needs. If your workflow genuinely benefits from occasionally using a model like Claude or GPT-4 on top of your own private infrastructure, we'll scope a redaction layer built around your specific document types and risk tolerance — not a generic toggle everyone gets whether they asked for it or not. If it's not a fit for how your practice actually works, we won't build it.