Pasting Internal Text into ChatGPT Is a Data Path, Not a Productivity Hack
Pasting internal text into a public chatbot is a transfer to a third party. Treat that path in policy, contracts and logs — including the option to use no model at all.
Someone on the team pastes a contract, a ticket dump, a payroll extract or a customer email thread into ChatGPT and gets a useful rewrite in thirty seconds. The work looks done. The data path has only just started.
Company data in ChatGPT is not a productivity feature with a privacy footnote. It is a transfer: text left your tenant, arrived at a vendor, and will live in whatever retention, logging, training and support processes that product actually runs. If you did that from a personal browser session, you may not even be the customer on the contract. That is the whole issue. The rest of this article is the mechanics, the policy shape, and the point at which a private model — or no model — is the honest answer.
I design private AI on infrastructure the company controls. I also write PHP and Go backends. Neither job produces a clone of a consumer chatbot that is free, local, and as good. If that is the requirement, stop. If the requirement is “this class of text must not go to an unmanaged public chatbot”, keep reading.
Pasting into a public chatbot is a transfer
Treat the paste buffer as an integration.
Whatever is in the prompt is the payload. Whatever is in the uploaded file is the payload. Conversation history that the UI keeps sending back as context is also the payload. If a browser plugin or a “helpful” desktop wrapper is involved, assume it can see the same text. None of this is theoretical. It is how HTTP APIs work.
What actually leaves, in the ordinary case:
- the full prompt, including hidden system text the UI added;
- file contents you attached, not just the filename;
- prior turns in the same chat, which often contain the sensitive bit from ten minutes ago;
- account identifiers, IP addresses, timestamps, and whatever the vendor stores for abuse review;
- tool or browsing output if the product called other services on your behalf.
What does not automatically stay behind: your office network, your GDPR posture, your NDA with a customer, or the fact that the employee “only used it for grammar”. Grammar is not a data classification. The document is.
Consumer ChatGPT on chatgpt.com, a random “free GPT” site, and an employee’s phone app are the same class of path unless you have a written processing agreement with that vendor for that product. Marketing copy about “we do not train on your data” is not a substitute for knowing which legal entity you contracted, which product SKU, and which retention toggle is actually on.
If you want a longer split between sending text to a vendor and running a model yourself, that comparison is in local LLM vs cloud AI. This article is narrower: the paste into a public chatbot, and the shadow path that appears when you pretend people will not do it.
Consumer ChatGPT is not the processor you think you hired
Under GDPR, a processor is someone you have engaged to process personal data on your documented instructions, with a contract that actually says so. A Data Processing Agreement (DPA) is that contract. It is not a vibe. It is not a checkbox in a consumer signup flow that an employee clicked at lunch.
A personal ChatGPT account used on company text usually fails that test in several places at once:
- the company is not the customer;
- the employee is not authorised to appoint a processor;
- there is no instruction set, no sub-processor list you accepted, no deletion process you can operate, no audit trail you control;
- retention and training settings follow the consumer product, not your record of processing.
ChatGPT Team, Enterprise, or an API account under a company contract is a different object. You can have a DPA, a named subprocessors list, retention controls, and a prohibition on using prompts to train the public model. That still makes the vendor a processor. The text still leaves. Abuse monitoring, support access, backups on their side, and jurisdiction still exist. A DPA is permission to use a processor, not a claim that the data never moved.
Be exact in the policy language:
- Forbidden: consumer chatbots, unknown wrappers, personal API keys, browser extensions that ship prompts off-box.
- Allowed under contract: named vendor, named product, named account owned by the company, DPA in place, retention configured, logging reviewed.
- Must stay inside: named classes of data (HR, health, payment, pre-release M&A, customer secrets your MSA forbids sharing). For those, a vendor AI API is the wrong default even with a DPA, unless legal has explicitly accepted that processor for that class.
I am an engineer, not your DPO. The engineering job is to make the default path match the list above, not to argue with legal on LinkedIn.
What logs keep, including yours
Leaks are not only “the model trained on our files”. That is the story people tell because it sounds cinematic. The boring stores are worse, because they are complete and searchable.
On the vendor side, expect some combination of request logs, conversation stores, abuse queues, and backups. You do not operate those systems. You cannot grep them. You cannot prove a negative. If a support engineer at the vendor can see a prompt, that is a disclosure path whether or not the weights ever change.
On your side, the same mistake gets rebuilt in house:
- a reverse proxy that logs POST bodies;
- an “AI gateway” that writes full prompts to stdout “for debugging”;
- a helpdesk macro that dumps the model reply, which still contains the customer’s address, into Slack;
- laptop disk encryption that does not help when the paste already went out on HTTPS;
- chat UI history on a shared workstation.
If you wrap an official API, design the logs first. Log request id, user id, model name, token counts, latency, and a hash of the prompt if you must correlate. Do not log the prompt. Do not log the completion if the completion restates the input. Redaction after the fact is not a logging strategy; it is an admission.
The same rule applies to a local model. A GPU under your desk that writes every prompt into Elasticsearch is not a privacy win. It is a new archive of the most sensitive text you have, with worse access control than the HR drive. Private inference only helps if the prompt path, the disk, and the backup policy are designed. That is ordinary backend work. Treat the model as another service with a network boundary, an identity, and an owner, which is the same stance as in local LLMs for business.
Shadow AI is a policy failure with a UI
Shadow AI is employees using public models because the official path is slow, forbidden without an alternative, or embarrassing to ask for. It shows up as personal ChatGPT tabs, WhatsApp bots, and “I uploaded the PDF to a site that summarises PDFs”.
A ban without a tool does not produce compliance. It produces quiet pasting and a surprise during discovery. DLP on the browser can catch some of it. It will not catch the phone. Culture catches more than DLP, and culture needs a sentence people can repeat: this class of text stays here; that class may go to vendor X under these settings; if you are unsure, do not paste.
You will not eliminate shadow AI with a poster. You reduce it by naming allowed work and providing a path that is not humiliating:
- a contracted API for text that may leave;
- an internal search or template for text that must not;
- a local or private model for a narrow workflow that you actually operate;
- a human process when the model would be theatre.
If the work is “search our own PDFs”, the answer is not a public chatbot with the PDF attached. It is retrieval on infrastructure you control, as in private AI document search. If the work is “make this marketing paragraph less stiff”, a vendor API under a DPA is often fine. If the work is “summarise this employee’s medical correspondence”, the answer is often no model.
Shadow AI is also a records problem. Once text is in a consumer account, you do not have a retention schedule. You have a hope. Legal hold, DSARs, and customer audits do not run on hope.
Enterprise API, local inference, or no model
Three options, not two.
Official API with enterprise terms. Use this when the data class may be processed by that vendor, quality matters, load is bursty, and you do not want to run GPUs. Put the company on the contract. Turn off training. Set retention. Put an application in front so people are not pasting into a consumer site. Log metadata, not bodies. This is still cloud AI. It is the grown-up version of the thing people are already doing in secret.
Local or private inference. Use this when the data class must not go to an AI vendor as a processor, volume is high enough to justify operations, and a smaller model plus retrieval or a rigid template is good enough for a human to review. You still have disks, admins, and backups. You do not get frontier quality for free. You get a path you can point at on a whiteboard. Hardware and operations are covered in the local versus cloud piece and in the on-premise deployment notes; do not skip those and buy a GPU because a blog said “air gap”.
No model. Use this when the cost of a wrong answer is high, the text is rare, or the job is already a search problem, a form, or a checklist. Not every request for “AI” survives contact with a workflow. A macros library, a better full-text index, and a junior person with a style guide will beat a hallucinated summary of a contract. “No” is an architecture.
Decision order that does not start with a vendor logo:
- Name the workflow and the data class.
- Ask whether a model is allowed to see it at all.
- If yes, ask whether a named vendor may process it under a DPA.
- If no vendor, ask whether a local model plus a human reviewer is good enough.
- If not good enough, do the work without a model, or change the workflow so the sensitive bit never enters the prompt (redact, aggregate, sample).
- Write the path down. If it is not written, it will be ChatGPT in a personal tab.
Hybrid designs — some prompts inside, some to a vendor — are common and honest. They are also easy to fake: a gateway that “redacts PII” with a regex and then ships the rest is not a classification programme. If you need that split designed as a system, it sits on the private AI overview. A Private AI Readiness Audit from €1,500 is the fixed-scope version: one workflow, a written public / private / hybrid recommendation, and permission to conclude that you should not deploy a model. Single-workflow pilots are €300/day. Implementation after that stays at €300/day. None of those numbers buy you ChatGPT-at-home.
What to do this week
If you only have a week of attention, do not spend it comparing model names.
Inventory the path that already exists. Ask, in writing, where people currently paste internal text. You want honesty, not a witch hunt. Personal ChatGPT, Notion AI, Grammarly, meeting bots, “PDF summariser” sites, and unofficial Slack bots all count.
Classify three piles. Must not leave. May leave to a named processor. Public anyway. If everything is “must not leave”, you are not classifying; you are stalling. If nothing is “must not leave”, you are not a regulated business or you have not thought yet.
Kill the consumer path for company work. Company-owned accounts or nothing. Block the obvious consumer domains on corp browsers if you can do it without theatre. State that personal accounts are not a processor. Mean it.
Put a front door on anything allowed. An internal form that calls an official API beats a paste into a website. You then own authentication, audit ids, and the ability to switch the backend later.
Do not log bodies. Change it now if you already do. This includes “temporary” debug flags on a gateway.
Pick one real workflow if you still think you need a model. Not “a company ChatGPT”. A ticket summary, a document question with citations, a transcript. Run it on real files. Compare vendor API, local, and no model on the same samples. The business decision framework is the order of operations before anyone orders hardware.
Name an owner. Policy without an owner is a PDF. A model without an owner is a demo that will rot and then leak through its logs.
Company data should stay out of ChatGPT when you have not contracted ChatGPT, when the data class cannot go to that vendor, or when you cannot explain the logs. It can go to a contracted API when legal accepts that processor and engineering has built a door you control. It can go to a local model when the workflow is narrow and someone will operate the box. It can go to neither, which is still a decision.
The failure mode I see is not “we used AI”. It is “we used an unmanaged consumer chatbot as the unofficial integration bus for the most sensitive text we have, and we called it productivity”. That is a data path. Close it, or replace it with one you can describe.