On-Premises AI Phone Assistants for NHS GP Federations: A DSPT-Aligned Approach

For GP federations, primary care networks (PCNs) and at-scale general practice in the UK, the conversation around AI phone assistants has changed in the last 18 months. Where ICBs initially looked at consumer-cloud-style triage tools, they are now asking a sharper question: where does the patient data actually live? That single question is the one that pushes serious deployments toward an on-premises architecture rather than a multi-tenant cloud SaaS.

This article is written for digital leads inside Integrated Care Boards, primary care network clinical directors, and federation operations managers who are evaluating an AI receptionist deployment. It covers the practical reasons an on-premises deployment makes sense in NHS primary care, the integration points that matter, and the regulatory framework you will need to satisfy — DSPT, NCSC CAF and the patient data residency expectations that come with general practice.

What ‘on-premises’ actually means in an NHS context

The vocabulary gets blurred quickly. Suppliers describe their offerings as ‘UK hosted’, ‘NHS-grade’, ‘DSPT-aligned’ — none of which are the same as on-premises. A defensible on-premises deployment answers four very specific questions:

1. Where does the database live? On hardware owned or leased by the federation, sitting inside its own network, or on a shared cloud platform that the supplier controls?
2. Who owns the LLM provider account? Is it a local model, a federation-owned Azure OpenAI subscription, or the supplier’s shared model endpoint?
3. How does the telephony work? Are the SIP trunks the federation’s own (Gamma, BT Wholesale, Voicehost, TalkTalk Business), or a shared supplier-managed trunk?
4. What does the network topology look like? Can the platform sit inside the practice network, behind the same perimeter as EMIS or SystmOne? Is an air-gapped variant possible?

A genuine on-premises deployment will answer all four with ‘inside our perimeter’. That is the architecture that satisfies the toughest information-governance reviews.

EMIS, SystmOne and the integration that actually matters

An AI phone assistant adds little value if it can’t see the appointment book and the patient demographic record. In English primary care that effectively means integration with EMIS Web or SystmOne (TPP). A small minority of practices use Vision (Cegedim), but the volume sits with the two big players.

Integration patterns fall into three groups:

• HL7 v2 for legacy ADT-style messaging. Most practice systems support HL7 v2 natively, though the depth of support varies.
• HL7 FHIR (R4 and newer) for modern RESTful interactions. NHS Digital’s GP Connect specification is FHIR-based, and is the most reliable route for cross-practice data access in a federation context.
• GP Connect Appointment Management for booking, cancelling and amending appointments across practices in a federation. This is the single most operationally useful integration for an AI receptionist.

In an on-premises deployment, all of these integrations happen inside the federation’s own network. Patient demographic data does not need to traverse the public internet to a supplier’s cloud. For an ICB digital lead defending the architecture to information governance, this is the cleanest possible story.

The regulatory backdrop: DSPT, NCSC CAF, UK GDPR

Three frameworks shape what a GP federation can and cannot do with patient data in an AI context.

1. Data Security and Protection Toolkit (DSPT)

The DSPT is the annual self-assessment all NHS organisations must complete. For an AI phone assistant deployment, the relevant assertions cluster around data flows, third-party suppliers, and information asset registers. An on-premises deployment makes most of these assertions straightforward: the data flows are internal, the third-party supplier provides software (not data processing), and the asset register records hardware that is physically inside the federation.

2. NCSC Cyber Assessment Framework (CAF)

For ICBs aligning with the NHS England Cyber Strategy, CAF objectives A through D are the relevant ones. An on-premises deployment positions the federation as the data controller and the operator of the platform, which simplifies the ‘managing security risk’ and ‘protecting against cyber attack’ conversations.

3. UK GDPR & Common Law Duty of Confidentiality

The common law duty of confidentiality is the often-forgotten counterpart to UK GDPR. It applies whenever a patient shares information with a clinician or practice, and it is breached when that information is passed to a third party without a lawful basis — even if UK GDPR is satisfied. On-premises deployments avoid creating a new third-party processor in the first place.

