An NDA is not a data license: what each agreement permits

A signed NDA can answer an important question: what may the recipient disclose? It can also restrict what the recipient does with the information. Neither answer should be inferred from the document's title. The actual wording determines whether the planned evaluation fits the agreed purpose or requires a further grant.

Consider Rightmark's public buyer NDA and terms. The NDA limits portal material to a purchasing decision: “Use it only to decide whether to license the data it describes.” The buyer terms separately explain that a data card is descriptive and that licensing requires an agreement signed by the owner and buyer. A buyer can learn about a collection under those terms without having acquired unrestricted rights to use it.

The difficult part is that an owner and a buyer can agree on the purpose while imagining different work. The owner may expect the first exchange to show what an archive contains. The buyer may need to test whether the records support a model task. Saying that both activities help evaluate a purchase does not settle whether the agreed purpose covers both methods. That is the point to resolve before the buyer spends time designing a test it cannot run.

The material matters as much as the method. A description of an archive, an extracted sample and the complete collection are different objects. A grant over a named sample leaves a different boundary from a grant over a defined collection and its updates. If someone replaces the sample with a larger export, the team needs to know whether that export is already covered. The word sample alone cannot answer.

For the buyer, useful scope is also an economic issue. Permission to inspect a file is worth little if the purchasing decision requires a test that the permission excludes. For the owner, agreeing to a useful test need not mean accepting every subsequent use. Put the proposed operation and the relevant wording beside each other. That gives counsel a specific interpretation to resolve, rather than asking whether the NDA looks normal.

An owner may want help finding a buyer well before it is ready to grant that buyer any rights. The engagement with an intermediary needs to explain what help is authorized and which decisions remain with the owner.

A Rightmark team member handling owner discussions made that distinction in a November 13 explanation of an offered engagement: “each deal is confirmed with you in writing first, and nothing goes to a buyer without your yes.” He was explaining an engagement that did not oblige the owner to sign a license. The appointment opened a commercial discussion; it did not settle the eventual licensing decision.

That is one arrangement. Rightmark's data licensing guide also describes code routes where signing covers future non-exclusive licensing. Advance authorization can be a deliberate choice. An owner using such a route needs to understand the rights already granted, rather than assume that every subsequent license will come back for another signature.

The difference changes whose answer a buyer needs. A broker retained to find interest and present offers can coordinate a request, but the owner may still have to authorize it. A broker empowered to grant defined rights can act within that delegation. The buyer should be able to trace the proposed use to the party granting those rights and, where relevant, to the authority behind the delegation. A long email thread with an intermediary does not establish that chain by itself.

Physical access is a separate issue. Rightmark's buyer diligence guidance explicitly distinguishes the ability to export a system from authority to grant a license. The person who can produce a file may be doing a technical job. That person should not have to interpret a commercial mandate from a request to upload the sample.

Billing adds another role. An invoice can identify where payment is due without explaining who granted the rights. If the intermediary handles both contracting and collection, the documents should make both capacities understandable. If it handles only collection, the buyer still needs the owner's grant or another valid authorization. This is why the person coordinating delivery, the party receiving payment and the party licensing the data should not silently become interchangeable in the team's records.

For the owner, the practical choice is how much authority to delegate. Retaining individual approvals preserves a decision on each offer, while a defined advance grant lets the intermediary act within an agreed scope. Neither arrangement should leave an engineer guessing whether a request from the broker is an instruction to export or evidence of permission to license.

The word evaluation describes a purpose, but it can leave the method almost entirely unstated. A technical team may mean checking whether an export parses correctly. It may mean using the records to answer questions through a retrieval system. It may want to adapt a model and compare the result. Those requests deserve a description that the owner, buyer and their advisers can all understand.

In its December 2025 analysis of AI data-license restrictions, Proskauer argues for specifying the intended AI activities and treating derived material carefully. Its drafting point cuts both ways: vague language can leave the grant narrower or broader than the parties intended. Simply adding “AI evaluation” to a purpose statement does not necessarily resolve that problem.

Consider this invented example; the owner, buyer, dates and permissions below are fictional. An owner offers a redacted support-ticket sample. The initial written permission allows the buyer's evaluation team to inspect fields, dates and completeness. It expressly excludes model-based retrieval tests and creation or retention of a reusable search representation.

The export passes that first inspection. But the buyer still cannot answer its purchasing question: can the ticket history help retrieve a relevant response to the kinds of support questions it receives? Its technical lead writes the following request. This is an invented operating note, not suggested contract wording.

Evaluation request, 13 November 2026

Material: tickets-v03.csv, the exact redacted sample already supplied. No other export or later version is included.

Operation: Build a temporary search index from that file. Run 20 questions written by the evaluation team. Record whether the three highest-ranked results for each question contain a relevant response. No model parameter updates are proposed.

Recipient and system: The buyer's designated evaluation team, in its own isolated test environment. No outside organization or external service receives the sample or index in this proposed test.

Retained output requested: Keep the index until the purchasing decision on 20 November so the team can rerun disputed results. Keep a results report containing question IDs and relevance judgments, without ticket text or an index that can be searched again.

Existing permission: Inspection of the sample's fields, dates and completeness only. It does not authorize this retrieval test or retention of the index.

Decision needed: Whether to authorize the test, who can access its index and report, and the proposed end of index retention. No retrieval test starts until those points are resolved in writing.

