skip to main content
iatroX JournalClinical AI

Buying Sovereign Clinical AI: 12 Questions for NHS Teams and Private Clinics

Featured image for Buying Sovereign Clinical AI: 12 Questions for NHS Teams and Private Clinics

A useful supplier meeting should leave a clinical organisation with evidence it can evaluate, not merely confidence that the sales presentation went well. Sovereign AI makes that particularly important because a single word can encompass several different promises about ownership, data location and operational control.

The twelve questions below are an original procurement aid for NHS teams and private clinics. They do not replace legal, security or clinical-safety expertise. They help those discussions begin with a defined service and a usable evidence request.

The immediate context is Tandem Sovereign Health, but the questions should be applied consistently to any supplier. A clear, bounded answer is preferable to an impressive claim whose scope remains impossible to establish.

1. Who are we contracting with, and who provides the service?

Request the legal name of the contracting supplier and a clear account of the organisations supplying the application, infrastructure and model services. Where a partner distributes the product, ask which party owes the relevant support and processing obligations.

A useful answer connects each entity to a role. A list of logos does not establish contractual responsibility, and a parent company's reputation does not identify the entity that would handle an incident.

The follow-up is practical: who receives the organisation's instructions, and who can authorise a change to the service?

2. Exactly which functions does the sovereignty commitment cover?

Ask whether the commitment applies to documentation, coding, decision support, search, integrations and supporting processes. Identify exclusions and optional features explicitly.

Request a configuration schedule rather than a brand-wide statement. "The platform is sovereign" is weaker than a description connecting named functions, information categories and permitted routes.

A customer should be able to disable a feature that falls outside its requirements without assuming that every remaining feature behaves identically. Establish whether such separation is supported before making it a procurement condition.

3. Where does each processing stage occur?

Request a diagram covering capture, transcription, inference, storage, logs, backups and support access where relevant. The diagram should distinguish actual deployment from available alternatives.

Ask which locations are contractual commitments and which are current operational choices that the supplier may change. That distinction affects the organisation's ability to respond later.

The UK cloud-data explainer sets out why the locations and legal entities must be examined together. A storage-region answer is not a complete account of processing.

4. Who controls the encryption keys and privileged access?

Ask which organisation administers keys, who can grant access and what happens during recovery or support. Customer-held, supplier-held and cloud-managed arrangements should not be described as though they grant identical control.

A useful demonstration shows relevant access permissions, approval requirements and revocation. It should distinguish ordinary clinical users from administrators and support personnel.

The NCSC's shared-responsibility guidance is relevant because the division of security work depends on the service model, not merely on who owns the cloud provider.

5. Who can see identifiable information, and under what circumstances?

Request the access model for the main service and for exceptional activities such as troubleshooting. Ask whether access is limited to what the task requires and how consequential access is recorded.

The answer should also address people mentioned during a consultation, not only the registered patient. An audio or transcript may contain information about relatives, carers and interpreters.

A broad statement that information is encrypted does not explain authorised human access. Nor does a promise of restricted access establish that staff have been given a usable route for requesting support without copying records elsewhere.

6. What are the retention and permitted-use arrangements?

Separate raw audio, transcripts, drafts, approved outputs, technical records and support material. Ask what is retained, why, for how long and under which exception process.

Examine model training, product improvement, evaluation and service delivery separately. "Not used for training" does not mean "never retained" or "never processed by another service".

The NHS information-governance guidance provides a relevant basis for individual-care ambient workflows. The contract should make the actual arrangement understandable to staff and patients.

7. Which configurations have been clinically evaluated?

Ask for the tested model, product version, tasks, population, languages and reference standard. Request consequential errors and correction work, not only a headline average.

A note-generation benchmark does not automatically validate recommendations or coding. The task-specific evaluation matrix provides a way to map evidence to functions.

A useful answer distinguishes supplier testing from independent review and local evaluation. None should be mislabelled as another. Ask what evidence supports the configuration the organisation is actually proposing to buy.

8. How are model and product changes controlled?

Request the change process for models, prompts, retrieval sources, templates and integrations. Ask which changes trigger regression testing, local notification or renewed assessment.

The supplier should explain how a user or investigator can identify the relevant configuration after a concern arises. An undated promise to use the best available model is not a change-control policy.

Also ask what the organisation can do when it cannot accept an immediate change. The answer may involve a supported transition, a restriction or an alternative workflow; do not assume that indefinite version pinning is available.

9. What assurance applies to the actual intended use?

Request the relevant regulatory and clinical-safety documentation for each enabled function, along with its scope and limitations. A certificate should identify what it covers rather than act as a universal badge for future additions.

NHS England's AVT registry is self-certified. The national description makes clear that inclusion is not supplier endorsement or a commercial framework, and procurement remains with individual NHS bodies.

For applicable English NHS deployments, distinguish manufacturer-side evidence from the organisation's own deployment responsibilities. Private providers should establish the requirements applying to their specific service rather than borrowing an NHS label without examining its scope.

10. What happens during disruption or partial failure?

Ask about an unavailable model, failed sign-in, loss of connectivity and an uncertain record transfer. Those failures may require different responses.

A useful demonstration shows what remains accessible, what is pending and what staff should do next. It should not report a task complete merely because generation finished.

Establish whether alternative processing routes can be used and whether they remain within the approved terms. A service-level commitment and a local fallback plan answer different questions; both may be needed.

11. Can we leave without losing necessary information or control?

Request an export of representative synthetic material and test whether the intended destination can use it. Include the context required to interpret an output, not just the text itself.

Clarify migration support, charges, notice, deletion and any continuing access needed for lawful records or incident evidence. A contractual right to request data is weaker than a demonstrated ability to use the export.

The vendor lock-in guide explains how to assess switching effort without pretending that every integration can be moved without cost.

12. What is the complete cost of a usable clinical workflow?

Ask for a quotation covering licences, usage, implementation, configuration, support, training and exit. Identify minimum commitments, assumptions and optional features separately.

Then include the organisation's own work: review, correction, local assurance and reconciliation. A cheaper model call does not establish a cheaper consultation workflow.

A proposed business case should separate financial savings from released staff time and improved quality. Those benefits can all matter, but they should not be counted as though they are the same outcome. The worked sovereign-AI cost comparison demonstrates that distinction with explicitly hypothetical figures.

Turn the answers into a decision record

For each question, record the evidence received, the person who assessed it and the remaining condition for approval. Distinguish an unacceptable arrangement from an arrangement that remains unclear.

Do not turn the twelve answers into an arbitrary total score that overrides a critical unresolved issue. A product can perform well in most areas and still fail a requirement essential to the proposed service.

The result should explain why a particular configuration is suitable, what limits apply and who owns future review. That is a more useful procurement outcome than a page of green ticks beside words whose meaning changes between suppliers.

Frequently asked questions

Does registry inclusion mean an AI scribe is NHS endorsed?

No. The national registry is self-certified and does not replace local procurement or assurance of the proposed deployment.

Should suppliers disclose every proprietary technical detail?

Not necessarily. They should provide enough evidence, through appropriate arrangements, to substantiate the commitments and risks relevant to the customer.

Is one unanswered question enough to reject a supplier?

Its significance depends on the requirement. Record the gap and obtain clarification; a critical unresolved processing or safety issue should not be obscured by strengths elsewhere.

Explore clinical safety and implementation-readiness support

More from the Journal