AI Procurement Checklist for European Healthcare Buyers

TL;DR: 15-point vendor questionnaire for healthcare SMEs buying AI systems in Europe. Covers MDR, EU AI Act, GDPR, and clinical validation requirements.

Before your clinic, hospital department, or healthcare operations team signs a contract for an AI system, there is a specific window when your leverage is highest: the procurement moment. Why this matters is straightforward. Once the contract is signed, the data processing agreement is in place, and the system is live, your ability to impose compliance requirements on the vendor drops sharply.

This checklist is for that window. It is not a general EU AI Act overview. It is a buyer-side tool for operations leaders, procurement managers, and hospital administrators at small and mid-sized healthcare organisations evaluating a specific vendor or product right now. It covers the six documentation categories you must address before any signature, and it closes with a 15-point vendor questionnaire you can send verbatim.

Who This Is For

This applies to founder-led clinics, growing healthcare operations teams, and small business healthcare providers across Europe procuring any AI system that touches: clinical decision support, patient triage, diagnostic imaging analysis, administrative automation using patient records, or any system processing special category health data under GDPR Article 9.

If the AI system your organisation is evaluating touches any of those categories, all six documentation areas below apply.

Six Documentation Areas Before Any Signature

1. EU AI Act High-Risk Classification

The EU AI Act classifies AI systems used in healthcare that influence clinical decisions as high-risk (Annex III, point 5). Before signing, you need to confirm the vendor's own classification and whether that classification has been independently reviewed.

Ask the vendor:

Has this system been classified under the EU AI Act? Under which category?
If high-risk: has a conformity assessment been completed, and by which notified body?
Is a CE mark under the EU AI Act in progress, issued, or not applicable, and why?

A vendor who cannot answer these questions in writing is a vendor whose compliance posture you cannot verify. For professional services firms or mid-sized companies handling patient data at scale, an unverifiable compliance posture is a procurement-ending condition.

2. Medical Device Regulation (MDR) Status

AI systems that meet the EU definition of a medical device fall under MDR (EU 2017/745). Many clinical AI tools, including diagnostic support systems and image analysis tools, are medical devices regardless of how the vendor markets them.

Ask the vendor:

Is this system classified as a medical device under MDR? If not, on what basis is it excluded?
If classified: what is the device class (I, IIa, IIb, III), and what is the notified body?
Is the Declaration of Conformity available for inspection before contract signature?

The intersection of MDR and EU AI Act creates a dual compliance obligation for high-risk AI medical devices. Your legal counsel should review both before signature.

3. Data Processing Agreement Requirements

Under GDPR Article 28, any vendor processing personal data on your behalf must sign a Data Processing Agreement (DPA) before processing begins. For special category health data under Article 9, the DPA requirements are stricter and non-negotiable.

Your DPA must specify:

Subject matter, duration, and purpose of processing
Categories of data subjects and types of personal data
Vendor's obligations (confidentiality, security, sub-processor controls)
Data subject rights support (access, erasure, portability)
Breach notification timeline (72 hours to you; you then notify the supervisory authority)

Do not accept a vendor's standard template without review. Most vendor DPA templates are written to protect the vendor, not the healthcare organisation. For small businesses and growing healthcare operations teams without in-house legal capacity, a one-hour review by a GDPR-specialist solicitor at this stage is significantly cheaper than a supervisory authority investigation later.

4. Training Data Provenance

The data used to train a clinical AI system directly affects its reliability and potential bias. European healthcare buyers have the right to ask, and high-quality vendors will have documentation ready.

Ask the vendor:

What datasets were used to train this model?
Were those datasets collected with appropriate consent for AI training purposes?
What is the geographic and demographic distribution of the training data?
Has the model been validated on European patient populations specifically?

A system trained primarily on North American patient data and applied to European clinical populations carries demographic validity risk that may not be visible in the vendor's headline accuracy figures.

5. Clinical Validation Evidence

For any AI system involved in clinical workflows, you need prospective or retrospective clinical validation evidence, not just technical performance metrics.

Request:

Peer-reviewed publications or clinical study reports validating the system's performance
Sensitivity and specificity data for the clinical use case you are procuring for
Any known failure modes or population subgroups where performance degrades
Post-market surveillance data if the system has been deployed for more than 12 months

A vendor who offers only internal benchmarks without independent clinical validation is asking you to make a clinical governance decision based on marketing data. For hospital administrators at small clinics, the liability exposure of deploying an unvalidated clinical AI tool is not a risk worth accepting for a faster procurement process.

