Cómo los PLC supervisan la IA agéntica con lógica de seguridad determinista

La IA agéntica puede proponer acciones, pero no se debe confiar en ella para ejecutarlas directamente en equipos industriales. En una arquitectura de Industria 5.0 más segura, el PLC sigue siendo el supervisor de seguridad determinista: evalúa los comandos generados por la IA frente a permisivos, enclavamientos y lógica a prueba de fallos codificados antes de permitir que cualquier salida física se mueva.

La IA agéntica no reemplaza al PLC. Cambia aquello contra lo que el PLC debe defenderse.

El problema arquitectónico es simple: los sistemas de IA generan salidas probabilísticas, mientras que los sistemas de control industrial deben aplicar un comportamiento determinista en el límite del equipo. Esa distinción no es filosófica. Es la diferencia entre una sugerencia de rendimiento y una carrera de válvula en una línea presurizada.

Durante las pruebas de estrés con gemelos digitales en OLLA Lab, las inyecciones de puntos de consigna (setpoints) similares a la IA sin restricciones produjeron fallos simulados de sobre-recorrido del actuador en 25 de 30 ejecuciones de prueba, mientras que la adición de lógica de limitación (clamp) y perro guardián (watchdog) determinista redujo esas brechas a cero en los mismos escenarios. Metodología: tamaño de muestra = 30 ejecuciones simuladas en escenarios de válvulas y cintas transportadoras; definición de tarea = inyectar cambios erráticos de puntos de consigna y caídas de comunicación en equipos controlados por lógica de escalera (ladder); comparador de referencia = sin lógica de limitación/perro guardián frente a lógica de escalera con permisivos acotados y manejo de tiempos de espera; ventana de tiempo = Q1 2026. Esto respalda el valor de la lógica de veto determinista en la simulación. Por sí mismo, no establece la fiabilidad en campo, el rendimiento SIL ni las tasas de reducción de fallos universales.

La norma IEC 61508 y las prácticas de seguridad funcional relacionadas hacen que el límite sea más claro: la acción crítica para la seguridad requiere determinismo, trazabilidad y comportamiento validado. Las multiplicaciones de matrices son útiles. No son un caso de seguridad.

La IA agéntica opera de forma probabilística, mientras que la lógica del PLC se ejecuta de forma determinista.

Una definición operativa ayuda aquí. En este artículo, IA agéntica significa un sistema de software que puede generar acciones, puntos de consigna o decisiones de trayectoria fuera de un script secuencial fijo, basándose en entradas cambiantes y objetivos de optimización. En términos de automatización, eso generalmente significa cosas como:

• generación dinámica de puntos de consigna,
• recomendaciones de secuenciación adaptativa,
• selección autónoma de rutas o trayectorias,
• sugerencias de comandos basadas en anomalías,
• optimización supervisora en múltiples activos.

Por el contrario, la lógica determinista del PLC significa un control basado en escaneo donde las mismas entradas validadas, estado lógico y condiciones de tiempo producen el mismo comportamiento de salida dentro de un modelo de ejecución definido.

Esa distinción es importante porque al equipo industrial no le importa si un comando inseguro provino de un operador humano, un script de historiador o un agente de IA. Un comando incorrecto sigue siendo incorrecto.

Control determinista frente a probabilístico en el límite del equipo

El PLC existe en el punto donde la intención del software se convierte en movimiento físico.

Un servicio de IA moderno puede ejecutarse de forma asíncrona en un nodo de borde (edge), servicio en la nube o PC industrial local. Su tiempo de respuesta puede variar con la latencia de la red, la complejidad del modelo, la profundidad de la cola o la calidad de los datos ascendentes. Un ciclo de escaneo de PLC, por diseño, es acotado y repetitivo. Es por eso que el PLC sigue siendo el lugar correcto para aplicar enclavamientos, permisivos, condiciones de disparo y vetos de salida.

El contraste práctico es directo:

