Cómo usamos nuestra infraestructura para cumplir las normas sanitarias con IA

Thu, 18 Jun 2026 10:30:00 +0200

En un entorno sanitario, el reto de poner IA en producción no es el modelo: es el cumplimiento. Las normas que aplican —tanto los estándares técnicos de interoperabilidad como las leyes— imponen requisitos concretos de control de acceso, confidencialidad, trazabilidad, localización del dato y gobernanza. Una demostración en un portátil ignora todo eso; una plataforma real tiene que satisfacerlo, y tiene que poder demostrarlo ante una auditoría.

Este artículo no es un recorrido por tecnologías. Es lo contrario: tomamos los requisitos que imponen las normas y, para cada uno, mostramos cómo se usa nuestra infraestructura para cumplirlo. La infraestructura es real —dos clústeres RKE2 (Kubernetes v1.35) con Cilium como red, GitOps con Flux, Keycloak como servidor de identidad, inferencia en GPU propias y, en preproducción, scheduling con Volcano— y cada componente está aquí porque resuelve un requisito normativo, no porque quede bien en un diagrama. Como toda infraestructura, además, se mide por eficiencia y coste, que es lo que hace el cumplimiento sostenible en lugar de un gasto que no se aguanta.

Conviene empezar por una idea que mucha gente desconoce: para esto ya existen estándares del sector, y no hay que inventarse nada. Hay estándares de interoperabilidad clínica (HL7, FHIR, DICOM y los perfiles IHE que los combinan), hay un estándar Kubernetes-native para empaquetar y ejecutar IA de imagen médica (MONAI Deploy y su MONAI Application Package), y hay un estándar emergente de cómo debe ser un clúster para ejecutar IA con garantías (el CNCF Kubernetes AI Conformance). Vamos primero a situar ese mapa de estándares, y después a recorrer los requisitos uno a uno.

El mapa de estándares del sector

Tres familias de estándares se cruzan en una plataforma de IA sanitaria, y entender qué cubre cada una evita reinventar ruedas.

Interoperabilidad clínica: HL7, FHIR, DICOM e IHE. Los formatos base son conocidos —HL7 v2 para la mensajería heredada, FHIR para el dato clínico moderno sobre REST, DICOM/DICOMweb para la imagen—. Lo que mucha gente pasa por alto es que existe un cuerpo, IHE (Integrating the Healthcare Enterprise), que no inventa formatos sino que define perfiles: combinaciones concretas de esos estándares para resolver un caso de uso de forma interoperable. Perfiles como XDS/XCA (intercambio de documentos), PIX/PDQ (identificación y consulta de pacientes) y, crucial para la seguridad, ATNA (Audit Trail and Node Authentication), que especifica los cuatro pilares de un nodo seguro: autenticación de nodo, autenticación de usuario, registro de auditoría y cifrado de las comunicaciones. Y se apoya en un perfil hermano, Consistent Time (CT), que sincroniza los relojes de todos los nodos: sin tiempo fiable, un registro de auditoría no sirve como prueba, porque no se puede ordenar ni correlacionar lo que pasó. ATNA se ha modernizado además con RESTful ATNA y el perfil BALP (Basic Audit Log Patterns), que expresan la auditoría como recursos FHIR AuditEvent. IHE es, en la práctica, el estándar que dice cómo se combinan FHIR y DICOM de forma segura y auditable; es la referencia natural para diseñar los controles de cumplimiento.

IA médica sobre Kubernetes: MONAI Deploy y el MAP. Para el problema específico de empaquetar, distribuir y ejecutar aplicaciones de IA de imagen médica existe un estándar de facto: MONAI Deploy, parte del proyecto MONAI (framework open source de deep learning para imagen sanitaria, del ecosistema PyTorch), y su MONAI Application Package (MAP). Un MAP es una imagen de contenedor que cumple una especificación definida por el MONAI Deploy working group —expertos de más de una docena de instituciones de imagen médica— y, según esa especificación, un MAP debe soportar el despliegue en Kubernetes e integrarse con DICOM y FHIR para el intercambio de datos. Es decir, hay un formato estándar para “una app de IA médica” que corre nativamente en Kubernetes, que es exactamente nuestro sustrato. Esto importa para el cumplimiento porque un MAP encapsula el modelo, sus dependencias y su contrato de entrada/salida de forma versionada y reproducible. Alrededor del MAP, MONAI Deploy aporta además las piezas de orquestación que un entorno clínico necesita: un Informatics Gateway que recibe estudios DICOM y dispara la inferencia, y un Workflow Manager que encadena los pasos de un pipeline sobre Kubernetes. No es solo un formato de empaquetado: es una manera estándar de llevar una app de imagen médica desde el registro hasta el PACS sin integraciones a medida en cada hospital.

