The conversation that prevents most AI-partnership offboarding pain takes 45 minutes and happens before any code is written. It is not a contract review. It is a kickoff call between the founder and the partner’s technical lead, structured around seven specific questions. Each maps to one artifact the engagement will produce. Each artifact has a correct answer for who owns it, the SOW clause that codifies that answer, and the pushback sentence for when the partner resists.
Founders skip this conversation because the partner’s SOW says “Founder owns all work product” and they assume that covers everything. It does not — “work product” in 2026 is seven different things, and the default partner stack only delivers two of them. By the time IP shows up in red-line, the founder has already lost negotiating room to the partner’s standard MSA.
This piece is the founder-side script. It draws on the founder-AI-partner operating manual and sits inside the idea-to-product manifesto.
Why the day-1 conversation matters more than the contract
A 2026 AI engagement produces seven distinct economic artifacts. Bain’s 2024 Beyond Hype report notes that more than half of enterprise AI projects stall at the handoff stage — and the proximate cause is almost always that one or more artifacts was never transferred. The contract said it would be. The mechanics never existed.
The reason is structural, not malicious. A typical partner runs prompts in their Cursor history, evals in their shared Weights and Biases project, fine-tuned adapters on their Hugging Face account, and inference on their OpenAI or Anthropic enterprise contract. None of those tools have a built-in “transfer to client” button. If the founder has not asked, on day 1, how each artifact will physically transfer, the answer at offboarding is “we’ll figure it out” — which usually means a six-figure check to rebuild from scratch.
A partner who answers all seven questions cleanly is a real partner. A partner who answers two cleanly and gets vague on the rest is selling an agency build dressed as a partnership. The conversation is the cheapest possible filter. This is a founder-facing operating script, not legal advice — validate every clause with counsel.
Question 1: Who owns the source code?
Ask it this way: “On the day this engagement ends, where does the source code live, and what does my team need to keep running it?”
Correct answer: The founder’s GitHub or GitLab organization owns the source code from commit one. The codebase is runnable on the founder’s own infrastructure within four hours of a fresh laptop checkout. No partner-internal monorepo.
SOW language to insist on: Source code, repository history, and CI/CD configuration are committed to a Founder-owned VCS organization from the first commit. A complete RUNBOOK.md describes every step to run the system on a clean environment.
Pushback sentence when the partner resists: “If the code only runs on your machines, I am paying for the right to read it, not the right to operate it. Where in the SOW does it commit to runnable handoff?”
Code is the easy question — use it to warm the conversation up. The harder six are next.
Question 2: Who owns the prompts and the prompt registry?
Ask it this way: “The prompts that make this system behave correctly — where do they live, and how do I take them with me?”
Correct answer: Prompts are versioned in the source repository as a structured registry (/prompts with one file per prompt, plus a manifest), and every change goes through the same code review process. Prompts are not stored in a third-party SaaS the partner controls.
SOW language to insist on: All production prompts are stored in /prompts/ in the Founder-owned repository with version metadata. Any prompts stored externally must be mirrored to the repository within one business day.
Pushback sentence when the partner resists: “Prompts are the operating instructions for the system I paid you to build. If those instructions live somewhere I cannot see, I am buying a system I cannot operate.”
Prompts are roughly 20-30% of the economic value of a 2026 AI engagement. A partner who treats them as their proprietary toolkit is treating the founder as a tenant, not an owner.
Question 3: Who owns the eval set?
Ask it this way: “The test suite that proves the system behaves correctly — what format is it in, and how do I run it on day 91?”
Correct answer: The eval set lives in the source repository as plain data files (JSONL, CSV, or YAML) plus a runnable script. The founder can run the full suite on a fresh laptop with one command. Eval set, rubric, and historical results are all transferred at offboarding in human-readable form.
SOW language to insist on: The eval set, evaluation rubric, and full evaluation history are committed to the Founder-owned repository in plain-text formats. A make evals (or equivalent) command runs the full suite locally.
Pushback sentence when the partner resists: “The eval set is the most valuable single artifact this engagement will produce. If I cannot run it after you leave, I cannot prove the next team did not regress the system. Where will it live?”
McKinsey’s 2024 State of AI report identifies evaluation infrastructure as the single biggest gap between pilot and production. A founder who walks away with a running system and no eval set walks away with a black box that cannot be verified.
Question 4: Who owns the fine-tuned weights?
Ask it this way: “If we fine-tune a model, whose Hugging Face account hosts the adapter, and what license is it under?”
Correct answer: If the engagement produces a fine-tuned model or adapter (LoRA, QLoRA, full-parameter), the artifact lives on the founder’s Hugging Face organization under a license the founder controls. The training script, dataset, and hyperparameters are committed to the source repository so the founder can re-run the fine-tune if the artifact is lost.
SOW language to insist on: Any fine-tuned model weights, adapters, or LoRA artifacts are uploaded to a Founder-controlled Hugging Face organization under a license selected by the Founder. The training script, dataset snapshot, and hyperparameter configuration are committed to the Founder-owned repository.
Pushback sentence when the partner resists: “Fine-tuned weights are an artifact I paid to produce, not a tool you used to produce it. If they live on your account, I have rented a model I bought. Move them to my account or the engagement is paused.”
This question surfaces the most resistance, because many partners genuinely believe the fine-tuned artifact is part of their proprietary stack. The base-model license (Meta’s Llama, Mistral’s Apache 2.0) carries through, but the adapter is the founder’s to license. The graceful exit becomes ungraceful if this is not settled on day 1 — see the graceful exit guide for the offboarding mechanics.
Question 5: Who owns the customer data?
Ask it this way: “Where is end-user data stored during this engagement, and what is the partner’s data processing role under GDPR?”
Correct answer: Customer data is stored in the founder’s own cloud account (AWS, GCP, Azure, or managed Postgres / vector-DB on the founder’s bill). The partner is a data processor under GDPR, not a controller. A DPA is signed before production data touches the system. No retention, copying, or reuse — including for model training.
SOW language to insist on: All end-user data is stored exclusively in Founder-controlled infrastructure. Partner acts as a data processor under GDPR Article 28. Partner shall not retain, copy, export, or use end-user data for any purpose outside this engagement, including model training, fine-tuning, or evaluation.
Pushback sentence when the partner resists: “End-user data is not a development artifact. It belongs to my users, who consented to me — not to you — holding it. Where does the data live, and what is your GDPR role?”
A partner who hedges on the GDPR-controller-vs-processor distinction has not run a production system before. That alone is worth knowing on day 1.
Question 6: Who owns the training data?
Ask it this way: “The data you use to fine-tune or evaluate the model — where does it come from, who curated it, and do I have an unencumbered right to keep using it?”
Correct answer: Training data falls into three buckets — founder-provided, third-party licensed, and partner-curated synthetic. Founder-provided stays the founder’s. Third-party licensed carries its original terms and the founder gets a copy plus license documentation. Partner-curated synthetic data is licensed to the founder perpetually and irrevocably at no additional cost.
SOW language to insist on: All training, evaluation, and synthetic data produced or curated under this engagement is delivered to the Founder at offboarding, with provenance documentation and license terms for any third-party subsets. Partner grants Founder a perpetual, irrevocable, royalty-free license to any Partner-curated synthetic data.
Pushback sentence when the partner resists: “If I cannot keep training on the data you used to train this version, I cannot keep improving the model after you leave. That is the definition of vendor lock-in.”
This is the most boring of the seven questions and the one most likely to be hand-waved. The hand-wave is the signal — a partner who has thought about offboarding has thought about training-data provenance.
Question 7: Whose name is on the model API account?
Ask it this way: “Whose OpenAI, Anthropic, or model-hosting account is the production traffic running through, and on the day you leave, what changes?”
Correct answer: Production model API traffic runs through the founder’s own enterprise account from day 1. The founder pays the vendor directly. Rate limits, custom enterprise terms, BAAs, and DPAs are all in the founder’s name. The partner is a team member, not a reseller — no margin on top of the vendor bill.
SOW language to insist on: Founder shall hold, in Founder’s name, the enterprise accounts for all production model APIs (including OpenAI, Anthropic, and model-hosting providers). Founder pays vendors directly. Partner may be granted team-member access, revocable on 24 hours’ notice. Partner shall not act as a reseller or pass-through for vendor invoices.
Pushback sentence when the partner resists: “If the production traffic runs through your account, you can turn the system off. That makes you a hostage-taker, not a partner. The account moves to my name before launch.”
This distinguishes a partnership from a managed service. The founder must know which one they are buying. For a deeper look at why this clause is load-bearing, see the hidden Y problem in AI agency contracts.
How to actually run the 45-minute conversation
The conversation happens with the partner’s technical lead in the room, not just the account executive. Ask the seven questions in order. Write each answer down verbatim. At the end of the call, send a written summary: “Here is what we agreed on each of the seven questions. Please confirm by reply within 48 hours, and these will be appended to the SOW as Schedule B.”
That last sentence is the entire mechanism. A verbal commitment from the partner’s technical lead, confirmed in writing and attached to the SOW as a schedule, is a stronger artifact than three weeks of red-line on the main MSA. A partner who refuses to write Schedule B is telling the founder the verbal commitments will not hold — itself a decision-grade signal.
If the partner answers all seven cleanly, the founder has bought a real partnership. The companion guide how AI development partnerships handle IP and code ownership walks through the underlying IP decomposition. If two or more answers are vague, the founder has bought a service. That is fine, but it should be priced like a service. Renegotiate or walk — the cost of walking on day 1 is one signed letter; the cost of walking on day 91 is six figures and three months.
Get the AI MVP scoping worksheet — the seven questions appear as a kickoff-call checklist with space for the partner’s verbatim answers and a templated Schedule B summary.
Frequently asked questions
When should I have this conversation — before the SOW or after?
Before the SOW is signed, ideally in the first sales call after the engagement is scoped. Before the SOW, the partner is in pursuit and will negotiate. After signing, the founder pays for time and the partner controls the agenda. Twenty minutes of friction in week zero saves three months of pain in month four.
What if the partner says “we always do it this way” and refuses to change?
That is your answer to whether they are a partner. A real partner adapts the operating model to the client. A partner who refuses to negotiate the seven questions is selling a productized service — fine as a category, but mispriced for what they claim to sell. Renegotiate the price down or find a different partner.
Do I really need all seven, or can I just insist on code and customer data?
All seven, because the offboarding pain is generated by whichever artifact you forgot. The partner you choose today will not be your partner in 18 months. If you only lock down code and data, the prompts, evals, weights, training data, and API account stay with the old partner, and the new partner cannot pick up.
What if I am non-technical and don’t understand the answer to (say) the eval set question?
Ask the partner to send a 90-second Loom showing the eval set running on a clean machine, before the SOW is signed. A real partner records it in 10 minutes. A vague partner spends two weeks scheduling a call. The Loom is also a useful artifact at offboarding — it documents what “running” actually means.
Is the eval set really more valuable than the source code?
Yes, in most 2026 AI engagements. Source code is reproducible — a competent successor partner can rewrite it in weeks using AI coding tools. The eval set encodes behavior the founder negotiated with the partner over months: what counts as a correct answer, a hallucination, an edge case. Re-deriving it is functionally impossible without a 6-12 month rebuild.
Should I expect to pay model vendors directly from day 1?
Yes. Direct-vendor billing is the single most important clause for preventing lock-in. If the partner offers a discount for running traffic through their account, refuse it — the discount is rarely worth the loss of independence. The exception is a short pilot where the partner runs the spike on their account; the SOW should then schedule the migration to the founder’s account before any production traffic.
How do I write SOW clauses without a lawyer who knows AI?
Use the SOW language above as a starting point, send the proposed Schedule B to the partner, and ask their counsel to redline it. The redline is informative — a counsel that strips the eval-set or fine-tuned-weight clauses is telling the founder where the negotiating power actually sits. Run the redlined version past a startup lawyer for a final sanity check.
What if the partner is an agency rather than a partnership-model boutique?
The conversation is the same; the answers will differ. An agency typically owns the prompts and evals as reusable IP, runs API traffic through their account, and treats fine-tuned weights as proprietary. That is a legitimate model — but it is not a partnership, and the SOW price should reflect that the founder is buying delivery, not ownership.
Key takeaways
- The IP-and-weights conversation is a 45-minute kickoff call between the founder and the partner’s technical lead, structured around seven questions covering code, prompts, evals, fine-tuned weights, customer data, training data, and model API account ownership.
- Each question has a correct answer (founder owns the artifact, in an accessible format, on founder-controlled infrastructure), a specific SOW clause, and a pushback sentence for when the partner resists.
- Have the conversation before the SOW is signed. Capture answers in writing as Schedule B. A partner who refuses to write the schedule is the most useful signal you will get.
- The eval set is the most valuable single artifact in a 2026 AI engagement. The model API account clause shifts the most negotiating power. Together they determine whether you have a partnership or a hostage situation.
- Two or more vague answers means you are buying a managed service, not a partnership. Reprice it or find a different partner.
Arthur Wandzel
