AI Co-Build Partnership IP Ownership: Code, Data, Models and Brand

In an AI co-build, one side usually brings domain data and customers. The other brings code and models. If you do not decide who owns what before the first sprint, you will decide it later in a dispute.

This post covers AI co-build partnership IP ownership: five assets, the questions each one raises, and a clause checklist. It is general information, not legal advice. Both sides need their own lawyer.

I am not describing any specific deal. Terms vary, and they should.

AI Co-Build Partnership IP Ownership: Five Assets

Most disputes come from treating “the IP” as one thing. A co-build has at least five assets, and each can have a different owner.

1. Code. The application, agent logic, connectors, and tooling.
2. Models. Prompts, fine-tuned weights, adapters, and evaluation sets.
3. Data. What the domain partner brings in, and what the product collects from customers.
4. Customer contracts. The right to the relationship, the revenue, and the renewals.
5. Brand. The name, domain, logo, and social accounts.

Write all five on one page. For each, answer: who owns it at the start, who owns it after the build, and who owns it if the partnership ends. If any cell is blank, that is your first conversation.

Studio-style deals add a sixth issue: what the studio keeps for itself. A 2026 guide for founders entering startup studios describes three common models. The studio keeps core technology. The IP moves to the new company. Or the IP stays at the studio as a portfolio asset. The guide says none is inherently unfair, but “not knowing which one you’re agreeing to is a problem.” I agree. For background on how studios work, see what an AI venture studio is.

Code and Models

The first question is simple: who owns the code?

The tempting answer is “whoever wrote it.” That is risky. Under US law, a joint work is a work prepared by two or more authors who intend their contributions to merge into a unitary whole. A co-build can easily produce one. Then you have co-authors, and the default rules may not be what either of you expected.

Patents work the same way. 35 U.S.C. 262 says that, absent an agreement to the contrary, each joint owner of a patent may make, use, and sell the invention without the consent of, and without accounting to, the other owners. So if you co-own a patent and say nothing, your partner can exploit it freely, including in a competing business. Most people find that surprising.

My recommendation: do not leave code or models jointly owned by default. Pick one owner for each asset, and use licenses to give the other side what it needs.

A clean pattern:

• The new entity owns the product code and models. Both partners assign their contributions to it in writing.
• Each partner keeps pre-existing tools. Anything built before the deal, or built for other uses, stays with its owner and is licensed to the entity.
• Name the pre-existing tools in a schedule. Do not rely on phrases like “proprietary framework” or “studio tools.” The startup studios guide warns that broad wording like this can reach technology the team built.

For models, add three points. First, who owns fine-tuned weights, adapters, and prompts. Second, the license on any base model. For example, Meta’s Llama 3.1 license says the licensee owns its own derivative works, requires fine-tuned models to start with “Llama” in the name, and requires a separate license above 700 million monthly active users. Your base model’s terms may limit what you can do with the result. Third, the eval set: whoever holds it can judge any future version of the product.

Also be careful about copyright in AI output. The US Copyright Office’s January 2025 report on copyrightability concludes that prompts alone are unlikely to meet the human authorship requirement. If your moat depends on copyrightable output, take advice early. For the buyer side of this same question, see AI agent ownership and exit rights.

Training and Customer Data

Data is where the domain partner holds the strongest hand, and where the builder has the most to lose.

Split data into three groups:

Data group	Example	Typical question
Contributed data	The domain partner’s documents, records, labeled examples	Does the entity get a license, or an assignment?
Customer data	What each customer’s users put in and get out	Who is the controller, and who is the processor?
Derived data	Embeddings, indexes, evals, usage analytics	Who owns it, and may it train shared models?

Contributed data. The domain partner usually wants to keep ownership and grant a license. The license should say what the entity may do with it: train, evaluate, serve customers, or all three. It should also say whether the license ends when the partnership ends. If the model has been trained on the data, “ending the license” gets technical fast. Decide now whether trained weights survive.

Customer data. If the product handles personal data, privacy law shapes the answer. Under GDPR, when two or more controllers jointly decide the purposes and means of processing, they are joint controllers and must set out their respective responsibilities in a transparent way. When the entity acts as a processor, Article 28(3)(g) requires it to delete or return the personal data at the controller’s choice once services end. Map who plays which role. And if you operate in the US only, the same exercise still helps, because customers will ask. My piece on data sovereignty for AI agents covers where data should live.

Derived data. The default is often unclear. Say who owns embeddings and indexes, and whether customer-derived data may be used to improve a shared model. Many enterprise customers will say no. Your contract with them should match what you agree between partners.

Last, protect the secrets. To count as a trade secret under US federal law, information must be something its owner has taken reasonable measures to keep secret. That means access limits and confidentiality terms from day one, not after a falling out.

Customer Contracts and Brand

These two are easy to miss because they are not “technology.”

Customer contracts. Decide which party signs with customers. In most co-builds the new entity should, so that revenue, liability, and renewals sit in one place. If the domain partner signs customers directly, you need a clear pass-through arrangement and a plan for what happens to those customers later.

