Cómo prevenir alucinaciones de IA en la lógica de PLC usando el bucle de Generación-Validación

Para prevenir las alucinaciones de IA en la programación de PLC, los ingenieros deben utilizar un bucle de Generación-Validación: generación de IA acotada, comprobaciones de sintaxis y estructura frente a las expectativas de la norma IEC 61131-3, y pruebas dinámicas frente al comportamiento simulado del equipo. En OLLA Lab, esto significa que las sugerencias de la IA se revisan dentro de un entorno de lógica de contactos (ladder) basado en web, y luego se prueban frente a la lógica del escenario, los estados de E/S y el comportamiento del gemelo digital antes de cualquier decisión de implementación en vivo.

La IA no falla en la automatización industrial porque sea "mala programando". Falla porque la lógica de PLC no es solo código; es un comportamiento de control determinista vinculado a equipos físicos, tiempos de escaneo y consecuencias ante fallos.

Esa distinción es importante. Un peldaño (rung) de lógica ladder puede parecer plausible y, aun así, ser operativamente incorrecto.

Durante un benchmark interno de Ampergon Vallis, la generación de lógica ladder asistida por IA sin restricciones produjo defectos de control críticos en el 42% de las tareas complejas de secuencias de control de motores. Estos incluyeron asignaciones de bits doblemente destructivas, manejo de permisivos no válidos y ambigüedad en el estado de la secuencia. Metodología: 31 tareas de generación acotada que involucran patrones de arranque/parada de motor, enclavamiento (seal-in), lead/lag y reinicio de fallos; el comparador de referencia fue el comportamiento de control esperado revisado por ingenieros en las especificaciones del escenario; ventana de tiempo enero-marzo de 2026. Esta métrica respalda un punto limitado: no es seguro confiar en la generación sin restricciones sin validación. No respalda una afirmación general sobre todas las herramientas de IA, todas las tareas de PLC o todos los proveedores.

La respuesta práctica no es "nunca usar IA". Es obligar a la IA a entrar en un flujo de trabajo de validación. En términos industriales, eso significa barreras de seguridad de sintaxis, contexto de escenario y simulación dinámica antes de que algo se acerque a las E/S físicas. El optimismo no es una filosofía de control.

Los modelos de lenguaje extenso (LLM) alucinan en la lógica ladder porque generan patrones estadísticamente probables, mientras que los PLC ejecutan lógica determinista bajo estrictas restricciones de ciclo de escaneo y estado.

Un LLM predice qué secuencia de instrucciones parece plausible a partir de los datos de entrenamiento. A un PLC no le importa lo que parezca plausible. Evalúa la lógica en un orden de ejecución definido, con etiquetas reales, tiempos reales y consecuencias reales. Esa es la discrepancia fundamental.

La norma IEC 61131-3 define lenguajes de programación de PLC estandarizados y expectativas estructurales, pero no rescata a un modelo de malinterpretar el comportamiento de la planta, los límites de los dialectos de los proveedores o la intención de la secuencia. Un peldaño generado puede ser sintácticamente familiar y, aun así, violar la filosofía de control. La sintaxis no es sinónimo de capacidad de implementación.

Fallos comunes de la lógica de IA en el trabajo con PLC

- Ignorancia del ciclo de escaneo: El modelo asume un modelo de eventos similar al software en lugar de una ejecución cíclica. Esto a menudo aparece como condiciones de carrera, enclavamientos inadecuados o un comportamiento de salida que depende de un orden de ejecución que el PLC no proporciona realmente.

- Mezcla de dialectos: El modelo mezcla estilos de instrucción, convenciones de direccionamiento o semántica de funciones entre proveedores. Rockwell, Siemens, entornos derivados de Codesys y otros no son intercambiables solo porque el peldaño "se vea bien".

- Ceguera física: El modelo no puede razonar intrínsecamente sobre el tiempo de recorrido de una válvula, la inercia de una bomba, el traqueteo de un sensor, el rebote de contactos o la histéresis de un actuador a menos que esas restricciones se modelen y prueben explícitamente.

- E/S o etiquetas inventadas: El modelo crea direcciones, enclavamientos o bits de estado que no existen en la narrativa de control. Esto es común cuando las instrucciones (prompts) son laxas y se permite que el sistema improvise.

- Omisión de rutas de fallo: El modelo maneja el camino feliz (happy path) y descuida los disparos, reinicios, retroalimentaciones de prueba, comportamiento de tiempo de espera o condiciones de reinicio. Las plantas son implacables con la lógica que solo funciona cuando nada sale mal.

