Cómo programar un veto determinista en un PLC de seguridad para anular alucinaciones de IA

Para anular las alucinaciones de la IA en la automatización industrial, los ingenieros deben colocar la IA detrás de un veto de PLC determinista. El PLC debe verificar los comandos solicitados por la IA frente a límites fijos, permisivos de estado y funciones de seguridad cableadas antes de que ocurra cualquier actuación. Esta defensa por capas separa la optimización probabilística de la ejecución determinista.

La IA no se vuelve segura solo porque suene convincente. En el control industrial, la confianza no es una variable de control.

El conflicto de ingeniería es directo: los LLM y los sistemas de IA agentes son probabilísticos y no deterministas, mientras que los PLCs ejecutan lógica en ciclos de escaneo repetibles con un comportamiento acotado. Esa diferencia no es filosófica. Es arquitectónica y, en contextos relevantes para la seguridad, es decisiva.

En un lote interno reciente de 500 anomalías de puntos de consigna generadas por IA simuladas a través de los flujos de trabajo de validación de gemelos digitales de OLLA Lab, un limitador de tasa de cambio en el lado del PLC más permisivos de estado explícitos bloquearon el 100% de los comandos catastróficos fuera de límites antes de que actuaran sobre los modelos virtuales de válvulas y motores. Metodología: n=500 casos de anomalías inyectadas en tareas de velocidad, presión y posición de válvula acotadas; comparador de referencia = paso directo del comando solicitado por la IA al tag del actuador simulado; ventana de tiempo = pruebas de laboratorio interno de Ampergon Vallis realizadas en el primer trimestre de 2026. Esto respalda el valor de la verificación determinista en la simulación. No constituye una certificación IEC 61508, evidencia SIL ni una afirmación sobre todas las arquitecturas de planta.

La respuesta práctica no es prohibir la IA. Es denegar a la IA la autoridad de ejecución directa y exigir que el PLC mantenga un veto determinista permanente.

Las alucinaciones de la IA requieren un veto determinista porque las salidas de la IA no tienen garantía de estar acotadas, ser repetibles o ser síncronas con el escaneo de la forma en que debe ser la ejecución del PLC.

En un sistema de control, un comando inseguro es inseguro incluso si fue generado por un modelo estadísticamente impresionante. A una válvula no le importa que la probabilidad del token pareciera persuasiva.

Las normas IEC 61508 e ISO 13849 se basan en un comportamiento predecible, un manejo de fallos definido y estados seguros conocidos. Las funciones de control relacionadas con la seguridad deben fallar de maneras que puedan ser analizadas, acotadas y validadas. Los sistemas actuales tipo LLM no cumplen con ese estándar porque sus modos de fallo no son caracterizables exhaustivamente de la manera que requiere la lógica de seguridad determinista. Ese es el verdadero problema: no que la IA sea nueva, sino que la IA no está lo suficientemente acotada de forma sistemática como para poseer la ruta de actuación final.

El ciclo de escaneo frente al motor de inferencia

Un PLC ejecuta lógica cíclicamente. Escanea entradas, resuelve lógica, actualiza salidas y repite en un intervalo conocido, a menudo en el rango de los milisegundos, dependiendo de la plataforma, la estructura de la tarea y la carga.

Un motor de inferencia de IA no se comporta de esa manera. Su tiempo de respuesta varía según el tamaño del modelo, la disponibilidad de cómputo, las condiciones de la red, la sobrecarga de orquestación y la complejidad del prompt. Incluso cuando la latencia promedio parece aceptable, el peor escenario de tiempo y comportamiento de salida sigue siendo el problema.

Eso crea dos clases de riesgo:

- Riesgo de tiempo: la respuesta de la IA puede llegar tarde, fuera de secuencia o durante un estado de máquina no válido. - Riesgo de contenido: la respuesta de la IA puede solicitar una acción imposible, insegura o ciega al contexto.

Un PLC puede tolerar solicitudes retrasadas o rechazadas. Un tren de bombas no puede tolerar fantasías.

¿Qué exigen realmente las normas?

Las normas exigen un comportamiento de seguridad predecible, no software de moda.

A alto nivel:

• IEC 61508 aborda la seguridad funcional de sistemas eléctricos, electrónicos y electrónicos programables relacionados con la seguridad.
• ISO 13849 aborda las partes de los sistemas de control relacionadas con la seguridad, particularmente en contextos de maquinaria.
• Ambos marcos dependen de arquitecturas definidas, comportamiento validado y respuestas conocidas a condiciones de fallo.

Eso no significa que cada componente de software no determinista esté prohibido en todas partes en una pila industrial. Significa que los componentes no deterministas no deben tratarse como la autoridad de seguridad final. La distinción es importante. La percepción y la optimización pueden ser probabilísticas; el veto y la ruta de parada no pueden serlo.

