Municipal community health programmes occupy a distinct position in healthcare delivery. They're dispersed across schools, home visits, and local clinics, staffed predominantly by nurses and health visitors, and accountable to population-level mandates rather than individual episode-of-care metrics. When AI documentation assistance enters this environment, the evaluation questions that apply in a GP surgery or hospital ward don't map cleanly onto what a municipality actually needs to assess. This guide sets out a structured framework for public health administrators approaching that assessment for the first time, drawing on current European regulatory obligations, published implementation evidence, and the practical realities of community health delivery.

Why municipal health settings require a separate evaluation framework

The dominant evidence base for AI documentation tools in clinical settings comes from secondary care hospitals and, to a lesser extent, GP practices. Both contexts share characteristics that don't reflect how community health programmes operate: fixed consulting rooms, dedicated IT infrastructure, and clinicians with protected documentation time.

Municipal community health delivery is typically nurse-led, conducted across multiple dispersed locations, and structured around brief, often informal encounters: a school health check, a home visit with a new mother, a drop-in session at a community centre. Staff frequently move between sites, connectivity is intermittent, and the same individual may function simultaneously as clinician, care coordinator, and case manager.

WHO/Europe's assessment of AI readiness across EU Member States found that workforce preparedness and data governance structures vary significantly between national health systems and sub-national delivery tiers. This reinforces why municipal administrators can't assume that a tool validated at hospital level will perform appropriately in their setting.

The European Commission's analysis of AI deployment barriers in clinical practice identifies four distinct challenge categories: technological and data challenges, regulatory complexity, organisational and financial barriers, and social and cultural factors. In municipal community health programmes, all four categories present with particular intensity, making a tailored assessment framework necessary rather than optional.

A systematic review of e-health implementation factors across primary care, secondary care, and home care settings found that successful deployment depended on factors operating simultaneously at the level of the technology itself, the outer organisational setting, the inner delivery context, and the individual professionals involved. Municipal health programmes span all of these levels in ways that hospital deployments typically don't.

What an AI documentation assistant actually does in a community health context

Before any regulatory or procurement assessment begins, administrators need a precise functional definition of the tool under evaluation. Misclassification at this stage creates downstream compliance errors that are difficult to correct.

An AI documentation assistant in a community health context does the following:

• Listens to a clinical conversation between a health professional and a patient or family member

• Converts spoken content into text in real time using speech-to-text technology (automated speech recognition)

• Generates a structured clinical note or summary from that transcription

• Reduces the documentation burden on the clinician by automating note creation

What it doesn't do, and this distinction carries regulatory weight, is interpret clinical findings, suggest diagnoses, recommend treatments, or flag clinical risk. Those functions define clinical decision support, which carries different regulatory obligations under both the EU Medical Device Regulation (MDR) and the EU AI Act.

The Lancet Primary Care's framework for categorising AI applications in primary care uses the World Health Organization digital health interventions taxonomy to draw precisely this distinction, separating tools that support documentation and communication from those that provide clinical guidance. Administrators who conflate the two categories risk either over-regulating a documentation tool or, more dangerously, under-regulating a tool that is actually performing clinical functions.

A practical test: if removing the AI tool's output from a consultation would leave the clinician's clinical judgement unchanged, the tool is functioning as a documentation assistant. If the tool's output would alter what the clinician decides to do next, it is functioning as clinical decision support.

MDR classification: what municipal administrators must determine first

Classification under the MDR (Regulation 2017/745) is the first formal determination that must be made before any procurement decision. Getting this wrong exposes the municipality to legal liability and, more importantly, to patient safety risk.

The central question is whether the AI documentation assistant meets the MDR definition of a medical device, specifically whether it is intended for the diagnosis, prevention, monitoring, treatment, or alleviation of disease. A tool that only captures and structures clinical conversations, without interpreting their clinical content, generally falls outside the MDR's scope. A tool that generates clinical recommendations, risk scores, or diagnostic suggestions falls within it.

The convergence of MDR, General Data Protection Regulation (GDPR), and the EU AI Act means that even a tool classified as a non-device may still carry obligations under the AI Act if it is considered a high-risk AI system, for example if it is used in a way that influences clinical decisions affecting patient safety.

Where a tool is classified as a medical device:

• The manufacturer must hold CE marking under MDR

• A conformity assessment must have been completed, potentially involving a Notified Body

• Technical documentation, post-market surveillance, and incident reporting obligations apply

• The municipality as deployer takes on specific obligations as an economic operator

