Most AI product contracts focus on the customer-vendor relationship and treat the foundation model provider sitting upstream as an invisible layer. That layer does not stay invisible when something goes wrong. Restrictions imposed on the vendor do not automatically flow up to the model provider, the model provider's terms are almost always click-through and unseen by the customer, and the gap between what a vendor promises and what its upstream provider actually delivers is where the real exposure lives.
This How to Contract webinar was hosted by Laura Frederick, with Kay Lee, Head of Commercial at Recharge, taking the customer perspective, and Carly, Senior Director on a global commercial legal team at an e-commerce and fraud detection company, taking the vendor perspective. Both speakers actually negotiate inbound and outbound contracts in their day jobs, which meant the redlines on each clause came from people who have lived these provisions on both sides of the table rather than from a single vantage point.
The conversation worked through three AI-drafted provisions. The first covered feedback and user interaction data and the trapdoor language that makes those clauses leak. The second covered restrictions on vendor disclosure of customer prompts to the foundation model provider and the reframe from confidentiality to data flow. The third covered training data provenance documentation and the honest limits of what disclosure can deliver. Threaded through all three were drafting patterns that work and patterns that look protective but do nothing.
Here are our top ten takeaways from the speakers' comments during the webinar:
The foundation model layer is the layer most lawyers skip, and that is the problem. Customer-vendor focus is natural in any contract, but in AI product deals the upstream provider is doing real work and operating under its own terms we never see. Restrictions we put on the vendor do not flow upstream automatically. Assuming they do is the easiest way to give a client false comfort. The first move on any AI deal is to ask who is the foundation model provider, and what governs that relationship.
Catch AI vendors before they reach legal review. An AI governance policy with a preliminary set of security and legal questions saves real time and surfaces deal breakers early. We do not need a formal program to start. A spreadsheet works. The point is to keep contracts that should not move forward from getting deep into commercial review where everyone has already invested time.
Pair every list of restrictions with a list of permissions. AI product contracts are not the place for open-ended definitions with narrow exceptions. The technology and its use cases are too unsettled. Specifying what the vendor may do alongside what the vendor may not do forces both sides to think rigorously about the deal. That discipline is harder than leaning on broad language, and it produces better contracts.
Watch for "except as necessary to provide the services." This phrase in an AI product contract is a trapdoor. It can be made to swallow data uses the customer never contemplated, including upstream uses governed by the foundation model provider's terms. Kay called this kind of catchall a trick because it lets a third party's terms govern what looks like a vendor-customer commitment. The fix is an active list of what the vendor may disclose or use, with clear limits, rather than a broad permission with vague exceptions.
Do not let the vendor "ensure" anything about a third party. Vendors cannot ensure that a foundation model provider does anything, because the model provider's terms govern that relationship. Carly flagged this same pattern from the era when hosting providers were the big target, and the lesson carries over. The right verbs are softer commitments like taking reasonable steps or having policies designed to drive a particular outcome. This is a small drafting point with real consequences when something goes wrong and the customer tries to enforce the ensure against a vendor that never had upstream control to begin with.
Treat prompt disclosure as a data flow problem, not a confidentiality problem. Disclosure to the foundation model provider is a necessary evil for the service to work. The interesting question is what happens to the prompt after the inference is complete. Map the flow, get specificity on retention, and require update notifications when upstream terms change. Borrow the discipline from privacy and subprocessor management programs.
Do not sign clauses your client violates on day one. Foundation model providers legitimately use prompt data for debugging, abuse detection, logging, safety reviews, and compliance. A clause that limits use to "generating outputs in response to customer prompts" is unrealistic and creates immediate breach exposure. Carly's rule of thumb here is one to internalize. Aspirational restrictions that cannot be honored protect nobody and create real liability for the vendor on a contract that should never have been signed in that form.
The retention policy in the contract is the customer's, not the upstream provider's. Provisions that defer to the foundation model provider's data retention policies make the customer's protections only as strong as a third party's policy the customer never agreed to. Kay's redline here was structural. Either replace that deference outright with the customer's own retention terms, or add an active clause stating that the model provider's retention policy does not limit the contract's restrictions. Either way, bind the vendor not to accept upstream terms inconsistent with what the vendor owes the customer in this deal.
Training data provenance has real limits, and the contract should be honest about them. Provenance disclosure can flag personal information, unlicensed content, and other initial risks. It cannot prove a causal link between training data and a specific output, and significant pieces of the picture sit behind IP and trade secret protections at the foundation model provider. The vendor itself often does not know the full picture because the model provider may have bought parts of the training data from someone else. Adding an acknowledgment that foundation model providers are not fully transparent about training data documents the gap and supports enforceability of the rest of the clause.
A sole-remedy-of-termination clause that goes too far gets thrown out. US contract law expects a reasonable remedy to remain. Vendors that strip damages out too aggressively risk losing the entire limitation. A workable middle is to keep some damages exposure available but bound by a sensible cap, paired with the acknowledgment about provenance limits described above. Customers should not accept termination of an order form as the sole remedy where the exposure spans IP, regulatory, and operational risk.
Subscribe to Stay in the Loop
If this kind of practical AI contracting recap is useful, our weekly newsletter is built for that. Each issue points to upcoming How to Contract webinars and writeups like this one for past sessions. Subscribe now so the next one lands in your inbox.
