Healthcare AI Compliance Checklist for UK Developers and Providers

There is no single UK compliance certificate that covers every healthcare AI system.

The requirements depend on what the AI is intended to do, who will use it, what information it processes, whether it influences care and where it will be deployed. An administrative assistant, a patient-facing chatbot and an AI diagnostic tool may all use similar technology while following very different regulatory and assurance routes.

Depending on the project, relevant areas may include data-protection law, medical-device regulation, NHS assurance, clinical safety, cybersecurity, equality, accessibility and post-deployment monitoring.

This healthcare AI compliance checklist helps UK developers and healthcare providers identify the areas requiring assessment before an AI system moves into production or clinical use.

This checklist supports initial planning and does not provide a legal, clinical-safety or medical-device classification.

Start by Defining What the Healthcare AI System Will Do

Compliance planning should begin with the intended purpose—not the model, platform or AI feature.

Before selecting technology or preparing an assessment, document:

• The problem the system is intended to solve
• Its intended purpose
• Target users
• Intended patient or service-user population
• Information and data sources
• Output produced
• Decision or workflow affected
• Level of automation
• Required human review
• Consequences of an incorrect result
• Organisations expected to use it
• Deployment environment
• Whether the system learns or changes after release

Vague descriptions such as “AI assistant for healthcare” are not sufficient. The compliance route may change significantly depending on whether the assistant finds internal policies, drafts administrative letters or recommends clinical actions.

Do not start by asking, “Which regulations apply to artificial intelligence?” Start with:

What decision or action does this specific system support, and what could happen if its output is wrong?

1. Could the AI System Be a Medical Device?

Not every healthcare AI system is a medical device. However, an AI system may fall within medical-device regulation depending on its intended purpose and functionality.

Potential indicators include software that:

• Supports or performs diagnosis
• Predicts disease or clinical deterioration
• Calculates an individual’s clinical risk
• Recommends treatment
• Monitors a medical condition
• Controls or influences a medical device
• Provides information used for an individual clinical decision

A tool used only for general administration may follow a different route from software that analyses an individual’s symptoms and recommends a clinical response.

The intended purpose should be clear and consistent across:

• Product requirements
• User instructions
• Website and marketing claims
• Technical documentation
• Training materials
• Contracts
• Actual system behaviour

Restricting marketing language will not necessarily keep a product outside medical-device regulation if its real functionality and intended use indicate otherwise.

Where the system may qualify as a medical device, the manufacturer may need to consider:

• Medical-device classification
• Quality-management processes
• Clinical evidence
• Risk management
• Technical documentation
• Conformity assessment
• Registration
• Post-market surveillance
• Incident reporting
• Change control

Market-access requirements may also differ between Great Britain and Northern Ireland. The appropriate route should be confirmed for the markets in which the product will be supplied.

The MHRA provides current guidance on software and AI as a medical device. Specialist regulatory advice should be obtained where classification is uncertain.

Completing an NHS assessment or participating in a regulatory sandbox does not replace applicable medical-device requirements or constitute general regulatory approval.

2. Does the AI Process Personal or Health Information?

An AI healthcare project may create data-protection responsibilities even when it is not a medical device.

Map the information processed across the complete AI lifecycle:

• Collection
• Preparation
• Model development
• Testing
• Deployment
• User interaction
• Logging
• Monitoring
• Retention
• Deletion

Data-protection checklist

• What personal data will be processed?
• Does it include health, genetic, biometric or other special-category information?
• What is the purpose of the processing?
• What lawful basis applies?
• Which special-category condition applies?
• Is patient or service-user consent relevant?
• Is the information used for direct care, research, product development or another purpose?
• Is a Data Protection Impact Assessment required?
• Has data minimisation been applied?
• Are individuals informed appropriately?
• How is data accuracy managed?
• How long will prompts, outputs and logs be retained?
• Are international transfers involved?
• Are processors and subprocessors identified?
• Can individuals exercise their information rights?
• Is solely automated decision-making involved?
• Are security controls proportionate to the risk?