Clústeres preparados para IA: CNCF Kubernetes AI Conformance. En noviembre de 2025 la CNCF lanzó el Certified Kubernetes AI Conformance Program, que estandariza cómo se ejecutan cargas de IA sobre Kubernetes mediante un conjunto de requisitos —los KARs (Kubernetes AI Requirements)— sobre integración de GPU, gestión de volúmenes y networking a nivel de job, alineados con Kubernetes v1.35. Y lo más relevante para sanidad: el programa anunció que durante 2026 se amplía con una línea de Sovereign AI, centrada en sandboxing reforzado y privacidad del dato. Es la formalización, a nivel de industria, de que un clúster que ejecuta IA seria debe cumplir unas garantías mínimas —y de que la soberanía del dato es ya una categoría de primera clase, no una preferencia.

Con este mapa sobre la mesa, recorramos los requisitos.

Requisito: interoperabilidad sobre estándares (EHDS, MDR, IHE)

El EHDS obliga a que los datos de salud se intercambien en formatos estándar, y su perfilado se construye sobre FHIR R4; los perfiles IHE definen cómo se hace ese intercambio de forma interoperable; el MDR exige trazabilidad del dato cuando el software es producto sanitario. El requisito: la plataforma no puede hablar un dialecto propio.

Cómo lo cumplimos: ponemos una capa de interoperabilidad como frontera entre el dominio clínico y el de inferencia. Un servidor FHIR (R4, porque es la versión normativa y la que perfila el EHDS; R5 tiene adopción marginal y el sector espera a R6, en balotaje desde enero de 2026) expone los recursos clínicos; un nodo DICOMweb sirve la imagen mediante QIDO-RS, WADO-RS y STOW-RS; y una pasarela transforma a FHIR el HL7 v2 entrante. Sobre esa base aplicamos los perfiles IHE pertinentes: identificación de paciente con PIX/PDQ para no cruzar identidades entre fuentes, e intercambio documental con XDS/XCA cuando procede. El modelo de IA nunca toca la base de datos clínica directamente: consume FHIR y DICOMweb a través de esta capa, que es donde se normaliza, se perfila y se controla el acceso. Cuando desplegamos una aplicación de IA de imagen, el objetivo es empaquetarla como MAP, de modo que su contrato con DICOM/FHIR sea el estándar del sector y no una integración a medida.

Requisito: los resultados de la IA vuelven al flujo clínico en estándar (DICOM, FHIR, MDR)

Una IA clínica no termina cuando produce una salida: esa salida tiene que volver al sistema en un formato que el clínico y la historia entiendan, y de forma trazable (MDR). Devolver un PDF o un JSON propietario rompe la interoperabilidad y deja el resultado fuera del registro clínico, donde nadie lo audita ni lo reutiliza.

Cómo lo cumplimos: los resultados de los modelos de imagen se reinyectan como objetos DICOM estándar —DICOM SR (Structured Report) para hallazgos y mediciones, DICOM SEG para segmentaciones, o Secondary Capture para representaciones visuales— mediante STOW-RS, de modo que el PACS y el visor los tratan como cualquier otra serie del estudio. Los resultados no relacionados con imagen se expresan como recursos FHIR (Observation, DiagnosticReport) ligados al paciente y al estudio de origen. Así, el resultado de la IA es un ciudadano de primera del registro clínico —referenciable, versionado y auditable—, no un artefacto suelto en un disco. Empaquetar la aplicación como MAP ayuda también aquí: el contrato de salida hacia DICOM/FHIR forma parte de la propia especificación del paquete, no de un script de pegamento distinto en cada despliegue.

Requisito: acceso mínimo y autorizado (RGPD, ENS, EHDS, IHE ATNA)