Por qué la ejecución determinista cambia el estándar de prueba

La lógica de control determinista debe probarse mediante un comportamiento observable, no aceptarse por confianza estilística.

En la automatización industrial, "correcto" significa que la secuencia se comporta según lo previsto en estados normales, anormales, de arranque, de parada y de recuperación. Esa prueba requiere más que una compilación. Requiere la observación del estado a lo largo del tiempo.

Esta es también la razón por la cual la generación de IA sin restricciones no satisface las expectativas de trazabilidad y verificación asociadas con el trabajo de seguridad funcional bajo normas como la IEC 61508. Las obligaciones del ciclo de vida de seguridad requieren especificación, verificación y evidencia documentada. Un párrafo convincente de un modelo no es evidencia. Es, en el mejor de los casos, un borrador.

El bucle de Generación-Validación es un flujo de trabajo de ingeniería acotado en el que la IA puede proponer lógica de control, pero la lógica solo se acepta después de comprobaciones estructurales y validación dinámica frente al comportamiento esperado de la máquina.

Esto no es una preferencia filosófica. Es un método de contención de riesgos de control.

En la práctica, el bucle separa tres cosas que a menudo se fusionan descuidadamente:

• generación de borradores,
• revisión determinista,
• y validación del comportamiento.

Esa separación es saludable. También lo es no dejar que un modelo probabilístico pretenda ser un ingeniero de puesta en marcha.

La arquitectura de validación de 3 pasos

1. Generación contextual La IA está restringida por una filosofía de control definida, mapa de E/S, diccionario de etiquetas, objetivo de secuencia y contexto de peligro. Si faltan esas entradas, el modelo llena los vacíos con probabilidad. La probabilidad es útil en el lenguaje; es menos encantadora en un arrancador de motor.
2. Barreras de seguridad de sintaxis y estructura Se comprueba la conformidad del lenguaje, la compatibilidad de las instrucciones, la validez de las etiquetas y los defectos estructurales, como asignaciones conflictivas, enclavamientos ambiguos o transiciones de secuencia no válidas. La norma IEC 61131-3 es relevante aquí como marco de lenguaje, aunque los detalles de implementación específicos del proveedor siguen siendo importantes.
3. Simulación dinámica La lógica se ejecuta frente a un proceso o modelo de máquina simulado para que el ingeniero pueda observar las transiciones de E/S, el comportamiento de temporización, las condiciones de alarma, los enclavamientos y las respuestas ante fallos a lo largo del tiempo. Este es el punto donde "parece correcto" se convierte en "se comporta correctamente", o falla en el intento.

Qué significa operativamente "listo para la simulación" (Simulation-Ready)

Un ingeniero "Simulation-Ready" no es simplemente alguien que puede escribir sintaxis ladder. Un ingeniero "Simulation-Ready" puede probar, observar, diagnosticar y endurecer la lógica de control frente al comportamiento realista del proceso antes de que llegue a un proceso en vivo.

Esa definición es conductual, no aspiracional.

En términos prácticos, el trabajo "Simulation-Ready" incluye:

• definir cómo se ve el comportamiento correcto de la secuencia,
• rastrear el estado de la etiqueta frente al estado del equipo,
• inyectar fallos y condiciones anormales,
• revisar la lógica después de un fallo observado,
• y documentar por qué el comportamiento revisado es más robusto.

Aquí es donde OLLA Lab se vuelve operativamente útil. Proporciona un entorno basado en web para construir lógica ladder, ejecutar simulación, inspeccionar variables y E/S, y comparar el estado de la lógica ladder frente al comportamiento del escenario en un entorno contenido. Ese es un entorno de ensayo para tareas de validación, no un atajo para evitar la experiencia en planta.

OLLA Lab posiciona la asistencia de IA como una capa de entrenamiento y sugerencia acotada dentro de un flujo de trabajo de simulación definido, no como una autoridad autónoma sobre el diseño de control.

Esa distinción es importante porque la generación sin restricciones es exactamente donde prosperan las alucinaciones.

Dentro de OLLA Lab, el asistente GeniAI está destinado a apoyar la incorporación, la explicación, las sugerencias correctivas y la asistencia en la lógica ladder dentro de un entorno estructurado que ya contiene el encuadre del escenario, la visibilidad de etiquetas y herramientas de simulación. El valor práctico no es que GeniAI "escriba código perfecto". No lo hace. El valor es que las sugerencias pueden revisarse frente a condiciones de escenario conocidas en lugar de aceptarse como texto libre.

