IA local con datos de un PLC o un SCADA: arquitectura, modelos y límites
Cómo hacer que un modelo de lenguaje que corre dentro de la planta responda preguntas con datos de PLC y SCADA: la arquitectura en cinco capas, qué hardware hace falta, qué modelos caben, por qué la IA no debe escribir en el PLC y cómo empezar en un mes.

Descarga la planilla de este artículo
Política de uso de IA en la planta
La gente ya usa ChatGPT en la planta y no sabes qué datos están entrando ni qué te exige la Ley 21.719.
Para usar un modelo de IA local con datos de un PLC o un SCADA no se conecta el modelo al PLC. Se pone una capa en medio: algo que lee el PLC o el SCADA por su protocolo (Modbus, OPC UA, MQTT), guarda la serie de tiempo, y le ofrece al modelo un puñado de herramientas de solo lectura, como «dame la temperatura del túnel 2 en la última hora» o «lista las paradas de la línea 1 de hoy». El modelo corre en un equipo con GPU dentro de la planta, decide qué herramienta usar y redacta la respuesta. Nunca escribe en el PLC.
Esta guía explica esa arquitectura, qué hardware y qué modelos hacen falta, qué cosas sí resuelve un modelo local y cuáles no, y cómo empezar con un piloto acotado.
¿Por qué un modelo local y no ChatGPT? #
Hay tres razones, y ninguna es que el modelo local sea más inteligente: no lo es.
- Los datos no salen de la planta. Recetas, velocidades de línea, consumos y paradas son información sensible. Con un modelo local, la pregunta y los datos se procesan dentro de la red de la planta. Si además hay datos personales, como turnos o nombres de operadores, la Ley 21.719 obliga a pensar qué sale y con qué base legal; lo explicamos en ¿Es seguro usar ChatGPT con datos de mi planta?.
- Funciona sin internet. Una planta en una zona rural o una faena con enlace satelital no puede depender de la nube para consultar su propio proceso.
- El costo es fijo. El modelo corre en hardware propio; no hay cobro por cada consulta.
La contrapartida es real: los modelos que caben en una GPU de planta razonan peor que los modelos de frontera en la nube. Por eso conviene una arquitectura donde el modelo local hace lo que hace bien —entender la pregunta, elegir la herramienta, redactar— y los números los calcula el sistema, no el modelo.
La arquitectura en cinco capas #
| Capa | Qué hace | Con qué se hace |
|---|---|---|
| 1. Lectura | Lee el PLC o el SCADA sin modificar su programa | Modbus TCP/RTU, OPC UA, MQTT, Sparkplug B, o la base de datos del SCADA |
| 2. Historia | Guarda cada variable con fecha y hora | Una base de series de tiempo (TimescaleDB, InfluxDB) o el historiador que la planta ya tenga |
| 3. Contexto | Dice qué es cada señal: «%MW120 es la temperatura del túnel 2, en décimas de grado» | Un modelo de datos o grafo de la planta, y los manuales y procedimientos indexados para búsqueda (RAG) |
| 4. Herramientas | Expone consultas de solo lectura que el modelo puede pedir | Un servidor MCP (Model Context Protocol) o funciones con esquema JSON |
| 5. Modelo | Entiende la pregunta, llama a las herramientas y redacta | Un modelo abierto servido con Ollama, llama.cpp o vLLM en un equipo con GPU |
La capa que más se subestima es la tercera. Un PLC entrega registros, no significados. Si el modelo recibe «registro 40121 = 734», no sabe que es 73,4 °C ni que corresponde al túnel 2. El trabajo de mapear señales a nombres, unidades y equipos es lo que separa un experimento de algo que el jefe de turno puede usar. Lo desarrollamos en cómo conectar un PLC y en qué es la telemetría industrial.
¿Por qué el modelo no debe escribir en el PLC? #
Un modelo de lenguaje se equivoca de formas que no son predecibles: confunde unidades, inventa un registro que no existe o interpreta mal una instrucción ambigua. En una planilla eso es un error; en un variador o en una válvula es un accidente.
La regla que usamos es simple: la IA propone, una persona aprueba, el sistema de control ejecuta. En la práctica:
- Las herramientas que ve el modelo son de solo lectura. No existe una función «escribir registro».
- La conexión al PLC sale de un equipo en una red separada, con un usuario que solo tiene permiso de lectura cuando el protocolo lo permite (OPC UA lo permite; Modbus no, así que el aislamiento se hace por red).
- Si el modelo sugiere un cambio de consigna, el cambio lo hace un operador desde el HMI, como siempre.
El modelo Purdue sigue aplicando: el equipo de IA vive en el nivel de operaciones, no en el de control. Lo explicamos en cómo defender un PLC Modbus.
Digitaliza tu Planta con iGromi
Agenda una demo de 30 min y descubre cómo aumentar tu productividad.
¿Qué hardware hace falta? #
Depende del tamaño del modelo, no del número de PLC. Leer cientos de variables lo hace cualquier PC industrial; lo que pide GPU es el modelo de lenguaje.
| Equipo | Qué modelo cabe | Para qué alcanza |
|---|---|---|
| PC industrial sin GPU | Modelos de 1 a 4 mil millones de parámetros, lentos | Pruebas; respuestas de varios segundos a decenas de segundos |
| GPU de 12 a 16 GB | Modelos de 7 a 14 mil millones de parámetros, cuantizados a 4 bits | Consultas de turno con herramientas, búsqueda en manuales |
| GPU de 24 GB o dos GPU | Modelos de 27 a 32 mil millones de parámetros | Razonamiento más largo, informes, varias personas consultando a la vez |
Un dato medido por nosotros: en nuestro banco de laboratorio de septiembre de 2026, con una GPU de 16 GB, el modelo abierto Qwen3.5 de 9 mil millones de parámetros en 4 bits respondió bien 10 de 10 preguntas cerradas de percepción y lectura a unos 70 tokens por segundo, usando cerca de 7 GB de memoria de video. Un modelo de 27 mil millones aplastado para que cupiera en la misma GPU respondió peor. Más grande no es mejor cuando no cabe. Es una prueba de banco con una muestra chica, no una garantía de desempeño en una planta.
Para elegir el equipo físico, la guía de PC industrial para visión artificial sirve también para IA local: temperatura, polvo, alimentación y montaje pesan tanto como la GPU.
¿Qué preguntas responde bien y cuáles no? #
| Responde bien | Responde mal o no debe responder |
|---|---|
| «¿Cuántas paradas tuvo la línea 2 este turno y cuál fue la más larga?» | «Calcula el OEE del mes» sin una herramienta que lo calcule: el modelo sumará mal |
| «¿Qué dice el manual del variador sobre la falla F004?» | «Sube la velocidad de la línea»: no debe tener cómo hacerlo |
| «Compara el consumo del compresor 1 hoy contra el promedio de la semana» | «¿Por qué se quemó el motor?» sin datos de vibración ni corriente: inventará una causa |
| «Resume lo que pasó en el turno de noche para el jefe de planta» | Diagnósticos de seguridad que exigen a un especialista |
La regla práctica: si la respuesta es un número, el número lo calcula una herramienta y el modelo solo lo cita. Si la respuesta es un texto, el modelo cita de qué documento o de qué serie la sacó.
¿Cómo empezar en un mes? #
- Semana 1. Elegir una línea y diez preguntas. Las que hoy el jefe de turno responde llamando por radio o abriendo tres pantallas. Escribirlas tal como se dicen en la planta.
- Semana 2. Leer y nombrar las señales que esas preguntas necesitan. Normalmente son entre 20 y 60. Guardarlas con fecha y hora y con nombre, unidad y equipo.
- Semana 3. Escribir las herramientas de solo lectura y montar el modelo. Una herramienta por tipo de pregunta, no una por señal.
- Semana 4. Probar con las diez preguntas y medir. Cuántas respondió bien, cuántas mal y cuántas dijo «no tengo ese dato». Una respuesta honesta de «no sé» vale más que una inventada.
Antes de dar acceso a la planta entera, conviene tener por escrito qué se puede preguntar y qué no. La política de uso de IA en la planta que ofrecemos gratis parte de esa pregunta.
¿Qué hace iGromi? #
iGromi OS hace las cuatro primeras capas dentro de la planta: lee PLC, sensores, cámaras y SCADA con los protocolos de arriba, guarda la historia, mantiene el contexto de qué es cada señal en el Segundo Cerebro de la planta y expone herramientas de solo lectura por MCP, documentadas en la página para desarrolladores. El modelo puede ser uno local en el equipo Edge o uno de frontera en la nube; en ese caso al modelo le llega la pregunta con los fragmentos necesarios para responderla, no la base completa. En ningún caso la IA controla directamente una máquina.
Preguntas frecuentes #
¿Puedo conectar Ollama directamente a un PLC?
No conviene. Ollama sirve el modelo; no habla Modbus ni OPC UA, y no sabe qué significa cada registro. Entre ambos debe haber una capa que lea el PLC, guarde la historia y ofrezca herramientas de solo lectura.
¿Qué es MCP y para qué sirve en una planta?
MCP (Model Context Protocol) es un estándar abierto para que un modelo de lenguaje descubra y llame herramientas externas. En una planta permite exponer consultas como «temperatura del túnel 2» de forma uniforme, sin importar qué modelo se use.
¿Un modelo local sirve si la planta no tiene internet?
Sí. Esa es una de sus razones de ser. El modelo, la historia y las herramientas corren en la red de la planta.
¿La IA puede ajustar parámetros del proceso?
Puede sugerirlos con datos. El cambio lo aprueba y lo hace una persona desde el sistema de control.
¿Qué modelo abierto conviene usar?
El que quepa entero en la GPU disponible con cuantización de 4 bits y soporte llamadas a herramientas. Hoy, en 12 a 16 GB, los modelos de 7 a 14 mil millones de parámetros son el punto de partida razonable. Conviene medir con preguntas propias antes de decidir: los rankings públicos no miden lo que pregunta un jefe de turno.


