Intellectual property provisions determine who owns the software, data, configurations, and insights that emerge from an enterprise software relationship. In a world where AI-generated code, proprietary configurations, and training data derived from customer inputs are increasingly valuable, getting IP ownership right at contract signature is more commercially important than ever. Standard vendor terms are almost universally drafted to maximise vendor IP ownership — at the buyer's expense.
This article is part of our IT Contract Negotiation Strategy guide. IP ownership provisions interact closely with data portability and exit rights (which determine whether you can extract your data and configurations when a relationship ends), software escrow arrangements (which provide access to source code for business continuity), and contract red flags (which include problematic IP assignment and licence-back clauses). See also our comprehensive software contract negotiation checklist.
Enterprise software relationships generate multiple categories of intellectual property — and the standard approach in vendor contracts is to attribute ownership of all of it to the vendor, often without buyers realising the full implications. Understanding the distinct IP categories at stake is a prerequisite for effective negotiation.
The primary IP categories in an enterprise software relationship are: the software itself (including any customisations and configurations made for the buyer); the buyer's data (including content, transactional data, and business records held in the system); derivative data (analytics, insights, and AI model outputs generated from the buyer's data); buyer-funded development (features, integrations, or modules that the buyer pays the vendor to build); and implementation artefacts (configurations, scripts, integrations, and documentation created during implementation, often by the vendor or a third-party implementor).
Vendor contracts typically assert ownership of the software (expected), customisations (often surprising to buyers), configuration exports (frequently overlooked), anonymised or aggregated data derived from the buyer's inputs (increasingly contentious), and any feedback or suggestions the buyer provides (which vendors use to improve their product at the buyer's expense without compensation).
Multiple enterprise SaaS vendors have updated their terms of service in 2024–2026 to include provisions allowing them to use customer data — including content, configurations, and usage patterns — to train their AI models. This raises significant IP and confidentiality concerns. Buyers should explicitly negotiate exclusions from AI training use, or at minimum, opt-out rights for confidential business data. See the AI-generated IP section below for detailed guidance.
The distinction between background IP and foreground IP is foundational to IP negotiation in software development and customisation contracts.
Background IP is intellectual property that either party brings into the contract — pre-existing IP developed or owned before the relationship began. For the vendor, this includes the core software platform, development frameworks, libraries, and methodologies. For the buyer, this includes their data, business processes, proprietary business logic, and any internal IP used in the relationship. Both parties should retain ownership of their respective background IP, and contracts should make this explicit.
Foreground IP — also called "new IP" or "deliverables" — is intellectual property created during the contract, typically through customisation, implementation, or collaborative development. The ownership of foreground IP is where the most significant disputes arise. Vendors typically assert ownership of all foreground IP, including buyer-funded customisations and configurations, on the basis that these build on their platform background IP. Buyers who have funded bespoke development should negotiate for ownership of the specific deliverables they have funded, with a licence back to the vendor for the underlying platform elements.
When a buyer funds the development of bespoke software features — paying the vendor to build functionality specific to the buyer's requirements — the question of IP ownership has significant commercial consequences. Vendor-standard terms typically assert ownership of all code developed on their platform, regardless of who funded the development. This means that functionality the buyer has paid to build can be sold or licensed to competitors, without any share of revenue or acknowledgment.
The work-for-hire doctrine (in US law) and the commissioning rules (in UK law) provide some default protections for buyers in software development relationships, but these are frequently contracted out by vendor terms — and even where they apply, the interaction with underlying platform IP creates complexity. Enterprise buyers should negotiate explicitly for the IP outcomes they want, rather than relying on default legal rules.
There are three main allocation models for bespoke development IP, each with different commercial implications.
Buyer ownership with licence-back to vendor. The buyer owns all IP in bespoke deliverables funded by the buyer. The vendor receives a royalty-free, perpetual, non-exclusive licence to use the deliverables as part of their platform (but not to sell them separately or to third parties). This is the buyer-favourable position and is achievable where the buyer has funded significant bespoke development and has negotiating leverage.
Shared ownership. Both parties own the bespoke deliverables jointly. In most jurisdictions, joint ownership of IP means each party can exploit the IP independently without accounting to the other — which may not be the outcome the buyer wants if the deliverable embeds confidential business logic. Joint ownership provisions should specify whether each party can exploit the IP independently, and under what restrictions.
Vendor ownership with exclusive licence to buyer. The vendor owns the IP but grants the buyer an exclusive licence in the buyer's industry or territory. This is a reasonable compromise where the vendor cannot accept assignment — it prevents the vendor from providing the same functionality to direct competitors, while allowing the vendor to exploit the general platform.
Enterprise buyers almost universally own the data they input into software systems — but vendor contracts increasingly seek to exploit that data in ways that go beyond delivering the contracted service. The key questions are: what can the vendor do with the buyer's data beyond delivering the service? who owns insights, analytics, and derived data created from the buyer's inputs? and what happens to the data when the relationship ends?
Vendor-standard terms typically include provisions allowing the vendor to: use aggregated, anonymised data for product improvement; use usage data for benchmarking and research; and (increasingly) use content and interaction data for AI model training. Each of these uses has IP implications that buyers should address explicitly.
The buyer-favourable position is: the buyer owns all data it inputs into the system; the vendor may process data only to the extent necessary to deliver the contracted service; the vendor may not use buyer data for product improvement, training, benchmarking, or any other purpose without explicit written consent; and all derived data (analytics, model outputs) belongs to the buyer. In practice, buyers rarely achieve the full buyer-favourable position — but explicit negotiation consistently produces better outcomes than accepting standard terms.
For organisations with large, proprietary datasets — financial services firms with transaction data, healthcare organisations with patient records, retailers with purchase history — the question of whether their SaaS vendor can use that data to train AI models is not merely an IP issue. It is a competitive intelligence issue. A vendor that trains on one retailer's purchase patterns is effectively acquiring competitive insight that can benefit competing retailers on the same platform. Explicit data usage restrictions and AI training exclusions are now essential provisions for data-rich enterprise buyers.
The rapid integration of AI capabilities into enterprise software has created new IP questions that standard contract frameworks have not yet fully resolved. Enterprise buyers should be alert to the following emerging IP issues.
Many enterprise AI and SaaS platforms train their models on customer inputs, content, and interaction data. This raises questions about who owns the model improvements that result from this training. Buyers should negotiate for: an explicit prohibition on using the buyer's data (including content, queries, and interactions) for AI model training without the buyer's specific written consent; an opt-out mechanism that applies retroactively; and an obligation to delete any training data previously derived from the buyer's inputs if the buyer opts out.
When an enterprise AI tool generates content, code, or analysis in response to buyer inputs, the IP status of the output is unclear under current law in most jurisdictions. Vendor contracts typically assert that outputs belong to the buyer — which is commercially appropriate — but with carve-outs for outputs that are similar to outputs generated for other customers (creating a risk of inadvertent IP conflict). Buyers should negotiate for clear ownership of outputs, combined with vendor warranties that outputs do not infringe third-party IP.
Where a buyer funds the fine-tuning of an AI model on their proprietary data, the question of who owns the fine-tuned model is analogous to the bespoke development question — and should be negotiated on similar principles. Buyer-funded fine-tuning should result in the buyer owning the fine-tuned model or receiving an exclusive licence in their industry or use case.
Software contracts often include provisions addressing derivative works — modifications or enhancements based on the vendor's software — and improvements made by either party during the relationship. Vendor-standard terms typically assert ownership of all derivatives and improvements, even those created by the buyer's internal team or funded by the buyer.
The most commercially problematic provision in this category is the feedback or suggestions clause — found in virtually all enterprise SaaS agreements — which transfers ownership of any product suggestions, feedback, or ideas the buyer provides to the vendor, without compensation. While individual feature suggestions may have limited value, systematic feedback from enterprise buyers at scale represents significant product development input. Enterprise buyers should at minimum negotiate to remove the IP assignment effect from feedback clauses, preserving the vendor's right to act on feedback without acquiring IP ownership of the suggestions themselves.
| Vendor / Context | Standard IP Position | Buyer-Favourable Negotiated Position | Difficulty |
|---|---|---|---|
| SaaS (standard platform) | Vendor owns platform + all derivatives; buyer owns input data only | Buyer owns outputs, configurations; explicit data use restrictions; AI training opt-out | Moderate |
| Bespoke development (vendor-delivered) | Vendor owns all deliverables; buyer gets licence only | Buyer owns buyer-funded deliverables; licence-back to vendor for platform use | Moderate–High |
| SI/Implementor-delivered work | SI owns implementation artefacts; buyer gets licence | Buyer owns all configuration scripts, integrations, documentation funded by buyer | Moderate (SIs more flexible than vendors) |
| AI platform (LLM/GenAI) | Vendor trains on customer data; outputs assigned to buyer with broad carve-outs | Explicit AI training prohibition; clean output assignment; model fine-tuning ownership | High (evolving market practice) |
| Oracle / SAP (on-premises) | Vendor owns all platform IP; buyer owns data and configurations within limits | Explicit ownership of buyer configurations; escrow + portability for custom code | Moderate |
| Cloud (AWS / Azure / GCP) | Customer owns their data and workloads; cloud IP remains with provider | Generally favourable baseline; negotiate on data residency and portability | Lower (better baseline terms) |
| Managed services / Outsourcing | Service provider owns tools and methodologies; buyer owns outputs but not tools | Buyer owns all tools and scripts funded by buyer; licence-back for re-use | Moderate |
| # | Tactic | Application |
|---|---|---|
| 1 | Map IP categories before negotiation | Create a schedule of all IP categories at stake — software, data, outputs, custom development — before entering negotiation; prevents missing categories under time pressure |
| 2 | Separate data ownership from data processing | Vendor needs to process your data to deliver the service; they do not need to own it. Insist on clear ownership language separate from processing permission |
| 3 | Negotiate AI training exclusions explicitly | Do not rely on general confidentiality provisions to prevent AI training use — the exclusion must be specific and explicit |
| 4 | Define "derivative works" narrowly | Vendor contracts define derivative works broadly to capture buyer-created configurations and integrations; push for a narrow definition that excludes buyer-created implementation artefacts |
| 5 | Remove IP assignment from feedback clauses | Replace "the buyer assigns all feedback to the vendor" with "the buyer grants a royalty-free licence to implement feedback without IP transfer" |
| 6 | Link bespoke development IP to payment | For buyer-funded features, make IP ownership transfer conditional on payment — creates a clear commercial rationale for buyer ownership that is difficult to argue against |
| 7 | Negotiate survival of IP provisions on termination | Ensure that data ownership provisions survive termination and that the vendor's post-termination obligations (data deletion, portability) are explicit |
| 8 | Include IP warranties from vendors | Require the vendor to warrant that the software (and any outputs) does not infringe third-party IP; link to indemnification for IP infringement claims |
| 9 | Audit configuration and implementation artefact ownership with SIs | Implementation partner contracts are often overlooked; ensure the buyer owns all scripts, configurations, and integrations funded through the SI engagement |
Are your IP provisions protecting your business?
For further reading, see our guides on data portability negotiation, software escrow agreements, software contract red flags, and audit rights clauses. For the complete framework, visit our IT contract negotiation strategy guide.
Our advisors have negotiated IP provisions for enterprise buyers across hundreds of software, cloud, and AI relationships. We know where vendor contracts expose your competitive assets — and how to fix them.