La residencia de datos MQTT consiste en saber, y controlar, dónde se procesan y almacenan tus mensajes IoT en su camino desde el dispositivo hasta la aplicación. Este artículo explica qué partes de un sistema MQTT tocan los datos, qué cuestiones regulatorias y contractuales suelen aplicarse y cómo la elección de región y los despliegues bring-your-own-cloud te ayudan a cumplirlas. Es una guía práctica de ingeniería, no asesoramiento jurídico; implica a tu equipo legal o de cumplimiento en las decisiones.
Qué significa la residencia de datos para MQTT
La residencia de datos es el requisito de que ciertos datos se almacenen o procesen dentro de una geografía concreta, como un país o el Espacio Económico Europeo. Hay términos relacionados que a menudo se usan sin precisión:
- Residencia de datos: dónde residen físicamente los datos.
- Soberanía de datos: qué leyes de qué jurisdicción se aplican a los datos.
- Localización de datos: una obligación legal de que los datos permanezcan en un país.
Un broker MQTT está en la ruta de datos de cada mensaje. Aunque tu base de datos esté en el país correcto, un broker en otra región sigue recibiendo, procesando y posiblemente almacenando esos mensajes. Entender qué hace un broker MQTT con tus datos es el punto de partida.
Dónde viven los datos en un sistema MQTT
Mapea todos los lugares donde puede existir un mensaje, no solo tu base de datos:
| Ubicación | Qué contiene | Pregunta de residencia |
|---|---|---|
| Dispositivo | Lecturas antes del envío, mensajes en búfer | ¿Dónde están desplegados los dispositivos? |
| Ruta de red | Mensajes en tránsito | ¿Está el tráfico cifrado con TLS de extremo a extremo hasta el broker? |
| Memoria del broker | Mensajes que se están enrutando | ¿En qué región se ejecuta el broker? |
| Retained messages | Último valor por topic | ¿Dónde se almacenan y durante cuánto tiempo? |
| Sesiones persistentes | Mensajes en cola para clientes desconectados | ¿Dónde se almacenan y cuándo expiran? |
| Logs del broker | Client IDs, direcciones IP y, a veces, topics | ¿Contienen los logs datos personales y dónde se guardan? |
| Suscriptores y backends | Todo lo que va aguas abajo | ¿Dónde se ejecutan tus servicios y bases de datos? |
Hay dos elementos fáciles de pasar por alto. Primero, los retained messages y los mensajes de sesión en cola son datos en reposo en el broker. Segundo, los logs del broker pueden contener direcciones IP e identificadores de cliente, que pueden ser datos personales según algunas normativas.
Factores regulatorios y contractuales
RGPD y datos personales
Según el Reglamento General de Protección de Datos de la UE, que aplica por ejemplo a un despliegue en España, los datos personales solo pueden transferirse fuera del EEE con las garantías adecuadas. En América Latina, países como México, Colombia, Argentina o Chile tienen sus propias leyes de protección de datos personales, con reglas sobre transferencias internacionales que conviene revisar con tu equipo legal. No todos los datos IoT son personales, pero muchos pueden serlo: la ubicación de un localizador de vehículos, la ocupación de una vivienda, el consumo energético vinculado a un hogar o las lecturas de salud de un wearable. Si un dispositivo puede vincularse a una persona, su telemetría puede ser un dato personal.
Requisitos del sector y de los clientes
Más allá de la legislación de privacidad, los requisitos de residencia suelen venir de:
- Contratos del sector público que exigen alojamiento en el propio país.
- Infraestructuras críticas y empresas de servicios públicos con normas de seguridad nacional.
- Clientes sanitarios y financieros con sus propias políticas.
- Cuestionarios de compras corporativas que preguntan dónde se ejecuta cada subencargado.
A menudo, el requisito más estricto no es una ley, sino una cláusula de un contrato con un cliente. Recopila esos requisitos antes de elegir un modelo de alojamiento.
Reducir el riesgo de residencia en tu diseño
Las decisiones de ingeniería pueden reducir el problema independientemente de dónde se ejecute el broker:
- Minimiza los datos personales en los payloads. Envía IDs de dispositivo, no nombres ni direcciones. Resuelve las identidades en tu backend, en la región adecuada.
- Mantén los datos personales fuera de los nombres de topic. Los topics aparecen en logs, exploradores y herramientas de depuración.
- Usa TLS en todas las conexiones. Los puertos 8883 y 8084 cifran los datos en tránsito.
- Limita los datos en reposo en el broker. Usa la expiración de mensajes de MQTT 5 y una expiración de sesión razonable, y evita retener mensajes que contengan datos personales.
- Procesa en el edge. Agrega o anonimiza en un gateway antes de publicar en la nube.
- Documenta el flujo de datos. Un diagrama que liste cada componente y su región responde a la mayoría de las preguntas de compras.
Aquí tienes un ejemplo en Python (paho-mqtt 2.x) que publica telemetría seudonimizada con una expiración de mensaje de MQTT 5, de modo que el broker la descarta si ningún suscriptor la recoge en diez minutos.
import json
import ssl
import time
import paho.mqtt.client as mqtt
from paho.mqtt.packettypes import PacketTypes
from paho.mqtt.properties import Properties
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID",
protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.connect("YOUR_BROKER_HOST", 8883, keepalive=60)
client.loop_start()
props = Properties(PacketTypes.PUBLISH)
props.MessageExpiryInterval = 600 # segundos
payload = {"device": "dev-4f9a", "kwh": 1.84, "ts": int(time.time())} # sin nombres ni direcciones
info = client.publish("site-07/meter/dev-4f9a/telemetry", json.dumps(payload),
qos=1, properties=props)
info.wait_for_publish()
client.loop_stop()
client.disconnect()
Compromisos al elegir región
Elegir la región del broker es un equilibrio entre residencia, latencia y comodidad:
- Residencia: la región debe cumplir tus requisitos legales y contractuales.
- Latencia: los dispositivos y consumidores lejos del broker sufren viajes de ida y vuelta más largos; consulta la latencia de un broker MQTT por región.
- Coubicación: situar el broker cerca de tu backend reduce la transferencia de datos entre regiones.
- Flotas multirregión: si vendes en varias jurisdicciones, puede que necesites un broker por región, con cada dispositivo configurado para su broker de origen.
El último punto importa para la arquitectura. Una flota de dispositivos repartida entre regiones suele implicar brokers y backends separados por región, con solo datos agregados y no personales fluyendo hacia una vista global.
Retención y eliminación
Las preguntas de residencia suelen ir acompañadas de preguntas de retención. Decide cuánto tiempo puede vivir cada tipo de dato en cada etapa: en el búfer del dispositivo, en el broker como mensajes retenidos o en cola, en los logs y en tus bases de datos. Haz posible la eliminación por dispositivo y por cliente, porque dar de baja a un cliente o atender una solicitud de supresión implica borrar los datos de todos los lugares donde se copiaron. Borrar un retained message es sencillo en MQTT: publica un payload retenido vacío en el mismo topic.
Cómo resuelve BYOC la residencia
La respuesta más sólida a "¿dónde están nuestros datos?" es "en nuestra propia cuenta de nube, en una región que hemos elegido". Ese es el modelo bring-your-own-cloud. Con ConnectMQ BYOC, el broker se ejecuta en tu cuenta de nube y ConnectMQ lo gestiona, así que tú decides la región, los límites de red y la política de logs, sin cargar con el trabajo operativo del autoalojamiento. Los detalles están en nuestro artículo sobre el broker MQTT BYOC.
Los demás planes de ConnectMQ atienden otras necesidades. Los brokers Serverless en el clúster compartido son ideales para desarrollo, pilotos y datos sin restricciones de residencia. Un plan Dedicated te ofrece un clúster aislado. En ambos casos, pregunta a ConnectMQ dónde se ejecuta la infraestructura e incluye la respuesta en la documentación de tu flujo de datos. Las organizaciones que deben ejecutarlo todo por su cuenta pueden considerar Self Managed Enterprise.
Sea cual sea el plan, el lado del cliente no cambia: MQTT 3.1.1 o 5.0 sobre TLS en el puerto 8883, o Secure WebSocket en el 8084 con la ruta /mqtt. Migrar una flota de un modelo de alojamiento a otro es cuestión de actualizar el host y las credenciales.
Checklist de residencia antes del lanzamiento
- Enumera las jurisdicciones donde se encuentran los dispositivos, usuarios y clientes.
- Clasifica los campos del payload: personales, seudonimizados o no personales.
- Registra la región del broker, de cada suscriptor y de cada base de datos.
- Configura la expiración de mensajes, la expiración de sesiones y la política de retained messages.
- Confirma que TLS es obligatorio para todos los clientes.
- Decide si necesitas BYOC o brokers por región.
- Mantén los datos de prueba fuera de los brokers públicos; el área del servidor MQTT público gratuito la puede leer cualquiera y solo es adecuada para pruebas y experimentos sin datos sensibles, nunca para producción.
Empieza con ConnectMQ
Empieza a construir en el plan Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, usando datos de prueba no personales. Cuando los requisitos de residencia se concreten, habla con ConnectMQ sobre despliegues Dedicated o BYOC. Para una visión completa de los modelos de alojamiento, lee la guía de broker MQTT en la nube y la comparativa de broker MQTT gestionado.
Preguntas frecuentes
¿La residencia de datos MQTT solo importa para los datos almacenados?
No. Según muchas políticas, el procesamiento también cuenta, y un broker procesa todos los mensajes. Los retained messages, las sesiones en cola y los logs también son datos en reposo en el broker.
¿La telemetría IoT es un dato personal según el RGPD?
Puede serlo si se refiere a una persona identificable, como la ubicación o el consumo energético de un hogar. Pide a tu delegado de protección de datos que clasifique tus payloads.
¿Cómo ayuda BYOC con la residencia de datos?
El broker se ejecuta en tu propia cuenta de nube, en una región que tú eliges y bajo tus políticas, mientras el proveedor lo opera.
¿Puedo usar un solo broker para dispositivos en varios países?
Técnicamente sí, pero si cada país tiene normas de residencia, puede que necesites un broker por región, con los dispositivos asignados a su broker de origen.
