Field notes from the data supply layer.

Why the next AI data advantage is hidden in workflows

A text response can tell a model what the final answer looks like. A real workflow can show what it takes to get there: the initial request, tools selected, decisions made, failure states, corrections, and evidence of success.

For an agentic software assistant, that might include a bug report, a sequence of diagnostic commands, a code change, a test run and the final verification. For a customer support assistant, it might mean the original issue, customer context, system actions, escalation reason and confirmed resolution. Those intermediate steps carry learning signals a final answer cannot capture alone.

Three useful design questions

• What action sequence should the model learn—not simply what answer should it produce?
• Which artifacts or checks make the outcome verifiable?
• Which parts of the workflow can actually be licensed and shared?

The commercial challenge is to obtain appropriately authorized records while keeping the context that makes the examples valuable. That is why source access, licensing terms and acceptance criteria must be designed together.

Access is not a license: what data buyers should ask

Many organizations have rich data inside customer, operational, or technology systems. But holding a copy of information is different from having authority to license it for third-party model training or evaluation.

Before closing a sourcing transaction, buyers and suppliers should understand who owns the relevant rights; whether contracts with customers, platforms, employees or contractors limit sharing; whether personal data is involved; and exactly which AI uses are contemplated. The negotiated license should reflect the intended use rather than relying on vague references to analytics or research.

Five questions to put on the table

• Who created and controls the underlying content?
• Does the proposed source have authority to sublicense or transfer it?
• Does the license cover the buyer's training, evaluation, adaptation, retention and distribution needs?
• What personal, confidential or third-party information must be excluded or handled under additional controls?
• What source and transformation records will accompany the delivery?

These are practical commercial questions, not a substitute for legal advice. The more precisely they are answered up front, the fewer surprises appear after a buyer has integrated a dataset.

What should a pilot dataset actually prove?

The purpose of a pilot is not simply to demonstrate that files can be transferred. It is to determine whether a sourcing mechanism can repeatedly deliver usable units of data at acceptable cost and risk.

Begin by documenting the smallest valid data unit: perhaps a complete tool-use trajectory, a labeled call segment, a document with verified fields or a video clip with relevant context. Define a sample size sufficient to expose common mismatches without committing to an expensive program.

What to review before expanding

• Accepted units as a share of delivered units, with reasons for rejection.
• Completeness of required fields and coverage of requested scenarios.
• Rights documentation and constraints on downstream use.
• Effort needed for normalization, annotation and remediation.
• Supplier ability to replenish similar examples and sustain quality.

A good pilot can lead to scale—or reveal that a source is not viable. Both outcomes are valuable when the goal is to avoid speculative acquisition.

How to write a useful AI data acquisition brief

Strong briefs explain why the examples matter. Rather than requesting “100,000 documents,” specify what the model needs to learn, how the examples will be used, and which properties distinguish valuable records from irrelevant ones.

Describe the unit of data, desired distribution and exclusions; provide a sample schema if possible; explain any label, resolution, or verification requirements; and establish the intended license scope. Also state practical constraints such as region, language, delivery mechanism, pilot budget and timeline.

Keep the first discussion focused on high-level requirements. Sensitive source data, credentials, customer records, and confidential documents should only be exchanged after appropriate security and contractual arrangements.