Analysis of the EU AI Act's implications for healthcare notes that a practical bottleneck exists in the availability of Notified Bodies with the capacity to assess AI-based medical devices. Administrators should ask vendors directly about the current status of their conformity assessment and not assume CE marking is imminent if it hasn't yet been granted.

Administrators should request from any vendor:

• A written statement of intended purpose

• Confirmation of MDR classification and the basis for it

• CE marking documentation if applicable, or a clear explanation of why the tool falls outside MDR scope

• Evidence of any Notified Body involvement

GDPR and data residency: key questions for municipalities processing patient data

An AI documentation assistant processes special category personal data under GDPR, specifically health data concerning identifiable individuals. This triggers the most stringent tier of GDPR obligations, and municipalities as data controllers bear primary accountability for ensuring those obligations are met.

The key GDPR questions for municipal administrators to resolve before procurement are:

Lawful basis: Community health programmes will typically rely on Article 9(2)(h), processing necessary for preventive or occupational medicine, medical diagnosis, or the provision of health care, combined with Article 6(1)(e) for public task. Administrators should confirm with their Data Protection Officer (DPO) that this basis is properly documented.

Data Processing Agreement: Where a vendor processes patient data on behalf of the municipality, a Data Processing Agreement (DPA) compliant with Article 28 GDPR must be in place before any data is processed. The DPA must specify the subject matter, duration, nature, and purpose of processing; the type of personal data and categories of data subjects; and the obligations and rights of the controller.

Data residency: EU data residency requirements for health data are a significant procurement filter. Municipalities should require that patient data is stored and processed within the EU/European Economic Area (EEA), and should obtain contractual guarantees to that effect. Where a vendor uses sub-processors, for example cloud infrastructure providers, each sub-processor's location must be disclosed and assessed.

Sub-processor transparency: Vendors must be able to provide a complete list of sub-processors involved in processing patient data, with their locations and the safeguards in place for any transfers outside the EU/EEA.

Data minimisation and retention: Administrators should confirm what data the tool retains after a consultation, for how long, and under what deletion or anonymisation policy.

The European Health Data Space (EHDS), which entered into force in 2025, adds a further layer of data governance obligations that municipalities in EU Member States must factor into their assessment, particularly where patient data may be accessed across borders.

Assessing vendor security posture: what certifications and controls to look for

Security assessment of an AI documentation assistant vendor is not a one-time checkbox exercise. It requires administrators to evaluate both the vendor's formal certifications and the practical controls they have in place.

ISO 27001 is the baseline certification administrators should require. It demonstrates that the vendor has implemented an information security management system (ISMS) that has been independently audited. Administrators should ask for the current certificate, its scope, and the date of the most recent surveillance audit.

Beyond ISO 27001, administrators should ask vendors directly about:

• Access controls: Who within the vendor organisation can access patient data, under what conditions, and with what audit trail?

• Encryption: Is data encrypted in transit and at rest? What encryption standards are used?

• Audit logs: Are access and processing events logged, and can the municipality access those logs?

• Breach notification: What is the vendor's contractual commitment on breach notification timelines? GDPR requires notification to supervisory authorities within 72 hours of becoming aware of a breach, and vendors must be able to support that timeline.

• Penetration testing: How frequently is the system independently tested for vulnerabilities, and are reports available?

• Sub-processor security: What security requirements does the vendor impose on its sub-processors, and how is compliance verified?

The EU AI Act's requirements for high-risk AI systems include obligations around robustness, accuracy, and cybersecurity that vendors of in-scope tools must demonstrate through technical documentation. Administrators should ask whether the tool has been assessed under the AI Act and, if so, at what risk classification.

National-level health data security frameworks, such as those operated by national cybersecurity agencies in France, Germany, or the Netherlands, may impose additional requirements on top of ISO 27001. Municipalities should check whether their national framework applies to municipal health data systems and whether vendor certification covers it.

Community care workflow fit: why hospital-validated tools may not transfer directly

A tool that performs well in a hospital outpatient clinic or a GP consulting room may perform materially differently in a community health setting. Administrators should not treat hospital or GP validation evidence as sufficient proof of fitness for community health deployment.

The workflow characteristics that distinguish community health delivery include:

• Mobile and home-based consultations: The clinician is not in a fixed acoustic environment. Background noise, variable microphone quality, and physical distance from a device affect transcription accuracy in ways that controlled clinical environments don't.

