top of page
Buscar

Aplicaciones digitales para la salud mental: riesgos, requisitos de seguridad y cumplimiento normativo

hace 1 minuto
39 min de lectura


Agradezco al Grupo de Trabajo de Salud Mental Digital de la Sociedad Española de Psiquiatría y Salud Mental (SEPSM) la información que me han facilitado en el congreso anual de nuestra sociedad para redactar este post.


Introducción y alcance

Las aplicaciones digitales dirigidas a personas con problemas de salud mental se han convertido en una realidad cotidiana de la práctica clínica. Los pacientes las descargan por iniciativa propia, los servicios de salud empiezan a incorporarlas a sus procesos asistenciales y la industria ha desarrollado terapias digitales que se prescriben como cualquier otro tratamiento. La evidencia sobre su eficacia es prometedora, aunque desigual: una revisión paraguas reciente encontró efectos favorables en varios trastornos, pero con una certeza de la evidencia a menudo baja y con escasa representación de las personas con trastornos mentales graves (Crocamo et al., 2025).


Este documento no se ocupa de la eficacia, sino de una cuestión previa que con frecuencia se da por resuelta: qué requisitos de seguridad y de cumplimiento normativo debe reunir una aplicación de este tipo para que su uso sea lícito y seguro, tanto por parte del paciente como cuando la recomienda o la prescribe un profesional sanitario. La presencia de una aplicación en una tienda oficial, su gratuidad o incluso la existencia de estudios que la respaldan no dicen nada sobre si cumple el Reglamento de productos sanitarios, si sus algoritmos se ajustan al Reglamento de inteligencia artificial, si trata lícitamente datos de salud o si los servidores en los que se almacenan esos datos están protegidos y ubicados en un territorio con garantías suficientes.


La pregunta es especialmente pertinente en salud mental. Los datos que generan estas aplicaciones —estados de ánimo, ideación suicida, consumo de sustancias, adherencia a antipsicóticos, patrones de sueño y de movilidad— figuran entre los más sensibles que existen, y su exposición puede causar estigmatización, discriminación laboral o aseguradora, extorsión y un daño clínico directo. Las personas con trastorno mental grave (TMG) añaden factores de vulnerabilidad específicos: capacidad para consentir fluctuante, riesgo suicida, posibles contenidos delirantes relacionados con la vigilancia y una situación social a menudo precaria.


El análisis abarca la normativa de la Unión Europea y la española aplicable en noviembre de 2026, incluidos los cambios introducidos durante este año, y se estructura en torno a los distintos planos de cumplimiento: la cualificación como producto sanitario, la inteligencia artificial, la protección de datos, la seguridad de los servidores e infraestructuras, la ciberseguridad, el Espacio Europeo de Datos de Salud, la responsabilidad por productos defectuosos y la protección del consumidor, el uso asistencial y los requisitos específicos para el TMG. Termina con una matriz de verificación práctica.


Tipología de aplicaciones y actores implicados


Cuatro categorías con regímenes distintos

No existe un régimen jurídico único para «las aplicaciones de salud mental». Las obligaciones dependen ante todo de lo que la aplicación hace y, sobre todo, de lo que su fabricante declara que hace. A efectos de este análisis pueden distinguirse cuatro grandes categorías.


  • Aplicaciones de bienestar: meditación, relajación, diarios de estado de ánimo sin análisis, contadores de hábitos o contenidos psicoeducativos generales. No tienen finalidad médica declarada y no son productos sanitarios, pero sí tratan, casi siempre, datos de salud.

  • Aplicaciones con finalidad médica o terapias digitales: programas estructurados de terapia cognitivo-conductual para un trastorno concreto, herramientas de cribado o de diagnóstico, sistemas de monitorización de síntomas que generan alertas clínicas o que orientan decisiones terapéuticas. Son productos sanitarios.

  • Aplicaciones que incorporan inteligencia artificial, ya sean de bienestar (por ejemplo, los asistentes conversacionales) o con finalidad médica (por ejemplo, modelos predictivos de recaída o de riesgo suicida). A su régimen se suma el Reglamento de inteligencia artificial.

  • Plataformas asistenciales desplegadas por los servicios de salud, que integran aplicaciones de pacientes, paneles clínicos e historia clínica electrónica. A todo lo anterior añaden los requisitos propios del sector público, como el Esquema Nacional de Seguridad.


La Tabla 1 resume qué normas resultan de aplicación a cada categoría. Una misma aplicación puede pertenecer a varias a la vez, y una actualización que añada una función analítica puede hacerla pasar de una categoría a otra.


Tabla 1

Categorías de aplicaciones y normas aplicables

Categoría

Ejemplos en salud mental

Normas aplicables (además de las de consumo y responsabilidad por productos)

Aplicación de bienestar sin IA

Meditación, relajación, diario de estado de ánimo sin análisis, psicoeducación general

RGPD y LOPDGDD; Ley 34/2002 (rastreadores); Reglamento de Ciberresiliencia; RD 1907/1996 si alega beneficios sanitarios; EEDS si declara interoperabilidad con la historia clínica

Producto sanitario de software

Terapia cognitivo-conductual digital para un trastorno, cribado o diagnóstico, monitorización de síntomas con alertas clínicas

MDR y RD 192/2023 (incluida su ciberseguridad); RGPD y LOPDGDD; EEDS si declara interoperabilidad. Excluida del Reglamento de Ciberresiliencia

Aplicación con inteligencia artificial

Asistente conversacional de apoyo emocional; modelo predictivo de recaída o de riesgo suicida

Lo de su categoría de base más el RIA: prohibiciones y transparencia siempre; requisitos de alto riesgo si es producto sanitario de clase IIa o superior o si entra en el anexo III

Plataforma asistencial del sector público

Monitorización de pacientes integrada en la historia clínica, terapia digital prescrita por el servicio de salud

Lo anterior más ENS (RD 311/2022), art. 46 bis Ley 40/2015 (datos en la UE), Ley 41/2002, obligaciones de responsable del despliegue del RIA y NIS2 para el centro

Nota. EEDS = Espacio Europeo de Datos de Salud; ENS = Esquema Nacional de Seguridad; MDR = Reglamento (UE) 2017/745; RGPD = Reglamento (UE) 2016/679; RIA = Reglamento (UE) 2024/1689.


Quién responde de qué

El cumplimiento se reparte entre varios actores, y confundir sus papeles es una de las fuentes más frecuentes de incumplimiento. El fabricante es quien comercializa la aplicación con su nombre y responde de su conformidad como producto. El proveedor de un sistema de inteligencia artificial es quien lo desarrolla o lo comercializa con su nombre; el responsable del despliegue es quien lo utiliza bajo su autoridad, típicamente un hospital. En protección de datos, el responsable del tratamiento decide los fines y los medios: lo es el desarrollador de una aplicación de uso directo por el consumidor, pero lo es el centro sanitario cuando la aplicación forma parte de su asistencia y el desarrollador actúa por cuenta de él. Los proveedores de servicios en la nube y los demás subcontratistas tecnológicos son, normalmente, encargados o subencargados del tratamiento. Las tiendas de aplicaciones actúan, en general, como intermediarios. Y el profesional sanitario que recomienda o prescribe la aplicación responde conforme a la lex artis. Cada uno de estos papeles lleva aparejadas obligaciones distintas que se analizan a continuación.