| Atributo de control | IA agéntica | PLC / PLC de seguridad | |---|---|---| | Modelo de ejecución | Probabilístico o heurístico | Ejecución determinista basada en escaneo | | Comportamiento temporal | Variable, asíncrono | Acotado, cíclico, tiempo real estricto o casi real dependiendo de la plataforma | | Fortaleza principal | Optimización, adaptación, inferencia de patrones | Ejecución fiable, enclavamientos, secuenciación, respuesta a prueba de fallos | | Rol de certificación de seguridad | No apto como ejecutor directo de funciones de seguridad IEC 61508 | Puede implementarse dentro de arquitecturas de seguridad certificadas cuando se diseña correctamente | | Preocupación por modo de fallo | Salida no acotada, contexto obsoleto, recomendación alucinada, pérdida de comunicación | Defecto de lógica, error de integración, error de configuración, pero el comportamiento sigue siendo comprobable y trazable |

Por qué la IA no puede simplemente "ser el controlador"

La IA puede ayudar al control. No se debe asumir que cumple el papel de un controlador de seguridad.

La norma IEC 61508 no prohíbe la inteligencia de software en sentido amplio, pero la seguridad funcional requiere evidencia de capacidad sistemática, comportamiento predecible, controles de ciclo de vida y funciones de seguridad validadas. Los modelos de IA actuales no están diseñados como solucionadores de seguridad deterministas. Sus salidas son sensibles al contexto y no repetibles bajo muchas condiciones prácticas. Eso los convierte en candidatos pobres para la actuación directa de seguridad.

Un contraste útil es optimización frente a autoridad de veto. La IA puede recomendar. El PLC debe decidir si la recomendación es física y procedimentalmente admisible.

Un PLC veta los comandos de IA forzando cada comando externo a través de una lógica permisiva determinista antes de que llegue a las salidas físicas.

Esta es la arquitectura central. La IA no escribe directamente en la tarjeta de salida. Escribe, como máximo, en un registro de comando supervisado, un punto de consigna solicitado o un bloque de datos que no es de seguridad. El PLC luego evalúa esa solicitud frente a condiciones codificadas como:

• cadena de parada de emergencia (E-stop) saludable,
• selección de modo válida,
• bloqueo de mantenimiento inactivo,
• interruptores de límite no violados,
• variable de proceso dentro del rango seguro,
• latido (heartbeat) de comunicación presente,
• estado de secuencia válido,
• sin disparo activo o fallo enclavado.

Si alguna condición requerida falla, el PLC bloquea, limita, sustituye o descarta el comando.

Esa es la arquitectura de veto. Es menos glamurosa que el control autónomo, que es precisamente por lo que tiende a sobrevivir a la puesta en marcha.

El PLC como supervisor de seguridad

Un supervisor de seguridad PLC es una capa de lógica determinista que evalúa las solicitudes originadas por IA frente a restricciones operativas y de seguridad explícitas antes de permitir cualquier transición de estado de la máquina o cambio de salida analógica.

Esa definición es intencionalmente estrecha. Describe un comportamiento de ingeniería observable:

• la IA emite una solicitud,
• el PLC verifica los permisivos,
• el PLC rechaza, acota o pasa la solicitud,
• el comportamiento final del actuador permanece gobernado por lógica determinista.

En una arquitectura mixta de IA/OT, el PLC debe tratar a la IA como una fuente ascendente no confiable pero potencialmente útil. Este es un diseño de control normal.

Una ruta de veto práctica

Una ruta supervisada típica se ve así:

3. El PLC valida: 4. El PLC:

• frescura de la fuente,
• rango de comando,
• permisivos de modo,
• legalidad de la secuencia,
• disponibilidad del equipo,
• restricciones de seguridad.
• rechaza el comando,
• lo limita a un rango seguro,
• limita la tasa de cambio,
• sustituye un valor de respaldo,
• lo permite.

1. La IA genera un comando solicitado o un punto de consigna analógico.
2. La solicitud se escribe en una etiqueta (tag) de PLC que no es de seguridad o se intercambia a través de una capa de interfaz.
3. La salida final al actuador sigue siendo producida por la lógica del PLC, no por la IA directamente.