• Intermittent connectivity: Many community health visits occur in locations with unreliable internet access. Administrators must determine whether the tool requires continuous connectivity or can function offline with synchronisation on reconnection.

• Brief consultations: Community health encounters are often shorter and less structured than hospital or GP appointments, with less predictable clinical language and more conversational exchange.

• Multi-role staff: Community health workers and health visitors frequently perform functions that span clinical assessment, social care coordination, and public health monitoring. The tool's note templates and structured output must reflect this breadth.

• Shared or personal devices: Unlike hospital settings where devices are typically fixed and managed, community health staff may use shared tablets or personal devices, raising additional security and access control questions.

The Lancet Primary Care framework emphasises that AI tools in primary and community care must be assessed against the actual delivery model, not a generalised clinical encounter. Administrators should ask vendors specifically whether the tool has been tested or deployed in community health, home visiting, or school health contexts, and request performance data from those settings rather than from hospital environments.

A multi-centre implementation study of clinical decision support in diverse primary care settings found that user-centred design and workflow integration testing were critical determinants of adoption success. These findings apply directly to AI documentation tools in community health.

Staff roles and training requirements in nurse-led and school health services

The workforce in municipal community health programmes differs from hospital or GP settings in ways that affect both training requirements and accountability structures. Administrators must address these differences explicitly before deployment.

Who will use the tool? In nurse-led services, health visiting programmes, and school health teams, the primary users are registered nurses, health visitors, and community health workers, not doctors. Training and change management must be designed for this workforce, not adapted from materials developed for GP or hospital contexts.

Technical training versus confidence building: A cross-sectional survey of healthcare professionals on AI documentation tools found that familiarity with AI tools and awareness of institutional policies were both low, even among professionals working in settings where AI tools were available. Technical training, covering how to operate the tool, is necessary but not sufficient. Staff also need supported experience to build confidence in the tool's output and to develop the critical judgement to identify when the AI-generated note doesn't accurately reflect the clinical encounter.

Accountability for note accuracy: When an AI assistant generates a clinical note, the clinician who conducted the encounter retains full professional and legal accountability for the accuracy of that note. This must be communicated clearly and unambiguously to all staff before deployment, and built into training materials. The AI-generated note is a draft for clinician review, not a final record.

Change management: WHO/Europe's regional assessment identifies workforce preparedness as one of the most significant barriers to AI adoption in health systems across the European Region. Administrators should plan for a structured change management process that includes:

• Pre-deployment staff consultation

• Phased rollout with designated early adopters

• Ongoing feedback mechanisms

• Named clinical leads for governance and quality assurance

Clinical notes quality and accuracy: how to evaluate before you deploy

Accuracy assessment is not something administrators should delegate entirely to vendors. A structured pre-deployment evaluation process, conducted in the municipality's own clinical context, is essential.

Define what 'accurate' means for your setting. A clinical note generated for a health visitor's home visit has different structural requirements from a GP consultation note or a hospital discharge summary. Administrators should define, in advance, what a satisfactory note looks like for each encounter type in their programme: what fields must be present, what clinical language is appropriate, and what omissions would constitute a material error.

Conduct a structured pilot. Before full rollout, a time-limited pilot with a defined group of staff and a defined set of encounter types allows administrators to assess accuracy in their specific context. The pilot should include:

• A sample of real consultations across different encounter types

• Independent review of AI-generated notes against clinician-written notes or clinician recall

• Structured recording of errors, omissions, and hallucinations (instances where the AI generates content that was not said)

• Staff feedback on usability and workflow fit

Set acceptance thresholds. Administrators should define, before the pilot begins, what level of accuracy is acceptable and what error rate would trigger a decision not to proceed. This prevents post-hoc rationalisation of poor results.

Establish ongoing quality review. Deployment should not end the accuracy assessment process. A regular review of a sample of AI-generated notes, conducted by a clinical governance lead, should be built into the programme's governance framework from the outset.

A Belgian cluster-randomised trial of clinical decision support in primary care found that incomplete structured records were a primary cause of low system use rates. This underlines the importance of ensuring AI-generated notes meet the structured data requirements of the municipality's medical record system before deployment.

Language, dialect, and population diversity considerations

Municipal community health programmes frequently serve linguistically diverse populations. This is particularly true in urban municipalities with significant migrant or refugee communities, and in regions with minority language populations. AI documentation tools that perform well in standard spoken English, Dutch, or German may perform materially worse when processing accented speech, regional dialects, or code-switching between languages.