Requisitos como producto sanitario


Cualificación: la finalidad prevista decide

El Reglamento (UE) 2017/745 sobre los productos sanitarios (en adelante, MDR) incluye el software entre los productos sanitarios cuando el fabricante lo destina a diagnosticar, prevenir, monitorizar, predecir, pronosticar, tratar o aliviar una enfermedad. Su considerando 19 aclara que el software destinado a fines generales o de estilo de vida y bienestar no es producto sanitario. La guía MDCG 2019-11, revisada en junio de 2025, insiste en que la cualificación y la clasificación dependen exclusivamente de la finalidad prevista, con independencia de la plataforma, la integración o el modo de distribución, y reconoce expresamente que el software que incorpora inteligencia artificial está dentro del marco del MDR (Medical Device Coordination Group [MDCG], 2025a).


En salud mental la frontera es especialmente porosa. Un diario de estado de ánimo es una aplicación de bienestar mientras se limita a registrar lo que el usuario anota; pasa a ser producto sanitario si analiza esos registros para estimar un riesgo de recaída, sugiere un ajuste terapéutico o indica que el usuario debería consultar por sospecha de un trastorno.


Un programa de relajación es bienestar; un programa de terapia cognitivo-conductual destinado a tratar el trastorno de pánico es un producto sanitario. Los fabricantes pueden sentirse tentados de declarar una finalidad de bienestar para eludir la evaluación de conformidad mientras su publicidad, sus estudios o su modo de uso real sugieren una finalidad terapéutica. Esa estrategia no elimina la obligación: la finalidad prevista se deduce también del etiquetado, las instrucciones, el material promocional y las declaraciones del fabricante. Para el profesional, el criterio práctico es sencillo: si va a utilizar una aplicación para tratar o vigilar un trastorno, debe exigir que sea un producto sanitario con marcado CE cuya finalidad prevista cubra ese uso.


Clasificación conforme a la regla 11

Una vez cualificado, el software se clasifica con arreglo a la regla 11 del anexo VIII del MDR. El software que proporciona información utilizada para tomar decisiones diagnósticas o terapéuticas es de clase IIa; pasa a clase IIb si esas decisiones pueden causar un deterioro grave del estado de salud o una intervención quirúrgica, y a clase III si pueden causar la muerte o un deterioro irreversible. El software que monitoriza procesos fisiológicos es de clase IIa (IIb si se trata de parámetros vitales cuya variación pueda suponer un peligro inmediato), y el resto es de clase I. En salud mental, una herramienta que estima el riesgo de suicidio para orientar decisiones clínicas puede argumentarse razonablemente como de clase IIb, porque un error de clasificación puede tener consecuencias graves e incluso irreversibles. Las clases IIa, IIb y III exigen la intervención de un organismo notificado.


La Comisión Europea presentó el 16 de diciembre de 2025 una propuesta de revisión del MDR, COM(2025) 1023, que modificaría la regla 11 para permitir que una parte del software, incluidas muchas aplicaciones de autogestión del paciente, se clasifique en clase I y quede, por tanto, fuera de la intervención del organismo notificado (Comisión Europea, 2025a). La propuesta sigue en tramitación. Si prospera, reducirá las barreras de entrada para las aplicaciones de menor riesgo, pero también trasladará más peso a la autocertificación del fabricante y, en consecuencia, a la evaluación independiente por parte de los usuarios profesionales.


Obligaciones del fabricante

Un producto sanitario de software está sujeto al conjunto de obligaciones del MDR, que conviene enumerar porque constituyen la base de cualquier verificación:


  • Sistema de gestión de la calidad (artículo 10), habitualmente conforme a la norma ISO 13485, y sistema de gestión de riesgos a lo largo de todo el ciclo de vida, conforme a la norma ISO 14971.

  • Evaluación clínica basada en datos clínicos suficientes (artículo 61 y anexo XIV) y plan de seguimiento clínico poscomercialización.

  • Documentación técnica completa (anexos II y III), declaración UE de conformidad y marcado CE con el número del organismo notificado.

  • Identificación única del producto (UDI) y registro en la base de datos europea EUDAMED.

  • Persona responsable del cumplimiento de la normativa dentro de la organización (artículo 15) y, si el fabricante no está establecido en la Unión, un representante autorizado (artículo 11).

  • Cobertura financiera suficiente para responder de los daños que pueda causar el producto (artículo 10.16).

  • Sistema de vigilancia poscomercialización, con informes periódicos de seguridad en las clases IIa y superiores, y notificación de incidentes graves a la autoridad competente (artículos 83 a 92).

  • Información al usuario en la lengua oficial del Estado en que se comercializa; en España, en castellano, conforme al Real Decreto 192/2023.


Requisitos de seguridad informática en el propio MDR

El MDR contiene requisitos de ciberseguridad que a menudo pasan inadvertidos. El anexo I exige que el software se desarrolle conforme al estado de la técnica, teniendo en cuenta el ciclo de vida, la gestión de riesgos, la verificación y la validación (punto 17.2); que el fabricante establezca los requisitos mínimos de hardware, de redes informáticas y de medidas de seguridad informática, incluida la protección frente al acceso no autorizado (punto 17.4); y que el diseño reduzca los riesgos derivados de la interacción entre el software y el entorno informático en el que funciona. La guía MDCG 2019-16 desarrolla estos requisitos: exige integrar la seguridad desde el diseño, definir el entorno de uso previsto, gestionar las vulnerabilidades durante toda la vida del producto e informar a los usuarios de los requisitos de seguridad que deben cumplir (MDCG, 2020). Las normas IEC 62304 (ciclo de vida del software sanitario), IEC 82304-1 (seguridad del software sanitario como producto independiente), IEC 81001-5-1 (ciberseguridad en el ciclo de vida del software sanitario) e IEC 62366-1 (ingeniería de la usabilidad) son las vías habituales para demostrar el cumplimiento.


La consecuencia es importante para el objeto de este análisis: en un producto sanitario, la seguridad de los servidores no es un elemento accesorio del servicio, sino parte del producto evaluado. Si la aplicación depende de un servidor para almacenar o procesar datos clínicos, la arquitectura de ese servidor, su protección y su mantenimiento forman parte de la documentación técnica que examina el organismo notificado, y una vulnerabilidad grave en él puede constituir un incidente que debe notificarse.


El marco nacional: el Real Decreto 192/2023

El Real Decreto 192/2023, de 21 de marzo, completa en España la aplicación del MDR. Designa a la Agencia Española de Medicamentos y Productos Sanitarios (AEMPS) como autoridad competente y de vigilancia del mercado, regula las licencias de actividad, los requisitos lingüísticos, la investigación clínica con productos sanitarios, la publicidad y los productos sujetos a prescripción. A diferencia de otros países, como Alemania con sus aplicaciones de salud digital financiadas por el seguro público, España carece todavía de un procedimiento específico de evaluación, prescripción y financiación de terapias digitales (Bundesinstitut für Arzneimittel und Medizinprodukte [BfArM], s. f.).


Distribución a través de tiendas de aplicaciones

