What a training-only licence should include

"Training only" sounds like a complete answer, but two words in a cover email are not a contract. A training-only licence earns its name through specific clauses: what the buyer may do, what it may never do, what is in scope, how the data is handled and what happens to the raw archive afterward. If any of those pieces is missing, the restriction is weaker than it looks.

What follows is a plain-English checklist of the terms we think belong in every licence of company data for AI. It is general information, not legal advice, and your own counsel should review any licence before you sign it.

The heart of the licence is the grant: the sentence that says what the buyer is allowed to do. In a training-only licence, the permitted purposes should be listed, not implied. Training and evaluation are the core, and in practice that covers model training, post-training, building reinforcement learning environments and running evaluations.

Listing the purposes matters because anything not listed should be outside the grant. A vague phrase such as "research and development" or "any lawful purpose" can stretch to cover uses nobody intended. A clear grant keeps the conversation simple later: either a use is on the list or it is not.

If the terms "RL environment" or "evaluation" are unfamiliar, our posts on what an RL environment actually is and evaluations that look like real work explain what labs build with this material.

A good licence does not rely on the grant alone. It also lists what the buyer may never do, so there is no argument that a use was merely "not mentioned." The prohibitions we include in every licence are:

• No marketing to anyone who appears in the data
• No profiling of individuals or companies in the data
• No contacting anyone in the data, directly or through others
• No attempt to re-identify any person or company behind a token
• No resale or onward supply of the data for marketing or people-search purposes

These clauses protect the people in the data as much as the seller. They are also what let a founder or liquidator explain the decision to employees and customers with a straight face. For more on that side of the question, see our employee privacy standard.

The licence should describe exactly which data is covered. That means the systems (for example Slack, email, Jira, GitHub, the CRM), the date range and any exclusions the seller has chosen, such as a specific client, a set of channels or a shared drive folder.

The timing of this matters as much as the content. In our process, scope and exclusions are agreed and annexed to the contract before any data moves. The seller is not trusting that a sensitive client will be removed later; the exclusion is part of the signed document from the start.

The licence should also record the default exclusions. HR, payroll, medical and legally privileged folders are excluded by default. Direct messages are excluded unless the company chooses to include them and has the right to do so.

A training-only licence should not stop at what the buyer does with the data. It should also say what form the data is in when the buyer receives it, and who can see the raw version along the way.

On anonymization, the useful standard is specific. Every person, company, address, email, phone number and account is replaced with a consistent token across every tool, so the same person carries the same token in Slack, email and Jira. Credentials, API keys, card numbers and government IDs are removed outright. Faces, logos and signatures are blacked out in images and PDFs. Our post on why the same person must get the same token everywhere explains why consistency matters for training.

On access, the licence should say that no third party touches raw data. Anonymization is done in-house, and the buyer only ever receives the anonymized output.

Before delivery, the seller should have the right to review an anonymized sample and confirm it meets the agreed standard. That review is the seller's chance to catch anything that looks wrong, such as a client name that slipped through or a folder that should have been excluded, before the dataset goes anywhere.

After sign-off, the raw archive should not linger. In our licences, the raw archive is deleted within 30 days of sign-off. That is written as a contract obligation, not a policy statement, and it ends with a deletion certificate the seller can keep on file.

Without a deletion clause, a training-only licence leaves an open question: where is the unredacted copy, and who could reach it? With one, the seller has a dated document that answers it.

Finally, the licence should be clear about the parties. The licensor is the company, and the person signing must have authority over company assets. For a company that is winding down, that may be a director, officer, liquidator or assignee, and we ask for the authority document up front. Payment goes to the company entity, never to an individual.

The commercial terms belong in the same document. Typical licences we arrange range from $20K to $400K+, depending on connection depth, years of history, headcount and the number of systems involved, and there is no firm number until the data has been counted. Payment to the company entity typically follows in 2–4 weeks.

Imagine a 90-person fintech operations company reading a draft licence. If it can find the grant, the prohibited uses, the annexed scope, the anonymization standard, the review step and the deletion clause, it is looking at a real training-only licence. If several of those are missing, it is looking at a promise.

If you would like to see how these clauses would apply to your company's systems and exclusions, book a 15-minute call. We will walk through scope, the review step and what the licence would and would not allow.