Los productos conectados - dispositivos que integran hardware, firmware, conectividad inalámbrica y dependencia de la nube en un único sistema - se conocen comúnmente como productos IoT (Internet of Things, o Internet de las Cosas). Su desarrollo tarda más, presentan tasas de fallo más elevadas y resultan más costosos de modificar de lo que los equipos suelen anticipar - no porque cada disciplina se ejecute mal por separado, sino porque están mal coordinadas entre sí.

Según IoT Analytics, el tiempo promedio que tarda un producto IoT en llegar a su primer cliente de pago es hoy de 41 meses - casi un 80% más que en 2020, cuando esa cifra rondaba los 23 meses. Este dato proviene de una encuesta realizada a 100 fabricantes de equipos originales (OEM) como parte del IoT Commercialization & Business Model Adoption Report de IoT Analytics, con datos de mercado de 2023.

Aunque el estudio se centró principalmente en entornos industriales y de fabricantes OEM, varias de las restricciones técnicas de base - integración RF, fiabilidad de las actualizaciones OTA, carga de certificación y seguridad del ciclo de vida - no son exclusivas de ese sector y pueden aplicarse de forma más amplia a los productos de consumo conectados. Extrapolar de esa manera va más allá del alcance del estudio, pero es una hipótesis razonable dado que las bases técnicas son compartidas.

Las cifras más citadas sobre tasas de fracaso en iniciativas IoT provienen de mediados de la década de 2010 y deben tomarse con cautela. Una encuesta de Cisco de 2017, realizada a 1.845 responsables de decisiones en TI y en el área de negocio, encontró que solo el 26% de las empresas declaró haber tenido éxito completo en sus proyectos IoT - una cifra global que ocultaba una brecha más pronunciada: los encuestados del área de TI reportaron éxito en aproximadamente el 35% de los casos, mientras que los responsables de negocio lo hicieron en torno al 15%. Además, el 60% de las iniciativas se quedó estancado en la fase de prueba de concepto. Existen datos más recientes en investigaciones propietarias e informes de analistas, pero no hay estudios públicos comparables a esa escala. Las condiciones estructurales que generaron esos números - desalineación organizacional, complejidad de integración subestimada y falta de claridad en la asignación de responsabilidades - siguen siendo ampliamente documentadas en la literatura especializada.

En conjunto, los datos sobre el prolongado tiempo de llegada al mercado y las históricamente bajas tasas de éxito apuntan a una limitación estructural, no a una desaceleración temporal - una limitación que tiene sus raíces en cómo las disciplinas del desarrollo de productos conectados se condicionan mutuamente.

IoT es un sistema acoplado

Esto tiene consecuencias directas en la forma en que los usuarios experimentan los productos conectados - no como interfaces, sino como sistemas cuyos modos de fallo no pueden localizar ni explicar fácilmente. En el desarrollo de productos convencional, las disciplinas suelen operar con una separación secuencial significativa: el hardware puede finalizarse antes de que el firmware esté fuertemente condicionado, y la experiencia de usuario puede diseñarse sobre una plataforma razonablemente estable. En los productos conectados, esas fronteras desaparecen rápidamente. Las disciplinas en sí son conocidas - el problema es que la comunicación inalámbrica, las restricciones de consumo energético, el cumplimiento normativo y la dependencia de la nube generan dependencias físicas y lógicas que atraviesan todas ellas al mismo tiempo.

La ubicación de la antena modifica el diseño del enclosure (carcasa del dispositivo). La estrategia de gestión de energía afecta el área de la PCB y el comportamiento térmico. La arquitectura del firmware determina si las actualizaciones seguras seguirán siendo viables después del lanzamiento. Los requisitos de certificación condicionan tanto el hardware como el software mucho antes de que el producto tenga una apariencia terminada.

Este acoplamiento es uno de los principales responsables del prolongado tiempo de llegada al mercado descrito al inicio. El patrón de fallo más habitual no es que una sola disciplina falle - es que una decisión tomada en un área cierra silenciosamente opciones en todas las demás, y eso es exactamente lo que reflejan los datos de tiempo de llegada al mercado.

La seguridad y el cumplimiento normativo no pueden incorporarse tarde

Un estudio de referencia de 2024 realizado por Memfault y VDC Research, basado en una encuesta a más de 775 profesionales del desarrollo IoT, reveló que un tercio de los encuestados no cree que su organización evalúe adecuadamente la ciberseguridad de sus productos. Esto refleja un problema más profundo: la seguridad todavía se trata como una actividad de la fase de revisión, no como una restricción arquitectónica.

