El software médico se actualiza de forma continua. El flujo de trabajo de traducción tiene que seguir el ritmo sin comprometer la conformidad. Mientras que la industria farmacéutica y los ensayos clínicos se rigen por largos ciclos de presentación de documentos, el software como producto sanitario (SaMD) se desarrolla en entornos de integración continua y despliegue continuo (CI/CD). El departamento de asuntos regulatorios es el responsable del expediente, mientras que el de ingeniería se encarga del repositorio. El organismo notificado del MDR, el organismo de evaluación de la conformidad del Reglamento de IA de la UE y el Grupo de Software de la MHRA del Reino Unido exigen todos un registro de auditoría que se adapte de manera ordenada al ritmo de los ciclos de trabajo que ninguno de ellos diseñó.
En 2026, cinco marcos normativos regulan ese cruce:
- Reglamento (UE) 2017/745 (el MDR)
- Reglamento (UE) 2017/746 (el IVDR)
- Reglamento (UE) 2024/1689 (el Reglamento de IA de la UE)
- Reglamento de productos sanitarios del Reino Unido de 2002 (UK Medical Devices Regulations 2002)
- El programa de cambio sobre software e IA como producto sanitario de la MHRA
La traducción se aplica a los cinco marcos a la vez, sin importar la frecuencia de lanzamiento que tenga el equipo de ingeniería.
Esta guía reúne todos esos elementos en un solo lugar:
- La matriz de clasificación de la Regla 11 del MDR
- La matriz de elementos de software
- El calendario del Reglamento de IA de la UE tras el Ómnibus de mayo de 2026
- El marco normativo de la MHRA del Reino Unido
- El enfoque de la integración de CI/CD
- Una lista de verificación para evaluar a los proveedores
Si eres el director técnico, el responsable de ingeniería, de internacionalización, de asuntos regulatorios o de calidad en una empresa de salud digital, tecnología médica o productos sanitarios con IA que comercializa sus productos en la UE y en el Reino Unido, encontrarás información más detallada sobre la metodología de calidad en nuestro artículo sobre aseguramiento de la calidad en la traducción médica. Para conocer cómo estructuramos nuestro trabajo de traducción médica, visita nuestra página de servicios de traducción médica.
Resumen
|
Requisitos para la traducción de software médico en la UE y el Reino Unido
En 2026, la traducción de software médico se rige por cinco marcos normativos:
- El MDR (Reglamento (UE) 2017/745), que regula dos categorías: el software como producto sanitario (SaMD) y el software integrado en un producto sanitario (SiMD).
- El IVDR (Reglamento (UE) 2017/746), que regula el software de diagnóstico in vitro a través de sus propias normas de clasificación.
- El Reglamento de IA de la UE (Reglamento (UE) 2024/1689), que añade obligaciones de alto riesgo a las del MDR o el IVDR, para los productos sanitarios con IA.
- El Reglamento de productos sanitarios del Reino Unido de 2002, que regula el software en Gran Bretaña.
- El programa de cambio de software e IA como producto sanitario de la MHRA, que impulsa una agenda de reforma activa en paralelo.
La traducción se aplica en paralelo a los cinco marcos: los idiomas oficiales de cada Estado miembro o jurisdicción donde se pone a disposición el software, con los elementos específicos del software dentro de ese alcance.
SaMD, SiMD y las aplicaciones complementarias: dónde están los límites
Hay tres categorías de software que están dentro del alcance de la traducción médica:
- Software como producto sanitario (SaMD): software autónomo que realiza funciones médicas sin formar parte de un producto sanitario de hardware, como algoritmos de diagnóstico por imagen, aplicaciones para evaluar síntomas y sistemas de apoyo a la toma de decisiones clínicas.
- Software integrado en un producto sanitario (SiMD): software integrado en hardware, como el firmware que controla una bomba de infusión, el algoritmo dentro de un monitor de ECG o el software operativo de un escáner de tomografía computarizada.
- Aplicaciones complementarias: aplicaciones móviles destinadas a los pacientes que pueden cumplir o no con la definición de producto sanitario, según su finalidad prevista.
El MDCG 2019-11 (actualizado en 2023) es el documento que establece el árbol de decisión que determina si un determinado software cumple con los requisitos para considerarse un producto sanitario según el MDR. Si estás valorando un trabajo de traducción, deberías preguntar a tu equipo de asuntos regulatorios cuál es la clasificación actual de la Regla 11 antes de encargar nada.
El ámbito de aplicación del IVDR
El software de diagnóstico in vitro se rige por el IVDR y no por el MDR. El principio de traducción es el mismo: el artículo 18, apartado 1, del IVDR refleja lo establecido en el artículo 10, apartado 11, del MDR en cuanto al alcance lingüístico. La vía de evaluación de la conformidad es diferente, con normas de clasificación específicas para los productos de diagnóstico in vitro (IVD) y requisitos lingüísticos que dependen de cómo haya implementado cada Estado miembro el IVDR.
Para los fabricantes de tecnología médica que desarrollan algoritmos de diagnóstico, sobre todo diagnósticos complementarios para imágenes con IA, la vía del IVDR funciona en paralelo a la del MDR como una línea de trabajo independiente, con su propia matriz lingüística y su propio registro de auditoría.
Regla 11 del MDR: cómo se clasifica el software y qué implica para el alcance de la traducción
La Regla 11 del anexo VIII del MDR es la norma de clasificación específica para el software. La mayor parte del software que era Clase I según la antigua Directiva sobre productos sanitarios (MDD), ahora es Clase IIa o superior según el MDR. La clase determina la participación del organismo notificado, la vía de evaluación de la conformidad y el registro de auditoría necesario en torno al trabajo de traducción.
La Regla 11 se refiere a las consecuencias de un error de la información: cuando el software proporciona información para tomar decisiones diagnósticas o terapéuticas, la clase varía en función de la gravedad del daño que se produciría si esa información fuera errónea.
| Función del software | Clase de la Regla 11 | Participación del organismo notificado | Implicaciones para el alcance de la traducción |
|---|---|---|---|
| Información para decisiones diagnósticas o terapéuticas en las que un error puede causar la muerte o un daño irreversible | Clase III | Evaluación completa de la conformidad por el organismo notificado con escrutinio | Anexo I completo, sección 23; SSCP por Estado miembro; revisión local obligatoria |
| Información para tomar decisiones diagnósticas o terapéuticas en las que un error podría provocar un deterioro grave o requerir intervención quirúrgica | Clase IIb | Evaluación completa de la conformidad por parte del organismo notificado | Anexo I completo, sección 23; extractos de la documentación técnica a solicitud |
| Información para tomar decisiones diagnósticas o terapéuticas (otros casos) | Clase IIa | Evaluación completa de la conformidad por parte del organismo notificado | Anexo I completo, sección 23; declaración de la conformidad en el idioma del Estado miembro |
| Software que monitoriza procesos fisiológicos en los que una variación podría causar un peligro inmediato | Clase IIb | Evaluación completa de la conformidad por parte del organismo notificado | Anexo I completo, sección 23; informes de vigilancia por Estado miembro |
| Software que monitoriza procesos fisiológicos (otros casos) | Clase IIa | Evaluación completa de la conformidad por parte del organismo notificado | Anexo I completo, sección 23 |
| Cualquier otro software (por defecto) | Clase I | Autodeclarado | La sección 23 del anexo I sigue vigente; a menudo no se destinan suficientes recursos a la traducción |
La migración de la Clase I a la Clase IIa y lo que supone en cuanto a trabajo de traducción
La Clase I según la MDD pasa a ser Clase IIa, IIb o III según el MDR para la mayoría de los programas informáticos de diagnóstico y tratamiento. Las consecuencias prácticas son claras: participación de un organismo notificado, revisión de la documentación técnica durante la evaluación de la conformidad y un alcance lingüístico que cumple con todas las obligaciones del anexo I, apartado 23.
Para una empresa de salud digital que haya desarrollado su cartera de productos conforme con la antigua Directiva sobre productos sanitarios (MDD), la migración conlleva un coste real que hay que tener en cuenta en el calendario de transición al Reglamento de productos sanitarios. Un coste que a menudo se pasa por alto: el tiempo que dedica el revisor local a revisar las cadenas de la interfaz de usuario traducidas durante la auditoría del organismo notificado, en la que el revisor comprueba cada cadena traducida comparándola con la intención original y la documentación técnica. El MDCG 2024-7 (Preguntas y respuestas sobre la clasificación de la Regla 11) es la guía operativa más reciente y vale la pena leerla antes de definir el alcance de cualquier nuevo programa de traducción de SaMD.
¿Qué elementos de software hay que traducir?
La traducción de software médico abarca más que las cadenas de la interfaz de usuario. La matriz completa de elementos se divide en cuatro flujos:
- Contenido de software para el usuario: cadenas de la interfaz de usuario, texto dentro de la aplicación, flujos de incorporación y notas de la versión.
- Información complementaria que cumple con el MDR: instrucciones de uso electrónicas, ayuda integrada en la aplicación a la que se accede desde el dispositivo y acuerdos de licencia de usuario final (EULA).
- Documentación técnica normativa: elementos del ciclo de vida del software según la norma IEC 62304, documentación sobre ciberseguridad y documentación técnica relativa al Reglamento de IA.
- Documentación posterior a la comercialización: notas de la versión, avisos de seguridad y notas de seguridad sobre el terreno para software.
Cada flujo tiene su propio ritmo de traducción y sus propios requisitos en cuanto al registro de auditoría.
| Elemento | Lector principal | Función normativa | Especificaciones de traducción |
|---|---|---|---|
| Cadenas de la interfaz de usuario (menús, botones, ventanas de diálogo) | Usuarios | UX; usabilidad según la norma IEC 62366-1 | Longitud de cadenas, pluralización, accesibilidad |
| Mensajes de error | Usuarios, profesionales sanitarios | Seguridad del usuario | Lenguaje conciso y claro, terminología coherente |
| Ayuda integrada en la aplicación | Usuarios | Información complementaria (anexo I, sección 23) | Revisión contextual en la maqueta |
| Flujos de incorporación | Usuarios | Orientación en el primer uso | Texto breve, pantalla por pantalla |
| Notas de la versión | Usuarios, profesionales sanitarios | Comunicación posterior a la comercialización | Con control de versiones, según la cadencia |
| Instrucciones de uso electrónicas (eIFU) | Usuarios, profesionales sanitarios | Anexo I, sección 23 | Traducción completa de las instrucciones de uso, con calidad normativa |
| EULA y política de privacidad | Usuarios | Legal | Preciso y que tiene en cuenta la jurisdicción |
| Cadenas de accesibilidad (lector de pantalla, texto alternativo) | Usuarios de tecnología de apoyo | Cumplimiento de las normas de accesibilidad | Línea de trabajo distinta, que a menudo se pasa por alto |
| Documentación sobre el ciclo de vida del software según la norma IEC 62304 | Organismo notificado | Evaluación de la conformidad | Presentado en el idioma de trabajo del organismo notificado (a menudo inglés) |
| Expediente de ingeniería de usabilidad según la norma IEC 62366-1 | Organismo notificado | Validación de la usabilidad | Admite la aprobación de la interfaz de usuario traducida |
| Documentación de ciberseguridad | Organismo notificado; autoridades competentes | Anexo I del MDR; MDCG 2019-16 | Se pueden solicitar extractos en el idioma local |
| Documentación técnica del Reglamento de IA | Organismo de evaluación de la conformidad del Reglamento de IA | Artículos 11 a15 del Reglamento de IA | El texto sigue la práctica del Reglamento de IA |
| Aviso de transparencia del artículo 50 del Reglamento de IA | Usuarios | Divulgación de la interacción con la IA | Por idioma; visible para el usuario |
| Notas de seguridad sobre el terreno (software) | Usuarios; autoridades competentes | Artículo 89, apartado 8 | Por Estado miembro |
Las cadenas de la interfaz de usuario y las restricciones que debe tener en cuenta la traducción
La traducción de la interfaz de usuario conlleva restricciones específicas del software que no se dan en la traducción de instrucciones de uso de dispositivos de hardware. Las principales son:
- Longitud de la cadena. El alemán suele ser un 30 % más largo que el inglés, mientras que el chino es un 40 % más corto. Una etiqueta de botón que entra en inglés puede no caber en el botón o quedar descolocada en los idiomas de destino.
- Pluralización, género y variables. El formato de mensajes ICU gestiona estos aspectos en las principales configuraciones regionales y es el estándar de trabajo para cualquier cadena de interfaz de usuario con variaciones gramaticales.
- Cadenas de accesibilidad. El texto para lectores de pantalla, el texto alternativo y las etiquetas ARIA forman un área de trabajo específico que la mayoría de los proveedores de servicios lingüísticos pasan por alto y que, si se omite, hace fallar la auditoría de accesibilidad.
- Texto bidireccional. Para cualquier configuración regional que utilice el árabe o el hebreo, el cambio de maquetación y los marcadores de dirección incrustados suponen un paso adicional en el proceso de entrega entre equipos de ingeniería.
- Codificación. El estándar es Unicode UTF-8.
La revisión en contexto a través de nuestra herramienta SmartEdit permite al traductor ver cada cadena en la interfaz de usuario tal y como la verá el usuario, lo que alimenta directamente el expediente de ingeniería de usabilidad según la norma IEC 62366-1.
El límite entre el software y el MDR
La traducción de las instrucciones de uso (IFU), las etiquetas, el embalaje y las fichas de implante de los productos sanitarios de hardware se tratan por separado en los requisitos de traducción del MDR. Los elementos específicos del software son el tema de este artículo. Los compradores que necesiten ambos servicios deberían elegir un único proveedor de servicios lingüísticos (LSP) que se encargue de ambos con un mismo proceso, una misma base terminológica y un mismo registro de auditoría. Contar con dos proveedores puede generar falta de coherencia terminológica y lagunas en el registro de auditoría, que salen a la luz en la siguiente inspección del organismo notificado.
El Reglamento de IA de la UE tras el Ómnibus de mayo de 2026
El Reglamento de IA de la UE (Reglamento (UE) 2024/1689) clasifica los productos sanitarios con IA como sistemas de IA de alto riesgo según el artículo 6, apartado 1. El acuerdo político sobre el «Ómnibus Digital» alcanzado por el Consejo y el Parlamento el 7 de mayo de 2026 (una semana antes de la publicación de este artículo) amplió los plazos de cumplimiento de alto riesgo.
Para los SaMD con componentes de IA o aprendizaje automático (ML), este es el cambio normativo más importante de 2026 en lo que respecta al trabajo de traducción. Hay tres áreas de obligaciones que tienen implicaciones en la traducción: la documentación técnica del Reglamento de IA según los artículos 11 a 15, la transparencia para los usuarios según el artículo 50 y la formación en IA según el artículo 4.
| Fecha | Qué rige | Implicación de traducción |
|---|---|---|
| 1 de agosto de 2024 | Entra en vigor el Reglamento de IA | Ninguna directamente |
| 2 de febrero de 2025 | Se aplican las prácticas prohibidas en materia de IA y la obligación de formación en IA | Traducción de políticas internas; contenido de formación del personal |
| 2 de agosto de 2025 | Se aplican las obligaciones del modelo GPAI | Documentación del modelo base, si se utiliza |
| 2 de agosto de 2026 | Se aplica la obligación de formación en IA (artículo 4) | Formación del personal, avisos de formación en IA para usuarios por Estado miembro |
| 2 de diciembre de 2026 | Transparencia en el contenido generado por IA (artículo 50) | Información sobre la interacción con IA para usuarios por Estado miembro |
| 2 de diciembre de 2027* | IA autónoma de alto riesgo según el anexo III (ampliación posterior al Ómnibus) | Documentación completa de evaluación de la conformidad en los idiomas de presentación |
| 2 de agosto de 2028* | IA de alto riesgo integrada en productos regulados del anexo I (ampliación posterior al Ómnibus; abarca la mayoría de la IA médica) | Documentación técnica completa sobre el Reglamento de IA junto con la documentación del MDR |
*Sujeto a la aprobación formal del acuerdo político sobre el «Ómnibus Digital» alcanzado el 7 de mayo de 2026. Los plazos originales eran el 2 de agosto de 2026 (anexo III) y el 2 de agosto de 2027 (anexo I).
Qué hay que traducir para los productos sanitarios con IA de alto riesgo
Los productos sanitarios con IA de alto riesgo incluyen un conjunto de documentación conforme al Reglamento de IA que se presenta junto con el expediente técnico del MDR. Este conjunto de documentación abarca la gestión de mantenimiento de los datos de entrenamiento, la evaluación de la calidad de los datos y los sesgos de los datos, la transparencia para los usuarios, el diseño de la supervisión humana, las especificaciones de precisión y solidez, los planes de seguimiento posteriores a la comercialización y una entrada en la base de datos de la UE. La mayor parte de esta documentación se envía al organismo notificado en inglés, que es su idioma de trabajo.
Hay dos documentos que se envían a los usuarios en el idioma de cada Estado miembro:
- el aviso de transparencia del artículo 50 en el que se indica al usuario que está interactuando con un sistema de IA, y
- cualquier indicación específica sobre la IA en las instrucciones de uso.
La obligación de formación en IA prevista en el artículo 4, que seguirá vigente a partir del 2 de agosto de 2026 incluso tras la entrada en vigor del «Ómnibus», exige que se ofrezcan contenidos de formación en IA al personal que implemente sistemas de IA, a menudo en el idioma del mercado de destino.
Cumplir con el MDR y el Reglamento de IA a la vez
Los SaMD con IA requieren una evaluación de la conformidad con el MDR y una evaluación de la conformidad con el Reglamento de IA en el mismo programa. La postura de la Comisión Europea, confirmada por el acuerdo político «Ómnibus» de mayo de 2026, es que ambas evaluaciones se integren cuando un único organismo notificado se encargue de ambas: un único marcado CE, una única declaración de conformidad y un único expediente técnico con secciones dedicadas tanto al MDR como al Reglamento de IA.
Lo que esto implica en la traducción: un único expediente técnico coherente que abarque ambos regímenes normativos, con un registro de auditoría y un control de versiones que cubran ambos. Un proveedor de servicios lingüísticos que se ocupe del MDR pero no demuestre dominio del Reglamento de IA creará una laguna en la auditoría en cuanto las secciones de IA entren en el ámbito de aplicación. Nuestra herramienta SmartDesk cuenta con ese registro de auditoría combinado.
El marco normativo de la MHRA del Reino Unido en 2026
El software médico del Reino Unido se rige por el Reglamento sobre productos sanitarios de 2002 (modificado), que gestiona la MHRA. El programa de cambio sobre software e IA como producto sanitario de la MHRA está en marcha desde octubre de 2022 y seguirá evolucionando hasta 2026.
Hay tres novedades que marcan el trabajo de traducción de SaMD en mayo de 2026:
- las nuevas normativas de vigilancia posteriores a la comercialización en vigor desde junio de 2025;
- el sistema de reconocimiento internacional (International Reliance) que se puso en marcha en el primer semestre de 2026; y
- la Comisión Nacional para la Regulación de la IA en la asistencia sanitaria que debe presentar sus recomendaciones a finales de este año.
El reconocimiento CE en Gran Bretaña se ha ampliado de forma indefinida en virtud de la reforma del 22 de julio de 2025, lo que simplifica el expediente técnico para el doble mercado de las empresas multinacionales de SaMD.
El sistema de reconocimiento internacional (International Reliance)
El sistema de reconocimiento internacional (International Reliance) de la MHRA permite que los software como producto sanitario (SaMD) que cuenten con la autorización de la FDA, Health Canada o la TGA sigan una vía simplificada para acceder al mercado británico. Para una empresa de salud digital con una autorización 510(k) o De Novo de la FDA, los plazos en el Reino Unido se reducen de forma significativa.
En cuanto a la traducción, las implicaciones son más operativas que normativas: el expediente adapta la documentación extranjera sobre rendimiento clínico, ciberseguridad y gestión de riesgos a la normativa británica sobre productos sanitarios de 2002. La mayor parte de la documentación normativa se mantiene en inglés, pero las notas de versiones del Reino Unido, las notas de la versión dirigida a los usuarios y los materiales posteriores a la comercialización deben estar específicamente en inglés británico. Las diferencias de estilo y convenciones entre el inglés de EE. UU., el inglés australiano y el inglés británico son lo suficientemente grandes como para justificar una configuración regional independiente en la memoria de traducción.
El reconocimiento del marcado CE en Gran Bretaña y la simplificación del doble mercado
Desde la reforma del 22 de julio de 2025, los dispositivos con marcado CE siguen siendo válidos para el mercado del Reino Unido de forma indefinida. Se han eliminado las anteriores cláusulas de caducidad del 30 de junio de 2028 y del 30 de junio de 2030, a la espera de una consulta. Las empresas multinacionales de SaMD mantienen un único expediente técnico de la UE para ambos mercados, con una variante regional en inglés británico superpuesta para el contenido dirigido al usuario.
Lo que esto implica para la traducción: un único conjunto de documentos de la UE con una variante en inglés británico para el contenido dirigido a los usuarios, en lugar de dos conjuntos paralelos. Esto supuso una simplificación operativa significativa cuando entró en vigor en julio de 2025, y sigue siendo la hipótesis de trabajo para la mayoría de las empresas de SaMD que gestionan programas en el Reino Unido y la UE al mismo tiempo.
Integración de CI/CD y localización continua
El SaMD se actualiza de forma continua. Las aplicaciones complementarias para pacientes se lanzan cada semana, a veces incluso con más frecuencia. El flujo de trabajo de traducción tiene que integrarse con el de desarrollo de software a través de una API o un conector, y no funcionar en paralelo como un proceso independiente que lo ralentice todo. Esta es la parte de la traducción de software médico que depende de la ingeniería, y en la que la mayoría de los proveedores de servicios lingüísticos cometen más errores. Nuestra herramienta SmartConnect es nuestro principal soporte tecnológico para esta integración.
Integración con el repositorio
Nuestra herramienta SmartConnect ofrece integración mediante API o webhook con el repositorio de origen (GitHub, GitLab, Bitbucket) para que los cambios de cadenas pasen por el proceso de traducción sin necesidad de traspasos manuales. El conector supervisa las confirmaciones en los expedientes de recursos designados (JSON, YAML, .properties, .strings, .xliff), extrae las cadenas modificadas, las envía a la memoria de traducción y al lingüista humano, y devuelve las cadenas traducidas a una rama de características o a una solicitud de incorporación de cambios para que el equipo de ingeniería las revise.
El registro de auditoría que indica quién tradujo qué versión de qué cadena, cuándo y con qué base terminológica queda guardado en nuestra herramienta SmartDesk para la auditoría del organismo notificado del MDR y la documentación técnica del Reglamento de IA. Para un equipo de ingeniería que trabaja con versiones semanales, la alternativa es un ciclo manual de «exportar-traducir-importar» que retrasa los lanzamientos y provoca falta de coherencia terminológica entre versiones.
La revisión en contexto y el traspaso según la norma IEC 62366-1
La traducción de software que no pasa por una revisión en contexto no supera la validación de usabilidad según la norma IEC 62366-1. El traductor tiene que ver la cadena en la interfaz de usuario tal como la verá el usuario, con el contexto, la maquetación y los elementos visuales que la rodean a la vista.
Nuestra herramienta SmartEdit ofrece revisión en contexto para revisores locales sin necesidad de una licencia de InDesign ni de herramientas front-end. El revisor puede ajustar la longitud de las cadenas, corregir problemas de maquetación y confirmar que la traducción se lee con naturalidad en la interfaz de usuario renderizada. El resultado se incorpora directo al expediente de ingeniería de usabilidad según la norma IEC 62366-1, como parte de la documentación técnica que se envía al organismo notificado. Sin este paso, la interfaz de usuario traducida no se valida como parte de la interfaz de usuario, lo que supone un incumplimiento de la normativa durante la revisión del MDR.
Lista de verificación para evaluar proveedores de traducción de software médico
Un proveedor de traducción especializado en software médico combina dominio de la normativa médica (Regla 11 del MDR, Reglamento de IA de la UE, Grupo de Software de la MHRA) con la capacidad de integración de ingeniería de software (API, CI/CD, formato de mensajes ICU, revisión en contexto). La mayoría de los proveedores de servicios lingüísticos tienen una cosa o la otra, y pocos tienen ambas. La lista de verificación que aparece a continuación evalúa ambos aspectos con el nivel de detalle que exige un programa de SaMD.
| Criterio | Por qué es importante para el trabajo con software médico | Qué preguntar en la RFP |
|---|---|---|
| ISO 17100 | Base del proceso de traducción humana | Adjunta tu certificado ISO 17100 vigente e indica el organismo de certificación. |
| ISO 18587 | Es obligatorio cuando se usa MTPE en cadenas de la interfaz de usuario o en texto dentro de la aplicación | ¿Cuentas con la certificación ISO 18587 para tus servicios de posedición de traducción automática? Adjunta el certificado. |
| ISO 27001 | Seguridad de la información para contenido de software regulado | Confirma la certificación ISO 27001 y adjunta las pruebas correspondientes. |
| Dominio de la Regla 11 del MDR | La clase determina el alcance de la traducción y el registro de auditoría | Explica cómo tu sistema de gestión de la calidad (SGC) cumple con la Regla 11 del MDR y la MDCG 2024-7. ¿Qué pruebas puedes aportar de las solicitudes recientes de SaMD? |
| Conocimiento del Reglamento de IA de la UE | Los productos sanitarios con IA de alto riesgo necesitan la documentación técnica del Reglamento de IA | Explica cómo gestionas la documentación técnica de los artículos 11 a 15 del Reglamento de IA y los avisos de transparencia del artículo 50. |
| Marco del Grupo de Software de la MHRA | El proceso del Reino Unido se basa en la MHRA, no en la EMA ni en la NB | Explícanos cómo gestionas el trabajo de SaMD del Reino Unido, incluido el inglés británico como variante regional y la adaptación del expediente del sistema de reconocimiento internacional (International Reliance). |
| Integración del repositorio de software | El envío continuo descarta el traspaso manual | ¿A qué repositorios te conectas (GitHub, GitLab, Bitbucket)? Explícanos paso a paso cómo es un proceso típico desde el commit hasta el lanzamiento. |
| Integración del proceso de CI/CD | La traducción no debe retrasar el lanzamiento | ¿Cómo se integra tu plataforma con Jenkins, GitHub Actions, GitLab CI o CircleCI? |
| Compatibilidad con el formato de mensajes ICU | Pluralización, género e inserción de variables según la configuración regional | Confirma que es compatible con el formato de mensajes ICU y describe cómo se gestionan las normas de pluralización en tu equipo de lingüistas. |
| Herramientas de revisión en contexto | Requerido para la validación de usabilidad según la norma IEC 62366-1 | ¿Pueden los revisores locales ver y editar cadenas traducidas en la interfaz de usuario renderizada sin necesidad de herramientas de ingeniería? |
| Cadenas de accesibilidad | El texto para lectores de pantalla, el texto alternativo y las etiquetas ARIA constituyen una línea de trabajo independiente | ¿Cómo gestionas las cadenas de accesibilidad y cómo compruebas que se lean de manera correcta en los idiomas de destino? |
| Registro de auditoría por proyecto | Lo exigen tanto el organismo notificado del MDR como el organismo de evaluación de la conformidad del Reglamento de IA. | ¿Qué registros de auditoría por proyecto generas, y durante cuánto tiempo los conservas? |
En AdHoc Translations, contamos con las certificaciones ISO 17100 e ISO 18587 vigentes, cuyos certificados están disponibles en nuestra web para que puedas comprobarlos directamente:
- nuestra herramienta SmartConnect ofrece el repositorio y la integración de CI/CD que exige la vertiente de ingeniería de la traducción de software médico;
- nuestra herramienta SmartDesk incluye el registro de auditoría por proyecto que exigen tanto la revisión del organismo notificado del MDR como la documentación técnica del Reglamento de IA; y
- nuestra herramienta SmartEdit permite revisar el código en contexto sin necesidad de una licencia de herramientas de ingeniería
Para interiorizarte más sobre el proceso de control de calidad de todo el trabajo de traducción médica, consulta nuestro artículo sobre aseguramiento de la calidad en la traducción médica.
Preguntas frecuentes
¿Qué es el software como producto sanitario (SaMD)?
El software como producto sanitario, según la definición del International Medical Device Regulators Forum (Foro Internacional de Autoridades Reguladoras de Productos Sanitarios), es aquel software destinado a uno o más fines médicos que cumple dichos fines sin formar parte de un producto sanitario de hardware. Algunos ejemplos son los algoritmos de diagnóstico por imagen, las aplicaciones para la evaluación de síntomas y los sistemas de apoyo a la toma de decisiones clínicas. El SaMD se rige por el Reglamento (UE) 2017/745 (el MDR) en la UE.
¿Se aplica el Reglamento de IA de la UE al software médico?
Sí, cuando el software incluya componentes de IA o de aprendizaje automático. Los productos sanitarios con IA regulados por el MDR o el IVDR se clasifican de forma automática como de alto riesgo según el artículo 6, apartado 1, del Reglamento de IA. Tras el acuerdo político sobre el «Ómnibus Digital» del 7 de mayo de 2026, el plazo de cumplimiento para la IA integrada en productos sanitarios del anexo I se ha ampliado hasta el 2 de agosto de 2028, siempre que se apruebe oficialmente.
¿Qué es la Regla 11 del MDR?
La Regla 11 del anexo VIII del Reglamento (UE) 2017/745 es la norma de clasificación específica para el software en el marco del MDR. Clasifica la mayor parte del software como producto sanitario como clase IIa o superior, según las consecuencias que pueda tener un error de información. Las decisiones que impliquen la muerte o un daño irreversible sitúan el software en la clase III. Las decisiones que impliquen un deterioro grave lo sitúan en la clase IIb. La mayor parte del software de información diagnóstica y terapéutica es la clase IIa.
¿En qué se diferencia la traducción de software médico de la localización de software habitual?
La traducción de software médico debe cumplir los requisitos normativos que rigen los productos sanitarios de hardware: las obligaciones lingüísticas del artículo 10, apartado 11, del MDR; la información adjunta del apartado 23 del anexo I, la documentación sobre el ciclo de vida del software según la norma IEC 62304; la validación de la usabilidad según la norma IEC 62366-1; y (para los componentes de IA) la documentación técnica prevista en el Reglamento de IA. La localización habitual de software no tiene ninguna de estas obligaciones. El proveedor de traducción debe entender tanto la normativa como la integración en la ingeniería de software.
Conecta tus sistemas con nuestra herramienta SmartConnect
Si tu proveedor de traducción actual no puede integrarse con tu repositorio de software, tu proceso de CI/CD y los requisitos de registro de auditoría del organismo notificado con un solo proceso, el siguiente paso es realizar una evaluación estructurada del proveedor. Conecta tus sistemas con nuestra herramienta SmartConnect para ver cómo gestionamos la traducción de software médico para empresas de SaMD, SiMD y aplicaciones complementarias en toda la UE y el Reino Unido.
Fuentes
- EUR-Lex, Regulation (EU) 2017/745 (MDR), Annex VIII Rule 11 (Reglamento [UE] 2017/745 [MDR], anexo VIII, Regla 11). https://eur-lex.europa.eu/eli/reg/2017/745/oj?eliuri=eli%3Areg%3A2017%3A745%3Aoj&locale=es. Consultado el 14 de mayo de 2026.
- EUR-Lex, Regulation (EU) 2017/746 (IVDR) (Reglamento [UE] 2017/746 [IVDR]). https://eur-lex.europa.eu/eli/reg/2017/746/oj?eliuri=eli%3Areg%3A2017%3A746%3Aoj&locale=es#
- EUR-Lex, Regulation (EU) 2024/1689 (the EU AI Act) (Reglamento [UE] 2024/1689, el Reglamento de IA de la UE). https://eur-lex.europa.eu/eli/reg/2024/1689/oj?eliuri=eli%3Areg%3A2024%3A1689%3Aoj&locale=es#
- Council of the EU, AI Act Digital Omnibus political agreement, 7 May 2026 (subject to formal adoption) (Consejo de la UE, acuerdo político sobre el Ómnibus Digital del Reglamento de IA, 7 de mayo de 2026 [sujeto a adopción formal]). https://www.consilium.europa.eu/es/press/press-releases/2026/05/07/artificial-intelligence-council-and-parliament-agree-to-simplify-and-streamline-rules/
- MDCG 2019-11, Guidance on qualification and classification of software (updated 2023) (Orientación sobre la cualificación y clasificación del software [actualizada en 2023]).
- MDCG 2020-1, Clinical evaluation of medical device software (Evaluación clínica del software de productos sanitarios).
- MDCG 2024-7, Q&A on Rule 11 classification (Preguntas y respuestas sobre la clasificación según la Regla 11).
- MDCG 2019-16, Cybersecurity for medical devices (Ciberseguridad para productos sanitarios).
- GOV.UK, Software and Artificial Intelligence as a Medical Device (MHRA Software Group) (Software e inteligencia artificial como producto sanitario [Grupo de Software de la MHRA]). https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
- MHRA Software and AI as a Medical Device Change Programme Roadmap (October 2022, revised December 2024) (Hoja de ruta del programa de cambio de la MHRA sobre software e IA como producto sanitario [octubre de 2022, revisada en diciembre de 2024]).
- MHRA International Reliance scheme (announced 22 July 2025; opens H1 2026) (Sistema de reconocimiento internacional de la MHRA [anunciado el 22 de julio de 2025; se abre en el primer semestre de 2026]).
- GOV.UK, National Commission into the Regulation of AI in Healthcare (call for evidence 18 December 2025 to 2 February 2026; recommendations due 2026) (Comisión Nacional para la Regulación de la IA en la Atención Sanitaria [consulta pública del 18 de diciembre de 2025 al 2 de febrero de 2026; recomendaciones previstas para 2026]).
- IEC 62304, IEC 82304-1, IEC 62366-1, ISO 14971, ISO 13485.
- Certificaciones ISO 17100:2015 e ISO 18587:2017.