Aquí también es donde importa la disciplina de puesta en marcha. La arquitectura insegura generalmente no es dramática. Suele ser una ruta de escritura no verificada y un tiempo de espera faltante.

La supervisión de IA requiere patrones de escalera que detecten solicitudes fuera de rango, comunicaciones obsoletas, transiciones de secuencia no válidas y tasas de comando físicamente abusivas.

La implementación exacta varía según la plataforma, pero los patrones de control son estables.

1. Lógica de limitación (clamp) para ventanas operativas seguras

La lógica de limitación restringe los valores analógicos generados por IA a un rango físicamente seguro y operacionalmente válido.

Esta es la primera línea de defensa para velocidades solicitadas, posiciones de válvulas, objetivos de presión, puntos de consigna de temperatura o tasas de dosificación. El PLC compara el valor solicitado con los límites de ingeniería y reemplaza cualquier valor fuera de rango con una alternativa acotada.

La implementación típica utiliza:

• comparaciones `LES` / menor que,
• comparaciones `GRT` / mayor que,
• instrucciones de movimiento para sustituir valores mínimos/máximos,
• límites dependientes del modo,
• bits de alarma para visibilidad del operador.

Casos de uso típicos:

• limitar un comando de válvula al 20–80% durante el arranque,
• evitar comandos de velocidad de bomba por debajo del flujo de enfriamiento mínimo,
• acotar un punto de consigna de temperatura por debajo de los umbrales de disparo,
• restringir los cambios de velocidad de la cinta transportadora durante la transferencia de producto.

La lógica de limitación responde a una pregunta básica: incluso si la solicitud es sintácticamente válida, ¿es físicamente aceptable?

2. Filtros de tasa de cambio para evitar el latigazo mecánico

El filtrado de tasa de cambio limita qué tan rápido puede cambiar un valor comandado entre intervalos de escaneo.

Un optimizador de IA puede saltar de un mejor valor a otro sin tener en cuenta el desgaste del actuador, el golpe de ariete, el deslizamiento de la correa o el retraso térmico. El equipo tiende a objetar después del segundo o tercer ciclo.

Un PLC puede aplicar:

• delta máximo por escaneo,
• delta máximo por segundo,
• perfiles de aceleración y desaceleración,
• manejo de banda muerta,
• límites separados para arranque frente a operación en estado estable.

Esto importa especialmente en:

• control de velocidad VFD,
• posicionamiento de válvulas,
• bucles de presión y flujo,
• solicitudes de movimiento robótico o adyacente a servo,
• procesos con inercia o holgura mecánica.

3. Temporizadores de perro guardián (watchdog) para supervisión de latidos

Un temporizador de perro guardián verifica que la fuente de IA esté viva, actual y actualizándose dentro de un intervalo esperado.

Una implementación común utiliza un bit de latido o un valor incremental de la capa de IA. Si la señal no cambia dentro de un tiempo de espera definido, el PLC establece un fallo de comunicación y fuerza al proceso a un estado conocido. Ese estado puede ser mantener el último valor, desaceleración controlada, transferencia a manual o parada total, dependiendo del análisis de riesgos.

Los elementos de escalera típicos incluyen:

• temporizadores `TON`,
• lógica de comparación de latidos,
• enclavamientos de fallo,
• condiciones de reinicio,
• lógica de transferencia de modo.

Un perro guardián no es solo una sutileza de comunicaciones. Es una declaración de que la inteligencia obsoleta no es inteligencia.

4. Verificaciones de legalidad de secuencia

La lógica de legalidad de secuencia evita que la IA omita estados de proceso requeridos.

Esto importa en sistemas por lotes, trenes de bombas, transiciones HVAC, secuencias CIP y patines de servicios públicos donde el orden es parte de la seguridad y la protección del equipo. Una IA puede inferir que un estado posterior es deseable. La planta aún puede requerir condiciones de purga, prueba, permisivo o permanencia primero.

Las verificaciones típicas incluyen:

• validación del paso actual,
• retroalimentación de prueba de apertura o prueba de funcionamiento,
• tiempos de permanencia mínimos,
• permisivos de prearranque,
• lógica de solo transición si se confirma.