La Ley de Resiliencia Cibernética (Cyber Resilience Act) introduce obligaciones de notificación de vulnerabilidades a partir del 11 de septiembre de 2026. Los fabricantes deberán notificar las vulnerabilidades explotadas activamente en un plazo de 24 horas desde que tengan conocimiento de ellas - primero a un CSIRT (Equipo de Respuesta a Incidentes de Seguridad Informática) nacional, con ENISA recibiendo la notificación de forma simultánea como parte de ese proceso -, y deberán completar notificaciones adicionales dentro de los plazos establecidos. Las obligaciones principales relativas al producto - que abarcan el diseño seguro, el soporte del ciclo de vida y los requisitos de documentación - entrarán en vigor el 11 de diciembre de 2027. Se recomienda verificar estas fechas en la versión vigente del Diario Oficial, ya que los plazos de implementación han variado en el pasado. Cumplir con estas obligaciones en la práctica requiere sistemas capaces de detectar y hacer visibles las señales de explotación en tiempo real - no únicamente procesos de documentación. En mercados regulados como el de la Unión Europea, la ciberseguridad se está convirtiendo cada vez más en un requisito de acceso al mercado.

Las capacidades de seguridad clave dependen de decisiones de diseño tempranas: el arranque seguro depende de la selección de la plataforma; la fiabilidad de las actualizaciones OTA depende del diseño de memoria y la estrategia de reversión; y la gestión de vulnerabilidades a largo plazo depende de decisiones sobre el ciclo de vida tomadas antes de que exista el primer prototipo.

Para los productos de consumo conectados en Europa, ETSI EN 303 645 define la línea base de seguridad, abarcando actualizaciones, credenciales, divulgación de vulnerabilidades y soporte del ciclo de vida. Los productos industriales y del sector sanitario están sujetos a marcos normativos distintos, pero los principios de diseño subyacentes - arquitectura segura por defecto y con conciencia del ciclo de vida - aplican en ambos contextos. En los productos conectados, la seguridad no es una funcionalidad - es parte de la definición del producto.

El hardware es donde el acoplamiento se vuelve físico

Los fallos en la primera prueba de compatibilidad electromagnética (EMC) son ampliamente reconocidos en la industria como algo habitual. Rohde & Schwarz señala que más del 50% de todos los productos no superan las pruebas EMC en el primer intento - una cifra coherente con las estimaciones de los laboratorios de certificación y consultorías de cumplimiento normativo en distintas categorías de productos. Las tasas varían según la madurez del diseño, y las estimaciones específicas para dispositivos IoT son considerablemente más altas. La tasa es lo suficientemente elevada como para que un fallo en la primera prueba deba contemplarse en la planificación de tiempos y presupuesto desde el inicio.

El enclosure nunca es neutral en los productos inalámbricos. La elección de materiales, el espaciado, la ubicación de la antena y la geometría interna influyen en el rendimiento de RF. Un diseño que funciona en CAD puede fallar una vez que se coloca en su entorno mecánico real.

La certificación convierte esto en una restricción de negocio. Para productos más sencillos o aquellos que utilizan módulos precertificados, la certificación FCC puede oscilar entre 1.000 y 10.000 dólares según estimaciones publicadas por proveedores de pruebas y consultorías de cumplimiento normativo - para diseños RF personalizados, especialmente productos celulares, los costos pueden llegar a entre 50.000 y 200.000 dólares o más.

Según los precios publicados por distribuidores al momento de redactar este artículo, los módulos básicos de BLE y Wi-Fi suelen costar entre 1 y 10 dólares en volumen, mientras que los módulos multiprotocolo de rango medio y las opciones celulares como LTE-M y NB-IoT pueden alcanzar entre 10 y 50 dólares o más por unidad según el proveedor y el nivel de volumen - aunque estas cifras varían con las condiciones del mercado y deben verificarse con datos actuales de distribuidores. Los envíos fallidos a certificación generan trabajo de rediseño, nuevas pruebas y retrasos en los cronogramas.

Los módulos de radio precertificados reducen el riesgo de certificación, pero incrementan el costo por unidad. Las implementaciones RF personalizadas pueden ser más rentables a escala, pero requieren mayor experiencia y conllevan un riesgo inicial más elevado. La pregunta más relevante no es qué módulo elegir, sino cuándo se tomó esa decisión.

Los cambios tardíos en la arquitectura RF son un patrón que los equipos de desarrollo embebido identifican de manera consistente como una de las principales fuentes de sobrecostos y retrasos - una visión coherente con los patrones documentados de fallos EMI y con datos más amplios de proyectos embebidos, aunque aún no respaldada por un único estudio trazable.