Un veto determinista es una estructura lógica codificada y vinculada al ciclo de escaneo que evalúa un comando solicitado y lo bloquea, limita o anula cuando el comando viola límites físicos, restricciones de proceso o permisivos de estado de la máquina.

Esta es una definición operativa, no un eslogan. Un veto determinista debe ser observable en la lógica y comprobable frente a casos de fallo.

En la práctica, un veto determinista a menudo incluye:

- Comprobación de límites: rechazar o limitar valores por encima o por debajo de los límites permitidos. - Limitación de tasa de cambio: prevenir cambios abruptos más allá de las tasas de rampa seguras. - Permisivos de estado: permitir comandos solo en estados operativos válidos. - Comprobaciones de retroalimentación de prueba: requerir confirmación de dispositivos de campo antes de avanzar en la secuencia. - Manejo de alarmas y disparos: forzar una respuesta segura ante condiciones anormales. - Aislamiento de modo: prevenir acciones remotas o solicitadas por IA en modos local, mantenimiento o con fallos.

Si la IA solicita un 150% de velocidad de accionamiento y el PLC lo limita al máximo configurado mientras activa una alarma, el veto funcionó. Si la IA puede escribir directamente en la imagen de salida, la arquitectura es incorrecta.

Definiciones operativas que importan

Estos términos a menudo se usan de manera vaga. No deberían serlo.

- Veto determinista: Lógica de PLC que evalúa una solicitud externa o generada por IA en cada escaneo y bloquea la ejecución insegura mediante límites explícitos, permisivos y reglas de fallo. - Defensa por capas: separación arquitectónica entre funciones de IA/TI que sugieren u optimizan y funciones de PLC/OT que verifican, ejecutan y hacen cumplir los límites de seguridad. - Listo para simulación (Simulation-Ready): la capacidad de rastrear la causalidad de E/S, observar comportamientos anormales, inyectar casos de fallo, diagnosticar la respuesta de control y revisar la lógica en un entorno virtual antes de tocar el hardware físico.

“Listo para simulación” no es una abreviatura de “sabe escribir sintaxis ladder”. Significa que el ingeniero puede probar el comportamiento bajo estrés. La sintaxis es barata; la capacidad de despliegue no lo es.

La arquitectura de defensa por capas correcta otorga influencia a la IA sin darle autoridad sin control.

La separación debe ser explícita:

### Capa 1: Agente de IA para percepción u optimización

Esta capa puede:

• estimar la demanda,
• sugerir puntos de consigna,
• recomendar rutas,
• clasificar condiciones operativas,
• generar borradores de lógica u orientación al operador.

Esta capa debe escribir solo en tags de memoria intermedia, estructuras de mensajes o variables de solicitud de supervisión. No debe escribir directamente en salidas físicas o memoria de seguridad.

### Capa 2: Veto determinista en el PLC

Esta capa evalúa la solicitud de la IA frente a reglas de ingeniería fijas como:

• valores máximos/mínimos permitidos,
• estados válidos de la máquina,
• enclavamientos,
• permisivos,
• requisitos de paso de secuencia,
• condiciones de alarma y disparo,
• límites de tasa de cambio.

Aquí es donde el comando se vuelve aceptable, modificado o rechazado.

### Capa 3: Ruta de ejecución de seguridad cableada o certificada

Esta capa incluye, según corresponda:

• cadenas de parada de emergencia (E-stop),
• relés de seguridad,
• tareas de PLC de seguridad,
• contactores,
• circuitos STO,
• enclavamientos de protección,
• funciones de parada independientes.

Esta capa debe permanecer fuera del mapa de memoria de la IA y fuera de cualquier optimismo de supervisión por software. La seguridad cableada existe porque el software ocasionalmente desarrolla opiniones.

Se programa el veto forzando cada comando solicitado por la IA a través de una lógica de verificación explícita antes de que pueda influir en la variable de control final.

El principio de diseño clave es simple: las solicitudes de IA son propuestas, no salidas.

Implementación del limitador de punto de consigna

Un limitador de límites evita que valores imposibles o inseguros lleguen al comando del actuador.

Utilice una estructura como esta:

IF AI_Requested_Speed > Max_Allowable_Speed THEN Actual_Drive_Speed := Max_Allowable_Speed; Set Alarm_AI_Hallucination_Over_Speed; ELSIF AI_Requested_Speed < Min_Allowable_Speed THEN Actual_Drive_Speed := Min_Allowable_Speed; Set Alarm_AI_Hallucination_Under_Speed; ELSE Actual_Drive_Speed := AI_Requested_Speed; END_IF;

Ese es el patrón mínimo, no la arquitectura terminada.

