A 2026 fixed-price AI MVP contract has roughly thirty clauses. Seven of them carry most of the structural risk. A non-technical founder who can hold a counter-position on those seven preserves the negotiating power they paid for when they chose fixed-price; signing them as drafted gives that power back inside the first week. This is the clause-by-clause guide for the moment between proposal and counter-sign: which seven clauses to fight, what good looks like, the vendor’s typical objection, and the language that holds the line.
This is the negotiation-side companion to what a defensible fixed-price AI MVP scope looks like, sitting inside the AI MVP economics playbook as the procurement-edge spoke. The upstream pricing-model decision is treated in AI MVP pricing explained; the operational follow-on once contracted is the AI agency change-order playbook. The full non-engineer-led idea-to-product frame is in the idea-to-product manifesto.
Why these seven
A typical fixed-price AI MVP SOW in 2026 runs to roughly thirty clauses across the MSA and SOW. Most are boilerplate. Seven clauses do most of the work:
- Scope freeze and change-order policy — what counts as a change.
- IP ownership of prompts, eval sets, and runtime artifacts — what the founder owns at handover.
- Eval acceptance criteria — when the partner has delivered.
- Hallucination budget and liability allocation — who eats the cost of model failure.
- On-call window and severity-1 response — the support envelope after launch.
- Kill-switch and exit clause — what happens if the engagement fails.
- Payment milestones tied to eval-graded acceptance — when the partner gets paid.
BCG’s 2024 Where’s the Value in AI? reported 74% of corporate AI investments fail to scale beyond proof-of-concept. McKinsey’s State of AI work named scope discipline and acceptance criteria as the two largest gaps between the 26% that scale and the 74% that don’t. Engagements that ship on budget tend to have negotiated these seven; engagements that overrun tend to have signed them as drafted.
Each clause below follows the same four-part structure: what good looks like, what to push back on, vendor’s typical objection, and the response that holds the line.
Clause 1 — Scope freeze and change-order policy
The most consequential clause in the contract. Without a strict version, every mid-engagement conversation becomes a re-negotiation, and the fixed price functions as a floor.
What good looks like. A scope freeze at SOW execution naming one feature, one persona, one task, one primary model, plus a change-order policy distinguishing three categories:
| Category | Definition | Effect on price |
|---|---|---|
| Clarification | Resolves ambiguity without changing scope | No change order |
| Trade | Swaps one in-scope item for another of equivalent effort | Logged change order; no fee adjustment |
| Change | Adds scope, expands the eval set, or changes the named feature | Priced change order at published rate-card tier |
A 2026-typical rate card prices each priced change at $5K (small), $15K (medium), or $40K (large), each tier defined by eval-set delta and engineering-week delta. Include the rate card in the SOW.
What to push back on. “Any modification at the discretion of the partner constitutes a change order” — gives the partner unilateral classification rights. Also strike: “the partner may at its discretion incorporate minor changes within the fixed fee” — absorbed favors compound into a 30%-plus overrun argument by M3.
Vendor’s typical objection. “This is too rigid. AI projects discover scope as they go.”
Response that holds the line. “That is exactly what the three-category taxonomy is for. Clarifications and trades are unrestricted. We’re freezing the price, not the discovery. If we need a fourth feature in week three, that’s a change order at the published rate.”
Clause 2 — IP ownership of prompts, evals, and runtime artifacts
The most portable artifacts in a 2026 AI MVP are not the application code — they are the prompts, the eval set, and the runtime configuration. A partner who retains these as their IP retains a soft form of vendor lock-in after the engagement ends.
What good looks like. Full ownership at handover of: (1) application code, (2) prompt library and prompt-engineering documentation, (3) eval set with labeled cases, rubric, and grader code, (4) runtime configuration including model selection, retry logic, and observability instrumentation, (5) training data and annotations produced under the engagement. Open-source components stay under their licenses; the partner’s general toolkits (internal libraries that predate the engagement) stay the partner’s IP. The carve-out is sharp: engagement-specific artifacts transfer; general-purpose tooling does not.
What to push back on. “All prompts and evaluation materials remain the property of the partner.” Also: “the partner grants the founder a non-exclusive, perpetual license to use the prompt library.” A license is not ownership.
Vendor’s typical objection. “Our prompt library is our methodology. We can’t transfer ownership without giving away the core of how we deliver value.”
Response that holds the line. “Your general methodology stays with you. I’m asking for ownership of the specific prompts written for our specific feature against our specific eval set. Those have no value outside our use case. If you can’t transfer ownership of artifacts that exist only because of our engagement, we’re not buying a build — we’re renting access to your IP. Different deal, different price.”
Clause 3 — Eval acceptance criteria
The structural mechanism that decides whether the partner has delivered. Without a defined eval acceptance gate, the engagement converts to time-and-materials by default the moment quality becomes contested.
What good looks like. An eval set with three properties, all named in the SOW: (a) size — typically 100–250 labeled cases for a 6-week MVP; (b) labeling authority — the founder writes and approves the rubric, with partner support; (c) threshold — a single pass rate against a named rubric (e.g., “at least 85% of cases scored ‘pass’ on the four-criterion rubric attached as Appendix B”). The rubric and threshold are negotiated before the build starts.
What to push back on. “Deliverables will be accepted upon demonstration of working functionality” — converts the test from graded eval to demo. Also: “the partner will determine eval methodology and threshold in consultation with the founder” — consultation is not approval.
Vendor’s typical objection. “AI evaluation is an emerging discipline. Locking in a numeric threshold before we’ve seen the model behavior creates artificial constraints.”
Response that holds the line. “The team has a structural incentive to call the model ready when it’s good enough to ship. The eval threshold is the founder-side referee. We can set it at a deliberately achievable level — 85% against a rubric we both write — but it has to be a number, and it has to be in the SOW.”
Clause 4 — Hallucination budget and liability allocation
A 2026 AI MVP that calls a frontier model in production will produce occasional incorrect, fabricated, or off-policy outputs. Anthropic and OpenAI both publish public guidance on grounded-refusal rates and hallucination characteristics. The clause that allocates the cost of these failures is the one most often missing entirely from the partner’s draft.
What good looks like. Three components: (1) a hallucination budget — an acceptable failure rate against the eval set or per-1,000 production queries (typical 2026 ranges: 1–3% for low-stakes generative use cases, below 1% for high-stakes ones, the latter usually requiring guardrail architecture rather than a tighter raw budget); (2) a failure-mode taxonomy distinguishing hallucination, refusal, off-policy, and latency failures; (3) a liability allocation, typically capped at the fixed fee for engagement-period failures.
What to push back on. “The partner makes no warranty as to the accuracy, completeness, or fitness of any model output.” Not negotiable in absolute form — but the unconditional version concedes too much. Also strike: “the founder assumes all risk and liability arising from the use of model outputs.”
Vendor’s typical objection. “We can’t warrant model accuracy. We don’t control the model. Anthropic and OpenAI don’t warrant their own models — we can’t be on the hook for their behavior.”
Response that holds the line. “You can’t warrant the model. What I’m asking you to warrant is your work: the prompts, the eval rubric, the guardrails, the retry logic, the observability. If our hallucination rate exceeds the budget we agreed on in eval acceptance, that’s a defect in your work. You either fix it under the warranty period or refund the corresponding milestone.”
Clause 5 — On-call window and severity-1 response
The 30-day post-launch period is when most production AI defects surface — when the eval set meets real traffic and the unlabeled edge cases appear in volume. A founder without a contracted on-call window pays T&M rates for the most defect-rich part of the engagement.
What good looks like. A defined on-call window — typically 30 days from launch — with: (1) severity classification (sev-1 = production-down or systemic hallucination above the budget; sev-2 = degraded but functional; sev-3 = minor); (2) response time for sev-1 (typically 4 business hours first-response, 2 business days resolution); (3) coverage hours — single-shift business hours; 24/7 is a different engagement at a different price.
What to push back on. “The partner will provide reasonable post-launch support for thirty days” — reasonable is undefined. Also strike: “additional support is billable at the partner’s then-prevailing hourly rate” — lock the rate in the SOW.
Vendor’s typical objection. “We don’t know what defects will surface. Committing to a fixed resolution time for issues we haven’t seen yet is too open-ended.”
Response that holds the line. “The classification is what makes this manageable. We’re committing to response times for severity-1 only. Sev-2 and sev-3 run on longer windows or change orders. A thirty-day open promise to be reasonable means the partner decides what reasonable looks like the morning the issue happens.”
Clause 6 — Kill-switch and exit clause
The clause most partners hope the founder forgets to ask for. It defines what happens if the engagement fails — missed milestones, unachievable eval acceptance, or a founder pivot that retires the build.
What good looks like. A three-trigger exit clause: (1) for-cause termination by the founder if the partner misses a milestone by more than 14 days or fails eval acceptance after two correction cycles, with pro-rated refund of unearned milestones plus immediate transfer of all engagement-specific IP; (2) for-cause termination by the partner if the founder fails to provide named inputs by named dates after notice and cure period, with the partner retaining completed milestone payments; (3) for-convenience termination by the founder for any reason, with payment of all completed milestones plus a wind-down fee (typically 50% of the next unstarted milestone) and full IP transfer. Without the IP transfer at exit, a terminated engagement leaves the founder with no application code, no prompts, no eval set — they have paid for work product they cannot use.
What to push back on. “This agreement may be terminated by either party with 30 days written notice” — sounds neutral but favors the partner. Also strike: “all work product remains with the partner until full payment of the SOW value.”
Vendor’s typical objection. “We’re a small shop. If founders can terminate for convenience with partial payment, we can’t run a business.”
Response that holds the line. “The wind-down fee is the structural answer. The for-cause triggers protect both of us. What this clause prevents is the worst-case scenario where the engagement is failing and neither side has a clean exit — that ends in mediation, not in your bank account.”
Clause 7 — Payment milestones tied to eval-graded acceptance
The default 2026 fixed-price payment structure is calendar-based: 30% on signature, 35% at week three, 35% at week six. It pays the partner on time elapsed, not work delivered. A founder who has negotiated the previous six clauses and then signs a calendar-based payment schedule has given back most of the structural power from those negotiations.
What good looks like. A payment structure tied to milestones, each defined by an eval acceptance event:
| Milestone | Payment | Acceptance criterion |
|---|---|---|
| SOW execution | 20% | Signature |
| Eval set delivered + scoped baseline | 20% | Founder sign-off on rubric and threshold |
| MVP feature shell + first-pass eval run | 30% | Eval pass rate at or above 60% against the agreed rubric |
| Production-ready milestone | 25% | Eval pass rate at or above the contracted threshold; observability, on-call docs, and IP handover complete |
| 30-day on-call period close | 5% | No open sev-1 issues at day 30 |
What to push back on. “Payment milestones are based on calendar-week delivery of work in progress.” Also strike: “milestone acceptance is at the partner’s reasonable determination.”
Vendor’s typical objection. “Our cash flow has to track our engineering spend. We can’t run the engagement if 60% of the fee is held against a single eval-acceptance gate at week five.”
Response that holds the line. “The structure front-loads 40% by week one — signature plus eval set delivery — which covers your team setup. The 25% production-ready milestone is large because that’s where the engagement either ships or doesn’t. If the cash-flow shape doesn’t work, we can move 10 points to a calendar-based week-three milestone, but the eval-gated structure stays.”
Without Clause 7, the previous six soften.
The 72-hour counter-sign procedure
Every hour spent negotiating these seven clauses is worth roughly one day saved in mid-engagement re-negotiation later.
- Read the draft once, in full, without marking it up. Get the shape of the deal in your head before reacting to specific language.
- Inventory the seven clauses — mark which are present, absent, or present in a weaker form than this article describes.
- Score each present clause against what good looks like and write the specific phrase to strike and the response to the vendor’s likely objection.
- Decide the order of negotiation. Lead with Clauses 1, 3, and 7 because they have the largest dollar effect. Hold Clauses 2 and 6 as non-negotiables.
- Send the counter-sign in track-changes — marked-up SOW, not a long email.
- Expect a two-round negotiation. A negotiation that takes more than two rounds is signaling a structural mismatch worth listening to.
FAQ
Is this too founder-favorable? Won’t good partners walk?
The clauses are tight but not asymmetric. Each has a partner-side counterpart: the change-order taxonomy formalizes when the partner gets paid for extra work; IP carve-outs preserve general methodology; eval acceptance gives the partner a clear definition of done; the kill-switch protects the partner against founder-side input failures; payment milestones front-load 40% in week one. A partner who walks from this language is signaling a service model that depends on ambiguity to be profitable.
Do I need a lawyer to negotiate this?
Outside counsel adds value for the boilerplate clauses (governing law, indemnification, liability caps) and for the IP language in Clause 2. For the AI-native clauses, most counsel are not yet specialized enough to add value beyond the seven-clause framework. The right division: counsel reviews the MSA and IP transfer language; the founder negotiates the seven clauses directly.
What if the partner says all of this is in their template already?
Verify against the actual language. The diagnostic question per clause: does the language commit the partner to a specific behavior, or preserve partner discretion? “Three-category taxonomy” commits; “changes at partner discretion” preserves discretion. The difference is the entire negotiation.
Should the eval acceptance threshold be the same for every AI MVP?
No. The 85% threshold is a 2026 reference point for general-purpose generative or extraction use cases against a 100–250 case eval set. Low-stakes generative may pass at 80%, classification tasks may need 90% or higher, regulated use cases typically need guardrail architecture rather than a tighter raw threshold. The structural point is that there is a threshold, named in the SOW, before the build starts.
What if the partner offers a discount in exchange for softer clauses?
Decline. The 5–10% discount typically offered is meaningfully smaller than the 30%-plus overrun the clauses prevent. The discount-for-softness trade is the partner’s most common counter-move; acknowledge it, decline it, re-anchor.
How does this interact with milestone-based pricing (not fixed-price)?
Most of the seven apply equally. Clause 7 is the structural form milestone-pricing already uses, so the negotiation focuses on the acceptance criteria rather than the payment shape. Clause 1 relaxes slightly because the smaller milestone scope absorbs minor changes more naturally. The other five are unchanged.
What’s the single most undervalued clause of the seven?
Clause 7. The other six are enforceable only because the founder retains payment power at the structural acceptance gate. If forced to negotiate only one, negotiate this one — it is the structural keystone.
What if we’ve already signed and we’re three weeks into the build?
The structural moves narrow but remain real: you can propose a change-order taxonomy (Clause 1) as a written addendum, negotiate the eval acceptance threshold (Clause 3) as a sub-agreement, and negotiate the on-call window (Clause 5) before launch. The smallest in-flight room is in Clauses 2, 6, and 7 — set at signature. The operational playbook is treated in the AI agency change-order playbook.
Arthur Wandzel
