IA on lo0 — Blog Técnico

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

Thu, 18 Jun 2026 11:00:00 +0200

En el ámbito de defensa, el reto de poner IA en operación no es el modelo: es la seguridad y el cumplimiento. Las normas que aplican —los estándares de interoperabilidad aliada, las reglas de seguridad centrada en el dato, los marcos de acreditación y los principios de uso responsable— imponen requisitos concretos de control de acceso, clasificación, confidencialidad, trazabilidad, cadena de suministro y soberanía. Una demostración en un portátil conectado a internet ignora todo eso; una plataforma operable tiene que satisfacerlo, y tiene que poder demostrarlo ante una acreditación.

Este artículo no es un recorrido por tecnologías. Es lo contrario: tomamos los requisitos que imponen las normas del sector y, para cada uno, mostramos cómo se usa nuestra infraestructura para cumplirlo. La infraestructura es la misma plataforma real que usamos en otros sectores —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— adaptada a un entorno con requisitos de seguridad más severos. Cada componente está aquí porque resuelve un requisito normativo, no porque quede bien en un diagrama. Y, como toda infraestructura, se mide por eficiencia y coste, lo que hace el cumplimiento sostenible.

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 aliada, hay un modelo de referencia DevSecOps sobre Kubernetes específico de defensa, hay un marco de seguridad (Zero Trust) y de acreditación de proveedores, y hay un cuerpo de principios para el uso responsable de la IA militar. Vamos primero a situar ese mapa, y después a recorrer los requisitos uno a uno.

El mapa de estándares del sector

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

Interoperabilidad aliada. En coalición, los sistemas tienen que entenderse. La Federated Mission Networking (FMN) define cómo se federan redes de misión entre naciones por “spirals” sucesivos; el MIP (Multilateral Interoperability Programme) y su modelo de datos JC3IEDM estandarizan el mando y control; Link-16 y formatos como NVG (NATO Vector Graphics) cubren el intercambio táctico y de situación. Son el equivalente, en defensa, a lo que FHIR y DICOM son en sanidad: el idioma común sin el cual la IA es un sistema aislado que no puede integrarse en la operación.

Seguridad centrada en el dato: STANAG 4774 y 4778. Esta es la pieza más característica del sector. STANAG 4774 define la sintaxis de una etiqueta de confidencialidad (política, clasificación, categorías de seguridad), y STANAG 4778 define el mecanismo de enlace (binding) que ata esa etiqueta al dato a lo largo de todo su ciclo de vida y entre las partes que lo comparten. En lugar de proteger solo el perímetro o el sistema, se protege el propio objeto de información: la clasificación viaja con el dato y la decisión de acceso se toma contra la etiqueta. Ambos STANAG están en proceso de ratificación por las naciones y avanzan de práctica recomendada a requisito para software de misión crítica.

DevSecOps de defensa sobre Kubernetes. Para construir y desplegar software de defensa existe un modelo de referencia muy concreto: el DoD Enterprise DevSecOps Reference Design sobre Kubernetes, materializado en plataformas como Platform One y su línea de productos Big Bang (entrega continua declarativa de paquetes endurecidos sobre un clúster Kubernetes), apoyado en Iron Bank, el repositorio de imágenes de contenedor endurecidas y conformes con los STIG de DISA, escaneadas de forma continua. La filosofía asociada es el cATO (Continuous Authority To Operate): la acreditación deja de ser un hito puntual y pasa a ser un estado que se mantiene con monitorización continua. Es, para defensa, el equivalente al estándar Kubernetes-native que en imagen médica representa MONAI: una forma acordada de empaquetar y operar software con garantías sobre el sustrato que ya usamos.

Marcos de seguridad y acreditación. El DoD Zero Trust Reference Architecture (v2.0) fija el principio rector —no confiar por defecto, verificar siempre— con metas de adopción hacia 2027. La acreditación de proveedores se rige por CMMC 2.0 (cuya Fase 2, con certificación obligatoria por tercero para el nivel 2, llega en noviembre de 2026) sobre los 110 controles de NIST SP 800-171. En España y la UE, el Esquema Nacional de Seguridad en categoría alta y las guías CCN-STIC del Centro Criptológico Nacional cumplen un papel equivalente para los sistemas que manejan información sensible o clasificada.

IA responsable en defensa. La OTAN adoptó seis Principios de Uso Responsable (PRU) de la IA en defensa —legalidad, responsabilidad y rendición de cuentas, explicabilidad y trazabilidad, fiabilidad, gobernabilidad y mitigación de sesgos—, reforzados por su Estrategia de IA revisada en 2024 y por el DARB (Data and AI Review Board). Un matiz jurídico importante: el AI Act de la UE excluye expresamente (art. 2.3) los sistemas de IA destinados en exclusiva a fines militares, de defensa o de seguridad nacional. Es decir, en defensa el marco de IA responsable no es el AI Act, sino los PRU de la OTAN, las reglas nacionales y, como sistema de gestión, la ISO/IEC 42001.

