Cómo preparar SOPs y narrativas de control para la IA

Para que los SOPs y diagramas industriales sean aptos para la IA, los ingenieros deben convertir los archivos PDF no estructurados en datos de control legibles por máquina utilizando diccionarios de etiquetas estandarizados, estados seguros explícitos y matrices de causa y efecto. OLLA Lab proporciona un entorno delimitado para practicar la creación de control determinista y validar si la lógica generada se comporta correctamente en simulación.

La IA no falla con los documentos industriales porque "no sea lo suficientemente inteligente". Falla porque la mayoría de la documentación de planta fue escrita para la interpretación humana, reuniones de revisión y memoria tribal, no para el análisis determinista por máquina. Un P&ID escaneado con anotaciones de hace tres paradas de planta no es contexto; es entropía con un cajetín de rotulación.

Durante la evaluación comparativa interna del asistente Yaga AI de OLLA Lab, el uso de prompts con un diccionario de etiquetas estructurado y una matriz de transición de estados redujo los errores de generación de lógica de escalera (ladder logic) en un 83% en comparación con el uso de prompts basados únicamente en narrativas de control en prosa [Metodología: n=36 tareas de generación de escenarios en ejercicios de control de bombas, cintas transportadoras, tanques y HVAC; comparador base = prompts basados solo en párrafos derivados de textos de SOP narrativos; ventana temporal = enero-febrero de 2026]. Esto respalda una afirmación limitada: la documentación de control estructurada mejora materialmente la calidad de los prompts de IA en tareas acotadas de generación de lógica de escalera. No prueba la seguridad general de la automatización, la capacidad de despliegue en campo ni el rendimiento universal del modelo.

El punto práctico es sencillo: si la cadena de suministro de documentos es ambigua, la salida de la IA se convierte en un riesgo mucho antes de convertirse en una herramienta de productividad.

Los LLM son sistemas probabilísticos, mientras que el control industrial requiere una interpretación determinista. Esa discrepancia es el problema raíz.

Un PDF industrial estándar suele contener tipos de documentos mixtos, suposiciones implícitas, desviaciones por revisiones y prosa escrita para ingenieros que ya conocen la planta. Los lectores humanos llenan los vacíos con su experiencia. El modelo los llena con probabilidades de tokens. Ese es un sustituto deficiente para una filosofía de control.

¿Qué hace que un PDF heredado sea un "archivo muerto" para la IA?

Un archivo muerto no es inútil para los humanos. Es inutilizable como entrada fiable para una máquina porque el significado crítico del control está oculto, implícito o es contradictorio.

Los modos de fallo comunes incluyen:

• Revisiones contradictorias
• Existen marcas de revisión (redlines) en un plano pero no en el SOP maestro.
• Los puntos de consigna (setpoints) cambiaron durante la puesta en marcha pero nunca se propagaron a la narrativa.
• Los nombres de los dispositivos difieren entre pantallas HMI, listas de E/S y notas de mantenimiento.

- "Arrancar la bomba cuando el tanque esté lleno" no define:

• Ambigüedad lingüística
• qué tanque,
• qué instrumento de nivel,
• qué umbral,
• qué tiempo de rebote (debounce),
• qué sucede ante una señal errónea,
• o si "lleno" significa alarma de nivel alto o permisivo de nivel alto.
• La IA ve una oración. El proceso ve un argumento.

• Estados seguros faltantes
• Los documentos narrativos a menudo omiten el comportamiento de fallo (abierto o cerrado).
• Rara vez definen el estado de salida ante pérdida de comunicaciones, fallo analógico o transferencia de modo.
• Las suposiciones adyacentes a la seguridad quedan en la cabeza del personal experimentado, lo cual es eficiente hasta que deja de serlo.

• Jerarquía de ejecución colapsada
• Los permisivos, enclavamientos, disparos (trips), alarmas y comandos del operador se describen en un solo párrafo como si la secuencia y la prioridad fueran obvias.
• Solo son obvias después de la tercera visita a la planta.

¿Por qué la prosa es especialmente débil para la generación de control?

La prosa es buena para explicar y mala para ejecutar. La lógica de control necesita estados, precedencia y manejo de condiciones explícitos.

