1
What is technical due diligence?
Technical due diligence establishes what a buyer is acquiring, what it will cost to keep running, and which of the seller’s claims rest on something the buyer will still own after completion. It is not an award of marks against a maturity model. It is a set of findings, each attached to a consequence for price, for the plan, or for the conditions of completion.
Technical due diligence and technology due diligence are used interchangeably. Where a distinction is drawn, technology due diligence takes in the product and the roadmap, and technical due diligence concentrates on the systems, data and engineering practice beneath them.
2
Where did the data come from, and may it be used?
Provenance is the first question, because it is the one that cannot be repaired after completion. Records assembled from public sources, from customer activity or under a third-party licence carry different rights, and those rights are not always what the seller believes them to be.
Three matters warrant a written answer. On what terms was each material dataset obtained. Do the customer contracts permit the use to which the data is now put, including the training or tuning of models. And does any material dataset depend on a licence that terminates, or reprices, on a change of control. Where the answer is unclear, the value attributed to the data is unclear with it.
3
What is the model doing, and how would anyone know?
A model in production is a component whose behaviour shifts with its inputs. The question is not whether it performs well on the evaluation the seller has chosen to show, but whether anyone would notice if it stopped performing well.
Look for an evaluation set that was not selected after the results were known, a record of how performance has moved over the past year, and a defined procedure for what happens when a model is replaced or a provider changes a version beneath it. Where none of that exists, the target does not know how its own product behaves. This is a common finding and a manageable one, provided it is priced.
4
How much of the system belongs to somebody else?
Most systems now rest on external providers: model interfaces, cloud infrastructure, data feeds and open components. Dependence is not itself a fault. Undocumented dependence is.
The buyer should establish which providers the product cannot operate without, what a plausible price change from each would do to gross margin, and how long a substitution would take in weeks and in named staff. Where the product is a thin layer over a provider that also sells directly to the same customers, the report should say so rather than imply it.
5
What does the system cost to serve and to maintain?
Cost to serve is a commercial figure with a technical origin. It is the marginal cost of producing one more unit of output, including inference, retrieval, storage and any human review attached to it. In a business priced per seat or per subscription, a rising cost to serve moves margin quietly and is often discovered late.
Maintenance cost is the second figure, and it is measured in people rather than invoices. How many engineers are required simply to keep the present system working, and how much of their time is absorbed by defects arising from decisions taken years earlier.
6
Who answers for the output?
Where a system produces an output that a customer relies upon, somebody must be accountable for it. The examination establishes who reviews what, on what basis, and what record survives that review. It also establishes what the target has told its customers, because commitments about accuracy, human oversight or data handling become the buyer’s commitments at completion.
This is the point at which technical and legal diligence meet. The two workstreams should be made to compare notes rather than report in parallel.