Con este mapa sobre la mesa, recorramos los requisitos.

Requisito: interoperabilidad en coalición (FMN, MIP/JC3IEDM)

En una operación aliada, un sistema que no se integra es inútil por bueno que sea. El requisito, derivado de FMN, del modelo de datos de mando y control (MIP/JC3IEDM) y de los formatos tácticos (Link-16, NVG), es que la IA consuma y produzca información en los formatos comunes de la coalición, no en un dialecto propio.

Cómo lo cumplimos: igual que en otros sectores ponemos una capa de interoperabilidad como frontera, aquí la plataforma se integra a través de los gateways y formatos acordados, de modo que la IA nunca habla directamente con los sistemas de misión, sino que consume y entrega información ya normalizada al estándar de la coalición. Esto mantiene a la IA como un componente que se acopla a la arquitectura federada —respetando sus perfiles y su gobierno del dato— en lugar de un silo que obliga a integraciones a medida en cada despliegue. La interoperabilidad es, además, condición para la trazabilidad y el etiquetado: solo si el dato entra y sale en un formato conocido se le puede adjuntar y preservar su etiqueta de confidencialidad.

Requisito: no confiar por defecto — Zero Trust y acceso verificado (DoD ZT RA, NIST 800-171)

El principio rector de la seguridad de defensa moderna es el Zero Trust: ninguna entidad —usuario, servicio, nodo— es de confianza por su posición en la red; cada acceso se autentica, se autoriza y se verifica de forma continua. NIST 800-171 detalla los controles de acceso e identificación que lo sustentan.

Cómo lo cumplimos: un único servidor de identidad, Keycloak, gobierna la autorización con OAuth 2.1 y OpenID Connect, emitiendo tokens de vida corta y atándolos a su destinatario con la validación de audiencia (aud), de modo que una credencial emitida para un servicio no sirve contra otro. Entre componentes que tratan información sensible exigimos TLS mutuo (mTLS): no solo se autentica al usuario o al servicio, sino a la propia carga que participa en el intercambio. Y la red opera en default-deny (siguiente sección), de forma que la conectividad no es un derecho por estar dentro del clúster, sino un permiso explícito. Las cargas de trabajo usan service accounts sin permisos por defecto, y el acceso de los administradores a la API de Kubernetes se federa contra Keycloak por OIDC con roles acotados: también el acceso técnico queda autenticado, limitado y auditado. Zero Trust no es un producto que se compra; es una propiedad que emerge de identidad fuerte, mínimo privilegio y verificación continua, y así está montada la plataforma. La verificación, además, no se agota en el inicio de sesión: los tokens son de vida corta y se renuevan, las políticas se reevalúan en cada petición, y la postura de cada carga —imagen firmada, política de seguridad aplicada— condiciona si puede ejecutarse y comunicarse. Un componente que deja de cumplir su política deja de poder operar; no se le concede un margen por haber estado dentro.

Requisito: seguridad centrada en el dato y etiquetado (STANAG 4774/4778)

A diferencia de otros sectores, en defensa la clasificación viaja con el dato. El requisito, derivado de STANAG 4774/4778, es que cada objeto de información lleve su etiqueta de confidencialidad y que las decisiones de acceso se tomen contra esa etiqueta, no contra el sistema que la aloja.

Cómo lo cumplimos: las decisiones de autorización no se limitan a roles, sino que incorporan control de acceso basado en atributos (ABAC) evaluando la etiqueta de clasificación del dato frente a la habilitación del solicitante. La política se expresa como código y se evalúa en un punto de decisión central (un motor de políticas tipo OPA/Open Policy Agent) que la capa de aplicación y los gateways consultan antes de servir un recurso. La etiqueta, conforme a STANAG 4774, acompaña al objeto, y el enlace conforme a STANAG 4778 se preserva a través de la plataforma —en los metadatos del objeto en almacenamiento y en las anotaciones que viajan con la petición—. Para un agente de IA, esto significa que su token le da acceso a un nivel de clasificación, y que un dato por encima de ese nivel simplemente no se le entrega, con independencia de dónde esté almacenado.

Este enfoque encarna la regla clásica de no-lectura-hacia-arriba: una entidad con una habilitación dada no accede a información por encima de su nivel, y la decisión se toma sobre la etiqueta del objeto, no sobre suposiciones del sistema. Cuando un flujo requiere mover información a un nivel inferior —una desclasificación o sanitización—, es un paso explícito y auditado, con su propia política, nunca un efecto colateral de una consulta. La etiqueta se preserva en los metadatos del objeto en almacenamiento y en las anotaciones que acompañan a la petición, de modo que el enlace de STANAG 4778 no se pierde al cruzar los componentes de la plataforma.

Requisito: segregación por misión y nivel (multitenancy, NIST 800-171, ENS)

Distintas misiones, distintos niveles de clasificación y distintos compartimentos no pueden compartir un espacio común sin controles. El requisito: aislamiento fuerte, de modo que lo de una misión o nivel no sea accesible desde otro.

