Drafting AI Confidentiality Provisions: What Changes When Data Moves Through Models

Check whether the clause was written for AI at all. Most AI confidentiality problems trace back to language copied from a SaaS agreement or an outsourcing deal. Those clauses assume data sits in one place under one party's control. In an AI product, your data moves through prompts, model providers, logs, and caches. Read the clause against where the data actually goes and you will spot the gaps quickly.

Educate both sides before the redlines start. So much friction in these negotiations comes from fear and conflated concepts, like treating machine learning and generative AI as the same thing. Carly sends an FAQ about the service before redlining begins and holds calls to explain how the AI works. Data flow diagrams accelerate understanding even faster. Shared understanding of the technology shortens the negotiation more than any clever drafting move.

Cover outputs and configuration, not just inputs. A standard definition captures what you disclose, which handles inputs and little else. Outputs the system generates and the configuration you built, including your prompts and tuned workflows, can sit entirely outside the defined term. Those two buckets often reveal more about your strategy than the inputs do. Bring them into the definition explicitly rather than hoping a catch-all reaches them.

Plan for data that outlives the engagement. Return or destroy clauses were written for documents you can drag into a trash can. Prompt logs, vector embeddings, and similar artifacts persist after the session and sometimes after the contract. Your information can outlive the obligation meant to govern it. Close that gap with deletion on request, certification of deletion, and survival obligations tied to an enforceable timeline. Discovering the gap at termination is too late.

Promise only what your systems actually do. Before agreeing to a request like no prompt retention, confirm with the engineering team that the commitment is real. We sometimes see vendors sign confidentiality terms describing a service they do not actually operate, and that is a breach waiting to be found. The same discipline applies to data residency promises. Contracts should describe how the system works in reality, not how the customer imagines it works.

Know what your model providers agreed to. Your confidentiality commitments run downstream through frontier model terms you did not draft. Over-committing to a customer can put you in violation on day one because your model provider terms permit something you just promised away. Read those provider agreements before you negotiate your own paper. Your customer commitments can only ever be as strong as the weakest deal beneath them.

Drop marking requirements for prompts and outputs. Identification gates made sense when confidential information arrived as a document with a cover letter. Nobody marks hundreds of prompts a day. A marking requirement quietly drops that entire data flow outside the clause. Make inputs and outputs confidential by default, without any marking or identification requirement, so the protection works at the scale the tool actually runs.

Put a floor under derived data. A carve-out for derived or aggregated data without restriction or time limit gives the vendor a relabeling path out of the entire clause. Require that derived data must not allow re-identification of the customer or reconstruction of customer inputs. Remember that sensitive data can be derived from innocuous data points, so add protections against derivatives that violate law or create sensitive categories. Vague derivative language is a black box, and we should be the ones adding the clarity.

Carry your protections down the sub-processor chain. Your contract binds your vendor and nobody else. Require that each downstream recipient be bound by terms at least as protective as your agreement, and ask for a current list of sub-processors and model providers with advance notice of changes and a right to object. You can't assess a risk you can't see. Without the flow-down, your negotiated deal is the high water mark and everything below it runs weaker.

Keep residuals and training rights on a short leash. Residuals doctrine exists because you cannot erase a person's brain. A model retains by design, so the word systems in a residuals clause converts human memory into unrestricted machine retention. Limit residuals to individual memory only. Watch for develop, train, and improve language, which is a training license in disguise, and for ownership grabs over improvements and insights derived from your data. Start from a clear no-training position and consent later when the value makes sense.