An hour before a renewal call, someone asks for the supplier contract to be summarised — forty-odd pages, the pricing schedule buried near the back. The account team wants three sentences, not an afternoon of reading. The quickest way anyone in finance knows to get that is to paste the whole document into a public chatbot, the free one already open in another tab. It reads the contract in about the time it takes to make coffee and hands back a clean summary, pricing clauses included. Nobody told this person not to do it, because nobody had ever told them what that chatbot is and is not allowed to see. The contract carries a customer's own pricing terms. That text now sits on a server the company does not run, and there is no way to ask for it back.
Why we build it this way
The instinct after something like this surfaces is to write a policy: handle sensitive data with care. That sentence has never stopped anyone, because it does not answer the only question a person actually has, which is whether this file, in this tool, right now, is allowed. A policy speaks in principle, written months before the moment it is meant to govern. The moment needs an answer in the ten seconds before the paste.
The other instinct is to block public chatbots outright. That fails for a different reason. The contract still needs summarising before the call, so if there is no approved way to do it quickly, someone finds an unapproved one, on a personal device, off any list the company keeps. A rule that is slower than going around it gets gone around, and the company loses the one thing the ban was supposed to buy: knowing where its data went.
So the answer cannot be a sentence of guidance, and it cannot be a wall either. It has to be a short, explicit list: which classes of data exist, and which tools are cleared to see each class. Customer pricing is a class. A public chatbot is a tool. The list says, before anyone has to guess, whether the two may meet — and which tool is cleared instead, so the three-sentence summary still gets written, just somewhere the company can see it.
A rule nobody can look up in the ten seconds before they need it is not a rule. It is a sentence someone half-remembers having read once.
How it works, roughly
The list we build with a customer is short on purpose — a handful of data classes, not a taxonomy:
- Pricing and commercial terms belonging to a customer or supplier
- Designs, drawings or specifications not yet released
- Personal records — employee or candidate information
- Everything else, which is most of what people actually want summarised
Each class is paired with the tools cleared to see it. When a request matches, it goes through without anyone stopping to ask — most paperwork is not sensitive, and treating it as if it were is how a rule earns a reputation for being slow. When a request does not match, the system says why, in plain words, and points at the tool that is cleared, rather than just failing and leaving the person to work around it. The cases in between — is this clause actually pricing, or boilerplate — go to a person who owns that call, because it is a judgment, not a lookup.
A year in, the question "can I use this for that" has an answer before the paste happens, not an argument after someone finds out it already did.
The record of which class a document belongs to, and which tools may see it, stays inside your own building — not in whoever happened to remember the rule that day.
See how that rule gets written →