That request exposes a choice the phrase AI evaluation concealed. The buyer wants two outputs for two reasons: an index to rerun the test and a report to support the purchase decision. The owner can respond to each. It might accept the temporary index while refusing later reuse, or ask whether the team can finish its checks before the decision date. The buyer can then explain which restriction would prevent it from answering the purchasing question.

Suppose, still within this fictional example, the parties approve the specified test and index retention until 20 November. They also agree that the named team may retain the described report afterward, but no ticket text or searchable index. The engineer now has a concrete distinction to implement: the report can remain; the index cannot. Deleting the original CSV would not satisfy the agreed index-removal condition. Calling both outputs evaluation materials would erase the very distinction the parties resolved.

The report's contents also matter. In the request above, it contains question IDs and relevance judgments. If the team instead inserts full ticket excerpts to explain its scores, it has changed the output it asked to retain. It cannot rely on the approved description of an excerpt-free report to answer that new question. This follows from the fictional conditions chosen here; it is not a claim that every evaluation report needs the same restrictions.

This makes the commercial tradeoff visible without requiring the owner to design the test. A refusal to allow any meaningful retrieval work would leave the buyer with evidence about file structure but not evidence for its proposed use. An unrestricted right to keep and reuse the index would exceed the narrow test contemplated in this example. The request creates room to agree on useful work between those positions.

A buyer may reasonably object to a process that sends every ordinary action back for approval. If the collection, recipients and intended work are known, a grant that covers them together gives the team a basis for planning. Repeatedly negotiating fragments can instead leave it reconciling approvals written at different times for different people.

The licensee's side of this decision is expressed directly by Daniel Glazer, Henry Lebowitz and Jason Greenberg in their Practical Law article on data ownership and use: “It should ensure that the license is sufficiently broad to address all anticipated uses of the data.” They are referring to the data licensee. That is a serious qualification to an owner-focused argument for tighter control: the agreed grant has to support the buyer's work.

An actual public agreement shows how permissions and protections can sit together. Defined.ai's Data License Agreement puts its license grant and use restrictions in section 1, and confidentiality in section 3. Section 1(c) addresses commercial exploitation of models that have used the data for training, testing or benchmarking, while excluding commercialization of the data itself and imposing limits on making it available or producing recognizable contributor content. The same document can grant specified uses and restrict disclosure. Those are complementary jobs, not a reason to require a separate PDF for each.

A combined agreement is the stronger option when the parties can describe the intended relationship coherently. For example, an owner and buyer might be ready to identify a collection, define its updates, specify permitted model uses and name the recipients from the outset. A schedule can connect those choices to the main grant. The buyer then has a stable scope to work within, rather than needing to reopen an already-settled licensing decision whenever a delivery arrives.

Consolidation still requires reading the terms together. A broad grant may be limited by another section, and a disclosure exception may not permit the intended use. The task is to reconcile those provisions before the team relies on them. Putting inconsistent language in one file would simply move the ambiguity inside the contract.

A narrower initial permission wins when the technical scope is genuinely undecided. The buyer may need an inspection to determine which evaluation to propose; the owner may be willing to disclose a sample while withholding a decision on later uses. In that situation, a limited first step gives the parties information they lack. Once the work is understood, continuing to divide every permission into smaller approvals can create friction without preserving a decision the owner still needs to make.

Read an AI data licensing agreement with a concrete request beside it: share this sample, run this test or give this organization access. The following map separates the functions that can otherwise disappear inside the phrase the paperwork is done. It does not prescribe four documents or their order. A direct transaction may have no broker appointment, and one agreement may cover several rows.

Start with material that both sides can identify. A sample's label should connect to the collection and version being discussed. If the owner changes the sample, the reader should be able to see what changed and whether that affects the permission. Rightmark's provenance record can organize source periods, processing, exclusions and supporting references. It does not establish title or consent. Its role here is to help people discuss the same material.

Now consider a second invented example; the owner, buyer and agreement terms are fictional. The buyer's existing agreement expressly permits its evaluation team to run a specified model-based test on sample-b-v02, repeat that test and retain a defined results report. The team asks to rerun it after correcting an error in the test's scoring code. Assume the correction changes no agreed input, operation, recipient or retained output.

That request is already covered. A short decision note can point to the existing evaluation clause and record the unchanged sample and test scope. There is no unresolved licensing decision to send back to the owner under these assumptions. The technical team can correct its scoring error and repeat the work while observing the existing conditions.

Now change one fact: the team wants a separate organization to rerun the evaluation. Assume the agreement expressly excludes that organization's access. The problem is no longer the right to repeat the test. It is the proposed recipient. A request to add that recipient should identify the material and access it needs, rather than reopening every part of an otherwise usable grant. The sample stays with the permitted team until the required authorization is resolved.

The contrast is the reason to keep the decision note specific. It should record the requested action, the relevant collection or sample version, the permission relied on and any issue still open. In the first request, it records existing coverage. In the second, it routes a defined access decision to the person able to make it. It cannot create a right missing from the agreement; disputed scope or authority still needs counsel's interpretation of the actual terms.

An owner does not gain meaningful control from a stack of documents nobody can connect to the work. A buyer does not gain useful access from a confidentiality promise that leaves its intended test unresolved. The stronger arrangement lets each side see what can happen now, what remains undecided and which changes would require another decision.

Before the next licensing discussion, use Rightmark's data licensing agreement checklist to record the scope and permission questions the actual documents still need to answer.