IA e IoT: la guía completa de AIoT, de los modelos en el edge a los agentes LLM

La IA y el IoT se complementan: los dispositivos IoT producen flujos continuos de datos sobre el mundo físico, y la IA convierte esos flujos en detecciones, previsiones y decisiones. Esta guía explica dónde deben ejecutarse los modelos de IA, cómo fluyen los datos y los comandos entre dispositivos y modelos, y cómo construir con MQTT un detector de anomalías en tiempo real y una vía de comandos segura para agentes de IA.

Qué significa AIoT

AIoT, abreviatura de Artificial Intelligence of Things (inteligencia artificial de las cosas), describe sistemas en los que los dispositivos conectados y el machine learning funcionan como un único ciclo. Los sensores miden, los modelos interpretan y los resultados desencadenan acciones: una alerta, una orden de mantenimiento, un setpoint modificado o una cinta transportadora detenida.

Ninguna de las dos mitades es muy útil por sí sola a escala. Miles de sensores producen más datos de los que las personas pueden vigilar, así que sin analítica la mayor parte nunca se mira. Y un modelo sin datos en vivo no es más que un informe sobre el pasado. Combinarlos permite:

• Detectar comportamientos inusuales en el momento en que ocurren, en lugar de descubrirlos en una revisión mensual.
• Predecir averías, demanda o consumo energético con antelación suficiente para actuar.
• Reconocer objetos, personas y defectos en flujos de cámara y audio.
• Explicar e interactuar, permitiendo que las personas pregunten sobre sus equipos en lenguaje natural.

La parte difícil rara vez es el modelo. Es hacer llegar al modelo datos limpios y contextualizados de forma fiable, y devolver su resultado al lugar adecuado. Eso es un problema de arquitectura, y es el foco de esta guía.

Dónde se ejecuta la IA: dispositivo, edge o nube

La primera decisión de diseño en cualquier proyecto de IA e IoT es dónde se realiza la inferencia. Cada ubicación tiene puntos fuertes claros.

En la práctica, la mayoría de los sistemas usan las tres. Un dispositivo filtra y comprime, un nodo edge ejecuta el modelo crítico en tiempo y la nube entrena los modelos y analiza la flota. La comparativa IA en el edge vs IA en la nube te ayuda a decidir caso por caso, y qué es la IA en el edge y qué es TinyML explican en detalle las opciones del edge.

Una regla útil es acercar el cómputo al sensor tanto como lo permita el modelo, y enviar solo lo que necesitan los sistemas superiores. Un acelerómetro que muestrea a varios kilohercios produce demasiados datos para transmitirlos de forma continua, pero un microcontrolador puede calcular cada segundo el RMS, el pico y unas cuantas bandas de frecuencia y publicar esas características en un pequeño mensaje JSON. Si quieres probar tú mismo la inferencia en el dispositivo, TinyML en el ESP32 recorre un ejemplo completo, y la comparativa de hardware para IA en el edge te ayuda a elegir un gateway cuando el modelo se queda grande para un microcontrolador.

MQTT como canal de datos y comandos para IA e IoT

Sea cual sea el reparto, los dispositivos, los nodos edge y los servicios en la nube deben intercambiar datos. MQTT encaja de forma natural en ese papel:

• Desacoplamiento. Un modelo se suscribe a los topics que necesita. Añadir un segundo modelo, o sustituir uno, no afecta a los dispositivos.
• Bidireccional. El mismo broker transporta la telemetría hacia arriba y los comandos o resultados de los modelos hacia abajo.
• Eficiente. Las cabeceras pequeñas y las conexiones persistentes se adaptan a dispositivos limitados y enlaces móviles.
• Resultados como datos. Un modelo publica sus salidas, como una puntuación de anomalía o un objeto detectado, como nuevos topics que pueden consumir los dashboards, las alertas y otros modelos.

