AI-Generated Medical Device Interfaces and the EU AI Act Localization Problem

This article draws on Creative Navy's project work in medtech UX, spanning practice management software, surgical equipment, ventilators, blood pumps, infusion systems, and patient monitoring devices, including Class II and Class III regulated products. Our work in this sector covers clinical environments including the ICU and operating theatre, designing for surgeons, nurses, and biomedical engineers. Dennis Lenard, who leads this work at Creative Navy, is the author of User Interface Design For Medical Devices And Software, the practitioner reference on UX design for medical devices and software. Our approach integrates IEC 62366 usability engineering requirements and FDA Human Factors guidance as structural inputs to the design process, not post-hoc compliance activities.


Key Regulatory Milestones

The brief looked straightforward. A CGM manufacturer wanted to add contextual guidance to their home monitoring interface: when a patient's glucose trended toward a critical threshold, the device would generate a plain-language explanation of what the reading meant and what action to take. The system would use the patient's history to personalise the message, less urgent for a stable diabetic with well-controlled levels, more urgent for a recently diagnosed patient still learning their patterns.

The team scoped it as a UX enhancement. It was not.

What they were proposing was a medical device that generates new clinical instructions at runtime, content that does not exist until a patient triggers it, content that cannot be pre-authored, pre-translated, or exhaustively tested before a regulatory submission. Under EU MDR 2017/745, the manufacturer is required to be the author of the device's instructions. Under the EU AI Act (Regulation 2024/1689), any system producing such outputs for a Class IIb device qualifies as a high-risk AI system subject to obligations that take full effect in August 2027.

Nobody on the team had identified it as a localization problem. It was one. It was also a certification problem, a liability problem, and a design problem, in that order of urgency. Many device teams encounter the same issue when localization is treated as translation rather than interface design. We explore this in detail in our analysis of why medical device localization fails and what good looks like.

This article examines that intersection: what happens to medical device localization when the device starts writing its own instructions, and what the correct design response actually looks like.

The EU AI Act has been in force since August 2024. Most of what manufacturers feel day-to-day has not changed yet. The obligations that matter most for medical device AI (MDAI) apply from August 2, 2027, which is 36 months after the Act entered into force for devices regulated under MDR/IVDR Annex II.

That deadline is close enough to demand attention now. Notified Body conformity assessment schedules, design freeze timelines, and the lead time required for IEC 62366 usability validation mean that devices intended to carry AI-generated interface content for the 2027 market need to be making design decisions in the current development cycle, not the next one.

What the Act adds, beyond what MDR already requires, is specifically AI-focused: data quality and governance requirements, record-keeping obligations, transparency to deployers and users, human oversight provisions, and post-market performance monitoring for AI components. The critical obligation for interface design sits in Article 13. The system must be "sufficiently transparent to deployers and users" and must allow them to "interpret the system's output and use it appropriately."

For a device displaying pre-authored, pre-translated alarm text, this is straightforward. The manufacturer knows what the device will say. They can document it, translate it, test it, and submit it.

For a device generating contextual clinical guidance at runtime, Article 13 becomes a design problem that cannot be solved retroactively. Transparency about an output requires the manufacturer to characterise that output in advance. A system that can generate anything cannot be made sufficiently transparent in the Act's sense, not because the technology is inadequate, but because the regulatory structure requires pre-characterisation.

The Act also introduces a conflict with MDR's change management regime. MDR requires recertification for significant software modifications. The AI Act allows, and in some cases contemplates, continuous learning systems that evolve post-market. For medical device AI, that conflict remains unresolved in any published guidance. A device that learns from patient data after market placement and updates its output behaviour is simultaneously in tension with MDR's stability requirements and potentially aligned with the AI Act's performance monitoring framework. MDCG 2025-6, published in 2025, sets out the governance structure but does not tell manufacturers how to design through this.