Cómo lo cumplimos: cada misión o compartimento vive en su propio namespace de Kubernetes, con RBAC acotado, ResourceQuota y LimitRange, almacenamiento y bases de datos dedicadas por operador —no compartidas con un filtro de aplicación— y su propia segmentación de red. La identidad se segrega por realm en Keycloak. Toda la definición vive en Git y la reconcilia Flux (GitOps), de modo que la segregación es declarativa y auditable por historial de cambios. Donde el nivel de clasificación lo exige, la separación trasciende el clúster: se opera sobre clústeres o emplazamientos físicamente distintos, y el intercambio entre dominios de clasificación, cuando es necesario, se hace mediante soluciones de cruce de dominio (cross-domain) controladas, no abriendo un agujero entre namespaces. En los niveles más altos, cada dominio de seguridad puede ser un clúster independiente con su propia cadena de confianza, sus propias identidades y su propio gobierno, evitando que un único plano de control abarque clasificaciones que nunca deben mezclarse. La elección entre namespace, clúster o emplazamiento separado es, en sí misma, una decisión de acreditación: se documenta, se justifica según el nivel y el compartimento, y queda reflejada de forma declarativa en el repositorio.

Requisito: confidencialidad, cifrado y prevención de exfiltración (NIST 800-171, ENS, Zero Trust)

NIST 800-171 (familias de protección del sistema y las comunicaciones) y el ENS exigen confidencialidad, cifrado de las comunicaciones y prevención de la fuga de información. En defensa, la exfiltración no es un riesgo abstracto: es el objetivo del adversario.

Cómo lo cumplimos: 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. Un componente solo puede hablar con los destinos estrictamente necesarios:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
 name: inferencia-egress-minimo
 namespace: mision-alfa
spec:
 endpointSelector:
 matchLabels:
 app: serving-inferencia
 egressDeny:
 - toEntities: [world]  # ninguna salida fuera del clúster
 egress:
 - toEndpoints:
 - matchLabels:
 app: gateway-modelos
 - toEndpoints: # DNS interno, sin esto 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 permeable: hay que permitir explícitamente el DNS 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 —un proceso inesperado en una carga sensible es justo la señal que se quiere ver en tiempo real—. El cifrado en tránsito lo cubren cert-manager (TLS en los bordes) y el cifrado transparente entre nodos de Cilium. A esto se suman los Pod Security Standards en perfil restringido (sin privilegios, sin root) y una gestión disciplinada de secretos y claves, que no viven en manifiestos planos.

Requisito: cadena de suministro de software verificable (Iron Bank/STIG, SBOM, CMMC)

La cadena de suministro de software es un vector de ataque de primer orden, y el sector lo trata como tal: imágenes endurecidas conforme a los STIG, inventario de componentes (SBOM) y verificación criptográfica de la procedencia. CMMC y NIST 800-171 lo exigen en el flujo de proveedores; la Orden Ejecutiva 14028 popularizó el SBOM.

Cómo lo cumplimos: partimos de imágenes base endurecidas (en la línea de Iron Bank y los STIG de DISA), generamos un SBOM (CycloneDX/SPDX) por artefacto y firmamos imágenes y SBOM con Sigstore/Cosign —proyecto graduado de la CNCF, con firma sin clave gestionada y registro de transparencia—. En el clúster, un control de admisión (Kyverno/políticas) rechaza cualquier imagen que no esté firmada por una identidad de confianza, de modo que no se ejecuta software cuya procedencia no se pueda verificar. La regla se expresa como código y verifica la firma de cada imagen antes de permitir su ejecución:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
 name: exigir-imagenes-firmadas
spec:
 validationFailureAction: Enforce
 rules:
 - name: verificar-firma-cosign
 match:
 any:
 - resources:
 kinds: [Pod]
 verifyImages:
 - imageReferences:
 - "registro.interno/*"
 attestors:
 - entries:
 - keys:
 publicKeys: |-
 -----BEGIN PUBLIC KEY-----
 ...clave de confianza...
 -----END PUBLIC KEY-----

Una imagen sin firma válida es rechazada en admisión, antes de ejecutarse. Como todo el despliegue es GitOps, la cadena —del commit a la imagen firmada a la política que la admite— es trazable de extremo a extremo. Esto satisface el control de cadena de suministro de NIST 800-171 y encaja con el modelo cATO: la verificación es continua, no un sello de una sola vez.

Requisito: soberanía y operación desconectada o air-gapped (redes clasificadas, DDIL)

Las redes de defensa operan frecuentemente aisladas de internet (air-gapped) o en condiciones DDIL —conectividad degradada, intermitente o de bajo ancho de banda en el borde táctico—. Y el dato no puede salir a una API externa bajo ninguna circunstancia. El requisito: la plataforma tiene que funcionar sin internet y sin sacar el dato fuera.