The conversation that has played out repeatedly in 2025-2026 information governance committees: ‘Yes, the supplier is UK hosted, and yes, they have a DPA in place. But every patient call still flows through their infrastructure. Can we honestly say the information has not been disclosed?’ On-premises ends that conversation cleanly.

Cloud vs. on-premises for primary care

The point of this table is not that on-premises wins every cell — it doesn’t. Cloud deployments are faster to stand up and easier to scale. Where on-premises wins is in the rows that information governance teams care about most: data residency, third-party assertion complexity, auditability.

Three realistic primary care scenarios

Scenario 1: Federation of 14 practices, shared back-office

A federation that has invested in centralised digital infrastructure (shared EMIS hub, federation-wide appointment search, central PCN clinical co-ordinator) is the textbook fit. The AI phone assistant becomes a natural extension of an architecture that already treats the federation as a single operational unit. On-premises sits inside the existing technology pattern, not next to it.

Scenario 2: At-scale general practice / super-partnership

Super-partnerships and at-scale GP businesses tend to have a stronger digital function and a clearer commercial mandate. They are also more likely to be exploring 111-style triage AI, online consultations, and remote monitoring. On-premises lets them combine these workstreams behind one perimeter, with one set of integrations, rather than running parallel cloud silos.

Scenario 3: ICB pilot for OOH and 111 overflow

Integrated Care Boards experimenting with AI for out-of-hours overflow or 111 deflection have particularly high information-governance scrutiny. An on-premises pilot inside the ICB’s data centre allows the experiment to proceed without lengthy supplier-DPIA discussions. If the pilot works, the production rollout uses the same architecture — no migration shock.

What to clarify before go-live

1. Clinical system inventory. Which EMIS / SystmOne / Vision configurations are in scope? Which GP Connect endpoints are live across the federation?
2. Network topology. Where does the hardware sit? Is the HSCN connection sufficient? Which firewall rules need to be updated?
3. SIP and DDIs. Are existing DDIs being kept? Which SIP provider will carry the traffic? Are call-recording obligations clear and aligned with NHS England guidance?
4. LLM strategy. Local model in the federation rack? Federation-owned Azure OpenAI in a UK South tenant? Hybrid? Each has different latency, cost and information-governance profiles.
5. Identity management. NHSmail SSO, federation Active Directory, smartcard integration? The receptionist-facing interface needs to plug into the existing identity layer.
6. Backup and DR. How often is the PostgreSQL database backed up? Where do the backups sit? Is there a second site for disaster recovery?
7. DPIA and information governance. The DPIA needs to reflect the on-premises architecture. A template that simply describes a cloud SaaS will not pass review.

Common objections — and realistic answers

‘We don’t have the in-house IT to run this.’ — True for a single practice. Not true for most federations at eight or more practices, which either have a federation IT lead or use a managed-service partner. The install footprint is comparable to a clinical-system upgrade, not a data-centre programme.

‘We lose the rapid updates.’ — Partially true. On-premises updates happen in planned maintenance windows. In primary care, that is often a feature, not a bug — rapid surprise updates can break workflows during a busy Monday morning surgery.

‘What about scaling across 30 practices?’ — Primary care load profiles are highly predictable (morning rush, post-lunch rush, evening tail). Hardware can be sized accordingly, without the elastic scaling that suits a Black-Friday e-commerce site but not a federation.

‘It must be more expensive.’ — At one practice, yes. At 14 practices and 400,000 patient interactions per year, often not. Per-seat cloud costs scale linearly with volume; on-premises costs scale primarily with practices, and practices grow more slowly than interaction volume.

Closing thought

The on-premises versus cloud debate in NHS primary care will not be settled by a single technology argument. It will be settled by a combination of information-governance pressure, the realities of EMIS / SystmOne integration depth, and the political climate around patient data — all of which currently push at-scale federations toward on-premises for the deployments that matter.

The technology side has caught up. PostgreSQL, modern LLM providers with UK data residency, FHIR-based clinical-system APIs, federated identity — the pieces are mature. The remaining question is one of governance and commercial design, and that is the conversation worth having before procurement begins.

Related articles

• On-Premises AI for hospital chains and MVZ providers (German)
• AI phone assistants and German legal privilege (§ 203 StGB) for law firms (German)