Most clients who've been burned by an AI development project can point to a contract clause that should have been a warning. They didn't know what to look for at signing. By the time the problem surfaced, it was expensive to fix.
These are the six clauses that show up repeatedly in problematic engagements, what the red flag actually looks like, and what to ask for instead.
1. Vague deliverable definitions
What it looks like: "Vendor will deliver an AI system for automating customer support inquiries."
That sentence says almost nothing. What does "AI system" mean? What requests does it handle? What's the expected accuracy? What infrastructure does it run on? What format is the deliverable in?
Vague deliverable definitions are a setup for scope disputes. When you think "working AI system" means handling 90% of inquiries automatically and the vendor thinks it means a system that technically responds to all inquiries (even if most get kicked to humans), you have a problem that no one can resolve cleanly.
What to ask for instead: The contract should reference a technical specification that defines deliverables in measurable terms. At minimum: the specific use cases covered, quantitative quality thresholds (task completion rate, accuracy on a defined eval set), the integrations included, and the deployment environment. "AI system for automating customer support" becomes "RAG-based support chatbot handling billing, account, and shipping inquiries with recall@5 above 85% on the attached evaluation set, deployed to AWS Lambda, integrated with Zendesk."
2. Ambiguous IP ownership
What it looks like: "Vendor grants Client a perpetual license to use the developed software."
A license is not ownership. You are not receiving the IP — you are receiving the right to use it. This means the vendor retains ownership of the code, can resell it to your competitors, can revoke the license under certain conditions, and controls what you can modify or extend.
This matters more in AI development than in traditional software development because the "software" includes prompt libraries, fine-tuned model weights, evaluation harnesses, and custom tooling that are valuable and specialized. A license to use these is significantly less valuable than owning them outright.
What to ask for instead: "All work product created under this agreement, including but not limited to source code, prompts, documentation, evaluation test cases, and any custom model weights, shall be the sole and exclusive property of Client upon payment in full." Full assignment, not a license.
3. Open-ended time and materials on ambiguous scope
What it looks like: "Billing at $X/hour against a not-to-exceed estimate of $Y."
Time and materials isn't inherently a red flag — it's appropriate when scope genuinely can't be determined upfront, such as in a discovery phase or a research project. The red flag is T+M on a project that should have a defined scope.
An estimate is not a cap unless the contract says it is. "Not-to-exceed" language helps but it creates a perverse incentive: once the vendor is close to the ceiling, they either absorb overruns (and do so resentfully, affecting quality) or surface a scope change to justify exceeding it.
What to ask for instead: Fixed-price with a defined scope for the build phase. Discovery and architecture can be T+M because the outputs of those phases define the build scope. Once you have a spec, price the build against it. Change request process for any scope additions.
4. Data usage rights for model training
What it looks like: "Vendor may use inputs and outputs from the system to improve its AI products and services."
This clause, or something like it, has appeared in AI vendor contracts in various forms. What it means: the vendor can use your proprietary business data — your customer conversations, your internal documents, your workflows — to train their models. Those models then benefit other customers, possibly including your competitors.
For most businesses, this is unacceptable. For businesses with proprietary data that is genuinely valuable — legal firms, financial institutions, healthcare organizations — it can be a material IP risk.
What to ask for instead: Explicit prohibition on use of your data for model training. "Vendor shall not use any data provided by Client, or any inputs or outputs from the system, to train, fine-tune, or improve any AI model, whether proprietary or third-party, without Client's prior written consent."
5. Lock-in through proprietary platform dependencies
What it looks like: "The system will be built on VendorName's AI platform, subject to VendorName's standard platform terms."
Some AI development agencies build on their own platforms — proprietary orchestration layers, custom vector stores, or agent frameworks that only run on their infrastructure. This is not inherently wrong; some platforms are genuinely useful. But it creates a dependency: if you want to migrate away from the vendor, you may not be able to take your system with you.
What to look for: Does the vendor use open-source or standard infrastructure (LangChain, LlamaIndex, standard cloud services, open vector databases)? Or does the contract reference a proprietary platform you've never heard of? Can you run the system independently after handoff, without the vendor's proprietary software?
What to ask for instead: Systems built on open-source or standard cloud components where you own the infrastructure. The contract should specify that the delivered system can be run independently by Client without any ongoing dependency on Vendor's proprietary software.
6. Undefined maintenance and support scope
What it looks like: Nothing in the contract about what happens after launch.
AI systems degrade over time in ways traditional software doesn't. The LLM provider may change their model behavior in an update. Your knowledge base becomes stale as your product changes. Prompt engineering that worked at launch may not work with the same quality six months later. An LLM system that launches well and receives no attention will not perform as well in six months.
If the contract is silent on post-launch support, you have no recourse when things degrade and no path to get the vendor to fix them.
What to ask for instead: A defined warranty period (30–90 days) during which the vendor fixes defects at no charge. A clear definition of what counts as a defect versus a new feature request. Optional maintenance support scope (knowledge base updates, prompt iteration, model version updates) with specific hourly or monthly pricing.
The meta-point
These clauses appear in contracts from legitimate vendors — not just bad actors. Vague deliverable definitions happen because both parties are optimistic and don't want to slow down the process with detail. Ambiguous IP ownership happens because legal templates from one context get reused in another. T+M on ambiguous scope happens because the vendor doesn't know how long it will take.
The value of reviewing these clauses before signing is not to assume bad intent — it's to create shared understanding of what you're buying before money changes hands.
If you're evaluating an AI development engagement, our process page covers how we structure contracts and what you'll own at the end of the project. Alternatively, reach out directly and we can walk through your specific situation.