Resumen ejecutivo

La convergencia de las Tecnologías de la Información (TI) y las Tecnologías de la Operación (TO) ha entrado en una nueva fase crítica con la integración de la Inteligencia Artificial (IA). Si bien la IA ofrece avances transformadores en mantenimiento predictivo, optimización de procesos y gestión de activos, también introduce riesgos sistémicos profundos cuando se implementa en Sistemas Ciberfísicos (CPS) deterministas y críticos para la seguridad sin las debidas salvaguardas.

Este artículo examina los riesgos estructurales, operativos, de gobernanza y de ciberseguridad asociados con el despliegue de plataformas de IA dentro de entornos industriales. Utilizando el perfil técnico público de arquitecturas de IA de frontera como Claude Mythos de Anthropic (presentada a principios de 2026), intentaremos distinguir entre las vulnerabilidades inherentes a cualquier modelo de IA operativo y los vectores de riesgo específicos introducidos por modelos de investigación de seguridad autónomos y agénticos capaces de generar exploits de forma automatizada. Para los propietarios de activos, directores de seguridad de la información (CISO) y gerentes de planta, navegar esta transición exige ir mucho más allá de los modelos de seguridad centrados en TI y establecer un enfoque de gobernanza de la IA industrial alineado con la ingeniería y basado en el principio de confianza cero (zero-trust).

La idea no es desincentivar el uso de la IA, sino comprender los riesgos para poder implementar una estrategia de mitigación que los aborde.

Por qué los entornos de TO son fundamentalmente diferentes de los de TI

El error fundamental que cometen los equipos de seguridad empresarial al implementar software moderno, incluida la IA, es tratar una instalación industrial como si fuera un centro de datos corporativo. Los parámetros operativos, las restricciones y las tolerancias al riesgo son diametralmente opuestos.

En un entorno de TI, un mal funcionamiento del software o un resultado inesperado provoca la caída de una aplicación, un proceso colgado o la corrupción de datos, lo que a menudo se puede resolver mediante un reinicio automatizado (¿ya lo apagó y lo volvió a encender?) o la restauración de una copia de seguridad. En un entorno de TO, un comportamiento inesperado en el Nivel 2 (Control) o el Nivel 1 (Detección/Actuación) del Modelo de Purdue puede llevar a un proceso físico más allá de sus límites operativos seguros. Esto podría traducirse en daños a los equipos, fallas físicas catastróficas o riesgos para la seguridad humana.

El creciente rol de la IA en las operaciones industriales

Los operadores industriales están aprovechando cada vez más la IA a través de dos vectores distintos:

• Motores de IA operativos: Desplegados dentro o de manera adyacente a los Sistemas de Ejecución de Manufactura (MES), Sistemas de Control Distribuido (DCS) e Historiadores de Datos para analizar flujos masivos de telemetría. Estas plataformas optimizan las relaciones de combustible-aire en turbinas, predicen fallas en válvulas y ajustan los niveles de dosificación química en tiempo real.

• Plataformas de IA agénticas de frontera (la disrupción de Mythos): Las arquitecturas de frontera como Claude Mythos de Anthropic representan una transición de la generación pasiva de texto al razonamiento autónomo y de múltiples pasos. Las capacidades documentadas públicamente de Mythos incluyen el descubrimiento autónomo de vulnerabilidades de día cero, el análisis de bases de código, la autocorrección recursiva y la capacidad de ejecutar código directamente mediante la integración de herramientas en entornos controlados (sandboxed).

Aunque plataformas como Mythos se crearon para la investigación de seguridad defensiva u ofensiva en TI, la capacidad subyacente que utiliza modelos de lenguaje grande (LLM) para leer código, formular hipótesis operativas e interactuar directamente con las herramientas del sistema, señala una realidad en la que el análisis de código autónomo puede (teóricamente) dirigirse al software industrial heredado, al firmware del fabricante y a la lógica de los PLC.

Riesgos operativos clave al introducir IA en TO

Pérdida de operaciones deterministas

Los Sistemas de Control Industrial (ICS) dependen de un comportamiento determinista: para un conjunto dado de entradas, un controlador lógico programable (PLC) o un sistema instrumentado de seguridad (SIS) debe ejecutar la misma secuencia matemáticamente predecible dentro de una ventana de tiempo estricta, que a menudo se mide en milisegundos.