5. Enclavamiento de fallos y recuperación determinista

El enclavamiento de fallos asegura que las solicitudes de IA inseguras o inválidas no puedan ser borradas implícitamente por el siguiente ciclo.

Si la IA solicita una transición de estado ilegal o pierde el latido durante una operación crítica, el PLC no debería simplemente borrar el problema cuando se reanuden las comunicaciones. Muchos sistemas requieren un fallo enclavado, reconocimiento del operador y una ruta de reinicio definida.

Eso no es exceso burocrático. Es cómo se evita que los fallos intermitentes se conviertan en misterios recurrentes.

Un peldaño (rung) de supervisión de IA práctico combina monitoreo de latidos, enclavamiento de fallos, verificaciones de permisivos y control de salidas.

A continuación, un ejemplo simplificado estilo escalera para ilustración. La sintaxis variará según la familia de PLC.

[Language: Ladder Diagram]

// Tiempo de espera de latido de IA |---[ AI_Heartbeat_Changed ]-------------------------(RES T4:0)---| |---[/AI_Heartbeat_Changed ]-------------------------(TON T4:0)---| | PRE 500ms |

// Enclavar fallo de comunicación de IA en tiempo de espera |---[ T4:0/DN ]--------------------------------------(L AI_Fault)--|

// Borrar fallo solo con reinicio del operador y latido válido restaurado |---[ Reset_PB ]---[ AI_Healthy ]--------------------(U AI_Fault)--|

// Permisivo de limitación para comando de válvula |---[ AI_Request_GT_Max ]----------------------------(OTE Clamp_Hi)-| |---[ AI_Request_LT_Min ]----------------------------(OTE Clamp_Lo)-|

// Salida final permitida solo si no hay fallo de IA y todos los permisivos seguros son verdaderos |---[ AI_Command_Enable ]---[/AI_Fault]---[ Safe_Permissive ]---[ No_Trip ]---(OTE Valve_Open)--|

El punto de ingeniería no es la elección mnemotécnica exacta. Es la estructura de control:

• verificar la frescura de la fuente,
• enclavar fallos de forma determinista,
• requerir condiciones de recuperación explícitas,
• controlar cada salida final a través de permisivos duros.

La norma IEC 61508 sigue siendo importante porque agregar IA no elimina la necesidad de una seguridad funcional demostrable; generalmente aumenta la necesidad de separación arquitectónica y disciplina de validación.

IEC 61508 es el estándar fundamental de seguridad funcional para sistemas eléctricos, electrónicos y electrónicos programables relacionados con la seguridad. En términos prácticos, enmarca cómo se especifican, diseñan, validan y mantienen las funciones de seguridad a lo largo del ciclo de vida. También sustenta muchos estándares específicos del sector.

Para este artículo, el punto relevante es más estrecho: una función de seguridad debe implementarse de una manera que sea analizable, comprobable y justificada por evidencia. Las salidas generadas por IA no están inherentemente descalificadas para existir en algún lugar del sistema más amplio, pero no son un sustituto de la lógica de seguridad determinista.

Qué significa esto en la arquitectura de control real

En una arquitectura creíble:

• La IA puede recomendar un punto de consigna.
• El BPCS o PLC puede evaluar e implementar una versión acotada del mismo.
• La función de seguridad permanece separada y determinista.
• Los disparos, paradas y acciones protectoras no dependen de la inferencia de la IA.

Donde se utiliza un PLC de seguridad, la separación debe ser aún más limpia. La lógica de seguridad no es el lugar para la improvisación probabilística.

Lo que esto no significa

Esto no significa que la IA no tenga uso en la automatización industrial.

La IA puede ser valiosa para:

• mantenimiento predictivo,
• optimización energética,
• detección suave (soft sensing),
• detección de anomalías,
• programación de la producción,
• sugerencias de ajuste adaptativo,
• soporte a la toma de decisiones del operador.

El patrón de diseño correcto es inteligencia asesora o supervisora probabilística por encima de la aplicación de control determinista. Esa es la respuesta práctica de la Industria 5.0.

