When you define input data in an AI product contract, you are doing a lot. The one defined term sets what the customer keeps protected and what the vendor may reuse or train on. If you get it wrong, as our speakers said, the provision that says “do not train on my data” may not protect what you think it does.
This week’s lesson from How to Contract is here to help you improve your approach to these provisions.
PART 1: PDF Download on Reviewing AI Input Data Definitions
Here’s our two-page handout on input data definitions. The next time an input data definition crosses your desk, you will know what to look for.
PART 2: Video Lesson With Important Drafting Fixes
David Sclar and Laura Belmont shared their insights into drafting data definitions in AI agreements during a webinar earlier this year. Here’s a link to watch the 12-minute segment on input data definitions.
Why does an input data definition carry so much weight?
David Sclar explained that a customer’s inputs reveal the customer’s AI strategy. What you choose to enter, and why, exposes how you use the tool. So the customer wants to own all of it and keep it confidential. The provider needs room to operate. David’s punchline framed the whole segment. Everyone wants the clause that says “do not train on my customer data.” But if you have not paid attention to how the contract defines customer data or input data, that clause is worth far less than you think. The definition does the real work.
Laura Belmont made the point that a provider gets real intelligence from watching how its system performs in the real world: where it fails, what edge cases emerge, and how users interact with it. The provider uses that data to fix bugs, improve accuracy, and prevent harmful outputs, which customers want too. Both needs are legitimate, and they sit in genuine conflict. That tension is why these negotiations get hard.
Join us at ContractsCon 2026 for a full training day on AI contract drafting
ContractsCon 2026 includes five training sessions on critical provisions in AI product contracts. Join us in Philadelphia on October 13-14 and virtually on October 21-22. You’ll learn from our AI contracting experts and practice drafting revisions with your small group. Don’t miss out on the contract training event of the year! Early bird pricing ends July 15.
Laura and David’s Definition Language Review
Each How to Contract AI contract drafting webinar analyzes a sample provision drafted by Claude. Here is the language we reviewed in this segment:
“Input data means any data or information submitted by the customer while using the product.” AI-drafted slop language (do not use)
As David put it, vagueness helps no one, and this definition sits on the vaguer side. It also skips the specifics that matter: what a customer wants protected, and what a provider wants carved out. Here is where it goes wrong.
1. “Submitted by the customer” is too narrow for how AI pulls data
“Submitted by” - Laura Belmont said this word stems from the old chat model where you type something and send it. She pointed out that it misses the data an AI system accesses or retrieves on its own. Now you enable the AI tool to pull data in for a response. You did not “submit” it. The connector pulled it. The same happens with agents. An agent identifies what information it needs to do a job and pulls it in on its own. Laura emphasized how we need a tighter definition that covers data accessed and retrieved, not just submitted.
“By the customer” - This phrase is also limiting. Laura suggested we should look at broadening it to cover a named entity acting on behalf of the customer, and an agent pulling data on the customer’s behalf. Say who and what counts, or the most common modern data flows fall outside the definition.
2. “While using the product” does not fit how agents run
“While using the product” — Both David and Laura flagged this issue. The harder or more complex the task, the greater the latency, and the more likely people are using agents that run in the background. If you start an agent and walk away, are you “using” the product? Laura’s point is that you are not hands on keyboard watching it work. You may set it and forget it. That’s why she suggested you consider language like “in connection with” the product rather than “while using” it, so the definition captures the work happening on the back end.
3. “Any data or information” is too vague to protect either side
“Any data or information” - This is the meat of the definition, and it cuts both ways.
For the customer - Laura explained how “any data or information” may sound broad but lacks precision. Laura’s advice is to add “including but not limited to” and then list what you know matters today. That may include your prompts, the data you attach, confidential information you retrieve through a connector, your instructions and commands, usage data and patterns, metadata, and feedback data. She flagged how blurry these boundaries are. If you tell the model “that response was terrible, do more,” is that a prompt, feedback, or input? If you want it captured as yours, say so explicitly.
For the provider - David suggested adding in exclusions. He said telemetry, safety signals, and fraud and abuse monitoring data should be expressly carved out of input data, so the provider stays free to use them to run and protect the platform. David also offered a way to argue for this detail without sounding defensive. He said partner with your business team so you can explain, in plain terms, exactly what data the provider needs and why it keeps the platform safe and useful for everyone. Framed that way, the specificity looks beneficial and practical, not like a lawyer hedging against risk.
Laura made one other important point that applies to both parties. Before you negotiate, get introspective about what you actually care about. Maybe the competitive intelligence angle does not matter much to you, but the financial data you want analyzed does. Know your use cases, decide what is genuinely important to protect, and spend your negotiating capital there.
Want to learn more? Read this article with 10 takeaways from the full webinar.
Want to watch this entire webinar or any of the other 100+ contract training webinars we’ve hosted since March 2025?
How to Contract members have access to all 100+ webinars. That includes 60+ webinars recorded in 2026 (25 on AI contracts and 25 on core subjects) plus 40 webinars on AI contract drafting in 2025. That is just part of our library with over 240+ hours of training videos from the last five years of How to Contract contract training programs.
