CrossnoKaye hace que su agente de IA en fábricas calcule en un sandbox de Python y no «de cabeza» como un LLM

Si ha intentado conectar un agente LLM a un sistema industrial, sabe cómo suele acabar. Los datos están en historians (almacenes de series temporales) con nombres de tags enrevesados. La lógica del equipo está incrustada en el código propietario de los controladores, que una herramienta externa no puede ver. Y dar acceso a todos los sistemas a la vez supone dispersar credenciales por toda la red de la planta. CrossnoKaye ha resuelto el problema sin «acoplar» un agente por fuera: lo ha integrado en su propia plataforma.

Un agente dentro de la plataforma, no fuera

ATLAS es una plataforma de automatización definida por software. En la planta hay un clúster local de Kubernetes que ejecuta los escenarios básicos de control (máquinas de estados, secuencias, límites, enclavamientos) sobre los PLC y DCS existentes. El cliente no tiene que sustituir el hardware. La pasarela edge solo envía datos hacia fuera y no abre ningún puerto entrante. Si se pierde la conexión con la nube, la planta sigue funcionando con la lógica local.

El agente AURA vive en el mismo perímetro de seguridad, sobre Amazon EKS. Lee el estado de la planta a través de una pasarela de datos única, con los permisos del usuario que hace la consulta. Ahí están la topología del equipo, la lógica de enclavamientos desplegada, las lecturas físicas y calculadas, el historial de alarmas y la documentación en Bedrock Knowledge Bases.

El contexto lo cambia casi todo. En una cantera, la trituradora secundaria se detuvo dos veces en un turno después de la terciaria. Según las marcas de tiempo, parecía que la culpable era la trituradora. Pero AURA veía el esquema de las cintas y los enclavamientos. La cinta de recirculación situada bajo la trituradora terciaria patinaba, saltaba la protección por sobrecarga y un enclavamiento aguas arriba paraba la secundaria para no sepultar la máquina detenida. Enviaron al operador a la cinta y el problema se resolvió en minutos.

Que calcule el código, no el modelo

Un LLM interpreta bien el contexto de ingeniería y planifica una investigación, pero no puede calcular de forma fiable estadísticas ni balances sobre millones de lecturas dentro del prompt. Por eso AURA escribe Python y lo ejecuta en Code Interpreter de Amazon Bedrock AgentCore. Se trata de microVM aisladas y gestionadas por AWS. Además, hay Bedrock Guardrails y capas de protección en el borde.

Hay dos decisiones que resultan útiles también fuera de la industria.

Sandboxes calientes y desechables. En un chat interactivo, el ingeniero comprueba hipótesis paso a paso: carga un día de alarmas de 94 plantas, filtra los sensores de nivel «oscilantes», cruza las paradas de compresores con la temperatura de bulbo húmedo. Un arranque en frío en cada turno borraría las tablas de la memoria.

Por eso cada conversación se vincula a una única sesión viva de AgentCore con un TTL flotante de 15 minutos; si el usuario vuelve tras una pausa, se crea una nueva. Con las Tasks programadas y las Routines nocturnas ocurre lo contrario. Se necesita reproducibilidad, así que cada ejecución corre en una microVM nueva que se detiene nada más terminar el cálculo.

Eso evita fugas de estado entre ejecuciones y el coste de un sandbox inactivo.

Contratos de datos en lugar de texto de stdout. Las primeras versiones, en las que el modelo imprimía un JSON o un resumen en la salida estándar, resultaron frágiles. El modelo confundía nombres de columnas, perdía parte de la ventana temporal o rompía el formato para generar gráficos.

Ahora el orquestador comprueba de antemano el contrato de entrada y carga en el sandbox hasta 50 conjuntos de datos. Al script del modelo le añade una capa de verificación que comprueba que cada tabla declarada existe como pandas.DataFrame con las columnas y los tipos requeridos, y la guarda en Parquet.

Si el script falla o falta una columna, el usuario no verá cifras erróneas. Un workflow en Temporal convierte el traceback y la discrepancia de esquema en una solicitud estructurada, y el agente corrige el código y relanza el cálculo.

Qué aporta en la práctica

Un ejemplo con la flota: al analizar las averías críticas de 94 plantas en un día, el código agrupó los eventos por instalación, regla e intervalos entre activaciones. En lugar de un ranking por número de alarmas, resultó que las 103 activaciones de una planta eran dos reglas repetitivas de nivel en un depósito. En otra, 58 activaciones (amoníaco, evaporadores, válvulas de gas caliente) se produjeron en un solo segundo. Ahí es donde hay un fallo en cascada del equipo.

AURA también lanza Routines, observadores en segundo plano que actúan según un calendario, umbrales y modos del equipo. Abren por sí solos una investigación en modo de solo lectura. Antes de enviar un informe (Brief), el sistema comprueba que cada enlace apunta a una ventana de telemetría guardada.

Limitaciones y conclusión

Las cifras de un aumento de la producción del 11–17 %, una reducción del consumo energético del 21 % y cero incidentes de seguridad por millón de horas son afirmaciones de la propia CrossnoKaye. Se refieren a toda la plataforma APC, no al agente por separado. Además, la descripción depende mucho del stack de AWS: VPC Lattice, MSK, SQS, EKS, AgentCore. Conviene recordar también que en CrossnoKaye esta arquitectura funciona sobre una plataforma ya lista con un modelo unificado de la planta, y la mayoría de las empresas no tiene esa base.

Hay tres lecciones universales. Primera: el agente necesita acceso a la estructura del sistema, no solo a los logs. Segunda: conviene calcular cualquier afirmación numérica en un entorno aislado. Tercera: es mejor aceptar el resultado del sandbox solo a través de un esquema y un validador, y devolver el error al agente para que se corrija solo. Estas prácticas sirven también para finanzas, logística y cualquier análisis en el que un error en una cifra sale caro.