Una estructura de topics típica separa los datos en bruto, las salidas de los modelos y los comandos:

plant1/line2/pump3/telemetry          lecturas en bruto del sensor (JSON)
plant1/line2/pump3/ai/anomaly         salida del modelo: puntuación, etiqueta, versión del modelo
plant1/line2/pump3/ai/forecast        valores previstos
plant1/line2/pump3/command/set        comandos validados para el dispositivo

Publicar las salidas de los modelos en sus propios topics es un patrón infravalorado. Hace que los resultados de la IA sean observables como cualquier otra señal, lo que importa cuando alguien pregunta por qué saltó una alerta. También te permite ejecutar dos versiones de un modelo en paralelo y compararlas.

Ten en cuenta que el broker transporta datos; no ejecuta modelos. ConnectMQ es un broker MQTT gestionado sin funciones de IA integradas, y ese es el patrón honesto y modular: tus modelos se ejecutan en servicios de Python, dispositivos edge o plataformas de ML que se conectan al broker como clientes MQTT normales.

Preparar los datos IoT para la IA

Los modelos son tan buenos como los datos que ven, y los datos IoT en bruto son desordenados. Antes de cualquier entrenamiento o inferencia, asegúrate de que cada flujo cumple unos cuantos requisitos básicos. Hacerlo bien desde el principio ahorra semanas de limpieza después.

Marcas de tiempo en origen. Pon la marca de tiempo a cada lectura donde se mide, no donde se recibe. Los retardos de red, los reintentos y el buffer en el edge desordenan los mensajes, y un modelo que use la hora de llegada aprenderá patrones que en realidad son artefactos de la red. Sincroniza los relojes de los dispositivos con NTP e incluye la marca de tiempo en el payload.

Unidades y contexto del activo explícitos. Un valor de 71.2 no significará nada para un modelo dentro de seis meses. Pon las unidades en el payload o en un esquema documentado, y haz que la ruta del topic identifique el activo sin ambigüedad. Un espacio de nombres jerárquico como planta, área, línea y activo te permite agrupar los datos por tipo de máquina o ubicación al construir los conjuntos de entrenamiento.

Muestreo coherente. Muchos modelos suponen intervalos regulares. Decide si los dispositivos informan periódicamente, cuando hay cambios o de ambas formas, y documéntalo. Cuando los dispositivos informan solo con cambios, un latido periódico con el valor actual ayuda a distinguir "sin cambios" de "sin datos".

Contexto operativo. Que una bomba consuma mucha corriente durante el arranque es normal; la misma corriente en régimen estable no lo es. Publica el estado de la máquina, el tipo de producto o el ID de lote junto a las lecturas de los sensores para que los modelos puedan tenerlos en cuenta.

Etiquetas y eventos. Los modelos supervisados necesitan ejemplos de los resultados que te interesan. Registra las acciones de mantenimiento, las notas de los operarios y las averías confirmadas como eventos con marca de tiempo en sus propios topics, para poder cruzarlos después con el histórico de los sensores. La guía de etiquetado de datos de sensores en series temporales cubre flujos de trabajo prácticos.

Puedes ensayar toda la canalización de datos en el servidor MQTT público gratuito con valores simulados antes de conectar equipos reales, que es exactamente lo que hace el ejemplo práctico de más abajo.

Casos de uso clave de AIoT

Detección de anomalías

La detección de anomalías señala lecturas o patrones que difieren del comportamiento normal: un rodamiento más caliente de lo habitual, un espectro de vibración inusual, un perfil energético que cambia de un día para otro. Es el primer proyecto de IA más habitual porque no necesita datos de averías etiquetados. Los métodos van desde estadísticas móviles hasta Isolation Forests y autoencoders. Empieza con la guía de detección de anomalías en IoT.

Mantenimiento predictivo

