A senior engineer is three hours into a stubborn concurrency bug. They copy the failing function — proprietary logic, internal variable names, a comment referencing an unreleased architecture — and paste it into ChatGPT with "why does this deadlock?" The answer is helpful. The paste is irreversible. That snippet is now subject to a provider's terms of use, and no amount of policy after the fact pulls it back.
This is the tension every R&D-intensive company is living with. The people closest to your crown-jewel IP are the ones getting the most value from AI — and the most tempted to feed it the exact code that makes your company worth something. You don't want to slow them down. But every fast answer carries the risk of quietly disclosing the thing your valuation rests on.
Why the crown jewels are the most exposed
The cruel logic of AI adoption in engineering orgs is that usefulness scales with specificity. Generic questions get generic answers. The prompts that actually unblock work are the ones stuffed with your real code, your real schemas, your real design decisions. So the most sensitive material is precisely what flows most naturally into the prompt box.
The numbers say this is already happening at scale. Cyberhaven found in 2025 that roughly 40% of AI interactions involve sensitive data, and that the sensitive share of corporate data going to AI rose to about 35%, up from around 11% two years earlier. LayerX reported that 77% of AI users paste data into prompts, and 82% of that comes from unmanaged personal accounts. Gartner's 2026 survey found 88% of employees with enterprise AI access also use personal AI tools for work. Your careful enterprise agreement doesn't govern the tab an engineer opened on their own login.
Samsung learned the shape of this in 2023: within about twenty days of allowing ChatGPT internally, engineers had pasted source code, a defect-detection algorithm, and a meeting transcript into it. The data couldn't be recalled. A company-wide ban followed — which is the reaction most orgs default to, and the one that quietly fails.
Bans don't reduce risk, they hide it
When you block ChatGPT at the network, you don't remove the engineer's need to debug faster. You remove your visibility into how they're solving it. They switch to a personal account on their phone, or a different tool you haven't blocked yet — there are more than a dozen in common use — and the paste happens anyway, now completely outside anything you can see or govern.
This is the trap of treating AI as a tool to control rather than data to protect. Gartner reports 69% of organizations suspect or have evidence of prohibited public GenAI use. The prohibition is already there for most of them. The prohibited use is happening anyway. A ban converts a governable behavior into an invisible one, and invisibility is exactly what you can't afford when the material at stake is your source code.
There's a real cost attached to getting this wrong at the diligence table, too. When an acquirer or investor examines your company, your IP is the asset. "We can't fully account for where our source code has been sent" is not a sentence you want to say during due diligence — and once code has been submitted to a public tool, it may be retained, processed by sub-processors elsewhere, or used to train the provider's models. That's not a hypothetical exposure; it's a factual weakening of your trade-secret position.
Trade secrets require secrecy — and a paste can end it
The legal reasoning here is worth sitting with, even directionally. In Trinidad v. OpenAI (N.D. Cal., Jan 2026), a trade-secret claim was dismissed because developing the alleged secrets via ChatGPT counted as voluntary disclosure. The secrecy that made the material protectable was treated as forfeited the moment it went into the tool.
Translate that to a deep-tech company: trade-secret status and, in some cases, patentability depend on the invention not having been disclosed. An engineer pasting a pre-patent algorithm or a novel process into a public AI tool isn't just leaking data — they may be undermining the legal protections that make the invention yours to commercialize. This is directional, not settled law, but the direction is clear enough that you don't want to be the test case.
And the point isn't to make your engineers afraid to use AI. It's that the disclosure risk lives at a specific, catchable moment: the instant before a prompt is submitted. Before that moment, you have a decision to make. After it, there's nothing left to control.
Govern the data, not the tool
The way to keep velocity is to stop asking engineers to make a judgment call under pressure about what's safe to paste. That judgment is exactly what breaks down at hour three of a debugging session. Instead, the control has to act on the data itself, in the moment, whatever tool the engineer reached for.
That means sensitive content — source code, internal identifiers, design details — gets caught and redacted before the prompt reaches the AI tool, with realistic placeholder values so the model can still reason about the structure of the problem and return a useful answer. The engineer keeps their fast feedback loop. The crown-jewel specifics never leave your control. And when something is flagged, a plain-language explanation of what was caught and why turns each near-miss into a moment of training, so your team gets measurably better at safe AI use instead of just getting blocked.
This is the principle Sanitized AI is built on: protect the data at the point of entry, so people don't have to choose between doing their job well and keeping the company's IP intact. Leaders get a record of policy events and where risk concentrates — never the contents of what an engineer typed.
The question worth asking your team this quarter is simple: if an engineer pasted your most valuable function into a public AI tool tomorrow, would you know — and could you have stopped just the sensitive part without slowing them down? If the honest answer is no, that's the gap to close. Request a demo and we'll show you what it looks like in your own workflow.