Una implementación orientada a la producción generalmente añade:

- comprobación de modo: solo aceptar solicitudes de IA en modo Auto. - permisivo de estado: solo aceptar solicitudes cuando la máquina está en un estado de secuencia válido. - limitador ROC: limitar el cambio por escaneo o por segundo. - bit de calidad: rechazar datos upstream obsoletos, no válidos o no confiables. - manejo de tiempo de espera (timeout): revertir al valor de respaldo si el flujo de solicitudes se interrumpe. - enclavamiento de alarmas y visibilidad del operador: hacer que el rechazo sea visible y revisable.

Una ruta de control más completa a menudo se ve así:

1. Recibir `AI_Requested_Speed`
2. Validar la calidad y frescura de la fuente
3. Confirmar `System_Auto = TRUE`
4. Confirmar que todos los permisivos son verdaderos
5. Limitar a los mínimos/máximos de ingeniería
6. Aplicar límite ROC
7. Escribir en `Actual_Drive_Speed_Command`
8. Disparar o inhibir si la cadena de seguridad está abierta

¿Qué debe hacer cumplir la lógica ladder antes de pasar un comando de IA?

El PLC debe hacer cumplir las mismas cosas que un ingeniero de puesta en marcha cauteloso preguntaría antes de energizar el equipo:

• ¿Está la máquina en el modo correcto?
• ¿Está la secuencia en el paso correcto?
• ¿Están satisfechos todos los permisivos?
• ¿Son saludables las retroalimentaciones?
• ¿Está el valor solicitado dentro de los límites físicos?
• ¿Es el cambio solicitado plausible para este proceso?
• ¿Existe alguna condición activa de disparo o seguridad?

Esa última pregunta tiende a importar más que el diagrama de arquitectura.

La cadena maestra de E-stop

La cadena maestra de E-stop debe situarse fuera del límite de autoridad de la IA porque el comportamiento de parada de emergencia no puede depender de la calidad de la inferencia, el tiempo de red o el estado del software de supervisión.

En la práctica:

• La ruta de E-stop debe estar cableada o manejada en una función de seguridad certificada según lo requiera la aplicación.
• El sistema de IA no debe escribir ni suprimir el estado de E-stop.
• La tarea de control estándar puede observar el estado de E-stop, pero no debe ser el único guardián del mismo.
• Cualquier comando solicitado por la IA debe colapsar inofensivamente cuando la cadena de E-stop se abre.

Una regla útil es esta: si un hipo de red, un error de modelo o un fallo del analizador pueden mantener el movimiento habilitado, el diseño no está terminado.

Se prueba inyectando comandos anormales y demostrando que la respuesta del PLC permanece acotada, observable y correcta bajo esas condiciones.

Aquí es donde muchos equipos se detienen demasiado pronto. Una ejecución nominal limpia no prueba casi nada.

Como mínimo, pruebe estos casos:

• Solicitudes de IA por encima del valor máximo permitido
• Solicitudes de IA por debajo del valor mínimo permitido
• Cambios de paso abruptos más allá de la tasa de rampa segura
• Comandos emitidos en el estado de máquina incorrecto
• Comandos emitidos mientras un permisivo es falso
• Valores upstream obsoletos o congelados
• Señales de solicitud oscilantes o ruidosas
• Activación de E-stop o disparo durante una solicitud de IA activa

Para cada caso, verifique:

• comando final del actuador,
• comportamiento de la alarma,
• comportamiento de la secuencia,
• visibilidad del operador,
• comportamiento de recuperación después de que el fallo se despeja.

Un veto que limita correctamente pero deja la secuencia varada en un estado incoherente es solo la mitad de una solución.

OLLA Lab es útil aquí como un entorno de validación acotado donde los ingenieros pueden inyectar comandos incorrectos, observar la respuesta del equipo y revisar la lógica ladder antes de que intervenga cualquier hardware real.

Ese posicionamiento es importante. OLLA Lab no es un certificador de seguridad ni un sustituto de la validación formal en la plataforma objetivo. Es un entorno práctico para ensayar lógica de puesta en marcha de alto riesgo de una manera contenida.

Dentro de OLLA Lab, los ingenieros pueden:

• construir lógica ladder en un editor basado en web,
• ejecutar simulación sin hardware físico,
• monitorear tags, E/S, valores analógicos y variables relacionadas con PID,
• usar modelos de equipo basados en escenarios,
• comparar el estado de la lógica con el comportamiento simulado de la máquina,
• revisar la lógica después de observar un caso de fallo.

Para el caso de uso de este artículo, el flujo de trabajo relevante es directo:

1. Crear un tag intermedio como `AI_Requested_Speed`
2. Enrutar ese tag a través de la lógica de limitación y permisivos
3. Observar el `Actual_Drive_Speed_Command` resultante
4. Inyectar valores anormales o patrones inestables
5. Confirmar que el modelo simulado de motor, bomba o válvula nunca exceda los límites seguros
6. Revisar alarmas y revisar la lógica

Aquí es donde OLLA Lab se vuelve operativamente útil. No se puede probar responsablemente un comando de válvula abierta al 200% alucinado en un patín de proceso en vivo solo para ver qué sucede. La curiosidad es valiosa; el hardware doblado es caro.

Cómo se ve "Listo para simulación" en la práctica

Un ingeniero está Listo para simulación cuando puede hacer todo lo siguiente en un entorno virtual:

• rastrear causa y efecto desde la entrada hasta la salida,
• observar si un permisivo o enclavamiento bloqueó la ejecución,
• identificar el peldaño (rung) o condición exacta que produjo la respuesta,
• comparar el estado de la lógica de control con el estado del equipo simulado,
• inyectar un fallo y explicar el comportamiento resultante,
• revisar la lógica y volver a probar hasta que la respuesta sea acotada y repetible.

Ese es el umbral que importa para la preparación de la puesta en marcha. No es “saber colocar una instrucción de temporizador”, sino “poder demostrar por qué la máquina se movió o no se movió”.

El artefacto correcto es un cuerpo compacto de evidencia de ingeniería, no una galería de capturas de pantalla.

Utilice esta estructura:

Establezca qué significa un comportamiento aceptable en términos observables: rango permitido, estados válidos, respuesta de alarma esperada, comportamiento de disparo y comportamiento de recuperación.

Documente la entrada anormal exacta: solicitud de sobrevelocidad, comando de estado no válido, tag obsoleto, señal ruidosa o E-stop durante el movimiento.

Registre qué cambió en la lógica: limitador añadido, permisivo endurecido, tiempo de espera introducido, alarma enclavada, límite ROC ajustado.

1. Descripción del sistema Defina la máquina o celda de proceso, la variable controlada, los modos operativos y el límite de seguridad relevante.
2. Definición operativa de "correcto"
3. Lógica ladder y estado del equipo simulado Muestre la lógica de control junto con la respuesta del actuador o proceso simulado para que la cadena causal sea visible.
4. El caso de fallo inyectado
5. La revisión realizada
6. Lecciones aprendidas Establezca qué expuso el fallo y qué regla de diseño se deriva ahora de ello.

Esto produce evidencia que otro ingeniero puede revisar, desafiar y reproducir. Ese es el estándar al que vale la pena aspirar.

El error más común es permitir que la IA pase por alto la capa de verificación.

Otros errores recurrentes incluyen:

• escribir la salida de la IA directamente en los tags de comando del actuador,
• tratar el rendimiento promedio de la IA como un argumento de seguridad,
• olvidar la detección de datos obsoletos,
• omitir permisivos basados en estados,
• confiar en alarmas de HMI en lugar de bloques de ejecución duros,
• depositar demasiada confianza en la simulación sin una validación final específica de la plataforma,
• confundir la lógica ladder generada con la lógica ladder validada.

Un peldaño generado no es un peldaño probado. El control industrial todavía se rige por lo que la máquina realmente hace.

El patrón correcto no es “la IA controla la planta”. El patrón correcto es “la IA puede sugerir, pero el PLC decide, y la capa de seguridad aún puede decir que no”.

Un veto determinista es el mecanismo de ingeniería que hace real ese límite. Convierte solicitudes no acotadas en un comportamiento de control acotado a través de limitadores, permisivos, enclavamientos y funciones de seguridad independientes. Así es como se evita que el software probabilístico se convierta en un incidente físico.

OLLA Lab encaja en este flujo de trabajo como un entorno de ensayo y validación. Permite a los ingenieros practicar los casos incómodos (puntos de consigna incorrectos, estados no válidos, señales ruidosas, permisivos fallidos, paradas de emergencia) sin usar equipos reales como banco de pruebas. Ese es un camino más creíble hacia el juicio de puesta en marcha que memorizar sintaxis y esperar que el primer fallo real sea leve.

Este artículo fue preparado por el equipo de ingeniería de Ampergon Vallis Lab para proporcionar directrices sobre la integración segura de sistemas de IA en entornos de control industrial.

La metodología de validación y los datos de simulación citados fueron verificados internamente por el equipo de ingeniería de Ampergon Vallis en el primer trimestre de 2026.

- IEC 61131-3: Programmable controllers — Part 3: Programming languages - IEC 61508 overview (functional safety) - NIST AI Risk Management Framework (AI RMF 1.0) - Digital Twin in Manufacturing: A Categorical Literature Review and Classification (IFAC, DOI) - Digital Twin in Industry: State-of-the-Art (IEEE, DOI)