Turning off training does not protect your data

A setting that several engineers switched off in the spring was reported back on by late summer, without any action on their side. That is the substance of the recurring “Tell HN” complaints about OpenAI’s “allow training” control: people opt out, and after a product update, a new session, or a quiet backend change, the toggle is enabled again. If you are running anything real on top of these models, treat that behavior as the default assumption, not the anomaly. A UI checkbox is not a data governance control, and it was never designed to be one.

The practical answer is short. Do not let a consumer-facing setting stand between your company’s data and someone else’s training corpus. If data sensitivity matters, you move the workload onto a surface where data handling is defined by contract and enforced by the API tier, not by a toggle in an account panel. That means the API with a business agreement, an enterprise plan with a signed data processing addendum, or a zero-retention arrangement where OpenAI has committed in writing that inputs and outputs are neither stored beyond a short abuse-monitoring window nor used for training. The toggle is a preference. A contract is an obligation. Only one of those survives a product update.

So the real issue is not “OpenAI is malicious” or “the setting is broken.” The issue is architectural. Teams routed sensitive workflows through a control surface that carries no guarantee, then treated the absence of a guarantee as if it were one. The fix is not to keep re-checking the box or to file another complaint. The fix is to stop depending on the box at all, and to design the data path so that training exposure is impossible by construction rather than disabled by preference.

Underneath the complaint are two completely different systems wearing the same brand. ChatGPT the consumer and team product has one set of data behaviors, defaults, and controls. The API and enterprise platforms have another. On the consumer and team side, “improve the model for everyone” is the historical default posture, and the opt-out lives in a settings menu that is subject to the same forces every settings menu is subject to: feature-flag rollouts, default resets on major releases, account-level versus workspace-level scoping, and the gap between a session preference and a persisted account attribute. When any of those shift, a value you set months ago can be recomputed to its default, and nobody sends you a changelog for your own checkbox.

The data path is what actually matters, and it is worth tracing. When a prompt goes to a training-eligible surface, the text can be retained, sampled, reviewed, and folded into future training and evaluation sets. “Do not train” is one flag on that path; it is not the same as “do not retain” and not the same as “do not have a human read this during abuse review.” Those are separate controls with separate lifespans, and they are enforced at different layers. A single toggle in a settings page is a thin abstraction sitting on top of several independent backend decisions, which is exactly why it is fragile. The abstraction can silently fall out of sync with the systems it claims to control.

This is also why the re-enabling looks inconsistent rather than deliberate. From the outside it reads as bad faith. From a systems view it reads like state that is not authoritative: a preference stored in a place that gets overwritten, scoped to an object that gets replaced, or represented by a default that a new code path re-applies. None of that requires intent. It only requires that the setting was never the source of truth for how the data is handled. The account panel is showing you a value it does not fully own, and when ownership is unclear, the value drifts. For a personal account that is an annoyance. For a company piping customer records, source code, or contract text through the same surface, it is an uncontrolled data-exfiltration path that resets itself.

The first mistake is reading the toggle as a contract. A checkbox in a product UI is a stated preference with no enforced lifetime and no notification when it changes. People saw the word “training,” flipped it off, and mentally filed the risk as closed. But a preference has no obligation attached, no audit trail you control, and no commitment about what happens on the next release. Compliance and security are built on enforceable commitments, logging, and defined retention. A setting that can silently revert satisfies none of those, which means it was never evidence of anything to an auditor, a customer, or a regulator, regardless of how it was positioned in the interface.

The second mistake is collapsing ChatGPT and the API into one thing because they share a logo. Engineers read that API inputs are excluded from training by default, then assume their team’s ChatGPT usage inherits the same guarantee. It does not. Different products, different defaults, different contractual terms, different enforcement. The moment your workflow runs through the consumer surface, you are on the consumer data posture no matter what the API documentation says. Half the panic in these threads comes from people discovering, after the fact, that the protection they were counting on lived on a product they were not actually using for that workload.

The third mistake is treating “training” as the whole of the risk while ignoring retention and human review, and treating an opt-out as a permanent state rather than a value that must be continuously verified. “Not used for training” still allows storage, and stored data can be breached, subpoenaed, or sampled for abuse monitoring where a human may read it. A team can be fully opted out of training and still have sensitive prompts sitting in retention. And because the setting can revert, “I turned it off once” is not a control; it is a snapshot with no guarantee about the next frame. Any posture that depends on a human remembering to re-check a box after every product update is not a control at all. It is a hope with a UI.

The working pattern starts by moving the decision out of the account panel and into the network path. You put a gateway between your applications and any model provider, a thin proxy that every prompt and every completion flows through, and you make that gateway the single place where data policy is decided and enforced. Nothing in your stack talks to OpenAI directly. The application calls your gateway, the gateway decides which endpoint is allowed to see the payload, and the provider’s own settings stop mattering because you never depend on them. A toggle that reverts on the next release cannot hurt you if no production path was ever routed through the surface that toggle governs.