Los modelos de IA, particularmente las redes neuronales y los LLM, son inherentemente estocásticos y operan con base en pesos probabilísticos. Introducir un motor de IA en el lazo de decisión o permitirle escribir configuraciones directamente en los dispositivos de campo elimina el determinismo, sustituyendo la lógica de control predecible por resultados algorítmicos variables y no repetibles.

Implicaciones de seguridad

Si una plataforma de IA se integra en un lazo de control (ya sea directamente o a través de una estación de trabajo de ingeniería mal aislada), un caso límite algorítmico puede desencadenar incidentes de seguridad física que podrían salirse de control en poco tiempo. A diferencia de los algoritmos tradicionales de control de procesos avanzado (APC), que operan dentro de matrices matemáticas estrictamente acotadas, los modelos de aprendizaje profundo pueden generar comandos anómalos inesperados cuando se exponen a telemetría operativa inédita (datos fuera de distribución).

Recomendaciones incorrectas que afectan la producción

Incluso cuando se limitan a un rol de asesoría (con intervención humana o "human-in-the-loop"), las herramientas de IA pueden malinterpretar la deriva de los sensores, los errores de calibración o las perturbaciones inusuales del proceso como operaciones normales u oportunidades de optimización estándar. Un ingeniero que ejecute una recomendación no validada de una IA con respecto a ajustes de puntos de consigna (setpoints) puede inducir condiciones de parada en compresores, estrés térmico en torres de fraccionamiento o sobrepresurización en tuberías.

Excesiva dependencia humana (sesgo de automatización)

A medida que las plataformas de IA alcanzan altos niveles de precisión base, los operadores de las salas de control y los ingenieros de planta caen víctimas del sesgo de automatización: la tendencia a confiar ciegamente en las sugerencias automatizadas por encima de la conciencia situacional humana. Con el tiempo, esto erosiona la experiencia interna para la resolución de problemas. Cuando la IA se topa con una excepción de proceso inusual y ofrece un consejo catastrófico, es posible que los operadores carezcan del contexto inmediato o de la confianza para anular el sistema.

Riesgos para la integridad del proceso

Los procesos industriales requieren un cumplimiento estricto del equilibrio químico, térmico y mecánico. Pequeños ajustes en una sola variable repercuten en cascada en múltiples operaciones unitarias. Dado que las plataformas de IA generales carecen de una comprensión intrínseca de la física, la termodinámica y la dinámica de fluidos, sus recomendaciones de optimización se derivan de correlaciones de datos en lugar de leyes físicas, lo que introduce riesgos ocultos para la integridad del proceso físico.

Riesgos de ciberseguridad

Aumento de la superficie de ataque y riesgos de integración

El despliegue de una plataforma de IA requiere la ingesta de volúmenes masivos de datos operativos. Para lograrlo, se crean integraciones entre el entorno de IA y los activos críticos de los Niveles 3 y 2, que incluyen:

• Historiadores de Datos (como AVEVA PI System)

• Servidores de Control Supervisorio y Adquisición de Datos (SCADA)

• Sistemas de Control Distribuido (DCS)

• Estaciones de trabajo de ingeniería que ejecutan software de programación de PLC

Cada punto de conexión de API, conector de base de datos y agente de software implementado para extraer estos datos funciona como una nueva vía de entrada potencial para los actores de amenazas. Si la plataforma de IA está alojada en la nube, establece de manera efectiva una ruta bidireccional continua que atraviesa la DMZ industrial directamente desde los Niveles 3 y 2 hacia la nube pública, invalidando los modelos tradicionales de aislamiento de redes.

[Nivel 1/2: PLCs y SCADA] <--> [Nivel 3: Historiador de datos] <--> [Gateways de la DMZ de TO] <== (Canal de datos de IA) ==> [Plataforma de IA alojada en la nube]

Gestión de credenciales y escalación de privilegios

Los agentes de IA que operan dentro del entorno de TO requieren credenciales de acceso para consultar bases de datos o enviar perfiles de optimización. Si estas credenciales no se aseguran adecuadamente o se codifican directamente en las cuentas de servicio de la IA, el compromiso de la aplicación de IA permite a un atacante recopilar credenciales de TO altamente privilegiadas. Con estas credenciales, los atacantes pueden saltar directamente a las estaciones de trabajo de ingeniería o a los entornos de ejecución de SCADA.

