En diciembre de 2025, CISA publicó junto con la NSA, el FBI y agencias de ciberseguridad de siete países la guía «Principles for the Secure Integration of Artificial Intelligence in Operational Technology». Que nueve organismos internacionales se coordinen para advertir sobre los riesgos de la IA en entornos industriales debería ser suficiente señal de alarma para cualquier equipo SOC que proteja infraestructura crítica.

Este artículo no pretende ser una introducción genérica a la IA ni un ejercicio teórico. Lo que sigue es un análisis de los vectores de ataque que emergen cuando la IA entra en el loop industrial, los desafíos reales que esto representa y las estrategias concretas, que los equipos de seguridad pueden implementar ahora mismo.

El contexto: porqué esto ya no es futuro.

Los entornos OT llevan décadas operando bajo un principio comprensible: si funciona, no se toca. Un PLC con firmware de 2003 se mantiene porque el proveedor no ofrece actualizaciones certificadas para el proceso. Una HMI con Windows XP embebido sigue operativa porque nadie quiere asumir el riesgo de migrar durante producción. Es una filosofía conservadora que tiene sentido desde la continuidad operacional, pero que choca contra la presión de la Industria 4.0.

Los datos respaldan esta presión. Según el informe SANS 2024 ICS/OT Cybersecurity, el 19% de las organizaciones industriales reportaron al menos un incidente de seguridad en el último año. Un estudio de Rockwell Automation y SANS encontró que el 49% de los líderes del sector manufacturero planean incorporar IA y machine learning para ciberseguridad en los próximos 12 meses. La adopción no es opcional: se estima que el downtime no planificado cuesta a la manufactura industrial aproximadamente 50.000 millones de dólares al año, y según un informe de Siemens de 2024, una hora de parada puede costar entre 36.000 dólares en bienes de consumo rápido y 2,3 millones de dólares en el sector automotriz.

Las aplicaciones concretas que están entrando en producción incluyen:

El mantenimiento predictivo es probablemente el caso de uso más extendido. Modelos de ML que analizan vibraciones, temperaturas y presiones para anticipar fallos en motores, bombas y compresores. Los datos de industria sitúan la reducción de downtime no planificado entre un 30% y un 50% según la implementación, con fuentes como Gartner (2024) reportando reducciones de hasta 30% y McKinsey indicando que en logística y transporte se alcanza hasta el 50%.

La optimización de proceso en tiempo real es otro vector creciente. Algoritmos de control adaptativo que ajustan parámetros de producción (velocidad de línea, temperatura de cocción, dosificación química) para maximizar eficiencia y calidad. En industrias, donde el control preciso de variables, la temperatura de digestores y la velocidad de formación es crítico, estos sistemas se están volviendo parte del proceso productivo central.

Y hay más: detección de anomalías de proceso, integración con digital twins, sistemas de visión por computadora para control de calidad. Todos legítimos, todos con ROI demostrable. El problema no es la tecnología. El problema es que esta integración se está realizando mayoritariamente sin un marco de seguridad específico para IA en OT.

He visto servidores de inferencia desplegados en redes de nivel 2 con acceso a datos de proceso en tiempo real y conectividad directa hacia redes corporativas para sincronización de modelos. He visto modelos de ML cuya última auditoría de seguridad fue «ninguna, porque el proveedor dijo que estaba todo bien». La brecha entre la velocidad de adopción y la madurez de seguridad es real, medible, y probablemente el mayor riesgo silencioso del sector industrial hoy.

La superficie de ataque:lo que cambia cuando hay IA en el Loop

El modelo de IA como activo crítico no reconocido.

Antes de la IA, los activos críticos en OT eran claros: PLCs, DCS, RTUs, HMIs. Los equipos de seguridad sabían qué proteger. Con la incorporación de sistemas de IA aparece una nueva categoría de activo que los frameworks tradicionales no contemplan adecuadamente: el modelo de machine learning y su infraestructura.

