Protect IP and data by putting explicit contract terms in place before work starts covering data ownership, model and code ownership, confidentiality, and what the vendor can and cannot do with the data after the engagement ends, since standard vendor terms often default in the vendor's favor unless specifically negotiated otherwise. Specify in writing that any code, fine-tuned model weights, and prompt or evaluation datasets created during the engagement belong to the client company rather than the vendor, unless a shared platform is deliberately being licensed instead. Clarify whether the company's data can be used to improve the vendor's models for other customers, and require an explicit opt-out if not, since this default varies significantly between vendors, which matters most for hosted or SaaS AI tools. Require data processing agreements that specify storage location, retention period, deletion timelines and subprocessor disclosure, particularly for any data crossing borders during processing. Include a clean handover clause requiring documentation, source code and model artifacts to be delivered on termination, not merely access revoked. Review these terms with legal counsel before signing, since verbal assurances from a sales team carry no weight once the relationship ends. Nanobase AI puts these ownership and data terms in writing as standard practice, since a client's IP should remain the client's regardless of who built the system.
Standard vendor terms rarely protect the client by default
Most AI vendor contracts, particularly SaaS and hosted API agreements, are written with terms that default in the vendor's favor unless the client specifically negotiates otherwise, since the vendor's standard paperwork is drafted to protect the vendor first. Assuming a contract protects company IP and data because it looks professional is a mistake; every clause that matters has to be checked and, where needed, rewritten before signing, not after a dispute arises.
The clauses that matter most
Five clauses account for most of the real IP and data exposure in an AI vendor contract, and each needs specific language, not a general confidentiality paragraph.
| Clause | What to require | Why it matters |
|---|---|---|
| Code and model ownership | Client owns any code, fine-tuned weights and prompt/eval datasets created during the engagement | Prevents the vendor from treating deliverables as reusable IP for other clients |
| Training data use | Explicit opt-out from having client data used to improve the vendor's models for others | Default terms often allow this unless excluded in writing |
| Data processing terms | Named storage location, retention period, deletion timeline, subprocessor disclosure | Determines actual compliance exposure, especially for cross-border data |
| Confidentiality | Mutual, covering both business information and any data shared during the engagement | Protects against disclosure beyond the immediate project team |
| Handover on termination | Full delivery of documentation, source code and model artifacts, not just access revocation | Prevents a functional but undocumented system from being effectively unusable after the vendor leaves |
A negotiation checklist before signing
- Confirm in writing who owns any code, fine-tuned model weights, and evaluation or prompt datasets created during the engagement.
- Get an explicit answer on whether the vendor can use company data to improve models serving other customers, and require an opt-out if the default is yes.
- Require a data processing agreement specifying storage location, retention period, deletion timeline and any subprocessors involved.
- Add a clean handover clause: documentation, source code and model artifacts delivered on termination, not merely access turned off.
- Route the final contract through legal counsel before signing, regardless of how much trust has built up during the sales process.
Why verbal assurances do not hold up later
A sales team's verbal reassurance that "of course your data stays yours" carries no legal weight once a dispute arises or the relationship ends, since only the signed contract terms are enforceable. This gap matters most at exactly the moment it becomes expensive: during a contentious termination, an acquisition due diligence process, or a regulator's request for documentation of data handling practices. Getting these terms in writing during the calm of contract negotiation, rather than trying to negotiate them during a dispute, is the only point of real leverage either side has.
How this connects to broader vendor evaluation
IP and data protection terms are one part of a larger evaluation that should also cover the vendor's technical approach, support model and exit terms more generally; the full list of questions worth asking any AI vendor before signing covers this broader ground. Avoiding lock-in through portable data formats and an abstraction layer also reduces how much leverage the client loses if the vendor relationship needs to end.
Frequently asked questions
Who typically owns fine-tuned model weights created during an engagement?
This should be specified explicitly in the contract rather than assumed; absent clear language, some vendors' standard terms claim rights over fine-tuned artifacts created using their platform. Requiring client ownership in writing before the engagement starts avoids this becoming a dispute later.
Can an AI vendor use our data to train models for other customers?
Only if the contract allows it, and this varies significantly between vendors, so it needs a direct question and a written answer rather than an assumption either way. Requiring an explicit opt-out is standard practice for any data with competitive or regulatory sensitivity.
What should happen to our data and models when the vendor relationship ends?
The contract should require full documentation, source code and any model artifacts to be delivered, not just access revoked, along with a defined deletion timeline for any client data the vendor retained during the engagement. Negotiating this before signing carries far more leverage than negotiating it during an actual termination.
How Nanobase AI helps
Nanobase AI puts client ownership of code, model artifacts and data in writing as standard practice on every engagement, since a client's intellectual property should remain the client's regardless of who built the system or how the relationship eventually ends.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.