Qué hacen las barreras de seguridad en la práctica

En un flujo de trabajo acotado de OLLA Lab, las sugerencias de la IA pueden restringirse mediante:

Por ejemplo, un escenario de control de motor, secuenciación de bombas, HVAC o skid de proceso define lo que se supone que debe lograr la lógica.

• Objetivos específicos del escenario

Las entradas, salidas, valores analógicos y etiquetas de estado son visibles y están vinculados al escenario en lugar de inventarse bajo demanda.

• Mapeos de E/S conocidos

El ingeniero trabaja a partir del significado explícito de las etiquetas, enclavamientos, permisivos y el comportamiento esperado de la secuencia.

• Diccionarios de etiquetas y filosofía de control

Los escenarios pueden incluir expectativas de estado anormal, como cadenas de parada de emergencia (estop), retroalimentaciones de prueba, lógica de tiempo de espera, umbrales de alarma y comportamiento de reinicio.

• Notas de peligro y puesta en marcha

La lógica sugerida se puede ejecutar, pausar, alternar y observar en lugar de admirarse desde una distancia segura.

• Modo de simulación e inspección de variables

Este es un uso más estrecho y creíble de la IA. El modelo es útil cuando se le obliga a operar dentro de las mismas restricciones que se esperaría que respetara un ingeniero junior.

### Un ejemplo compacto: permisivos inventados frente a generación acotada

Supongamos que se le pide a una IA que "escriba una secuencia de arranque de bomba con manejo de fallos". En un entorno sin restricciones, puede inventar un permisivo como `PUMP_READY_FB`, asumir una ruta de reinicio y crear un bit de tiempo de espera que no existe en la base de diseño.

En un escenario acotado de OLLA Lab, el ingeniero puede comparar esa sugerencia frente a:

• las etiquetas reales disponibles,
• el objetivo de secuencia documentado,
• la retroalimentación de prueba esperada,
• y la respuesta simulada del equipo.

La corrección suele ser simple. Las consecuencias de no corregirlo no lo son.

Los ingenieros prueban la lógica generada por IA frente a gemelos digitales ejecutando la secuencia de control propuesta en simulación, observando los cambios de estado a lo largo del tiempo y comparando el comportamiento de la lógica ladder con el comportamiento esperado de la máquina o proceso tanto en condiciones normales como anormales.

Un gemelo digital no es una envoltura decorativa en 3D. En este contexto, es una capa de simulación dinámica utilizada para probar si la lógica de control sobrevive al contacto con la realidad del proceso.

Esa definición operativa es importante porque "gemelo digital" a menudo se usa como vocabulario de prestigio. Aquí, significa algo observable: la lógica impulsa un sistema modelado, y el sistema modelado expone si la lógica es realmente válida.

Qué observar durante la validación

Al validar la lógica asistida por IA en OLLA Lab, los ingenieros deben inspeccionar:

¿La salida se energiza solo cuando los permisivos están realmente satisfechos?

• Causalidad de entrada a salida

¿Los temporizadores, transiciones y reinicios se comportan correctamente a través de los ciclos de escaneo y cambios de estado?

• Temporización de la secuencia

¿La lógica confirma el estado del equipo o simplemente lo asume?

• Comportamiento de la retroalimentación de prueba

¿Las condiciones anormales se enclavan, anuncian y reinician de manera controlada?

• Manejo de alarmas y disparos

Si la IA sugiere comparadores, umbrales analógicos o comportamiento PID, ¿esas respuestas permanecen estables bajo valores de proceso cambiantes?

• Respuesta analógica y PID

Después de un fallo, ¿el sistema vuelve a un estado seguro y previsto, o se reinicia en un estado de confusión?

• Lógica de recuperación

Uso del panel de variables para rastrear la causalidad

El panel de variables en OLLA Lab es útil porque convierte la lógica ladder en un modelo de estado observable.

En lugar de preguntar solo si un peldaño es verdadero, el ingeniero puede inspeccionar:

• valores de etiquetas,
• transiciones de entrada,
• estados de salida,
• valores analógicos,
• variables relacionadas con PID,
• y el comportamiento del escenario a medida que se ejecuta la simulación.