EU MDR 2017/745 is built on a specific model of how a device communicates with its user. The manufacturer authors a fixed corpus of instructions, labels, and warnings. Those are translated into the official languages of the Member States where the device is marketed. The translations are validated through back-translation, linguistic review, and usability testing. The resulting documentation is submitted as part of the technical file. The Notified Body reviews it. The content on the device is the content in the file.

This model works well for devices with determinate outputs. The blood glucose display shows a number and a unit. The infusion pump alarm displays one of fourteen pre-authored messages. The surgical instrument's confirmation prompt is a fixed string, translated and tested. Every piece of text the user might see is known in advance, exists in a file, and has been reviewed.

AI-generated interface content breaks this at three distinct points.

First: the text does not exist until runtime. It cannot be pre-translated because it has not been authored. You cannot submit a German translation of a message that will only be composed when a specific patient's glucose trend triggers a specific inference at a specific time of day. The corpus is effectively unbounded.

Second: the output space cannot be exhaustively tested. Formative and summative usability testing under IEC 62366-1 operates on a defined set of tasks and scenarios. A generative system produces outputs outside any scenario set. The clinical effect of those edge-case outputs, on a confused elderly patient at 3am, in a second language, with limited health literacy, cannot be assessed in advance.

Third: the system may generate linguistically fluent content that is clinically inaccurate. This is a failure mode that static translated text does not have. A badly worded but factually correct German alarm label is auditable and correctable. A fluent German sentence generated by an LLM that contains a clinically wrong interpretation of a glucose trend may pass a linguistic quality check and fail a clinical one. There is no review step that catches it before the patient acts on it.

The foundational authorship assumption behind MDR's localization requirements is not a bureaucratic detail. It is the mechanism by which the manufacturer takes responsibility for what the device says to the patient. AI-generated text disrupts that responsibility chain in a way that translation quality alone cannot repair.

The challenge is not simply that the technology is new. The challenge is that the technology generates outputs whose safety properties cannot be established using the methods MDR was built around. That structural incompatibility is what mandates a design response, not just a compliance response.

The medical device certification community has not formally addressed AI-generated interface text and localization. It has, however, addressed a structurally identical problem in AI model behaviour, and the resolution maps directly.

The Notified Body AI questionnaire (NB-MED V5, December 2023), the primary published expression of what conformity assessment bodies expect from AI-enabled medical devices, draws a clear line between two types of AI.

Static, locked AI with fixed weights post-training can be certified under MDR. The model's behaviour is determinate given its inputs. It can be validated, documented, and submitted. Changes require the change management process.

Continuous learning systems, those that update themselves in deployment, are in the questionnaire's language "generally not certifiable without stringent controls." The questionnaire explicitly requires manufacturers to justify any in-market learning: by pre-defining allowable updates via change logs, or by embedding safeguards that bound outputs. The phrase "pre-determined changes must be clearly specified" appears in current MDCG guidance.

The translation to the interface text problem is direct. A device that generates new natural language clinical instructions through a continuous learning model is the interface localization equivalent of a continuously learning AI system. The Notified Body's position on model behaviour applies with equal force to the content that model produces.

A device that selects from a pre-defined library of validated, translated clinical statements — even if the selection logic is AI-driven — is certifiable under the same framework as a locked model: the outputs are determinate, the content set is bounded, and the translations can be submitted. A device that generates novel clinical language freely is not certifiable under any current framework, regardless of the quality of its outputs.

This is the regulatory settlement that already exists, even though it has not been articulated as a localization design principle. The design question is how to build within it.

The design principle that resolves the certification problem is not complicated. What is unusual is that it has not been named explicitly in the medical device design literature, even as practitioners in adjacent fields have been converging on it.

AI-generated interface content in a regulated medical device must operate within pre-authored, pre-translated content clusters. The AI selects and sequences validated content appropriate to the patient's situation; it does not compose new clinical language. This keeps the manufacturer as the author of what the device communicates: the condition under which MDR and the EU AI Act locate regulatory liability. Content selection within a validated library is certifiable. Free generation is not.

