A growing number of corporate clients are putting explicit AI provisions in their MSAs and NDAs. Not vague "protect our data" language that's been in contracts for years, but specific clauses that address AI services by name or category. Some of those clauses are narrow: no training on our data, no use of outputs to improve a model. Others are broader: no uploading of our confidential information to any AI service.
If you're an independent consultant or boutique agency that signs MSAs with enterprise clients, there's a real chance you already have one of these clauses sitting in your contract stack. And if you're using ChatGPT Plus, Claude Pro, or any cloud-based AI tool for that client's work, there's a real chance you're in breach of it.
I want to walk through the actual distinction that matters in these clauses, why common "safe" options like enterprise AI tiers don't fully address it, and what the only architecture is that honors a strict no-upload requirement literally.
Most of the AI-specific NDA language that's been reported in legal commentary over the past 18 months falls into two categories.
The first category is training-focused: "Consultant shall not use Client's confidential information to train any artificial intelligence model." This is primarily about protecting the client's data from being used to improve AI systems. It addresses what happens to data after it's been processed, not whether it can be transmitted in the first place.
The second category is upload-focused: "Consultant shall not upload, transmit, or otherwise submit Client's confidential information to any artificial intelligence service or platform." This is broader. It prohibits the transmission itself, regardless of what happens to the data afterward. A vendor's contractual promise not to train on your data does not satisfy this clause, because the data still got transmitted.
Sophisticated clients, particularly in financial services, healthcare, and defense contracting, have been moving toward the second formulation. Their legal teams understand the distinction between "they promised not to use it" and "it never left our control," and they want the latter.
This is the gap most consultants don't notice until it's too late.
When you paste client work product into ChatGPT Enterprise or Claude Team, the data travels from your machine to OpenAI's or Anthropic's servers. That's an upload. Those enterprise tiers contractually promise not to use the data for training. But the upload happened. The data left your machine and arrived at a third-party vendor's infrastructure.
A strict no-upload clause is violated by the transmission itself. The vendor's training policy is irrelevant to whether you've complied with the clause, because the clause governs the upload, not what the vendor does afterward.
A "no training on our data" promise from a vendor tells you what they'll do with your client's information after it arrives. A "no upload" clause tells you the data can't arrive there at all. These are different requirements and they need different solutions.
The same logic applies to Microsoft 365 Copilot, even in its enterprise tenant configuration. Your prompts go to Microsoft's Azure infrastructure for processing. Your client's confidential strategy document, pasted into a Copilot prompt, left your machine. The enterprise security around that transmission is real, and Microsoft's data handling commitments are real, but the clause says no upload. The document was uploaded.
Before getting to the architecture solution, it's worth being specific about what the consumer tiers actually do, because many consultants don't realize their default settings.
ChatGPT Free and Plus train on conversations by default. You have to actively opt out in settings. Claude's consumer tiers (Free, Pro, Max) have similar default behavior; Anthropic's consumer privacy policy describes data retention and usage that differs from the enterprise agreement. Claude Pro keeps conversation data for a period of time and uses it for safety and model improvement unless you opt out.
So with consumer tiers, you're not just uploading to a vendor. You're uploading to a vendor that trains on the data by default. A client who wrote a "no training" clause and then discovered their strategy documents were in your Claude Pro conversation history would have grounds to be upset on two levels: the upload itself, and the training use.
Even if you've opted out of training on a consumer account, you're still uploading. The opt-out addresses the training clause but not the upload clause.
There's a related risk that doesn't get as much attention: cross-contamination between client contexts.
Most consultants work across multiple clients at once. If you're using the same AI tool account for multiple clients, there's a question of whether information from one client's context can influence responses involving another client's context. This depends heavily on the tool and how context is stored and used.
Long-context memory features, conversation history, and workspace features in AI tools can create situations where confidential information from Client A is technically in scope when you're working on Client B's project. Whether this violates your NDAs depends on the specific language, but it's a real risk surface that a single shared AI account creates.
The cleaner answer is per-client isolation at the folder level. Your work for each client lives in a separate, clearly bounded workspace. Nothing from Client A's context is reachable when you're working on Client B. This is a structural guarantee rather than a behavioral one.
A local model, running entirely on your hardware, means the AI inference happens on your machine. Your prompt, which contains your client's confidential information, never travels over the network to any vendor. There is no upload. The data doesn't arrive anywhere except your own processor.
This is the only setup that can honestly tell a client: "Nothing you shared with me was uploaded to any AI service." With a cloud tool, even the best-governed enterprise tier, you're telling them: "What you shared was uploaded to a vendor, but the vendor has promised to handle it responsibly." Those are different representations, and a client with a strict no-upload clause will read them differently.
The local model path has gotten considerably more practical over the past year. Open-weight models like Llama 3.1, Mistral, and Qwen 2.5 run well on modern laptops with a decent GPU, or on a desktop machine. Ollama makes the setup tractable without requiring any technical depth beyond following a guide. The output quality is meaningfully below the frontier models (Claude Sonnet, GPT-4.1) for complex reasoning tasks, but for drafting, summarizing, outlining, and reviewing client documents, the quality is usable.
One honest caveat: local models don't change anything about your final deliverable. The deck still gets built in PowerPoint or Gamma. The model helps you think, draft, and structure. It doesn't replace the design tool, the spreadsheet, or the presentation software your client is expecting. Using a local model for the confidential thinking work and a standard tool for the designed output is a reasonable and honest split.
If you're actively working on an engagement with a no-upload NDA clause and you've been using cloud AI tools, the practical steps:
Some clients will accept a "enterprise tier with SOC 2 and no-training contractual protections" answer. Others won't. Knowing which kind of client you're dealing with before you start using AI on their work is much better than finding out afterward.
Here's the angle most consultants miss: being able to honestly tell a prospective client "I use AI to work faster, and I do it in a way that nothing is ever uploaded to any external service" is a differentiator. Sophisticated clients are asking about AI use in their vendor evaluation now. Most consultants either use cloud AI and hope the client doesn't ask, or avoid AI and miss the productivity. The local model path lets you say yes to AI and yes to strict confidentiality at the same time.
That's a conversation worth having proactively, not reactively when the client's legal team is already asking questions.
Advisor Prep Hero is set up for this workflow. Connect it to a local model via Ollama and nothing leaves your machine; connect it with your own API key and you're routing directly to the model provider with no Advisor Prep Hero intermediary. Each client gets their own workspace folder. Your outputs are Markdown files on your drive, not entries in a vendor's database. The consulting workflow templates were built with input from practicing independent consultants and include engagement kickoff, discovery synthesis, and stakeholder-presentation templates. The local model setup guide covers the Ollama connection step by step. For a direct look at how this compares to the deck-generation tools, here's an honest comparison of Advisor Prep Hero and Gamma, including where Gamma is the better tool for the final deliverable.
The NDA clause problem has a clean technical answer. A local model is the only AI setup where you can say, without qualification, that your client's confidential information was never uploaded to any service. For the clients who care about that distinction, and there are more of them every year, that's a real and substantive promise.
This is informational, not legal advice. Whether your current AI tool use complies with your specific NDA or MSA obligations depends on the exact contract language and applicable law. Verify your posture with your own counsel before making representations to clients about your AI data handling.