La interoperabilidad es donde reside el valor

La investigación de McKinsey sobre IoT de 2015 identificó la interoperabilidad como uno de los factores determinantes más importantes del valor realizado en proyectos IoT - un hallazgo coherente con la experiencia de los profesionales del sector, aunque la distribución precisa varía según el caso de uso y la madurez del mercado. Esa investigación tiene más de una década de antigüedad y el panorama de la interoperabilidad ha cambiado de forma sustancial desde entonces - especialmente con la aparición de estándares como Matter y Thread, que no existían en ese momento. La conclusión de fondo sigue vigente en la práctica: los despliegues compartimentados y sin interoperabilidad dejan sistemáticamente sin aprovechar un valor potencial considerable.

Cada capa del stack fragmenta el problema. Los equipos deben elegir entre Wi-Fi, Bluetooth, Zigbee, Thread, LoRa, LTE-M y NB-IoT. Cada elección se propaga hacia el diseño de protocolos, los flujos de aprovisionamiento, las dependencias en la nube, los modelos de identidad y la complejidad de integración. Una decisión que parece menor al inicio del desarrollo suele convertirse en una restricción a largo plazo.

Estándares como Matter ayudan a reducir la fragmentación, pero no eliminan la complejidad arquitectónica - la desplazan hacia etapas más tempranas: la selección del hardware, la arquitectura del firmware y la estrategia de conectividad. 

Matter 1.5 (lanzado en noviembre de 2025) amplió la especificación a nuevas categorías de productos - cámaras, cierres motorizados (puertas de garaje, persianas motorizadas y similares), un nuevo tipo de dispositivo para tarifas de energía eléctrica con soporte para precios en tiempo real e intercambio de datos tarifarios (según las notas de versión de CSA), y soporte TCP completo para transferencia de datos de alto ancho de banda - y cada nueva categoría incrementa la carga de certificación y arquitectura. El ecosistema de Matter ha crecido de manera significativa desde su lanzamiento, aunque los desafíos de interoperabilidad en entornos reales siguen apareciendo en distintas plataformas.

El mismo principio aplica a las arquitecturas de borde y nube. Los sistemas sensibles a la latencia no siempre pueden depender del procesamiento centralizado para el control en tiempo real - una restricción reflejada en 3GPP TS 22.261, un estándar de 3GPP que define los requisitos de latencia de extremo a extremo por servicio y clase de caso de uso para redes 5G -, lo que ilustra el nivel de disciplina arquitectónica que exigen los sistemas en tiempo real. Cuando el comportamiento en tiempo real es relevante, la arquitectura debe reflejar esas restricciones desde el principio. Las restricciones de latencia no son preferencias de ingeniería abstractas - determinan si el producto se comporta de manera confiable en condiciones reales.

Esa fragmentación no se detiene en la capa arquitectónica - se manifiesta directamente en la experiencia del usuario con el producto. Cuando los estándares de conectividad se multiplican, los límites entre protocolos se difuminan y las dependencias en la nube se acumulan, los modos de fallo que encuentran los usuarios se vuelven más difíciles de identificar, de explicar y de resolver.

La UX es comportamiento del sistema, no diseño de interfaz

La experiencia de usuario en productos conectados no puede comprenderse plenamente a través de los marcos tradicionales centrados en la interfaz, porque los sistemas IoT se comportan como redes distribuidas y no como aplicaciones aisladas. Cuando algo falla, los usuarios rara vez saben dónde se origina el problema - en el hardware, la red, la infraestructura de nube, el estado de la cuenta o la lógica de automatización. Esa ambigüedad cambia de forma fundamental cómo los usuarios perciben la fiabilidad y la confianza en los sistemas conectados.

En la práctica, los fallos de experiencia de usuario en IoT tienden a concentrarse en torno a cuatro dimensiones interconectadas que reflejan la naturaleza distribuida de estos sistemas:

• visibilidad del estado (los usuarios necesitan saber qué está haciendo el sistema en cada momento),
• confianza (el comportamiento debe ser lo suficientemente consistente como para depender de él a lo largo del tiempo),
• predecibilidad (las automatizaciones y los programas deben funcionar según lo esperado)
• y recuperación (los usuarios necesitan rutas claras cuando algo falla).