La guía MDCG 2025-4, de junio de 2025, aclara las responsabilidades cuando un producto sanitario de software se distribuye a través de tiendas de aplicaciones. El fabricante «comercializa» el producto en el momento en que lo sube a la plataforma. Las tiendas actúan en general como prestadores de servicios intermediarios conforme al Reglamento de Servicios Digitales, con su régimen de exención de responsabilidad y sin obligación general de supervisión, aunque la guía recomienda que verifiquen la identidad de los desarrolladores y que distingan con claridad entre aplicaciones que son productos sanitarios y las que carecen de finalidad médica (MDCG, 2025b). En consecuencia, la disponibilidad de una aplicación en una tienda oficial no acredita su conformidad normativa.


Requisitos derivados del Reglamento de inteligencia artificial (RIA)


Ámbito y niveles de riesgo

El Reglamento (UE) 2024/1689 de inteligencia artificial (en adelante, RIA) se aplica a cualquier aplicación que incorpore un sistema de IA, sea o no producto sanitario. Adopta un enfoque basado en el riesgo con cuatro niveles relevantes para la salud mental.


  • Prácticas prohibidas (artículo 5), aplicables desde el 2 de febrero de 2025. Entre ellas figuran los sistemas que utilizan técnicas manipuladoras o engañosas, o que explotan vulnerabilidades derivadas de la edad, la discapacidad o la situación social o económica, para alterar el comportamiento de una persona de un modo que pueda causarle un perjuicio considerable, así como el reconocimiento de emociones en el lugar de trabajo y en los centros educativos salvo por motivos médicos o de seguridad. Ninguna población está más directamente protegida por estas prohibiciones que las personas con trastornos mentales.

  • Sistemas de alto riesgo por estar integrados en productos regulados (artículo 6.1 y anexo I): en la práctica, todo producto sanitario de clase IIa o superior que incorpore IA.

  • Sistemas de alto riesgo independientes del anexo III, entre los que se encuentran determinados sistemas de reconocimiento de emociones y los de evaluación y triaje de pacientes en situaciones de urgencia.

  • Obligaciones de transparencia (artículo 50): las personas deben ser informadas de que interactúan con un sistema de IA, y quien despliegue un sistema de reconocimiento de emociones debe informar a las personas expuestas.


Requisitos de los sistemas de alto riesgo

Los proveedores de sistemas de alto riesgo deben cumplir los requisitos de los artículos 9 a 15: un sistema de gestión de riesgos durante todo el ciclo de vida; una gobernanza de los datos de entrenamiento, validación y prueba que garantice su pertinencia y representatividad y que examine los posibles sesgos; documentación técnica; registro automático de eventos que permita la trazabilidad; transparencia e instrucciones de uso para el responsable del despliegue; diseño que permita una supervisión humana efectiva; y un nivel adecuado de precisión, solidez y ciberseguridad, incluida la resistencia frente a intentos de manipular los datos de entrenamiento o las entradas del modelo. Deben además disponer de un sistema de gestión de la calidad, someter el sistema a evaluación de la conformidad, registrarlo en la base de datos de la Unión cuando proceda, mantener un seguimiento post-comercialización y notificar los incidentes graves. Para los productos sanitarios, la evaluación de la conformidad del RIA se integra en la que realiza el organismo notificado conforme al MDR.


Los responsables del despliegue —típicamente, los centros sanitarios— también tienen obligaciones (artículo 26): utilizar el sistema conforme a sus instrucciones, encomendar la supervisión humana a personas con la competencia, la formación y la autoridad necesarias, vigilar su funcionamiento, conservar los registros generados e informar al proveedor y a las autoridades de los riesgos e incidentes detectados. Los organismos de Derecho público y las entidades privadas que prestan servicios públicos deben realizar una evaluación de impacto en los derechos fundamentales antes de desplegar determinados sistemas del anexo III (artículo 27). Todos los proveedores y responsables del despliegue deben garantizar un nivel suficiente de alfabetización en IA de su personal (artículo 4).


El calendario tras el Ómnibus Digital sobre IA

El calendario de aplicación de las obligaciones de alto riesgo ha cambiado este año. El Reglamento (UE) 2026/1744, conocido como Ómnibus Digital sobre IA, se publicó en el Diario Oficial el 24 de julio de 2026 (Reglamento (UE) 2026/1744, 2026). Los requisitos de alto riesgo se aplican ahora desde el 2 de diciembre de 2027 a los sistemas del anexo III y desde el 2 de agosto de 2028 a los sistemas del anexo I, entre los que se incluyen los productos sanitarios que cumplen las condiciones del artículo 6.1. La Comisión había propuesto trasladar los productos sanitarios a la sección B del anexo I, lo que habría reducido sustancialmente la aplicación del RIA a estos productos, pero esa propuesta no prosperó en la negociación y los productos sanitarios siguen en la sección A. El Ómnibus añadió además dos nuevas prácticas prohibidas aplicables desde el 2 de diciembre de 2026.


El aplazamiento no es una moratoria general. Las prohibiciones del artículo 5 y la obligación de alfabetización están en vigor desde febrero de 2025, las obligaciones de transparencia desde agosto de 2026, y cualquier sistema de alto riesgo cuyo desarrollo se inicie ahora debe diseñarse conforme a los requisitos que serán exigibles cuando se despliegue.


Los asistentes conversacionales

Los asistentes conversacionales basados en modelos de lenguaje que se ofrecen como apoyo emocional merecen una mención particular. Si no declaran finalidad médica, no son productos sanitarios ni, por lo general, sistemas de alto riesgo, y su régimen se reduce a la transparencia y a las prohibiciones del artículo 5. Sin embargo, en la práctica pueden recibir confidencias sobre ideación suicida, pueden generar respuestas inadecuadas ante una crisis y pueden fomentar una dependencia emocional en personas vulnerables. Desde el punto de vista del cumplimiento, cualquier asistente de este tipo debería, como mínimo, identificarse inequívocamente como sistema automatizado, detectar los indicadores de riesgo y derivar a recursos de urgencia, y abstenerse de presentarse como sustituto de la atención profesional. Si su fabricante le atribuye efectos terapéuticos sobre un trastorno, pasa a ser un producto sanitario.


Requisitos de protección de datos personales


Principios y bases jurídicas

El Reglamento (UE) 2016/679 general de protección de datos (RGPD) se aplica a todas las aplicaciones que traten datos personales, sean o no productos sanitarios. En España se complementa con la Ley Orgánica 3/2018, de Protección de Datos Personales y garantía de los derechos digitales (LOPDGDD).


Los datos de salud son una categoría especial cuyo tratamiento está prohibido salvo que concurra una de las excepciones del artículo 9.2 del RGPD. Para una aplicación de uso directo por el consumidor, la base habitual es el consentimiento explícito del interesado. Para una aplicación integrada en la asistencia sanitaria, la base es la prestación de asistencia o tratamiento sanitario bajo la responsabilidad de un profesional sujeto al secreto profesional (artículo 9.2.h y 9.3). La elección no es formal: determina quién es responsable del tratamiento, con qué fines pueden usarse los datos y qué ocurre si el paciente retira su consentimiento. Son también datos de salud los inferidos o derivados, como el riesgo de recaída calculado a partir del patrón de sueño o de uso del teléfono.


El tratamiento debe respetar los principios del artículo 5: licitud, lealtad y transparencia; limitación de la finalidad; minimización de datos; exactitud; limitación del plazo de conservación; e integridad y confidencialidad. En salud mental, el principio de minimización tiene consecuencias concretas: una aplicación de relajación no necesita la geolocalización continua del usuario ni el acceso a sus contactos, y un programa de terapia no necesita compartir con terceros el hecho de que el usuario lo utiliza.


