The gap in a standard development contract
Most software development agreements deal with deliverables, IP in code and confidentiality. A machine learning project produces things those clauses do not cleanly cover.
- The trained model - parameters learned from your data, not written by anyone
- Engineered features and the transformation logic, which often encode real business knowledge
- Labelled datasets created during the project, frequently the most expensive asset produced
- The supplier's general learning, which they will inevitably carry to other clients
Silence on these is not neutral. It leads to a disagreement later, usually when the relationship is ending and goodwill is lowest.
Four questions to settle
- Who owns the trained model? Typically the client where it was trained on client data and paid for by the client, but say so.
- Who owns labelled data created in the project? Often overlooked and often the most reusable asset.
- May the supplier reuse what they learned? General expertise, yes - that is unavoidable and reasonable. Your specific data, features or model, that needs stating.
- What happens at the end? Exactly what is handed over, in what form, and whether it is usable without the supplier.
Handover that actually works
Owning a model is worthless if you cannot run it. A handover clause should list what must be delivered in enough detail that ownership is meaningful.
| Deliverable | Why it is needed |
|---|---|
| Model artefacts and weights | The model itself |
| Training and feature code | To retrain when it degrades |
| Training data or a reference to it | Reproducibility and audit |
| Environment specification | To run it at all |
| Documentation and evaluation results | To know what it does and how well |
| A working deployment example | Proof that what was handed over runs |
That last line is worth insisting on. A handover that has never been tested by anyone other than the supplier frequently turns out to be incomplete.
Being realistic about supplier learning
A supplier cannot unlearn general techniques. Demanding that they never apply similar methods elsewhere is unenforceable and will either be refused or ignored.
The reasonable line is between general expertise, which they keep, and your specific assets - your data, your labels, your trained model, your particular feature definitions - which they do not reuse. Most competent suppliers will agree to that readily, and reluctance tells you something useful.
Third-party components
Models frequently build on open-source components and pre-trained models with their own licences, some of which restrict commercial use or impose conditions on derived models.
Ask for a list of components and their licences as a deliverable, and check it before launch rather than during due diligence for a funding round or a sale. Discovering a restrictive licence deep in a production system is an expensive surprise.
If the contract does not mention the trained model, nobody has agreed who owns it.