Keeping Client Data and IP Out of Your AI Tools: A Practical Boundary

I hear a version of the same sentence from almost every technical firm I talk to: “We want to use AI, but legal won’t let us near client data with it.” Usually this gets treated as a dead end, as if the choice is between a blanket ban and hoping nobody notices. It isn’t. Most of the time nobody has drawn a line anyone can defend, so the safest available answer is no.

The blocker is legitimate

Take the objection seriously, because it usually is. If you run a biotech consultancy with pre-patent research on your laptop, or an engineering firm holding client designs under NDA, the downside of a leak isn’t hypothetical. A sequence or a schematic that ends up in a third party’s training data or logs can compromise a patent filing or violate a contract you signed in good faith. Counsel is not being difficult. Counsel is doing the job.

The trouble is that a ban doesn’t make the risk go away. It moves the risk somewhere you can’t see it. Engineers under deadline pressure paste a spec into ChatGPT on a personal account because the sanctioned path doesn’t exist. Now the same data is exposed, and you’ve lost the audit trail that would have told you it happened.

Not all data is the same risk

Sort your data into categories, because a marketing brainstorm and a client’s proprietary process do not carry the same exposure.

Some work genuinely doesn’t need protection. Drafting a blog post, summarizing a public paper, or brainstorming a conference talk carries no client obligation and no IP exposure. That kind of work can go to a hosted model with reasonable terms.

Other work sits in the middle: internal documentation, non-sensitive code review, general research synthesis. This is where an enterprise agreement with a no-train clause earns its keep. You get the capability of a hosted model without your inputs becoming someone else’s training data.

Then there’s the category that should never leave a boundary you control: client data under NDA, pre-patent research, anything a subpoena or a breach notification law would treat as sensitive. That tier gets a self-hosted or heavily bounded environment, regardless of how convenient the alternative looks.

Most firms I talk to have never drawn these three lines. They have one bucket labeled “AI” and one policy, “ask legal,” which functions as a no by default.

The questions that build the boundary

Before any tool touches sensitive data, four questions should have documented answers, not gut-feel answers.

Does it train on your inputs? Most vendors have an enterprise tier that disables training by contract, but the default consumer tier for the same product often does not. Read the terms, not the marketing page.

Where is it hosted, and under what jurisdiction? A model running in your own VPC or on hardware you control is a different exposure than a call to an API endpoint you don’t operate.

Who can be compelled to hand over your data? Subpoena exposure runs through the vendor’s legal jurisdiction and their own retention policy. Know both before you commit anything sensitive to the pipeline.

Is there an audit log you can produce on demand? If a client or a regulator asks what touched their data and when, “we’re not sure” ends the relationship. A log showing exactly which tool touched which file, and when, keeps it.

I wrote about the same underlying idea from an engineering angle in an earlier post on sandboxing coding agents: the discipline of running an AI tool inside explicit limits, rather than handing it the run of your environment, isn’t a constraint on capability. It’s what makes the capability usable on work that actually matters. The same logic applies one level up, at the level of which data classes go to which tools.

A boundary you can explain beats a ban you can’t enforce

None of this is legal advice, and I’m not your counsel. What I can tell you, as someone who builds these pipelines for a living, is that the technical piece is the tractable part. Enterprise no-train agreements exist. Self-hosted models that never leave your network exist. Audit logging that shows exactly what went where is a solved problem, not a research project.

What’s usually missing is someone translating “we want to use AI safely” into a written data contract that counsel can actually read and sign off on: this class of data goes here, under these terms, with this log; that class never leaves the building. Once that document exists, the conversation with legal stops being adversarial. You’re not asking them to approve a black box. You’re asking them to review a boundary, which is exactly the kind of thing they’re equipped to approve.

If your team is stuck between “we need AI to stay competitive” and “legal won’t sign off,” that gap is usually a half-day of scoping work, not a six-month evaluation. I help firms like yours draw that line and write it down. If that’s useful, grab 30 minutes on my calendar and we can figure out where your boundary actually needs to sit.