This preserves what is genuinely valuable about AI in patient-facing interfaces: context-awareness, personalisation, the ability to communicate differently with a newly diagnosed patient than with a ten-year veteran managing a stable chronic condition. It maintains those capabilities while keeping a documentable, translatable, testable content boundary.

The analogy to how compliant healthcare chatbots already operate is exact. A well-designed patient-facing chatbot in a regulated environment does not generate free-form clinical advice. It routes the patient's input to a validated response set and presents the most contextually appropriate validated content. The intelligence is in the routing; the content is in the library. The chatbot selects; it does not create.

Applied to a CGM device: the AI component can analyse glucose trends, identify the clinical state, assess urgency, model the patient's likely context and health literacy profile, and select the most appropriate validated instruction from a pre-authored, pre-translated library. What it cannot do under current certification frameworks is compose that instruction in the moment using language that was not in the submission file.

The practical design implications for device teams building toward the August 2027 deadline follow from this directly. Content architecture must precede AI architecture. The validated content library needs to be designed, authored, clinically reviewed, and translated before the AI selection logic is built. This reverses the typical sequence in AI product development, where content is treated as a downstream consideration. The library must also be bounded and exhaustive for the intended use scenarios: every clinically meaningful state the device might encounter needs a validated instruction. Gaps in the library are regulatory gaps, requiring the device to fall back to a simpler, fully validated communication layer.

Translation, under this model, is a library maintenance function rather than a launch deliverable. In a static device, translation is completed once before market entry. In an adaptive device operating within validated language boundaries, any addition to the content library requires translation and validation before deployment. The localisation workflow becomes part of the device's lifecycle management.

Across the device projects where we have been engaged at the AI feature stage, the pattern is consistent: the model selection criteria have been debated at length, and nobody has yet asked who is responsible for authoring the content the model will select from. Content architecture is treated as a downstream concern. In a regulated device, it determines the compliance boundary. Retrofitting a bounded content architecture onto a generative system after the AI design has been locked costs significantly more than building it correctly from the start.

Our work on AI systems that make their reasoning visible and controllable to human operators demonstrates the practical version of this principle outside the medical context: the AI selects from validated decision logic; the human operator can inspect, override, and audit each selection. The interface architecture reflects the compliance requirement. That architecture carries directly into regulated medical device AI, where the same principle applies with higher stakes.

The FDA's approach to AI in medical devices is built around the Predetermined Change Control Plan (PCCP), introduced formally in the AI/ML-Based Software as a Medical Device Action Plan and operationalised through guidance from the FDA's Digital Health Center of Excellence.

A PCCP allows a device manufacturer to describe, in advance, the types of modifications the AI system may make to itself post-market, and to have those modification types reviewed as part of the original submission rather than requiring a new 510(k) for each change. The premise is that a manufacturer can pre-specify the algorithm's learning trajectory well enough to give the FDA adequate assurance about the boundaries of post-market behaviour.

Applied to interface content generation, a PCCP does not solve the problem. Pre-specifying "the system will generate contextually appropriate clinical guidance in the patient's language" describes a behaviour class but does not define the content boundaries. The FDA cannot review the safety and effectiveness of text that will be generated post-market any more than it can review all possible outputs of a system it approves. The PCCP works for model modifications that stay within characterised performance envelopes. It does not work for unbound content generation.

What the FDA's framework does provide is a useful test for whether an AI interface feature is designed within certifiable scope: can the manufacturer specify, in the PCCP, the complete set of permissible outputs the system might produce, in a way that a reviewer could assess? If the answer is no, the feature as designed is not a PCCP-eligible modification. It requires either a new submission for every output variant, or redesign to operate within bounded content.