Riesgos en la cadena de suministro y de software de terceros

La plataformas de IA modernas se construyen sobre pilas de software de código abierto complejas, que incorporan cientos de bibliotecas de Python, bases de datos vectoriales y marcos de orquestación (por ejemplo, LangChain). Estas dependencias introducen vulnerabilidades profundas en la cadena de suministro. Un solo paquete malicioso o una dependencia sin parchear dentro del ecosistema de la plataforma de IA puede exponer a toda la red industrial conectada a la ejecución remota de código (RCE).

Fuga de datos

La telemetría operativa contiene información altamente sensible sobre volúmenes de producción, formulaciones químicas, puntos débiles mecánicos y pasos de fabricación patentados. Si un modelo de IA basado en la nube utiliza estos datos para el entrenamiento continuo o se reentrena con las instrucciones del usuario sin límites estrictos de aislamiento de datos, la inteligencia industrial patentada puede filtrarse al dominio público o quedar expuesta en entornos multiinquilino (multi-tenant).

Inyección de instrucciones (prompt injection) y manipulación de la IA

Si un adversario logra establecer un punto de apoyo en una red de TI o en un activo de Nivel 3, puede manipular las entradas que alimentan a la plataforma de IA operativa. A través de la inyección indirecta de instrucciones (por ejemplo, inyectando cargas de datos maliciosas en archivos de registro o registros del historiador que la IA analiza), el atacante puede alterar el razonamiento de la IA. Esto la obliga a generar parámetros de optimización corruptos, eludir los límites de seguridad integrados o clasificar erróneamente alertas críticas del sistema.

Movimiento lateral e impacto de las capacidades de la clase Mythos

La aparición de plataformas como Claude Mythos destaca un vector de riesgo acelerado para el movimiento lateral dentro de las redes de TO. Tradicionalmente, las redes industriales heredadas son planas y confían en defensas perimetrales en lugar de la segmentación interna. Si una plataforma de IA agéntica avanzada (o un adversario que utilice herramientas equivalentes de generación autónoma de exploits) obtiene acceso a un host de salto de TO o a un controlador de dominio de Active Directory activo, puede de manera autónoma:

• Descubrir PLC, unidades de terminal remota (RTU) y interfaces humano-máquina (HMI) no documentados.

• Descompilar o realizar ingeniería inversa en binarios y firmware patentados de fabricantes utilizando la integración de herramientas nativas.

• Identificar fallas en software heredado (como desbordamientos de búfer con décadas de antigüedad o protocolos sin autenticación).

• Construir y ejecutar cadenas de exploits de múltiples vulnerabilidades en minutos para lograr el control total sobre la capa física del proceso.

Consideraciones regulatorias y de cumplimiento

Los propietarios de activos deben evaluar los despliegues de IA industrial frente a marcos de ciberseguridad obligatorios y voluntarios para mantener el cumplimiento y proteger sus licencias operativas.

Serie de normas ISA/IEC 62443

El marco ISA/IEC 62443 proporciona la metodología fundamental para asegurar los sistemas de automatización y control industrial (IACS). Los sistemas de IA deben evaluarse en varias partes específicas:

• IEC 62443-3-2 (Zonas y conductos): Cualquier plataforma de IA debe asignarse a su propia zona de seguridad lógica independiente. Todos los flujos de comunicación entre la zona de la IA y los activos operativos (PLCs, Historiadores) deben canalizarse a través de conductos estrictamente definidos, monitoreados y protegidos por firewalls.

• IEC 62443-3-3 (Requisitos de seguridad del sistema): La integración debe imponer un control de acceso estricto, integridad de datos y disponibilidad de recursos, garantizando que la IA no agote los recursos de red o procesamiento requeridos por las aplicaciones de control en tiempo real.

• IEC 62443-4-1 / 4-2 (Ciclo de vida del producto y seguridad de componentes): Los proveedores de software de IA industrial deben demostrar un ciclo de vida de desarrollo seguro, que incluya una gestión rigurosa de la lista de materiales de software (SBOM) para mitigar los riesgos en la cadena de suministro.

NIST SP 800-82 Rev. 3 (Guía de seguridad para TO)

