El punto donde más proyectos del internet de las cosas (IoT) se tuercen no suele ser el software ni la analítica de datos, sino algo que muchas organizaciones siguen tratando como un detalle técnico de última hora: la conectividad.
SECCIONES
Cuatro errores que pueden hundir un proyecto de IOT
HD
Harvard Deusto
Management & Innovation (Núm. 89) · TIC · Octubre 2026
Esa es, precisamente, la primera lección que dejan los despliegues de IoT fallidos: la conectividad no es un accesorio que se añade al final del proyecto, sino una decisión estratégica que condiciona el diseño desde el primer día. Afecta a la elección del hardware, a la compatibilidad con las redes de cada mercado, a la seguridad, a la continuidad operativa y, en última instancia, al coste total de propiedad de todo el ecosistema.
A continuación, repasamos los cuatro errores más habituales que comprometen un despliegue de IoT y por qué corregirlos a tiempo marca la diferencia entre un proyecto escalable y otro que se queda atrapado en el proyecto piloto.
1. Escalar sin validar el ecosistema de conectividad. Uno de los espejismos más frecuentes en proyectos de IoT internacionales es pensar que, si un dispositivo funciona en un país, funcionará igual en cualquier otro. No es así. La disponibilidad de bandas de frecuencia, el soporte de tecnologías de acceso y las particularidades de cada red local varían. La validación previa del ecosistema completo (no solo del dispositivo) es lo que evita sorpresas costosas en producción.
2. Elegir el hardware pensando solo en el presente. Comprar el módulo de comunicaciones más barato puede parecer una decisión razonable a corto plazo, pero rara vez lo es a largo plazo. Un proyecto de IoT bien diseñado necesita hardware compatible con los estándares actuales y con capacidad para acompañar la evolución de las redes durante todo su ciclo de vida. La progresiva desconexión de tecnologías heredadas como el 2G y el 3G en varios países es un recordatorio de que un despliegue IoT no se diseña para hoy, sino para los cinco o diez años siguientes.
3. No validar el ecosistema completo, solo sus piezas sueltas. La conectividad de un dispositivo no depende de un único elemento, sino de que todas las piezas (SIM, módulo, perfil, estándares de aprovisionamiento remoto, configuración de APN…) funcionen de forma coordinada. Es habitual comprobar cada componente por separado y dar por hecho que, si cada uno funciona de forma aislada, el conjunto funcionará igual de bien. La experiencia demuestra lo contrario: las incompatibilidades aparecen precisamente en la intersección entre elementos.
4. Ignorar el marco...
