Article
Vendor due diligence runs in one direction. Before a healthcare AI vendor invests time in a prospect, it establishes whether the organisation has budget, a decision-maker, an integration route and a plausible timeline. What it does not establish, because it has no commercial reason to, is whether the organisation's data can support the product it is about to buy. That question is left to the buyer, and most buyers do not know to ask it.
The result is a familiar pattern. The demonstration is run on clean, curated data and works well. The contract is signed. Implementation begins, and the tool meets the organisation's actual records: inconsistent coding, free text where structure was assumed, fields blank for a year after a system migration, consent recorded in a form that does not cover the new use. The tool underperforms, the vendor points to the data, and the organisation discovers that the readiness work it skipped has become remediation work at three times the cost.
Four questions to answer before signing
Does the data exist in the form the tool needs?
Most AI tools assume structure: coded diagnoses, medication lists in a standard vocabulary, observations in discrete fields, dates that are populated and correct. Many organisations hold this information as free text in progress notes, or in a mixture of legacy and current coding, or in scanned documents. The gap between the data model the vendor demonstrated on and the data model the organisation actually has is the single largest predictor of whether the tool will work in production.
Is the data of sufficient quality?
Completeness, consistency and accuracy vary across sites, teams and time. A system migration three years ago may have left a period of unreliable records. One clinic may code meticulously and another not at all. AI tools tend to fail at the margins, and the margins are where data quality is worst and where clinical uncertainty is highest. A quality assessment does not need to be exhaustive; it needs to be honest about where the tool's inputs are weakest.
Is the processing lawful and governed?
Introducing an AI tool creates new data flows, new purposes and often new processors. Each needs a lawful basis under UK GDPR, a data protection impact assessment where the processing is high risk, a processing agreement with the vendor and any sub-processors, and attention to Article 22 where decisions with significant effects are automated. NHS data brings further obligations, including the Data Security and Protection Toolkit and the national data opt-out. Information governance retrofitted after go-live is possible but slow, and in the interim the organisation is processing unlawfully.
Can the infrastructure carry it?
Integration with the record system, identity and access management, audit logging of who saw what, and the network and device estate to run the tool where care is delivered. A tool that works on the practice manager's laptop and fails on the ward is a tool that will be abandoned.
The vendor assesses whether you can buy. Only you can assess whether what you buy will work.
What a data readiness review looks like
It is not a large exercise. For a single tool and a single use case, a competent review takes days rather than weeks. It maps the data the tool requires against the data the organisation holds, field by field; samples the quality of the fields that matter most; traces the new data flows and identifies the governance each requires; and checks the infrastructure assumptions the vendor has made. The output is a short document that says either that the organisation is ready, or what would have to change first and what that would cost.
That document changes the negotiation. A buyer who knows their data gaps can ask the vendor how the tool behaves when a field is missing, can require a pilot on real rather than curated data, and can price remediation into the decision rather than discover it afterwards.
The question to put to the vendor
If the review is not possible before a decision is needed, one question to the vendor is at least revealing: what does the tool do when the input it expects is absent, wrong or in a different form? A vendor with a considered answer has met real data before. A vendor who says it does not happen has not.
This article sets out Novatib's advisory position. It is not legal or regulatory advice.