Software acquisition due diligence: AI and data rights questions to add

Why standard software diligence misses AI and data rights#

Standard software diligence focuses on architecture, code quality, open source licenses, security and scalability, and it rarely asks what the target is allowed to do with the records its customers create. For a buy-and-hold software acquirer that gap matters, because the thesis often assumes the group can use support history, usage records and engineering history in new AI features.

The answers sit in places a code review never touches: the master subscription agreement template and its negotiated versions, the data processing addendum, model vendor terms and any side agreements the founder signed with partners. A short, separate question set gets those documents into the data room early.

The six question groups to add#

The six question groups cover what the target already does with AI and what it is permitted to do with its records. Each group has one core question and a document that answers it, so the deal team can track gaps instead of collecting narrative answers.

AI features and model vendors: what to ask#

AI features and model vendors should be reviewed together, because a feature's risk depends on where customer content goes after the user clicks. A support summarizer that sends ticket text to a hosted model raises different questions from a forecasting feature that runs on the target's own aggregated tables.

Retention and training settings often differ between a provider's consumer, team and enterprise plans, so ask for screenshots or exports of the actual account configuration rather than a link to the provider's public policy page.

• 1List every feature that calls a model, internal or third party, with the release in which it shipped.
• 2For each feature, name the customer content sent, such as ticket text, attachments, call transcripts or records from the customer's own database.
• 3Confirm the provider's data settings: whether inputs and outputs are retained and whether the provider may use them to improve its models.
• 4Check that the subprocessor list in the data processing addendum names each model provider, and whether customers were notified when it changed.
• 5Ask whether any enterprise customer signed an AI addendum or opted out of AI features, and how the product enforces that choice.

Reading customer contracts for training and AI clauses#

Customer contracts decide whether the target may train on customer records, and most software companies have several generations of terms in force at once. Early customers may sit on a short click-through, while later enterprise customers negotiated their own data language.

Ask the target for a contract abstract that lists each customer's governing terms version and any data or AI clause, with references. Then spot-check the abstract against the signed contracts for the largest accounts, since abstracts prepared for a sale tend to smooth over exceptions.

Data exports and prior licenses#

Data exports matter because records the company cannot extract with their links intact are worth less, whether for internal AI or a later license. Ask the target to test an export of issue history from Jira or Linear, pull requests and review comments from GitHub or GitLab, and tickets from Zendesk or Intercom, and to confirm that issue keys and ticket references survive.

Prior licenses are the quieter risk. Founders sometimes sign benchmarking agreements with industry associations, data partnerships with channel partners or early data deals with AI developers. Read each one for exclusivity, field of use, term, survival after termination and whether the counterparty may keep models trained on delivered records.

Illustrative: a software holding company reviews a landscaping software target#

Illustrative: a fictional vertical software holding company is buying a scheduling and billing platform used by commercial landscaping firms. Standard diligence comes back clean, so the head of M&A adds the six question groups to the request list.

The contract abstract shows three generations of terms. The oldest customers accepted an aggregated data clause, the middle group's terms are silent, and a handful of large customers negotiated no-AI addenda. The support summarizer sends ticket text to a hosted model under a team plan with limited retention, and the founder signed a non-exclusive benchmarking agreement with a trade association covering aggregated job data.

The acquirer adds a representation listing all prior data grants, a schedule of customers with AI restrictions and a pre-closing covenant to move the summarizer to an enterprise account with stricter data settings. After closing, only records from customers whose terms support the use enter any AI or licensing plan.

Red flags that should change price or structure#

Red flags in AI and data rights diligence rarely end a deal, but they should change the price, the representations or the post-closing plan. Raise each one with deal counsel as soon as it appears.

• 1The target trained a model on customer content under terms that are silent on that use.
• 2A prior data license grants exclusivity, survives termination or lets the counterparty keep trained models.
• 3No one can produce the model provider's actual account settings.
• 4The customer contract abstract does not exist or cannot be reconciled to signed agreements.
• 5Issue, support or code history was lost in a migration and cannot be exported with links.

How SourceX uses diligence answers after closing#

SourceX picks up where diligence leaves off. When a software company in a group decides to license engineering or support records, the SourceX five-step transaction starts with Supply and Rights, and the contract abstract and prior-license review from diligence shorten both steps.

Each package that proceeds gets a SourceX Evidence Packet covering provenance, licensing rights, permitted use, the privacy record and release authorization, so the customers and prior grants excluded at signing stay excluded at delivery.