Consent should not be presented as the universal answer. Depending on the circumstances, another lawful basis and special-category condition may be more appropriate. The organisation must assess the specific processing rather than choosing a basis because it appears convenient.

Where appropriate, involve:

• Data Protection Officer
• Information-governance lead
• Caldicott Guardian
• Clinical Safety Officer
• Legal adviser
• Research governance team
• Security specialists
• Relevant data controllers

NHS England’s current AI information-governance guidance advises involving information-governance professionals, the DPO and Caldicott Guardian when deciding to implement AI or share data for its development.

The ICO’s AI and data-protection guidance is being reviewed following recent legislative changes. Organisations should consult the latest ICO guidance on AI and data protection rather than relying on an outdated internal checklist.

3. Will the AI Be Deployed in an NHS Environment?

There is no single process that makes an AI product “NHS approved.”

An NHS-facing system may need to address several requirements depending on the product, integration, customer and deployment.

These may include:

• Digital Technology Assessment Criteria
• Data Security and Protection Toolkit
• DCB0129
• DCB0160
• NHS service standards
• Accessibility
• API-specific onboarding
• Information governance
• Technical security
• Interoperability
• Local clinical-safety assessment
• Procurement and commercial assurance
• Medical-device regulation where applicable

Different NHS organisations may also request evidence according to their local procurement, risk and deployment processes.

Understand What DTAC Does

The Digital Technology Assessment Criteria helps NHS and social-care organisations assess digital health technologies across areas including:

• Clinical safety
• Data protection
• Technical security
• Interoperability
• Usability and accessibility

DTAC is not a universal AI certification. Completing it does not automatically:

• Make a product NHS approved
• Guarantee procurement
• Replace medical-device requirements
• Replace local clinical-safety responsibilities
• Confirm that every deployment is appropriate
• Remove the need for supplier due diligence

Evidence should relate to the product being assessed, its intended use and the version being supplied. Generic company policies may not be enough where product-specific evidence is required.

As of August 2026, organisations should use the current DTAC 2.0 form, published in February 2026.

4. Have Clinical-Safety Responsibilities Been Assigned?

Healthcare AI can change how information is interpreted, prioritised and acted upon. Clinical-safety assessment should consider the complete workflow, including how users respond to the output.

For health IT systems within scope, DCB0129 and DCB0160 address different responsibilities.

DCB0129: Development and Manufacture

DCB0129 concerns organisations responsible for developing and maintaining health IT systems.

Activities can include:

• Establishing a clinical risk-management process
• Appointing an appropriately qualified Clinical Safety Officer
• Identifying clinical hazards
• Assessing risks
• Defining risk controls
• Maintaining a hazard log
• Verifying that controls have been implemented
• Producing a clinical safety case
• Managing safety throughout development and maintenance
• Assessing the safety effect of product changes

DCB0160: Deployment and Use

DCB0160 concerns health organisations deploying and using health IT systems.

Activities can include:

• Assessing the local clinical workflow
• Identifying deployment-specific hazards
• Reviewing interactions with existing systems
• Defining local controls
• Training users
• Monitoring the system in use
• Managing local modifications
• Responding to safety incidents
• Planning decommissioning

A supplier cannot remove the healthcare provider’s deployment responsibilities simply by stating that the product is compliant with DCB0129.

Similarly, a technically well-designed product can still be deployed unsafely if an organisation changes roles, processes or decision points without assessing the local consequences.

NHS England explains the respective responsibilities in its current clinical risk-management standards.

5. Is There Appropriate Evidence That the AI Works?

A demonstration or internally successful proof of concept does not establish that an AI healthcare system is ready for clinical or operational deployment.

The evidence required depends on:

• Intended purpose
• Risk
• Patient population
• Type of output
• Consequence of failure
• Medical-device classification
• Deployment environment
• Claims made about the system

Evidence checklist

