Article
Most AI procurement contracts in healthcare are written by the vendor, for the vendor. That is not a complaint; it is a description of who holds the pen. The buyer's protection lies in the questions it asks before signing, and in healthcare those questions have a clinical dimension that a general commercial review will not cover. The seven below are the ones that matter most, and each is one that legal teams tend not to ask unless a clinician or an operations lead puts it in front of them.
1. Who is liable when the output is wrong and someone is harmed?
Read the limitation of liability clause and then read the clause that describes the tool as decision support requiring clinical judgement. Together they usually mean that the vendor has excluded liability for the very thing the tool does. That may be acceptable, but only if the organisation understands that it is carrying the clinical risk itself, has priced that into the decision, and has the oversight in place to manage it. Ask the question directly and get the answer in writing.
2. Where does the data go, who touches it, and can they learn from it?
Identify every processor and sub-processor, every location where data rests or is processed, and every international transfer. Then read the clause on the vendor's right to use your data to improve its models. Training on patient data is a new purpose with its own lawful basis requirements, and a right granted silently in a schedule is still a right granted. If the answer is that the vendor trains on your data, decide whether that is acceptable; if it is not, strike it.
3. What is the tool's stated intended purpose, and does its regulatory status match?
The contract should contain, or incorporate by reference, the vendor's intended purpose statement, its medical device status and class, and its DCB0129 clinical safety case. If any of these is missing, the organisation is buying a product whose regulatory position it cannot verify. Where the product is used in the NHS, the Digital Technology Assessment Criteria evidence belongs here too. A vendor who cannot produce these documents at contract stage will not produce them afterwards.
4. What can you see, and what can you ask for?
Audit rights, access to logs of what the tool did and who saw what, performance data across your own population, and notification of incidents affecting other customers that could affect you. Without these the organisation is operating a system it cannot inspect, which is a governance position no inspector will accept.
The clause you most need is the one the vendor least wants to write: what happens when the model changes.
5. What happens when the model changes?
AI products change continuously. A model retrained, a threshold adjusted, a feature added by update. Each can alter the tool's behaviour, its intended purpose and its regulatory status. The contract should require advance notice of material changes, describe what counts as material, give the organisation the right to test before accepting, and allow it to refuse or defer an update. A clinical safety case written against version three is not a safety case for version four.
6. How do you leave, and what do you take with you?
Notice periods, the format in which your data is returned, the vendor's obligation to assist with transition, certified deletion of what remains, and what happens to the outputs the tool has already written into your records. Exit terms are negotiated on the day of signing or not at all. An organisation that cannot leave has no negotiating position on price, on changes, or on anything else for the life of the contract.
7. What are the obligations when something goes wrong?
Service levels for availability are standard. Obligations around clinical safety incidents are not, and they matter more. The contract should set the timescale within which the vendor must report an incident or defect that could affect patient safety, require cooperation with the organisation's own DCB0160 investigation, and make clear who leads the response and who communicates with patients and regulators. A vendor whose contract is silent on this has not thought about it, or has and would rather you did not.
Two further points
Price escalation clauses in AI contracts are frequently tied to usage metrics the buyer does not control, such as tokens or API calls, and can rise sharply as adoption succeeds. And the contract should name the version of the tool being purchased and the date of the documents it incorporates, so that there is a fixed reference point when a dispute arises about what was promised.
None of these questions is hostile. A competent vendor will have answers to all seven and will respect a buyer who asks them. The vendor who bristles is telling you something.
This article sets out Novatib's advisory position. It is not legal or regulatory advice.