The Lancet Primary Care identifies equity as a core principle for AI integration in primary and community care, noting that tools that perform differently across population groups risk amplifying existing health inequalities rather than reducing them. For municipal health programmes with an explicit population health mandate, this is not an abstract concern. It's a governance obligation.

Administrators should ask vendors:

• In which languages and language variants has the tool been validated?

• What is the documented accuracy differential between standard and non-standard speech varieties in those languages?

• How does the tool handle consultations conducted partially or wholly through an interpreter?

• What is the vendor's roadmap for expanding language coverage?

Testing should include consultations with staff and patients representative of the municipality's actual population diversity, not only the majority language group. If the tool can't demonstrate acceptable accuracy across the municipality's primary language groups, it should not be deployed in services where those populations are served.

Integration with existing medical record systems and municipal IT

Technical integration is frequently the longest lead-time item in an AI documentation assistant deployment. Administrators should begin this assessment early and not treat it as a final-stage implementation question.

The core integration questions are:

Medical record system compatibility: Which medical record systems does the tool currently integrate with, and through what mechanism? Direct integration via application programming interface (API), HL7 Fast Healthcare Interoperability Resources (FHIR), or proprietary connector each carries different implementation complexity and maintenance obligations.

Legacy system constraints: The European Commission's analysis identifies fragmented data infrastructure and legacy systems as one of the four primary barriers to AI deployment in European health settings. Municipal public health IT environments frequently include older systems that predate modern interoperability standards. Administrators should obtain a clear technical assessment of whether the AI tool can operate within their existing infrastructure or requires system upgrades as a precondition.

MyHealth@EU and FHIR compliance: A JMIR tutorial on AI Act compliance within the MyHealth@EU framework describes the dual compliance challenge facing health AI deployers: vertical safety and ethics controls under the AI Act, and horizontal interoperability requirements under MyHealth@EU using FHIR/HL7 standards. Municipalities that are part of cross-border health data exchange programmes must ensure the AI tool's output is compatible with these standards.

Offline functionality: For community health settings with intermittent connectivity, administrators must confirm whether the tool can capture and process consultations offline, and how synchronisation with the central medical record system is handled when connectivity is restored.

Data flow mapping: Before deployment, a complete data flow map, showing where data is created, processed, stored, and deleted, must be produced and reviewed by the DPO. This is both a GDPR requirement and a practical governance tool.

Procurement and governance: building the internal case for approval

Municipal procurement of an AI documentation assistant involves stakeholders across multiple functions, and the sequence in which they are engaged matters. Administrators who approach procurement as primarily a technology purchase, rather than a governance process, typically encounter delays and objections that could have been anticipated.

The internal stakeholders who must be involved, and the sequence that reflects good governance practice, are:

Data Protection Officer: The DPO should be engaged from the outset, not consulted at the end. The DPO must conduct or oversee a Data Protection Impact Assessment (DPIA) under Article 35 GDPR, which is mandatory where processing is likely to result in a high risk to individuals, as is the case with AI processing of health data at scale.

Clinical governance lead: This person must define the clinical quality standards the tool must meet, oversee the pilot evaluation, and take accountability for the ongoing accuracy review process.

IT and information security: This team must assess technical integration feasibility, security architecture, and compatibility with existing infrastructure before a procurement decision is finalised.

Legal counsel: Legal counsel must review vendor contracts, including the DPA, and assess the municipality's liability position under MDR, the AI Act, and applicable national law.

Finance and procurement: This function must ensure the procurement process complies with applicable public procurement rules, which in EU Member States typically means compliance with the Public Procurement Directive for contracts above threshold values.

Clinical staff representatives: Staff should be involved in requirements definition and pilot design. WHO/Europe's assessment identifies stakeholder engagement as a key determinant of AI adoption success at system level. This applies equally at programme level.

The business case for approval should address:

• Quantified documentation burden reduction for nursing and community health staff

• Staff retention and burnout reduction as a workforce sustainability argument

• Regulatory compliance as a risk management obligation, not an optional enhancement

• Costs of deployment including training, integration, and ongoing governance

• Risks of not acting, including continued documentation burden and associated staff attrition

The EU's AICare@EU initiative and EU4Health funding may provide co-funding pathways for municipalities in Member States. Administrators should check current eligibility criteria as part of the financial assessment.

A pre-deployment checklist for municipal health administrators

The following checklist consolidates the key assessment questions from each section of this guide. It is designed as a practical reference for administrators moving from evaluation to procurement decision.

Regulatory classification