"Listo para simulación" significa que un ingeniero puede probar, observar, diagnosticar y endurecer la lógica de control contra el comportamiento realista del proceso antes de que llegue a un proceso en vivo.

Esa definición es operativa, no aspiracional. Un ingeniero listo para simulación puede hacer al menos seis cosas:

• definir qué debe hacer el sistema de control en condiciones normales y anormales,
• observar el comportamiento de E/S y etiquetas internas durante la ejecución,
• inyectar fallos realistas y solicitudes anormales,
• comparar el estado de la escalera con el estado del equipo simulado,
• revisar la lógica después de un fallo,
• documentar por qué la revisión es más segura o robusta.

Esta es la distinción entre sintaxis y desplegabilidad.

Una persona que puede dibujar un peldaño no está necesariamente lista para supervisar equipos influenciados por IA. Una persona que puede probar perros guardianes, lógica de limitación, legalidad de secuencia y recuperación de fallos contra un modelo realista está mucho más cerca.

Validar la lógica de supervisión de IA requiere un entorno contenido de riesgo donde se puedan inyectar comandos erráticos sin arriesgar el hardware, la producción o las personas.

Aquí es donde OLLA Lab se vuelve operacionalmente útil.

OLLA Lab es un entorno de simulación de lógica de escalera y gemelos digitales basado en web donde los usuarios pueden construir programas de escalera, ejecutarlos en simulación, inspeccionar variables y E/S, y validar el comportamiento frente a escenarios industriales realistas. En este contexto, su valor es acotado y claro: brinda a los ingenieros un lugar para ensayar lógica de puesta en marcha de alto riesgo antes de aplicar patrones similares en sistemas reales.

Cómo OLLA Lab apoya la práctica de supervisión de IA

Las capacidades relevantes de la plataforma incluyen:

• un editor de lógica de escalera basado en navegador para construir lógica de supervisión,
• modo de simulación para ejecutar y detener la lógica de forma segura,
• un panel de variables para monitorear y forzar etiquetas,
• herramientas analógicas y PID para ejercicios de puntos de consigna acotados,
• simulaciones 3D / WebXR para observar el comportamiento del equipo,
• laboratorios basados en escenarios con enclavamientos, peligros y notas de puesta en marcha,
• GeniAI, la guía de laboratorio de IA, para soporte guiado mientras se construye o depura la lógica.

La afirmación del producto debe seguir siendo modesta: OLLA Lab no certifica funciones de seguridad, no otorga competencia en el sitio ni reemplaza FAT/SAT en un proyecto real. Sí permite a los ingenieros ensayar el tipo exacto de validación de lógica que las plantas en vivo no pueden permitirse tratar como improvisación.

Un flujo de trabajo práctico de OLLA Lab para la validación de intercambio de señales IA

Un ejercicio de laboratorio útil es simular la IA como una fuente de comando externa y luego probar la respuesta de supervisión del PLC.

Construya y pruebe lo siguiente:

- Ejemplo: `AI_Valve_SP_Request`

• Trátela como entrada no confiable.

• limitación mín/máx,
• limitador de tasa de cambio,
• tiempo de espera de perro guardián,
• permisivos de secuencia,
• enclavamiento de fallo.

• posición de válvula,
• estado de funcionamiento del motor,
• respuesta de nivel de tanque,
• movimiento de cinta transportadora,
• velocidad del ventilador.

• saltos repentinos de 0% a 100%,
• valores negativos imposibles,
• latido obsoleto,
• comando durante condición de disparo,
• comando durante paso de secuencia inválido.

• ¿El PLC rechazó la solicitud?
• ¿Se enclavó el fallo?
• ¿El equipo permaneció dentro de un comportamiento seguro?
• ¿El proceso se movió al estado de respaldo previsto?

• ajustar valores de tiempo de espera,
• endurecer permisivos,
• agregar visibilidad de alarma,
• refinar condiciones de reinicio.

