Fixed-Scope AI Contracts: A Buyer's Clause-by-Clause Guide

Companies evaluating AI outsourcing projects often invest heavily in comparing technical proposals, only to rush through the contract review stage. AI project contract risks differ from standard software development: model behavior is difficult to quantify, deliverable boundaries are easily blurred, and downstream API cost structures are not always transparent. The following breaks down eight core clauses a fixed-scope AI contract should cover, with an explanation of each clause's practical impact on buyers.

1. Scope Definition Must Reach the Feature Level

The core premise of any fixed-scope contract is that both parties agree in writing on what "done" means before work begins.

A typical vague scope statement: "Build an AI system that can answer customer questions." This type of description cannot serve as an acceptance benchmark.

An executable scope definition should specify:

• Input sources: Which file formats, maximum file size, supported data sources
• Output format: Plain text replies, structured JSON, Telegram messages, etc.
• Language support: Chinese, English, whether Cantonese queries are supported
• Concurrency limits: Maximum simultaneous users the system is designed to support
• Explicit exclusions: A list of features not included, not just what is included

Without a clear scope definition, any additional requirement can become a dispute: the contractor considers it out of scope, while the buyer assumed it was always included. A clear exclusions list often provides as much legal protection as the inclusions list.

2. The Deliverables List Determines What You Actually Receive

The contract should enumerate each deliverable item by item, rather than describing the work as simply "completing the system." A complete deliverables list typically covers three layers:

3. Milestone Payment Structure Should Be Tied to Deliverables

The payment structure for a fixed-scope project directly determines how risk is distributed between the parties. Common high-risk structures include paying the full amount or a large deposit upfront, or tying the final payment to "buyer satisfaction" — the former shifts all risk to the buyer; the latter creates disputes by using a subjective standard as a payment trigger.

A recommended three-stage structure that ties each payment to verifiable deliverables:

Acceptance criteria should be objective and quantifiable — for example: "Correct field extraction rate of 85% or above across 20 provided test documents" — rather than "the system works." Using subjective satisfaction as an acceptance standard is difficult to arbitrate in any actual dispute.

4. Source Code Handover Terms Are the Decisive Factor for Long-Term Costs

This clause's long-term impact on the buyer often far exceeds the initial development cost. The contract should explicitly state: the exact point at which source code is transferred (typically after final payment is cleared), the method of transfer (private Git repository access, compressed archive delivery), and that intellectual property belongs to the buyer with no usage license retained by the contractor.

AI projects require special confirmation of ownership across the following layers:

• Application-layer source code
• Custom system prompts
• Adjusted RAG chunking logic
• Embedding data in the vector database (if applicable)
• Fine-tuned model weights trained on buyer data (if applicable)

For a complete framework on source code handover: Why Source Code Handover Matters: Core Buyer Protection Clauses.

5. LLM API Cost Attribution Must Be Defined During the Contract Period

Fixed-scope development costs are one-time; LLM API costs are ongoing and variable. The contract should clearly define:

During the development period (within the contract term): Which party bears API costs; whether there is a usage cap and how overages are handled.

After delivery (outside the contract term): The buyer operates the system using their own API keys; monthly cost estimates based on projected usage and model pricing.

If the system uses multiple LLM providers (a primary model plus a fallback), billing attribution for each provider should be included in the contract. Which provider's API is ultimately used in production should be confirmed in writing before delivery, to avoid the buyer discovering after handover that they need to register for multiple API accounts.

6. Change Request Mechanism Prevents Scope Creep

Common disputes in fixed-scope contracts stem from disagreement on whether something is a modification within the original scope or a new requirement. The contract should include an explicit Change Request process:

• The buyer submits requirement changes in writing
• The contractor responds in writing within the agreed timeframe (typically 3 business days): whether it falls within the original scope, and an additional hours estimate
• Both parties confirm in writing before proceeding, or decide not to proceed
• Verbal requests without written confirmation do not constitute a delivery obligation for the contractor

Contracts without this mechanism tend to evolve into a situation where both parties dispute the scope of work in the later stages of the project.

7. Warranty Period Terms Define Post-Delivery Responsibility Boundaries

Edge cases appearing in the initial operation of an AI system after delivery are normal. The contract should specify:

• Warranty period length: Typically 30 to 60 days after delivery
• Warranty scope: Defect fixes within the original delivered functionality only, not new feature development
• Response times: Classification of critical issues (system inoperable) versus general issues, and maximum resolution times for each
• Post-warranty maintenance: Whether it is offered and how it is billed

After the warranty period, if the buyer requires ongoing technical support, a separate maintenance contract should be signed rather than extending the responsibility scope of the original fixed-scope contract.

8. Five Questions to Confirm with the Contractor Before Signing

Regardless of how the contract clauses are written, it is worth directly confirming the following with the contractor before signing:

1. Does the source code handover include all prompts and RAG settings? Ask the contractor to provide a complete handover checklist.
2. Who defines the acceptance criteria? If the contractor defines them unilaterally, a conflict of interest exists.
3. If the project terminates early, which specific deliverables correspond to payments already made? Each milestone should have independent deliverable outputs.
4. Which third-party services does the system depend on? The replaceability and cost structure of each service should be understood in advance.
5. Is documentation written by the contractor, or compiled by the buyer? If the contract does not specify, documentation often becomes a dispute point later.

The core protection logic of a fixed-scope contract is: tying each payment to a specific, verifiable deliverable, so that regardless of which stage the project ends at, the assets the buyer holds are commensurate with the amount paid. The clauses themselves do not need to be complex, but each one must be specific, measurable, and confirmed in writing by both parties before the contract takes effect.

Further reading: Fixed-Scope vs. Time-and-Material: How to Pay for AI Projects · How to Evaluate an AI Vendor Proposal