Is it safe to put your SOPs into ChatGPT?
Usually not, and the reason is rarely the one people argue about. The blocker is almost never that a vendor is untrustworthy. It is that a plant's documents are frequently bound by terms the plant did not write, and those terms do not care how good the vendor's security is.
This question arrives in a specific way. Someone in maintenance or quality tries a hosted assistant on a real problem, it works, and they tell people. A week later the same conversation is happening with IT or legal in the room, and it is a different conversation.
What follows is what we have found useful for having that conversation properly, rather than either waving it through or refusing on instinct.
Four things can happen to an uploaded document
People collapse all of this into "do they train on it", because that is the one a vendor can promise away most cleanly. It is the least important of the four.
1. Training
Whether the text is used to improve a model. Consumer tiers and business tiers of the same product routinely differ here, and the difference is not visible in the interface. Two people at the same company, using what looks like the same tool, can be under different terms because one of them pays personally.
2. Retention
How long a copy exists after the conversation ends. Deleting a chat and deleting a document are not the same operation, and abuse-monitoring retention typically continues after both.
3. Jurisdiction
Where that copy physically sits, and therefore whose courts and agencies can compel it. For a supplier holding drawings under a customer agreement that names permitted geographies, this is the clause that decides the question, and it is decided before anyone evaluates the product.
4. Subprocessing
Which other companies touch the data on the way. Every major assistant has a subprocessor list. It is a real list of real companies, it changes, and your obligations flow down to all of them.
A vendor can be entirely honest in saying it does not train on your documents while the other three still apply in full. That statement is often read as answering the whole question. It answers a quarter of it.
The question that actually decides it
Not "is this vendor secure". Assume they are, and better at it than you are. The question is:
What are we contractually obliged to do with this document, and does uploading it break that?
For a lot of manufacturers the answer is already written down, in agreements nobody re-reads until something like this comes up:
- Export-controlled technical data. ITAR and EAR name who may access technical data and where. A US-person restriction is not satisfied by a vendor's assurance about their staff, and "we did not know it was controlled" has never been a defence.
- Customer confidentiality clauses. Automotive and aerospace customers commonly restrict where their drawings may be processed and by whom. The restriction was accepted when the contract was signed, usually by someone who is not in this meeting.
- Regulated process records. Medical device and pharmaceutical documentation sits under quality systems that require controlled copies. An uncontrolled copy in a chat history is a finding waiting for an audit.
If none of these apply to your documents, a business tier of a hosted assistant may be a perfectly reasonable answer, and you should take it. A lot of plants are in exactly that position and talk themselves out of a useful tool for no reason. Being clear about the distinction is the point of this piece, not steering you to one conclusion.
Where the technical argument does bite
Two situations are not about contracts at all.
The network has no route out. OT networks running production equipment are commonly segmented from IT and from the internet, following a Purdue-model separation or similar. That is not a policy somebody can relax for a pilot. A tool that needs an outbound API call cannot be deployed where the work happens, whatever the terms say.
Someone will paste something eventually. This is the one that is hard to say out loud. If the tool is available and useful, the controlled document gets pasted in at some point, by someone with no visibility of the clause. Policies that depend on every person remembering a restriction under time pressure at three in the morning do not hold. The only control that holds is one where the wrong thing is not possible rather than not permitted.
What "keeping it inside" actually requires
"Run it locally" sounds like a deployment choice. It is an architectural one, and it is worth being honest about the cost.
The largest models are not available to run on your hardware. What you can run on a single unit is a few billion parameters, which is materially less capable at open-ended reasoning than a hosted frontier model. Anyone telling you otherwise is selling something.
What closes most of that gap for this particular job is that answering questions from documents is not mostly a reasoning task. It is a retrieval task with a short writing task at the end. A smaller model that is made to quote its source, and to refuse when the source does not exist, is more useful for a torque specification than a larger one answering from memory. We wrote about how that is enforced in stopping an AI inventing torque specs, and about the hardware it takes in the measured numbers.
The honest summary: you give up capability at the top end, and you get back a boundary that does not depend on anyone's behaviour.
A short version for the meeting
- Establish what the documents are bound by, before evaluating any product. This is a contracts question and it is usually already answered.
- If nothing binds them, use a business tier of a hosted assistant and move on. It will be cheaper and more capable.
- If something binds them, or the network has no route out, the only options are on-premise or not doing it.
- Do not rely on people remembering which documents are which.
Most of the plants we talk to arrive at step three having already spent a month at step two, because nobody asked the first question first.