El mantenimiento predictivo estima cuándo fallará un equipo para poder planificar el mantenimiento. Necesita histórico, idealmente con averías incluidas, y un buen contexto sobre las condiciones de funcionamiento. El artículo sobre mantenimiento predictivo con machine learning trata las características, los modelos y los datos que debes recoger primero.

Previsión

La previsión predice valores futuros como la carga energética, los niveles de los depósitos o la demanda de producción. Los métodos clásicos de series temporales suelen dar buenos resultados y son más fáciles de explicar que los modelos profundos.

Visión artificial

Las cámaras con modelos de detección de objetos cuentan piezas, buscan defectos, detectan personas en zonas restringidas o leen manómetros. La visión suele ejecutarse en el edge porque transmitir vídeo a la nube es caro, y solo las detecciones viajan por MQTT, como se muestra en detección de objetos con YOLO y MQTT.

Agentes LLM e interfaces en lenguaje natural

Los modelos de lenguaje grandes pueden resumir datos de sensores, responder preguntas sobre los equipos y, mediante tool calling, interactuar con los dispositivos. Es muy potente y también el ámbito en el que los errores tienen consecuencias físicas. La guía sobre agentes LLM para dispositivos IoT trata la arquitectura, y la sección de más abajo muestra la capa de seguridad que debe situarse entre un agente y el hardware real.

Práctica: detección de anomalías en tiempo real sobre MQTT

Este ejemplo construye un detector de anomalías en streaming con Python. Un simulador publica lecturas de vibración con averías ocasionales, y un detector se suscribe, puntúa cada lectura con un z-score móvil y publica los eventos de anomalía en otro topic. Ambos se ejecutan contra el área pública gratuita de broker.connectmq.com, que acepta clientes anónimos con un client ID único y no vacío. Cualquiera puede leer los datos de esa área, así que mantenlos simulados.

pip install "paho-mqtt>=2.0"

El simulador del sensor

# sensor_sim.py
import json
import random
import sys
import time

import paho.mqtt.client as mqtt

RUN_ID = sys.argv[1]  # cualquier cadena corta y única, p. ej. a7f3k2
TOPIC = f"connectmq/demo/{RUN_ID}/line2/pump3/telemetry"

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"pump3-sim-{RUN_ID}")
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()

while True:
    vibration = random.gauss(2.0, 0.15)  # velocidad RMS normal en mm/s
    if random.random() < 0.03:
        vibration += random.uniform(1.0, 2.5)  # pico de avería inyectado
    payload = {"ts": int(time.time() * 1000), "vibrationMmS": round(vibration, 3)}
    client.publish(TOPIC, json.dumps(payload), qos=0)
    time.sleep(0.5)

El detector en streaming

# detector.py
import json
import math
import sys
from collections import deque

import paho.mqtt.client as mqtt

RUN_ID = sys.argv[1]
BASE = f"connectmq/demo/{RUN_ID}/line2/pump3"
WINDOW, THRESHOLD, MODEL_VERSION = 120, 4.0, "zscore-v1"
history = deque(maxlen=WINDOW)


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{BASE}/telemetry", qos=0)
    print("detector listening:", reason_code)


def on_message(client, userdata, msg):
    reading = json.loads(msg.payload)
    value = reading["vibrationMmS"]

    if len(history) >= 30:  # espera a tener una línea base mínima
        mean = sum(history) / len(history)
        std = math.sqrt(sum((x - mean) ** 2 for x in history) / len(history)) or 1e-6
        score = (value - mean) / std
        if abs(score) > THRESHOLD:
            event = {
                "ts": reading["ts"],
                "value": value,
                "score": round(score, 2),
                "baselineMean": round(mean, 3),
                "model": MODEL_VERSION,
            }
            client.publish(f"{BASE}/ai/anomaly", json.dumps(event), qos=1)
            print("ANOMALY", event)
            return  # deja las anomalías fuera de la línea base

    history.append(value)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"detector-{RUN_ID}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