Transparencia y derechos de los usuarios

El usuario debe recibir antes del tratamiento una información clara y accesible sobre la identidad del responsable, los fines y la base jurídica, los destinatarios, las transferencias internacionales, el plazo de conservación y sus derechos (artículos 13 y 14). Tiene derecho de acceso, rectificación, supresión, limitación, portabilidad y oposición, y derecho a no ser objeto de decisiones basadas únicamente en el tratamiento automatizado que produzcan efectos jurídicos o le afecten significativamente, con garantías como la intervención humana (artículos 15 a 22). En España, los menores de catorce años no pueden consentir por sí mismos el tratamiento de sus datos (artículo 7 de la LOPDGDD).


Protección de datos desde el diseño y obligaciones de responsabilidad proactiva

El responsable debe aplicar medidas técnicas y organizativas para integrar la protección de datos desde el diseño y por defecto (artículo 25), mantener un registro de las actividades de tratamiento (artículo 30) y realizar una evaluación de impacto antes de un tratamiento que entrañe un alto riesgo (artículo 35). El tratamiento a gran escala de datos de salud, la elaboración de perfiles y el uso de nuevas tecnologías, que concurren en casi todas las aplicaciones de salud mental, hacen obligatoria esa evaluación. Debe designarse un delegado de protección de datos cuando la actividad principal consista en el tratamiento a gran escala de categorías especiales de datos (artículo 37), y la LOPDGDD incluye además expresamente entre las entidades obligadas a los centros sanitarios legalmente obligados al mantenimiento de las historias clínicas (artículo 34).


La disposición adicional decimoséptima de la LOPDGDD regula los tratamientos de datos de salud, incluida su reutilización con fines de investigación y las garantías de seudoanonimización exigibles, y el artículo 9.2 de esa ley exige que los tratamientos de datos de salud basados en el Derecho español estén amparados en una norma con rango de ley.


Rastreadores, kits de desarrollo y publicidad

Una de las principales fuentes de riesgo no está en el núcleo de la aplicación, sino en los componentes de terceros que incorpora: kits de desarrollo de publicidad, de analítica o de autenticación que transmiten a sus proveedores identificadores del dispositivo, eventos de uso o incluso contenidos. Huckvale et al. (2019) comprobaron que la mayoría de las aplicaciones para la depresión y la deshabituación tabáquica que analizaron transmitían datos a servicios de Facebook y Google, y que una parte relevante no lo declaraba en su política de privacidad. Iwaya et al. (2023) encontraron, en las aplicaciones de salud mental más descargadas, permisos innecesarios, implementaciones criptográficas inseguras y fugas de datos personales y credenciales en registros y peticiones web. El acceso a la información almacenada en el dispositivo del usuario y la instalación de estos rastreadores requieren, además, el consentimiento previo conforme al artículo 22.2 de la Ley 34/2002, de servicios de la sociedad de la información, salvo cuando sean estrictamente necesarios para prestar el servicio.


El caso de BetterHelp ilustra las consecuencias: la Comisión Federal de Comercio de Estados Unidos sancionó en 2023 a esta plataforma de terapia en línea por compartir con Facebook, Snapchat y otras empresas, con fines publicitarios, los correos electrónicos, las direcciones IP y las respuestas a cuestionarios de salud de sus usuarios pese a haber prometido no hacerlo; el acuerdo supuso 7,8 millones de dólares en reembolsos a unas 800.000 personas (Federal Trade Commission, 2024). En el marco europeo, una práctica equivalente constituiría un tratamiento de categorías especiales de datos sin base jurídica. La conclusión práctica es que una aplicación de salud mental no debería incorporar kits de desarrollo publicitarios y que cualquier analítica debe limitarse a datos agregados o seudoanonimizados, sin información clínica.


Una reforma en curso

La Comisión presentó en noviembre de 2025 una propuesta de Ómnibus Digital (Comisión Europea, 2025b) que modificaría, entre otras normas, el RGPD y las reglas sobre acceso al terminal del usuario. El Consejo fijó su posición en octubre de 2026, rechazando la modificación de la definición de dato personal que había propuesto la Comisión, y la negociación con el Parlamento Europeo no ha comenzado. Mientras no se adopte, el RGPD vigente es el único marco aplicable.


Seguridad de los servidores y de la infraestructura


Las fuentes de las obligaciones

La seguridad de los servidores que respaldan una aplicación no está regulada en una norma única, sino que resulta de la convergencia de varias. El artículo 32 del RGPD obliga a todo responsable y encargado a aplicar medidas apropiadas al riesgo, entre ellas la seudoanonimización y el cifrado, la capacidad de garantizar la confidencialidad, integridad, disponibilidad y resiliencia permanentes de los sistemas, la capacidad de restaurar el acceso a los datos tras un incidente y un proceso de verificación regular de la eficacia de las medidas. El anexo I del MDR, para los productos sanitarios, y el artículo 15 del RIA, para los sistemas de alto riesgo, exigen ciberseguridad conforme al estado de la técnica. El Reglamento de Ciber-resiliencia la exige para las aplicaciones que no son productos sanitarios. NIS2 la exige a los prestadores de asistencia sanitaria y a su cadena de suministro. Y el Esquema Nacional de Seguridad la concreta para el sector público español. Las medidas que se describen a continuación son el denominador común que se deriva de este conjunto.


Ubicación de los datos y transferencias internacionales

Contra una creencia extendida, el RGPD no exige que los datos se almacenen físicamente en la Unión Europea. Lo que regula son las transferencias internacionales (capítulo V): los datos pueden enviarse a un tercer país con decisión de adecuación de la Comisión o, en su defecto, con garantías adecuadas como las cláusulas contractuales tipo, que tras la sentencia del Tribunal de Justicia en el asunto C-311/18 (Schrems II) deben acompañarse de una evaluación del nivel de protección efectivo en el país de destino y, en su caso, de medidas complementarias como el cifrado con claves bajo control exclusivo del exportador. Debe tenerse en cuenta que el mero acceso remoto desde un tercer país, por ejemplo por parte del personal de soporte de un proveedor, constituye una transferencia.


Las transferencias a Estados Unidos, donde se encuentran los principales proveedores de nube, se basan hoy en el Marco de Privacidad de Datos UE-EE. UU. de 2023. El Tribunal General confirmó su validez el 3 de septiembre de 2025 en el asunto T-553/23, pero la sentencia está recurrida ante el Tribunal de Justicia en el asunto C-703/25 P, todavía pendiente. Los dos marcos anteriores, Safe Harbour y Privacy Shield, fueron anulados por el Tribunal de Justicia. Además, la legislación estadounidense permite a sus autoridades requerir datos a proveedores sometidos a su jurisdicción aunque los datos estén almacenados fuera de su territorio. Para datos de salud mental, la combinación de incertidumbre jurídica y sensibilidad de la información aconseja alojar los datos en el Espacio Económico Europeo, con proveedores que ofrezcan garantías contractuales y técnicas frente al acceso extraterritorial, y cifrar los datos con claves gestionadas por el responsable.