Un modelo de ML que controla la dosificación de químicos en un proceso de blanqueo o que ajusta la presión en un sistema de vapor no es solo un archivo. Es lógica de control que puede ser manipulada, corrompida o robada. Y, a diferencia de un PLC cuya lógica está en ladder diagram y es auditada por ingenieros de proceso, la lógica de un modelo de ML es opaca, estadística y difícilmente verificable por operadores tradicionales.

La guía CISA de diciembre 2025 lo dice sin rodeos: la IA introduce riesgos «fundamentally different from traditional automation», incluyendo manipulación de modelos, envenenamiento de datos, prompt injection, problemas de calidad de datos, model drift y limitaciones de explicabilidad que complican las auditorías y el análisis de incidentes.

La superficie de ataque expandida incluye los datos de entrenamiento (si un atacante contamina los datos históricos de proceso, puede envenenar el comportamiento futuro del modelo sin necesidad de acceder al sistema en producción), el pipeline de inferencia completo desde sensores hasta actuación, las APIs de comunicación (los modelos en OT frecuentemente exponen endpoints REST o utilizan OPC-UA para intercambiar datos con el SCADA), y la infraestructura de modelo (servidores de inferencia, bases de datos de series temporales como OSIsoft PI o InfluxDB, y sistemas de MLOps).

Vectores de ataque: lo documentado vs. lo teórico.

Voy a ser directo en algo que considero importante para la credibilidad de este artículo: hay que separar con claridad lo que ya ha ocurrido en el mundo real de lo que es técnicamente viable pero aún no se ha documentado públicamente en entornos industriales. Mezclar ambos sin distinción es un error que he visto en demasiadas publicaciones del sector.

Data Poisoning — Técnicamente demostrado, no documentado públicamente en OT

El envenenamiento de datos contra modelos de ML es un campo de investigación con más de una década de trabajo académico riguroso. Biggio y Roli documentaron extensamente los fundamentos teóricos y prácticos en su paper de referencia «Wild Patterns: Ten Years After the Rise of Adversarial Machine Learning» (Pattern Recognition, Vol. 84, 2018), cubriendo ataques de poisoning tanto en tiempo de entrenamiento como de evasión en test. Biggio, Nelson y Laskov demostraron ataques de poisoning funcionales contra SVMs ya en 2012. MITRE ATLAS, el framework dedicado a amenazas contra sistemas AI/ML, incluye data poisoning como técnica documentada con casos de estudio reales en otros dominios.

En el contexto OT, el escenario teórico es particularmente preocupante: los modelos de mantenimiento predictivo se entrenan con meses o años de datos históricos de sensores. Un atacante con acceso persistente a la red OT (post-compromiso de un activo en nivel 2 o 3) podría inyectar lecturas de sensores sutilmente modificadas durante el período de entrenamiento, haciendo que el modelo aprenda que ciertas condiciones anómalas son «normales». Hablo de modificaciones dentro del rango de ruido de sensor normal que no generarían alertas en sistemas SCADA (los umbrales de alarma siguen siendo los mismos), no dejarían trazas en logs de red convencionales, y cuyo efecto se manifestaría meses después del compromiso inicial.

No conozco un caso público donde esto haya ocurrido en una planta industrial. Pero la viabilidad técnica está documentada, el acceso persistente a redes OT es un hecho comprobado (Dragos reporta en su OT Cybersecurity Year in Review 2025 que el 45% de sus engagements de servicio encuentran falta de visibilidad en redes OT), y la guía CISA de diciembre 2025 lista explícitamente data poisoning como amenaza credible para AI en OT.

Adversarial Attacks — Documentados en laboratorio, emergentes en campo.

Los ataques adversariales contra modelos de visión son una realidad demostrada desde el trabajo seminal de Goodfellow, Shlens y Szegedy en 2014 (ICLR 2015) y extensamente validados por Carlini y Wagner en 2017 (IEEE S&P). MITRE ATLAS documentó en noviembre de 2025 un caso de estudio real de ataques deepfake contra sistemas de KYC (Know Your Customer) con detección de vivacidad en banca.