Esa visibilidad es esencial para depurar la lógica generada por IA. La mayoría de las alucinaciones se vuelven obvias solo cuando se obliga a la secuencia a explicarse a sí misma a lo largo del tiempo.

Pruebas de condiciones anormales, no solo comportamiento nominal

La lógica generada por IA debe probarse bajo inyección de fallos, no solo bajo condiciones ideales de arranque.

En OLLA Lab, eso significa usar controles de simulación y cambios de estado del escenario para provocar la lógica:

• eliminar un permisivo,
• retrasar una retroalimentación de prueba,
• forzar el estado de un sensor,
• variar una entrada analógica,
• o crear una condición de reinicio después de un disparo.

Si la secuencia colapsa bajo una condición anormal modesta, el problema no es que el simulador sea duro. El simulador está siendo educado en nombre de la planta.

Un error de lógica ladder alucinado por IA a menudo parece estructuralmente familiar, pero contiene una lógica de estado conflictiva que una revisión determinista rechazaría.

Un ejemplo común es el problema de la bobina doble o asignación conflictiva, donde la misma salida o bit de memoria se activa en múltiples lugares sin una estrategia de secuenciación controlada.

### Ejemplo: comando de motor conflictivo frente a lógica de enclavamiento validada

Patrón alucinado por IA: asignaciones conflictivas

Lenguaje: Diagrama de contactos (Ladder)