Un modelo de lenguaje puede resumir un párrafo con elegancia mientras omite lo único que importa: si `PMP_101` debe detenerse ante `LSL_100_BAD` antes o después de que expire un temporizador de reinicio. En automatización industrial, eso no es una diferencia estilística. Es la diferencia entre un comportamiento molesto y un suelo mojado, y a veces algo peor.

¿Qué implican las normas al respecto?

Las normas no dicen "use JSON listo para IA". Sí implican que la claridad, la disciplina de nomenclatura y la estructura lógica explícita son importantes.

Los referentes relevantes incluyen:

• ISA-5.1 para la identificación de instrumentación y disciplina de nomenclatura.
• IEC 61131-3 para la estructura formal de programas de control y modelos de instrucción.
• IEC 61508 para el principio más amplio de que el comportamiento relacionado con la seguridad debe especificarse, verificarse y validarse con el rigor apropiado al riesgo.

El lenguaje de las normas no es decorativo. Si sus etiquetas, estados y acciones no son lo suficientemente explícitos para sobrevivir a una revisión estructurada, tampoco están listos para una interpretación fiable por IA.

La documentación lista para IA es aquella que puede analizarse para extraer la intención de control explícita sin depender de la intuición humana para llenar los vacíos.

Esa definición debe mantenerse operativa. "Listo para IA" no es un adjetivo de prestigio para cualquier documento que esté digitalizado.

Definición operativa de documentación lista para IA

Una narrativa de control está lista para IA cuando contiene, como mínimo:

• Mapeo de E/S explícito
• Entradas, salidas, valores analógicos, comandos, estados y estados derivados están nombrados y definidos.
• Estados seguros definidos
• Cada dispositivo controlado tiene una expectativa conocida de estado desenergizado, de fallo o de seguridad, según corresponda.
• Lógica de transición de máquina de estados
• El documento define qué causa las transiciones entre estados de reposo, arranque, marcha, parada, fallo, reinicio, manual y automático.
• Jerarquía de ejecución
• Disparos, enclavamientos, permisivos, alarmas y comandos del operador están separados por prioridad y efecto.
• Extractibilidad estructurada
• La información puede representarse limpiamente en tablas, matrices o datos estructurados como JSON.

Si un documento no puede responder a "¿qué sucede después, bajo qué condición exacta y con qué prioridad?", no está listo para la IA. Puede seguir siendo útil, pero no es lo suficientemente legible por máquina para una generación de control segura.

¿Qué no significa "listo para IA"?

No significa:

• conforme por asociación,
• seguro sin revisión,
• adecuado para despliegue directo en campo,
• o equivalente a una especificación funcional validada.

Tampoco significa que la IA "entenderá la planta". Los modelos no entienden las plantas. Los ingenieros apenas lo logran en algunos sitios industriales antiguos (brownfield), y al menos ellos tienen botas de seguridad.

Tres elementos soportan la mayor parte de la carga: diccionarios de etiquetas estandarizados, matrices de causa y efecto, y definiciones explícitas de enclavamientos/permisivos.

Estas no son ideas nuevas. La novedad es que la IA expone el costo de omitirlas.

1. ¿Por qué son esenciales los diccionarios de etiquetas estandarizados?

Un diccionario de etiquetas convierte la nomenclatura de un hábito local en un significado de control estructurado.

Cada etiqueta debe definir, como mínimo:

• nombre de la etiqueta,
• descripción,
• tipo de datos,
• unidades de ingeniería cuando sea relevante,
• fuente o destino,
• significado normal,
• estado seguro o expectativa de fallo cuando sea aplicable,
• y relaciones con permisivos, alarmas o pasos de secuencia.

Un ejemplo acotado:

- Etiqueta: `PMP_101_CMD` - Descripción: Comando de marcha de la bomba de alimentación principal - Tipo de datos: `BOOL` - Estado seguro: `0` - Permisivos: `LSL_100_OK`, `VLV_102_ZSO`

Esta estructura no es magia. Es simplemente menos ambigua que "arrancar la bomba de alimentación cuando las condiciones sean normales".

