top of page
Search

How to Set Up AI Document Translation for MDR Technical Files

1 hour ago
6 min read
Reviewers comparing a translated medical device technical file against the source

A medical device technical file runs to thousands of pages, from the General Safety and Performance Requirements to the risk file and every Instruction for Use. You can translate it with AI document translation and stay inside MDR, but only in one order: lock the terminology, constrain the model to it, then put a certified linguist in front of the output before it reaches the file.


AD VERBUM is an EU-hosted AI translation company that runs MDR technical documentation through a client-tuned LLM constrained by your term base, then certified medical review under ISO 13485, ISO 17100 and ISO 18587, with no public-cloud transit and no training on client data. Here's the workflow we use, step by step, so your team can set up the same one.


One thing to settle up front. MDR bans no tool and names no AI translation product. What it inspects is whether the translated document is accurate, current, and backed by a quality system. That's a question about your review record, not your model.


What MDR asks of a translated technical file


Article 10(11) of the Medical Device Regulation (Regulation (EU) 2017/745) requires the Instructions for Use and the label in the official language or languages of every member state where you sell the device. Annex II of the same regulation sets out the technical documentation itself, which has to be clear, organised, and readily searchable. A translation that drifts from the source breaks both obligations at once.


Two document types carry the most risk. The Instruction for Use (IFU), the manual a clinician or patient actually reads, and the Summary of Safety and Clinical Performance (SSCP) under Article 32 for implantable and class III devices, which goes public through EUDAMED. An error in either is an error on the record, not a draft you can quietly fix later.


Linguists building a device term base from approved documentation

How to set up AI document translation for MDR technical files


Six steps, in sequence. Each one feeds the next, so skipping the early ones costs you at the end.


  1. Lock the device term base and translation memory. Pull approved IFU wording, device names, and warning phrasing from past accepted files into a term base, and load your translation memory so earlier sign-offs carry forward.

  2. Run constrained generation on a client-tuned model. Feed the term base and memory to a client-tuned, open-weight LLM so it produces output bound to your approved terminology instead of free-form text.

  3. Apply certified post-editing under ISO 18587 and ISO 13485. A qualified medical linguist edits the output and takes responsibility for the final text, inside a device quality system.

  4. Check EUDAMED and label consistency. Confirm the device name, UDI-DI, and intended-purpose wording match across the file, the labels, and the EUDAMED record in every language.

  5. Keep the notified-body audit trail. Record who reviewed what, against which term base version, so the review history is retrievable at audit.

  6. Run the whole thing on EU-hosted infrastructure. Keep source files, memory, and output on EU servers with no public-cloud API anywhere in the path.


Notice that the model sits in the middle, not at the end. The last word on an MDR technical file belongs to a person who signs for it.


Lock terminology before the model runs


This is the step teams skip, and it's the one that decides quality. A device term base fixes how a contraindication, a warning caption, or a specific component name appears every time, so the model can't paraphrase a safety term into something a reviewer has to catch later. If you want the fuller picture of why constrained generation plus certified review is what we mean by the term, we set it out in what AI translation means for regulated content. Build the term base from files a notified body has already accepted, not from a fresh glossary written for this project.


Certified review is what the notified body inspects



ISO 18587 is the standard for full post-editing of machine and model output, and it puts a named, qualified post-editor on the hook for the final translation. Its 2026 revision widens the scope to cover output from AI and large language models directly. Pair it with ISO 13485, the device quality-management standard, and the review stops being a courtesy pass and becomes a controlled step that leaves a record.


The regulation itself backs this up. We walk through why MDR permits the tool but demands the review in does MDR allow AI translation for IFUs and labelling, and which device documents suit the workflow in which medical device documents suit AI translation with human review.


Secure EU-hosted device for controlled translation data

Keep EUDAMED, labels and the audit trail aligned


A technical file doesn't sit on its own. The device name and UDI-DI in the file have to match the label and the EUDAMED registration, in every language, or an auditor finds the gap. Holding those surfaces consistent is its own task, and we cover the 28 November 2026 deadline for it in can AI translation keep EUDAMED device data consistent before November 2026.


The audit trail is the deliverable buyers underrate. Under the EU AI Act (Regulation (EU) 2024/1689), an AI system used in a regulated process is expected to keep records of how output was produced and checked. A documented certified review gives you that record. An unlogged machine pass gives you nothing to show.


Where it goes wrong


Three failure modes account for most of the rejected MDR translations we're asked to fix after the fact:


  • An unconstrained model. Run a general LLM with no term base and it will paraphrase warnings, invent synonyms for device names, and produce fluent text that fails terminology review.

  • No human sign-off. Pushing raw output into the file means no qualified person has taken responsibility for it, which is exactly what ISO 18587 and ISO 13485 require.

  • Public-cloud transit. Sending the technical file through a public translation API moves controlled product data through servers you don't control, and it breaks the EU data-residency posture GDPR and your own security review expect.


We built our device workflow around those three traps. AD VERBUM runs MDR and IVDR files on EU-hosted, client-tuned models with certified SME review, and you can see how we rank that approach against other providers in best AI translation services for medical device IFUs and labelling and best AI translation companies for MDR and IVDR documentation.


Our medical device translation services


translation services for regulated sectors run on ISO 27001 and ISO 42001 certified, EU-hosted infrastructure, with no reliance on public cloud tooling for core processing. Every project runs through our AI+HUMAN hybrid workflow: we ingest client Translation Memories and Term Bases first, our proprietary LLM-based LangOps System generates output constrained by client terminology on client-tuned open-weight models, and our certified subject-matter experts review for technical accuracy and regulatory compliance. Our QA is aligned to ISO 17100 and ISO 18587, with sector-specific requirements such as ISO 13485 device quality management and MDR Article 10(11) language rules applied where relevant. We serve Life Sciences, Legal, Finance, Defense, and Manufacturing clients across 150+ languages with 3,500+ subject-matter linguists. For teams managing audit-sensitive content, contact us to discuss your security and compliance requirements directly.


FAQ


Does MDR allow AI document translation for technical files?


Yes. The Medical Device Regulation (Regulation (EU) 2017/745) names no tool and bans none. Article 10(11) requires the Instructions for Use and label to be accurate in each market's official language, and Annex II requires clear, current technical documentation. AI translation meets that when a certified linguist post-edits the output under ISO 18587 and ISO 13485.


What does the notified body actually check?


The record, not the model. A notified body inspects whether the translated document is accurate and current, and whether your quality system controlled how it was produced. A documented certified review under ISO 13485 and ISO 17100 answers that, so keep the reviewer, the term base version, and the sign-off on file.


Why lock a term base before running the model?


Because the term base is what stops the model paraphrasing a safety term. It fixes device names, warnings, and contraindication wording to the forms a notified body has already accepted, so constrained generation produces compliant text instead of fluent guesses that review then has to catch.


Is raw machine translation the same as AI translation here?


No. Raw machine or NMT output with no review is not what we mean by AI translation. AD VERBUM's AI translation is a client-tuned LLM constrained by your term base, followed by certified human review under ISO 18587. The review is the difference, not a synonym.


How does AI document translation keep data inside the EU?


By running on EU-hosted infrastructure with no public-cloud API in the path and no training on client data. That keeps controlled technical documentation under EU data residency, which GDPR and most medical-device security reviews require before a file leaves your systems.


What breaks MDR compliance fastest?


Unreviewed output in a safety-critical sentence. An IFU warning or an SSCP statement under Article 32 that no qualified linguist signed for is an error on the public record. Unconstrained models, missing sign-off, and public-cloud transit are the three causes we see most.


Recommended


 
 
bottom of page