IoT y agentes de IA: el dato que la plataforma no te deja ver

Índice

El 12 de septiembre de 2026 entró en vigor la obligación de “acceso por diseño” del Data Act para los productos conectados que se pongan en el mercado a partir de esa fecha. El Reglamento ya aplicaba desde el 12 de septiembre de 2025, así que el fabricante lleva un año obligado a entregar el dato cuando se le pide. Lo que cambia ahora es la dirección de la carga: el usuario tiene que poder llegar al dato sin pedirlo.

Este artículo cruza esa obligación con la ola de agentes de IA que se está montando encima del IoT. La tesis es corta. Un agente solo puede razonar sobre lo que ve, y en la mayoría de las plataformas de fabricante el dato del dispositivo está retenido por diseño de negocio. Eso convierte la gobernanza del dato en el problema previo a cualquier agente, y el Data Act en la palanca contractual para resolverlo.

Qué es un agente sobre IoT y por qué el dato manda

Un agente de IA sobre IoT es un bucle: observa estado (sensores, telemetría, eventos), decide con un modelo de lenguaje o con reglas, y actúa sobre actuadores o sobre sistemas de terceros. La parte de “decidir” es la que sale en las presentaciones. La parte de “observar” es la que determina si el sistema sirve para algo.

La capa de conexión entre agente y dispositivo ya no es un problema. El Model Context Protocol se donó a la Agentic AI Foundation de la Linux Foundation el 9 de diciembre de 2025, con Anthropic, Block y OpenAI como cofundadores y AWS, Google, Microsoft, Cloudflare y Bloomberg como miembros platino; a esa fecha había más de 10.000 servidores públicos activos. En el mundo IoT el patrón “servidor MCP delante del hub” se ha vuelto la forma habitual de exponer sensores y actuadores como herramientas tipadas, y proyectos de código abierto como Home Assistant lo implementan en ambas direcciones: como cliente MCP para su agente de conversación y como servidor MCP (integración incluida en el núcleo desde la versión 2025.2, con OAuth sobre su API de autenticación).

Con la tubería resuelta, el cuello de botella se desplaza a lo que circula por ella. Y ahí es donde el fabricante decide.

Cinco maneras de retener el dato sin decir que no

No hace falta un contrato que prohíba el acceso. Basta con una arquitectura que lo haga inútil. Estos son los mecanismos que se repiten, sin nombres, porque el patrón importa más que el logotipo.

Solo nube. El dispositivo habla con la nube del fabricante y el usuario habla con la nube. No hay API local, o existe con una fracción de las capacidades. El “modo local” figura en la hoja de producto y desaparece con la conexión WAN. Un agente que quiera observar el estado tiene que pasar por una cuenta, un token y una tasa de peticiones que fija el fabricante.

Dato derivado en lugar de dato bruto. La plataforma entrega un índice de eficiencia, un estado de salud del equipo o una alerta ya interpretada, y no la serie de sensor que la produjo. Aquí el Data Act tiene una grieta que hay que contar entera: el considerando 15 excluye del ámbito la información inferida o derivada mediante algoritmos propietarios, y pone como ejemplo la fusión de sensores. El fabricante tiene un incentivo claro a mover la frontera de lo que llama “derivado”. El artículo 4(1) contrarresta parte de eso al exigir que el dato disponible se entregue con la misma calidad de la que dispone el titular y con los metadatos necesarios para interpretarlo.

Formatos y semántica sin diccionario. JSON sin esquema publicado, unidades sin declarar, marcas de tiempo ambiguas, identificadores que cambian en cada actualización de firmware. Se cumple la letra de “estructurado y legible por máquina” y se sigue necesitando al fabricante para entender el campo. El mismo artículo 4(1) exige los metadatos para interpretar y usar el dato; un JSON sin esquema no los aporta.

Acceso racionado. Exportación mensual en CSV, API de pago por volumen, límites de peticiones que impiden una ingesta continua. Un agente que necesita observar cada pocos segundos no puede trabajar con una foto diaria. El artículo 4(1) pide acceso gratuito y, donde sea pertinente y técnicamente viable, continuo y en tiempo real.

El agente del fabricante como nueva capa de retención. Este es el mecanismo nuevo. Cada plataforma saca ahora su asistente de IA sobre su dato. Si el único agente que ve los sensores es el del fabricante, el dato no ha salido de su perímetro; lo que ha cambiado es que la interfaz es conversacional. El Reglamento lo tiene previsto en el considerando 23: los asistentes virtuales quedan cubiertos por los derechos de acceso, y el dato generado al interactuar con un producto a través de un asistente de otro proveedor también. Lo que no cubre son los datos que el asistente produce y que no guardan relación con el uso del producto.

Lo que el Reglamento pone a favor del usuario

Los artículos que un responsable de infraestructura puede citar en una negociación, sin necesidad de un jurista al lado:

  • Artículo 3(1), en vigor desde el 12 de septiembre de 2026 para productos nuevos: diseño que permita al usuario acceder por defecto, de forma fácil, segura y gratuita, en formato estructurado y legible por máquina, y directamente desde el dispositivo cuando sea técnicamente viable.
  • Artículo 4(1): cuando no hay acceso directo, el titular entrega el dato y sus metadatos sin dilación, con la misma calidad que tiene él, y continuo y en tiempo real donde proceda.
  • Artículo 4(4): prohibición de interfaces que dificulten el ejercicio del derecho (patrones oscuros en el portal del fabricante).
  • Artículo 4(5): el titular no puede conservar registros del acceso del usuario más allá de lo necesario para servirlo y mantener la infraestructura.
  • Artículo 4(6) a 4(8): los secretos comerciales se protegen, pero el titular tiene que identificarlos en los metadatos, pactar medidas con el usuario y, si se niega, hacerlo por escrito, motivado y notificando a la autoridad competente. La negativa genérica no vale.
  • Artículo 4(13) y 4(14): el titular solo puede usar el dato no personal con un contrato con el usuario, y no puede cederlo a terceros fuera de ese contrato.
  • Artículo 5(1): el usuario puede dirigir el dato a un tercero de su elección, en las mismas condiciones.
  • Artículo 5(3): una empresa designada como guardián de acceso bajo el Reglamento de Mercados Digitales no puede ser ese tercero. Para quien piense en enchufar el IoT al agente de una gran plataforma, esto cierra la puerta por ley.