_Texto alternativo de la imagen: Captura de pantalla que compara un Procedimiento Operativo Estándar basado en texto con un diccionario de etiquetas estructurado en OLLA Lab, demostrando cómo se organizan los permisivos y estados seguros explícitos para la ingesta por IA._

2. ¿Por qué las matrices de causa y efecto superan a las narrativas en párrafos?

Las matrices de causa y efecto fuerzan las condiciones y respuestas a un formato observable.

Una matriz hace explícito lo siguiente:

• la condición de inicio,
• el umbral o estado discreto,
• el equipo afectado,
• la acción requerida,
• el comportamiento de la alarma,
• el comportamiento de enclavamiento (latching),
• las condiciones de reinicio,
• y la visibilidad para el operador.

Eso importa porque la calidad de la generación de la IA mejora cuando el documento expresa la lógica como relaciones en lugar de prosa. También importa porque la revisión humana mejora por la misma razón. Un párrafo puede ocultar una contradicción durante semanas. Una matriz suele ofender a alguien de inmediato, lo cual es saludable.

3. ¿Por qué deben separarse los enclavamientos y los permisivos?

Los enclavamientos y los permisivos a menudo se describen juntos, pero realizan trabajos diferentes.

Una distinción útil:

- Permisivo: condición requerida antes de que pueda ocurrir una acción. - Enclavamiento o disparo: condición que bloquea o fuerza un cambio de estado durante la operación. - Alarma: condición que informa; puede actuar o no. - Función de seguridad: comportamiento de reducción de riesgos separado que no debe mezclarse casualmente con la lógica de control de procesos estándar.

Si la documentación no separa estas categorías, la IA a menudo las aplanará en una sola capa de control. Así es como se obtiene una lógica de escalera de aspecto elegante con el juicio de una caja de cartón mojada.

El proceso de conversión debe ser escalonado, auditable y deliberadamente aburrido. Lo aburrido está subestimado en los controles.

### Paso 1: Normalizar el conjunto de fuentes

Comience identificando los documentos rectores:

• SOPs actuales,
• P&IDs,
• listas de E/S,
• narrativas de control,
• listas de alarmas,
• hojas de lazo (loop sheets),
• referencias de objetos HMI,
• y notas de puesta en marcha.

Luego resuelva los conflictos obvios:

• nombres de etiquetas duplicados,
• referencias a dispositivos obsoletos,
• puntos de consigna desajustados,
• unidades inconsistentes,
• y modificaciones de campo no documentadas.

No le pida a la IA que reconcilie un conjunto de documentos que usted mismo no ha reconciliado. Eso no es delegar. Eso es abdicar.

### Paso 2: Construir un diccionario de etiquetas

Cree una única fuente estructurada para etiquetas y señales.

Incluya:

• nomenclatura de dispositivos y señales,
• tipo y unidades,
• dirección o fuente lógica,
• emparejamiento comando/estado,
• comportamiento ante fallos,
• umbrales de alarma,
• y cualquier rol en la secuencia.

La disciplina de nomenclatura ISA-5.1 es útil aquí porque la consistencia mejora tanto la revisión humana como la extracción por máquina.

### Paso 3: Extraer la lógica de estado

Convierta las descripciones narrativas del proceso en estados y transiciones explícitos.

Para cada subsistema, defina:

• modos de operación,
• condiciones de entrada,
• condiciones de salida,
• condiciones de tiempo de espera (timeout),
• transiciones anormales,
• y comportamiento de reinicio.

Aquí es donde muchos "proyectos de IA" vuelven a convertirse silenciosamente en proyectos de ingeniería. Eso no es un retroceso. Es el trabajo.

### Paso 4: Escribir tablas de causa y efecto

Mapee cada causa del proceso a su efecto requerido.

Las columnas típicas incluyen:

• ID de causa,
• condición de inicio,
• umbral/valor,
• rebote o retardo,
• equipo afectado,
• acción,
• enclavamiento/sin enclavamiento,
• condición de reinicio,
• respuesta de alarma/HMI,
• y notas.

### Paso 5: Separar el control del comportamiento relacionado con la seguridad

Donde existan funciones de seguridad, documéntelas de forma distinta y revíselas bajo las expectativas de ciclo de vida y normas apropiadas.