• Has the vendor provided a written statement of intended purpose?

• Has MDR classification been determined, and is the basis for that classification documented?

• If CE marked, is the current certificate available and within its validity period?

• Has the tool's classification under the EU AI Act been assessed?

GDPR and data governance

• Has a DPIA been initiated and assigned to the DPO?

• Is a compliant DPA in place or ready for signature before go-live?

• Has the vendor confirmed EU/EEA data residency for storage and processing?

• Has a complete sub-processor list been obtained and reviewed?

• Is a data flow map complete and reviewed?

Security

• Does the vendor hold current ISO 27001 certification, and does its scope cover the relevant systems?

• Have access controls, audit log availability, and breach notification timelines been confirmed in writing?

• Has the vendor disclosed its penetration testing schedule and made results available?

• Are national health data security framework requirements assessed and met?

Workflow fit

• Has the tool been tested or deployed in community health, home visiting, or school health settings?

• Is performance data available from those settings specifically?

• Does the tool function in low-connectivity or offline conditions?

• Are note templates and structured output appropriate for the municipality's encounter types?

Staff readiness

• Is a training programme designed for the specific workforce (nurses, health visitors, community health workers) in place?

• Is accountability for note accuracy clearly communicated and documented?

• Is a change management plan, including clinical leads and feedback mechanisms, in place?

Clinical notes quality

• Are acceptance thresholds for accuracy defined before the pilot begins?

• Is a structured pilot plan, including independent note review, in place?

• Is an ongoing quality review process built into the governance framework?

Language and population diversity

• Has the tool been validated in the languages and dialects present in the municipality's population?

• Has accuracy been tested with staff and patients representative of the actual population?

• Is interpreter-mediated consultation handling documented and assessed?

Medical record system and IT integration

• Is medical record system compatibility confirmed, and is the integration mechanism documented?

• Has a technical assessment of legacy system constraints been completed?

• Is FHIR/HL7 compatibility confirmed where relevant to cross-border data exchange?

Internal governance and procurement

• Have all required internal stakeholders (DPO, clinical governance, IT, legal, finance) been engaged?

• Does the procurement process comply with applicable public procurement rules?

• Has the business case been prepared, addressing both efficiency gains and risk management obligations?

This framework structures the complexity of deploying AI documentation assistance in municipal community health settings into assessable, sequenced questions that administrators can work through systematically. The regulatory environment across MDR, GDPR, and the EU AI Act is genuinely demanding, and the evidence from across the WHO European Region suggests that health systems at every level are still developing the governance capacity to navigate it. Starting with a clear framework, rather than a technology-first approach, is the most reliable path to a deployment that is both legally sound and genuinely useful to the staff and communities it is intended to serve.

Frequently asked questions

▶ Why do municipal community health programmes need a separate evaluation framework for AI documentation tools?

Most evidence for AI documentation tools comes from hospitals and GP practices, which have fixed consulting rooms, dedicated IT infrastructure, and protected documentation time. Municipal community health delivery is typically nurse-led, spread across dispersed locations, and built around brief, informal encounters such as home visits and school health checks. Staff move between sites, connectivity is intermittent, and the same person often acts as clinician, care coordinator, and case manager simultaneously. A tool validated in a hospital setting can't be assumed to perform appropriately in this context, which is why a tailored assessment framework is necessary rather than optional.

▶ What does an AI documentation assistant actually do in a community health setting?

An AI documentation assistant listens to a clinical conversation, converts spoken content into text using speech-to-text technology (automated speech recognition), and generates a structured clinical note or summary from that transcription. It doesn't interpret clinical findings, suggest diagnoses, recommend treatments, or flag clinical risk. Those functions define clinical decision support, which carries different regulatory obligations. A practical test: if removing the tool's output would leave the clinician's judgement unchanged, it's functioning as a documentation assistant. If the output would alter what the clinician decides to do next, it's functioning as clinical decision support.

▶ How does the EU Medical Device Regulation (MDR) apply to AI documentation tools in municipal health?

The central question under the Medical Device Regulation (Regulation 2017/745) is whether the tool is intended for the diagnosis, prevention, monitoring, treatment, or alleviation of disease. A tool that only captures and structures clinical conversations, without interpreting their clinical content, generally falls outside the MDR's scope. A tool that generates clinical recommendations, risk scores, or diagnostic suggestions falls within it. Where a tool is classified as a medical device, the manufacturer must hold CE marking, complete a conformity assessment, and meet technical documentation and post-market surveillance obligations. Administrators should request a written statement of intended purpose and confirmation of MDR classification from any vendor before procurement.