El RGPD impone minimización (art. 5) y protección reforzada de los datos de salud como categoría especial (art. 9); el ENS exige identificación y control de acceso; el EHDS, control sobre quién accede y para qué; e IHE ATNA exige autenticación de nodo y autenticación de usuario como pilares de un nodo seguro. Traducido a infraestructura: cada acceso a datos clínicos autenticado, autorizado al mínimo y atado a un propósito; y cada nodo que participa, identificado.

Cómo lo cumplimos: un único servidor de identidad, Keycloak, gobierna toda la autorización con OAuth 2.1 y OpenID Connect, perfilados por SMART on FHIR:

Scopes orientados a recurso y propósito. SMART distingue patient/, user/ y system/, y su versión 2 separa permisos por operación (create, read, update, delete, search). Un agente de IA recibe el mínimo, por ejemplo system/ImagingStudy.rs (solo leer y buscar estudios). Es la minimización del RGPD implementada en el token —y la autenticación de usuario que pide ATNA.
Identidad de servicio sin secretos compartidos. Las cargas desatendidas usan private_key_jwt (aserción firmada con clave privada).
Binding de audiencia. El token lleva en aud la URL del servidor de destino y este la valida, evitando la reutilización lateral de credenciales; se apoya en extensiones de Keycloak específicas para FHIR.
Autenticación de nodo (ATNA) con mTLS. Entre los nodos que tratan datos clínicos exigimos TLS mutuo, de modo que no solo se autentica al usuario o al servicio, sino a la propia máquina/servicio que participa en el intercambio.

DICOMweb se protege con el mismo token y el mismo Keycloak. El resultado es un plano de identidad único para FHIR, DICOMweb y los servidores MCP: un solo sitio donde demostrar quién puede acceder a qué.

El mismo principio de mínimo privilegio se aplica un nivel más abajo, al propio plano de Kubernetes, que el ENS también alcanza. Los operadores no acceden con un cluster-admin universal: el acceso de los administradores a la API del clúster se federa contra Keycloak por OIDC, con roles acotados por namespace, de modo que también el acceso técnico queda autenticado, limitado y auditado. Y las cargas de trabajo usan service accounts sin permisos por defecto, a las que se concede solo lo imprescindible. Quien administra la plataforma está sujeto al mismo régimen de identidad que quien consume los datos clínicos a través de ella.

Requisito: confidencialidad, aislamiento y prevención de fugas (RGPD art. 32, ENS, ATNA cifrado)

El RGPD (art. 32) exige confidencialidad, integridad, disponibilidad y resiliencia, con medidas como la separación de datos y el cifrado; el ENS detalla controles de segregación y protección de las comunicaciones; ATNA exige cifrado de las comunicaciones entre nodos. En una plataforma multi-cliente esto se traduce en dos cosas: que lo de un centro no sea visible para otro, y que un componente comprometido no pueda sacar datos fuera.

Cómo lo cumplimos en el aislamiento entre inquilinos: cada tenant vive en su propio namespace, con RBAC acotado, ResourceQuota y LimitRange, una base de datos dedicada por operador (CloudNativePG) —no una base compartida con un filtro de aplicación— y su propio espacio de almacenamiento de objetos. La identidad se segrega por realm en Keycloak. Todo se define en Git y lo reconcilia Flux (GitOps): la separación es declarativa y auditable por historial de cambios. Ante “demuéstrame que el centro A no ve los datos del centro B”, la respuesta es un commit.

Cómo lo cumplimos en la confidencialidad de red y la prevención de exfiltración: la red la gestiona Cilium (eBPF) con modelo default-deny. Un pod no tiene conectividad salvo la que una política le concede explícitamente, flujo a flujo, lo que convierte la exfiltración en algo que se bloquea en el kernel. Por ejemplo, el componente de trazabilidad solo puede hablar con su base analítica, su PostgreSQL, el almacenamiento de objetos, la caché y el DNS:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
 name: trazabilidad-egress-minimo
 namespace: trazabilidad
spec:
 endpointSelector:
 matchLabels:
 app: trazabilidad-web
 egressDeny:
 - toEntities: [world]  # nada hacia fuera del clúster por defecto
 egress:
 - toEndpoints:
 - matchLabels:
 app: postgres
 - toEndpoints:
 - matchLabels:
 app: analitica
 - toEndpoints: # DNS, sin esto el pod no resuelve
 - matchLabels:
 k8s:io.kubernetes.pod.namespace: kube-system
 k8s-app: kube-dns
 toPorts:
 - ports: [{ port: "53", protocol: UDP }]

