Key Contract Terms in an AI Data Licensing Agreement

Before you read: a note on legal advice

This guide is general information, not legal advice. Contract law, IP law and privacy law differ between countries, and every agreement is different. Please have a qualified lawyer review any data licensing or purchase agreement before you sign, especially if your data includes personal information or material connected to clients.

It also helps to remember that the NDA and the main agreement do different jobs. The NDA, signed before any sample review, covers confidentiality, permitted use of samples, retention and security during evaluation. The main agreement governs the actual partnership: what is included, how it may be used, how it is transferred and processed, and what each side promises.

A useful habit is to read the draft with your own data inventory beside it. For each clause, ask what it would mean for a specific repository, workspace or table you plan to include. Abstract wording becomes much easier to judge when you test it against real examples.

Scope: exactly what is included

The scope clause should leave no doubt about which data is covered. Vague wording such as all engineering data invites disagreement. Better drafts list specific systems, repositories, workspaces, date ranges and exclusions, often in a schedule attached to the agreement.

• Named sources and date ranges.
• Explicit exclusions, such as client-owned projects or specific folders.
• Whether future data is included, or only what exists at signing.
• The de-identification standard the data will meet before further use.

Permitted use and model of the deal

Permitted use is where licensing and purchasing differ most. A licence typically grants specific rights, such as using the data to train and evaluate AI models, for a defined period, while you keep ownership. A purchase transfers more rights outright. A custom project partnership may mix both. Whatever the model, read the use clause closely.

Questions to ask include whether the data may be passed on to other parties, whether it may be combined with other datasets, whether the restrictions apply to the data itself or also to things derived from it, and whether any attempt to re-identify people or companies is prohibited. A clear prohibition on re-identification is a reasonable term to expect.

Also check how the agreement describes outputs. Models trained on many sources do not usually contain your data in a recognisable form, but some agreements address whether the receiving party may reproduce your data directly, publish it, or use it in ways other than training and evaluation. Clear limits here are worth having.

Security, retention and deletion

The agreement should describe how the data will be transferred, stored and protected, and who may access it. Retention terms say how long data may be kept and what happens at the end of that period. For a licence, look for what happens on expiry or termination: whether the data must be deleted or returned, and how that will be confirmed.

Be realistic about what deletion means for models already trained. Once data has been used for training, it generally cannot be pulled back out of a model, so ask your lawyer how the agreement treats models and outputs created during the permitted period.

Warranties, liability and indemnities

Warranties are promises each side makes. You will likely be asked to confirm that you have the right to provide the data and that providing it does not breach other contracts or laws. Think carefully before giving these, and do the ownership and privacy work first so you can give them honestly.

Liability and indemnity clauses decide who bears the cost if something goes wrong. Look at whether liability is capped, what is excluded from the cap, and whether indemnities run in both directions, for example covering misuse of the data by the receiving party as well as problems with your rights to provide it.

Points that deserve a second look

Most drafts are reasonable, but certain wording deserves extra attention from you and your lawyer. None of these is necessarily a problem on its own; they are simply places where the practical effect may be wider than it first appears.

• Scope defined by category, such as all communications, rather than by named sources and dates.
• Use clauses that say any purpose, or that allow sublicensing without limits.
• Automatic inclusion of future data or updates without a separate agreement.
• Warranties that your data is accurate or complete in every respect, which may be hard to give for historical records.
• No clear statement of what happens to the data on expiry or termination.
• One-sided liability, where you carry the risk of misuse by the receiving party.

Payment and other practical terms

Payment terms should state the amount or method of calculation, milestones such as on signing or on delivery, and any conditions attached, such as acceptance of the dataset after review. Other practical terms worth checking include confidentiality of the deal itself, whether either party can mention the partnership publicly, governing law and how disputes are resolved.

• Are payment milestones linked to clear, objective events?
• What happens if a delivered dataset is found to contain material outside the agreed scope?
• Can the agreement be extended to new data later, and on what basis?
• Which country's law applies, and where would disputes be heard?