AI Development Agreements: Key Issues When Commissioning or Co-Developing an AI Product

Key takeaways

• Ownership: Paying a developer does not transfer ownership. The agreement needs to identify each AI component (code, models, weights, data, prompts) and say who owns it and what licences apply.
• Data and third-party models: Many disputes turn on data and on third-party models rather than code: who may use the customer’s data to train models, and what the terms of the underlying AI services allow.
• Performance: AI systems are probabilistic, so acceptance and warranties work best when tied to measurable performance against agreed test data rather than to error-free operation.
• Regulation: In the EU, the AI Act allocates obligations by role, and the agreement should reflect who will be the provider and what information and assistance each party must give.

Businesses increasingly commission AI products from specialist developers rather than building them in-house. A financial services firm may engage an agency to build a document-analysis tool; a manufacturer may work with a technology partner to develop a computer vision system for quality control; a start-up may co-develop a product with its first major customer. In each case, the development agreement determines who owns what is built, who can use it afterwards, and who bears the risk if it does not work or infringes the rights of others.

Standard software development agreements are a useful starting point, but they rarely deal adequately with the features that distinguish AI projects. This article considers the key issues from a UK perspective, with reference to the EU and US where relevant, focusing on the position of the business commissioning the work.

How is an AI development agreement different?

Three features of AI projects tend to require specific drafting. First, the deliverables are more varied: alongside code, the project will produce trained models, model weights, datasets, prompts and evaluation results, some of which may not be protected by copyright at all. Second, AI systems are usually built on third-party components, such as foundation models accessed through an API, open-weight models and open-source libraries, which neither party owns. Third, AI systems produce probabilistic outputs, so they cannot be specified and tested in the same way as conventional software.

Who will own the AI product?

Identifying the components

The agreement should define the deliverables precisely and allocate ownership of each. A typical AI project may involve:

• Code: application code, model architecture, training and fine-tuning scripts, data pipelines and evaluation tools.
• Models: trained or fine-tuned models, weights and checkpoints, and adapters built on top of a third-party model.
• Data: training, validation and test datasets, labels and annotations, and synthetic data generated during the project.
• Prompts and configuration: system prompts, prompt templates, hyperparameters and retrieval configuration.
• Documentation: technical documentation, records of training data and methods, and test results.

Foreground and background IP

Under the Copyright, Designs and Patents Act 1988, the developer will generally own the copyright in materials its personnel create unless it assigns them in writing, and an assignment is not effective unless it is in writing and signed by or on behalf of the assignor. The usual approach is to distinguish foreground IP created in the project, which the customer may expect to own, from the developer’s background IP, such as its existing platform, tools and libraries, which the developer will want to keep and reuse. Where background IP is incorporated into the product, the customer will need a licence broad enough to use, modify, maintain and commercialise the product, including after the relationship ends.

Developers commonly seek to retain ownership of generic improvements to their tools, and the right to reuse general know-how and techniques. These provisions are often reasonable, but they should be drafted so that they do not extend to the customer’s data, its confidential information or the features that give the product its value. In the US, a statement that deliverables are “works made for hire” will not usually transfer copyright in software created by a non-employee developer, so a present assignment is needed.

Why joint ownership is best avoided

Co-development arrangements sometimes provide for jointly owned IP as a compromise. In the UK, joint ownership can be difficult to work with: a jointly owned copyright cannot be licensed without the consent of all the owners, and a co-owner of a patent cannot generally grant a licence or assign its share without the consent of the others. The position differs in other jurisdictions, including the US, where each co-owner can generally exploit the right independently. It is usually clearer to allocate ownership of each component to one party and grant the other the licences it needs.

Models and weights

It is uncertain whether trained model weights are protected by copyright, and in many cases their value lies in their confidentiality. The agreement should therefore address weights expressly, by assigning whatever rights exist in them, imposing confidentiality obligations, and controlling where they are stored and who can access them. Where the customer’s model is a fine-tuned version of a third-party model, the customer will own at most its own modifications, and its use will remain subject to the third-party licence.

Who can use the data?

Data is frequently the most sensitive issue in an AI development project. The customer will often supply proprietary or personal data to train, fine-tune or test the model, and may be concerned that the developer could use that data, or models trained on it, for other clients. The agreement should specify:

• Purpose limitation. The customer’s data may be used only for the project, and not to train or improve the developer’s other models or products, unless the customer agrees.
• Derived materials. Who owns datasets, labels, embeddings and models derived from the customer’s data.
• Third-party data. Where the developer sources training data itself, warranties as to its provenance and the right to use it for training, including compliance with website terms, licences and any rights reservations.
• Return and deletion. What happens to the data, and to models trained on it, at the end of the project.

Where personal data is involved, the parties will need to establish their respective roles under the UK GDPR (and, where applicable, the EU GDPR), and include the processor terms required by Article 28 where the developer acts as the customer’s processor. A lawful basis and appropriate transparency will be needed for using personal data to train models, and data protection impact assessments are likely to be required for many AI projects.

What about third-party models and open source?

Most AI products depend on third-party components. A product may call a foundation model through an API, be built on an open-weight model licensed on specific terms, and incorporate many open-source libraries. These components are not owned by either party, and their terms may restrict use, impose attribution or disclosure obligations, limit commercial use above certain thresholds, or prohibit using outputs to develop competing models. Some open-source licences require that modified versions, or software distributed with them, be made available under the same licence.