Dos matices que separan una política correcta de una rota o permeable: hay que permitir explícitamente el DNS (si no, el pod no funciona) y filtrar por identidad de endpoint, no por CIDR, porque en una red basada en identidad el filtrado por rangos de IP no se comporta como la intuición sugiere. Sobre esto añadimos observabilidad de flujos con Hubble y seguridad en runtime con Tetragon (eBPF), que vigila ejecución de procesos, acceso a ficheros y conexiones dentro del contenedor, permitiendo detectar y bloquear comportamiento anómalo en cargas que tratan datos sensibles. Para el cifrado en tránsito que exigen el art. 32 y ATNA, cert-manager gestiona TLS en los ingress y Cilium puede cifrar de forma transparente el tráfico entre nodos.

A esto se suman dos controles de base que el art. 32 y el ENS dan por descontados. Primero, los Pod Security Standards en perfil restringido —contenedores sin privilegios, sin ejecutarse como root y con el sistema de ficheros en solo lectura donde es posible—, que reducen la superficie de un contenedor comprometido. Segundo, una gestión disciplinada de secretos y claves: las claves privadas de private_key_jwt, los certificados y las credenciales de base de datos no viven en manifiestos planos en Git, sino gestionadas y rotadas, con cert-manager emitiendo y renovando certificados de forma automática. Un secreto filtrado en un repositorio es una brecha de datos en potencia, y se trata como tal desde el diseño.

Requisito: ciclo de vida del dato — minimización, retención y pseudonimización (RGPD, EHDS)

El RGPD no solo limita quién accede: limita cuánto dato se trata (minimización, art. 5) y cuánto tiempo se conserva (limitación del plazo de conservación), y promueve la pseudonimización como medida de protección (art. 32). El requisito: no acumular datos clínicos identificables más de lo necesario, y desidentificar donde el caso de uso lo permita.

Cómo lo cumplimos: la capa de interoperabilidad es también el punto de control del ciclo de vida del dato. Allí se aplica pseudonimización cuando el flujo de IA no necesita identidad directa —por ejemplo, evaluación o ajuste sobre cohortes—, manteniendo la tabla de reidentificación separada del resto del sistema y tras sus propias políticas de acceso. Un principio que aplicamos de forma estricta: las trazas y los logs no contienen datos clínicos. Registran identificadores de recurso, modelo, coste, latencia y tenant, no el contenido de la historia ni la imagen, de modo que la capa de observabilidad no se convierte en un segundo almacén de datos sensibles que haya que proteger y auditar por duplicado. Y las políticas de retención se aplican por tipo de dato —trazas, cachés, copias intermedias— con expiración automática, de forma que el plazo de conservación es una propiedad declarada y verificable, no un olvido que va acumulando riesgo en discos que nadie revisa.

Requisito: localización y soberanía del dato (RGPD, EHDS, CNCF Sovereign AI)

Tratar datos de salud de categoría especial enviándolos a una API de inferencia de un tercero, fuera del control del responsable, es difícil de justificar bajo el RGPD y contrario al espíritu del EHDS. Y no es solo un requisito legal: la línea de Sovereign AI del CNCF AI Conformance lo eleva a categoría técnica de primera clase para 2026. El requisito implícito es que el dato clínico no salga del perímetro.

Cómo lo cumplimos: la inferencia se sirve en local, sobre GPU propias, con un motor de serving de alto rendimiento (vLLM). Las aplicaciones de IA de imagen se empaquetan, idealmente, como MAP, que corren nativamente en el clúster sin sacar el dato fuera. Delante ponemos una pasarela de modelos por la que pasa todo el tráfico de inferencia: es el punto donde se decide qué se ejecuta dentro y dónde, de forma que el dato clínico no sale por defecto y cualquier excepción es explícita y registrada. Que esto sea viable —y no un lujo— depende de la eficiencia: para servir en casa con un coste razonable hay que exprimir el hardware, y ahí entra el scheduling. La soberanía deja de ser una promesa de la diapositiva para ser una propiedad de cómo está montada la inferencia.

