IA aplicada a IoT industrial: los cuatro patrones que sí funcionan en producción (y los que prometen y no entregan)

Si su operación ya captura telemetría y ya tiene dashboards y analítica, el siguiente paso lógico es preguntarse: ¿qué puede predecir o automatizar la IA sobre estos datos? Y aquí es donde la conversación se vuelve confusa, porque la palabra “IA” en 2026 abarca desde un isolation forest de 200 líneas hasta un agente autónomo conectado a tres LLMs.

Este post es honesto sobre los cuatro patrones que sí entregan ROI en operaciones IoT industriales —los que ya hemos puesto en producción— y los que prometen mucho pero no entregan para este tipo de cliente.

Antes de IA: tenga datos limpios

Si saltó directo aquí sin tener analítica básica funcionando, devuélvase. Los modelos predictivos sobre datos sucios aprenden el ruido en lugar de la señal. Antes de cualquier piloto IA serio, asegúrese de tener:

• 6+ meses de telemetría consistente capturada.
• Una capa de analítica histórica donde los datos ya estén normalizados.
• Un equipo de operación que sepa interpretar los dashboards actuales.

Cubrimos esa base en analítica de datos industriales. Si todavía no la tiene, ese es el primer proyecto, no este.

Los cuatro patrones que sí funcionan

1. Mantenimiento predictivo sobre series de tiempo

Lo que la gente cree: que se necesita una red neuronal profunda con millones de parámetros.

Lo que funciona en la realidad: anomaly detection clásico (isolation forest, autoencoder simple, even rolling statistics) sobre vibración, temperatura, corriente o consumo.

El caso típico: un HVAC, un motor o un transformador con telemetría continua. El modelo aprende el comportamiento “normal” durante 60-90 días, y a partir de ahí marca desviaciones. No predice fallas con semanas de anticipación —eso es vendido por consultores que nunca lo midieron—, pero sí adelanta entre 2 y 7 días la detección frente al método actual (inspección visual o falla súbita).

Stack: scikit-learn (IsolationForest, OneClassSVM), PyOD si quiere algo más rico. PyTorch solo si tiene volumen masivo y patrones complejos.

Cuándo NO usarlo: si la telemetría llega cada 5 minutos en un equipo cuyas fallas se desarrollan en segundos (algunas vibraciones de rodamiento), no va a predecir nada. La frecuencia de muestreo manda.

2. Computer vision sobre el CCTV que ya tiene

Lo que la gente cree: que se necesitan cámaras industriales certificadas y un proyecto de visión de USD 80k.

Lo que funciona en la realidad: las cámaras IP que ya tiene + un NVIDIA Jetson Orin (USD 500-1.500) corriendo YOLO afinado para su caso. Detección de:

• EPP (casco, chaleco, gafas) en zonas de obra o planta.
• Conteo de personas en accesos, filas, comedores.
• Intrusión en zonas restringidas fuera de horario.
• Defectos en línea de producción (al final del transportador, antes del empaque).
• Patrones de carga en muelles logísticos.

La inferencia corre en el Jetson, no en la nube. Solo suben los eventos relevantes (“persona sin casco a las 14:23 en cámara 3, foto adjunta”). Esto es clave en sitios con poco ancho de banda — link directo con conectividad multi-Starlink.

Stack: YOLO (v8 o v11 según hardware), OpenCV para pre/post procesado, Jetson Orin Nano o Coral TPU como acelerador, MQTT para enviar eventos al backend.

Lo difícil: etiquetar el dataset inicial (200-1.000 imágenes por clase). Hay que invertir tiempo de un operador real, no se puede saltar.

3. Anti-fraude con isolation forest (caso real)

Esto ya lo pusimos en producción. En el caso de telemetría de flota extendimos el sistema con un modelo de isolation forest sobre los patrones históricos de tanqueo y consumo. El modelo aprende el comportamiento normal de cada vehículo (consumo esperado según ruta, hora y carga) y marca desviaciones para revisión humana.

Resultados medidos:

• Detección de fraudes escalada a toda la flota sin reglas duras.
• Falsos positivos reducidos cerca de 60% vs los umbrales fijos iniciales.
• Inferencia cada hora en el backend; sin GPU.

El mismo patrón funciona para anti-fraude de combustible en estaciones de servicio (reconciliación entre tanqueos al cliente y caída de nivel real en el tanque) y para detección de mermas anómalas en cadena de frío.

Stack: scikit-learn, PostgreSQL para features, un microservicio Python que corre cada hora vía cron o Airflow.

Cuándo NO usarlo: si solo tiene 30 días de historia, el modelo no aprende lo suficiente. Espere a tener al menos 6 meses.

