AI IP ownership - three questions, three different answers, one contract.

Output ownership is the smallest of the three.

A 2026 enterprise AI contract resolves three IP questions, in this order. First, who owns the customer's input data when it is uploaded to the vendor's service? Second, who owns the output that the model produces in response? Third, who owns the model state - the weights, embeddings, retrieval indexes, evaluation sets and other derivative artifacts that exist because of the customer's data? Buyers usually focus on the second question, get a clean answer, and miss that the first and third questions matter more for long-term value capture.

Input ownership

Input ownership in a standard enterprise AI contract is straightforward: the customer retains all rights to the data they upload. The vendor receives a limited license to process the data for the purpose of providing the service. The redlines on input ownership are not about ownership itself but about the scope of the license - specifically, whether "providing the service" extends to model improvement, telemetry analysis or third-party benchmarking. See our data rights clauses article for the full redline set on the license scope.

Output ownership

Output ownership in 2026 contracts is almost universally framed as "Customer owns outputs subject to vendor's residual rights". Three structural issues. First, outputs are not exclusive - the same prompt produces the same output for another customer, so "ownership" is non-rivalrous. Second, the vendor retains the right to use outputs for service operation, abuse monitoring and (variably) service improvement. Third, outputs may incorporate third-party IP - the model was trained on copyrighted material - which is why the indemnity for IP claims matters more than the ownership label. Mapping those residual rights is part of every software license compliance assessment we run across an AI estate.

The redline on output ownership has three components: explicit ownership of outputs subject only to operational rights (not improvement rights); an output IP indemnity with caps that match the deal size; and a representation that outputs will not be retained beyond the period strictly necessary for abuse monitoring. Where the vendor cannot offer exclusive ownership, document the non-exclusivity and price it into your risk model.

Model state ownership

This is the question buyers most often miss. When you fine-tune a model on your data, the vendor creates a derivative artifact - the fine-tuned weights - that exists only because of your data. When you build a retrieval system over your corpus, the vendor creates embeddings that encode the semantics of your corpus. These derivative artifacts have economic value: they are the operational implementation of your AI investment. The default vendor position is silence (the contract says nothing about derivative ownership) or vendor-favourable ("derivative artifacts are deemed part of the Service and are owned by Vendor"). In our experience, the silent contracts are worse - the vendor's standard terms of service usually have a generic IP clause that defaults to vendor ownership in the absence of customer-specific terms.

The redlines for model state ownership: explicit customer ownership of fine-tuned model weights derived from customer data; explicit customer ownership of embeddings derived from customer corpora; deletion of all derivative artifacts on termination, with a certificate of destruction; and a prohibition on incorporating derivative artifacts into the vendor's base model or distributing them to other customers in any form, including aggregated or anonymised.

The indemnity decides who carries the risk.

Output IP indemnities became standard among the major foundation-model vendors in 2023-2024. By 2026, every enterprise-tier contract from the top five vendors includes one. The variation is in the carve-outs. The most common carve-outs we redline:

• Content filters required - indemnity applies only when default content filters are enabled. Push to make this optional or carve out specific approved business uses where filters need to be off.
• Substantial similarity to inputs - indemnity excludes outputs that are substantially similar to customer-provided inputs. This is the carve-out that guts RAG protection. Negotiate a narrow definition of "substantial similarity" that requires direct copying, not retrieval-based grounding.
• Modified outputs - indemnity excludes outputs that have been modified by the customer. Negotiate a threshold (e.g., outputs that retain more than 50% of the original generation are still covered).
• Third-party model components - indemnity excludes claims arising from third-party models incorporated into the vendor's service. Push for full coverage on integrated models or get a list of excluded components.

Cap structure

Output IP indemnity caps in 2026 enterprise contracts range from 12 months of fees (entry-level) to uncapped (rare, but achievable for large deals). The negotiation strategy: start by asking for uncapped, accept a multiple of fees (2-3x is achievable on deals above $1M annual), and only accept the 12-month cap if other indemnity components are favourable. For deals below $500k, the 12-month cap is the market and is usually defensible.

When the model itself is open source.

Open-source foundation models (Llama, Mistral, Qwen) create a different IP profile. The model itself is governed by its open-source license, which typically does not flow IP risk to the customer. But the deployment vendor (the company hosting Llama for you on their cloud) often layers additional terms on top. Three things to verify in an open-source-model contract: that the underlying open-source license is preserved and disclosed; that the deployment vendor cannot revoke access to the model weights you have already deployed; and that the indemnity from the deployment vendor covers the integration layer, not just the underlying model. Open-source-model deployments are usually cheaper and more flexible than proprietary alternatives but the contract is rarely simpler.

What survives the contract is part of the IP allocation.

A clean termination clause for an AI contract has three components. First, customer data is returned or deleted at customer election, with a 30-day window after termination. Second, derivative artifacts (fine-tuned weights, embeddings, indexes) are deleted by the vendor with a certificate of destruction. Third, the customer retains the right to use any outputs already generated, including outputs that were generated using a fine-tuned model that has subsequently been deleted. The third component is the one most often missing from vendor standard terms - and it is the one that matters if the contract ends in a dispute.

For the broader exit-planning issues, see our contract red flags piece and the AI vendor contracts pillar.

Common buyer questions.

If I fine-tune a model on my data, do I own the resulting model?

Not by default. Vendor standard terms typically leave derivative-artifact ownership ambiguous or assign it to the vendor. The redline is to establish customer ownership of fine-tuned weights explicitly.

Does output ownership protect me if a generated output infringes a copyright?

No. Ownership and indemnity are separate clauses. The indemnity is what protects you against third-party IP claims.

Can the vendor use my prompts to train future models?

In enterprise tier, the default in 2026 is no - but the redline is to make sure the definition of "training" includes embeddings, retrieval indexes and any other derivative artifact.

What is the most consequential IP redline?

Customer ownership of derivative artifacts (fine-tuned weights, embeddings) and a deletion certificate at termination. Together they prevent the vendor from compounding value on your data.