The agreement should require the developer to identify every third-party component, obtain the customer’s approval before introducing new ones, and confirm that the licence terms permit the intended use. The customer should consider whether it will hold the relevant licences and accounts in its own name, so that it does not depend on the developer to keep the product running, and how the product will be maintained if the underlying model changes or is withdrawn.

How should performance and acceptance be dealt with?

Because AI systems produce probabilistic outputs, a warranty that the product will be error-free or always accurate is unlikely to be realistic or acceptable to a developer. Acceptance testing is more effective when tied to agreed metrics, such as accuracy, precision and recall, measured against an agreed test dataset that is kept separate from the training data. The parties may also wish to agree requirements relating to bias and fairness testing, robustness, explainability, latency and cost.

Performance may change after acceptance, as data or the underlying third-party model changes. The agreement should therefore address monitoring, retraining and support, and the consequences if performance falls below agreed levels.

Warranties, indemnities and liability

The customer will usually seek warranties that the deliverables do not infringe third-party rights, that the developer has the right to use any data it supplies, and that third-party and open-source components have been disclosed. Because there is significant uncertainty about whether training AI models on copyright material, or their outputs, can infringe copyright (as we consider in our article on AI training and copyright), developers are often reluctant to give unqualified non-infringement warranties or uncapped indemnities. A realistic allocation may distinguish between risks within the developer’s control, such as the data it selects and the code it writes, and risks arising from the customer’s data or instructions or from third-party models. The scope of any IP indemnities offered by the third-party model provider should also be checked, as these may not extend to products built by a developer for its customer.

How does AI regulation affect the agreement?

In the EU, the AI Act imposes obligations according to a party’s role, in particular as the provider that places an AI system on the market or puts it into service under its own name or trademark, or as a deployer that uses it. A business that commissions an AI system and puts it on the market under its own brand will normally be the provider, even if a developer built it. Under Article 25, a party can also become the provider of a high-risk AI system if it puts its name or trademark on a high-risk system already on the market, substantially modifies it, or changes its intended purpose so that it becomes high-risk. Article 25(4) requires the provider of a high-risk AI system and third parties supplying AI systems, tools, services, components or processes used in it to specify, by written agreement, the information, capabilities, technical access and other assistance needed for the provider to comply.

Following the Digital Omnibus on AI, Regulation (EU) 2026/1744, which entered into force on 27 July 2026, the obligations for high-risk AI systems listed in Annex III apply from 2 December 2027, and those for AI embedded in products covered by EU product safety legislation from 2 August 2028. The transparency obligations in Article 50 have applied since 2 August 2026, subject to a transitional period until 2 December 2026 for marking AI-generated content from systems already on the market. Even where an AI system is not high-risk, the agreement should allocate responsibility for transparency, documentation, record-keeping and cooperation with regulators.

The UK has not introduced AI-specific legislation, and AI systems are regulated through existing laws and sector regulators, including data protection, consumer protection, financial services and product safety rules. A customer operating in a regulated sector will need the developer’s cooperation to meet its own obligations, such as explaining automated decisions or demonstrating appropriate testing.

Handover, exit and continuity

An AI product that cannot be maintained or retrained without the developer has limited value to the customer. The agreement should require delivery of source code, model weights, training scripts, data lineage records and documentation in a form that enables a competent third party to operate, maintain and retrain the system. Where the developer will host the system, the customer may wish to provide for escrow or transition assistance, and to ensure that accounts, repositories and cloud environments are held in its own name. Obligations on the developer to ensure that its personnel and subcontractors assign their rights, and to keep the customer’s data and models confidential, should survive termination.

AI development agreements: a practical checklist

For businesses commissioning or co-developing an AI product, a development agreement is likely to need to address:

• A full list of AI components, including models, weights, datasets, prompts and documentation.
• Ownership and licences. A present assignment of foreground IP, a sufficient licence of background IP, and limits on the developer’s reuse.
• Purpose limitation, ownership of derived materials, provenance of developer-sourced data, data protection terms and deletion.
• Third-party components. Disclosure and approval of third-party models and open-source software, and who holds the relevant licences.
• Measurable acceptance criteria against an agreed test dataset, and ongoing monitoring and retraining.
• Risk allocation. Warranties, indemnities and liability caps that reflect the uncertainty around AI and copyright and the role of third-party providers.
• The parties’ roles under the EU AI Act and other applicable rules, and the information and assistance each must provide.
• Handover of code, weights, data lineage and documentation, and continuity of accounts and licences.

At Maybrook Law, we advise businesses developing, commissioning and investing in AI technologies on the legal and commercial issues arising throughout the development and commercialisation of their products, including technology development and co-development agreements, intellectual property, data protection and the use of third-party models, software and data. If you are negotiating an AI development agreement, or would like to discuss any of the issues raised in this article, we would be pleased to advise on your position.

This article reflects the law as at 12 August 2026. Our insights, articles and guides do not, and are not intended to, constitute legal advice or be an exhaustive review of all legal developments. Although every effort is made to ensure that the information provided in this article is accurate as of the publication date, please be aware that this area of law is developing rapidly and may be subject to change. Please seek legal advice before applying the information provided to any specific circumstances, transactions or legal issues.