Cómo lo cumplimos: la inferencia se sirve en local, sobre GPU propias, con un motor de serving de alto rendimiento (vLLM) y modelos de pesos abiertos que se pueden alojar íntegramente dentro del perímetro. Todo lo que la plataforma necesita —imágenes de contenedor, modelos, dependencias— se replica en registros y repositorios internos, de modo que el despliegue GitOps reconcilia desde fuentes internas y no requiere acceso a internet. Una pasarela de modelos centraliza el acceso e invierte la carga: el comportamiento por defecto es la inferencia local, y cualquier salida es una excepción que, además de tener que habilitarse explícitamente, chocaría con las políticas de red default-deny. La soberanía no se sostiene en una promesa, sino en varios controles que se refuerzan —pasarela, política de red y aislamiento—, de modo que un descuido de configuración no se traduce en una fuga.

Un punto que en defensa no se puede pasar por alto: ningún componente debe “llamar a casa”. Muchas herramientas envían telemetría, comprueban licencias o descargan actualizaciones contra servidores externos por defecto, y eso, en una red clasificada, es inadmisible. Por eso el default-deny no es solo una medida frente al adversario, sino también frente al propio software: si una imagen intenta una conexión de telemetría no declarada, la política la bloquea y Tetragon la registra. La ausencia de “phone-home” se verifica, no se confía.

Requisito: resiliencia y operación en el borde táctico (DDIL)

Mucha operación de defensa ocurre en condiciones DDIL —conectividad degradada, intermitente o de bajo ancho de banda—, e incluso en aislamiento total. El requisito: la plataforma debe seguir siendo útil cuando el enlace con la retaguardia se cae, y reconciliarse cuando vuelve.

Cómo lo cumplimos: el modelo declarativo de GitOps encaja de forma natural con la operación desconectada. Un emplazamiento en el borde mantiene su propia copia del estado deseado y reconcilia contra registros y repositorios locales, de modo que opera sin depender de una conexión permanente; cuando el enlace vuelve, sincroniza. La inferencia se sirve localmente con modelos ya alojados en el nodo, sin llamadas externas. Las trazas y los eventos de auditoría se almacenan en local y se reenvían (store-and-forward) cuando hay enlace, sin perder el registro. El plano de control de alta disponibilidad y la separación en emplazamientos permiten degradar de forma controlada en vez de caer en bloque. La resiliencia no es un añadido: es una propiedad del diseño declarativo y de la inferencia soberana.

Requisito: robustez y protección del propio sistema de IA (PRU fiabilidad)

El principio de fiabilidad de la OTAN exige que los sistemas de IA tengan capacidades explícitas y bien probadas, y que sean seguros frente a manipulación. Esto añade un requisito que otros sectores tratan con menos urgencia: proteger el propio modelo —sus pesos y su comportamiento— como un activo sensible.

Cómo lo cumplimos: los pesos de los modelos se tratan como dato sensible, alojados dentro del perímetro y con su acceso controlado por las mismas políticas de identidad y red que el resto. La pasarela de modelos es el punto donde se aplican salvaguardas de entrada y salida (validación, límites, filtrado) y donde se puede acotar o desconectar un modelo. La cadena de suministro firmada (SBOM y Cosign) se extiende a los artefactos de modelo, de modo que se ejecuta solo lo que tiene procedencia verificable. Y la trazabilidad alimenta la evaluación continua: medir el comportamiento del modelo a lo largo del tiempo es lo que permite detectar degradaciones o manipulaciones antes de que afecten a la operación. La robustez se construye con los mismos controles —identidad, red, cadena de suministro, trazas— aplicados ahora también al modelo. A esto se añaden salvaguardas frente a entradas adversarias —inyección de instrucciones, datos manipulados— en la pasarela, que valida y acota lo que entra y sale del modelo. En defensa, asumir que el adversario intentará manipular la IA no es pesimismo: es el supuesto de partida del diseño.

Requisito: ejecución fiable de cargas de misión y eficiencia (disponibilidad, sostenibilidad)

Servir IA en casa solo es sostenible si la GPU —recurso escaso y caro— se aprovecha, y ciertas cargas de misión deben ejecutarse de forma fiable y completa. 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 gang scheduling (PodGroup con minAvailable: el trabajo arranca completo o no arranca), colas por misión con cuota y prioridad, fair-share (DRF) para repartir con justicia, preempción para que una carga urgente adelante a una diferible y 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 viable la inferencia soberana. 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. Se gestiona con métricas: utilización efectiva frente a asignada, fragmentación, rendimiento por GPU y horas-GPU por misión. En el borde, donde la GPU es aún más escasa, estas mismas técnicas —junto con modelos cuantizados y de menor tamaño— son las que permiten servir inferencia útil con el hardware disponible en vez de depender de un centro de datos que quizá no esté alcanzable.

Requisito: explicabilidad, trazabilidad y gobernabilidad (PRU de la OTAN, NIST AU)