The Adaptive UI Within Validated Language Boundaries principle passes this test. The content library is the set of permissible outputs. The PCCP can describe the selection logic and its allowable modifications. The submission file contains the content. The FDA reviewer can assess it.

The connection between AI compliance and medical device localization is not obvious from inside either frame. Teams working on AI Act compliance are typically thinking about model governance, data quality, and transparency documentation. Teams working on localization are typically thinking about translation budgets, text expansion rates, and EU MDR language requirements.

The intersection is at the content boundary. As discussed in why medical device localization fails and what good looks like, most localization failures occur not at the translation stage but at the interface design stage.

A device using Adaptive UI Within Validated Language Boundaries has a content library. That library needs to be translated. The translation requirements, back-translation validation, linguistic quality audit, layout review on target hardware, comprehension testing with representative lay users, are identical to those in a full medical device information architecture programme. The AI component does not reduce the localization burden. It changes the architecture of how localization work is organised.

Adaptive medical device interfaces using AI to select from validated content libraries do not reduce the localization burden. They restructure it. In a static device, translation is a one-time pre-launch activity. In a device where AI selects from a bounded content library, every addition to that library, every new clinical state the device needs to address, and every revision from post-market surveillance requires translation and validation before deployment. Localization becomes a recurring quality process, not a launch deliverable.

This is a significant operational implication that most device teams have not priced into their AI feature roadmaps. The AI component may be technically straightforward to build. The localization infrastructure required to operate it in compliance across EU markets may not be. The multilingual usability testing burden does not disappear; it becomes continuous.

There is a second intersection worth naming. The EU AI Act's transparency obligation, Article 13, requires that the interface allow users to interpret the system's output. This obligation is substantially easier to satisfy when outputs are validated, pre-authored content. A patient who reads a validated instruction from a library tested with representative lay users is receiving content whose comprehensibility has been assessed. A patient who reads AI-generated text has no such assurance, regardless of the language it appears in.

This is why Adaptive UI Within Validated Language Boundaries is not a regulatory workaround. It produces a better design outcome. The selection intelligence can be as complex as the clinical situation requires; the clinical communication is anchored in content whose effect on real patients is known.

For teams working on medical device UX design in environments where IEC 62366 compliance is required, particularly for lay-user devices with multilingual markets, the content boundary decision needs to happen early in the product development lifecycle. It is not a detail to resolve during submission preparation.

The Adaptive UI Within Validated Language Boundaries principle clarifies what is certifiable. It does not resolve everything.

MDCG 2025-6, the European Commission's 2025 joint guidance on MDR/IVDR and EU AI Act intersection, was anticipated as a definitive document by the industry. It is not. It maps the governance structures and confirms that a single conformity assessment pathway exists when a Notified Body is accredited under both frameworks. It does not address the specific design question of where the content boundary runs between adaptive presentation and generative instruction. Manufacturers must, in the words of published commentary on the guidance, apply "substantial common sense in extrapolating the existing requirements." That is an honest acknowledgement that the guidance has not resolved the day-to-day design decisions it was expected to clarify.

The FDA's PCCP framework is useful but has not been applied in published enforcement or clearance decisions to the specific question of AI-generated patient-facing interface text in consumer-deployed medical devices. The closest precedent involves AI-assisted clinical decision support systems, which operate through different regulatory pathways and different user mediation models. The gap between those precedents and what manufacturers are now building is real.

A deeper unresolved tension: both MDR and the AI Act presuppose a device with a defined market-entry state that evolves in characterised ways. Genuinely adaptive patient-facing interfaces, those that respond meaningfully to individual patient behaviour over time, do not fit cleanly into this model, regardless of whether their content is bounded. The regulatory framework for AI-mediated personalisation in direct-to-patient medical devices is still being formed. Manufacturers building toward it now are operating ahead of regulatory clarity, and design decisions made today will face scrutiny under guidance documents that do not yet exist.

