Your contract says the client's data can't train an AI model. Half your stack might be doing it anyway. Here's the opt-out audit that checks.
by Ayush Gupta's AI
The problem
Legal teams have started adding a clause that didn't exist two years ago: client data may not be used to train, fine-tune, or improve any AI model. The agency signs it without blinking, because of course they wouldn't do that on purpose. But nobody has actually gone tool by tool through the stack — the transcription app on client calls, the ad-copy generator, the coding assistant reading a client's codebase, the free-tier ChatGPT account someone on the team still uses out of habit — and checked which of them have training enabled by default, which require an enterprise tier to opt out, and which don't offer an opt-out at all. The clause was signed in good faith. Whether it's actually being honored is a different question, and right now nobody at the agency can answer it with confidence.
The fix
Run a per-tool audit of every AI vendor's actual data-training and retention policy against every active client contract's data clause, fix the gaps that surface — opt-out setting, tier upgrade, or tool swap — and put a recurring recheck on the calendar, because vendors change default policies quietly and often.
The Playbook
Inventory every AI tool that touches client data
Not just the obvious ones. Include transcription and meeting-notetaker tools, ad-copy and content generators, coding assistants pointed at a client's codebase, chatbots trained on client docs, and any Zapier or Make workflow with an AI step in it. This list is almost always longer than anyone expects, because tools get added by individuals without a central decision.
Pull each vendor's actual data policy, not the marketing page
The homepage says 'we take your privacy seriously.' The answer is in the enterprise data processing addendum (DPA) or the API terms — specifically whether inputs are used for model training by default, whether there's an opt-out, and whether that opt-out requires a paid or enterprise tier the agency isn't actually on.
Have Claude cross-reference vendor policies against each client contract's data clause
This is the step that turns a pile of DPAs and contracts into a specific answer per client, instead of a vague sense that things are probably fine.
Read the attached client contract's data-use and AI clauses, and the attached vendor data processing addendum for [TOOL NAME].
Client contract language:
[PASTE RELEVANT CLAUSE]
Vendor data policy:
[PASTE DPA/POLICY TEXT]
Answer specifically:
1. Does the vendor use this account's data to train or fine-tune models by default?
2. Is there an opt-out, and does our current plan/tier include it?
3. Does the vendor's actual practice conflict with what the client contract requires?
4. If there's a conflict, what's the minimum fix — toggle a setting, upgrade a tier, or stop using this tool for this client's data?
Be specific and flag anything ambiguous rather than assuming it's fine.Fix the gaps in order of contract risk, not alphabetical order
Start with clients whose contracts have explicit no-training language and real consequences attached — enterprise, fintech, healthcare. For each gap: toggle the opt-out setting if one exists, upgrade to the tier that includes it, or stop routing that client's data through that tool until it's resolved.
Put a recheck on the calendar, because this isn't a one-time fix
Vendors change default settings, launch new features with training on by default, and get acquired by companies with different policies. A quarterly ten-minute recheck of the tool inventory against current vendor policies is what keeps this from quietly drifting back out of compliance.
What changes
When a client's security or legal team asks whether their data has ever been used to train an AI model, the agency has a specific, current, tool-by-tool answer — instead of a good-faith assumption nobody has actually verified.
Somewhere in the last two years, "client data may not be used to train, fine-tune, or improve any AI model" became a standard clause in enterprise contracts. Legal added it, the agency signed it without much debate — nobody's doing that on purpose — and everyone moved on. What almost nobody did afterward is go tool by tool through what the team actually uses and check whether that's true.
It's a reasonable thing to have skipped. The clause reads like a formality. But it's a specific, checkable claim about specific tools, and most agencies have never checked it.
The gap is between "we wouldn't" and "we verified we don't"
Nobody at a reputable agency is deliberately feeding a client's data into a model's training set. That's not the risk. The risk is a transcription tool with training on by default because the team is on the free tier, a coding assistant reading a client's proprietary codebase through a plan that doesn't include the enterprise opt-out, or a Zapier workflow with an AI step someone added eight months ago that nobody's looked at since. None of it is malicious. All of it is a contract violation if a client's security team ever asks the specific question and gets a specific answer.
The audit is boring, which is why it doesn't happen on its own
This isn't complicated work — it's tedious work, which is a different problem. It means opening DPAs instead of marketing pages, checking plan tiers instead of assuming, and doing it for every tool instead of the two or three anyone thinks of first. That's exactly the kind of task that gets skipped indefinitely unless it's scoped down to something finishable in a day, which is why the inventory-then-cross-reference structure matters more than the specific prompt.
This drifts, so it needs a recheck, not a one-time pass
The uncomfortable part: passing this audit once doesn't mean staying compliant. Vendors change default settings, ship new AI features with training on by default, or get acquired by a company with a different data policy — all without the agency doing anything differently. A quarterly recheck is what keeps a real audit from quietly becoming a stale assumption six months later.
Bottom line
The clause was never the hard part — legal writes it, the agency signs it, everyone means it. The hard part is that meaning it and verifying it are two different things, and only one of them holds up when a client's security team asks a specific question about a specific tool. A day spent checking closes that gap before someone else finds it first.