Ejecuta python sensor_sim.py a7f3k2 en un terminal y python detector.py a7f3k2 en otro, sustituyendo a7f3k2 por tu propia cadena aleatoria. Observa los resultados con:

mosquitto_sub -h broker.connectmq.com -p 1883 -i viewer-a7f3k2 -t "connectmq/demo/a7f3k2/line2/pump3/ai/#" -v

Tres detalles hacen que esto sea más que un juguete. Los valores anómalos se excluyen de la línea base, de modo que una avería no enseña al detector que las averías son normales. Cada evento lleva la versión del modelo, así que puedes saber qué detector lo produjo. Y la salida es un topic MQTT normal, de modo que un dashboard, un servicio de alertas o un sistema de mantenimiento pueden suscribirse sin cambiar el detector. Para una versión que usa Isolation Forest con varias características, consulta detección de anomalías en tiempo real con Python.

Permitir que los agentes de IA actúen de forma segura sobre los dispositivos

Cuando un agente LLM o cualquier modelo envía comandos a un equipo físico, el componente más importante no es el modelo. Es la barrera entre el modelo y el dispositivo. Nunca dejes que un modelo publique directamente en los topics de comando. En su lugar, haz pasar sus propuestas por un validador que aplique una lista de permitidos, límites y control de frecuencia:

# command_gate.py - valida los comandos propuestos por la IA antes de que lleguen a los dispositivos
import json
import time
import uuid

import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/a7f3k2"
POLICY = {
    "line2/pump3": {"setpointRpm": (800, 1600)},
    "line2/fan1": {"speedPct": (0, 80)},
}
MIN_INTERVAL_S = 10
last_sent = {}


def validate(proposal):
    asset, param, value = proposal["asset"], proposal["param"], proposal["value"]
    if asset not in POLICY or param not in POLICY[asset]:
        return f"{asset}/{param} is not on the allowlist"
    lo, hi = POLICY[asset][param]
    if not isinstance(value, (int, float)) or not lo <= value <= hi:
        return f"value {value} outside [{lo}, {hi}]"
    if time.time() - last_sent.get(asset, 0) < MIN_INTERVAL_S:
        return "rate limit: too many commands for this asset"
    return None


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{PREFIX}/ai/proposals", qos=1)


def on_message(client, userdata, msg):
    try:
        proposal = json.loads(msg.payload)
        error = validate(proposal)
    except (ValueError, KeyError) as exc:
        proposal, error = {"raw": msg.payload.decode(errors="replace")}, f"malformed: {exc}"
    audit = {"ts": int(time.time() * 1000), "proposal": proposal, "accepted": error is None, "reason": error}
    client.publish(f"{PREFIX}/ai/audit", json.dumps(audit), qos=1)
    if error is None:
        topic = f"{PREFIX}/{proposal['asset']}/command/set"
        client.publish(topic, json.dumps({proposal["param"]: proposal["value"]}), qos=1)
        last_sent[proposal["asset"]] = time.time()


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"gate-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

El agente, use el LLM o el framework que use, publica propuestas como {"asset": "line2/pump3", "param": "setpointRpm", "value": 1450} en ai/proposals. Solo la barrera publica en los topics de comando de los dispositivos, y cada decisión se escribe en un topic de auditoría. En producción, la barrera se ejecuta con sus propias credenciales de broker, y los dispositivos solo aceptan comandos procedentes de ella. Las funciones de seguridad siguen perteneciendo al PLC o al controlador, donde ningún software situado por encima puede anularlas. Control seguro de dispositivos IoT con IA amplía esto con pasos de aprobación humana, y cómo construir un servidor MCP para MQTT muestra cómo exponer a un agente herramientas de lectura y de comando de forma estructurada.

Hoja de ruta para un proyecto AIoT

