Last post, I unpacked the different types of IP in AI systems. Today, I want to go deeper into a question that comes up constantly: who owns the IP developed in AI collaborations?
Most enterprise AI projects involve a client and a provider, each bringing significant IP and expertise to the table, and working together to build a custom solution. At first glance, it can feel like a “blank slate” project. In reality, almost nothing in AI is created from scratch.
The Collaboration
In a typical collaboration, both client and provider contribute important IP inputs:
- Background IP (ie. pre-existing IP):
- Clients contribute business processes, data, and domain expertise.
- Providers contribute methods, algorithms, libraries, and a toolbox of reusable code.
- Open-source software and pre-trained models are often a third major source.
- Foreground IP (IP created in the collaboration):
The outputs of the project, such as trained models, optimization engines, pipelines, and integrations. - Intermediate IP:
Assets created along the way, such as untrained models, custom tools, or reusable modules.
A key point here: the provider’s background IP is usually substantial. What looks like a “bespoke” model from the client’s perspective is often 80–90% provider background IP and tools, with the remaining portion being the customization to the client’s data, systems, and business processes.
Who Owns the Foreground IP?
This is where things can get contentious.
Contracts often default to a zero-sum approach: one side owns everything. This isn’t based on strategy or logic, but on bargaining power. Clients – believing that “if we pay for it, we own it” – push for complete ownership of all the Foreground IP.
But IP isn’t monolithic. It can — and often should — be divided strategically.
A useful way to think about it is the orange and peel:
- The orange is the core model built from generic architectures, reusable frameworks, and algorithms.
- The peel is the customization that wraps the model in the client’s data, workflows, and integrations.
Clients typically care most about the peel — the custom parts that directly embed their competitive advantage. Providers need the orange — the reusable code and frameworks that let them build for the next client.
This distinction matters, because tying up the orange in client ownership not only limits the provider, it provides little real benefit to the client.
Background IP Licensing
Even when clients negotiate to own the foreground IP (the trained model, integrations, etc.), they can’t operate those assets without continued access to the provider’s background IP.
Why? Because the background IP — the algorithms, libraries, and code frameworks — makes up the majority of the system. Foreground IP is usually just a thin customization layer. Without a license to the provider’s background IP, the client may own “the peel” but not the orange that actually delivers value.
That’s why contracts need to include a clear license to the provider’s background IP. This ensures the client can continue using the system effectively, while allowing the provider to keep building on and reusing its core assets across projects.
Why Contracts Matter
There’s a basic legal principle at play here: the creator of IP is its first owner. In collaborations, that usually means the provider. Unless a contract transfers some or all of those rights to the client, the provider retains ownership by default.
This is why contracts must be explicit about ownership and licensing of background, foreground, and intermediate IP. Without that clarity, disputes are almost inevitable.
Takeaway
The reality of enterprise AI collaborations is that:
- Most of the “custom” system is built from provider background IP.
- Clients mainly benefit from owning or controlling the customizations (the peel).
- Providers need to retain ownership of the generic, reusable components (the orange).
- Clients require licenses to background IP to use the outputs effectively.
- Contracts are the only mechanism to allocate ownership and usage rights strategically.
Framing collaborations this way creates win–win outcomes: clients secure the parts of the system that give them competitive advantage, while providers build a stronger toolbox to serve more clients more efficiently.
It’s not zero-sum. It’s about aligning ownership with value.
