Del software autorizado al sistema integrado: elverdadero desafío de la salud digital y de la IA en salud

Cuando se habla de salud digital, la primera imagen que el lector de a pie puede asociar con la existencia de un reloj inteligente, una aplicación móvil o un algoritmo capaz de analizar una imagen médica. Sin embargo, esa representación, si bien es real, resulta insuficiente. La salud digital no es una tecnología determinada ni constituye, por sí misma, una categoría jurídica homogénea. Es un campo de actividad —una vertical— que agrupa soluciones muy diferentes: telemedicina, historias clínicas electrónicas, dispositivos conectados, plataformas de seguimiento remoto, software médico, sistemas de apoyo a la decisión e inteligencia artificial aplicada a la atención sanitaria.
Estas tecnologías comparten un ámbito de aplicación, pero no necesariamente la misma finalidad, el mismo nivel de riesgo ni idéntico encuadre regulatorio. Una aplicación que registra pasos, horas de sueño o hábitos de hidratación no ocupa el mismo lugar que un sistema que detecta una fibrilación auricular, identifica una lesión en una mamografía o recomienda priorizar la atención de un paciente con signos de sepsis. La diferencia jurídica comienza con la finalidad prevista por el fabricante; la diferencia clínica, con la función que efectivamente cumple; y la diferencia ética, con las consecuencias integrales que puede producir sobre las personas.
Esta distinción inicial es necesaria, pero ya no alcanza. En la práctica asistencial, las instituciones no incorporan productos digitales aislados. Integran soluciones dentro de sistemas complejos en los que conviven componentes regulados como productos médicos, programas de uso general, bases de datos, interfaces, servicios en la nube, redes de comunicación, tableros de visualización y procedimientos organizacionales. Algunos de esos componentes pueden carecer de finalidad médica individualmente considerada y, aún así, participar de una cadena de decisiones clínicas.
Por eso, el desafío contemporáneo no concluye únicamente en determinar cuándo un software es un dispositivo médico. Consiste también en comprender qué ocurre cuando ese software se integra en una institución, modifica un proceso asistencial y comienza a intervenir —directa o indirectamente— en el cuidado.
La comunicación de ANMAT: una aclaración relevante, no una nueva norma
El 10 de septiembre de 2026, la Administración Nacional de Medicamentos, Alimentos y Tecnología Médica (de Argentina) difundió una comunicación dirigida al sector regulado sobre el encuadre del Software como Dispositivo Médico o Software as a Medical Device (SaMD).
Aunque el título utilizado por el organismo alude a una “actualización” de criterios, es importante efectuar una precisión jurídica: la comunicación no creó una nueva categoría ni modificó por sí misma el régimen vigente.
El documento explicó el alcance práctico de definiciones y reglas de clasificación que ya habían sido incorporadas mediante la Disposición ANMAT 64/2025, relacionada con la internalización de la Resolución GMC MERCOSUR 25/2021. Su novedad es, principalmente, explicativa y operativa: ayuda a reconocer cuándo una aplicación deja de limitarse al bienestar general y
comienza a desempeñar una función médica sometida al control sanitario.
ANMAT señaló que el software destinado por su fabricante al diagnóstico, la prevención, el tratamiento o la mitigación de una enfermedad o afección específica, y que cumple su función sin formar parte del hardware de un producto médico, adquiere la categoría de SaMD. La comunicación menciona, entre otros ejemplos, aplicaciones de electrocardiograma para
detectar fibrilación auricular, notificaciones de ritmo cardíaco irregular, sistemas de detección de apnea del sueño y mecanismos automatizados de alerta ante un paro cardíaco o una pérdida de pulso.
Los ejemplos son especialmente útiles porque muestran que el soporte material no define la naturaleza de la función. Un reloj inteligente puede reunir en un mismo dispositivo un contador de pasos, que en principio se vincula con el bienestar, y una función de electrocardiograma destinada a detectar una alteración cardíaca. El reloj no es jurídicamente una unidad indivisible: sus distintas funciones deben examinarse atendiendo a su finalidad, funcionamiento, evidencia y riesgo.
La comunicación de ANMAT fortalece, por lo tanto, la primera pregunta que debe formularse frente a una solución digital: ¿qué hace y para qué se ofrece? Sin embargo, el problema institucional comienza inmediatamente después: ¿qué sucede cuando esa función se conecta con datos, personas y procedimientos que no formaron parte de su evaluación original?
La autorización sanitaria no agota la seguridad
La regulación de productos médicos se ha construido tradicionalmente alrededor de un objeto identificable: un fabricante define una finalidad prevista, aporta evidencia, gestiona los riesgos y solicita la autorización correspondiente. Este modelo continúa siendo necesario, pero la digitalización introduce una dificultad adicional. El resultado que recibe el profesional no depende exclusivamente del algoritmo, sino también de la calidad de los datos de entrada, las interfaces utilizadas, las reglas de configuración, la forma en que se presenta una alerta y la capacidad de la organización para actuar frente a ella.

Puede pensarse en un sistema para detectar tempranamente la sepsis. El algoritmo analiza datos de la historia clínica electrónica (HCE) y genera una alerta cuando identifica un patrón compatible con un deterioro grave. El producto puede haber sido validado y autorizado. Pero, para que produzca un beneficio real, deben funcionar correctamente varias etapas:
▪ la temperatura, presión arterial y frecuencia cardíaca deben registrarse a tiempo;
▪ los resultados de laboratorio deben asociarse con el paciente correcto;
▪ la interfaz debe transmitir los datos sin omisiones ni alteraciones;
▪ el sistema debe mostrar la alerta de manera comprensible;
▪ el aviso debe llegar a la persona indicada;
▪ el profesional debe disponer de tiempo, información y autoridad para evaluar el
resultado;
▪ la institución debe contar con un procedimiento para responder.
Si falla una sola de esas condiciones, el algoritmo puede operar según sus especificaciones y, sin embargo, el sistema asistencial puede fracasar. Una carga tardía, una interoperabilidad defectuosa o una notificación enviada a un dispositivo sin supervisión pueden convertir una herramienta técnicamente correcta en una intervención clínicamente insegura.
Este ejemplo permite formular una distinción esencial: la clasificación regulatoria corresponde al producto; la seguridad clínica pertenece al sistema integrado.

No todos los elementos de esa cadena son necesariamente dispositivos médicos. El servicio de mensajería, la red de comunicación, la nube, el software de integración o el tablero de visualización pueden ser tecnologías de propósito general. Pero la ausencia de finalidad médica propia no significa ausencia de relevancia sanitaria. Cuando un componente general se
incorpora a un proceso del cual dependen decisiones clínicas, su funcionamiento adquiere importancia para la seguridad del paciente.
Aquí aparece uno de los puntos menos desarrollados por los enfoques regulatorios centrados exclusivamente en el producto: los riesgos pueden surgir no solo dentro de cada componente, sino también entre los componentes.