Private equity and portfolios
A portfolio company got an inbound data request: what the sponsor should do
By SourceX Editorial · Updated
Short answer
When an AI company sends a portfolio company an inbound data request, the sponsor should help the company slow down rather than answer on the spot. Follow five steps: send no files, route the request to the company's owner, run a metadata-only fit check, check rights and consents, then decide whether and how to proceed.
Key takeaways
- No records, samples or schema documents leave the company before a rights review and a signed agreement.
- The request belongs to the portfolio company's CEO or a named executive, with the sponsor informed and supporting.
- A metadata-only fit check shows whether the requested records exist, how far back they go and what restricts them.
- The first reply should acknowledge, ask questions and set the process, without numbers or files.
- An inbound request signals interest in a record type; it does not set the value or the terms.
Why inbound requests need a portfolio-wide playbook#
Inbound data requests need a portfolio-wide playbook because they arrive at the wrong desk. A request may reach a CTO through a professional network, a support inbox through a web form, or a CEO through a former colleague now working at an AI developer, and each recipient will improvise a different answer.
Improvised answers create avoidable risk. An engineer sends a small export to show good faith, a CEO signs a mutual NDA with a broad residuals clause, or a reply mentions a figure before anyone knows what the records contain. A one-page sponsor playbook keeps the response consistent across every company in the portfolio.
The five-step response#
The five-step response gives the portfolio company a calm sequence that protects its records and keeps every option open. The first two steps should happen as soon as the request arrives; the rest follow at the company's own pace.
The order matters. A fit check before the rights review avoids paying counsel to read contracts for records that turn out not to exist, and a rights review before the decision keeps the company from agreeing to a scope it cannot deliver.
- Send no files. No exports, samples, screenshots, schema documents or record counts go out until the rights review is done and an agreement is signed.
- Route the request to the owner. Forward it to the CEO or a named executive, copy the general counsel and tell the operating partner.
- Run a fit check on metadata. Confirm which systems hold the requested records, how many years remain accessible and whether records link requests to outcomes.
- Check rights and consents. Review customer contracts, vendor terms, privacy notices and employee policies, plus sponsor, board and lender consents.
- Decide. Proceed with the requester, widen the process to see who else is interested, narrow the scope, or decline.
What to say in the first reply#
The first reply should acknowledge the request, name a single contact and ask the requester to describe what it wants in writing. It should commit to nothing and should not describe the company's records in any detail.
A written description from the requester is useful in its own right. It shows which record families draw interest, and it becomes the first draft of the permitted-use language if the conversation continues.
| Include in the first reply | Leave out of the first reply |
|---|---|
| Thanks and a named contact at the company | Samples, screenshots or exports of any kind |
| A request for the record types, time span and format wanted | Record counts, customer names or system details |
| A question on intended use: training, evaluation or both | Any price, range or expectation of value |
| A question on exclusivity and term expectations | Agreement to the requester's NDA as drafted |
| A note that the company reviews rights before sharing anything | Promises about timing or approval |
What the fit check should capture#
The fit check should capture enough metadata to judge this specific request without opening a single record. Most answers come from the system owner, the account team and a quick look at admin settings, and none of them require exporting data.
Test the request against what the company actually holds. Requesters describe records in their own terms, and the gap between what they asked for and what exists is often the most useful finding.
| Question | Who answers | Why it matters |
|---|---|---|
| Do we hold the record family the requester described, and under what name? | System owner | A requested support conversation may be a ticket thread in one system and chat logs in another |
| Does our accessible history cover the time span requested? | IT | A request for many years fails if a past migration kept only recent records |
| Do the records link the request to a decision and an outcome? | Operations lead | Resolution notes, approvals and callbacks are usually what the requester is after |
| Whose information sits in the records: customers, clients, employees or partners? | Account management and HR | Each group brings its own contract, notice or policy to review |
| Is the requester already a customer, vendor or partner of the company? | CFO or account owner | An existing contract may already govern data use or create a conflict |
| Has anyone already shared material with this requester? | Whoever received the request | Informal demos or samples must be found and documented before talks go further |
Who owns the request inside the company?#
The request is owned by the portfolio company's CEO or an executive the CEO names, usually the COO, CFO or CTO. The sponsor stays informed because consents, lender covenants and consistency across the portfolio are its concern, but the company makes the decision.
IT and engineering help answer metadata questions about systems and history, and nothing more at this stage. The general counsel or outside counsel reads the requester's NDA and leads the rights review. Keeping the circle small also limits the chance that someone sends records informally to be helpful.
The operating partner's own task is narrower: confirm which sponsor consents apply, check whether the credit agreement restricts licensing company assets, and make sure the board hears about the request before any term sheet is discussed.
Illustrative: a request lands at a 3PL in a buy-and-build platform#
Illustrative: a fictional third-party logistics company, recently added to a sponsor's buy-and-build platform, receives an email from an AI developer asking for warehouse exception records and dispatcher notes. The VP of IT receives it and, following the platform's playbook, forwards it to the CEO and the operating partner without replying.
The fit check finds years of exception records in the WMS with reason codes and resolution notes, and dispatcher notes in the TMS that name shippers. The rights review shows that several large shipper contracts treat shipment information as the shipper's confidential information.
The CEO decides to continue with a narrower scope covering internal exception handling, with shipper identifiers removed and the restricted shippers excluded. The requester's NDA is revised to remove a residuals clause before any description of the records is shared.
Mistakes that turn a good request into a problem#
The costliest mistake is sending a sample to prove the records exist. A sample delivered without a license has no permitted-use terms, no deletion duty and no record of who approved it, and it cannot be recalled.
Other mistakes are quieter. Treating the first requester as the only option means the company never learns whether others want the same records, and offering a number before scoping anchors the conversation. Declining without a fit check can also discard a sound opportunity because one executive assumed the records were unusable.
A last mistake is letting the request define the scope. Requesters ask for what they know exists; the fit check often finds that a neighboring record family, such as resolution notes rather than raw tickets, is both more useful and easier to clear.
How SourceX handles an inbound request#
SourceX can take an inbound request and run it through the SourceX five-step transaction. Supply starts with a metadata-only fit check, Rights covers contracts and consents, Preparation removes personal and confidential details, Approval sits with the company's authorized signer, and Delivery happens only under signed terms.
The SourceX Evidence Packet then documents provenance, licensing rights, permitted use, the privacy record and release authorization, so the sponsor holds the same kind of record for every portfolio company that answers a request.
Frequently asked questions
Should the company sign the requester's NDA?
Read it before signing. Check whether it is mutual, how it defines confidential information, whether a residuals clause lets the requester use what its staff remember, and how long obligations last. Counsel can usually narrow an NDA quickly, and it should be in place before the records are described.
Is an inbound request a sign the records are valuable?
It is a sign that someone is interested in a record type. Value depends on scope, history, linkage to outcomes, rights and the terms of use, none of which a first email reveals. A fit check gives a more reliable view than the request itself.
Can we ask the requester what it expects to pay?
You can ask how it usually structures deals and whether the request has a budget behind it. Avoid offering a number of your own before scoping, because the company does not yet know what it can license or under which restrictions.
What if the request comes from our own software vendor?
Treat it differently. A vendor asking to use your records for its own AI features is relying on its terms of service with you, not a new license. Check what the current terms already allow and whether you can opt out, then respond through the account owner.
Should other portfolio companies hear about the request?
Share the playbook, not the details. Other companies benefit from knowing how to respond, but the requester's identity and terms may be confidential, and companies that compete should not exchange information about their records or pricing through the sponsor.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.