En el sector público español existe además una exigencia legal expresa. El artículo 46 bis de la Ley 40/2015, de Régimen Jurídico del Sector Público, introducido por el Real Decreto-ley 14/2019, obliga a que los sistemas de información y comunicaciones utilizados para la recogida, almacenamiento, procesamiento y gestión de determinadas categorías de datos —entre ellas, los datos de los usuarios del Sistema Nacional de Salud— y los tratamientos de datos personales correspondientes se ubiquen y presten dentro del territorio de la Unión Europea. Una aplicación desplegada por un servicio público de salud que almacene datos de sus pacientes en servidores fuera de la Unión incumpliría directamente esta disposición.


Medidas técnicas del lado del servidor

Las medidas que cabe exigir a la infraestructura que respalda una aplicación de salud mental pueden agruparse en los siguientes bloques, que coinciden en lo sustancial con los requisitos del Esquema Nacional de Seguridad en su categoría alta y con los controles de la norma ISO/IEC 27001.


  • Cifrado en tránsito mediante versiones actuales del protocolo TLS, con configuración robusta y, en la aplicación móvil, fijación de certificados para dificultar la interceptación.

  • Cifrado en reposo de las bases de datos, los ficheros y las copias de seguridad con algoritmos robustos, y gestión de claves mediante módulos de seguridad o servicios de gestión de claves, preferiblemente con claves controladas por el responsable del tratamiento y no por el proveedor de la nube.

  • Seudoanonimización y separación de los identificadores directos (nombre, teléfono, correo) de los datos clínicos, de modo que una brecha en un sistema no exponga ambos.

  • Minimización de los datos almacenados y plazos de conservación definidos, con supresión efectiva al término del plazo o a petición del usuario.

  • Control de acceso basado en el principio de mínimo privilegio, autenticación multifactor para todos los accesos administrativos y clínicos, y revisión periódica de los permisos.

  • Registro de la actividad, en especial de los accesos a datos clínicos, en registros protegidos frente a la manipulación y conservados durante un plazo suficiente, con revisión y alertas.

  • Segregación de entornos de desarrollo, pruebas y producción, sin datos reales de pacientes en los entornos no productivos.

  • Gestión de vulnerabilidades: inventario de componentes, incluida una lista de materiales de software, aplicación de parches en plazos definidos y pruebas de intrusión periódicas, tanto de la aplicación móvil como de las interfaces y servidores.

  • Protección de las interfaces de programación frente a abusos, con autenticación robusta, limitación de peticiones y validación de entradas.

  • Monitorización continua de la seguridad y capacidad de detección y respuesta ante incidentes.


Medidas en el dispositivo del usuario

La seguridad no termina en el servidor. Los datos almacenados en el teléfono deben cifrarse utilizando los mecanismos seguros del sistema operativo; la aplicación debe solicitar solo los permisos imprescindibles; no deben escribirse datos personales en los registros de depuración; y la sesión debe protegerse con un código o con autenticación biométrica. En salud mental hay requisitos adicionales que a menudo se olvidan: las notificaciones no deben mostrar contenido clínico en la pantalla de bloqueo, porque pueden revelar a terceros que el usuario sigue un tratamiento psiquiátrico; el icono y el nombre de la aplicación deberían poder ser discretos; y debe contemplarse el riesgo de dispositivos compartidos o de control coercitivo por parte de la pareja u otros convivientes. Los estándares de verificación de seguridad para aplicaciones móviles de OWASP ofrecen un catálogo de controles ampliamente aceptado para comprobar estos aspectos.


Proveedores de nube y cadena de suministro

La relación con los proveedores de infraestructura debe formalizarse en un contrato de encargo del tratamiento conforme al artículo 28 del RGPD, que fije el objeto, la duración, la naturaleza y la finalidad del tratamiento, obligue a seguir las instrucciones del responsable, imponga la confidencialidad, regule la subcontratación con autorización previa, prevea la asistencia en caso de incidentes y el derecho de auditoría, y determine la devolución o supresión de los datos al terminar el servicio. El responsable debe elegir proveedores que ofrezcan garantías suficientes; en la práctica, certificaciones como ISO/IEC 27001, ISO/IEC 27017 y 27018 para servicios en la nube y la certificación de conformidad con el Esquema Nacional de Seguridad. El modelo alemán ofrece un ejemplo de exigencia reforzada: las aplicaciones de salud digital financiadas por el seguro público deben acreditar desde 2025 la conformidad con la directriz técnica TR-03161 de la oficina federal de seguridad informática, que incluye requisitos específicos para los sistemas de servidor, y deben operar sobre servicios en la nube que dispongan de un informe de seguridad independiente conforme al catálogo C5 (Bundesamt für Sicherheit in der Informationstechnik [BSI], 2024).


La reversibilidad forma parte también de la seguridad. El Reglamento (UE) 2023/2854 de Datos regula el cambio entre proveedores de servicios de tratamiento de datos y limita los obstáculos a la portabilidad. Para un servicio de salud, la posibilidad de recuperar todos los datos clínicos en un formato utilizable si el proveedor de la aplicación cierra o rescinde el contrato es una garantía de continuidad asistencial.


Continuidad y copias de seguridad

Las aplicaciones que sustentan procesos clínicos —por ejemplo, la monitorización de pacientes con TMG o la recepción de alertas— deben definir objetivos de tiempo y punto de recuperación, mantener copias de seguridad cifradas, aisladas y verificadas periódicamente mediante pruebas de restauración, y disponer de un plan de continuidad que prevea qué ocurre con los pacientes si el sistema deja de funcionar. Una alerta de riesgo que no llega porque el servidor está caído debe tener un mecanismo alternativo y conocido por los profesionales.


Gestión y notificación de incidentes

Las normas aplicables imponen obligaciones de notificación con plazos distintos, que pueden concurrir sobre un mismo incidente. La Tabla 2 las resume. Un fabricante de una aplicación de salud mental debe tener un procedimiento único de gestión de incidentes que identifique, desde el primer momento, qué notificaciones proceden, a qué autoridad y en qué plazo.


Tabla 2

Obligaciones de notificación de incidentes que pueden concurrir

Norma

Qué se notifica

Plazo

Destinatario

RGPD (arts. 33 y 34)

Violación de la seguridad de los datos personales

Sin dilación indebida y, a ser posible, en 72 horas; a los afectados, sin dilación si hay alto riesgo

Agencia Española de Protección de Datos; personas afectadas

MDR (art. 87)

Incidente grave relacionado con un producto sanitario

Inmediatamente y no más tarde de 15 días; 2 días si hay amenaza grave para la salud pública; 10 días en caso de muerte o deterioro grave imprevisto

AEMPS

RIA (art. 73)

Incidente grave de un sistema de IA de alto riesgo

Inmediatamente y no más tarde de 15 días, con plazos más breves en los supuestos más graves

Autoridad de vigilancia del mercado

NIS2 (art. 23)

Incidente significativo

Alerta temprana en 24 horas, notificación en 72 horas, informe final en un mes

CSIRT o autoridad competente (en España, conforme al RDL 12/2018 mientras no se transponga)

Ciber-resiliencia (art. 14)

Vulnerabilidad activamente explotada o incidente grave en un producto con elementos digitales

Alerta temprana en 24 horas, notificación en 72 horas; informe final a los 14 días de disponer de una corrección (vulnerabilidad) o al mes (incidente)

CSIRT coordinador y ENISA, mediante la plataforma única de notificación

ENS (RD 311/2022)

Incidentes de seguridad en sistemas del sector público

Sin dilación, conforme a la guía nacional de notificación