La versión recientemente actualizada de NIST SP 800-82 Rev. 3 detalla los requisitos de protección y seguridad para los sistemas ciberfísicos. Establece que cualquier plataforma analítica o automatizada avanzada implementada de manera adyacente a un ICS no debe perjudicar las funciones críticas para la seguridad. Exige explícitamente procesos rigurosos de gestión de riesgos antes de conectar herramientas analíticas a las capas operativas, haciendo hincapié en la segmentación de red y el monitoreo continuo de las desviaciones de configuración.

Directiva NIS2 (Unión Europea)

Bajo la Directiva NIS2, las organizaciones que administran infraestructura crítica (energía, transporte, agua, manufactura) enfrentan obligaciones estrictas de gestión de riesgos y seguridad en la cadena de suministro. Introducir motores de IA no validados que procesen datos operativos o proporcionen retroalimentación de control sin evaluaciones exhaustivas de riesgos de terceros puede resultar en severas sanciones por incumplimiento, ya que la NIS2 impone responsabilidad personal directa a los líderes corporativos por las fallas de seguridad.

Preguntas que todo equipo de seguridad de TO debe hacer antes de implementar IA

Antes de que se conceda acceso a cualquier plataforma de IA a los datos operativos, los equipos de seguridad e ingeniería deben exigir respuestas formales a las siguientes preguntas:

• ¿Dónde residen los datos? ¿El modelo de IA se ejecuta completamente de forma local (on-premise) dentro de un servidor perimetral aislado (air-gapped) o localizado, o requiere conectividad saliente a un entorno en la nube?

• ¿Cuáles son los permisos precisos de lectura/escritura? ¿La plataforma opera estricticamente con capacidad de solo lectura en relación con el historiador de datos/SCADA, o posee privilegios de escritura programáticos para modificar puntos de consigna, configuraciones o parámetros lógicos?

• ¿Cómo se aíslan los datos? Si se utiliza un modelo en la nube, ¿nuestros datos operativos están aislados dentro de una instancia dedicada de un solo inquilino (single-tenant) y se excluyen explícitamente de los conjuntos de datos de reentrenamiento del modelo del proveedor?

• ¿Cuál es el mecanismo a prueba de fallas si la plataforma de IA se desconecta o falla? ¿El proceso físico pasará inmediatamente de manera predeterminada a un estado seguro, conocido y determinista gobernado puramente por la lógica local del PLC sin interrupción operativa?

• ¿Cómo se gestionan las dependencias de software de la pila de IA? ¿Puede el proveedor proporcionar una Lista de Materiales de Software (SBOM) verificada y actualizada periódicamente para toda la pila de aplicaciones de IA, incluidas las bibliotecas de código abierto?

Lista de verificación para la evaluación de riesgos

El siguiente marco de trabajo debe ejecutarse durante la fase de diseño de ingeniería de cualquier proyecto de IA industrial:

Estrategias de mitigación y mejores prácticas para la adopción segura de la IA

Para integrar capacidades de IA sin comprometer la seguridad y la resiliencia de la infraestructura crítica, las organizaciones deben adoptar las siguientes mejores prácticas operativas.

Implementar diodos de datos unidireccionales estrictos

Para las plataformas de IA enfocadas en el mantenimiento predictivo y la optimización operativa, imponga una arquitectura unidireccional física o criptográfica. Utilice diodos de datos basados en hardware para replicar la telemetría en tiempo real desde los historiadores de los Niveles 2 y 3 hacia la plataforma de IA alojada en la zona corporativa o en la nube. Esto garantiza que la plataforma de IA pueda ingerir y analizar datos, pero permanezca físicamente incapaz de enviar ningún paquete o comando de vuelta a la red de control.

Aislar la arquitectura de identidad central

Nunca permita que una plataforma de IA aproveche credenciales corporativas o compartidas de Active Directory que abarquen tanto activos de TI como de TO. Despliegue un bosque de Active Directory de TO dedicado e independiente con cero relaciones de confianza extendiéndose hacia la red corporativa. Las cuentas de servicio de la IA deben limitarse exclusivamente a las instancias de bases de datos específicas que requieran, evitando que se utilicen como vectores de movimiento lateral.

Establecer copias de seguridad inmutables fuera de banda

