10 Guidelines for Drafting Data Definitions: Practice Points

Start with what your client actually needs from the product. Tiffany grounded every data definition review in the client's goals and how the client planned to use the product. You can fight for rights to everything that could ever touch your client's confidential information, and you'll burn a ton of cycles on terms that don't match how the product works. Know the purpose first. That tells you how expansive each definition needs to be.

Draft input definitions for how data really reaches the system. Inputs used to mean prompts. Today they include connectors, data feeds, integrations, agents, knowledge bases, playbooks, and anything pulled in through Slack or a calendar. Tiffany replaced narrow phrases like "submitted by customer" with language covering data submitted or made available by or on behalf of the customer. That way nobody can argue input lost its protections because an agent or a contractor supplied it.

Keep obligations out of your definitions. Laura flagged sample definitions that mushed a training restriction into the definition itself. Tiffany pointed out that a restriction buried in a definition is much harder to give teeth, because you'll want representations, indemnities, and maybe a super cap around it. Laura compared it to littered indemnities scattered across a contract without the notice, process, and exclusions that belong with them. Give each obligation its own section.

Make training restrictions reach the whole model supply chain. A vendor promise not to use your input data to train ITS models says nothing about the underlying model providers. Most vendors don't build their own LLM and instead rely on a web of upstream providers. Akiva called that wording favorable to the vendor, and Tiffany wanted the restriction extended to every underlying AI provider. Read the possessive pronoun carefully.

Tie usage data to the technical realities of the product. Tiffany defined usage data around the health of the system, including uptime, latency, errors, and the capacity numbers needed for usage-based billing. Akiva offered the vendor view that vendors want more than telemetry. They want to see where users click, which features get used, and what users do with the data they upload. Know which version you're agreeing to before you sign.

Focus your negotiation on what the vendor may do with the data. Akiva said it is much easier for a vendor to agree to use restrictions than to change what the product collects, because the lawyer controls the promises and not the engineering. Tiffany cared less about who owned usage data and more about what it could be used for. "For any purpose" let the vendor sell or publish it. Push for internal analytics and product improvement only, and ask for anonymization, not just aggregation.

Carve out what you don't want swept into usage data. "All data generated by the service" arguably covered output. Tiffany didn't try to fix those words and instead added an express exclusion for customer input, output, and confidential information. Laura added that usage patterns can reveal trade secrets and business decisions a customer considers confidential. Say exactly what you mean rather than hoping the words get you there.

Give customer outputs room to cover what the system creates. The sample defined customer outputs as content that "contains" customer input data, and AI output often contains no input at all. Akiva and Tiffany both expanded it to content generated in response to or derived from customer input. Tiffany also wanted vague system outputs tied to concrete examples like workflows or playbooks. She checked whether the customer needed rights to them just to use the product.

Study how the major AI providers draw their lines. Anthropic and OpenAI defined inputs narrowly around what customers and users submit, which ignored connectors and agentic access. Perplexity used the broader "made accessible to the services" and excluded third-party material. xAI excluded support, billing, and account data from input, which left that data outside its training ban. Laura said every deviation among similar companies shows you where some lawyer thought "we better take care of this."

Read every place a defined term shows up before you push. Laura searched each key defined term with a simple find command and read every use in context before deciding whether she wanted it broad or narrow. A broad definition that helps a customer in one clause can come back to define a limitation of liability exclusion. Akiva wanted neither broad nor narrow and preferred one consistent definition across contracts, with flexibility on obligations. Tiffany aimed for the narrowest definition that reflected what the product really needed.