Peldaño 1: | START_PB STOP_PB OL_OK MOTOR_RUN | |----] [-------]/[------] [--------------------( )-----|

Peldaño 2: | FAULT_RESET MOTOR_RUN | |----] [----------------------------------------( )-----|

Por qué falla: La misma salida se asigna en múltiples peldaños con diferente intención. Dependiendo del orden de escaneo y la lógica circundante, el segundo peldaño puede sobrescribir el estado del primer peldaño. El resultado es un comportamiento ambiguo, especialmente durante las condiciones de reinicio.

Patrón validado: enclavamiento explícito con ruta de reinicio controlada

Lenguaje: Diagrama de contactos (Ladder)

Peldaño 1: | STOP_PB OL_OK FAULT_CLEAR START_PB MOTOR_RUN | |----]/[------] [------] [----------] [----------------------( )-----| | MOTOR_RUN | |----------------------------] [----------------------------------|

Peldaño 2: | FAULT_ACTIVE MOTOR_RUN_LATCH_RST | |----] [----------------------------------------------------( )-------------|

Por qué es mejor: El comando de marcha se mantiene a través de una ruta de enclavamiento explícita, mientras que el manejo de fallos se separa en una estrategia definida de reinicio o inhibición. La implementación exacta variará según la plataforma y la filosofía de control, pero el principio es estable: una intención de estado, una ruta controlada.

El punto no es que cada asignación doble sea siempre inválida en todos los entornos de proveedores. El punto es que la IA a menudo introduce una lógica de estado conflictiva sin comprender las consecuencias del escaneo. Esa es la parte que los ingenieros deben detectar.

Los ingenieros deben documentar un cuerpo compacto de evidencia de ingeniería que muestre que la lógica fue especificada, probada, falló cuando correspondía, revisada y re-probada frente a un comportamiento observable.

Una galería de capturas de pantalla no es suficiente. Solo prueba que una pantalla existió.

Utilice esta estructura:

Especifique qué significa el comportamiento correcto en términos observables: condiciones de arranque, permisivos, transiciones de secuencia, alarmas, disparos y comportamiento de recuperación.

Documente la condición anormal introducida: retroalimentación retrasada, permisivo fallido, excursión analógica, evento de parada de emergencia, traqueteo o tiempo de espera.

1. Descripción del sistema Defina la celda de proceso, máquina o escenario. Indique el equipo, el objetivo de la secuencia y las E/S relevantes.
2. Definición operativa de "correcto"
3. Lógica ladder y estado del equipo simulado Incluya la implementación ladder y el estado correspondiente de la máquina o proceso simulado durante la ejecución.
4. El caso de fallo inyectado
5. La revisión realizada Muestre exactamente qué cambió en la lógica y por qué.
6. Lecciones aprendidas Indique qué reveló la prueba sobre el diseño de la secuencia, el manejo de fallos, las suposiciones de tiempo o los defectos generados por la IA.

Este estilo de documentación es más valioso que los visuales pulidos porque demuestra juicio de ingeniería. Los empleadores y revisores no necesitan otra captura de pantalla de un peldaño. Necesitan evidencia de que el peldaño sobrevivió al interrogatorio.

El bucle de Generación-Validación está respaldado por distinciones establecidas en el control industrial, la seguridad funcional y la validación basada en simulación, en lugar de por una única norma "bala de plata".

El respaldo relevante proviene de varios niveles:

Normas y fundamentos técnicos

• IEC 61131-3 respalda la necesidad de disciplina lingüística en la programación de PLC, incluidos modelos de programación definidos y expectativas de implementación en controladores industriales.
• IEC 61508 respalda la necesidad de trazabilidad, verificación y rigor en el ciclo de vida de los sistemas eléctricos, electrónicos y programables relacionados con la seguridad.
• La guía de exida y la literatura de prácticas de seguridad refuerzan constantemente que la verificación, la independencia de la revisión y la validación documentada importan más que la aparente fluidez en la codificación.
• La literatura sobre gemelos digitales y simulación en ingeniería industrial, sistemas de procesos y sistemas ciberfísicos respalda el uso de modelos dinámicos para probar el comportamiento del control antes de la implementación.
• La literatura sobre factores humanos y capacitación inmersiva respalda la simulación como un entorno útil para ensayar tareas operativas complejas, especialmente donde la práctica en sistemas en vivo es costosa, insegura o está operativamente restringida.

Qué justifica y qué no justifica esto

Este cuerpo de evidencia justifica el uso de la simulación y la asistencia de IA acotada como un flujo de trabajo de reducción de riesgos para la validación de control.

No justifica afirmar que:

• la lógica de PLC generada por IA es intrínsecamente segura,
• la simulación reemplaza la puesta en marcha,
• los gemelos digitales garantizan el éxito en campo,
• o que un entorno de capacitación confiere certificación, competencia en el sitio o cumplimiento formal por asociación.

Esas son afirmaciones diferentes. Algunas de ellas son errores costosos.

Los ingenieros deben usar OLLA Lab como un entorno de ensayo y validación para tareas de control de alto riesgo que son difíciles de practicar de manera segura en equipos en vivo.

Esa es la posición creíble del producto.

OLLA Lab combina un editor ladder basado en navegador, modo de simulación, visibilidad de variables y E/S, ejercicios basados en escenarios, interacción con máquinas tipo gemelo digital, herramientas analógicas y PID, y soporte de entrenamiento de IA en un solo entorno. El beneficio práctico es que los ingenieros pueden pasar de escribir lógica a observar consecuencias.

Utilizado correctamente, OLLA Lab respalda trabajos como:

• validar secuencias de motores y bombas,
• probar enclavamientos y permisivos,
• observar el comportamiento de alarmas y disparos,
• rastrear la respuesta analógica y PID,
• comparar el estado de la lógica ladder con el estado del equipo simulado,
• y revisar la lógica después de la inyección de fallos.

Esto es especialmente útil para ingenieros al inicio de su carrera y programas de capacitación, porque los empleadores no pueden transferir riesgos de puesta en marcha en vivo a novatos de manera económica. Las plantas no son pasantías para lógica no validada.

Lo que OLLA Lab no debe posicionarse como:

• un sustituto para la puesta en marcha en sitio,
• una garantía de empleabilidad,
• una vía de certificación de seguridad,
• o prueba de que el código generado está listo para producción por defecto.

Es un entorno acotado para aprender y validar el comportamiento de ingeniería antes de la exposición en campo. Ese ya es un caso de uso serio.

Las alucinaciones de IA en la lógica de PLC se tratan mejor como un problema de riesgo de control, no como un inconveniente de redacción de instrucciones (prompts).

El remedio es el bucle de Generación-Validación: restringir el contexto de generación, hacer cumplir la disciplina estructural y probar el comportamiento frente a la realidad del proceso simulado. En ese flujo de trabajo, la IA puede ser útil. Fuera de él, la IA suele ser solo una suposición fluida con casco de seguridad.

Para la automatización industrial, el estándar es simple: si la lógica no puede ser observada, sometida a fallos, revisada y re-probada antes de la implementación, no está lista. La planta eventualmente realizará la revisión de todos modos, generalmente con menos paciencia.

- Marco de gestión de riesgos de IA del NIST (AI RMF 1.0) - Descripción general de la norma IEC 61131-3 (PLCopen) - Página de la norma ISO/IEC 42001 sobre sistemas de gestión de IA - Descripción general de seguridad funcional IEC 61508 - Biblioteca digital ACM para literatura sobre verificación de software