Recomendaciones: el módulo de acciones de operación de Captia.ai

Cómo funciona el módulo de recomendaciones dentro de Captia.ai

El módulo ocupa un lugar muy concreto en la plataforma: se sitúa después de los dashboards, las reglas y las alertas, y antes de la acción. Una alerta dice que algo se sale de lo esperado. Una recomendación va un paso más allá y dice qué se puede hacer al respecto, con qué justificación y con qué prioridad frente a lo demás que está abierto en la planta en ese momento. Esa distinción entre avisar y proponer es la razón de ser del módulo.

La materia prima son dos cosas. La primera es el estado actual: las señales que Captia Connect adquiere en el edge sobre los protocolos disponibles en la instalación (MQTT, OPC UA, Modbus TCP, Modbus RTU sobre RS-485, OpenWebNet, IEC 870-5-102, API REST, webhooks o ficheros CSV), normalizadas en series temporales y enviadas con buffering local. La segunda es el comportamiento histórico de cada línea, ya consolidado en la plataforma. El módulo compara lo que la línea está haciendo ahora con lo que esa misma línea ha hecho antes en circunstancias comparables, y lo hace apoyándose en los modelos industriales de Captia.ai, que son los que aportan la representación del proceso: qué activos existen, qué relación tienen entre sí y qué rangos de operación son admisibles.

La salida no es una consigna que baje al PLC. Es una propuesta que aparece en el Operator Layer de la plataforma, dirigida a una persona con un rol concreto, y que solo se convierte en acción cuando esa persona la acepta. A partir de ahí la ejecución usa los mecanismos que ya existen en Captia.ai: una regla, un workflow, un aviso a mantenimiento o, sencillamente, un cambio manual que el operario registra. La aceptación o el rechazo quedan como eventos en el histórico, con lo cual el propio comportamiento de la planta frente a las recomendaciones pasa a ser un dato más.

Qué contiene una recomendación y por qué importa la trazabilidad

Una recomendación sin su porqué es una orden anónima, y en un entorno industrial una orden anónima se ignora o, peor, se obedece sin criterio. Por eso cada propuesta del módulo se acompaña de los elementos que permiten auditarla después: la observación que la dispara, la referencia histórica contra la que se compara, el modelo industrial implicado y el margen de operación dentro del que la acción es admisible. Si seis meses después alguien pregunta por qué se cambió una secuencia de arranque, la respuesta está en el histórico, no en la memoria de quien estaba de turno.

Requisitos de datos: qué hace falta antes de activarlo

El primer requisito no es de dato, es de gobierno: tiene que existir un rol que reciba las recomendaciones y que tenga autoridad para aceptarlas o rechazarlas. La gestión de usuarios y roles de Captia.ai resuelve la parte técnica, pero la parte organizativa la decide la planta. Un módulo que propone acciones a nadie en particular produce una bandeja de entrada que se llena y no se vacía.

El segundo es el histórico por línea con continuidad. El módulo compara el presente con el pasado de esa misma línea, de modo que sin pasado no hay término de comparación y la propuesta se degrada a una regla genérica, que es algo que la plataforma ya sabe hacer sin módulo de IA. La continuidad importa tanto como el volumen: un histórico con huecos deja precisamente fuera los episodios anómalos, que son los más informativos. Aquí es donde el buffering local de Captia Connect deja de ser un detalle de infraestructura y pasa a ser una condición de calidad del dato.

El tercero es que los modelos industriales estén construidos. El módulo no infiere la estructura de la planta a partir de las señales: se apoya en la representación que ya existe en la plataforma, con sus activos, sus líneas y sus relaciones. Una señal suelta sin activo asociado puede vigilarse con una alerta, pero no genera una recomendación interpretable, porque no hay nada sobre lo que actuar.

El cuarto es el contexto de operación: turno, calendario, estado de máquina, producción registrada, y en su caso lo que llegue por API desde ERP, MES, CRM o SAP. Sin ese contexto el módulo puede detectar que algo se comporta distinto, pero no puede decidir si lo que procede es actuar o esperar, que es justamente lo que se le pide.

El quinto es más incómodo de reunir y suele olvidarse: las restricciones. Qué no se puede tocar, en qué franjas, con qué autorización. Sin ese conjunto declarado, el módulo propondrá acciones formalmente correctas y operativamente inaceptables, y bastarán dos o tres para que la planta deje de leerlo.

Casos de aplicación industrial

El caso más directo es la priorización del turno. En una planta con varias líneas hay siempre más avisos abiertos que capacidad de atenderlos, y la decisión real no es qué está mal sino qué se atiende primero. El módulo ordena lo abierto según el estado actual y el comportamiento histórico de cada línea, y esa ordenación es en sí misma la recomendación. Es el caso donde antes se nota el módulo, porque no exige cambiar nada del proceso.

