One of the real reasons a lot of companies won't touch AI isn't "will it write good code." It's "where does my code go, and who trains on it?"
A lot of companies are correctly worried about giving up their IP. That isn't paranoia — it's a reasonable question. Here's how I help people get their heads around the lay of the land.
The landscape
Most of the big AI companies — I'm talking about Google, Microsoft, OpenAI, and Anthropic, which makes Claude — have a consumer tier we're all used to, plus business and enterprise tiers. At the other end of the spectrum you've got local models you run yourself.
In between there's a whole set of inference providers — Amazon and other cloud providers who'll run a model for you. And there's another tier of organizations, many of them out of China or other parts of the world, running their own near-frontier-class models that are still very much viable.
Since most of my customers are US-based, I'll talk about it from that practical standpoint. And to be clear up front: I'm going to leave the foreign cloud models out of this discussion for now. Not because I think they're intrinsically wrong — just that if something went sideways, and it turned out they weren't honoring their agreements and were training on my client's data, I'd have no real recourse. So I set them aside.
First, what shouldn't be in your code at all
A lot of this comes down to how concerned you are about a specific piece of IP.
If it's something like "here's the secret key that unlocks my product" — that shouldn't be in your code in the first place. It shouldn't be committed to your repository. Software developers learned this a long time ago with networked systems: you don't store your secret keys and encryption keys alongside your source.
Same idea if you've got, say, a proprietary algorithm. You don't necessarily want the coefficients left in plaintext in your source code. It could be handled in firmware as a binary, or even better, built by CI.
That's smart, and it means that even if you have partners or AI agents that you don't fully trust working on it — you aren't risking your IP!
So before you even get to the AI question, some of your most sensitive material just shouldn't be sitting in the code you'd hand to a tool or an outsourcing house anyway.
What "do not train" actually buys you
Here's the most useful distinction to understand: consumer tier versus business tier.
Most of these vendors will give you a strong guarantee, on their business tier, that none of your data will be used to train their models. That's the thing to fight for, because a model trained heavily on your proprietary data can create a nightmare scenario.
The nightmare scenario is a competitor building a product just like yours — they describe it, and the model starts producing your source code, or at least a facsimile of it. That's your absolute worst case, and "do not train" is what helps prevent it.
This is the world we're in. Allowing all your data to be used for training is the default setting on personal Claude and ChatGPT accounts.
This means your team members are likely regularly uploading your company IP to these frontier models.
It's not because they are trying to violate their agreements, but usually because they are unwittingly doing so.
Fortunately this one is easy to fix, and it's worth having everyone on your team do it today.
ChatGPT or Codex — go to Settings → Data controls and make sure "Improve the model for everyone" is Off:
https://chatgpt.com/#settings/DataControls
Claude — go to Settings → Privacy and make sure "Help improve our AI models" is turned off:
https://claude.ai/new#settings/data-privacy-controls
That takes about a minute per person, and it's basically the cheapest risk reduction you can get!
But "do not train" doesn't cover everything. It doesn't guarantee that, say, a human at the company never looks at your prompts. For example, let's say your AI provider is diagnosing an issue with their cloud services. They may start looking at the prompts that came through. Many of these agreements allow them to do whatever they need to do to fix their services. Some providers will give you a guarantee of zero data retention, others require 30 days.
So it's worth understanding how private "private" really is.
For my own work, I'm under a lot of different agreements about how I can and can't handle client data — where it's processed, what it's processed through. I keep a machine here that can run AIs fully air-gapped: not connected to the internet, not connected to anything. That's extremely safe — it can't leak data anywhere. But most people don't start there, and the models I run locally aren't as capable as the frontier ones.
If you want to hedge against the hype
I often get asked: we're very concerned about security, how do we move forward? Which provider should we use? Do you trust this vendor over that one?
A lot of the folks asking aren't already embracing AI, and they're suspicious there's a bubble that could pop. If you want to hedge against that, my recommendation is to look at Google or Microsoft or Amazon as your main provider. GitHub Copilot is a very popular tool, and it lets you reach a lot of these other models through it.
The reasoning is enforceability. If something wild happens — the laws change, somebody messes up, your IP gets out — Google and Microsoft are very likely still going to be in business. They've got other revenue streams; they'll probably be fine. With some of the pure-play AI companies, it remains to be seen what happens if there's a big correction and it turns out they weren't holding up their end. So when a client is very concerned, I'll point them at Google's Gemini or Microsoft's GitHub Copilot.
A practical ladder for sensitive data
For a lot of businesses, this comes down to policy. Here's roughly the ladder I walk people up, from lowest cost to most protective:
- Turn off training. The lower-cost, slightly-less-safe option: tell your employees they have to turn training off (the two settings above), which essentially all the major frontier models let you do for the data you upload. It's a good step.
- Have a policy that team members don't put sensitive data into outside AI. The practical reason is simple — you don't want your sensitive data ending up as training data in a public model your competitors can pull value from.
- Provide enterprise access. Give people one of the enterprise-level AI accounts. That comes with some cost and setup on your end, but it's a real step up.
- Run your own local models. The longest view: stand up your own models on a relatively expensive piece of hardware. You get a lot of the same benefits of AI without putting any of your data at risk.
The middle path I use a lot
I'll often hit a situation where I have restrictions on AI use from a client for IP reasons. I can often split the work into two buckets. One where the work is fully separated and isolated from the existing IP and another where it is not. I agree on this split with the client up front — the point of their restrictions is keeping their IP out of outside models, and this is how we honor it. In the non-isolated bucket I only use air-gapped locally hosted models and do the rest by hand.
In the isolated bucket I often include new components or tools to be built or set up. The idea is these are things that are not directly related to our work, let's say a supporting UI or some standard algorithms. The way I handle it is to write up a spec for the pieces I need built without including any of the customer details (no IP, no names, no product category, etc.). That's something I can absolutely hand to a frontier model without exposing any private information.
The integration of the UI or other component still has to be done by hand, but it still saves a ton of time. Less time, higher value, smaller invoices.
Everyone wins! And IP is fully isolated from any cloud providers.
So honestly — you really don't have to choose between using AI and protecting your IP. If you're trying to find a setup that works for your sensitive work, I'm happy to talk it through.