Inside that gateway, classification comes before routing. Every request gets tagged before it leaves your perimeter: public, internal, or regulated. Public and internal traffic can go to a standard API endpoint. Regulated traffic, meaning customer records, source code, contracts, health or payment data, is only ever allowed to reach an endpoint backed by a signed data processing addendum and a written zero-retention commitment. The routing table is code, it is reviewed like code, and it fails closed. If the classifier is uncertain, the request does not get the benefit of the doubt. It is blocked, downgraded to a redacted form, or sent to the most restrictive endpoint available. You are replacing a human remembering to check a box with a deterministic rule that applies on every call, which is the whole point of putting structure around a probabilistic system.

Verification then shifts from the UI to artifacts you actually own. You do not confirm your posture by opening a settings page, because that page shows a value it does not fully control. You confirm it three ways: the contract on file that defines retention and training exclusion, the endpoint identifier in your routing config that maps to that contract, and the request log your gateway writes for every call. That log records what was sent, how it was classified, which endpoint received it, and whether redaction ran. When an auditor, a customer, or a regulator asks how you prevent training exposure, you hand them a retention clause and a logged data path, not a screenshot of a checkbox. A setting that can silently flip is not evidence of anything. A contract plus an enforced route plus an immutable log is.

The last piece is egress control, because a gateway only works if it is the only way out. You block outbound traffic to model providers at the network layer so that nothing can reach OpenAI except through the proxy. Without that, an engineer pastes a production incident into consumer ChatGPT from a browser, and your architecture is bypassed by a copy and paste. The control is not only the routing logic. It is the routing logic combined with the fact that there is no other door. That is what ‘impossible by construction’ means in practice: not that the risk is discouraged, but that the sensitive path physically cannot reach a training-eligible surface.

Make this concrete with a team that actually exists in some form at most mid-size SaaS companies. A support engineering group was using ChatGPT Team for two things: summarizing inbound tickets, which routinely contain customer names, account identifiers, and occasional payment details, and debugging production incidents by pasting stack traces, logs, and chunks of proprietary source into the chat. Both workloads ran through the consumer surface. The team had opted out of training in the spring, assumed the matter was closed, and discovered in late summer, during a SOC 2 review, that the toggle had quietly re-enabled and that they had no log of what had been sent in the interim. There was no breach notice to point to and no record to reconstruct exposure from. The gap was the finding.

The redesign did not involve a new model or a better prompt. It involved a gateway and a routing table. Support ticket summarization kept running, but ticket text now passed through a redaction step that stripped payment identifiers and replaced customer names with stable tokens before anything left the perimeter, then went to a standard API endpoint. The incident-debugging workflow, which handled source code and raw logs, was classified as regulated and routed exclusively to a zero-retention endpoint under the company’s business agreement. Roughly eighty percent of daily volume was non-sensitive summarization that went to the cheaper standard tier, and the remaining twenty percent carrying source and customer data went to the contracted zero-retention path. Browser access to consumer ChatGPT from corporate devices was blocked at the firewall, closing the copy-and-paste bypass.

The outcome was not just compliance theater. The next audit was answered with a retention clause, a routing config, and a request log showing classification and destination for every call, which turned a multi-week scramble into a single afternoon of evidence-gathering. Cost dropped because the majority of traffic stopped defaulting to the most expensive path. And the original complaint, the toggle re-enabling itself, became a non-event. It still flips. Nobody checks it anymore, because no production data depends on its state. The setting was demoted from a control to a piece of trivia.

The thread on Hacker News reads like a story about OpenAI’s bad faith or a broken feature. It is neither. It is a story about teams mistaking a stated preference for an enforced obligation, and discovering the difference at the worst possible time. A checkbox in a product UI has no lifetime you control, no notification when it changes, and no commitment attached to it. Building data governance on top of it is building on state that was never authoritative, and state that is not authoritative drifts back to its default the moment a code path decides to reapply one. That is not malice. It is the predictable behavior of a value that its owner treats as a default and you treat as a guarantee.

The fix is architectural and it is boring, which is how you know it holds. Route sensitive workloads through a surface governed by contract, put a gateway in front of every provider so the contractual route is the only route, classify before you send, redact what you can, log what you do, and block the paths that bypass all of it. Once that exists, the question ‘is training turned off?’ stops being a question you ask a settings page and becomes a property of your system that is true on every call whether or not anyone is watching. You have moved from hoping the box stays checked to making the box irrelevant.

Treat every consumer-facing setting the same way from here forward. Assume it can revert without notice, assume no one will tell you when it does, and design so that the reversion cannot touch anything that matters. The teams that got burned were not careless about the toggle. They were careful about the wrong thing. They guarded a preference and called it a control. Guard the data path instead, enforce it by contract and by construction, and the next quiet backend change at OpenAI becomes something you read about, not something you have to survive.