• Is the intended claim precisely defined?
• Is the test population relevant to intended users?
• Is the dataset sufficiently representative?
• Is the comparator or baseline appropriate?
• Are the performance measures meaningful for the use case?
• Are false positives and false negatives assessed separately?
• Are uncertainty and failure conditions documented?
• Has performance been evaluated across relevant groups?
• Is independent or external validation required?
• Has the system been assessed in the intended workflow?
• Have human interactions with the output been evaluated?
• Can the results be reproduced?
• Are limitations communicated clearly?
• Is performance reassessed when the model, data or workflow changes?

Do not rely on one headline “accuracy” percentage.

For example, 95% overall accuracy may still conceal an unacceptable false-negative rate, poor performance for a particular patient group or results produced using data that does not represent the intended setting.

The evidence should answer whether the system performs well enough for its claimed purpose—not merely whether the model can generate an output.

6. Have Bias, Fairness and Health Inequality Been Assessed?

Healthcare AI can reproduce or amplify inequalities found in data, service access and existing clinical or operational processes.

Removing protected characteristics from the dataset does not automatically remove bias. Other variables may act as proxies, and existing patterns in the data may still reflect historical inequality.

Fairness checklist

• Which patients, employees or service users may be affected?
• Is the training data representative of the intended population?
• Are any important groups missing or underrepresented?
• Does performance vary across demographic or clinical groups?
• Could proxy variables create indirect discrimination?
• Could the system affect access to care or services?
• Could it increase workload for a particular group?
• Are language, disability and digital-exclusion needs considered?
• Is accessibility included in design and testing?
• Can users challenge or escalate an AI-supported outcome?
• Can human reviewers recognise unfair results?
• Will subgroup performance be monitored after deployment?

Relevant legal considerations may include the Equality Act 2010 and, for organisations within scope, the Public Sector Equality Duty. The exact duties should be confirmed for the organisation and use case.

An equality or health-impact assessment should influence product and deployment decisions. It should not be completed only as a document after the technical approach has already been fixed.

7. Are Security and Third-Party Dependencies Controlled?

Healthcare AI systems may depend on several external components:

• Cloud infrastructure
• Foundation models
• Model APIs
• Data platforms
• Vector databases
• Integration providers
• Monitoring tools
• Third-party datasets
• Open-source libraries

The security assessment should cover the complete system rather than only the application interface.

Security checklist

• Is access based on roles and least privilege?
• Is multifactor authentication used appropriately?
• Are development, testing and production environments separated?
• Is information encrypted in transit and at rest?
• Are audit logs protected and monitored?
• Are prompts and generated outputs retained?
• Can personal information enter third-party services?
• Are model and API providers identified?
• Are subprocessors understood?
• Are software dependencies maintained?
• Have relevant vulnerabilities been assessed?
• Has penetration testing been considered?
• Are API keys and secrets protected?
• Is there an incident-response plan?
• Can the AI feature be disabled without losing the entire service?
• Is business continuity addressed?
• Can data be exported or deleted when the contract ends?

Questions for AI Suppliers

• Where will information be processed and stored?
• Will customer information be used to train or improve models?
• Which settings control retention?
• Who are the subprocessors?
• Can the underlying model change without notice?
• How are material changes communicated?
• What audit evidence is available?
• How are security incidents reported?
• What happens if the model or API is withdrawn?
• Can the organisation retrieve and delete its information?
• Which responsibilities remain with the healthcare provider?

A supplier’s general claim that its platform is “secure,” “GDPR compliant” or “healthcare ready” does not establish that the proposed implementation is appropriate.

8. Is Human Oversight Meaningful?

“Human in the loop” is often used as a general safety assurance. It is only effective when the responsible person can meaningfully review and reject the output.

Effective human oversight requires:

• Relevant knowledge
• Sufficient time
• Access to the underlying information
• Understanding of the AI system’s limitations
• Clear responsibility
• Authority to reject or override the output
• Protection against automation bias
• Appropriate training
• Escalation routes
• Monitoring of whether review occurs in practice

Ask:

If the AI produces a confident but incorrect output, how will the reviewer recognise it?

A clinician cannot meaningfully verify a recommendation if the underlying evidence is unavailable or the workflow encourages rapid acceptance. Likewise, an administrator cannot reliably review a generated clinical letter without the knowledge needed to identify an error.

Human oversight should be designed into the workflow, tested and monitored. It should not be added to a policy simply to compensate for an uncontrolled risk.

9. Can Patients and Users Understand How AI Is Involved?

People should not be misled about whether they are interacting with AI or how it affects a service or decision.

Depending on the use case, assess:

• Whether users know they are interacting with an AI system
• Whether clinicians understand how outputs are produced
• Whether patients need an explanation of the AI’s role
• Whether important limitations are communicated
• Whether significant outcomes can be challenged
• Whether people can request human support
• Whether the responsible organisation is identifiable
• Whether appropriate records are retained
• Whether public-sector transparency requirements apply
• Whether privacy information accurately describes the processing

Transparency does not necessarily require publishing proprietary source code. It requires providing meaningful information appropriate to the affected person and context.

Algorithmic Transparency Recording Standard

The Algorithmic Transparency Recording Standard provides a structured way for public-sector organisations to publish information about algorithmic tools.

Its mandatory scope currently covers central government departments and certain arm’s-length bodies for defined tools. It is recommended more broadly across the public sector, but it should not be described as mandatory for every NHS trust or private healthcare provider.

Organisations should check the current ATRS mandatory scope and exemptions policy.

10. Is the AI Ready for Change and Post-Deployment Monitoring?

Healthcare AI compliance does not end when the system goes live.

Performance and risk can change because of:

• New patient populations
• Different clinical settings
• Changes to workflows
• New data sources
• Model updates
• Prompt changes
• Retrieval-source changes
• New integrations
• User behaviour
• Data drift
• External platform changes
• Expansion beyond the original intended use

Monitoring checklist

• Are baseline performance measures recorded?
• Are model, prompt and retrieval versions controlled?
• Can outputs be audited?
• Are safety incidents and near misses monitored?
• Are complaints and user concerns reviewed?
• Is subgroup performance monitored?
• Are unusual or deteriorating outputs detectable?
• Are changes assessed before release?
• Can a previous version be restored?
• Can the AI function be suspended quickly?
• Are responsibilities clear after deployment?
• Is the clinical safety case maintained where applicable?
• Are regulatory reporting duties understood?
• Is retraining controlled and documented?
• Is decommissioning planned?

A system should not be assumed to remain compliant because it passed an assessment before launch. Significant changes to the model, intended purpose, data or workflow may require new assessment and evidence.

Use This Healthcare AI Compliance Routing Checklist

Use the following checklist to identify the workstreams that may require assessment.

Do not calculate one overall compliance percentage.

A strong result in nine areas cannot cancel out a missing medical-device assessment, unlawful processing or an unmanaged clinical-safety risk. Each applicable requirement needs its own evidence, owner and decision.

Ready to Move Your Healthcare AI Project Beyond the Proof of Concept?

Moving from a promising AI demonstration to a dependable AI healthcare product requires more than model performance. The system needs an appropriate architecture, controlled data, documented evidence, security, human oversight and a clear assurance route.

Ultralink IT helps healthcare and HealthTech teams:

• Define production requirements
• Assess data and technical readiness
• Design secure AI architecture
• Prepare technical evidence
• Build integrations and access controls
• Implement monitoring and auditability
• Organise development around the identified assurance route
• Coordinate technical work with the client’s clinical-safety, legal, data-protection and regulatory specialists

Ultralink IT does not replace qualified legal, medical-device or clinical-safety advisers. We help ensure that the technology and delivery process can support the requirements identified for the project.

Note: This article provides general information and does not constitute legal, regulatory, medical-device or clinical-safety advice. UK healthcare AI requirements and official guidance continue to develop. Confirm the current position with appropriately qualified specialists for the specific product, organisation, market and deployment.