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

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