En entornos de manufactura, los sistemas de visión para control de calidad y detección de defectos son objetivos lógicos. Un sistema de visión que detecta defectos en papel podría ser engañado para no reportar rasgaduras o manchas. No tengo evidencia de que esto haya ocurrido, pero la técnica está validada y el incentivo económico existe.

Model Extraction — Documentado en el mundo real, incluso entre empresas

Este vector sí tiene precedente público. En enero de 2025, OpenAI identificó evidencia de que DeepSeek usó outputs de GPT-3 y GPT-4 para entrenar un modelo competidor mediante consultas sistemáticas a la API (Financial Times, 29 de enero de 2025). El caso demostró que la extracción de modelo por consultas repetidas no es solo teoría: es una práctica que ha generado consecuencias legales reales.

En entornos industriales, los modelos de optimización de proceso representan años de ingeniería, datos propietarios y ventaja competitiva. Actores con motivación de espionaje industrial tienen incentivos claros para este tipo de exfiltración. Esto es especialmente relevante en sectores concentrados como celulosa y papel, donde pocas empresas dominan el mercado global.

Prompt Injection en LLMs Operacionales — Riesgo emergente y reconocido oficialmente

La tendencia a desplegar LLMs como interfaces de consulta para operadores de planta es real y creciente. La guía CISA de diciembre 2025 menciona explícitamente prompt injection como riesgo para AI en OT. En diciembre de 2024, investigadores demostraron prompt injection contra la función de búsqueda de ChatGPT mediante texto oculto embebido en páginas web (The Guardian, 24 de diciembre de 2024).

Un sistema donde un operador consulta el estado de la línea de producción y recibe respuestas generadas por un LLM alimentado con datos de proceso en tiempo real es vulnerable a manipulación si un atacante logra modificar los datos que forman el contexto del modelo. La diferencia con prompt injection en entornos IT es que aquí la decisión manipulada puede afectar un proceso físico.

Incidentes reales en OT: El contexto de amenaza actual

Para entender por qué la seguridad de IA en OT no es un ejercicio académico, conviene mirar lo que ya está ocurriendo en el espacio de amenazas OT general:

En enero de 2024, atacantes desplegaron FrostyGoop, un malware ICS que ataca dispositivos Modbus TCP, contra una empresa de energía distrital en Ucrania. El resultado fue la pérdida de calefacción en más de 600 edificios de apartamentos durante temperaturas bajo cero, afectando directamente la seguridad física de miles de personas. Dragos asoció este ataque con la manipulación de controladores ENCO mediante el envío de comandos no autorizados.

El grupo hacktivista Z-Pentest emergió como el actor más activo contra sistemas OT durante 2024-2025, realizando intrusiones repetidas en un amplio espectro de tecnologías industriales según el análisis de Cyble. En el mismo período, Cyble documentó 2.451 vulnerabilidades específicas de ICS reveladas por 152 vendors entre diciembre de 2024 y noviembre de 2025.

Honeywell reportó que solo en el primer trimestre de 2025 hubo más de 2.400 ataques de ransomware contra el sector manufacturero, con la capa OT como objetivo principal, una tendencia agresiva considerando que en todo 2024 se registraron 6.130 incidentes de este tipo.

Estos datos muestran que los atacantes ya tienen presencia en redes OT. Cuando los modelos de IA se desplieguen masivamente en estas mismas redes, serán objetivos naturales.

Los desafíos reales: Lo que hace diferente a OT

No puedes parchear lo que no puedes parar.

El principal mecanismo de respuesta ante vulnerabilidades en IT (aplicar parches) es frecuentemente inviable en OT. Los servidores que alojan modelos de ML heredan las restricciones del entorno: ventanas de mantenimiento anuales, validación de proveedor para cualquier cambio de software, y sistemas operativos que no pueden actualizarse sin recertificación del proceso.