1. Define la decisión. ¿Qué cambiará cuando el modelo produzca un resultado? Si nada, detente aquí.
2. Recoge y contextualiza los datos. Topics, unidades, marcas de tiempo y metadatos de activos coherentes. La mayoría de los proyectos de IA fracasan por la calidad de los datos, no por los algoritmos.
3. Establece una línea base con reglas o estadísticas sencillas. Te dirá si un modelo complejo aporta algo.
4. Elige la ubicación de la inferencia en función de la latencia, el ancho de banda y la conectividad.
5. Publica las salidas del modelo como topics con la versión del modelo y la confianza.
6. Cierra el ciclo con cuidado: primero alertas, después recomendaciones y por último comandos automáticos, y solo a través de una barrera de validación.
7. Monitoriza y reentrena. Los sensores derivan, los procesos cambian y los modelos se degradan. La guía de MLOps para IoT cubre el versionado, la monitorización y el redespliegue.

Errores habituales

• Entrenar con datos poco representativos. Un modelo entrenado en verano puede marcar como anomalía cada mañana de invierno.
• Ignorar los datos que faltan. Un sensor que deja de informar es en sí mismo una señal. Usa topics de status con Last Will para que los modelos no confundan los huecos con lecturas estables.
• Alertas de caja negra. Los operarios ignoran las alertas que no entienden. Incluye en cada evento el valor, la línea base y el motivo.
• Confiar demasiado en los LLM. Los modelos de lenguaje pueden producir comandos plausibles pero erróneos. Valida todo lo que propongan contra límites estrictos.
• Enviarlo todo a la nube. La vibración de alta frecuencia o el vídeo deben procesarse en el edge, enviando hacia arriba solo las características o las detecciones.

Impulsa tu pipeline AIoT con ConnectMQ

Tus modelos necesitan un flujo de datos de entrada fiable y un canal controlado para los resultados y los comandos de salida. Crea una cuenta gratuita en app.connectmq.com con el plan Serverless, sin tarjeta de crédito, y conecta dispositivos, detectores y agentes con las credenciales generadas por TLS en el puerto 8883. ConnectMQ admite MQTT 3.1.1 y 5.0, y los planes de pago añaden suscripciones compartidas para que varias instancias de un detector se repartan la carga de un mismo flujo de telemetría. Si necesitas más conexiones o un entorno aislado, compara los planes de broker MQTT en la nube.

Preguntas frecuentes

¿Qué diferencia hay entre la IA y el IoT?

El IoT es la red de dispositivos conectados que miden y actúan en el mundo físico, mientras que la IA es el conjunto de técnicas que aprenden patrones a partir de los datos y hacen predicciones. AIoT las combina para que los datos de los dispositivos alimenten los modelos y las salidas de los modelos desencadenen acciones.

¿La IA debe ejecutarse en el edge o en la nube?

Ejecuta en el edge la inferencia crítica en tiempo y la que consume mucho ancho de banda, como la visión o el análisis de vibraciones de alta frecuencia. Usa la nube para el entrenamiento, la analítica de toda la flota, la previsión y los modelos de lenguaje grandes. La mayoría de los sistemas combinan ambas.

¿ConnectMQ incluye funciones de IA o machine learning?

No. ConnectMQ es la capa de mensajería MQTT. Tus modelos se ejecutan en tus propios servicios, dispositivos edge o plataformas de ML, que se conectan a ConnectMQ como clientes MQTT para recibir datos y publicar resultados.

¿Puede un LLM controlar directamente los dispositivos IoT?

No debería. Haz pasar los comandos que proponga un agente por una barrera de validación que aplique listas de permitidos, límites de valores y de frecuencia, registre una pista de auditoría y sea el único cliente autorizado a publicar en los topics de comando de los dispositivos.

¿Cuál es el primer proyecto de IA e IoT más sencillo?

La detección de anomalías en tiempo real sobre un flujo de sensor existente, porque no necesita datos de averías etiquetados. Una línea base estadística móvil como la del ejemplo de esta guía suele bastar para generar alertas útiles.