Debido a que las capacidades de generación autónoma de exploits reducen la ventana defensiva para aplicar parches, las organizaciones deben garantizar su capacidad de recuperarse ante un compromiso en el peor de los casos. Implemente una estrategia de respaldo inmutable para todos los archivos de lógica de PLC, entornos de ejecución SCADA, configuraciones de DCS e imágenes HMI. Los respaldos deben almacenarse completamente fuera de banda y fuera de línea, con simulacros de restauración periódicos y validados ejecutados por los equipos de ingeniería de la planta.

Estaciones de trabajo de ingeniería aisladas físicamente (air-gapped)

La estación de trabajo de ingeniería es el objetivo de mayor valor dentro de una instalación industrial porque dicta la lógica que se escribe en los PLC. Estos sistemas deben estar estrictamente aislados de las aplicaciones corporativas estándar, el correo electrónico, el acceso a Internet y cualquier pila de software de IA analítica. Las modificaciones de software o de lógica deben regirse por un riguroso proceso de control de cambios que involucre entradas físicas de USB previamente analizadas contra malware o gateways de transferencia dedicados y altamente monitoreados.

Recomendaciones para el liderazgo

Para los Directores de Seguridad de la Información (CISO)

• Dejen de heredar manuales de TI. No asuman que un marco de gobernanza de datos empresariales o un agente de detección y respuesta de endpoints (EDR) estándar de TI es suficiente para gestionar los riesgos físicos de un motor de IA industrial.

• Establezcan una sala de control de crisis para IA (AI War Room). Asóciense directamente con el vicepresidente de Manufactura u Operaciones para crear un equipo de evaluación de seguridad e ingeniería dedicado y multidisciplinario, encargado de validar todas las integraciones de software analítico y operativo propuestas.

Para los líderes de seguridad de TO

• Impongan la segmentación de zonas. Traten al sistema de IA como si fuera un componente de terceros no confiable. Mapeen todas las dependencias de activos y rutas de comunicación utilizando herramientas de Detección y Respuesta de Red (NDR) optimizadas para protocolos industriales (por ejemplo, Modbus, CIP, DNP3, OPC UA).

• Operativicen el triaje de avisos de seguridad de proveedores. Establezcan acuerdos de nivel de servicio (SLA) claros para evaluar y aplicar de inmediato los parches de los fabricantes o los controles de compensación cuando se divulguen fallas de software críticas, anticipando que las herramientas impulsadas por IA acelerarán los tiempos transcurridos desde la divulgación de una vulnerabilidad hasta el desarrollo de un exploit.

Para los equipos de operaciones y gerentes de planta

• Prioricen los Sistemas Instrumentados de Seguridad (SIS). Asegúrense de que los sistemas de seguridad permanezcan completamente separados, cableados e aislados de cualquier capa de red que contenga software de optimización o plataformas de IA. El lazo de seguridad debe funcionar como una barrera de contención inquebrantable contra cualquier comando de control anómalo.

• Combatan el sesgo de automatización. Lleven a cabo entrenamientos continuos para los operadores y simulacros enfocados en la gestión manual de perturbaciones en los procesos. Asegúrense de que los operadores mantengan la competencia básica para reconocer, desconfiar y anular recomendaciones automatizadas defectuosas.

Conclusión

La integración de plataformas de IA en entornos de Tecnologías de la Operación posee un potencial inmenso para maximizar la eficiencia y reducir el tiempo de inactividad industrial. Sin embargo, la introducción de motores de software estocásticos y no deterministas en arquitecturas deterministas y críticas para la seguridad plantea desafíos operativos y de ciberseguridad profundos.

Las capacidades agénticas avanzadas, representadas por modelos de frontera como Claude Mythos, demuestran que la velocidad de descubrimiento y explotación de vulnerabilidades se ha acelerado de manera permanente. Para defender la infraestructura crítica contra este panorama de amenazas en evolución, los propietarios de activos no pueden depender de las defensas perimetrales convencionales ni de modelos de cumplimiento pasivos. Los equipos de seguridad y de ingeniería deben colaborar para construir arquitecturas resilientes arraigadas en una segmentación estricta de zonas, entrega unidireccional de datos, validación con intervención humana (human-in-the-loop) y un compromiso inquebrantable con la seguridad de los procesos físicos.