Un servidor de inferencia corriendo Python 3.8 con TensorFlow 2.3 y una vulnerabilidad conocida en su API de serving puede permanecer así durante 18 meses esperando el próximo shutdown programado. Esto no es negligencia. Es la realidad operacional de un entorno donde una actualización mal ejecutada puede parar una línea de producción que genera cientos de miles de dólares por hora. La guía CISA de diciembre 2025 reconoce este problema y recomienda específicamente que los sistemas de IA en OT incluyan estados de fallo documentados y la capacidad de desactivar o bypass la IA rápidamente, permitiendo la reversión a control manual o determinístico.

Puntos ciegos en la detección

La mayoría de las plataformas de seguridad OT (incluyendo TXOne Networks, Claroty y Nozomi Networks) están diseñadas para detectar amenazas basadas en comportamiento de red y protocolos industriales. Tienen capacidad limitada para identificar manipulación de modelos de ML o anomalías en pipelines de inferencia, porque estos patrones simplemente no existían cuando se diseñaron sus motores de detección.

El resultado práctico: un equipo SOC puede ver que un servidor de ML se comunica con el historian de proceso, pero no puede determinar si los datos que fluyen están siendo manipulados. El SIEM registra conexiones y eventos de red, pero no tiene contexto sobre si las predicciones del modelo son coherentes con el estado real del proceso.

Dragos señaló en su Year in Review 2025 que el 45% de los engagements de servicio presentan falta de visibilidad en redes OT. Si la visibilidad ya es deficiente para activos OT tradicionales, para sistemas de IA es prácticamente inexistente en la mayoría de las organizaciones.

Tres mundos, un problema

La seguridad de IA en OT requiere la colaboración de tres disciplinas que históricamente operan en silos: ingenieros de proceso (entienden qué hace el modelo pero no las amenazas de seguridad), equipos IT/SOC (entienden seguridad pero no los constraints operacionales ni los modelos de ML), y data scientists/MLOps (entienden los modelos pero no el threat landscape industrial). Esta brecha tiene consecuencias prácticas.

La guía CISA de diciembre 2025 aborda esto directamente con su primer principio («Understand AI»), insistiendo en que todo el personal involucrado en OT necesita educación sobre los riesgos específicos de la IA, su ciclo de vida y sus modos de fallo. No es suficiente con que el data scientist entienda la IA o con que el SOC entienda la seguridad. Todos necesitan entender ambos.

Estrategias Defensivas: Qué Puede Hacer Tu SOC Hoy

Inventariar lo que no sabes que tienes

El primer paso, y en mi experiencia el más descuidado, es saber qué sistemas de IA existen en el entorno OT. Este inventario debe incluir:

Un registro de modelos que documente qué modelos están en producción, su versión, los datos de entrenamiento utilizados y quién es el responsable técnico. Un mapeo de flujos de datos que identifique qué fuentes alimentan cada modelo (sensores, historians, SCADA) y qué sistemas consumen sus outputs. Una evaluación de dependencias de proceso: si el modelo falla o es manipulado, cuál es el impacto en producción y si existe fallback manual. Y un análisis de exposición de red: conectividad hacia redes IT, APIs expuestas, acceso remoto de proveedores.

La guía CISA recomienda además que los operadores exijan a sus vendors AI-specific SBOMs (Software Bill of Materials para IA) que documenten dependencias del modelo, fuentes de datos y mecanismos de actualización.

Este inventario debe alimentar directamente el CMDB y estar disponible para el equipo SOC como contexto crítico durante la gestión de incidentes. Si el analista SOC que investiga una alerta no sabe que el servidor origen es un servidor de inferencia de ML, no tiene posibilidad de contextualizar el evento correctamente.

Casos de Uso de detección específicos para AI

Los SOC necesitan desarrollar detecciones que vayan más allá del monitoreo de red convencional. Las señales que pueden indicar compromiso de un sistema AI industrial incluyen:

Anomalías en datos de entrada (Feature Drift): Monitorear las estadísticas de los datos que ingresan al modelo en tiempo real y compararlas con el baseline histórico. Una desviación significativa en la distribución de features puede indicar manipulación de sensores o data poisoning en curso. La guía CISA recomienda específicamente monitorear model drift como control continuo.

Anomalías en predicciones del modelo (Prediction Drift): Si un modelo que históricamente genera distribuciones estables comienza a producir outputs con distribución diferente sin cambios en el proceso, es una señal de alarma. Esto aplica tanto a modelos de mantenimiento predictivo como a sistemas de detección de anomalías.

Comportamiento anómalo del servidor de inferencia: Consultas a la API desde IPs no esperadas (posible model extraction), volumen inusualmente alto de requests (scraping sistemático), acceso al sistema de archivos del modelo desde procesos no autorizados, y conexiones de red hacia destinos externos.

Hardening de infraestructura AI en OT

Las siguientes medidas deben adaptarse al riesgo específico de cada implementación:

Segmentación de red. Los servidores de inferencia no deben tener conectividad directa hacia redes IT corporativas. La comunicación debe fluir a través de data diodes o firewalls con reglas explícitas y mínimo privilegio. En Palo Alto, esto implica zonas específicas para infraestructura AI con políticas App-ID que solo permitan los protocolos estrictamente necesarios (OPC-UA, REST API sobre HTTPS hacia destinos específicos). La guía CISA recomienda explícitamente arquitecturas push-based o unidireccionales para preservar la segmentación OT y minimizar las rutas de ataque.

Autenticación de modelo. Implementar checksums criptográficos de los archivos de modelo (.pkl, .h5, .onnx, .pt) y verificarlos en cada carga. Un cambio no autorizado en el archivo del modelo debe generar una alerta crítica.

Segregación de datos de entrenamiento. Los datos históricos utilizados para entrenamiento deben almacenarse en un sistema separado con controles de integridad, acceso auditado mediante PAM (BeyondTrust u otra solución equivalente) y versionado inmutable. Nunca deben ser modificables desde el entorno de producción.

Monitoreo de integridad de archivos. Aplicar FIM (File Integrity Monitoring) sobre los directorios que contienen modelos, configuraciones y scripts de inferencia. CrowdStrike Falcon puede configurarse para alertar sobre cualquier modificación en paths específicos.

Logging exhaustivo del pipeline. Cada predicción del modelo debe loguearse con timestamp, features de entrada (o hash de ellas), output generado y versión del modelo utilizado. Este log es crítico para análisis forense post-incidente y para detectar data poisoning retrospectivamente.

Threat Hunting adaptado al nuevo paradigma.

El threat hunting en este contexto requiere hipótesis que reflejen los vectores de ataque específicos de AI en OT:

Hipótesis 1: Model Extraction en curso. Un actor con acceso inicial a la red OT está realizando consultas sistemáticas a la API de inferencia para extraer el comportamiento del modelo. Buscar: Volumen anormalmente alto de requests a endpoints de inferencia desde un único origen, con patrones de input que varían sistemáticamente (lo que indicaría un grid search sobre el espacio de features). El caso OpenAI/DeepSeek demuestra que esta técnica es operacionalmente viable.

Hipótesis 2: Data Poisoning en pipeline de reentrenamiento. Un actor está inyectando datos anómalos en el flujo de telemetría de sensores para corromper el próximo ciclo de reentrenamiento del modelo. Buscar: Lecturas de sensores que presentan drift estadístico sutil pero sostenido, correlacionado con la ventana temporal de reentrenamiento. Comparar con datos de sensores físicos que no alimentan el modelo como grupo de control.

Hipótesis 3: Compromiso del servidor de MLOps. Un atacante comprometió el sistema de gestión del ciclo de vida del modelo y tiene capacidad para desplegar versiones modificadas. Buscar: Accesos al sistema MLOps fuera de ventanas de mantenimiento, deployments de nuevas versiones de modelo sin change request asociado, modificaciones en pipelines de CI/CD.