No permita que la conveniencia fusione el control básico de procesos, la lógica de parada y las funciones de seguridad en una sola masa narrativa. El documento puede volverse más corto. El argumento de riesgo no.

OLLA Lab es útil aquí porque entrena el comportamiento de autoría del que depende el trabajo de control asistido por IA. No convierte los documentos de planta automáticamente, y ese límite es importante.

La estructura de construcción guiada de la plataforma requiere que los estudiantes trabajen a partir de objetivos explícitos, mapeos de E/S, filosofía de control, diccionarios de etiquetas y pasos de verificación antes de considerar la lógica de escalera como "terminada". Ese es el hábito correcto. La sintaxis llega más tarde de lo que la mayoría cree.

¿Qué proporciona realmente OLLA Lab en este flujo de trabajo?

Dentro del alcance delimitado del producto, OLLA Lab proporciona:

• un editor de lógica de escalera basado en web con tipos de instrucción estándar,
• flujos de trabajo guiados de aprendizaje de escalera que van desde peldaños básicos hasta temporizadores, contadores, comparadores, matemáticas y PID,
• modo de simulación para ejecutar y detener la lógica y observar el comportamiento de las E/S,
• un panel de variables para etiquetas, valores analógicos y visibilidad de lazos de control,
• simulaciones 3D/WebXR/VR vinculadas a un comportamiento realista del equipo,
• validación de gemelos digitales frente a modelos de escenarios,
• laboratorios basados en escenarios con objetivos, peligros, necesidades de secuenciación y notas de puesta en marcha,
• instrucciones de construcción guiadas con mapeo de E/S, filosofía de control y pasos de verificación,
• y el Yaga Assistant, que proporciona orientación de IA acotada dentro del entorno de entrenamiento.

Aquí es donde OLLA Lab se vuelve operativamente útil. Ofrece a los ingenieros un lugar para practicar la escritura de lógica a partir de una intención estructurada, y luego observar si esa intención sobrevive a la ejecución frente a equipos simulados.

¿Por qué es importante para la documentación lista para IA?

Porque la misma disciplina que mejora la calidad de la simulación también mejora la calidad de los prompts de IA.

Cuando un estudiante debe definir:

• qué significa cada etiqueta,
• cómo se ve el comportamiento "correcto",
• cuáles son los permisivos,
• qué fallo debe inyectarse,
• y qué revisión se necesita después de un fallo,

están aprendiendo a pensar en control basado en especificaciones. Ese es el puente real entre la documentación y la asistencia por IA. No es "ingeniería de prompts" en abstracto, sino intención de ingeniería estructurada.

La validación debe probar la interpretación, no solo la sintaxis. Compilar no es una prueba.

La documentación lista para IA es solo la primera mitad del problema. La segunda mitad es comprobar si la lógica generada se comporta correctamente frente a un modelo de proceso realista, incluyendo fallos, temporizaciones y transiciones de estado anormales.

¿Qué significa "listo para simulación" operativamente?

Listo para simulación significa que un ingeniero puede probar, observar, diagnosticar y endurecer la lógica de control frente a un comportamiento de proceso realista, antes de que llegue a un proceso real.

Eso incluye la capacidad de:

• monitorear E/S y estados internos,
• comparar el estado de la escalera frente al estado del equipo simulado,
• rastrear la causa y efecto a través de una secuencia,
• inyectar condiciones anormales,
• revisar la lógica después de un fallo,
• y verificar que el comportamiento revisado aún satisfaga la intención de control documentada.

Esta es la distinción que importa: sintaxis frente a capacidad de despliegue. Mucha lógica parece competente hasta el primer sensor defectuoso, válvula atascada o transferencia de modo.

¿Cómo debe realizarse la validación en OLLA Lab?

Un flujo de trabajo práctico en OLLA Lab se ve así:

- Ejemplos: interruptor de nivel bajo defectuoso, falta de confirmación de válvula, tiempo de espera de temporizador, rango analógico excedido.

