What security questions to ask an AI data buyer before delivery

Why ask security questions before delivery?#

Security questions belong before delivery because the handover is the last moment you control the data directly. After that, protection rests on the buyer's practices and on what the contract obliges it to do, so the answers you collect should become contract terms rather than sit in an email thread.

The fifteen questions below fall into five groups. Your CTO or security lead usually asks them, and your counsel makes sure the answers land in the license agreement or its security schedule. A buyer with mature practices will usually answer in writing and may point you to an existing security report or completed questionnaire.

Storage and location: questions 1 to 3#

Storage questions establish where your records will sit, physically and logically. They matter for security and for any data residency commitments in your own customer contracts.

Location questions also connect to provenance standards. The Data & Trust Alliance's Data Provenance Standards list allowed and excluded processing and storage geographies among the use metadata a dataset can carry, alongside license to use and intended use, which gives both sides a shared vocabulary for writing location limits into the record.

Access, use and onward sharing: questions 4 to 9#

Access and sharing questions decide how many people, systems and outside companies will touch your records, and for what purpose. Subprocessors include anyone outside the buyer who may handle the data, such as cloud hosts, annotation vendors and evaluation contractors.

Good answers name roles rather than everyone on a research team, describe an approval step and confirm that logs exist. Pay attention to question 6: records licensed to train one kind of model should not quietly become input to unrelated products. The permitted use clause in the license is what gives that answer force.

Annotation and labeling vendors deserve a direct question, because they often involve people outside the buyer's staff working in separate tools. Question 9 overlaps with competitive use terms; counsel will usually want the license to restrict onward sharing of raw data outright and to address models trained on it explicitly.

• 14. Who will have access, by role, and how is access approved and reviewed?
• 25. Is access logged, and will logs be shared on request or during an audit?
• 36. Which systems will the data feed, and is use limited to the purposes in the license?
• 47. Which subprocessors will receive or access the data, and for which tasks?
• 58. Will we be notified before a subprocessor is added, and can we object?
• 69. Will the data, or models trained on it, be shared with affiliates or other companies?

Retention, deletion and proof: questions 10 to 12#

Retention questions set how long the buyer keeps your records and what evidence you receive when it stops.

Deleting raw files is easier to promise than deleting what was learned from them. Ask directly whether trained models are covered, and expect an honest buyer to explain that model weights are treated differently from raw data. The license should say so in plain terms rather than leave it implied.

Incident notice and audit: questions 13 to 15#

Incident questions decide how quickly you learn about a problem and what you can do about it.

Notification timing is negotiated deal by deal. What matters is that the contract names a timeline, a contact on each side and the minimum contents of a notice. For question 15, a current independent report such as a SOC 2 report, where the buyer has one, often answers several earlier questions at once.

• 113. How soon will we be notified of a security incident affecting our data, and through which contact?
• 214. What will a notice include: scope, records affected, cause and remediation?
• 315. Can we review evidence of your controls, such as an independent audit report or a completed security questionnaire?

Where each answer belongs in the contract#

Each answer belongs in a specific part of the license, and mapping them before negotiation keeps any of them from being lost between the security review and the final draft. Counsel will adapt the structure to the agreement in front of them; the table shows the usual home for each topic.

Keep the buyer's written answers as an exhibit or in the deal file even after they are turned into terms. If a later dispute turns on what was promised, the original answers show what both sides understood at signing.

Illustrative: a procurement software company puts the questions to a buyer#

Illustrative: a fictional procurement software company is preparing to deliver a package of Jira issues, pull requests and support escalations. Before signing, its CTO sends the fifteen questions to the buyer's security team, and the company's counsel tracks which answers must appear in the license.

Most answers come back clear. Two do not: the buyer plans to use an outside annotation vendor it has not yet named, and its deletion process covers primary storage but not backups. The company asks for advance notice and an objection right for new subprocessors, and for backups to age out on a defined schedule with a certificate at the end. Both terms go into the security schedule before delivery is approved.

How SourceX handles security before delivery#

SourceX places these questions in the Approval and Delivery steps of the SourceX five-step transaction. The supplier sees the buyer's answers before approving release, and the agreed terms are recorded with permitted use and release authorization in the SourceX Evidence Packet.

Large datasets stay in the supplier's own storage with controlled access or ship on encrypted drives; SourceX does not host multi-terabyte datasets. That keeps the number of copies small and makes the deletion questions easier to answer.