Tres de los seis Principios de Uso Responsable de la OTAN tocan directamente a la infraestructura: explicabilidad y trazabilidad, gobernabilidad y responsabilidad/rendición de cuentas. Más los controles de auditoría (AU) de NIST. El requisito: poder reconstruir cada decisión de la IA, mantener el control humano y rendir cuentas.

Cómo lo cumplimos: cada inferencia se registra como una traza auditable con Langfuse —entrada, salida, modelo y versión, coste, latencia y misión—, almacenada en componentes propios encerrados tras políticas de red que impiden su salida. Esa traza sirve la trazabilidad que exigen los PRU y los controles AU de NIST, y es la base de la supervisión humana, que se ejerce en la pasarela (revisión, límites y, crucialmente, la posibilidad de intervención y desconexión que pide el principio de gobernabilidad: un sistema de IA en defensa debe poder ser desactivado o acotado por el operador). 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 y los relojes se mantienen sincronizados por NTP. La instrumentación converge en las convenciones semánticas GenAI de OpenTelemetry.

La rendición de cuentas exige además poder atribuir una decisión: qué modelo, qué versión, qué entrada y qué operador estaban implicados. Por eso cada traza enlaza la inferencia con la identidad que la solicitó y con la versión exacta del artefacto de modelo que respondió, de modo que la cadena “quién pidió qué, con qué sistema y con qué resultado” es reconstruible. Sin esa atribución, el principio de responsabilidad y rendición de cuentas de la OTAN queda en una declaración de intenciones.

Requisito: acreditación continua y operación reproducible (cATO, CMMC, ENS)

El sector ha sustituido la acreditación de una sola vez por el cATO: una autorización que se mantiene mientras se demuestre, de forma continua, que los controles siguen en su sitio. El ENS y CMMC exigen igualmente gestión de la configuración y trazabilidad de los cambios.

Cómo lo cumplimos: todo el estado de la plataforma —despliegues, políticas de red, cuotas, RBAC, identidad, políticas de admisión— 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 políticas de seguridad son código (Kyverno/OPA) que se evalúa de forma continua, no una lista que alguien revisa una vez al año, y la monitorización de cumplimiento es permanente. Esto materializa el cATO: una auditoría deja de ser una foto puntual y pasa a ser una consulta a un estado que se mantiene y se verifica sin interrupción, con capacidad de reconstruir exactamente qué estaba desplegado en una fecha dada. Un beneficio práctico es que la evidencia de cumplimiento se genera sola: el estado declarativo en Git, los registros de admisión, las firmas de imagen y las trazas son, en conjunto, el cuerpo de pruebas que una acreditación necesita, producido de forma continua en lugar de recopilado a mano la semana antes de la inspección.

La pieza que lo ata todo: ISO/IEC 42001 y los principios de la OTAN

Todo lo anterior son controles técnicos que satisfacen requisitos concretos. Pero hace falta un sistema de gestión que los ordene, evalúe y mejore, con roles y responsabilidades definidos. En defensa, ese gobierno tiene dos referencias complementarias: los Principios de Uso Responsable de la OTAN, que fijan el “qué” ético y operativo, e ISO/IEC 42001, la norma certificable de sistemas de gestión de IA, que aporta el “cómo” de la gestión continua. Dado que el AI Act excluye la defensa, esta combinación —PRU + ISO 42001— es la espina dorsal de gobernanza para una IA militar responsable y demostrable. Es, precisamente, el contenido del curso de Sistemas de Gestión de IA que publicaremos en breve.

Visión del sector a junio de 2026

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

Agenda “AI-first” y la IA en redes clasificadas. En enero de 2026, el Departamento de Defensa estadounidense fijó una agenda de IA a “velocidad de guerra”, y a lo largo de la primavera se cerraron acuerdos para desplegar modelos de IA generativa en redes clasificadas. La señal es clara: la IA militar deja de ser un piloto y pasa a operación, lo que dispara la exigencia sobre la infraestructura que la sostiene.

El sustrato es Kubernetes endurecido. Platform One, Big Bang e Iron Bank consolidan el patrón: clústeres Kubernetes con imágenes conformes a STIG, cadena de suministro firmada y cATO. La IA de defensa se despliega sobre ese mismo sustrato cloud-native, no sobre sistemas a medida.

Zero Trust con fecha. Las metas de adopción de Zero Trust se sitúan hacia 2027, lo que convierte la identidad fuerte, la microsegmentación y la verificación continua en requisitos con calendario, no en aspiraciones.

La acreditación de proveedores se endurece. La Fase 2 de CMMC, en noviembre de 2026, acaba con la autoacreditación para quien maneja información controlada: hará falta certificación por un tercero sobre los 110 controles de NIST 800-171. La cadena de suministro de software —SBOM y firma con Sigstore— pasa de buena práctica a condición de contrato.

Seguridad centrada en el dato, al fin operativa. Con STANAG 4774/4778 avanzando en ratificación, el etiquetado de confidencialidad enlazado al dato se vuelve un requisito real para software de misión, y no solo una recomendación.

