Una revisión de riesgos, controles y desafíos emergentes en entornos OT/ICS
Por Pablo G. M. Bobadilla— CTL
Escribo esto desde el lugar de quien tiene que decidir, en tiempo real, si una alerta generada por un sistema de IA amerita frenar una línea de producción. No desde la torre de un paper académico. Y esa distancia entre la literatura y la sala de operaciones es, justamente, el motivo de este artículo.
La incorporación de inteligencia artificial en entornos de Operational Technology (OT) abre posibilidades reales para la monitorización, el análisis y la automatización de procesos industriales. También trae componentes tecnológicos y superficies de ataque nuevas, que los modelos tradicionales de ciberseguridad OT todavía no contemplan del todo.
Esto dejó de ser una discusión de laboratorio. En abril de 2026, NIST abrió el desarrollo de un perfil específico del AI Risk Management Framework (AI RMF) para infraestructura crítica, con alcance explícito sobre IT, OT e ICS. Cinco meses antes, en diciembre de 2025, CISA, la NSA, el FBI y agencias de ciberseguridad de seis países aliados habían publicado principios conjuntos para integrar IA en OT de forma segura. Dos frentes institucionales distintos llegando, casi al mismo tiempo, a la misma pregunta.
Este artículo revisa esa convergencia entre AI Security y OT Security a partir de documentación institucional y literatura reciente, con foco en sistemas basados en modelos de lenguaje y en agentes de IA.
Nota metodológica: distingo tres niveles de certeza a lo largo del texto — hecho documentado (hay una fuente que lo respalda directamente), interpretación (una relación que establezco yo entre dos fuentes) y propuesta (una idea que no forma parte todavía de ningún estándar). No repito esta aclaración en cada sección; si algo se presenta como propuesta o interpretación quedará claro por el verbo y el contexto.
1. Por qué esto ya no es prospectiva
Operational Technology comprende sistemas y dispositivos programables que interactúan con el entorno físico o lo controlan. NIST SP 800-82 Rev. 3 es explícito en que la seguridad OT exige requisitos de rendimiento, fiabilidad y seguridad funcional distintos a los de IT convencional.
La IA agrega una variable que ese marco no fue diseñado para absorber. Puede analizar información, detectar anomalías, generar recomendaciones o automatizar funciones — pero cuando se integra con componentes OT, la superficie de análisis deja de ser el modelo y pasa a ser el sistema completo: los datos que lo alimentan, las interfaces que expone, la identidad con la que actúa, las herramientas que puede invocar y las consecuencias físicas de lo que decide.
El documento de concepto de NIST de abril de 2026 lo confirma con los ejemplos que elige tratar: agentes de IA para respuesta autónoma ante incidentes, sistemas de monitorización de plantas, digital twins, robots y vehículos autónomos, sistemas de optimización que puedan degradarse de forma controlada. No es IA como herramienta de análisis pasivo — es IA participando en la decisión y en la acción.
2. Lo que ya dicen los organismos internacionales
En diciembre de 2025, CISA y la Australian Signals Directorate, junto con NSA, FBI, Canadian Centre for Cyber Security, BSI, y los NCSC de Países Bajos, Nueva Zelanda y Reino Unido, publicaron Principles for the Secure Integration of Artificial Intelligence in Operational Technology. Cuatro principios: entender la IA y sus riesgos, evaluar su uso dentro del dominio OT, establecer gobierno y aseguramiento, e incorporar prácticas de safety y security tanto en la IA como en los sistemas OT que la usan.
Lo más útil del documento, para quien trabaja en un SOC industrial, no es la lista de principios sino las recomendaciones concretas: usar infraestructura de prueba antes de desplegar, preferir arquitecturas push-based para evitar acceso persistente de la IA hacia OT, mantener fail-safes, limitar el control activo de infraestructura OT por IA sin supervisión humana, monitorizar los componentes de IA y registrar entradas y salidas. La guía también es tajante en un punto que cualquier analista OT va a compartir: los sistemas basados en LLM no deberían tomar decisiones de seguridad funcional.
3. De la seguridad del modelo a la seguridad del sistema
Analizar solamente el modelo de IA es insuficiente cuando ese modelo está integrado en OT. La cadena real de dependencias va del modelo a los datos, de los datos al contexto de ejecución, de ahí a la identidad con la que el agente actúa, a las herramientas y APIs que puede invocar, a la red, a los activos OT y finalmente al proceso físico.
Una vulnerabilidad en cualquier eslabón de esa cadena cambia el riesgo del conjunto. Esto es consistente con la evolución reciente de MITRE ATLAS: en mayo de 2026, el proyecto Secure AI del Center for Threat-Informed Defense reportó la incorporación de más de 45 nuevas técnicas y sub-técnicas, más de 10 mitigaciones y más de 20 casos de estudio, casi todos orientados a sistemas agentic y no a modelos aislados. El objeto de análisis se está corriendo de «seguridad del modelo» a «seguridad del sistema habilitado por IA» — y en OT esa distinción no es un matiz teórico, es la diferencia entre auditar un algoritmo y auditar una planta.
4. El problema de la autonomía
No es lo mismo un sistema que solo genera una recomendación que uno que ejecuta directamente sobre un PLC. La guía CISA/NSA es explícita en recomendar que se limite el control activo de infraestructura OT por IA sin supervisión humana, en buena parte por latencia y por seguridad funcional.
Conviene pensarlo como una escalera de cuatro escalones, donde la autoridad operacional del sistema crece a la par de la necesidad de supervisión:
Observación → la IA analiza. Recomendación → la IA propone. Ejecución supervisada → la IA propone y una persona autoriza. Ejecución autónoma → la IA determina y ejecuta. Cuanto más arriba en esa escalera, más caro sale un error de diseño en los mecanismos de validación y control — y en una planta de celulosa o de consumo masivo, «caro» puede significar una parada no programada, no solo un incidente de seguridad.
5. Trayectoria, no solo acción
Un trabajo publicado en agosto de 2026 por Lotfi, Karmaker Shanto, Karim y Bertino introduce el concepto de trajectory assurance para sistemas agentic: verificar cada acción de forma aislada puede no alcanzar, porque una secuencia de acciones individualmente aceptables puede violar colectivamente una restricción del sistema.
Para OT esto cambia la pregunta que le hacemos a un control. Ya no alcanza con «¿está autorizada esta acción?» — hace falta preguntar si la secuencia que llevó hasta acá, y la que sigue, se mantiene dentro de las restricciones del proceso. El paper no propone un mecanismo específico para OT, así que no corresponde presentarlo como una solución ya aplicable — es una línea de investigación a seguir, no una arquitectura de referencia.
Un antecedente más concreto en esta dirección es el trabajo de Ogunmolu, Olaniyi, Ejoh y colegas (marzo de 2026), que propone y evalúa cuantitativamente una arquitectura secure-by-containment para IA agentic en OT/ICS: contención como propiedad arquitectónica de primer orden, que limita estructuralmente la autoridad de decisión y el alcance operacional de un agente. Es, hasta donde puedo verificar, uno de los pocos intentos con evaluación cuantitativa aplicados directamente al dominio OT/ICS.
6. La brecha que todavía no se cierra
Hay tres líneas de desarrollo avanzando en paralelo: NIST construyendo gestión de riesgo específica para IA en infraestructura crítica, NIST SP 800-82 en revisión para OT, y MITRE ATLAS ampliando cobertura de amenazas de IA. El problema es que evolucionan desde puntos de partida distintos, y todavía no hay evidencia de que se hayan cruzado lo suficiente.
La pregunta de investigación que me parece más honesta no es si existe una brecha — es cuánto cubren, en conjunto, los controles de AI Security y OT Security hoy disponibles, frente a un agente que puede leer un historian, escribir en un HMI o abrir una sesión PRA sin que haya un humano mirando en tiempo real.
| Dimensión | AI Security | OT Security | Punto de análisis |
| Identidad | Sí | Sí | Identidad del agente y autoridad |
| Datos | Sí | Sí | Calidad, integridad, procedencia |
| Modelo | Sí | — | Validación del modelo |
| Herramientas/APIs | Sí | Sí | Control de capacidades |
| Activos OT | — | Sí | Criticidad y función |
| Estado del proceso | — | Sí | Contexto operacional |
| Comportamiento del agente | Sí | — | Trayectoria y restricciones |
| Safety | Parcial | Sí | Impacto sobre funciones críticas |
| Supervisión humana | Sí | Sí | Decisiones y acciones |
| Impacto ciberfísico | Parcial | Sí | Evaluación conjunta |
Esta tabla es una herramienta de trabajo que propongo para este artículo, no una taxonomía oficial de ningún organismo. La comparto igual porque me sirvió para ordenar dónde un SOC OT ya tiene cobertura y dónde no.
7. Limitaciones
El perfil de NIST para infraestructura crítica sigue en desarrollo, así que nada de lo que dice hoy debería tomarse como requisito definitivo — puede cambiar en la versión final. En el mismo sentido, buena parte de la literatura sobre agentic AI citada acá es de 2026 y todavía no pasó por una validación o replicación independiente amplia.
Tampoco puedo afirmar que todo sistema de IA integrado en OT presente el mismo nivel de riesgo: depende de la arquitectura concreta, el activo, el proceso y los permisos otorgados — y esta revisión es documental, no una evaluación sobre una planta real.
8. Para quien trabaja en un SOC industrial hoy
La IA ya está entrando en infraestructura crítica, y su seguridad ya es un tema reconocido por NIST, CISA, NSA y las agencias que las acompañan. Lo que todavía no existe es un framework único que integre AI Security y OT Security de punta a punta — lo que hay es una convergencia en marcha, con piezas sueltas que un equipo de detección tiene que empezar a ensamblar por su cuenta.
En la práctica, esto amplía lo que un analista OT necesita entender: ya no alcanza con redes, endpoints y vulnerabilidades tradicionales. Cuando un agente de IA entra al entorno operacional, hace falta comprender también su modelo de amenaza, su identidad, sus herramientas, y sobre todo los límites de autonomía que tiene — o que no debería tener — sobre el proceso físico.
Referencias
National Institute of Standards and Technology. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1.
National Institute of Standards and Technology. (2026). Concept Note: AI RMF Profile on Trustworthy AI in Critical Infrastructure.
Stouffer, K. A., Pease, M., Tang, C., Zimmerman, T., Pillitteri, V. Y., Lightman, S., Hahn, A., Saravia, S., Sherule, A., & Thompson, M. (2023). Guide to Operational Technology (OT) Security (NIST SP 800-82 Rev. 3). NIST.
Cybersecurity and Infrastructure Security Agency, National Security Agency, Federal Bureau of Investigation, Australian Signals Directorate’s ACSC, Canadian Centre for Cyber Security, BSI, NCSC-NL, NCSC-NZ, NCSC-UK. (2025). Principles for the Secure Integration of Artificial Intelligence in Operational Technology.
Center for Threat-Informed Defense. (2026). MITRE ATLAS Grows through Collaboration with CTID and Industry.
Lotfi, A., Karmaker Shanto, S., Karim, I., & Bertino, E. (2026). Securing Agentic AI: From Per-Action Checks to Trajectory Assurance. arXiv:2608.01558.
Ogunmolu, A. M., Olaniyi, O. M., Ejoh, C. I., Balogun, A. Y., & Oyekunle, S. M. (2026). Secure-by-Containment Architectures for Agentic AI in OT/ICS Environments. Asian Journal of Research in Computer Science, 19(3), 1–23.