Seguridad de datos médicos con LLM: on-premise y accesos

01/10/2026

El director de tecnología de un hospital me dijo una vez, entre broma y verdad: mi personal ni siquiera necesita que le enseñen a pegar el expediente de un paciente en un chatbot público para que se lo resuma. La broma no tiene gracia, porque es cierta. Cuando se habla de seguridad de datos médicos con LLM, el mayor riesgo casi nunca viene de hackers sino de la comodidad de los propios usuarios.

Como desarrolladora de LLM en vietnamita, AIVISION ve la seguridad como parte del diseño desde el principio, no como una capa de pintura al final. Este artículo trata las tres capas en las que pensamos: dónde se ejecuta el modelo, cómo se tratan los datos antes de que lleguen al modelo y quién puede ver qué.

Capa uno: dónde se ejecuta el modelo

La primera pregunta, antes de cualquier discusión sobre calidad, es adónde van los datos. Hay tres tipos de despliegue comunes, y cada uno implica compromisos distintos.

• Servicio de nube pública por API: rápido y barato para empezar, pero los datos salen de su infraestructura. Con expedientes clínicos, muchas instituciones no pueden aceptarlo.
• Nube privada o zona de datos aislada: los datos permanecen en un entorno cuyo contrato ustedes controlan, un equilibrio entre flexibilidad y seguridad.
• On-premise: el modelo se ejecuta dentro del centro de datos del propio hospital. Los datos no salen de sus muros, pero ustedes se hacen cargo del hardware, la operación y las actualizaciones.

No creo que on-premise siempre sea la respuesta correcta. Para una clínica pequeña, operar su propio servidor con GPU puede costar más esfuerzo del que aporta, y un sistema mal asegurado en un servidor casero es peor que una nube bien administrada. Pero para un hospital grande, o para datos con requisitos legales estrictos, ejecutar el modelo en la infraestructura propia es una opción razonable que muchas instituciones prefieren. Nuestro enfoque de diseño es admitir también el despliegue interno, donde el modelo va hacia los datos y no al revés.

Capa dos: anonimización antes del procesamiento

Muchas tareas no necesitan saber quién es el paciente. Resumir una nota, estandarizar terminología, encontrar el procedimiento correspondiente: nada de esto depende del nombre ni del número de identificación. Entonces, ¿para qué incluirlos?

La anonimización es un filtro previo a que los datos toquen el modelo: detectar nombres, teléfonos, domicilios, números de paciente, fechas de nacimiento, y reemplazarlos por marcadores. Cuando el modelo devuelve su resultado, si hace falta se vuelven a colocar los datos desde una tabla de correspondencia guardada por separado y con control de accesos.

La dificultad está en los detalles. Los nombres vietnamitas se confunden fácilmente con palabras comunes: un nombre propio puede ser un sustantivo en otra frase. Los domicilios aparecen abreviados, incompletos, en medio de oraciones descriptivas. Un dato poco frecuente, como una ocupación particular junto con una localidad pequeña, basta para reconocer a una persona aunque no aparezca el nombre. Por eso la anonimización nunca es perfecta, y no prometemos que lo sea. Reduce el riesgo, no lo elimina. Necesita probarse con el tipo de datos propio de la institución, con una muestra de revisión manual de forma periódica.

Hay una opción intermedia que vale la pena considerar: enviar al modelo solo la cantidad mínima de datos necesaria para la tarea. Resumir un episodio de tratamiento no requiere incluir todo el historial administrativo del paciente. El principio de minimización de datos suena árido, pero es una de las medidas más baratas y eficaces.

Capa tres: control de accesos

Aunque el modelo corra en casa y los datos estén anonimizados, queda la pregunta de quién puede preguntar qué. Un sistema de consulta de expedientes conectado a un LLM puede convertirse sin querer en una puerta trasera si lee todo y responde a cualquiera.

• Permisos por rol: enfermería, médicos y personal de facturación ven partes distintas.
• El modelo solo recupera de los documentos que la propia persona que pregunta tiene permiso de ver, no de todo el acervo.
• Bitácora: quién preguntó qué, cuándo y con base en qué documentos respondió el sistema.
• Límites a la exportación masiva de datos y alertas ante consultas fuera de lo normal.

El segundo punto de la lista es donde tropiezan muchos proyectos. Si indexan todos los expedientes en un acervo y dejan que el modelo busque, pero olvidan ligar el permiso de acceso a cada documento, habrán creado una herramienta que permite a un empleado preguntar por pacientes que no están dentro de su ámbito de atención. Los permisos deben aplicarse en la capa de recuperación, antes de que el contenido llegue al modelo, y no se puede confiar en que el modelo sepa comportarse.

Lo que suele olvidarse

Quedan otras fugas en las que poca gente piensa. Las bitácoras del sistema pueden contener el texto literal de las preguntas y, sin querer, convertirse en un segundo almacén de datos sensibles. Los respaldos también deben cifrarse. Los datos usados para entrenar o hacer fine-tuning adicional requieren una política propia: cuándo se pueden usar, si ya fueron anonimizados, quién los aprueba. Y los proveedores, nosotros incluidos, deben decir por escrito si conservan los datos, por cuánto tiempo y para qué.

También quiero mencionar a las personas. El mejor proceso pierde frente a un empleado que pega datos en una herramienta pública porque la oficial es muy lenta o difícil de usar. La buena seguridad es la que los compañeros quieren usar. Si la herramienta interna es más cómoda que el atajo, la gente elegirá el camino correcto.

Lo que no decimos

AIVISION entrena modelos en un clúster de 24 GPU NVIDIA H200 y 8 GPU NVIDIA B300, ya lanzó el LLM L1.0 y el modelo de speech to text E1.0 para vietnamita, y hace fine-tuning para dominios como el de salud. No ofrecemos compromisos del tipo totalmente seguro, porque ningún sistema lo logra y quien lo promete resulta sospechoso. Lo recomendable es evaluar el riesgo según cada contexto, acordar con las áreas jurídica y de seguridad de la información de la institución, probar primero con datos simulados y solo después tocar datos reales. Y sin importar la tecnología, el contenido generado por un modelo en el ámbito médico sigue necesitando la revisión de una persona antes de usarse.