4.5 Playbook de Respuesta: sospecha de manipulación de Modelo AI

Fase 1 — Detección y Triaje (0-30 minutos)

  1. Identificar el modelo afectado y su criticidad para el proceso productivo.
  2. Revisar logs del servidor de inferencia: accesos recientes, cambios en archivos, anomalías de red.
  3. Comparar checksum actual del modelo con el valor registrado en el inventario.
  4. Notificar al ingeniero de proceso responsable para evaluación de impacto operacional.
  5. Si hay evidencia de manipulación activa: escalar a incidente P1 e involucrar al equipo OT.

Fase 2 — Contención (30-120 minutos)

  1. Aislar el servidor de inferencia de la red sin interrumpir el proceso si existe fallback manual. CRÍTICO: coordinar con operaciones antes de cualquier acción que afecte el proceso. La guía CISA insiste en que los operadores deben retener la capacidad de revertir a control manual o determinístico.
  2. Redirigir el flujo de control al sistema fallback (control manual o lógica de proceso primaria en PLC/DCS).
  3. Preservar evidencia forense: snapshot del sistema, copia de logs, imagen del modelo afectado.
  4. Bloquear en firewall las conexiones hacia y desde el servidor comprometido.

Fase 3 — Erradicación y Recuperación

  1. Restaurar el modelo desde la última versión conocida buena (verificada por checksum).
  2. Revisar todos los datos de telemetría del período sospechoso para evaluar posible data poisoning.
  3. Si existe evidencia de envenenamiento de datos, reentrenar el modelo utilizando datos validados del período previo al compromiso.
  4. Realizar análisis de causa raíz del vector de acceso inicial.

Fase 4 — Post-Incidente

  1. Documentar TTPs observados y mapear a MITRE ATT&CK for ICS y MITRE ATLAS.
  2. Actualizar reglas de detección en SIEM y EDR.
  3. Comunicar lecciones aprendidas al equipo de ingeniería de proceso.
  4. Evaluar si el incidente requiere notificación regulatoria (NIS2 en la UE, regulaciones sectoriales locales).

El framework dual: MITRE ATT&CK for ICS + MITRE ATLAS

A group of four professionals in hard hats analyzing cyber threat models displayed in a high-tech control room. The screens feature diagrams related to MITRE ATT&CK for ICS and MITRE ATT&CK Atlas, with detailed interconnected flowcharts and information.

Un aspecto que considero que el sector industrial está pasando por alto es que existen dos frameworks de MITRE complementarios para modelar las amenazas en este espacio.

MITRE ATT&CK for ICS es el framework establecido para amenazas contra sistemas de control industrial. Modela las tácticas y técnicas que usan los atacantes para comprometer PLCs, SCADA, DCS y otros activos OT.

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) es el framework dedicado a amenazas contra sistemas AI/ML. A octubre de 2025, contiene 15 tácticas, 66 técnicas, 46 sub-técnicas, 26 mitigaciones y 33 casos de estudio reales. En octubre de 2025, MITRE ATLAS colaboró con Zenity Labs para integrar 14 nuevas técnicas y sub-técnicas enfocadas específicamente en agentes de IA y sistemas de IA generativa. MITRE también publicó el framework SAFE-AI, que mapea amenazas de ATLAS contra controles de NIST SP 800-53 para sistemas habilitados con IA.

Cuando se trata de IA en entornos industriales, el modelo de amenazas debe combinar ambos. Un atacante podría usar técnicas de ATT&CK for ICS para ganar acceso inicial a la red OT, y luego emplear técnicas de ATLAS para comprometer el modelo de ML. La siguiente tabla mapea esta intersección:

Vector de Ataque AITécnica ATT&CK for ICSTécnica MITRE ATLASTácticas Combinadas
Data Poisoning en sensoresT0830 (Modify Alarm Settings)AML.T0020 (Poison Training Data)Impair Process Control + ML Attack Staging
Model Extraction via APIT0882 (Theft of Operational Information)AML.T0024 (Exfiltration via ML Inference API)Collection + Exfiltration
Compromiso servidor MLOpsT0843 (Program Download)AML.T0010 (ML Supply Chain Compromise)Lateral Movement + Initial Access
Adversarial InputT0806 (Brute Force I/O)AML.T0015 (Evade ML Model)Impair Process Control + Defense Evasion
Prompt Injection en LLM OTT0831 (Manipulation of Control)AML.T0051 (LLM Prompt Injection)Impact + Initial Access
Robo de modelo desplegadoT0882 (Theft of Operational Information)AML.T0024.002 (Replicate via Query)Collection + Exfiltration

Este mapeo dual es, hasta donde he podido verificar, un enfoque que todavía no se ha formalizado en la comunidad de seguridad industrial. La ausencia de técnicas específicas para IA en ATT&CK for ICS es reveladora del estado de madurez del sector: estamos protegiendo PLCs y Modbus, pero los modelos de ML que influyen cada vez más en los procesos que esos PLCs controlan están fuera del radar de threat modeling.

El marco regulatorio: lo que ya es obligatorio y lo que viene

El contexto regulatorio está avanzando más rápido de lo que muchos equipos de seguridad industrial perciben:

CISA — Principles for the Secure Integration of AI in OT (diciembre 2025). Co-autoría de CISA, ASD ACSC (Australia), NSA AISC, FBI, BSI (Alemania), NCSC de UK, Países Bajos, Nueva Zelanda y Canadian Cyber Centre. Define cuatro principios: entender los riesgos de AI, evaluar el caso de uso en OT, establecer gobernanza de AI, e integrar seguridad y safety. No es legalmente vinculante, pero establece el estándar de due diligence.

AI Act de la UE. Vigente desde agosto de 2024 con aplicación gradual. Sistemas de IA usados en infraestructura crítica se clasifican como alto riesgo, requiriendo evaluación de conformidad, gestión de riesgos, y documentación técnica.

NIS2. Aplicable desde octubre de 2024 para operadores de servicios esenciales en la UE, incluyendo manufactura y energía. Exige gestión de riesgos de ciberseguridad que debería cubrir los sistemas de IA como parte de la infraestructura.

NIST SP 800-82. La Rev. 3 (septiembre de 2023) es la guía de referencia para seguridad OT. NIST ya inició el proceso de Rev. 4 (enero de 2026, con período de comentarios públicos abierto hasta febrero de 2026), que incorporará lecciones aprendidas y alineación con el CSF 2.0. La convergencia regulatoria entre IA y OT es un campo emergente que va a generar obligaciones concretas.

Hoja de ruta pragmática

Para organizaciones industriales que están incorporando IA en sus operaciones, esta es una hoja de ruta basada en madurez de seguridad:

Corto plazo (0-3 meses) — Ganar visibilidad

Completar inventario de todos los sistemas de AI/ML desplegados en entorno OT. Implementar checksum de integridad en archivos de modelos críticos. Configurar alertas básicas de acceso anómalo a servidores de inferencia en SIEM. Leer y distribuir internamente la guía CISA de diciembre de 2025.

Mediano plazo (3-12 meses) — Construir capacidad de detección

Desarrollar casos de uso de monitoreo de feature drift y prediction drift. Implementar PAM para acceso a infraestructura AI (gestión de sesiones, grabación de accesos). Documentar playbooks de respuesta a incidentes específicos para AI en OT. Realizar threat modeling específico para cada sistema de AI crítico usando MITRE ATT&CK for ICS y ATLAS como frameworks complementarios.

Largo plazo (12-24 meses) — Alcanzar madurez