Gobernanza de IA específica de defensa. Los Principios de Uso Responsable de la OTAN y el DARB maduran como el marco de referencia, ocupando el espacio que el AI Act deja libre al excluir la defensa. Y la economía de la GPU, junto con la madurez de los modelos de pesos abiertos, empuja el cómputo hacia infraestructura propia, justo donde el dato clasificado y la operación desconectada lo exigen.

Europa empuja su propia autonomía. En paralelo, la UE refuerza su base industrial y tecnológica de defensa —a través del Fondo Europeo de Defensa y la Agencia Europea de Defensa—, con un énfasis creciente en la soberanía tecnológica. Para una plataforma europea, esto refuerza la apuesta por infraestructura propia, modelos alojables localmente y dependencia mínima de servicios externos: exactamente la dirección en la que está montada.

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

Resumen: requisito por requisito

Cada norma o estándar del sector impone un requisito, y cada requisito se satisface con una pieza concreta de la infraestructura. El Zero Trust y el acceso verificado, con Keycloak, mTLS y default-deny. La seguridad centrada en el dato de STANAG 4774/4778, con ABAC sobre etiquetas de clasificación. La segregación por misión y nivel, con multitenancy y, donde toca, separación física y cross-domain. La confidencialidad y la prevención de fugas, con Cilium en default-deny y Tetragon. La cadena de suministro verificable, con imágenes endurecidas STIG, SBOM y firma Sigstore más control de admisión. La soberanía y la operación desconectada, con inferencia local sobre modelos abiertos y registros internos. La ejecución fiable y la eficiencia, con Volcano. La explicabilidad, trazabilidad y gobernabilidad de los PRU de la OTAN, con trazas auditables y control humano en la pasarela. La acreditación continua (cATO) y la operación reproducible, con GitOps y políticas como código. Y la gobernanza que lo ata todo, con los PRU de la OTAN e ISO 42001.

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

Fuentes

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.

Fuentes

Cuando el MCP crece: ponerle autenticación con Keycloak

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

Cuando un hijo es pequeño, basta con vigilar que no se haga daño. Le pones una valla en la escalera, tapas los enchufes y poco más. Pero el niño crece. Empieza a salir solo, a manejar dinero, a tomar decisiones que tienen consecuencias. Y entonces la educación deja de ser «que no se caiga» para convertirse en algo mucho más exigente: enseñarle a identificarse, a pedir permiso, a saber hasta dónde puede llegar y a rendir cuentas de lo que hace.

Con nuestros servidores MCP nos ha pasado exactamente eso.

El MCP ya no es un juguete

Hace nada, un servidor Model Context Protocol era un experimento que corría en el portátil de alguien para que un modelo pudiera leer un par de ficheros o llamar a una API interna. Daba igual quién lo usara: éramos nosotros, en local, sin nada en juego.

Eso se acabó. Los MCP se han vuelto piezas de infraestructura que la IA usa para tocar sistemas de verdad. Y, como cualquier hijo que crece, han desarrollado necesidades nuevas que antes no tenían:

Multitenancy: ya no hay un único usuario, sino muchos, y lo de uno no puede ser visible para otro.
Control de costes: cada llamada del modelo consume tokens, cómputo y, a veces, APIs de pago. Hay que medir, atribuir y poner límites.
Autenticación y autorización: saber quién está al otro lado, qué permisos tiene y para qué servidor concreto vale su credencial.

Son tres frentes distintos. Hoy nos centramos en el tercero, que es el que abre la puerta a los otros dos: la autenticación. Sin saber quién llama, no hay tenant que separar ni coste que atribuir.

Por qué la autenticación del MCP es un problema con nombre propio

La buena noticia es que aquí no hay que inventar nada. La especificación de MCP no se sacó de la manga un mecanismo de seguridad propio: se apoya en OAuth, el mismo estándar que lleva años detrás del «Iniciar sesión con…» de medio internet. El MCP define cómo un servidor MCP actúa de recurso protegido y delega la emisión de credenciales en un servidor de autorización.

Y ese servidor de autorización puede ser Keycloak, el gestor de identidades open source de la Cloud Native Computing Foundation que probablemente ya tengas montado para el resto de tus aplicaciones. La idea es no añadir un silo de identidad más solo porque ahora hablamos con modelos: reutilizar el que ya gobierna a tus usuarios.

El matiz importante es que MCP no es un único estándar congelado, sino una especificación viva con varias versiones, y cada una pide cosas distintas. A día de hoy conviven cuatro:

2025-11-25 (la última)
2025-06-18
2025-03-26
2024-11-05 (la inicial, que ni siquiera contemplaba autorización)

Igual que con la educación de un hijo no es lo mismo lo que necesita a los 6 años que a los 16, lo que Keycloak tiene que cumplir depende de la versión de MCP con la que trabajes. Veámoslo.

Qué le exige MCP a un servidor de autorización (y qué cumple Keycloak)