CCN-CERT

Nota. AEMPS = Agencia Española de Medicamentos y Productos Sanitarios; ENISA = Agencia de la Unión Europea para la Ciberseguridad.


La gravedad de las consecuencias justifica este rigor. En Finlandia, el acceso indebido a la base de datos de un centro privado de psicoterapia expuso los registros de decenas de miles de pacientes, incluidas notas de sesiones, y el atacante extorsionó individualmente a los pacientes amenazando con publicarlas; el responsable fue condenado en 2024 a más de seis años de prisión y la empresa quebró (Associated Press, 2024). El caso demuestra que una brecha en datos de salud mental produce un daño clínico directo sobre personas vulnerables, y que la notificación a los afectados debe acompañarse de medidas de apoyo.


Certificaciones y normas técnicas de referencia

Ninguna certificación garantiza por sí sola la seguridad, pero permiten verificar de forma objetiva que el proveedor gestiona sus riesgos. Las más pertinentes son ISO/IEC 27001 (sistema de gestión de la seguridad de la información), ISO/IEC 27701 (gestión de la privacidad), ISO 27799 (seguridad de la información en el ámbito sanitario), ISO/IEC 27017 y 27018 (servicios en la nube), la certificación de conformidad con el Esquema Nacional de Seguridad, y, para los productos sanitarios, las normas de ciclo de vida y ciberseguridad citadas en el apartado correspondiente. La especificación técnica ISO/TS 82304-2 propone además una etiqueta de calidad y fiabilidad para aplicaciones de salud y bienestar que incluye criterios de privacidad y seguridad.


Marco de ciberseguridad


La Directiva NIS2

La Directiva (UE) 2022/2555 (NIS2) incluye la sanidad entre los sectores de alta criticidad. Los prestadores de asistencia sanitaria y los fabricantes de determinados productos sanitarios que superen los umbrales de tamaño son entidades esenciales o importantes, obligadas a adoptar medidas de gestión de riesgos (artículo 21): políticas de análisis de riesgos, gestión de incidentes, continuidad de la actividad y gestión de copias de seguridad, seguridad de la cadena de suministro, seguridad en la adquisición, el desarrollo y el mantenimiento de los sistemas, criptografía y cifrado, seguridad de los recursos humanos, control de acceso y autenticación multifactor. Los órganos de dirección responden personalmente de su aprobación y supervisión. Para un hospital que despliega una plataforma de monitorización, la seguridad del proveedor de la aplicación forma parte de su propia cadena de suministro y debe evaluarse y exigirse contractualmente.


España no ha transpuesto la Directiva, cuyo plazo venció el 17 de octubre de 2024. El anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad, aprobado por el Consejo de Ministros en enero de 2025, no llegó a remitirse a las Cortes; sigue aplicándose el Real Decreto-ley 12/2018, que transpuso la primera directiva, y la Comisión Europea decidió en julio de 2026 llevar a España ante el Tribunal de Justicia por este incumplimiento. La falta de transposición no exime a las entidades de adoptar las medidas, que constituyen el estado de la técnica exigible también por el RGPD.


El Reglamento de Ciberresiliencia

El Reglamento (UE) 2024/2847 de Ciberresiliencia establece requisitos horizontales para los productos con elementos digitales, incluido el software que se comercializa en la Unión y las soluciones de tratamiento remoto de datos necesarias para su funcionamiento. Los productos sanitarios regulados por el MDR están excluidos porque su ciberseguridad ya se rige por este, pero las aplicaciones de bienestar que no son productos sanitarios quedan, en principio, dentro de su ámbito. Desde el 11 de septiembre de 2026 sus fabricantes deben notificar las vulnerabilidades activamente explotadas y los incidentes graves; desde el 11 de diciembre de 2027 serán exigibles los requisitos esenciales del anexo I, entre ellos la seguridad desde el diseño y por defecto, la ausencia de vulnerabilidades explotables conocidas, la protección de la confidencialidad mediante cifrado, la minimización de datos, la gestión de vulnerabilidades con una lista de materiales de software y el suministro de actualizaciones de seguridad durante el periodo de soporte (Reglamento (UE) 2024/2847, 2024). El Reglamento de Ciberresiliencia cubre así, al menos en parte, la laguna de seguridad de las aplicaciones de bienestar, aunque no se ocupa de su validez clínica.


El Esquema Nacional de Seguridad

El Real Decreto 311/2022, por el que se regula el Esquema Nacional de Seguridad (ENS), es de obligado cumplimiento para todo el sector público y para las entidades privadas que le prestan servicios o soluciones, y obliga a que los pliegos de contratación incluyan los requisitos necesarios para garantizar la conformidad. Cuando un servicio público de salud contrata o despliega una aplicación, el proveedor y la infraestructura que la soporta deben ser conformes con el ENS en la categoría que resulte del análisis de riesgos, que para datos de salud mental de una población amplia debería ser la alta. El ENS exige, entre otras medidas, análisis y gestión de riesgos, control de accesos, registro de actividad, protección criptográfica, continuidad del servicio, gestión de incidentes con notificación al CCN-CERT y auditorías periódicas de conformidad. Es, por tanto, la respuesta más concreta del ordenamiento español a la pregunta por la seguridad de los servidores, aunque limitada al ámbito público.


El Espacio Europeo de Datos de Salud

El Reglamento (UE) 2025/327, del Espacio Europeo de Datos de Salud (EEDS), entró en vigor el 26 de marzo de 2025 y se aplicará de forma escalonada a partir de 2027 (Reglamento (UE) 2025/327, 2025). Para las aplicaciones de salud mental tiene tres implicaciones. La primera es que las aplicaciones de bienestar que declaren interoperabilidad con los sistemas de historia clínica electrónica deberán cumplir los requisitos esenciales y las especificaciones comunes del Reglamento, llevar una etiqueta que informe al usuario e inscribirse en una base de datos europea; la interoperabilidad no implicará la transferencia automática de datos, sino que la persona decidirá qué categorías de datos se incorporan a su historia (artículos 47 a 49). La segunda es que los productos sanitarios y los sistemas de IA de alto riesgo que declaren esa interoperabilidad deberán demostrar el cumplimiento de los componentes armonizados. La tercera es que el Reglamento reconoce al paciente el derecho a acceder a sus datos, a añadir información a su historia clínica y a restringir el acceso de los profesionales a determinados datos, y regula el uso secundario de los datos de salud, incluidos los procedentes de aplicaciones, para investigación e innovación mediante permisos de los organismos de acceso.


Para el TMG, el EEDS plantea la necesidad de explicar con especial cuidado al paciente qué datos de la aplicación pueden llegar a su historia clínica, quién podrá verlos y cómo puede restringir su acceso.


Responsabilidad por productos defectuosos y protección del consumidor


La nueva Directiva de responsabilidad por productos defectuosos