Integrar AI Security en el proceso de gestión de cambios OT: cualquier despliegue de modelo requiere revisión de seguridad. Establecer prácticas de MLSecOps: seguridad integrada en el ciclo de vida del modelo. Desarrollar capacidades de red team específicas para AI (adversarial testing de modelos en producción, como recomienda la guía CISA). Exigir AI-SBOMs a vendors que desplieguen modelos en el entorno OT. Contribuir con inteligencia de amenazas al ecosistema (ISACs, CERTs nacionales).

Mi opinión sobre hacia dónde va esto

Voy a cerrar con algo más personal. Después de trabajar en la seguridad de entornos industriales donde conviven PLCs de 2003 con servidores de TensorFlow de 2024, tengo una visión que quizás sea impopular pero considero necesaria:

La mayoría de los vendors de seguridad OT están entre tres y cinco años detrás de la curva en lo que respecta a IA. Venden detección de anomalías de red industrial (que es necesaria, sin duda), pero no tienen capacidad para evaluar la integridad de un modelo de ML ni para detectar data poisoning en un pipeline de inferencia. La guía CISA de diciembre de 2025, con toda la coordinación internacional que involucró, es parcialmente un reconocimiento de que el ecosistema de seguridad OT no estaba preparado para esto.

El SOC del futuro industrial no puede ser un equipo que mira logs de Modbus y alertas de firewall. Necesita gente que entienda cómo funciona un random forest, qué significa que un modelo tenga drift, y por qué un cambio de 2% en la distribución de features de entrada puede ser más peligroso que un scan de puertos.

Eso no significa que todos los analistas SOC necesiten un doctorado en machine learning. Pero sí significa que los equipos de seguridad industrial necesitan incorporar perfiles con conocimiento de AI/ML, de la misma forma que hace diez años tuvieron que incorporar gente que entendiera protocolos industriales.

Los que se muevan primero en este espacio van a tener una ventaja significativa. Los que esperen a que el primer incidente público de manipulación de modelo de IA en una planta industrial llegue a las noticias probablemente estén reaccionando demasiado tarde.

Referencias y fuentes

Guías gubernamentales y estándares:

Frameworks de threat modeling:

Reportes de industria y threat intelligence:

  • SANS 2024 ICS/OT Cybersecurity Report — 19% de organizaciones con incidentes, 49% planean adoptar AI/ML para ciberseguridad.
  • Dragos — OT Cybersecurity Year in Review 2025. https://www.dragos.com/ot-cybersecurity-year-in-review — FrostyGoop, 45% de engagements con falta de visibilidad OT.
  • Cyble — Annual Threat Landscape Report 2025 — 2.451 vulnerabilidades ICS por 152 vendors, Z-Pentest como grupo hacktivista más activo contra OT.
  • Honeywell — Reporte Q1 2025: más de 2.400 ataques de ransomware contra manufactura en un trimestre.
  • Deloitte — Downtime no planificado cuesta $50 billion/año a manufactura industrial.
  • Siemens (2024) — Costo por hora de downtime: $36.000 (FMCG) a $2,3M (automotriz).
  • Gartner (2024) — Mantenimiento predictivo reduce downtime no planificado hasta 30%.
  • McKinsey — Mantenimiento predictivo reduce costos 10-40% y downtime hasta 50%.

Investigación académica:

  • Biggio, B. y Roli, F. (2018). Wild Patterns: Ten Years After the Rise of Adversarial Machine Learning. Pattern Recognition, Vol. 84, pp. 317-331.
  • Goodfellow, I., Shlens, J. y Szegedy, C. (2015). Explaining and Harnessing Adversarial Examples. ICLR 2015.
  • Carlini, N. y Wagner, D. (2017). Towards Evaluating the Robustness of Neural Networks. IEEE Symposium on Security and Privacy, pp. 39-57.

Incidentes citados:

  • OpenAI / DeepSeek — Model extraction via API queries (Financial Times, 29 enero 2025).
  • ChatGPT Search — Prompt injection via texto oculto en webpages (The Guardian, 24 diciembre 2024).
  • FrostyGoop — Malware ICS contra Modbus TCP en Ucrania, enero 2024 (Dragos).