La especificación enumera una serie de estándares OAuth que el servidor de autorización debe soportar, con distintos niveles de exigencia (MUST, SHOULD, MAY). Esta es la foto, cruzada con lo que Keycloak soporta:

Estándar	2025-11-25	2025-06-18	2025-03-26	Keycloak
OAuth 2.1 Authorization Framework (borrador)	MUST	MUST	MUST	Soportado
OAuth 2.0 Authorization Server Metadata (RFC 8414)	MUST	MUST	MUST	Soportado
Resource Indicators for OAuth 2.0 (RFC 8707)	MUST	MUST	—	No soportado
Dynamic Client Registration (RFC 7591)	MAY	SHOULD	SHOULD	Soportado
OAuth Client ID Metadata Document (borrador)	SHOULD	—	—	Soportado (experimental)

Una aclaración: MCP también adopta OAuth 2.0 Protected Resource Metadata (RFC 9728), pero ese estándar es cosa del servidor MCP, no del servidor de autorización, así que no entra en la tabla de Keycloak.

Si tomamos como criterio de conformidad que Keycloak «soporta» una versión cuando cumple todos sus MUST y SHOULD, el resultado es este:

Versión MCP	Conformidad
`2025-03-26`	Soportada
`2025-06-18`	Parcial, sin Resource Indicators (RFC 8707)
`2025-11-25`	Parcial, sin Resource Indicators (RFC 8707)

La única pieza que hoy le falta a Keycloak es Resource Indicators for OAuth 2.0 (RFC 8707), el parámetro resource que ata un token a un servidor concreto. La comunidad de Keycloak ya tiene en hoja de ruta soportarlo; mientras tanto, hay un rodeo perfectamente válido que vemos más abajo. Es, siguiendo la analogía, esa asignatura que al niño aún se le resiste pero que se puede aprobar con un truco de estudio hasta que madure del todo.

Manos a la obra: montar Keycloak según tu versión de MCP

Para MCP 2025-03-26

No hay que configurar nada especial. Esta versión no exige el parámetro resource, así que Keycloak cumple de serie. El hijo todavía es pequeño y la valla en la escalera basta.

Para MCP 2025-06-18 y 2025-11-25: atar el token a su audiencia

Aquí empieza lo interesante. Por seguridad, estas versiones exigen que un token de acceso esté ligado a la audiencia para la que se emitió. En cristiano:

El cliente MCP debe incluir el parámetro resource (de RFC 8707) en la petición de autorización y de token, con el valor que identifica al servidor MCP que va a usar.
El servidor MCP debe validar que los tokens que recibe se emitieron específicamente para él.

Esto evita que un token robado o reutilizado sirva para entrar en un servidor distinto del previsto. El problema, como decíamos, es que Keycloak todavía no entiende el parámetro resource.

La solución mientras llega el soporte nativo de RFC 8707 es usar el parámetro scope de OAuth para conseguir el mismo efecto. Imaginemos esta situación:

El servidor MCP está en https://example.com/mcp.
Soporta tres scopes: mcp:tools, mcp:prompts y mcp:resources.
El cliente pide un token con resource = https://example.com/mcp y una combinación de esos scopes.
Queremos que Keycloak emita un token cuyo aud (audiencia) sea precisamente https://example.com/mcp.

Para lograrlo, configuramos Keycloak así, repitiendo el patrón para cada scope:

Crea un client scope mcp:tools de tipo Optional y añádele un Audience mapper cuyo Included Custom Audience sea https://example.com/mcp.
Crea un client scope mcp:prompts de tipo Optional con su Audience mapper apuntando a https://example.com/mcp.
Crea un client scope mcp:resources de tipo Optional con su Audience mapper apuntando a https://example.com/mcp.

La clave es que el Included Custom Audience de cada client scope sea idéntico al valor del parámetro resource de la petición y a la URL del servidor MCP. Con esto, si el cliente pide un token con esos tres scopes, Keycloak emite algo como:

{
 "aud": "https://example.com/mcp",
 "scope": "mcp:resources mcp:tools mcp:prompts"
}

El servidor MCP ya puede comprobar el aud y rechazar cualquier token que no fuera para él. Hemos atado la credencial a su destinatario sin esperar a RFC 8707.

Si usas MCP Inspector

MCP Inspector es la herramienta oficial para depurar servidores MCP, y registra clientes dinámicamente contra Keycloak ejecutando JavaScript desde su backend. Para que funcione hay que ajustar CORS en las anonymous access policies del registro de clientes:

Allowed Client Scopes: incluir los scopes que soporta tu servidor MCP.
Allowed Registration Web Origins: incluir el origen web del backend de MCP Inspector.
Trusted Hosts: incluir el host o IP de la máquina que envía la petición de registro dinámico, es decir, donde corre tu navegador.

Para MCP 2025-11-25: registro de clientes con Client ID Metadata Document

La última versión añade un capítulo nuevo: cómo se registran los clientes. Contempla tres enfoques, y eliges según tu escenario:

Client ID Metadata Documents: cuando cliente y servidor no se conocen de antes (el caso más común).
Pre-registro: cuando ya existe una relación previa.
Dynamic Client Registration: para compatibilidad hacia atrás o requisitos concretos.

Keycloak soporta el primero, OAuth Client ID Metadata Document (CIMD), aunque conviene saber que es una función experimental: puede traer cambios incompatibles en versiones futuras. Para activarla, arranca Keycloak con el flag:

bin/kc.sh start --features=cimd

La idea de CIMD es que el client_id deja de ser un identificador opaco y pasa a ser una URL que apunta a un documento con los metadatos del cliente. Keycloak descarga ese documento y procesa la petición con lo que encuentre. Para que lo haga, hay que crear un client policy profile y una policy que lo disparen.

Perfil (profile). En Realm Settings → Client Policies → Profiles, crea un perfil (p. ej. cimd-profile), añade el ejecutor client-id-metadata-document y configúralo:

Allow http scheme: permite http para las URLs (client_id, client_uri, logo_uri, jwks_uri, etc.). Solo en desarrollo; en producción OFF.
Trusted domains: patrones con comodín de dominios aceptados (p. ej. *.example.org). Si está vacío, se deniegan todos.
Restrict same domain: si está ON, exige que el client_id URL, el redirect_uri y las URLs de los metadatos estén todos bajo el mismo dominio de confianza.
Required properties: propiedades que el documento de metadatos debe incluir obligatoriamente.
Only Allow Confidential Client: si está ON, solo acepta clientes confidenciales (con jwks/jwks_uri y autenticación private_key_jwt o tls_client_auth).

Política (policy). En Realm Settings → Client Policies → Policies, crea una policy (p. ej. cimd-policy), añade la condición client-id-uri y configúrala:

URI scheme: esquemas a reconocer en el client_id (en producción, solo https).
Trusted domains: dominios aceptados en el host del client_id. Si se rellenan, la condición solo es verdadera cuando el host coincide; si se dejan vacíos, es siempre falsa.

Luego asocia el cimd-profile a esta policy. A partir de ahí, cuando llegue una petición con un client_id que sea una URL https de un dominio de confianza, Keycloak descarga el documento de metadatos y lo usa para procesar la petición.

Ajustes globales del ejecutor. Algunos parámetros no están en la consola y se pasan como opciones SPI al arrancar:

min-cache-time: tiempo mínimo de caché del documento (por defecto 300 s).
max-cache-time: tiempo máximo de caché (por defecto 259200 s, 3 días).
upper-limit-metadata-bytes: tamaño máximo del documento (por defecto 5000 bytes).

bin/kc.sh start \
 --spi-client-policy-executor--client-id-metadata-document--min-cache-time=600 \
 --spi-client-policy-executor--client-id-metadata-document--max-cache-time=86400 \
 --spi-client-policy-executor--client-id-metadata-document--upper-limit-metadata-bytes=10000

Caso real: VS Code desktop como cliente MCP

Visual Studio Code es un cliente MCP que usa CIMD. Cuando se conecta a un servidor MCP que requiere autorización, manda un client_id que es una URL https alojada en vscode.dev (p. ej. https://vscode.dev/mcp-client), y Keycloak descarga de ahí sus metadatos. El detalle a tener en cuenta es que VS Code es un cliente público que usa PKCE (sin secreto de cliente) y, para el callback de OAuth, levanta un servidor local con un redirect_uri tipo http://127.0.0.1:<puerto>/callback. Como ese redirect no está en el dominio de vscode.dev, hay que dejar Restrict same domain en OFF.

Arranca con --features=cimd y configura:

Perfil vscode-cimd-profile (ejecutor client-id-metadata-document):

Allow http scheme: OFF
Trusted domains: vscode.dev, 127.0.0.1
Restrict same domain: OFF (el redirect es un localhost, no vscode.dev)
Only Allow Confidential Client: OFF (VS Code es público)

Política vscode-cimd-policy (condición client-id-uri):

URI scheme: https
Trusted domains: vscode.dev
Asocia el perfil vscode-cimd-profile.

Con esto, cuando VS Code lance la petición, Keycloak reconoce el client_id como una URL de vscode.dev, descarga el Client ID Metadata Document y completa el flujo OAuth con el callback en localhost.

La educación continúa

Hemos enseñado a nuestro MCP a identificarse y a pedir permiso de forma estándar, reutilizando la identidad que ya gobierna Keycloak en el resto de la casa. No es poca cosa: con un token bien atado a su audiencia, lo demás empieza a ser posible.

Pero, como con cualquier hijo que crece, esto no termina aquí. Quedan pendientes las otras dos asignaturas que mencionábamos al principio —separar a los inquilinos (multitenancy) y controlar lo que gasta (costes)— y a Keycloak todavía le falta madurar en algún punto, como el soporte nativo de Resource Indicators. Iremos cubriéndolas en próximos artículos. Por ahora, nuestro MCP ya sabe decir quién es. Y eso, en seguridad, es el primer día de colegio.