Most AI development partnership contracts in 2026 say “you own everything,” and most founders sign without asking what “everything” actually contains. Then offboarding arrives. The source code is in the founder’s GitHub. The prompts that make the code work live in the partner’s Cursor history. The eval set that proves the system behaves sits in the partner’s W&B project. The fine-tuned weights are pinned to the partner’s Hugging Face account. The OpenAI API key on the production deployment is the partner’s enterprise contract, not the founder’s. The founder owns roughly 15% of what they paid for, and only learns the percentage when they try to leave.
The fix is not a better lawyer. It is a clearer mental model. A 2026 AI engagement produces six distinct IP categories, and a default partnership contract treats each one differently. This piece walks through all six, the default treatment in a typical 2026 partnership SOW, and the specific clauses a founder should insist on before signing.
For the full picture, see the founder-AI-partner operating manual, the guide for non-engineer founders running an AI MVP build, within the broader idea-to-product manifesto for non-engineers shipping AI products.
Why “you own the code” is not the same as “you own the system”
A traditional software build produces one IP artifact that matters: source code. A 2014-era MSA could say “Client owns all Work Product upon payment” and that single sentence covered 95% of the value of the engagement. The remaining 5% — design files, documentation, deployment scripts — was either copy-pasted along with the code or trivial to re-create.
An AI build does not work that way. The source code is a thin scaffold. The behaviour of the system depends on five other artifact classes, and four of them are not “code” in any sense the 2014 clause contemplated. The prompts are configuration. The eval set is data. The fine-tuned weights are the output of a training loop on someone else’s base model. The vendor SLA is a third party’s terms. The operational data is a continuous stream that started flowing the day the system went into production.
A founder who walks away with the GitHub repo but none of the other five categories has the equivalent of a car with no fuel, no key, and no proof of ownership. The technical answer to “can I keep running this?” is yes — but only because the partner is still paying the OpenAI bill on a key bound to their corporate entity and still hosts the eval harness on their infrastructure. The day the partner shuts off the key, the founder discovers what they actually own.
The frame to internalise: in a 2026 AI partnership, the source code is the smallest of the six IP categories by economic value. Trying to extend a 2014-style “you own all code” clause to the other five is the most common contract failure mode in the program.
The six IP categories in a 2026 AI partnership
The six categories below appear in every AI development partnership engagement, whether or not the contract acknowledges them. The first column names the category. The second names what it physically is. The third names the default treatment in a typical 2026 boutique-partner MSA — i.e., what happens if the founder does not negotiate.
| # | Category | What it physically is | Default treatment (un-negotiated) |
|---|---|---|---|
| 1 | Source code | The application repo: API handlers, database schemas, frontend, integration glue | Assigned to founder on payment (this is the only category 2014-style clauses get right) |
| 2 | Prompts | System prompts, few-shot examples, prompt-registry version history | Often un-named in the contract; lives in partner’s Cursor / Langfuse / private repo |
| 3 | Eval set + rubric | Graded test cases, scoring rubric, baseline numbers | Un-named; lives in partner’s W&B / Braintrust / Inspect AI workspace |
| 4 | Fine-tuned weights | LoRA adapters, full fine-tunes, distilled models | Un-named; pinned to partner’s Hugging Face / S3 / vendor workspace |
| 5 | Vendor SLA pass-through | The OpenAI / Anthropic / Google enterprise terms protecting the system | Held by partner; founder inherits a degraded operational SLA |
| 6 | Training / operational data | Production logs, traces, user feedback, training corpus | Un-named; sits in partner’s observability stack |
Two patterns to notice. First, only category 1 has a default treatment that protects the founder. Categories 2–6 default to either silence or to the partner’s infrastructure. Second, the silence is structural — most MSA templates do not list these categories at all, so the default is not “shared” or “vendor-owned”, it is “undefined”. Undefined favours the party that physically holds the artifact, which is always the partner.
The next six sections walk through each category, the failure mode if it stays un-negotiated, and the specific clause language a founder should insert. Treat these as starting points to bring to counsel, not as drop-in contract text.
Category 1: Source code
This is the only category that 2014-style contract clauses handle cleanly. A standard “all Work Product is assigned to Client upon payment of fees” clause covers the application repo, the database migrations, the frontend, and the deployment scripts. If a partner pushes back on a clean assignment of code, that is itself a red flag and the engagement is unlikely to be a real partnership.
Three nuances still matter.
Open-source dependencies. The codebase will pull in MIT, Apache 2.0, BSD, and GPL libraries. The clause should make clear that “Work Product” excludes upstream open-source code (which remains under its own licenses) but includes any modifications the partner makes to fork those libraries.
Pre-existing partner tooling. Many boutique partners bring an internal “scaffold” — eval harness boilerplate, deployment templates, common prompt-evaluation utilities. The contract should explicitly grant the founder a perpetual, royalty-free, sublicensable license to use any pre-existing tooling embedded in the delivered system, even if the partner retains underlying ownership.
Delivery format. “Assigned on payment” means nothing if the founder cannot get the code. The clause should specify the delivery mechanism: a git repository under the founder’s organisation, accessible on the closing date, with the full commit history, branches, and tags intact.
Clause to insist on (paraphrase, not legal text):
All source code authored by the Partner in performance of the Statement of Work is hereby assigned to Client upon payment, excluding upstream open-source dependencies and Partner Background IP. Partner grants Client a perpetual, worldwide, royalty-free, sublicensable license to any Partner Background IP embedded in the Deliverables. Code is delivered as a git repository under Client’s GitHub organisation on the Closing Date, with full commit history.
Failure mode if you skip this: rare in 2026, but where it happens, the partner delivers a zipped tarball of the latest commit and keeps the history (which includes the prompt-iteration commits the founder needs to understand the system) on their internal GitLab.
Category 2: Prompts and prompt registry
Prompts are the single most under-specified IP category in 2026 partnership contracts. They are not “code” in the conventional sense — they are configuration strings that determine 60–80% of the system’s behaviour. A skilled prompt-engineer typically spends 3–5 days of an eight-week build iterating on the system prompts. That work product rarely shows up in a default work-product clause because the clause is thinking about typed code, not configuration files.
Where the prompts physically live matters. Three common patterns:
- Inline in the codebase. The cleanest case. Prompts sit in a
prompts/directory as plain text or YAML, version-controlled with the rest of the code. They flow through the source-code assignment clean. - In a third-party prompt registry. Langfuse, PromptLayer, LangSmith, Helicone. The prompts are technically the founder’s, but accessed through the partner’s account on the registry. If the partner offboards without exporting them, they are recoverable only by re-paying the partner.
- In the partner’s Cursor / Claude Code history. The worst case. The prompt that ended up in production is one of forty variants the partner tried — the lineage and reasoning live in the engineer’s IDE history. Nothing transfers.
Clause to insist on:
All prompts, prompt templates, few-shot examples, and prompt-registry version histories authored by the Partner in performance of the Statement of Work, including all prior iterations preserved in version control or third-party prompt-registry tooling, are deliverables assigned to Client on payment. Prompts must be delivered in a version-controlled directory inside the source-code repository on the Closing Date, with the full revision history of each prompt.
Failure mode if you skip this: the founder gets the current production prompt but loses the iteration history. Six months later they want to improve the system; they no longer remember which variants were tested or why the current one was chosen. They re-discover the work from scratch.
Category 3: Eval set and rubric
The eval set is the load-bearing IP of a 2026 AI engagement. Founders are told to fight for “the model.” The model in most builds is GPT-5, Claude Opus 4.8, or Gemini 2.5 Pro — vendor-owned, not the founder’s, regardless of contract language. The eval set is what differentiates this founder’s deployment of those models from any other founder’s. It is the proof that the system meets a specified quality bar, and it is the artifact that lets the founder swap out the underlying model in 12 months without re-doing the entire engagement.
A real eval set has four parts:
- The graded test cases. Inputs paired with expected outputs (binary pass/fail) and / or rubric-scored outputs (1–5 on multiple dimensions).
- The rubric document. Plain-English description of what each dimension scores, with anchor examples.
- The baseline numbers. Pass rate at handoff on the current model, with confidence intervals if the eval set is small.
- The eval-harness code. The scaffolding that actually runs the evals — Inspect AI, OpenAI Evals, custom harness — and the regression-detection logic.
The Stack Overflow Developer Survey 2025 found that fewer than 30% of AI engineers ship to production with a formal eval set, which means that founders who insist on owning theirs are walking out of the engagement with a strictly more valuable system than the median 2026 deployment.
Clause to insist on:
All eval datasets, rubric documents, baseline performance reports, and eval-harness code authored or curated by the Partner in performance of the Statement of Work are Client Work Product, assigned on payment. Eval artifacts are delivered as a version-controlled directory inside the source-code repository on the Closing Date, including the harness code, the graded test cases, the rubric document, and a baseline pass-rate report.
Failure mode if you skip this: six months post-launch the founder wants to switch from Claude Opus 4.8 to Gemini 2.5 Pro to cut inference cost. Without the eval set, the migration becomes “ship it and hope”. With the eval set, it becomes “re-run the harness on the new model and ship if the pass rate holds.” The eval set is the difference between a founder who can choose their model vendor and a founder who is locked to whoever the partner originally picked.
See the hidden Y problem in AI agency contracts: who owns the model weights? for the clause-by-clause version of this argument written for buyer-side counsel rather than founders.
Category 4: Fine-tuned weights and adapters
Not every partnership produces fine-tuned weights. Most 2026 boutique partnerships are built on prompt engineering plus retrieval against a vector store, with no fine-tuning at all. When a partnership does fine-tune, weights become the most legally entangled category in the contract because they exist under two licenses simultaneously: the partnership IP clause, and the base-model license.
Three common fine-tune shapes:
| Fine-tune type | Storage form | Base-model license entanglement |
|---|---|---|
| Full fine-tune of an open-weight base | Full set of model parameters | Llama, Mistral, Gemma, or Qwen license flows through; derivative-distribution terms apply |
| LoRA / QLoRA adapter | Adapter weights only (often under 1% of base size) | Adapter is technically separable; in practice useless without the licensed base model |
| Hosted fine-tune (OpenAI, Anthropic, Google) | Snapshot ID on vendor’s infrastructure | Cannot be exported; vendor terms of service govern entirely |
Hosted fine-tunes are the trap. OpenAI’s fine-tuning terms grant the customer ownership of the resulting model snapshot, but the snapshot is not portable — it lives on OpenAI infrastructure and is callable only through OpenAI’s API. If the partner is the OpenAI customer of record, the snapshot is on the partner’s account, not the founder’s. The founder owns a model they cannot directly access.
Clause to insist on (only relevant if the engagement includes fine-tuning):
All fine-tuned model weights, LoRA / QLoRA adapter weights, distilled model parameters, and training-run configurations (base-model identifier and version, hyperparameters, dataset manifest hash, framework version, random seeds) produced in performance of the Statement of Work are Client Work Product, assigned on payment, and delivered as accessible files on infrastructure under Client’s control on the Closing Date. Where the fine-tune is hosted by a third-party vendor (e.g., OpenAI, Anthropic, Google), the engagement shall be conducted under a vendor account in Client’s name, or the snapshot shall be re-created under such an account before the Closing Date.
Failure mode if you skip this: the founder’s product depends on a hosted fine-tune that lives on the partner’s vendor account. The partner ends the relationship. The founder either pays a transition fee to re-train the fine-tune on their own account, or rebuilds the system around a different base model — both of which take weeks and break the production deployment.
Category 5: Vendor SLA pass-through
This is the category that surprises founders most often. The OpenAI, Anthropic, and Google Cloud business terms protect the named customer of record on the API account. If the partner uses their own API key during the build (as roughly 70% of boutique partnerships do — it is simpler operationally), the SLA, support escalation path, abuse-policy protections, and downtime credits all flow to the partner, not the founder.
The most common failure mode plays out like this. The partner ships the MVP on their own OpenAI account because it had higher rate limits during development. Handoff happens; the founder takes over operations. Six weeks later, the OpenAI policy team flags a prompt the system is sending as a suspected ToS violation. The escalation email goes to the partner, who is no longer engaged and takes three days to reply. The system is rate-limited during the response window. The founder, who is technically running the product, has no direct relationship with OpenAI to escalate.
There are two clean fixes.
Fix 1 — founder is customer of record from day one. Founder signs up for the OpenAI / Anthropic / Google account, the partner is invited as a billing-and-deployment user. All API calls land on the founder’s account from kickoff. The partner sees only the workspace, not the parent account. This is the cleanest outcome and works for ~60% of engagements.
Fix 2 — migration to founder’s account before the closing date. Partner uses their account during development for higher rate limits and faster iteration; in week 10 of a 12-week build, the partner provisions the founder’s account, migrates the production deployment to it, and re-verifies the eval set against the new account. Adds a few days of work but keeps the production system fully aligned with the founder’s name by handoff.
Clause to insist on:
Prior to the Closing Date, the production deployment shall run entirely under API and infrastructure accounts in Client’s name. Partner shall not be the customer of record on any third-party AI vendor account (including but not limited to OpenAI, Anthropic, Google Cloud, AWS Bedrock) at handoff. Where Partner used a Partner account during development, Partner shall complete migration to a Client account, with full eval re-verification, no later than two weeks before the Closing Date.
Failure mode if you skip this: the founder owns the code but inherits a degraded SLA. When the vendor side breaks — and over a multi-year horizon, it will — the founder has no relationship to invoke.
Category 6: Training and operational data
Data shows up in two distinct forms across the engagement, and the contract needs to address both.
Training data is the corpus used to fine-tune the model (if fine-tuning is in scope) or to construct the RAG index. It is usually founder-supplied — customer transcripts, product documentation, internal knowledge bases. The contract needs to make clear that this data remains the founder’s property, the partner has a limited license to use it during the engagement only, and the partner deletes all copies within 30 days of the closing date except where legally required to retain.
Operational data is the continuous stream the system produces in production: API traces, prompt-response logs, user feedback, error reports. This data is the single most valuable asset for future system improvements — it is the raw material for the next eval set, the next fine-tune, the next prompt iteration. It usually lives in Langfuse / Helicone / Braintrust / Datadog. By default it sits in the partner’s workspace on those tools.
Clauses to insist on:
All Client-provided training data, RAG indexes derived from Client-provided source materials, and embeddings computed from Client-provided documents are and remain Client property. Partner’s license is limited to performance of the Statement of Work and expires on the Closing Date; all Partner-held copies (including embeddings) shall be deleted within 30 days of expiry, except as required by law.
All operational data produced by the deployed system, including API traces, prompt-response logs, user feedback, and error reports, is Client property and shall be routed to observability infrastructure (Langfuse, Helicone, Braintrust, Datadog, etc.) under Client’s account from the production go-live date. Partner shall not retain copies of operational data after the Closing Date.
Failure mode if you skip this: the partner accumulates six months of valuable production traces on their own Langfuse workspace. The founder later wants to improve the system; the data they need is technically theirs but practically inaccessible without paying the partner to extract it.
The six-clause checklist a founder should insist on
The checklist below is the founder-facing summary. Bring it to the kickoff conversation, not to the contract signing — by the time the SOW is in front of counsel, the partner has had four weeks to settle on positions and the negotiation is harder.
| # | Category | Clause demand | What it produces |
|---|---|---|---|
| 1 | Source code | Full assignment of code on payment, including pre-existing partner tooling licensed in perpetuity | Founder owns the application repo with complete commit history |
| 2 | Prompts | Prompts version-controlled inside the repo, including iteration history | Founder can change prompts without re-hiring the partner |
| 3 | Eval set | Eval harness, graded test cases, rubric, baseline numbers delivered in the repo | Founder can swap vendors and re-validate against a known bar |
| 4 | Fine-tuned weights | Weights delivered on infrastructure under founder’s control; hosted fine-tunes re-created on founder’s vendor account | Founder is not locked to the partner’s vendor account |
| 5 | Vendor SLA | All API accounts in founder’s name by closing date | Founder has direct escalation path to OpenAI / Anthropic / Google |
| 6 | Operational data | All traces and logs route to founder’s observability infrastructure | Founder owns the raw material for the next iteration |
A partner who agrees to all six in the kickoff conversation is a real partner. A partner who pushes back on three or more is selling an agency relationship with a partnership label.
For more on how this fits into the broader partnership operating rhythm, see the founder-AI-partner operating manual and how does an idea-to-product engagement actually work week by week. For an upstream view of what a partnership actually is, see what is an AI development partnership, in plain English?.
Three contract failure modes to avoid
Beyond the six categories, three structural patterns sink IP discussions in 2026 partnership contracts.
Failure mode 1 — “we handle the IP at the end.” Some partners propose deferring the IP conversation to the closing date. The argument is reasonable on the surface: scope changes, artifacts evolve, easier to enumerate what was built once it exists. The trap is that the partner gains negotiating power as the engagement progresses. At kickoff the founder has signed for $150K and can walk. At closing the founder has paid $130K and the production system is running on the partner’s infrastructure. The negotiation positions are inverted. Lock the IP terms at kickoff, not at handoff.
Failure mode 2 — the “perpetual marketing license.” A standard partner clause grants the partner the right to “describe the engagement at a high level in marketing materials.” Many versions are reasonable. Some versions creep into broader rights: the right to publish a case study including specific eval numbers, the right to reference the architecture in conference talks, the right to use the founder’s name and logo “in perpetuity.” A perpetual marketing license is a real cost — it caps the founder’s ability to keep the system’s architecture and performance numbers confidential. Limit the partner’s marketing rights to (a) anonymised case studies with founder approval, and (b) a 24-month time window.
Failure mode 3 — “boilerplate from a 2014 web-development MSA.” Many boutique partners use an MSA template inherited from a previous services business. The template was written for deterministic software builds and never updated. Symptoms: the contract mentions “the Software” but never names prompts or evals; the deliverable list says “source code and documentation” with no mention of model artifacts; the IP clause references “copyright in the Work Product” but not “any computed model parameters.” If the contract uses 2014 language, either the partner has not seriously updated their practice, or they have but they are using the older language strategically. Either way, the founder should send back an annotated version that names the six categories explicitly.
Frequently asked questions
Do I actually need clauses for all six categories, or is the source-code clause enough?
All six. The source-code clause is a 2014 protection for a 2026 problem. In a typical engagement the source code is 15–20% of the economic value of the artifacts produced; the other 80–85% sits in prompts, evals, weights (where applicable), vendor SLAs, and operational data. A contract that only covers the code leaves the majority of the value un-protected.
Will a 2026 boutique AI partner actually agree to all of this?
A real partner will agree to all six in some form. They may negotiate the specifics (timing of vendor-account migration, exact format of eval-set delivery, scope of marketing license), but the principle — that founder owns everything materially produced by the engagement, delivered in accessible form — is non-controversial inside the 2026 partner community. Pushback on the principle is itself a strong signal that the engagement is closer to an agency build than a partnership.
What if the partner says “we need to keep the eval set because we use it in our internal benchmarking”?
This is a polite restatement of “we want to retain a key piece of your IP.” The clean answer is that the founder owns the eval set, but grants the partner a non-exclusive, anonymised license to use anonymised performance numbers (not the test cases themselves) in internal benchmarking. The partner can publish “we improved customer-service bot pass rate from 62% to 89% on a real engagement” without ever needing to retain or re-access the actual test cases.
How does this differ from a standard software-development IP clause?
Standard SaaS or app-build MSAs were written for deterministic code. They cover “the Software” as a single bucket. AI engagements produce five additional artifact classes (prompts, evals, weights, vendor relationships, operational data) that are not “software” in the 2014 sense but carry most of the economic value. The clauses above name those categories explicitly because the older language does not contemplate them.
Does this apply to engagements without fine-tuning?
Most of it does. Category 4 (fine-tuned weights) is the only one that depends on fine-tuning being in scope. The other five — source code, prompts, eval set, vendor SLA, operational data — apply to every engagement, including pure prompt-engineering plus RAG builds, which represent ~70% of 2026 boutique partnership work.
Who is the customer of record on OpenAI / Anthropic / Google during the build itself?
Best practice is the founder, from day one. Partner is invited as a workspace member, not as the parent-account holder. Where this is impossible (e.g., the founder cannot get an enterprise account because of org-size requirements), the partner runs the build on a partner account and migrates to a founder account in week 10 of a 12-week build, with two weeks of stabilisation before closing. Anything later is risky; anything earlier is ideal.
What happens to the IP clauses if the engagement ends early?
The clauses should be drafted so that ownership of every artifact produced through the early-termination date assigns to the founder, regardless of the reason for termination. The partner should be paid for the work completed; the founder should still own everything that was built. This is one of the clauses worth specifically calling out in counsel review, because some boilerplate ties IP assignment to “completion of the Statement of Work” — which fails the founder if the SOW is not technically complete.
Are open-weight model fine-tunes safer to own than hosted fine-tunes?
Yes — for portability. A Llama 3.3 or Mistral fine-tune sits on infrastructure of the founder’s choosing and remains accessible if any vendor relationship ends. A hosted fine-tune on OpenAI or Anthropic is callable only through that vendor’s API; if the vendor relationship breaks or the founder is offboarded from the partner’s account, the fine-tune is unreachable. Open-weight fine-tunes carry their own license entanglements (Llama Community License’s 700M-MAU threshold, Mistral Research License’s commercial restrictions) but they preserve operational independence.
What single clause does the most work in a typical 2026 partnership contract?
The eval-set assignment clause. The eval set is the asset that lets the founder change models, change partners, and prove system quality to investors and customers. Founders consistently underestimate it because it does not look like code. Partners who understand the 2026 landscape will not push back on assigning it cleanly. Partners who do push back are revealing that they expect to retain it for their own benchmarking — which is the founder’s first signal to find a different partner.
Key takeaways
A 2026 AI development partnership produces six IP categories. Only one of them — source code — defaults to founder ownership in a standard 2014-style MSA. The other five (prompts, eval set, fine-tuned weights, vendor SLA pass-through, and training / operational data) require explicit clauses. The eval set is the single most valuable category and the most often overlooked. Lock the IP language at kickoff, not at handoff, while the founder’s negotiating position is still strong. A real boutique AI partner will agree to all six in some form; a partner who pushes back on three or more is using “partnership” as a marketing label on top of an agency engagement.
The contract is not the relationship. But the IP terms in the contract decide whether the founder leaves the engagement with a system they can independently operate, evolve, and re-vendor — or with a 15%-complete asset that requires the partner’s continued participation to function. The conversation in week zero is the cheapest moment a founder will ever have to set the terms.
Stay subscribed. New idea-to-product manifesto pieces arrive weekly — covering scoping, evals, economics, DIY tradeoffs, and the founder operating manual. Join the SFAI Labs newsletter for the next one.
Arthur Wandzel