Estas dimensiones están fundamentadas en la investigación de UX de sistemas distribuidos y se alinean con los principios de retroalimentación y estado del sistema establecidos en la literatura de factores humanos - en particular, el requisito de visibilidad continua del estado del sistema y las rutas de recuperación ante errores establecidas en los marcos fundamentales de usabilidad. Estas no son preocupaciones de diseño de interfaz - son preocupaciones de comportamiento del sistema, moldeadas por la arquitectura subyacente.

Estas dimensiones importan porque los usuarios interactúan con los sistemas conectados a través de múltiples capas simultáneamente: controles físicos, aplicaciones móviles, servicios en la nube, asistentes de voz, programas y automatizaciones de terceros. Los fallos suelen surgir de la interacción entre esas capas, no de una sola interfaz.

Un termostato que cambia su comportamiento por una automatización oculta rompe la predecibilidad. Un sensor que se desconecta sin previo aviso rompe la visibilidad del estado. Un cerrojo que funciona de forma local pero falla de forma remota rompe la confianza. En cada caso, el fallo es arquitectónico antes de ser experiencial - por eso las rutas de recuperación ante errores y el estado del sistema deben diseñarse desde el principio, no descubrirse durante las pruebas con usuarios.

El costo de equivocarse escala rápidamente

Los cambios en etapas tardías del desarrollo de productos conectados son costosos porque se propagan a través de todas las disciplinas. Una revisión de placa no es una iteración sencilla - generalmente implica trabajo adicional de ingeniería, nuevas pruebas, nuevos útiles de prueba (fixtures), retrasos en el suministro e impacto en los cronogramas posteriores. En la práctica, un único rediseño RF en etapas tardías puede absorber semanas de tiempo de ingeniería, retrasar la certificación varios meses y requerir nuevo utillaje - costos que se acumulan sobre los plazos de la cadena de suministro y las obligaciones contractuales de entrega.

NIST IR 8259, Foundational Cybersecurity Activities for IoT Product Manufacturers - en revisión activa al momento de redactar este artículo en 2026; se recomienda verificar el estado actual del borrador en nist.gov - enfatiza el enfoque de ciclo de vida, incluyendo mantenimiento, soporte y planificación del fin de vida del producto. La misma lógica aplica tanto a la arquitectura de seguridad como a la certificación: ninguna puede tratarse como una compuerta final. Los equipos que postergan ambas cuestiones lo pagan con ciclos de rediseño, sobrecostos de cronograma y restricciones en cascada a través de todas las disciplinas dependientes - de ahí que el cumplimiento EMC deba abordarse en etapas tempranas mediante el diseño del enclosure, la estrategia de antena, el blindaje y las pruebas de precumplimiento.

Los estándares de conectividad emergentes elevan aún más el nivel de exigencia. Tecnologías como Wi-Fi 6E y Wi-Fi 7, 5G privado y la mejora en la cobertura de LTE-M reducen algunas fricciones en el despliegue, pero también tienden a elevar las expectativas de usuarios y sistemas en cuanto a fiabilidad, transición fluida entre redes y rendimiento de baja latencia. Un equipo de producto que diseña un dispositivo con operación multienlace Wi-Fi 7, por ejemplo, debe decidir tempranamente si el firmware y la pila de radio pueden aprovechar la operación simultánea en varias bandas - una decisión que afecta el diseño de la antena, el diseño de la PCB y el presupuesto de batería antes de que se escriba una sola línea de código de aplicación. Los equipos que ya han internalizado el diseño paralelo y consciente de las restricciones están mejor posicionados para absorber esa aceleración que aquellos que todavía tratan las disciplinas de forma secuencial.

El diseño paralelo es la respuesta estructural

El prolongado tiempo de llegada al mercado de los productos IoT refleja no solo complejidad técnica sino, en muchos casos, desalineación organizacional - específicamente, la falla en hacer visibles las decisiones de diseño acopladas con suficiente antelación para que los equipos puedan actuar sobre ellas.

Los equipos que suelen llevar sus productos a buen término diseñan en paralelo. La ubicación de la antena, la geometría del enclosure y el diseño de la PCB se analizan de forma conjunta. Los ingenieros de cumplimiento participan en las decisiones de arquitectura desde el principio. Los equipos de firmware comprenden las restricciones de OTA y memoria antes de que se finalicen las decisiones de hardware.

El desafío suele ser menos una cuestión de inventar una nueva metodología que de alinear las disciplinas con suficiente antelación para que las decisiones acopladas permanezcan visibles - y actuar sobre esa alineación antes de que el costo del cambio se vuelva prohibitivo. Esa alineación, más que cualquier herramienta o proceso individual, es lo que determina si las restricciones acopladas emergen a tiempo o demasiado tarde.