Hay un matiz que conviene explicitar, porque marca la diferencia entre “decimos que el dato no sale” y “el dato no puede salir sin que conste”. La pasarela invierte la carga: el comportamiento por defecto es la inferencia local, y cualquier salida hacia un servicio externo es una excepción que hay que habilitar de forma explícita, que queda registrada y que, además, choca con las políticas de red default-deny si no se ha abierto el destino correspondiente. Es decir, la soberanía no se sostiene solo en una decisión de diseño, sino en varios controles que se refuerzan entre sí —pasarela, política de red y registro—, de modo que un descuido de configuración no se traduce en una fuga silenciosa. En un dato de categoría especial, esa diferencia entre confianza y garantía es justo lo que pide el RGPD cuando habla de protección de datos desde el diseño y por defecto (art. 25).

Requisito: ejecución fiable de cargas críticas y eficiencia (ENS, CNCF AI Conformance)

Mantener la inferencia en casa solo es sostenible si la GPU se aprovecha, y ciertas cargas (un lote nocturno de procesamiento de imagen) deben ejecutarse de forma fiable y completa. El KAR del CNCF AI Conformance formaliza, además, requisitos de integración de GPU y de networking a nivel de job que un clúster serio de IA debe cumplir. El planificador por defecto de Kubernetes programa pod a pod, lo que para cargas distribuidas produce trabajos a medias que retienen GPU sin avanzar.

Cómo lo cumplimos: el reparto de GPU lo gobierna Volcano (proyecto incubado en la CNCF), hoy en preproducción, con los mecanismos que importan para fiabilidad y eficiencia:

Gang scheduling (PodGroup con minAvailable): un trabajo distribuido arranca completo o no arranca, evitando GPU bloqueadas a la espera.
Colas por tenant con cuota y prioridad, que materializan el reparto justo entre inquilinos que la multitenancy solo declara.
Fair-share (DRF) para repartir proporcionalmente y preempción para que una carga urgente adelante a un lote diferible.
Conciencia de topología (NVLink/PCIe) para reducir la fragmentación.

Esto eleva la utilización efectiva del parque de GPU, que es lo que hace económicamente viable la inferencia soberana. Y se gestiona con métricas, no con impresiones: utilización efectiva frente a asignada, porcentaje de tiempo en idle, fragmentación, rendimiento por GPU (tokens por segundo) y horas-GPU consumidas por tenant. Son las cifras que permiten decidir si hace falta más hardware o si sobra capacidad mal repartida, y las que convierten una discusión sobre coste en una decisión con datos. Sobre el estado del arte: Kubernetes 1.34 llevó DRA (Dynamic Resource Allocation) a disponibilidad general —asignación de aceleradores por atributos en lugar de por conteo—, y Kueue cubre la gestión de cuotas de jobs; ambos se combinan con un scheduler de gang como Volcano. La eficiencia no es un extra de FinOps: aquí es la condición que hace sostenible cumplir el requisito de soberanía.

Conviene además leer estos componentes a la luz del CNCF AI Conformance: sus requisitos (los KAR) verifican que un clúster integra correctamente las GPU, gestiona los volúmenes que las cargas de IA necesitan y resuelve el networking a nivel de job. No son adornos: son justo las capacidades sobre las que se apoyan el serving de inferencia, el almacenamiento de modelos y datos, y el scheduling distribuido que acabamos de describir. Alinearse con ese estándar es, en la práctica, garantizar que la plataforma ejecuta IA con las mismas propiedades que la industria ha acordado como mínimo exigible —y poder demostrarlo, que en un entorno regulado vale tanto como cumplirlo.

Requisito: registro de actividad y supervisión humana (AI Act, EHDS, IHE ATNA/BALP)

El AI Act, para sistemas de alto riesgo —y la IA clínica casi siempre lo es—, exige registro automático de la actividad (logging, art. 12) y supervisión humana significativa (art. 14); el EHDS impone trazabilidad sobre el uso de los datos; e IHE ATNA/BALP define cómo debe ser ese registro de auditoría, expresándolo como recursos FHIR AuditEvent. El requisito: poder reconstruir cada acceso y cada decisión, en un formato estándar y consultable.