Also decide who owns the relationship. If the domain expert brings the customers, may the builder contact them directly if the partnership ends? Write down the answer. A non-solicit clause with a fixed term and a narrow scope is common. How enforceable it is depends on where you are, so ask your lawyer.

Brand. List the name, the domain, the app store listings, the social accounts, and the email domains. Put every one of them in the entity’s name from day one. A domain registered to a founder’s personal account is a classic trap.

If the partnership uses revenue share instead of equity, the economic terms sit alongside IP. See revenue share in AI development partnerships and how venture studio equity splits work for that side.

Reuse Rights

Can either side reuse the work? The honest answer is “only if you wrote that down.”

Reuse questions to settle:

• May the builder reuse general components (connectors, utilities, patterns) in other projects?
• May the domain partner build a competing product with another builder?
• May the builder serve competitors of the domain partner?
• Does anyone get a non-compete? For how long, and in which market?
• May either side use the project in marketing or case studies?

I lean toward a split. The builder keeps the right to reuse general know-how and generic components that contain no partner data or confidential material. The domain partner keeps exclusivity on its data, its customer relationships, and anything that reveals its business. Narrow exclusivity is easier to defend than broad exclusivity.

Note the patent default above. If you co-own a patent and want to restrict your partner from licensing it to a rival, you need a contract that says so.

Exit and Buyout

Every co-build should assume it might end. Plan the exit when everyone still likes each other.

Cover these scenarios:

1. A partner leaves. What happens to their equity or revenue share? Is there vesting? The startup studios guide gives a warning example, where vesting tied to studio-defined milestones left a founder unable to walk away without forfeiting equity earned over two years.
2. A partner is bought out. How is value set? A formula, an independent appraisal, or a right of first refusal?
3. The project is shut down. Who gets the code, the models, the data, and the domain name? Is there a sale process, and who runs it?
4. A third party offers to buy the entity. Who must approve? Do both partners get the same terms?
5. A dispute. Which court or arbitrator? Is there a mediation step first?

Also cover the transition. On exit, the departing side should return or delete the other side’s confidential data, and the contract should say how and by when. Make the deletion certifiable.

Clause Checklist

Use this list in a first call with your lawyer. Mark each as “agreed,” “open,” or “not needed.”

Assets and assignment

• Written assignment of all project IP to the entity, signed by both partners
• Schedule of pre-existing IP kept by each partner
• License from each partner to the entity for pre-existing IP, with scope and term
• Employee and contractor IP assignments in place

Models and data

• Ownership of weights, adapters, prompts, and eval sets
• Base-model license terms reviewed
• License for contributed data: purpose, term, and what happens to trained weights
• Controller and processor roles for customer data
• Rules for training on customer-derived data
• Confidentiality terms and access controls

Commercial

• Who signs customer contracts
• Who owns the customer relationship
• Brand, domain, and accounts held by the entity
• Revenue share or equity terms, in a separate schedule

Reuse and restrictions

• Reuse rights for general components
• Exclusivity and non-compete scope, term, and territory
• Marketing and case study permissions

Exit

• Vesting and leaver terms
• Buyout formula or appraisal method
• Shutdown plan and asset distribution
• Return or deletion of confidential data
• Dispute process

Bottom Line

Do not treat “the IP” as one thing. Split it into code, models, data, customer contracts, and brand, and give each one an owner.

Assign project IP to one entity. Keep pre-existing tools with their owners and license them. Settle data rights, reuse, and exit before the first sprint.

Next step: fill out the five-asset page with your partner this week, then take it to your lawyers.

FAQ

Who owns the code in a co-build? It depends on what you sign. Without a written assignment, you may end up as co-authors of a joint work, which can create shared rights neither side wanted. The cleaner pattern is for both partners to assign project code to one entity and to license their pre-existing tools to it.

Who owns the customer data? Usually the customer, or the customer’s own users, with the product acting as a processor. If you handle personal data, privacy law such as GDPR sets roles and deletion duties. Decide who is the controller and who is the processor, and match your partner contract to your customer contracts.

What happens to the model? That is a question for the contract. Decide who owns the weights, adapters, prompts, and eval set, and check the base model’s license. If the model was trained on one partner’s data, decide whether the model stays with the entity when that partner leaves.

Can either side reuse the work? Only as far as the contract allows. A common split lets the builder reuse generic components and general know-how, while the domain partner keeps exclusivity over its data and customer relationships. Under US patent law, co-owners can exploit a patent without accounting to each other unless they agree otherwise, so say it in writing.

What if the partnership ends? The exit terms decide. Cover leaver and vesting rules, buyout method, shutdown, who gets which assets, return and deletion of confidential data, and how disputes are handled. Write these when the relationship is good.

Do we need lawyers for both sides? Yes. The interests differ, and one lawyer cannot properly advise both partners. Treat this post as a map for the first conversation. It is not a substitute for advice.

Three Ways to Work With TMA

Need an agent built? We deploy production AI agents in your infrastructure. Working pilot. Real data. Measurable ROI. → Schedule Demo

Want to co-build a product? We’re not a dev agency. We’re co-builders. Shared cost. Shared upside. → Partner with Us

Want to join the Guild? Ship pilots, earn bounties, share profit. Community + equity + path to exit. → Become an AI Architect