When you contract for an AI tool, you are rarely contracting with just one party. There is you, the vendor building the tool, and the third party model provider sitting underneath it all. That three-party reality shapes what you can ask for and what your vendor can promise.
In this conversation, Laura Belmont (GC at The L Suite), Matt Kohel (Partner at Saul Ewing), and I work through the core concepts for drafting AI model governance provisions. We cover the vendor perspective, the customer perspective, and where the two sides can find practical middle ground.
Why these provisions are harder than typical software provisions
Laura kicked off the discussion by pointing out how AI contracting differs from traditional software contracting in three important ways.
First, the flow-down problem. Vendors building on top of frontier models cannot promise customers more than their own contracts with those model providers allow. Customers need to recognize this constraint when they push for transparency.
Second, the black box. Much of what sits inside a model stays proprietary. Training data sets, weighting, fine tuning approaches. Even when a vendor wants to share, there are limits to what they can show you.
Third, AI is dynamic. Traditional software follows a "set it and forget it" pattern. AI models retrain, get swapped out, and shift in performance over time. Contract language built around a single point-in-time snapshot will not hold up.
The vendor view
Matt walked through the tensions vendors face when negotiating these provisions.
Broad cooperation obligations with no end date or cost structure create real problems for vendor teams. Engineers have limited bandwidth. Customers may ask for documents that do not exist or information the vendor cannot share because of its own contracts with the model provider.
Vendors can offer meaningful information without overpromising. Model cards identify the model and its known limitations. Bias audits and model drift testing speak to categories of risk. The goal is matching the customer's actual concerns rather than handing over everything they think they want.
We also floated a small campaign during the discussion. Replace "reasonable" with "thoughtful" in your contracts. It sets a different tone.
The customer view
Customers often ask for full transparency without thinking about what they would actually do with it. Most of us do not want to choose models for our vendors. That is why we hired the vendor in the first place.
What customers actually need from the contract:
Performance thresholds and accuracy commitments
A commitment that the vendor is not training on customer data
Clear data retention policies
Notice of material changes to the underlying model or provider
A real cooperation mechanism, not just a support chat bot
The subprocessor list and separate technical documentation can carry the specific model details. The contract should lock in the buckets that matter when something goes wrong.
Lesson: Cooperation may matter more than transparency
When a model drifts or results stop matching expectations, you need a person to call. Not a help desk. Not a chat bot. A real point of contact who can work through the issue with you. That is why cooperation provisions deserve careful drafting. The black box nature of models makes the relationship with your vendor more important, not less.
Subscribe to Stay in the Loop
Want more like this? Subscribe to How to Contract’s mailing list for practical guidance on AI contracts, vendor agreements, and commercial contracting in the real world.