▶ What GDPR obligations apply when a municipality uses an AI documentation assistant to process patient data?

An AI documentation assistant processes special category personal data under the General Data Protection Regulation (GDPR), specifically health data about identifiable individuals. This triggers the most stringent tier of GDPR obligations. Municipalities acting as data controllers must confirm a lawful basis for processing, typically Article 9(2)(h) combined with Article 6(1)(e) for public task. A Data Processing Agreement compliant with Article 28 GDPR must be in place before any data is processed. Administrators must also confirm that patient data is stored and processed within the EU or European Economic Area, obtain a complete list of sub-processors and their locations, and document data retention and deletion policies.

▶ What security certifications and controls should administrators require from AI documentation vendors?

ISO 27001 is the baseline certification administrators should require. It demonstrates that the vendor has implemented an information security management system that has been independently audited. Beyond that, administrators should confirm in writing that patient data is encrypted in transit and at rest, that access to patient data within the vendor organisation is controlled and logged, that the vendor can support the GDPR requirement to notify supervisory authorities within 72 hours of a breach, and that independent penetration testing is conducted regularly. National health data security frameworks, such as those operated by cybersecurity agencies in France, Germany, or the Netherlands, may impose additional requirements on top of ISO 27001.

▶ Why might a hospital-validated AI documentation tool perform differently in community health settings?

Community health delivery has workflow characteristics that don't exist in hospital or GP settings. Home visits and school health checks involve variable acoustic environments, unreliable internet access, and shorter, less structured conversations than hospital appointments. Staff frequently perform clinical, social care, and public health functions within a single encounter. Shared or personal devices raise additional security questions that fixed hospital devices don't. Administrators should ask vendors specifically whether the tool has been tested in community health, home visiting, or school health contexts, and request performance data from those settings rather than from hospital environments.

▶ Who is accountable for the accuracy of AI-generated clinical notes in a nurse-led community health service?

The clinician who conducted the encounter retains full professional and legal accountability for the accuracy of any AI-generated clinical note. The AI-generated note is a draft for clinician review, not a final record. This must be communicated clearly to all staff before deployment and built into training materials. Research published in a cross-sectional survey of healthcare professionals found that familiarity with AI tools and awareness of institutional policies were both low, even where tools were available. Technical training on how to operate the tool is necessary, but staff also need supported experience to build the critical judgement to identify when an AI-generated note doesn't accurately reflect what happened in the consultation.

▶ How should administrators evaluate AI documentation tool accuracy before deploying across a community health programme?

Administrators should define in advance what a satisfactory note looks like for each encounter type in their programme, including which fields must be present and what omissions would constitute a material error. A time-limited pilot with a defined group of staff and encounter types should then be conducted, with independent review of AI-generated notes against clinician-written notes or clinician recall, and structured recording of errors, omissions, and hallucinations (instances where the AI generates content that was not said). Acceptance thresholds for accuracy should be set before the pilot begins, not after. Ongoing quality review of a sample of AI-generated notes, conducted by a clinical governance lead, should be built into the programme's governance framework from the outset.

▶ How should administrators assess whether an AI documentation tool can serve linguistically diverse community health populations?

Municipal community health programmes frequently serve populations with diverse languages, dialects, and communication patterns, particularly in urban areas with significant migrant or refugee communities. AI documentation tools that perform well in standard spoken Dutch, German, or English may perform materially worse with accented speech, regional dialects, or consultations conducted through an interpreter. Administrators should ask vendors which languages and language variants the tool has been validated in, what the documented accuracy differential is between standard and non-standard speech, and how interpreter-mediated consultations are handled. Testing should include staff and patients representative of the municipality's actual population, not only the majority language group.

▶ Which internal stakeholders must be involved in procuring an AI documentation assistant for a municipal health programme?

The Data Protection Officer must be engaged from the outset and must conduct or oversee a Data Protection Impact Assessment, which is mandatory under Article 35 GDPR where AI processes health data at scale. A clinical governance lead must define quality standards, oversee the pilot, and take accountability for ongoing accuracy review. IT and information security teams must assess technical integration and infrastructure compatibility. Legal counsel must review vendor contracts and the municipality's liability position under the Medical Device Regulation, the EU AI Act, and applicable national law. Finance and procurement must ensure compliance with public procurement rules. Clinical staff representatives should be involved in requirements definition and pilot design from the beginning.