No empecé con una estrategia de IA para la sanidad.
Empecé con una incomodidad.
La gente va a pegar notas clínicas, resultados de laboratorio, resúmenes de médicos, historias de pacientes, exportaciones de formularios, cartas de aseguradoras y capturas de pantalla en herramientas, porque las herramientas son útiles.
Algunas de esas herramientas usan IA.
Otras son SaaS corrientes.
Otras son paneles de control, sistemas de tickets, productos de analítica, aplicaciones de transcripción, aplicaciones de notas, CRM, formularios de admisión o conversores de archivos.
Esa parte ya está decidida.
La pregunta es qué ocurre antes de la subida.
¿Qué se elimina?
¿Qué se queda en local?
¿Qué llega al servicio?
¿Quién lo almacena?
¿Quién puede revenderlo?
¿Quién puede cruzarlo después con otra cosa?
¿Quién puede demostrar lo que pasó?
La primera versión era pequeña
El repositorio público era pequeño.
Una herramienta local. Una nota clínica. Una pregunta básica: ¿puedo eliminar la información sanitaria sensible antes de que el texto salga del equipo?
No era una empresa.
No era un producto médico.
No era una garantía de cumplimiento.
Era una negativa a aceptar el comportamiento por defecto: copiar el texto en bruto, pegarlo en un sistema en la nube y confiar en que la política de privacidad sea suficiente.
No me gusta reducirlo a una envoltura técnica alrededor de otra herramienta.
Técnicamente, usaba NLM Scrubber.
Pero lo importante no era la fontanería del software.
Lo importante era la pregunta que había detrás.
¿Podría una persona corriente limpiar una nota de salud en local antes de enviar a otro sitio la parte útil?
¿Podría el sistema empezar con menos datos, no con más?
La idea más grande detrás del repositorio
El repositorio fue el primer artefacto público de una idea mayor.
Los datos de salud no son iguales en todas partes.
Los formularios son distintos.
Los identificadores son distintos.
Las fechas son distintas.
Los idiomas son distintos.
El contexto jurídico es distinto.
Nací en Bélgica. Tengo raíces marroquíes. Llevo años viviendo en España. Me comunico mucho con personas y proyectos vinculados a Estados Unidos.
Así que la pregunta no me parecía abstracta.
Bélgica, Marruecos, España, la Unión Europea, Estados Unidos.
Formularios distintos.
Supuestos distintos.
Lenguaje de privacidad distinto.
Presión jurídica distinta.
La versión imposible sería un anonimizador global para 200 países.
Eso no es lo que construí.
La versión útil era más pequeña: empezar por los contextos más relevantes, aprender de las herramientas existentes, adaptar el planteamiento a identificadores reales y a flujos de trabajo reales, y mantener el procesamiento en local siempre que sea posible.
Esa es la historia detrás del prototipo.
No un motor global de cumplimiento terminado.
Un primer artefacto para una pregunta más difícil.
Por qué esto no es paranoia
El problema no es que todas las empresas vendan en secreto la nota de tu hospital.
Eso es demasiado fácil de decir y demasiado débil para defenderlo.
El problema es que los datos se mueven.
Se registran.
Se conservan.
Se replican en copias de seguridad.
Se usan para mejorar el producto.
Se comparten con encargados del tratamiento.
Se combinan con datos de navegación, ubicación, compras, dispositivo y cuenta.
A veces se venden.
A veces sufren una brecha de seguridad.
A veces se infieren a partir de datos que, al principio, no parecían médicos.
La FTC ha advertido de que la información de salud es más amplia que los tratamientos y los diagnósticos: los datos de ubicación, navegación y compras también pueden revelar información de salud.
Eso importa porque una persona no queda expuesta solo por lo que escribió en un formulario médico.
Una persona queda expuesta por las conexiones.
Una compra en una farmacia.
Una visita a una clínica.
Una búsqueda sobre embarazo.
Una alergia.
Un medicamento.
Una ausencia del trabajo.
Un ticket de soporte.
Una foto.
Un vídeo.
Un evento del calendario.
Un solo dato puede parecer inofensivo.
El patrón no es inofensivo.
Lo que se puede usar en tu contra
Los datos de salud pueden convertirse en una palanca de presión.
No siempre.
No de forma automática.
Pero lo bastante como para que lo normal sea la contención.
Una alergia no es solo un dato médico.
En manos equivocadas, es una vulnerabilidad.
Un medicamento puede revelar una afección.
Una afección puede influir en cómo alguien juzga tu fiabilidad, tu nivel de riesgo, tu capacidad para trabajar, tu perfil ante las aseguradoras o tu credibilidad.
Un rastro de ubicación puede revelar qué clínica visitó alguien.
Una compra relacionada con el embarazo puede revelar algo antes de que la persona se lo haya contado a nadie.
Una nota de salud mental puede convertirse en un foco de estigma.
Una afección genética o crónica puede convertirse en una señal para elaborar perfiles.
Un conjunto de datos que llega a un mercado criminal puede servir para suplantar identidades, hacer phishing, cometer fraude con préstamos, apoderarse de cuentas o aplicar ingeniería social.
Esto no es el argumento de una película.
Es la consecuencia práctica de regalar demasiado contexto porque un servicio resultaba cómodo.
El servicio puede ser útil.
La comodidad puede ser real.
El informe puede ser bueno.
El flujo de trabajo puede ahorrar tiempo.
Eso sigue sin significar que los datos en bruto tuvieran que salir.
La perspectiva de los seguros, el empleo y el sector público
El riesgo futuro no es solo la publicidad.
Es la puntuación.
Puntuación en los seguros.
Filtrado en procesos de contratación.
Elegibilidad en el sector público.
Controles antifraude.
Comprobaciones de antecedentes.
Decisiones de crédito y préstamo.
Cuestiones de fronteras e inmigración.
Pruebas en disputas.
Credibilidad jurídica.
Cuando hay datos suficientes, los sistemas pueden contrastar la historia que cuentas con la que cuentan tus datos.
Eso puede ser útil cuando detecta un fraude.
También puede ser injusto cuando los datos están incompletos, son antiguos, son inferidos, están sesgados, se compraron a un intermediario de datos o se sacaron de contexto.
Puede que la persona juzgada nunca vea el perfil completo.
Puede que nunca sepa qué dato fue el que importó.
Puede que nunca sepa qué empresa lo tenía.
Por eso la minimización de los datos de salud no es solo una preferencia técnica.
Es una cuestión de poder.
Lo que dejó al descubierto el prototipo
Anonimizar no es solo quitar un nombre.
Una nota clínica puede identificar a una persona a través de fechas, sucesos poco comunes, lugares, cronologías, datos familiares, números de teléfono, documentos de identidad o combinaciones de detalles que por separado parecen inofensivos.
Si quitas el nombre y dejas la fecha de ingreso, la fecha de alta, el hospital y el número de teléfono, la nota todavía puede remitir a una persona.
Si quitas demasiado, la nota puede dejar de ser útil.
Si cambias mal una fecha, la cronología clínica puede volverse engañosa.
Ahí es donde el trabajo se vuelve serio.
No dramático.
Serio.
Los casos límite aburridos son el sistema de privacidad.
Por qué importan las fechas
Las fechas parecen pequeñas hasta que las tratas como evidencia.
Una fecha de nacimiento puede identificar a alguien.
La fecha de una operación puede identificar a alguien.
El intervalo entre un ingreso y un alta puede ser relevante desde el punto de vista clínico.
Si un sistema desplaza las fechas 0 días, la privacidad no ha mejorado.
Si cambia `03/15/22` a otro formato sin avisar, la forma del texto ha cambiado.
Si conserva el año en un sitio y desplaza el mes en otro, un intervalo puede volverse absurdo al cruzar el cambio de año.
No son problemas glamurosos.
Son justo el tipo de problemas que deciden si se puede confiar en una capa de privacidad.
Encontrar OpenMed
Después de construir el prototipo, encontré OpenMed.
OpenMed es un proyecto de código abierto del ámbito sanitario, de mayor tamaño, que trabaja en el procesamiento de texto clínico con prioridad local, la detección de datos personales (PII), la desidentificación y la extracción de entidades médicas.
Estaba trabajando en el mismo problema de privacidad a una escala más profunda.
Lo inmaduro habría sido fingir que mi pequeño prototipo era la respuesta completa.
Lo maduro fue contribuir al proyecto que ya iba más a fondo.
Y eso hice.
No construí OpenMed.
No soy propietario de OpenMed.
Aporté una pequeña parte a la privacidad y la fiabilidad en torno a la desidentificación.
Otros colaboradores han hecho más.
Eso importa.
Esta no es una historia para presumir.
Es una historia de colaboración.
Primero construí un pequeño prototipo independiente. Después encontré un proyecto de código abierto más grande que trabajaba en el mismo problema y empecé a contribuir allí donde el trabajo podía importar más.
Por qué no enumero aquí todas las contribuciones
El rastro público existe.
GitHub puede mostrarlo.
Pero la lección no es “mira mis pull requests”.
La lección es que el trabajo de privacidad en la sanidad se vuelve real en los detalles aburridos: fechas, formatos, reproducibilidad, pruebas, valores por defecto y revisión.
Esa es la parte que me importa.
No ser propietario del proyecto más grande.
No fingir que el primer prototipo lo resolvía todo.
Sumarme al ecosistema más sólido cuando lo encontré.
La regulación avanza hacia la misma pregunta
La dirección jurídica no es idéntica en todas las regiones, pero la presión se ve con facilidad.
En Europa, el artículo 9 del RGPD trata los datos relativos a la salud como datos de categoría especial.
El Reglamento Europeo de IA (AI Act) usa un marco basado en el riesgo, que incluye categorías de alto riesgo en las que los sistemas pueden afectar a la salud, a la seguridad o a los derechos fundamentales.
Estados Unidos no tiene un equivalente federal del RGPD para todos los datos relacionados con la salud.
Eso es parte del problema.
Existen algunas protecciones en contextos concretos.
Parte de la presión llega por las leyes estatales, la aplicación de la normativa y las normas sectoriales.
Colorado SB26-189 plantea la tecnología de toma de decisiones automatizada en torno a las decisiones con consecuencias, incluidos los servicios de atención sanitaria, con obligaciones para desarrolladores y para quienes la despliegan a partir del 1 de enero de 2027.
El sistema DROP de California muestra la dirección que se sigue con los intermediarios de datos: los residentes pueden presentar solicitudes de supresión y los intermediarios de datos deben empezar a tramitarlas a partir del 1 de agosto de 2026.
La herramienta de la FTC sobre aplicaciones móviles de salud y la guía de la FTC sobre información de salud apuntan a la misma pregunta práctica: qué información de salud se recoge, cómo se usa, quién la recibe, cuánto tiempo se conserva y si el consentimiento fue real.
Nada de esto significa que una demo cumpla la normativa por eliminar unos cuantos identificadores.
Esa es justo la trampa.
El cumplimiento no es una pegatina que se le pone a un prototipo.
La capa útil está antes del teatro del cumplimiento: recoger menos, eliminar más, mantener el procesamiento en local siempre que se pueda, revisar los resultados a mano y conservar evidencia de lo ocurrido.
La capa que falta
En la mayoría de los intercambios de datos falta una capa.
Trazabilidad.
No solo una política de privacidad.
No solo una casilla.
Una forma de saber por dónde viajaron los datos sensibles, quién los tocó, qué se eliminó, qué se conservó y qué uso posterior se permitió.
Llámalo libro de registro, recibo, pista de auditoría, contrato o algo más inteligente.
El nombre importa menos que la función.
Ahora mismo, la mayoría de la gente no tiene eso.
Suben.
Confían.
Se olvidan.
Los datos no se olvidan.
Eso es otro artículo.
Pero es la razón por la que este pequeño prototipo me importó.
Qué deberían hacer los equipos a continuación
Los siguientes pasos prácticos no son dramáticos.
Son aburridos.
Por eso importan.
No pegues texto clínico en bruto en las herramientas por defecto.
No subas formularios de salud, resultados de laboratorio ni capturas de pantalla a herramientas SaaS si no se entiende el flujo de los datos.
Elimina primero los identificadores.
Trata las fechas como datos sensibles.
Trata las alergias, los medicamentos, el estado de embarazo, las notas de salud mental, los datos genéticos y las enfermedades poco frecuentes como contexto de alto riesgo.
Mantén el procesamiento en local siempre que sea posible.
Usa ejemplos sintéticos para las pruebas.
Revisa los resultados a mano.
Guarda registros de lo que se eliminó y de lo que se envió.
Pregunta dónde se almacenan los datos.
Pregunta quiénes son los encargados del tratamiento.
Pregunta si se pueden borrar los datos.
Pregunta si se usan para entrenamiento, analítica, elaboración de perfiles o mejora del producto.
No afirmes que cumples la normativa sin una revisión jurídica y de privacidad.
Si el sistema no sabe responder a esas preguntas, el problema no es el prompt.
El problema es el flujo de trabajo.
Lo que aprendí
Lo que aprendí es sencillo: la privacidad en la sanidad no es un botón que se pulsa al final. Es una frontera que se diseña antes de que los datos sensibles lleguen a un sistema que no los necesita.
Los siguientes pasos prácticos son aburridos, y por eso importan.
No pegues texto clínico en bruto por defecto.
Elimina primero los identificadores.
Trata las fechas como datos sensibles.
Usa ejemplos sintéticos para las pruebas.
Mantén el procesamiento en local cuando sea posible.
Revisa los resultados a mano.
Registra lo que se eliminó y lo que se envió.
No afirmes que cumples la normativa porque una demo funcionó una vez.
Una mejor tecnología sanitaria no empieza con un prompt mejor.
Empieza con menos datos innecesarios cruzando la frontera.