Esa es la validación de gemelos digitales en términos prácticos: no "el modelo se ve impresionante", sino "la lógica sobrevive a entradas incorrectas sin producir movimiento incorrecto".

1. Crear una etiqueta de comando supervisado
2. Agregar lógica de validación determinista
3. Mapear salidas a equipos simulados
4. Inyectar casos incorrectos a través del panel de variables
5. Observar tanto el estado de la escalera como el estado del equipo simulado
6. Revisar y volver a probar

Los ingenieros deben documentar un cuerpo compacto de evidencia, no una galería de capturas de pantalla.

Si el objetivo es demostrar competencia en la supervisión IA-PLC, utilice esta estructura:

Establezca qué significa el comportamiento correcto en términos observables: rango de punto de consigna permitido, respuesta de tiempo de espera, transiciones de secuencia válidas, comportamiento de alarma y estado de respaldo seguro.

Documente la entrada anormal exacta: latido obsoleto, punto de consigna imposible, transición inválida o cambio de tasa excesivo.

Explique qué lógica se cambió: umbrales de limitación, temporización de perro guardián, enclavamiento de fallos, condiciones de enclavamiento o manejo de modo.

1. Descripción del sistema Defina la máquina o proceso, la variable solicitada por la IA, las salidas controladas por el PLC y los modos de operación.
2. Definición operativa de "correcto"
3. Lógica de escalera y estado del equipo simulado Muestre los peldaños, etiquetas y la respuesta del equipo correspondiente en la simulación.
4. El caso de fallo inyectado
5. La revisión realizada
6. Lecciones aprendidas Establezca qué reveló el fallo y qué evita ahora la lógica revisada.

Este formato es útil porque hace visible el juicio de ingeniería. Cualquiera puede afirmar que trabajó con IA y PLC. La evidencia comienza cuando el caso de fallo es explícito.

Los errores de integración más comunes son arquitectónicos, no algorítmicos.

Tratar la salida de la IA como autoridad de control confiable

Este es el error principal. Si la IA escribe directamente en una ruta de comando en vivo sin validación determinista, la arquitectura ya es débil.

Confundir optimización con seguridad

Una IA puede mejorar el rendimiento o el uso de energía. Eso no la hace adecuada para acciones protectoras, lógica de disparo o decisiones de derivación de enclavamientos.

Omitir el manejo de tiempo de espera y datos obsoletos

Un servicio de IA desconectado que deja el último valor en su lugar puede ser más peligroso que uno ruidoso. El silencio sigue siendo un estado.

Ignorar la legalidad de la secuencia

Muchos fallos ocurren no porque el valor solicitado sea numéricamente incorrecto, sino porque llega en el paso de proceso incorrecto.

Probar solo casos nominales

Si el laboratorio solo prueba que el sistema se comporta cuando todo está saludable, aún no ha probado mucho. La puesta en marcha es donde se auditan las suposiciones.

Los PLC actúan como supervisores de seguridad para la IA agéntica aplicando lógica de veto determinista entre las recomendaciones probabilísticas y el equipo físico.

Esa es la regla de diseño central. La IA puede optimizar, sugerir y adaptarse. El PLC aún debe validar, restringir y, cuando sea necesario, rechazar. En la Industria 5.0, el problema de control no es IA o PLC. Es cómo colocar a cada uno en el papel que realmente puede desempeñar con evidencia.

OLLA Lab se ajusta a ese flujo de trabajo como un entorno de validación acotado. Permite a los ingenieros construir lógica de escalera, simular entradas anormales similares a la IA, observar la respuesta del equipo y endurecer la lógica de supervisión antes de que patrones similares se expongan al riesgo de puesta en marcha en vivo. Ese es un uso creíble de la simulación: probar el comportamiento antes de que el metal se mueva.

- Marco de Gestión de Riesgos de IA del NIST (AI RMF 1.0) - Descripción general de seguridad funcional IEC 61508 - Descripción general de los estándares de ciberseguridad industrial IEC 62443 - Tecnologías habilitadoras de gemelos digitales (IEEE Access) - IA industrial para la Industria 4.0 (Manufacturing Letters)