La Directiva (UE) 2024/2853 sobre responsabilidad por los daños causados por productos defectuosos sustituye a la de 1985 y considera expresamente producto al software, incluidos los sistemas de IA. Se aplica a los productos introducidos en el mercado o puestos en servicio después del 9 de diciembre de 2026, fecha que es también el límite para su transposición (Directiva (UE) 2024/2853, 2024). Sus consecuencias para las aplicaciones de salud mental son notables. El incumplimiento de los requisitos de ciberseguridad o la falta de actualizaciones de seguridad pueden hacer que el producto se considere defectuoso; el incumplimiento de los requisitos obligatorios de seguridad del producto da lugar a una presunción de defectuosidad; la responsabilidad no puede excluirse por contrato; y entre los daños indemnizables se incluyen los daños a la salud psicológica médicamente reconocidos y la pérdida o corrupción de datos que no se usen con fines exclusivamente profesionales. Un fabricante que deja de actualizar su aplicación o que no corrige una vulnerabilidad conocida asume, por tanto, un riesgo de responsabilidad objetiva.


Publicidad, alegaciones de salud y prácticas comerciales

Las aplicaciones de bienestar que atribuyen a su uso beneficios sobre la salud mental quedan sometidas a las normas sobre publicidad sanitaria y prácticas comerciales. En España, el Real Decreto 1907/1996 prohíbe la publicidad de productos, actividades o servicios con pretendida finalidad sanitaria que, entre otros supuestos, se presenten como de utilidad terapéutica para el tratamiento de enfermedades o atribuyan efectos no probados. A ello se suman la normativa sobre prácticas comerciales desleales, que prohíbe las alegaciones engañosas y los diseños que manipulan la voluntad del consumidor, y la de defensa de los consumidores, aplicable a las suscripciones y compras dentro de la aplicación. Larsen et al. (2019) mostraron que las aplicaciones de salud mental recurren con frecuencia a un lenguaje científico en su descripción comercial, pero que muy pocas aportan evidencia directa sobre su propia eficacia. Una aplicación que se publicita como eficaz para tratar la depresión, sin ser producto sanitario, incurre a la vez en un problema de cualificación con arreglo al MDR y en un problema de publicidad.


Las tiendas de aplicaciones como intermediarios

El Reglamento (UE) 2022/2065 de Servicios Digitales impone a las plataformas en línea que permiten a los consumidores celebrar contratos a distancia con comerciantes la obligación de obtener y verificar información sobre estos, y establece mecanismos de notificación y acción frente a contenidos ilícitos. Estas obligaciones mejoran la trazabilidad de los desarrolladores, pero no convierten a las tiendas en garantes de la conformidad de las aplicaciones.


Requisitos en el uso asistencial


El profesional que recomienda o prescribe

La recomendación de una aplicación a un paciente forma parte del acto clínico y se rige por la lex artis. El profesional no responde de los defectos del producto, pero sí de la decisión de recomendarlo. Ello implica, como mínimo, conocer el estatus de la herramienta —producto sanitario o aplicación de bienestar—, utilizarla dentro de su finalidad prevista, tener una base razonable para considerar que no causará daño, informar al paciente de sus limitaciones y de los riesgos para su privacidad, registrar la indicación en la historia clínica y prever su seguimiento. Recomendar una aplicación de bienestar para tratar un trastorno, es decir, para un uso que su propio fabricante excluye, traslada al profesional una parte de la responsabilidad que el fabricante ha eludido.


La Ley 41/2002, básica reguladora de la autonomía del paciente, consagra el derecho a la confidencialidad de los datos de salud, regula la historia clínica y su custodia, y exige el consentimiento informado, con el alcance que corresponda a la intervención. Cuando la aplicación transmite información al equipo asistencial, esa información pasa a formar parte del proceso asistencial y debe integrarse en la historia clínica con las mismas garantías que cualquier otra.


Las organizaciones sanitarias que despliegan aplicaciones

Un servicio de salud que incorpora una aplicación a su cartera debe, además de lo anterior, realizar la evaluación de impacto en protección de datos, formalizar los contratos de encargo, exigir la conformidad con el ENS y la ubicación de los datos en la Unión, cumplir las obligaciones de responsable del despliegue del RIA cuando la herramienta sea un sistema de IA de alto riesgo, integrar la herramienta en la historia clínica electrónica para evitar sistemas paralelos, formar a los profesionales y definir los circuitos asistenciales que garanticen que las alertas se atienden. La experiencia acumulada muestra que muchas intervenciones con evidencia de eficacia no llegan a implantarse precisamente por no resolver la integración informática y las dudas sobre la seguridad de los datos, lo que subraya la necesidad de abordar estos requisitos desde el diseño de cualquier proyecto.


Requisitos específicos en el trastorno mental grave

Las personas con esquizofrenia, trastorno bipolar, depresión grave o riesgo suicida elevado son, por un lado, quienes más podrían beneficiarse de la monitorización continua y de las herramientas predictivas, y, por otro, quienes más expuestas están a sus riesgos. Además de los requisitos generales, el uso de aplicaciones en esta población exige atender a los siguientes aspectos.


  • Capacidad y consentimiento. La capacidad para consentir debe valorarse de forma explícita, especialmente para la monitorización pasiva y la geolocalización. El consentimiento debe poder revocarse con facilidad, y deben preverse los apoyos necesarios para que la persona tome sus propias decisiones, en coherencia con el modelo de apoyos de la Ley 8/2021.


  • Proporcionalidad de la monitorización. Recoger de forma continua la ubicación, el uso del teléfono o la actividad social de una persona es una intervención intensa en su intimidad. Debe justificarse clínicamente, limitarse a los datos necesarios y revisarse periódicamente.


  • Contenido delirante y confianza terapéutica. En pacientes con ideas de perjuicio, vigilancia o control, la propuesta de un sistema que registra sus movimientos requiere una valoración clínica individual y una explicación cuidadosa.


  • Protocolos de crisis. Las aplicaciones que traten contenidos relacionados con el suicidio o que puedan detectar un empeoramiento deben disponer de protocolos de seguridad clínica, con derivación inmediata a recursos de urgencia, y no limitarse a mostrar un número de teléfono.


  • Circuito asistencial de las alertas. Un sistema de alertas solo es seguro si existe un circuito que garantice que alguien las recibe y actúa en un plazo razonable, incluso fuera del horario laboral o si el sistema falla. Una alerta que nadie atiende genera una falsa expectativa de vigilancia en el paciente y en su familia y puede trasladar responsabilidad al centro.


  • Explicabilidad y supervisión humana. Los modelos predictivos deben ofrecer al clínico información sobre las variables que motivan cada alerta, de modo que pueda validarla o descartarla, en línea con el artículo 14 del RIA. Ninguna decisión que afecte significativamente al paciente debe basarse únicamente en el resultado de un algoritmo.


  • Sesgos y no discriminación. Los modelos entrenados con datos de historias clínicas pueden reproducir desigualdades en el acceso a la atención. El RIA obliga a examinar los posibles sesgos de los datos de entrenamiento, y su relevancia es máxima cuando el resultado condiciona la intensidad de la atención que recibe una persona.


  • Prohibición de la explotación de vulnerabilidades. Las técnicas de persuasión, gamificación o retención deben diseñarse con prudencia. El artículo 5 del RIA prohíbe los sistemas que explotan vulnerabilidades derivadas de la discapacidad para alterar el comportamiento de forma perjudicial, y la normativa de consumo prohíbe los diseños manipuladores.


Situación del desarrollo normativo en España