Cómo lo cumplimos en dos planos. En el plano de acceso al dato, los eventos de auditoría (quién accedió a qué recurso clínico, cuándo, con qué propósito) se emiten siguiendo el patrón FHIR AuditEvent de BALP, de modo que la auditoría es interoperable y no un log propietario. En el plano de decisión de la IA, cada inferencia se registra como una traza auditable con Langfuse —prompt, respuesta, modelo y versión, coste, latencia y tenant—, almacenada en componentes propios encerrados tras políticas de red que impiden su salida. La traza cumple el logging del AI Act y la trazabilidad del EHDS, y a la vez sirve de base para la evaluación continua y para la supervisión humana, que se ejerce en la pasarela (revisión, límites, posibilidad de intervención). La instrumentación converge en las convenciones semánticas GenAI de OpenTelemetry, correlacionables con el resto de la observabilidad.

Un registro de auditoría solo vale como prueba si es íntegro y está ordenado en el tiempo. Por eso los eventos se conservan en almacenamiento de solo-añadir (sin posibilidad de edición a posteriori) con su retención definida, y los relojes de los nodos se mantienen sincronizados —el perfil Consistent Time de IHE llevado a la práctica con NTP—, de modo que la secuencia de “quién hizo qué y cuándo” es reconstruible y defendible. Sin integridad y sin tiempo fiable, un log es un apunte, no una evidencia.

Requisito: disponibilidad, continuidad y recuperación (RGPD art. 32, ENS)

El art. 32 del RGPD exige no solo confidencialidad e integridad, sino disponibilidad y resiliencia, y la capacidad de restaurar el acceso a los datos tras un incidente; el ENS detalla medidas de continuidad de servicio. Un sistema clínico que se cae y no se recupera es un incumplimiento, no solo una incidencia operativa.

Cómo lo cumplimos: la plataforma corre sobre dos emplazamientos (site01 y site02), lo que permite separar cargas y disponer de capacidad ante la caída de un sitio. El plano de control de cada clúster es de alta disponibilidad, con varios nodos de control y etcd replicado. Las bases de datos por tenant las gestiona un operador que automatiza réplicas y copias de seguridad hacia el almacenamiento de objetos, y el estado declarativo en Git permite reconstruir un entorno completo desde su repositorio. La recuperación no depende de un servidor concreto ni de la memoria de quien lo montó, sino de volver a aplicar lo que está versionado. La combinación de copias de datos y reproducibilidad de configuración es, en términos del art. 32, precisamente la capacidad de restaurar el servicio en un plazo razonable.

Requisito: operación reproducible y demostrable (ENS, MDR/ISO 13485, AI Act)

Las normas no solo piden que el sistema haga lo correcto: piden poder demostrarlo y reproducirlo. El ENS exige gestión de la configuración y trazabilidad de cambios; el MDR (vía ISO 13485) exige control de cambios y reproducibilidad; el AI Act, gestión de riesgos y documentación técnica.

Cómo lo cumplimos: todo el estado de la plataforma —despliegues, políticas de red, cuotas, RBAC, configuración de identidad— se describe en Git y lo aplica Flux por GitOps. Cada cambio es una revisión con autor, fecha y revisor; cada entorno es reproducible desde su repositorio. Las versiones de modelo quedan registradas en las trazas, y empaquetar la IA como MAP versionado refuerza la reproducibilidad: se sabe exactamente qué artefacto se ejecutó. Una auditoría de configuración se convierte así en una consulta al historial, con capacidad de reconstruir qué estaba desplegado en una fecha dada.

La pieza que lo ata todo: ISO/IEC 42001

Todo lo anterior son controles técnicos que satisfacen requisitos concretos. Pero las normas también exigen un sistema de gestión que los ordene, evalúe y mejore de forma continua, con roles y responsabilidades definidos. Esa pieza es ISO/IEC 42001, la norma certificable de sistemas de gestión de IA: la que transforma “tenemos los controles” en “tenemos una IA gobernada y demostrable”. Es, precisamente, el contenido del curso de Sistemas de Gestión de IA que publicaremos en breve, pensado para acompañar el salto de la implementación técnica a la gobernanza certificable.

Visión del sector a junio de 2026

Vale la pena fijar la foto del momento, porque varias corrientes han convergido justo ahora y condicionan cualquier decisión de plataforma.

Todo lo de IA converge en Kubernetes. La propia CNCF lo describió en 2026 como “la gran migración”: las plataformas de IA, antes dispersas en soluciones propietarias, se están consolidando sobre Kubernetes como sustrato común. La consecuencia práctica es que las capacidades antes reservadas a sistemas HPC —gang scheduling, conciencia de topología, integración con fabric de red— son ya ciudadanas de primera en Kubernetes.

