Tengo la información pero… no entiendo nada
Asumamos el problema de fondo: los que somos muy técnicos nos movemos encantados entre pantallas con gráficos, nodos y conexiones, y amamos ver cómo los indicadores suben y bajan con el tiempo. Pero no todo el mundo quiere (ni debe) saber todo lo que dicen esos complejos diagramas. Ahí es donde los LLM nos ayudan a simplificar la interacción de las personas y las máquinas mediante un lenguaje común.
En nuestro día a día ya lo tenemos asumido, pero ¿qué pasa dentro de nuestros sistemas? ¿Estamos integrados con ellos para poder hablarles en nuestro idioma? Aquí entran los MCP. Ya se ha escrito mucho sobre ello, lo que pretendemos es mostraros un ejemplo claro de aplicación en uno de los muchos entornos donde todavía queda camino por recorrer.
Aun así, por hacer una breve introducción, resumamos el protocolo MCP (Model Context Protocol) como un estándar abierto que define cómo un asistente IA se conecta a datos y fuentes externas. Es decir, con este estándar podríamos definir cómo poder preguntarle cosas a nuestros sistemas en lenguaje natural.
El mundo industrial ya se está subiendo. Ya existen conectores MCP abiertos para protocolos industriales como OPC UA, y en general la mayoría de productos ya incorporan el MCP internamente. Pero, ¿podemos crear ese tipo de integración con nuestros sistemas actuales?
La demo: veamos un ejemplo
Para no quedarnos en la teoría, hemos construido un escenario ilustrativo (OJO: no es un escenario real, es una demostración que hemos montado para enseñar el concepto de forma concreta).
Simulamos una línea de producción ficticia (“Línea 1”) con datos que evolucionan en el tiempo: velocidad (RPM), temperatura de motor, piezas producidas, y estado de parada con su motivo. Lo exponemos igual que lo haría un SCADA real: mediante OPC UA, el protocolo estándar de facto para intercambiar datos entre sistemas industriales.
Sobre esos datos, construimos un servidor MCP a medida que no expone los nodos técnicos en crudo, sino herramientas de negocio ya traducidas: en vez de tener que saber que el tag se llama Linea1.TemperaturaMotor, el asistente puede responder directamente a “¿cómo va la línea?” o “¿hay algo que deba vigilar?”.
Simulamos un escenario con un posible problema real: la línea funciona con normalidad, luego la temperatura del motor empieza a subir de forma gradual, y finalmente se detiene por sobretemperatura. Esto nos permite mostrar tres momentos distintos:
1. Todo va bien
2. El aviso temprano: aquí está el verdadero valor
3. El incidente, explicado sin ir al PLC
Un matiz importante: OPC UA no es un SCADA, es el protocolo de comunicación que un SCADA (u otros sistemas como un ERP o un histórico) puede usar para intercambiar datos de forma segura y estandarizada entre fabricantes distintos. Nuestra demo simula ese nivel de comunicación, no un SCADA completo, y es justo esa pieza (el protocolo de datos) la que un servidor MCP necesita para poder “hablar” con la planta.
¿Y cómo le podemos sacar provecho?
Esta misma arquitectura se conecta igual a un ERP, a un CRM, o a cualquier sistema que exponga sus datos de forma estructurada. La parte de “traducir datos a preguntas de negocio” es la que realmente aporta valor, sea cual sea el sistema de origen.
No hace falta que salgas corriendo a conectar tu SCADA a un asistente de IA mañana. Pero sí merece la pena empezar a hacerse algunas preguntas:
- ¿Tenemos ya nuestros datos de planta expuestos de forma estructurada, o viven aislados en sistemas que no se hablan entre sí?
- ¿Quién en la empresa tendría que consultar estos datos con más frecuencia si fuera tan fácil como preguntar?
- ¿Qué controlamos hoy sobre quién puede acceder a qué dato, y estamos preparados para extender ese control a un asistente de IA?
Esta última pregunta no es menor. Un servidor MCP mal diseñado puede fallar de formas poco evidentes; nosotros mismos nos encontramos, construyendo esta misma demo, con que una reconexión de red mal gestionada dejaba el asistente “ciego” sin ningún aviso claro. No es solo cuestión de conectar y ya está: hay que diseñarlo pensando en fallos reales, en permisos, y en qué pasa cuando algo se cae.
Preguntas como estas son justo las que nos gusta pensar con cada cliente, caso a caso.
Como siempre, si te apetece conversar sobre este tema o cualquier otro, te invitamos a contactar con nosotros en cualquier momento y estaremos encantados de charlar sobre tecnología.