En noviembre de 2026 el desarrollo español de la normativa europea presenta lagunas que afectan directamente a las aplicaciones de salud mental. La Directiva NIS2 sigue sin transponerse, como se ha indicado. El Proyecto de Ley Orgánica para el buen uso y la gobernanza de la inteligencia artificial, que organizaba el sistema de autoridades encabezado por la Agencia Española de Supervisión de Inteligencia Artificial (AESIA) y el régimen sancionador, decayó con la disolución de las Cortes Generales por el Real Decreto 806/2026, de 5 de octubre, y deberá reiniciarse en la nueva legislatura. La transposición de la nueva Directiva de responsabilidad por productos defectuosos vence el 9 de diciembre de 2026. Y no existe un procedimiento nacional de evaluación, prescripción y financiación de terapias digitales.


Los reglamentos europeos —MDR, RIA, RGPD, Ciberresiliencia y EEDS— son directamente aplicables y no dependen de la legislación nacional para ser exigibles. Pero sin normas internas que concreten autoridades, procedimientos y sanciones, su eficacia práctica se resiente, y la carga de verificación recae en mayor medida sobre los propios profesionales, las organizaciones sanitarias y las sociedades científicas.


En este contexto, los catálogos de aplicaciones elaborados por sociedades científicas, son una ayuda valiosa para orientar la elección en términos de validación científica, calidad, usabilidad y pertinencia clínica. Sería recomendable que incorporasen de forma sistemática información sobre el estatus regulatorio, la ubicación de los servidores, la compartición de datos con terceros y las certificaciones de seguridad de cada aplicación, en la línea del modelo jerárquico de la Asociación Americana de Psiquiatría, que sitúa la privacidad y la seguridad en la base de la evaluación y la detiene si una aplicación no supera ese nivel (American Psychiatric Association, s. f.; Lagan et al., 2020; Torous et al., 2018).


Matriz de verificación

La Tabla 3 recoge una lista de comprobaciones mínimas, ordenadas de forma jerárquica, para evaluar una aplicación antes de recomendarla, prescribirla o contratarla. Las primeras filas tienen carácter eliminatorio: si una aplicación no las supera, no debería utilizarse con pacientes, con independencia de su calidad o de su evidencia de eficacia.


Tabla 3

Matriz jerárquica de verificación de una aplicación de salud mental

Nivel

Comprobación

Dónde verificarla

1. Identidad (eliminatorio)

¿El fabricante es identificable, con domicilio en la UE o representante autorizado en ella, y con un contacto operativo?

Ficha de la tienda, aviso legal, web del fabricante

2. Estatus regulatorio (eliminatorio)

¿Declara finalidad médica? Si es así, ¿tiene marcado CE como producto sanitario, en qué clase y con qué organismo notificado? ¿El uso previsto coincide con el que se le va a dar?

Instrucciones de uso, declaración UE de conformidad, EUDAMED

3. Privacidad (eliminatorio)

¿Hay una política de privacidad clara en castellano, accesible antes del registro? ¿Identifica la base jurídica, los destinatarios y los plazos? ¿Incorpora kits de publicidad o comparte datos con terceros? ¿Permite borrar los datos?

Política de privacidad; información de seguridad de datos de la tienda; análisis técnico si se va a contratar

4. Servidores y transferencias (eliminatorio)

¿Dónde se alojan los datos? ¿Hay transferencias o accesos desde fuera del EEE y con qué garantías? ¿Cifra en tránsito y en reposo? ¿Quién controla las claves?

Política de privacidad, contrato de encargo, documentación técnica

5. Seguridad

¿Dispone de certificaciones (ISO/IEC 27001, ENS)? ¿Realiza pruebas de intrusión y aplica parches? ¿Tiene procedimiento de notificación de incidentes y de vulnerabilidades?

Certificados, informes de auditoría, política de divulgación de vulnerabilidades

6. Inteligencia artificial

¿Usa IA? ¿Lo informa? ¿Es de alto riesgo? ¿Existe supervisión humana y explicación de sus resultados? ¿Se han evaluado sus sesgos?

Información al usuario, documentación técnica, instrucciones de uso

7. Seguridad clínica

¿Qué hace ante una crisis o ante la detección de ideación suicida? ¿Deriva a recursos de urgencia? ¿Hay circuito para atender las alertas?

Prueba directa; protocolo del servicio

8. Evidencia y calidad

¿Hay estudios propios publicados? ¿Qué valoración tiene en evaluaciones independientes?

Bibliografía; catálogos de sociedades científicas

9. Ajuste al paciente

¿Puede este paciente usarla y consentir de forma informada? ¿Qué objetivo clínico concreto se persigue y cuándo se revisará? ¿Se ha registrado en la historia clínica?

Valoración clínica; historia clínica

10. Despliegue institucional

Evaluación de impacto, contrato de encargo, conformidad con el ENS, datos en la UE, integración con la historia clínica, plan de continuidad y de reversibilidad

Expediente de contratación; delegado de protección de datos

Nota. Elaboración propia a partir de la normativa citada y del modelo de evaluación de la American Psychiatric Association (s. f.). EEE = Espacio Económico Europeo.


Conclusiones

El cumplimiento normativo de una aplicación de salud mental no puede inferirse de su disponibilidad en una tienda, de su popularidad ni siquiera de la existencia de estudios favorables. Depende de un conjunto de requisitos que se superponen y que deben verificarse de forma específica.


La primera cuestión es siempre la finalidad prevista. Si la aplicación se utiliza para diagnosticar, tratar o vigilar un trastorno, debe ser un producto sanitario con marcado CE y cumplir el MDR, incluidos sus requisitos de seguridad informática, que abarcan los servidores de los que depende. Si incorpora inteligencia artificial, se añaden las prohibiciones y las obligaciones de transparencia del RIA, ya vigentes, y, cuando se trate de un sistema de alto riesgo, los requisitos que serán exigibles desde diciembre de 2027 o agosto de 2028 según el caso. Si no es producto sanitario, el Reglamento de Ciberresiliencia empieza a cubrir su seguridad, pero nadie evalúa su validez clínica.


En todos los casos el RGPD es el eje del cumplimiento. Los datos de salud mental exigen una base jurídica específica, una evaluación de impacto, medidas de seguridad conformes al estado de la técnica y un control riguroso de las transferencias internacionales. La ubicación de los servidores es un factor de riesgo jurídico y, en el sector público, un requisito legal expreso: los datos de los usuarios del Sistema Nacional de Salud deben tratarse dentro de la Unión Europea. Las medidas técnicas exigibles —cifrado, seudoanonimización, control de acceso, registro, gestión de vulnerabilidades, continuidad y notificación de incidentes— están bien definidas en el Esquema Nacional de Seguridad y en las normas internacionales, y deben exigirse contractualmente a los proveedores.


La nueva Directiva de responsabilidad por productos defectuosos, aplicable a partir del 9 de diciembre de 2026, refuerza todo lo anterior al convertir los fallos de ciberseguridad y la falta de actualizaciones en defectos del producto.


En España, la falta de transposición de NIS2, el decaimiento de la ley de gobernanza de la IA y la ausencia de una vía de evaluación y financiación de terapias digitales trasladan a los profesionales y a las organizaciones una carga de verificación que debería asumir el sistema. Mientras esa situación persista, la regla práctica para el clínico es clara: una aplicación es una intervención y debe indicarse, explicarse, documentarse y supervisarse como tal; y cuando se trata de un paciente con un trastorno mental grave, la primera pregunta no es si la aplicación funciona, sino si es segura y lícita.


Referencias



Este post ha sido redactado con ayuda de Inteligencia Artificial

Suscripción al Blog

bottom of page