Dos límites que hay que tener presentes. El RGPD prevalece en caso de conflicto (artículo 1(5)), así que el dato personal sigue su propio régimen. Y las sanciones se dejan a cada Estado miembro (artículo 40), de modo que el peso real de la norma dependerá de la autoridad designada en cada país y de la primera reclamación que llegue.

La analogía

Un contador eléctrico inteligente que solo muestra la factura mensual cumple con “informar del consumo”. Pero para automatizar la carga de un vehículo o negociar con la red hace falta la curva horaria, en un formato que otro sistema pueda leer, sin pedirla cada mes. El fabricante que entrega solo la factura no miente. Ha decidido en qué punto de la cadena te deja mirar. El Data Act le obliga a bajar ese punto hasta la lectura del sensor, y el agente es quien tiene que estar esperando ahí.

La ruta de vuelta: dónde vive el dato cuando lo recuperas

Recuperar el dato no sirve de nada si aterriza en otra plataforma cerrada. La arquitectura que evita repetir el problema tiene cuatro piezas, todas con software de código abierto:

  1. Captura neutral. Un hub que hable los protocolos del dispositivo (Zigbee, Z-Wave, Matter, MQTT, Modbus) y que no dependa de la nube de nadie. Home Assistant cumple ese papel en despliegues domésticos y de edificio; en industria, un broker MQTT y un gateway OPC UA propios hacen lo mismo.
  2. Formato propio y persistencia propia. El dato va a una cola (Kafka) y a bases de series temporales y relacionales bajo control del usuario. Para activos y trazabilidad, EPCIS como esquema de eventos. Lo que define el formato es el usuario, no el fabricante.
  3. Servidor MCP delante del dato propio. El agente no habla con la API del fabricante. Habla con un servidor MCP que expone el dato ya normalizado, con las herramientas acotadas y con la autenticación que el usuario decide. Esto es lo que convierte la retención del fabricante en irrelevante: si el dato bruto llega a la captura, el resto de la cadena es tuya.
  4. El agente dentro del perímetro. Inferencia en el clúster propio, con el modelo que el usuario elija. Para un cliente sujeto al ENS, esto es lo que permite trazar quién autorizó al agente a leer qué y a actuar sobre qué, y hacerlo en un sistema bajo su responsabilidad.

En Fibercli tenemos este esquema montado en un entorno formativo con dos clústeres: uno con la captura, el dato y la salida (Home Assistant, Kafka, EPCIS, series temporales) y otro con la inferencia y el orquestador MCP. El agente de voz consulta activos RFID y telemetría sin que ningún fabricante esté en medio.

Lo que un agente pone en riesgo si se hace mal

Recuperar el dato abre problemas que la plataforma cerrada tenía resueltos por omisión. Tres que hay que tener en cuenta antes de darle un actuador a un modelo:

  • Latencia y determinismo. Un modelo de lenguaje no vale para el lazo de control. Su sitio es la supervisión, la consulta y la acción con confirmación. Lo que tenga que responder en milisegundos sigue siendo código.
  • Inyección a través del sensor. Cualquier dispositivo que devuelva texto (una etiqueta RFID, un nombre de entidad, un campo libre) es un vector de inyección de instrucciones al modelo. El servidor MCP tiene que tratar ese texto como dato, no como instrucción, y el agente no debería tener permiso de escritura sobre nada que no esté en una lista cerrada.
  • Catálogo de herramientas. Un edificio con mil entidades no puede exponer mil herramientas al modelo. El filtrado y la agrupación por dominio son parte del diseño del servidor MCP, no un ajuste posterior.

Qué exigir al proveedor de IoT a partir de hoy

Una lista corta para meter en el pliego o en el contrato:

  1. Acceso directo desde el dispositivo o desde el gateway local, sin dependencia de la nube del fabricante (artículo 3(1)).
  2. Dato bruto de sensor además de los derivados, con esquema publicado y unidades declaradas (artículo 4(1)).
  3. Acceso continuo y sin coste, con límites de peticiones documentados (artículo 4(1)).
  4. Relación de qué campos se consideran secreto comercial, identificados en los metadatos (artículo 4(6)).
  5. Contrato explícito sobre qué uso hace el fabricante del dato no personal y compromiso de no cesión a terceros (artículo 4(13) y 4(14)).
  6. Mecanismo para dirigir el dato a un tercero designado por el usuario (artículo 5(1)).

Si un proveedor no puede responder a esos seis puntos, el agente que ofrezca encima de su plataforma es una interfaz sobre un dato que sigue siendo suyo.

Ver también

  • Serie sobre priorización y selección de herramientas MCP en agentes.
  • Serie sobre el plano de control de inferencia (LiteLLM, Langfuse).
  • Proyecto de asistente de voz para IoT en el aula.

Fuentes