AI and Compliance in Healthcare: What to Resolve Before You Build
Compliance uncertainty stops more healthcare AI projects than budget constraints do. "We need to check with legal." "We're not sure about GDPR." "We'll wait until the regulatory picture is clearer." These are legitimate concerns expressed as indefinite delays. HIPAA, GDPR, and NHS Digital standards are navigable. The compliance questions that actually block healthcare AI are specific, answerable, and resolvable before the build begins — not after it stalls.
Compliance uncertainty is the most common reason healthcare AI projects stall before they begin — and the reason that most often should not be one.
"We need to check with legal" is a reasonable response to a specific compliance question. It becomes a problem when it is a response to the general category of compliance, deployed indefinitely to defer a decision that is actually about something else — budget, priority, leadership capacity, or organisational readiness. In these cases, compliance is being used as a proxy for uncertainty rather than as a specific obstacle to be resolved.
This article separates the compliance questions that genuinely require resolution before a healthcare AI build can proceed from the compliance concerns that are commonly cited but are not, in practice, blockers. It covers the three regulatory frameworks most relevant to mid-market healthcare AI — HIPAA (US), GDPR (UK/EU), and NHS Digital standards — and the four structural decisions that determine whether a healthcare AI system is compliant by design.
The conclusion is not that compliance is unimportant. It is that compliance uncertainty is not the same as a compliance barrier — and that for most healthcare AI applications in mid-market organisations, the compliance questions are specific, answerable, and resolvable before the build begins.
What Compliance Actually Requires in Healthcare AI
Healthcare AI compliance is governed by the same frameworks that govern healthcare data generally — with some AI-specific considerations layered on top. The core obligations are:
Data minimisation and purpose limitation. AI systems should use the minimum data necessary to achieve the specified purpose, and that data should not be used for purposes beyond what the patient consented to or what the regulatory framework permits. This is a design requirement, not a post-build audit: the data inputs to an AI system should be defined in the specification, with the legal basis for using each data category identified before development begins.
Accuracy and auditability. Healthcare AI outputs — particularly those that inform clinical decisions — must be accurate and the basis for their generation must be auditable. This does not require the AI to be infallible. It requires that errors can be identified, traced to their source, and corrected, and that there is a record of what the AI output was and how it was used in any given case.
Human oversight. For AI applications that inform clinical decisions, the regulatory frameworks in most markets require that a qualified clinician retains oversight of — and ultimate responsibility for — the clinical decision. AI that supports clinical decision-making is permissible in virtually all healthcare regulatory contexts. AI that replaces clinical decision-making entirely is subject to significantly higher regulatory scrutiny and, in most markets, specific regulatory approval requirements.
Data residency and security. Patient data must be stored and processed in accordance with the data residency requirements of the relevant jurisdiction (UK data for NHS patients must remain within the UK under NHS Digital standards; US patient data subject to HIPAA must be processed within HIPAA-compliant infrastructure). Security standards — encryption at rest and in transit, access control, audit logging — apply to all systems handling patient data.
These four requirements apply to virtually every healthcare AI system regardless of jurisdiction. The specific implementation of each requirement varies by framework — HIPAA, GDPR, and NHS Digital have different documentation requirements, different audit mechanisms, and different breach notification obligations — but the underlying compliance structure is the same.
HIPAA: What AI Changes and What It Doesn't
HIPAA's core requirements for Protected Health Information (PHI) do not change when AI is introduced. PHI must be handled by covered entities and business associates under appropriate agreements, stored securely, transmitted over encrypted channels, accessed only by authorised users, and audited.
What AI introduces is an additional category of consideration: the trained model itself. A machine learning model trained on PHI contains, in some sense, information derived from that PHI — and regulatory guidance on whether a trained model constitutes PHI or can be treated as de-identified is nuanced. For most mid-market healthcare AI applications — scheduling optimisation, documentation automation, claims processing — the model is not trained on identifiable individual patient data but on aggregate patterns. This distinction is worth establishing clearly in the compliance documentation before the build begins, but it is not a blocker for the categories of AI that mid-market healthcare organisations most commonly need.
The practical HIPAA compliance requirements for a new AI system are: Business Associate Agreement (BAA) with any third-party technology provider that will handle PHI, HIPAA-compliant hosting infrastructure, access control documentation, audit logging capability, and a documented data breach response plan. All of these are specifiable in advance and implementable as part of the build.
What is not a HIPAA blocker: The use of AI for administrative workflows (scheduling, intake, claims processing) that involve PHI but do not make autonomous clinical decisions. The development of custom software by a development partner operating under a properly executed BAA. The use of AI-generated clinical documentation where a physician reviews and approves the output before it is filed.
GDPR and UK GDPR: The Specific Requirements for Healthcare AI
GDPR classifies health data as a special category of personal data, requiring a higher standard of protection and a specific legal basis for processing. For healthcare AI in the UK/EU context, the relevant legal bases are typically: processing necessary for the provision of healthcare (Article 9(2)(h)), processing for the purposes of scientific research with appropriate safeguards, or explicit consent.
The AI-specific considerations under GDPR include:
Automated decision-making. Article 22 of GDPR restricts solely automated decision-making that produces legal or similarly significant effects on individuals — including, potentially, decisions about healthcare access or treatment. For AI that supports rather than replaces clinical decision-making, Article 22 is not triggered. A scheduling AI that prioritises waiting list patients does not make a solely automated decision — a clinician confirms the booking. A documentation AI that generates a note does not make a clinical decision — the physician reviews and approves it. These distinctions should be documented in the system's Data Protection Impact Assessment (DPIA).
Data Protection Impact Assessment. A DPIA is required for processing likely to result in high risk to individuals — which includes most healthcare AI applications processing special category data at scale. A DPIA is not a compliance barrier; it is a structured documentation process that identifies the risks of the system, the mitigations applied, and the residual risk accepted. It is completed before deployment and is a deliverable of the build process, not a precondition for beginning it.
Data residency. Under UK GDPR, personal data transferred outside the UK requires an appropriate transfer mechanism. For healthcare AI using cloud infrastructure, this means ensuring that the data processing stays within UK-compliant infrastructure or that an appropriate transfer mechanism (adequacy decision, standard contractual clauses) is in place.
What is not a GDPR blocker: The use of AI for healthcare administrative and operational applications where a clinician remains in the decision loop. The processing of patient data for scheduling, documentation, and claims purposes under the healthcare provision legal basis. The development of custom software by a UK-based development partner for a UK healthcare organisation processing UK patient data on UK infrastructure.
NHS Digital Standards: The Practical Requirements
For healthcare organisations operating within or alongside the NHS in England, NHS Digital standards — including the Data Security and Protection Toolkit (DSPT) and the Clinical Safety standards DCB0129/DCB0160 — set the compliance baseline for any system handling NHS patient data.
DSPT compliance requires annual self-assessment against a framework covering data security, data quality, and staff training. For AI systems handling NHS patient data, the DSPT assessment includes consideration of the AI system's data processing activities. This is a documentation and governance requirement, not a technical barrier — it requires that the organisation understands what data the system processes, how it is secured, who has access, and how it is audited.
Clinical Safety standards (DCB0129/DCB0160) apply to health IT systems that could directly or indirectly harm patients if they fail. DCB0129 applies to manufacturers of health IT systems (including custom-built software); DCB0160 applies to NHS organisations deploying health IT systems. For AI systems that support clinical workflows — documentation, scheduling, administrative triage — clinical safety assessment focuses on the failure modes of the system and the mitigations that prevent those failure modes from harming patients. This is a structured risk assessment, not a prohibitive standard.
What is not an NHS compliance blocker: The development of custom clinical software by a development partner who applies DCB0129 during the build. The deployment of operational AI (scheduling, documentation, claims) that supports clinical workflows without making autonomous clinical decisions. The use of cloud infrastructure that meets NHS Digital's data security requirements.
Compliance by Design: Four Structural Decisions
The most efficient approach to healthcare AI compliance is to resolve the structural compliance decisions before the build begins — in the specification phase — rather than to retrofit compliance onto a completed system.
Decision one: Data architecture. Define which data the system will process, the legal basis for processing each category, and the data residency requirements before the technical architecture is designed. A system designed from the start for UK data residency and NHS DSPT compliance is significantly less expensive to build compliant than a system designed without these constraints and retrofitted.
Decision two: Human oversight model. Define explicitly where human oversight is maintained in every clinical decision pathway. Document this in the specification. Build the system's architecture to make human oversight the default, not an optional add-on.
Decision three: Infrastructure and security. Select and specify the hosting infrastructure, encryption standards, access control model, and audit logging requirements before development begins. These are not afterthoughts — they are architectural decisions that affect the cost and timeline of the build if not resolved upfront.
Decision four: Data Subject rights mechanisms. Under GDPR, patients have rights of access, rectification, erasure, and portability in relation to their personal data. The system must have mechanisms to respond to these rights. These mechanisms are significantly cheaper to build in from the start than to add after deployment.
Compliance Uncertainty vs Compliance Barriers
The distinction that matters is between compliance uncertainty and a compliance barrier.
A compliance barrier is a specific legal requirement that the proposed AI system cannot meet — a use case that requires autonomous clinical decision-making in a market that prohibits it, or a data transfer requirement that cannot be met with available infrastructure. These are real and should stop the project or change its scope.
Compliance uncertainty is the absence of a definitive answer to a compliance question that has a definitive answer — one that can be obtained by completing the DPIA, reviewing the relevant regulatory guidance, or engaging a specialist. Most healthcare AI compliance concerns in mid-market organisations are of this type: not barriers, but questions that require work to answer.
The Xamun approach to healthcare AI builds compliance into the specification: every system built for a healthcare client is specified with the relevant regulatory framework in mind, the data architecture is designed for the applicable residency and security requirements, and the clinical safety assessment is completed as part of the build process. Compliance is a design requirement, not a post-build audit.
Compliance uncertainty is not a reason to delay. It is a reason to do the specification work — which is exactly where the compliance questions should be resolved.
Related reading: AI Readiness for Healthcare Organisations: A Self-Assessment → AI Strategy for Healthcare: Where Mid-Sized Clinics Should Start → What Is Spec-First Software Development? Why It Changes Everything →