Conectar inteligencia artificial con información proveniente de un PLC puede facilitar tareas de diagnóstico, consulta técnica o análisis de eventos. Sin embargo, que una integración sea posible no significa que deba comenzar con acceso directo al sistema de control.
Antes de elegir modelos, protocolos o infraestructura, conviene definir qué decisión se quiere mejorar y qué papel tendrá la IA. Muchas pruebas iniciales pueden realizarse con históricos, alarmas y documentación, sin intervenir en el proceso en tiempo real. Estas siete preguntas ayudan a delimitar el proyecto antes de diseñar su arquitectura.
1. ¿Qué pregunta operativa debe responder la solución?
“Aplicar IA a la planta” no es un objetivo verificable. El punto de partida debe ser una pregunta concreta: ¿qué ocurrió antes de una parada?, ¿qué procedimiento corresponde a determinada alarma?, ¿qué eventos deben revisarse durante la entrega de turno?
También hay que identificar quién utilizará la respuesta y qué hará con ella. Una explicación útil para mantenimiento puede resultar insuficiente para producción o ingeniería. Cuanto más precisa sea la pregunta, más sencillo será determinar si la IA aporta algo que no pueda resolverse con una consulta, una regla o una mejor visualización.
2. ¿La IA necesita observar, recomendar o actuar?
Estos niveles implican riesgos diferentes. Una solución de observación puede ordenar eventos o recuperar información. Una de recomendación puede proponer verificaciones, pero deja la decisión al personal autorizado. Una solución con capacidad de actuar podría modificar consignas, estados o parámetros.
El alcance debe declarar qué nivel está permitido. Para una prueba temprana, el acceso de solo lectura facilita el aislamiento y la revisión de resultados. Si se contempla cualquier escritura, deben definirse permisos, enclavamientos, condiciones de rechazo y mecanismos de retorno seguro junto con los responsables de automatización.
3. ¿Qué datos están disponibles y qué contexto les falta?
Un tag aislado rara vez explica por sí solo el estado de una máquina. Su interpretación puede depender del modo de operación, la receta, la fase del ciclo, otros equipos o una intervención manual.
Conviene inventariar las fuentes disponibles: valores de proceso, alarmas, eventos, históricos, registros de mantenimiento, manuales, procedimientos y notas de turno. Para cada fuente deben conocerse su propietario, formato, ubicación y condiciones de acceso.
El inventario también revela vacíos. Si cierta información no se registra, un modelo no puede reconstruirla de manera confiable únicamente a partir de señales indirectas.
4. ¿La resolución temporal permite reconstruir lo ocurrido?
Para analizar una secuencia no basta con disponer de los valores correctos: también deben poder ordenarse con consistencia temporal.
Es necesario revisar la frecuencia de muestreo, el registro por eventos, la sincronización de relojes y las transformaciones realizadas por historiadores o plataformas intermedias. Debe distinguirse entre la hora en que ocurrió un evento y aquella en que fue almacenado.
La resolución necesaria depende del caso. Un resumen diario y la investigación de una transición rápida requieren escalas de tiempo distintas.
5. ¿Cómo se comportará la solución cuando falten datos?
En planta pueden existir periodos sin comunicación, valores congelados, sensores fuera de servicio, cambios de nomenclatura o documentos desactualizados. La solución debe reconocer estas condiciones en lugar de presentar una respuesta incompleta como concluyente.
Antes del piloto, conviene acordar reglas para señalar datos ausentes, detectar entradas fuera de vigencia y comunicar incertidumbre. Una respuesta prudente puede indicar qué evidencia utilizó, qué información falta y qué comprobación requiere una persona.
También debe definirse qué sucederá si el componente de IA no está disponible. El control no debería depender accidentalmente de una asistencia que no fue diseñada como función crítica.
6. ¿Quién conserva la responsabilidad de la decisión?
La interfaz debe distinguir entre un hecho registrado, una correlación, una hipótesis y una recomendación. Mezclar estas categorías puede dar a una inferencia más autoridad de la que merece.
Cada caso necesita responsables para revisar resultados, autorizar accesos y atender comportamientos inesperados. Operación, automatización, mantenimiento y el proveedor pueden tener funciones diferentes; documentarlas evita supuestos durante la puesta en marcha.
Cuando el caso lo requiera, la trazabilidad debe incluir las entradas utilizadas, la configuración aplicada, la respuesta generada y la validación humana.
7. ¿Cómo se decidirá si el piloto funciona?
Los criterios de aceptación deben establecerse antes de observar los resultados. Pueden incluir la capacidad de recuperar evidencia relevante, ordenar correctamente una secuencia o abstenerse cuando la información sea insuficiente.
La evaluación debe utilizar casos representativos, incluidos escenarios incompletos o ambiguos. También conviene comparar la solución con el proceso actual y registrar errores, no solo ejemplos favorables.
El cierre del piloto debe admitir tres decisiones legítimas: avanzar, ajustar o detener. Una demostración convincente por sí sola no justifica una integración en producción.
Qué validar en tu planta
Antes de diseñar una conexión con el PLC, reúne a operación, automatización, mantenimiento y seguridad para confirmar:
- La pregunta operativa y el usuario responsable.
- Los límites entre observar, recomendar y actuar.
- Las fuentes disponibles, su contexto y sus propietarios.
- La calidad y resolución temporal de los datos.
- El comportamiento ante información ausente o servicios no disponibles.
- Los permisos, registros y revisiones humanas necesarios.
- Los casos de prueba y criterios para continuar o detener el piloto.
La arquitectura debe partir de estos límites. La tecnología puede elegirse después, cuando el equipo ya sabe qué información necesita, qué riesgos debe contener y cómo reconocerá una respuesta útil.