Accessing proprietary industry data for university AI research

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

Three agreement types, and who signs for the university

The agreement type follows the money and the intellectual property, not the dataset. A principal investigator almost never has signature authority; the institution's sponsored programs office, research contracts office or technology transfer office signs, and the PI typically acknowledges having read the terms.

• Data use agreement (DUA) or data transfer and use agreement (DTUA). Use this when the company gives data and no funding. The Federal Demonstration Partnership (FDP) DTUA is a modular template, a face page plus standard attachments, designed mainly for transfers among universities and other research institutions. Editions circulate with data-type attachments, such as de-identified data and limited data set versions. Companies are outside the template's design center, so expect a for-profit supplier to redline it or insist on its own paper; confirm the current FDP edition with your contracts office.
• Research license. The company licenses records for a defined research purpose, sometimes for a fee. This is closest to how commercial buyers license data, and it usually carries tighter use, term and deletion clauses than a DUA. Our guide to AI data license terms explains the clause vocabulary.
• Sponsored research agreement (SRA) with data provisions. The company funds the work and supplies data. Here the data terms sit beside IP, background-rights and option clauses, which is where most academic-industry conflicts start.

For health data, HIPAA adds its own instrument: disclosure of a limited data set, which strips 16 categories of direct identifiers but can keep dates and some geography, requires a HIPAA data use agreement under 45 CFR 164.514(e) [2].

Choosing the instrument: a decision table

Pick the lightest instrument that still covers funding, IP and privacy obligations. Over-papering a simple data loan with an SRA invites IP negotiation you do not need; under-papering a funded project with a DUA leaves results ownership undefined.

Illustrative example: invented to show structure; it does not describe an available dataset.

When IRB review applies to de-identified commercial data

Properly de-identified business records often fall outside "human subjects research," but the IRB, not the PI, makes that call. Under the Common Rule (45 CFR 46.102(e)), a human subject is a living individual about whom an investigator obtains information through intervention or interaction and uses, studies or analyzes it, or obtains, uses, studies, analyzes or generates identifiable private information; information is identifiable when the subject's identity is or may readily be ascertained by the investigator. Check the current wording of 45 CFR 46.102 on eCFR before relying on it.

Commercial operational data breaks this neat line in predictable ways. Support transcripts contain names typed into free text, CRM exports carry account numbers in note fields, and call recordings carry voices. Bring the IRB the supplier's de-identification method description, a sample, and the DUA clause barring re-identification. Many IRBs will then issue a "not human subjects research" determination, which you should keep on file with the agreement.

Health-derived records need more care. HIPAA recognizes two de-identification methods, Safe Harbor (removal of 18 identifiers) and Expert Determination, and HHS notes that neither eliminates all re-identification risk [1]. Our comparison of Safe Harbor and Expert Determination for AI training covers which to require. Consumer data that a CCPA-covered business has deidentified carries the CCPA definition of "deidentified," which binds the holder to a public no-re-identification commitment and contractual obligations on recipients [4]; your DUA will likely inherit those obligations.

Publication rights: what to protect and what never appears in a paper

Your agreement must state, in plain words, that the university may publish results. Industry suppliers usually accept that if they get a short pre-submission review to remove their confidential information, not to veto findings. Typical academic positions:

• Review, not approval. The supplier reviews for its confidential information and for personal data, within a fixed window stated in the agreement. Many agreements treat silence after the window as consent.
• Deferral, not deletion. If the supplier needs to file a patent, it may request a delay of a defined length; it may not strike conclusions.
• Never in the paper. Raw records, verbatim free text that could identify a customer or employee, account or ticket identifiers, and any example quoted so precisely that a reader could search for it in the supplier's public channels.
• Attribution choice. Whether the paper names the supplier is a negotiated term. Default to "a US software company" unless permission is given in writing.

Theses deserve their own clause. Students must deposit dissertations, and embargo periods are limited, so confirm the agreement lets a thesis describe the dataset at the level of detail a committee expects.

Access controls universities must actually run

A data agreement is only as good as the lab's ability to enforce it on a rotating population of students, postdocs and visitors. Suppliers increasingly ask for controls that mirror enterprise practice:

• Named users. Each person with access is listed or approved, signs an acknowledgment and completes human-subjects or data-handling training where the institution requires it.
• Student and visitor rules. Undergraduates, visiting researchers and anyone on a non-university appointment often need explicit supplier consent. Clarify whether co-authors at other universities may touch data or only results.
• Secure environment. Store records in an institutional secure research enclave or controlled cluster partition, not on personal laptops or shared cloud drives. Disable outbound copying where feasible and log access.
• Model artifacts. Decide whether trained weights are "derivatives" of the data. If weights can memorize free text, the supplier may treat them as data and require deletion with it.
• Deletion at project end. Specify deletion of raw data, intermediate files and backups, plus a written certificate. Plan for archived backups that cannot be selectively purged.

ML engineers will recognize these as the same controls described in our guide on turning license terms into pipeline controls.

Reproducibility without releasing the data

Proprietary data and open benchmarks conflict, and the conflict should be resolved in the agreement, not at camera-ready time. Venues and reviewers expect artifacts; the supplier expects records to stay private.

Workable patterns include releasing evaluation code, prompts and scoring rubrics; publishing aggregate statistics such as label distributions and length histograms; releasing a small synthetic or hand-written look-alike set clearly labeled as such; and offering reviewers access under the same agreement inside your enclave. Well-known academic datasets such as ImageNet and the IAM Handwriting Database show the opposite pattern: open to registered researchers but restricted to non-commercial research [5][6]. A proprietary supplier will rarely go that far, so do not promise a public benchmark release in a grant application before the license allows it. For held-out evaluation design, see building a golden evaluation dataset from business records and how model evaluation teams protect private evaluation data.

When a commercial sponsor wants the model or the data rights

Keep the data license separate from the IP clauses. When one company both funds the lab and supplies data, sponsors sometimes argue that their data contribution entitles them to own the resulting model or to an exclusive license. Separate exhibits make the trade-offs visible: the data exhibit governs records, uses, term and deletion; the IP article governs inventions, software and weights under the university's standard option terms.

Watch three traps. First, "research-only" data used to train weights that a spin-out later commercializes; research-only scope rarely survives that move, and the licensing cluster covers converting it. Second, a student who joins the sponsor and assumes the lab's access travels with them; it does not. Third, conflict-of-interest disclosure when the PI holds equity in the sponsor. Counsel reviewing these deals can use our in-house counsel review guide for diligence structure.

A research data request template

A precise request gets faster answers from suppliers and from your own contracts office. Describe the data you need, not which companies you hope hold it.

Illustrative example: invented to show structure; it does not describe an available dataset.

research_question: "Does retrieval over resolved tickets reduce escalation errors in support agents?"
data_description: "B2B SaaS support tickets with full thread, resolution code, escalation flag"
time_window: "24 months"
volume_target: "50k-100k tickets"
fields_required: [ticket_id_pseudonymized, created_at, thread_text, resolution_code, escalated_bool]
de_identification: "names, emails, phones, account numbers removed or replaced; method documented"
human_subjects: "IRB determination requested: not human subjects research"
intended_uses: [model training, evaluation, publication of aggregate results]
access: "named users in institutional secure enclave; no student access without approval"
publication: "right to publish; supplier review window for confidential info"
deletion: "raw data and backups deleted at project end with certificate"
signatory: "Office of Sponsored Programs"

Our guide on writing a data request for suppliers explains each field, and if your project only needs held-out testing, read whether data can be licensed for evaluation only.

How SourceX fits academic requests

SourceX sources operational datasets from US companies on request and manages the commercial process, including the licensing agreement. It serves AI teams wherever they are based, and its data kinds include support and sales histories, engineering records, documents, finance and legal workflows, and new recordings of hands-on work. Every dataset is rights-reviewed for ownership and consents, personal details such as names, emails, phones and account numbers are removed or replaced before delivery with the method recorded and a sample checked, and every release is approved by the supplying company. Nothing is held in stock, and a request may not produce a match; SourceX's own dataset rights, including any training use, are set out in the signed supplier agreement. Research teams can describe their data needs on the buyers page. For the broader context, see the buyer team hub, de-identified data for AI training and the AI data hub.

Request proprietary industry data for your lab

SourceX looks for US businesses that hold the data you describe, assesses data and licensing permissions, and agrees pricing and allowed uses in a license before anything is delivered through a private, access-controlled workflow. Nothing is contracted until a supplier agrees, and terms are set per deal. Describe the industry data your lab needs.