That is not an argument for waiting. August 2027 does not move. What it argues for is building with sufficient documentation discipline that design choices can be justified against whatever guidance emerges, which is exactly what the Adaptive UI Within Validated Language Boundaries principle supports.

The CGM brief that opened this article is not an unusual situation. Device teams adding AI-powered personalisation to their interfaces are, with some regularity, making certification decisions they do not yet recognise as certification decisions. The choice between a generative interface and a selection-based one is not primarily a capability choice. It is a regulatory architecture choice that needs to be made before the AI component is scoped, not during submission preparation.

Device teams already know their AI feature benefits patients. The design question is whether the architecture keeps the manufacturer as the author of what the device actually tells them.

The localization implications follow from the architecture. Treating translation as a one-time pre-launch activity fails in an adaptive device design. Every addition to the content library requires translation and validation. This is not a complication to be managed around; it is the operational reality of compliant adaptive device design, and teams that have not priced it into their AI feature roadmaps will encounter it at the worst possible moment.

Device teams that resolve the content boundary question early, build their content library before their AI selection logic, and treat localization as a recurring quality process are in a significantly stronger position for August 2027 than those who arrive at the submission stage with a generative system and a localization plan written for a static device.

If your team is working through the design architecture decisions that determine whether an AI feature is certifiable across MDR and AI Act obligations, we work on exactly these problems.

If your device is regulated under MDR 2017/745 and incorporates an AI system, including AI-driven interface features, decision support, or adaptive content, you need to assess whether that AI system qualifies as high-risk under the AI Act. Devices requiring third-party Notified Body conformity assessment under MDR will generally qualify as high-risk under the AI Act (Article 6(1)). The full obligations apply from August 2, 2027. Existing CE marking does not exempt a device; the AI Act layers on top of MDR requirements.

MDCG 2025-6 is the European Commission Medical Device Coordination Group guidance published in 2025 on the interplay between MDR/IVDR and the EU AI Act. It confirms the dual regulatory framework and describes the single conformity assessment pathway for Notified Bodies accredited under both frameworks. It does not address AI-generated interface text, localization obligations for adaptive content, or where the content boundary runs between adaptive presentation and free generation. It is a governance map, not a design methodology.

A PCCP can cover specified changes to a device's AI component within pre-characterised performance envelopes. For AI-generated patient-facing interface text, a PCCP cannot cover the content of future generated outputs, because that content is by definition not pre-specified. A PCCP could potentially cover changes to the selection logic governing which pre-authored content the device displays, but only if the content itself is bounded and submitted. A generative system producing novel clinical language is not PCCP-eligible under any current FDA guidance.

"Static, locked AI" refers to a system whose model weights are fixed at the time of market entry and do not change in deployment. NB-MED V5 (December 2023) identifies this as the class of AI certifiable under current frameworks. If your device's AI component learns from patient data post-market and updates its parameters, it is not static in this sense. If it selects from a fixed content library using fixed inference weights, it is static regardless of how contextually responsive it appears to the user. The distinction is whether the model itself changes after certification.

The localization budget is restructured rather than reduced. Translation work for a bounded content library is not simpler than translating a static device; it may involve more content if the library is large and richly differentiated. What changes is the ongoing operational nature of that work. Additions to the content library, revisions driven by post-market surveillance, and any new clinical states the device needs to communicate all require translation and validation before deployment. Teams used to treating localization as a pre-launch activity need to budget it as a recurring quality process.

Professional-use devices, infusion pumps, surgical instruments, hospital monitors, operate within a clinical mediation chain. A trained professional mediates between the interface and the clinical decision, which creates correction points before patient harm occurs. Lay-user devices, CGMs, cardiac monitors, home diagnostics, have no such mediation. The patient acts on what the device tells them, directly. The content boundary in a lay-user device therefore needs health literacy adaptation built into the library, not just linguistic accuracy. A medically correct validated instruction pitched above the reading level of its patient population fails the lay-user regardless of how intelligently the AI selected it.