6. Incident Response Obligations

Under NIS2 (for entities in scope) and GDPR, your organisation has breach notification obligations. Your AI vendor's incident response obligations must be contractually specified before you can meet yours.

Your contract must include:

Vendor notification to you within 24 hours of any security incident affecting your data
Definition of what constitutes a reportable incident
Vendor's incident response contact (name, not just a helpdesk email)
Post-incident root cause analysis obligation
Business continuity and system recovery time commitments

The 15-Point Vendor Questionnaire

Send this verbatim as part of your procurement process. Request written responses. Verbal assurances at a demo are not compliance documentation.

EU AI Act and MDR Classification

Under the EU AI Act, how is this system classified? If high-risk, which conformity assessment procedure has been followed?
Is this system a medical device under MDR (EU 2017/745)? If yes, what is the device class and notified body? If no, what is the regulatory basis for exclusion?
Is the Declaration of Conformity (MDR) or EU AI Act technical documentation available for review prior to contract signature?

Data Processing and GDPR

Will you sign our Data Processing Agreement, or do you require us to sign yours? (Note: we require our DPA as the minimum baseline.)
Which sub-processors will have access to our patient data? Are they all located within the EEA, or are there third-country transfers? If third-country: what transfer mechanism applies?
What is your breach notification timeline to us as the data controller?
How do you support data subject rights requests (access, erasure, portability) relating to data processed through your system?

Training Data and Clinical Validation

What datasets were used to train this model, and were those datasets collected with appropriate consent for AI training purposes?
What is the demographic and geographic distribution of the training data? Has the model been validated on European patient populations?
Can you provide peer-reviewed publications or independent clinical study reports validating performance for our specific use case?
What are the known failure modes or population subgroups where model performance degrades?

Security and Incident Response

What is your contractual commitment for notifying us of a security incident affecting our data? (We require 24 hours or less.)
Who is the named incident response contact at your organisation for our account?
What is your system's recovery time objective (RTO) and recovery point objective (RPO) in the event of a system failure?

Ongoing Obligations

If you update the AI model after contract signature (retraining, architectural changes), what is your obligation to notify us, and do we have a right to re-evaluate before the updated model is applied to our data?

What to Do With the Responses

Score each response against three criteria: specificity (is it a concrete answer or a deflection?), documentation (is there a document you can review, or only a verbal assurance?), and contractual commitment (is it in the contract or just in the sales conversation?).

Any question answered with "we can discuss that in implementation" or "our standard terms cover that" should be treated as a red flag. The implementation phase is after signature. You need answers before.

For procurement managers at mid-sized companies without a dedicated legal or compliance team, the threshold for proceeding without specialist review should be low: if more than two of the 15 questions receive deflection responses, bring in a healthcare IT legal specialist before proceeding.

Frequently Asked Questions

Does this checklist apply to AI tools we build internally, or only to vendor products?

If your organisation commissions a custom-built AI system from a software development partner who will process patient data, the same documentation requirements apply: the development partner is a data processor under GDPR, the system may still be a medical device under MDR, and the EU AI Act applies to the deployer (your organisation) regardless of who built the system.

We are a small clinic with limited procurement resources. Do we really need all 15 questions answered?

Yes, but you can sequence them. Questions 1-3 (classification) and 4-7 (data processing) are non-negotiable before any contract discussion continues. Questions 8-11 (clinical validation) and 12-15 (incident response) should be resolved before contract signature. A vendor who refuses to answer any of the first seven questions is not a vendor you should be contracting with, regardless of the product's capabilities.

What if the vendor is a large company with an established European presence? Can we trust their standard compliance documentation?

Vendor size and market presence do not substitute for contract-specific documentation. Large vendors often have standard compliance packs that do not reflect the specific configuration, data flows, or use case of your deployment. Request documentation specific to your contract, not the vendor's generic compliance overview.

How does NIS2 interact with these procurement obligations?

If your healthcare organisation is in scope for NIS2 (the revised Network and Information Security Directive, mandatory for essential entities including certain healthcare providers from October 2024), you have additional obligations around supply chain security. This means vendor security posture is not just a GDPR question: it is a regulatory obligation. Your vendor questionnaire responses on incident response (questions 12-14) feed directly into your NIS2 supply chain risk assessment.

The AI Procurement Checklist Every European Healthcare Buyer Needs Before Signing

Who This Is For