4. LLM + RAG sobre manuales y runbooks

Este es el patrón más nuevo y al que hay que tenerle más respeto, porque es donde más se promete y menos se entrega.

Lo que sí funciona:

• Asistente operativo de campo: el técnico pregunta “¿cuál es el procedimiento de purga del intercambiador HX-202?” y recibe la respuesta extraída del manual del fabricante. Sin esperar a que soporte conteste.
• Consulta de logs históricos: “¿cuándo fue la última vez que la celda 4 reportó alarma de presión alta?” y el sistema responde con citas.
• Documentación de incidentes: el operador describe el síntoma, el sistema sugiere el runbook más cercano.

Stack: un LLM (Claude, GPT, o un modelo open source como Llama 3 cuando hay restricción on-premise) + LangChain o LlamaIndex + base vectorial (Postgres pgvector basta para empezar) sobre sus manuales, logs y wikis internas.

Lo que NO funciona:

• Agentes autónomos que ejecutan acciones críticas sin supervisión.
• “Chatear con la planta” en lenguaje natural sin trabajo previo de modelado de datos.
• LLMs que decidan parámetros de control de proceso.

El LLM acelera la consulta de documentación, no reemplaza al ingeniero de proceso.

Edge vs cloud: cuándo cada uno

Escenario	Edge gana	Cloud gana
Sitio rural con BW limitado	✅	❌
Inferencia con latencia < 100 ms	✅	❌
Dataset masivo, entrenamiento mensual	❌	✅
Sector regulado (datos sensibles)	✅	depende
Modelo complejo (>1GB, GPU dedicada)	costoso	✅
Múltiples sitios homogéneos	híbrido	✅

La regla práctica: inferencia en edge, entrenamiento en cloud. El Jetson o Coral en el sitio ejecuta el modelo; el reentrenamiento mensual ocurre en la nube con los datos consolidados.

Y si su sitio depende de conectividad satelital, edge no es opcional — es la diferencia entre un sistema que funciona y uno que se cae cada vez que llueve. Lo cubrimos en Multi-Starlink Bonding.

Lo que NO hacemos

Como decisión deliberada de honestidad técnica:

• No vendemos “transformación digital con IA” ni hojas de ruta corporativas a 3 años. Vendemos modelos concretos sobre equipos concretos.
• No hacemos chatbots de servicio al cliente. Hay agencias que lo hacen mejor que nosotros.
• No hacemos agentes autónomos que tomen decisiones críticas sin un humano en el loop.
• No prometemos “100% de precisión” ni “elimina las inspecciones manuales”. Reducimos inspecciones manuales típicamente 40-60% según planta, con falsos positivos a controlar.
• No usamos modelos cerrados cuando el cliente exige on-premise. En sectores regulados, ofrecemos modelos open source autohospedados (Llama, Mistral, etc.).

Limitaciones reales que mencionamos en cada propuesta

1. Data drift. Los modelos se degradan con el tiempo si la operación cambia. Hay que reentrenarlos cada 3-6 meses según el caso.
2. Necesidad de etiquetado humano en computer vision. No hay forma de saltarse esto. Costo típico: 1-2 semanas de operador para un primer dataset usable.
3. Costo de GPUs edge. Un Jetson Orin Nano cuesta entre USD 500 y 1.500 por sitio; planeé el capex desde el inicio.
4. Tiempo de validación. Antes de actuar sobre las predicciones, hace falta 2-4 semanas de “modo observador” para medir falsos positivos en su operación real.

Checklist antes de un piloto IA

• ¿Tiene 6+ meses de datos limpios capturados?
• ¿Cuál es la decisión específica que el modelo va a automatizar o sugerir?
• ¿Cuál es el costo de un falso positivo? ¿Y de un falso negativo?
• ¿Quién va a validar las primeras semanas de predicciones?
• ¿Tiene el etiquetado supervisado disponible (si es computer vision)?
• ¿Necesita inferencia on-premise o cloud está bien?
• Presupuesto para piloto de 6-10 semanas
• ¿Quién va a mantener y reentrenar el modelo en producción?

Si la mitad de estas preguntas no tiene respuesta, todavía no es momento del piloto. Empiece por analítica básica.

Cómo seguir

Si tiene datos capturados y un caso concreto (no “queremos hacer algo con IA”), escríbanos a info@col0.com o por WhatsApp con la idea. En la primera reunión miramos si tiene sentido un piloto IA ahora o si conviene reforzar analítica primero.

Más detalle del servicio en IA aplicada a IoT, y si todavía no tiene la base analítica, empiece por Analítica de datos industriales.