El segundo es la reacción ante una desviación ya detectada. Cuando el módulo de detección de anomalías marca un comportamiento fuera de patrón, la pregunta inmediata del responsable de turno es qué hacer. El módulo de recomendaciones recupera qué se hizo las veces anteriores en esa misma línea y cómo acabó cada una, y propone la línea de actuación que el histórico respalda.

El tercero es el ajuste de parámetros de operación dentro de márgenes ya autorizados: secuencias de arranque, escalonamiento de equipos auxiliares, consignas que admiten un rango. Aquí la recomendación convive con el módulo de optimización de producción y consumo, que busca el punto de operación, mientras que el módulo de recomendaciones se ocupa de que ese punto llegue a una persona en forma de acción concreta y con su justificación.

El cuarto es la conservación del criterio operativo. En plantas con relevo generacional o con alta rotación de turno, buena parte del saber hacer vive en la cabeza de unas pocas personas. Cuando las decisiones y sus resultados quedan registrados, el histórico deja de ser solo una serie de medidas y pasa a contener también qué se hizo y qué funcionó. El módulo se apoya en ese registro para que un turno nuevo no tenga que redescubrir lo que la planta ya aprendió.

Si lo que se busca es entender la disciplina antes que el módulo, la guía de cómo aplicar la inteligencia artificial en una fábrica plantea el marco de decisión completo; esta página se limita a lo que hace el módulo dentro de la plataforma.

Cómo se implanta por fases

La implantación sigue las fases generales de la plataforma, descritas en el hub de plataforma de datos industriales. Este módulo llega tarde a propósito: es el último que se activa, porque consume el resultado de todos los anteriores.

1. Diagnóstico. Además del inventario de señales y protocolos, aquí se levanta el mapa de decisiones: qué se decide hoy en planta, quién lo decide y con qué información. Sin ese mapa no se sabe qué recomendación tendría destinatario.
2. Despliegue del edge. Captia Connect en planta, adquisición, normalización y buffering. A partir de aquí existe histórico por línea.
3. Puesta en marcha de la plataforma. Dashboards por activo, línea, rol o planta, usuarios y roles, reglas y alertas. La planta ve su estado y define quién responde de qué.
4. Modelos industriales. Representación de activos, líneas y relaciones, con sus rangos admisibles. Es el prerrequisito específico de este módulo y el paso que más suele subestimarse.
5. Recomendaciones en modo observación. El módulo empieza proponiendo sin que nada dependa de sus propuestas. La planta las lee, las acepta o las rechaza, y ese contraste se usa para ajustar el alcance antes de que nadie dependa de él.
6. Operacionalización. Las recomendaciones aceptadas se enlazan con workflows, reporting e integración por API con ERP o MES, de modo que la acción decidida no requiera pasos manuales de transcripción.

El diseño de esa cadena de decisión, cuando excede lo que la plataforma resuelve de serie, es un trabajo de ingeniería que llevamos como servicio de automatización operacional; cuando lo que se busca es un agente con alcance acotado sobre un proceso concreto, el encaje está en agentes de IA.

Límites y cuándo no aplica

Este módulo es el que más fácilmente se sobrevende, así que conviene acotarlo sin ambigüedad. No aplica, o aporta poco, en estos escenarios:

• Cuando se espera control automático en lazo cerrado. El módulo propone; no actúa por su cuenta sobre el proceso. Si lo que hace falta es que una consigna se modifique sola en milisegundos, eso es control, vive en el PLC o en el sistema de control y no es lo que hace este módulo.
• Sin histórico por línea. Con señales recién conectadas no hay contra qué comparar el presente. Durante ese periodo el valor está en los dashboards y las reglas, no aquí.
• Sin modelos industriales construidos. Si la plataforma no sabe qué activos hay ni cómo se relacionan, la propuesta no puede referirse a nada concreto. Lo que falta entonces es modelado, no analítica.
• Cuando la decisión no tiene dueño. Una recomendación dirigida a un rol inexistente o sin autoridad para aceptarla no llega nunca a acción. Este es el motivo más frecuente por el que un despliegue técnicamente correcto no produce ningún cambio.
• Cuando el margen de operación es nulo. Si el proceso no admite variar secuencia, horario ni consigna por restricciones de calidad, seguridad o contrato, no hay espacio para recomendar. La información sigue sirviendo para justificar inversión, pero no para operar distinto mañana.
• Cuando el problema es de equipo o de diseño. Ninguna recomendación operativa compensa un activo mal dimensionado o una instalación mal planteada. El módulo hará visible el síntoma; la corrección es de ingeniería.
• Cuando se busca una respuesta a una pregunta nueva. El módulo se apoya en el comportamiento histórico de la planta. Ante una situación sin precedente en el histórico (un producto nuevo, una reforma reciente, un equipo estrenado) sus propuestas pierden respaldo y deben leerse como tales.

Y el límite que da forma a todo lo demás: una recomendación no es una consigna. La plataforma está construida para que la decisión siga siendo de la persona que responde de la línea, y la traza de esa decisión forma parte del producto, no es un añadido opcional.