• Use el editor de escalera y las definiciones de escenarios.
• Confirme que los comandos, estados, valores analógicos y permisivos sean visibles.
• Observe si la secuencia coincide con la filosofía de control documentada.
• ¿Falló la lógica de forma segura?
• ¿Las alarmas, enclavamientos y reinicios se comportaron según lo previsto?
• Si la lógica generada se comportó "mal" porque el documento era vago, arregle primero el documento.
• El objetivo no es un peldaño parcheado. El objetivo es una cadena de especificación-a-comportamiento endurecida.

1. Cargar o construir la lógica de control
2. Mapear la lógica a etiquetas y estados de proceso explícitos
3. Ejecutar la simulación
4. Inyectar un fallo
5. Comparar el comportamiento esperado frente al observado
6. Revisar la especificación si es necesario
7. Volver a probar después de la revisión

Ese último punto es fácil de pasar por alto. Si la documentación estaba subespecificada, arreglar manualmente la escalera puede resolver el síntoma mientras se preserva el defecto en la cadena de suministro de documentos.

Los ingenieros deben producir un cuerpo compacto de evidencia que muestre razonamiento, comportamiento, fallo y revisión. Las capturas de pantalla por sí solas demuestran principalmente que el software estaba abierto.

Use esta estructura:

1. Descripción del sistema Defina el subsistema, el objetivo del proceso, los modos de operación y el equipo controlado.
2. Definición operativa de "correcto" Establezca el comportamiento esperado exacto, incluyendo permisivos, disparos, alarmas, temporizaciones y condiciones de reinicio.
3. Lógica de escalera y estado del equipo simulado Muestre los peldaños relevantes, las etiquetas y el comportamiento del proceso correspondiente en la simulación.
4. El caso de fallo inyectado Documente la condición anormal introducida y por qué importa.
5. La revisión realizada Registre si la corrección se hizo en la lógica, en la narrativa de control, en el diccionario de etiquetas o en los tres.
6. Lecciones aprendidas Establezca qué reveló el fallo sobre la especificación, el diseño de la secuencia o las suposiciones de validación.

Este formato es útil para la formación, la revisión interna y los flujos de trabajo asistidos por IA porque preserva la trazabilidad desde el requisito hasta el comportamiento. También revela si el ingeniero entiende el sistema o simplemente organizó símbolos de manera convincente.

La creación de control asistida por IA es útil, pero no se justifica por sí misma. La gobernanza sigue siendo importante.

Límites clave a mantener explícitos

• La salida de la IA no es validación
• La lógica de escalera generada aún debe ser revisada, probada y acotada frente a los requisitos específicos de la planta.
• Los entornos de entrenamiento no son calificación de sitio
• OLLA Lab es un entorno de ensayo y validación para tareas de alto riesgo, no un mecanismo de certificación o prueba de competencia en campo.
• Los gemelos digitales son tan buenos como sus suposiciones modeladas
• Una simulación puede exponer muchos defectos, especialmente defectos de secuencia y manejo de fallos, pero no puede garantizar una fidelidad total de la planta.
• Las funciones relacionadas con la seguridad requieren un rigor separado
• Las expectativas de ciclo de vida al estilo IEC 61508 no desaparecen porque un modelo produjo código rápidamente.

Una respuesta incorrecta rápida sigue siendo incorrecta. La IA simplemente hace que el error llegue con un mejor formato.

La cadena de suministro de documentos determina si la IA se comporta como un asistente de redacción útil o como una costosa fuente de errores plausibles.

Si los ingenieros quieren ayuda fiable de la IA en el trabajo de control, la solución no es un prompting místico. Es documentación estructurada: diccionarios de etiquetas, matrices de causa y efecto, lógica de estado explícita y una clara separación de permisivos, enclavamientos, alarmas y comportamiento relacionado con la seguridad. OLLA Lab encaja en ese flujo de trabajo como un lugar acotado para practicar y validar el pensamiento de control determinista frente a equipos simulados antes de que cualquier lógica se acerque a un proceso real.

Ese es el estándar real para la documentación lista para IA: no si un modelo puede leerla, sino si el comportamiento resultante puede probarse.

- IEC 61131-3: Controladores programables — Parte 3 - Familia de normas de seguridad funcional IEC 61508 - Marco de gestión de riesgos de IA del NIST (AI RMF 1.0) - Ley de IA de la UE: marco regulatorio - Visión general de la ciberseguridad industrial ISA/IEC 62443