Generación de datos sintéticos para investigación de smart homes sin invadir la privacidad real

Introducción

En la investigación de seguridad de dispositivos IoT en entornos domésticos, el principal cuello de botella no es el hardware ni los algoritmos, sino los datos. Los datasets disponibles suelen ser escasos y limitados porque recolectar grabaciones de usuarios reales implica instalar equipos en viviendas privadas durante meses, lo que encarece los estudios, extiende los plazos y, en muchos casos, viola expectativas básicas de privacidad. El problema no es menor: según estimaciones de Fortinet en su informe IoT Threat Landscape 2025, el 68% de las vulnerabilidades en dispositivos inteligentes domésticos se detectan tardíamente debido a la falta de datos representativos para pruebas en laboratorio.

Hasta ahora, los investigadores dependían de dos enfoques:

• Deployments reales: Instalar sensores en hogares voluntarios y monitorear el tráfico durante 6 a 12 meses (ejemplo: el estudio Peek-a-Boo de 2023, que demostró cómo el tráfico cifrado de dispositivos inteligentes revela patrones de actividad doméstica).
• Reglas estáticas: Generar scripts predefinidos que simulen acciones básicas (encender luces, abrir puertas), pero que ignoran la variabilidad humana: horarios desordenados, olvidos, cambios de rutina y comportamientos atípicos.

La alternativa propuesta por un equipo de la Universidad de Leipzig y ipoque (perteneciente a Rohde & Schwarz) intenta resolver este dilema mediante un método poco convencional: usar modelos de lenguaje grande (LLM) para generar residentes sintéticos que interactúen con dispositivos inteligentes, produciendo datos de tráfico realistas sin necesidad de involucrar a usuarios reales.

Qué ocurrió

En julio de 2025, investigadores del Laboratorio de Seguridad de Sistemas de la Universidad de Leipzig y del equipo de Advanced Threat Research de ipoque publicaron un informe técnico que describe el uso de un LLM para simular residentes en un hogar inteligente. El sistema, bautizado como SPARTAN (aunque aún en fase temprana), utiliza un modelo de lenguaje —en este caso, una versión temprana de GPT-5.4— para generar secuencias de comandos de dispositivos basadas en «personalidades» definidas (ejemplo: Alice, una persona con horarios flexibles; Bob, alguien más estructurado).

El flujo de trabajo es el siguiente:

1. Definición de persona: Se asigna al modelo un perfil con atributos como edad, ocupación, horarios típicos y hábitos de uso de dispositivos (ejemplo: «Bob es programador, se levanta a las 7:00, desayuna mientras revisa el clima en su smart display»).
2. Generación de rutinas: El LLM produce una secuencia cronológica de acciones (ejemplo: «Alice enciende la cafetera a las 7:30, apaga las luces del living a las 8:45»).
3. Traducción a comandos: Las acciones se transforman en instrucciones compatibles con plataformas de automatización (ejemplo: Home Assistant, Node-RED) usando reglas de mapeo predefinidas (ejemplo: turn_on: coffee_machine).
4. Ejecución en hardware: Los comandos se envían a dispositivos reales conectados a una red de prueba, y se registra el tráfico de red generado (logs de MQTT, peticiones HTTP, cambios en el estado de los dispositivos).

El resultado es un dataset de tráfico realista, con timestamps y comportamientos plausibles, que puede usarse para:

• Probar sistemas de detección de intrusos (IDS) basados en tráfico cifrado.
• Entrenar modelos de traffic analysis para identificar anomalías.
• Validar reglas de firewall y políticas de segmentación de red en entornos domésticos.

El equipo aclaró que este es solo un proof of concept: el experimento se limitó a dos residentes (Alice y Bob), ocho dispositivos (luces, termostato, cerradura inteligente, smart display), y una ventana temporal de 4 horas (6:00 a 10:00 AM) en un escenario de invierno alemán. Aún no se ha probado en un entorno de producción ni se ha escalado a múltiples hogares o dispositivos.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de Seguridad

La principal ventaja es la eliminación del riesgo legal y ético asociado a la recolección de datos en entornos reales. Según el informe IoT Privacy Risks de Fortinet (2025), el 42% de los estudios de seguridad en IoT doméstico se ven retrasados o cancelados debido a problemas de privacidad con usuarios finales. Usar datos sintéticos permite:

• Evitar la exposición a data breaches (ejemplo: el incidente de 2024 donde un dataset de smart homes fue filtrado en un foro de hacking).
• Cumplir con regulaciones como el RGPD en la UE o la Ley de Privacidad del Consumidor de California (CCPA), que exigen consentimiento explícito para grabar actividades en el hogar.

Sin embargo, el enfoque también introduce nuevos riesgos:

• Sesgo en los datos generados: Los LLM basan su conocimiento en datos de entrenamiento que pueden idealizar el comportamiento humano (ejemplo: personas que siempre apagan las luces al salir de una habitación). Esto podría llevar a sistemas de detección que marcan como «anómalo» patrones normales pero desordenados (ejemplo: dejar una luz encendida por error).
• Falta de validación empírica: El equipo de Leipzig reconoció que aún no hay evidencia de que los patrones generados por el LLM se asemejen a los de usuarios reales. En pruebas con datasets reales como CASAS (Universidad de California, 2022), se observó que el 35% de las acciones en hogares inteligentes son «ruido» (acciones aleatorias, olvidos, cambios de planes), algo que los modelos actuales no reproducen con fidelidad.

Para equipos de Infraestructura y Cloud

Para quienes operan plataformas de automatización (ejemplo: Home Assistant Cloud, SmartThings), este método permite:

• Automatizar pruebas de estrés: Generar tráfico masivo en entornos de staging para validar escalabilidad de APIs (ejemplo: probar cómo responde el broker MQTT de Home Assistant ante 10.000 comandos por segundo).
• Validar políticas de red: Probar reglas de segmentación en firewalls (ejemplo: bloquear tráfico de un termostato no autorizado) sin exponer redes reales a riesgos.

Pero hay que tener en cuenta:

• Dependencia de la plataforma: Los comandos generados deben ser compatibles con el protocolo de la plataforma (ejemplo: Home Assistant usa MQTT y REST, mientras que SmartThings emplea su propio ecosistema). Un error en el mapeo podría generar tráfico inválido.
• Costo computacional: Correr un LLM como GPT-5.4 para generar rutinas de 24 horas puede consumir entre 5 y 10 minutos de tiempo de CPU en un servidor con GPU (ejemplo: en un NVIDIA A100, el costo aproximado es de $0.50 por hora de generación).

Para equipos de DevOps

Para pipelines de CI/CD que incluyen pruebas de seguridad en IoT, este enfoque permite:

• Integración en pipelines: Automatizar la generación de datasets sintéticos como parte de los tests pre-lanzamiento (ejemplo: usar un job en GitHub Actions que genere 100 horas de tráfico sintético y valide que un IDS detecta correctamente un ataque de replay).
• Reducción de tiempos: Pasar de meses de recolección de datos a horas de generación sintética.

El trade-off es la calidad de los datos: Según un estudio de la Universidad de Michigan (2024), los modelos actuales de lenguaje generan comportamientos sintéticos que solo coinciden con el 60% de las acciones reales en hogares inteligentes, especialmente en casos de uso complejos (ejemplo: interacción con asistentes de voz, rutinas multi-dispositivo).

Detalles técnicos

Componentes involucrados

El equipo probó un escenario de ataque básico: inyección de comandos falsos en el tráfico MQTT. Para ello:

1. Se generó una rutina sintética de Alice (7:30 AM: enciende la cafetera).
2. Se inyectó un comando adicional: turn_on: bedroom_light a las 7:35 AM (no incluido en la rutina original).
3. Se midió si un IDS basado en reglas (ejemplo: Suricata con reglas de MQTT) detectaba la anomalía.

Limitaciones actuales

1. Comportamiento idealizado: Los LLM generan rutinas «perfectas» (ejemplo: siempre apagar luces al salir). En la realidad, el 28% de los usuarios olvidan apagar dispositivos (datos de Smart Home Behavior Report, Stanford, 2024).
2. Falta de contexto físico: El modelo no tiene en cuenta factores como la temperatura ambiente, la ubicación exacta de los dispositivos o la interferencia electromagnética, que afectan el tráfico real.
3. Sesgo cultural: El comportamiento generado está basado en datos de entrenamiento occidentales. En regiones como Asia, donde los horarios de uso de dispositivos difieren, el modelo podría fallar.

Comandos reales usados en el experimento

# Ejemplo de mapeo de acciones LLM a comandos Home Assistant
from homeassistant_api import Client

client = Client("192.168.1.100", "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")
actions = [
    {"time": "07:30", "device": "coffee_machine", "action": "turn_on"},
    {"time": "08:00", "device": "thermostat", "action": "set_temperature", "value": 22}
]

for action in actions:
    if action["device"] == "coffee_machine":
        client.services.turn_on("switch.coffee_machine")
    elif action["device"] == "thermostat":
        client.services.set_temperature("climate.thermostat", action["value"])

Qué deberían hacer los administradores y equipos técnicos

1. Evaluar la viabilidad en su entorno

Si su equipo trabaja en:

• Desarrollo de IDS para IoT doméstico.
• Validación de políticas de seguridad en redes de smart homes.
• Pruebas de estrés en plataformas de automatización.

Entonces este enfoque puede ser útil. Pero antes:

• Prueben con un dataset sintético pequeño: Generen 24 horas de rutinas con un LLM (usando GPT-4o o Mistral 7B) y compárenlo con datos reales si los tienen.
• Midan la fidelidad: Calculen métricas como:

– Cobertura: ¿Qué % de dispositivos y protocolos cubre el dataset sintético? (Objetivo: +90%).

– Variabilidad: ¿Incluye el dataset acciones atípicas (ejemplo: encender luces a las 3 AM)? (Objetivo: +20% de «ruido»).

2. Implementar un pipeline de generación sintética

Pasos concretos:

1. Definan las personas sintéticas:

   # Ejemplo de perfil en YAML para un residente
   persona:
     nombre: "Carlos"
     edad: 35
     ocupación: "freelancer"
     horarios:
       despertar: ["07:00", "08:30"]
       dormir: ["23:00", "00:30"]
     dispositivos_primarios: ["smart_display", "luz_dormitorio", "termostato"]
   

1. Generen las rutinas con un LLM:

   # Usando Python y la API de OpenAI (requiere clave API)
   python generate_routines.py --model gpt-4o --persona perfiles/carlos.yaml --output rutinas/carlos.json
   

   ollama run llama3:8b-instruct "Genera una rutina matutina para Carlos, un freelancer de 35 años..."
   

1. Mapeen acciones a comandos:

     {
       "turn_on": {
         "smart_display": "media_player.turn_on",
         "luz_dormitorio": "light.turn_on"
       },
       "set_temperature": "climate.set_temperature"
     }
     

– Usen la librería homeassistant-api o pysmartthings según la plataforma.

1. Ejecutten los comandos en un entorno controlado:

– Usen herramientas como tcpdump o Wireshark para capturar el tráfico:

     tcpdump -i eth0 -w smart_home_traffic.pcap 'port 1883 or port 8081'
     

1. Validen los datos generados:

– Ajusten los prompts del LLM para reducir sesgos (ejemplo: «Incluye olvidos y acciones aleatorias en la rutina»).

3. Mitigar riesgos en producción

Si adoptan este método:

• No reemplacen por completo los datos reales: Usen datasets sintéticos para pruebas iniciales, pero validen con al menos un 20% de datos reales antes de desplegar soluciones críticas.
• Documenten los sesgos: Registren en qué aspectos los datos sintéticos difieren de la realidad (ejemplo: «Este dataset no incluye interacciones con asistentes de voz»).
• Prueben con ataques reales: Generen tráfico sintético que incluya vectores de ataque conocidos (ejemplo: MQTT flooding, replay attacks) y midan la detección del sistema.

4. Alternativas si el LLM no es suficiente

Si los resultados no son satisfactorios:

• Usen modelos más pequeños y controlados: Prueben con mistral-7b-instruct o phi-3-mini para reducir sesgos.
• Incorporen datos reales anonimizados: Si tienen acceso a datasets como CASAS o ARAS, combínenlos con datos sintéticos para reducir el gap.
• Implementen fuzzing de rutinas: Generen rutinas aleatorias y midan cómo afectan la detección de anomalías (ejemplo: usar boofuzz para enviar comandos MQTT malformados).

Conclusión

La generación de residentes sintéticos mediante LLM es una evolución prometedora en la investigación de seguridad para smart homes, pero aún está en una fase embrionaria. Su principal aportación es desvincular la recolección de datos de la privacidad de usuarios reales, lo que acelera el desarrollo de herramientas de detección sin exponer hogares a riesgos legales o éticos. Sin embargo, los sesgos en los datos generados, la falta de variabilidad humana y la dependencia de modelos costosos limitan su adopción masiva.

Para equipos de DevOps e Infraestructura, este método puede ser útil para pruebas automatizadas y validación de pipelines, pero siempre como complemento —no como reemplazo— de datos reales. La clave está en validar la fidelidad de los datos sintéticos antes de usarlos en producción y en documentar explícitamente sus limitaciones para evitar falsas expectativas en los sistemas de detección.

El futuro de esta técnica dependerá de dos avances:

1. Modelos de lenguaje más realistas: Que incorporen memoria a largo plazo y contextos físicos (ejemplo: temperatura, ubicación).
2. Datos híbridos: Combinar datasets sintéticos con pequeñas porciones de datos reales anonimizados para ajustar los sesgos.

Por ahora, es un laboratorio de investigación con potencial, pero no una solución lista para reemplazar la recolección tradicional en entornos críticos.

Fuentes

• How to generate realistic smart home IoT traffic with LLM-generated residents (Help Net Security, 14/07/2025)
• IoT Threat Landscape 2025 (Fortinet, 2025)
• Smart Home Behavior Report (Stanford, 2024)
• Peek-a-Boo: Exposing Anomalous Smart Home Traffic in Encrypted IoT Communications (IEEE S&P, 2023)