La asignación de aceleradores se estandariza. Con DRA en disponibilidad general (Kubernetes 1.34) el modelo viejo de “contar GPU” da paso a la asignación por atributos del dispositivo, con particionado dinámico. Es un cambio de fondo en cómo se reparte el hardware caro, y nuestros clústeres (v1.35) ya están en la rama donde esto es real.

Aparecen sellos de conformidad para IA. El CNCF Kubernetes AI Conformance (lanzado en noviembre de 2025, con los KARs) define qué hace “AI-ready” a un clúster, y en 2026 incorpora la línea de Sovereign AI: sandboxing reforzado y privacidad del dato como requisitos formales. Para sanidad esto es enorme, porque convierte la soberanía del dato —que veníamos defendiendo por obligación legal— en una propiedad certificable de la plataforma.

La IA médica de imagen tiene su estándar de empaquetado. MONAI Deploy y el MAP maduran como la forma estándar de construir, validar y ejecutar aplicaciones de imagen médica, con Kubernetes como destino y DICOM/FHIR como contrato. Quien despliega IA de imagen seria en 2026 mira hacia MAP, no hacia integraciones a medida.

La regulación entra en su ventana de aplicación. El EHDS está en vigor desde marzo de 2025 y sus hitos se acercan: organismos de acceso a datos hacia 2027, uso primario transfronterizo hacia 2029, todo perfilado sobre FHIR R4. El AI Act vio sus plazos de alto riesgo aplazados por el Digital Omnibus (Anexo III a diciembre de 2027, Anexo I a agosto de 2028), pero sus obligaciones —gestión de riesgos, logging, supervisión humana— no se mueven. Y la transición FHIR R4 → R6 se planifica saltando R5. La foto es la de un sector donde la técnica (Kubernetes, eBPF, DRA, MAP) y la norma (EHDS, AI Act, IHE) por fin avanzan a la vez.

La economía de la GPU empuja hacia dentro de casa. El recurso sigue siendo escaso y caro, y eso tiene dos efectos que se refuerzan. Por un lado, la presión por la eficiencia —utilización, fragmentación, densidad— es máxima, y por eso el scheduling (Volcano) y la asignación por atributos (DRA) están en el centro del debate. Por otro, la maduración de los modelos de pesos abiertos, que rinden cada vez mejor en hardware modesto, ha hecho viable servir inferencia de calidad en local sin depender de una API externa. La combinación —modelos abiertos competentes más herramientas de eficiencia sobre Kubernetes— es justo la que convierte la soberanía del dato, en sanidad, de aspiración costosa a opción razonable. La tendencia de 2026 no es solo “IA en la nube”; es también un regreso pragmático del cómputo a infraestructura propia donde el dato y el coste lo exigen.

Dónde estamos nosotros en esa foto: con la plataforma sobre Kubernetes, eBPF como sustrato de red y seguridad, scheduling de GPU madurando en preproducción, inferencia soberana por diseño, trazabilidad en formato auditable y el marco de gestión (ISO 42001) como siguiente paso. No perseguimos la moda; estamos exactamente en la línea por donde el sector ha decidido avanzar.

Resumen: requisito por requisito

La tesis es simple: cada norma o estándar del sector impone un requisito, y cada requisito se satisface con una pieza concreta de la infraestructura. La interoperabilidad del EHDS y los perfiles IHE, con una capa FHIR R4 + DICOMweb y, para la IA de imagen, el empaquetado MAP. El acceso mínimo y autorizado del RGPD/ENS y la autenticación de ATNA, con Keycloak, SMART on FHIR y mTLS. La confidencialidad y la prevención de fugas del art. 32, con multitenancy, Cilium en default-deny y Tetragon. La soberanía del dato (RGPD/EHDS y CNCF Sovereign AI), con inferencia local viable gracias a la eficiencia de Volcano. El logging y la supervisión del AI Act y la auditoría de ATNA/BALP, con trazabilidad en formato FHIR AuditEvent. La operación reproducible del ENS y el MDR, con GitOps y MAP versionado. Y la gobernanza que lo ata todo, con ISO 42001.

No es un PowerPoint: es infraestructura que corre, que cumple y que —por ser infraestructura— se mide por eficiencia y coste. De eso, del control de costes de una plataforma de IA sanitaria, va el próximo artículo.

IHE on lo0 — Blog Técnico