TechCo vs. Telco: por qué las operadoras deben volver a construir, especialmente en IoT

24.06.2026

La brecha entre las empresas tecnológicas (“TechCos”) y las empresas tradicionales de telecomunicaciones (“Telcos”) se está ampliando. Lo que hoy distingue a las TechCos de las Telcos no son las redes que operan, sino lo que construyen a partir de ellas.

Mientras los hyperscalers (los grandes proveedores de servicios en la nube) y los actores nativos digitales siguen capturando la mayor parte del crecimiento gracias al software, las plataformas y los servicios impulsados por datos, muchas Telcos permanecen estancadas. Invierten grandes sumas en infraestructura, pero les cuesta generar nuevas fuentes de valor más allá de la conectividad.

Esta brecha resulta aún más evidente en el ámbito del IoT, donde la conectividad se ha convertido en una mercancía, y el verdadero valor se concentra en quienes construyen y gestionan las plataformas que se sitúan por encima de ella. Para seguir siendo relevantes en la próxima ola de transformación digital, las Telcos deben ir más allá de la simple venta de ancho de banda. Deben redescubrir su capacidad para construir: desarrollar software, plataformas y servicios digitales personalizados que vayan mucho más allá de la tarjeta SIM.

El modelo TechCo: quien posee la plataforma, posee el valo

Las TechCos como Amazon, Microsoft, Google y las nuevas startups de IoT siguen un enfoque sencillo:

Construyen plataformas para la gestión de datos, inteligencia artificial, dispositivos, seguridad y facturación.

Atraen ecosistemas de desarrolladores y socios.

Monetizan a través de servicios recurrentes, mejoras de valor (upsells) y nuevos modelos de negocio.

Esa es la razón por la que AWS es mucho más que un proveedor de infraestructura en la nube: es un motor de innovación. O por eso Apple obtiene ingresos que van mucho más allá del hardware, gracias a los servicios, las suscripciones y sus ecosistemas.

En el ámbito del IoT, las TechCos están ofreciendo plataformas integrales que gestionan todo el ciclo: incorporación de dispositivos, recopilación de datos, análisis, seguridad e inteligencia artificial. Facilitan a las empresas el despliegue de IoT a gran escala, ocultando la complejidad de las redes subyacentes.

¿El resultado? Ya sea NB-IoT, LTE-M, 5G o fibra, la conectividad se vuelve invisible para el cliente final: una simple línea de costos, no una ventaja estratégica.

El dilema de las Telcos: reducidas a meras proveedoras de conectividad

La mayoría de las Telcos centran sus esfuerzos en la infraestructura. Han invertido miles de millones en el despliegue de redes 5G, segmentos de red específicos dedicados al IoT, redes privadas y cobertura nacional.

Con demasiada frecuencia, ahí es donde termina la innovación. La conectividad IoT se vende como una mercancía, a precios de unos pocos centavos por megabyte o unos pocos dólares por SIM. Mientras tanto, el verdadero valor (las plataformas, los paneles de control, la analítica y la información) se queda en manos de otros.

Esto hace que las Telcos sean vulnerables a convertirse en meros mayoristas dentro de la cadena de valor del IoT, mientras que las TechCos y los especialistas del sector se apropian de la experiencia del cliente.

Por qué las Telcos deben volver a construir, especialmente en IoT

Para seguir siendo competitivas, las Telcos deben pasar de ser simples proveedoras de conectividad para convertirse en creadoras de plataformas y orquestadoras de soluciones. Desarrollar software y productos propios ya no es opcional: es crucial para su futuro.

El IoT necesita más que conectividad
Las empresas no buscan simples canales de datos, buscan resultados. Quieren rastrear activos, reducir el consumo energético, predecir el mantenimiento y mejorar la seguridad. Para lograrlo, se necesitan plataformas de datos, inteligencia artificial y aplicaciones verticales; ámbitos en los que las Telcos pueden ser líderes, si deciden comprometerse de verdad.
Poseer la relación con el cliente y los datos
Vender únicamente conectividad genera relaciones transaccionales. En cambio, ofrecer plataformas o soluciones específicas de cada sector convierte a las Telcos en socios estratégicos y les permite aprovechar los datos que circulan por sus redes para generar más valor.
Diferenciarse en un mercado saturado
Si todas las Telcos revenden el mismo software de gestión IoT, no existe diferenciación. Crear herramientas digitales propias, ofertas locales o plataformas personalizables genera lealtad y mayor poder para fijar los precios.
Aprovechar nuevas fuentes de ingresos
Al poseer la plataforma, las Telcos pueden monetizar más allá del precio por megabyte: ofrecer servicios de gestión de dispositivos, analítica, seguridad, SLA garantizados y mucho más.

Cómo se traduce “volver a construir” en la práctica

No todas las Telcos necesitan convertirse en Google. Pero sí deben desarrollar capacidades internas sólidas en torno al desarrollo de productos. Eso implica:

Incorporar product managers, ingenieros, diseñadores UX y científicos de datos.

Utilizar herramientas modernas, como arquitecturas nativas en la nube, microservicios, API abiertas y bibliotecas de inteligencia artificial.

Crear plataformas IoT modulares que funcionen de forma transversal en distintas industrias.

Apoyar a los desarrolladores con API bien documentadas, herramientas sandbox (entornos de prueba) y documentación clara.

Adoptar metodologías ágiles y mejorar continuamente en función de la retroalimentación de los usuarios.

Lo que está en juego

A medida que miles de millones de dispositivos se conectan (desde contadores inteligentes hasta robots autónomos), el IoT se convertirá en la columna vertebral de las industrias y de las ciudades. La gran pregunta es:

¿Aprovecharán las Telcos su experiencia en redes para convertirse en proveedoras de soluciones integrales?

¿O seguirán siendo simples operadoras de infraestructura, mientras otros se llevan los beneficios?

Todo se reduce a una sola decisión: volver a construir.

Reflexión final

Las Telcos ya cuentan con confianza, escala e infraestructura. Lo que muchas aún no tienen es la mentalidad y las capacidades necesarias para crear productos de software y plataformas realmente diferenciadas.

Sin embargo, si comienzan ahora, invirtiendo en equipos de desarrollo y construyendo soluciones IoT únicas, podrán capturar un valor significativo.

En emnify, hemos desarrollado nuestra plataforma con esa misma mentalidad: ofrecer a las empresas la velocidad para escalar y el control para gestionar la conectividad en sus propios términos. ¿Le interesa ver cómo funciona en la práctica? No se pierda nuestra demostración del producto.

Hablemos de estrategia y casos de éxito. Póngase en contacto con nosotros hoy mismo.

Martin Giess

Martin Giess es cofundador de emnify, donde supervisa la ejecución técnica de la visión de producto de la empresa. Cuenta con 15 años de experiencia como experto en tecnología, especializado en el desarrollo ágil de servicios de telecomunicaciones innovadores. Antes de fundar emnify, ocupó cargos de vicepresidente técnico en Syniverse y MACH.

Artículos relacionados

¿Qué es GSMA SGP.32? La guía definitiva del estándar eSIM IoT de nueva generación

23.06.2026 –

Tabla de contenidos Introducción En qué se diferencia SGP.32 de SGP.02 y SGP.22 Cómo funciona SGP.32 Cómo es la arquitectura eSIM para IoT en SGP.32 Qué requisitos de cumplimiento y estándares define SGP.32 Qué desafíos y consideraciones implica la implementación de SGP.32 Cómo impulsa emnify despliegues IoT compatibles con SGP.32 Conclusión: por qué SGP.32 es clave Introducción El estándar SGP.32 de la GSMA es la tecnología SIM global más reciente para IoT que permite la gestión remota de perfiles y el cambio entre ellos. Gracias a ello, los dispositivos conectados pueden descargar, gestionar y cambiar perfiles SIM de forma segura mediante conectividad remota, sin necesidad de interfaz de usuario, códigos QR ni sustituciones físicas de la SIM. A diferencia de los estándares anteriores de la GSMA, diseñados para implementaciones tradicionales de comunicaciones máquina a máquina (M2M), SGP.32 se ha definido específicamente para los despliegues modernos de IoT, donde la gestión logística de SIM físicas y la dependencia de un único proveedor han generado importantes desafíos operativos durante años. En esencia, SGP.32 introduce una arquitectura simplificada que permite a empresas y proveedores de conectividad gestionar perfiles SIM de múltiples operadores desde una única plataforma unificada. A gran escala, esto significa que las empresas no quedan vinculadas a un único proveedor durante todo el ciclo de vida del dispositivo, evitando así los elevados costes asociados a la sustitución de SIM al cambiar o añadir operadores. Algunos casos de uso típicos en los que esta capacidad resulta especialmente valiosa para las empresas que despliegan dispositivos conectados incluyen: Fabricantes de dispositivos conectados (OEM): necesitan que sus dispositivos se conecten directamente desde fábrica, pero sin quedar vinculados a una red específica para sus clientes. Con SGP.32, los dispositivos pueden desplegarse con un perfil de arranque que permite la conexión, y posteriormente añadir perfiles de distintos operadores en función de la ubicación del despliegue. Proveedores de dispositivos conectados: ahora cuentan con un plan de resiliencia integrado. Anteriormente, cambiar de proveedor de conectividad implicaba una gran complejidad, ya que los dispositivos ya desplegados permanecían conectados al operador original (debido al alto coste de sustituir las SIM), mientras que los nuevos despliegues podían requerir otro proveedor. Esta gestión de múltiples operadores incrementaba la complejidad y los costes operativos. Alta disponibilidad y continuidad del servicio: SGP.32 permite disponer de varios perfiles en una misma SIM, lo que hace posible un verdadero mecanismo de respaldo. En la práctica, si el perfil principal falla, el dispositivo puede cambiar automáticamente a un operador alternativo. Esto no solo protege la disponibilidad del servicio, sino también las operaciones frente a incidencias inesperadas, como interrupciones, pérdida de cobertura en la zona de despliegue o incluso la desaparición del operador. ¿En qué se diferencia SGP.32 de SGP.02 y SGP.22? SGP.02 SGP.02 fue diseñado para despliegues tradicionales de comunicaciones M2M. En teoría, permitía la descarga y el cambio remoto de perfiles. Sin embargo, en la práctica, su arquitectura resultaba compleja, costosa de integrar y poco adecuada para dispositivos IoT con limitaciones de energía o ancho de banda. Para la mayoría de los despliegues, el cambio de perfiles a gran escala no era comercialmente viable. SGP.22 SGP.22 se desarrolló para dispositivos de consumo como smartphones y tablets. Se basa en la existencia de una interfaz de usuario, el escaneo de códigos QR y la descarga de perfiles iniciada por el usuario. Este enfoque funciona perfectamente para dispositivos móviles, pero no es adecuado para dispositivos sin interfaz (headless). SGP.32 SGP.32 es el primer estándar diseñado específicamente para flotas IoT. Elimina la necesidad de interacción del usuario, es compatible con entornos con recursos limitados como NB-IoT y LTE-M, y permite gestionar el ciclo de vida completo de los perfiles orquestado desde el servidor y a gran escala. ¿Cómo funciona SGP.32? eUICC (Embedded Universal Integrated Circuit Card) Aunque no es un elemento nuevo ni exclusivo de SGP.32, la eUICC es fundamental para permitir la gestión remota de perfiles. Es el chip seguro integrado en la SIM que permite almacenar múltiples perfiles de operador. SM-DP+ (Subscription Manager Data Preparation+) El SM-DP+ es el servidor seguro donde se almacenan, preparan y cifran los perfiles eSIM para su descarga en los dispositivos. Cada perfil cuenta con un identificador único denominado código de activación, que los dispositivos utilizan para recuperar el perfil. En el caso de las eSIM de consumo, el código QR no es más que una representación gráfica de dicho código de activación. SM-DS (Subscription Manager Discovery Server) El SM-DS es un servicio de descubrimiento que los dispositivos pueden consultar para comprobar si hay nuevos perfiles eSIM disponibles. Cuando hay un perfil disponible, el sistema indica al dispositivo en qué servidor SM-DP+ se encuentra alojado para proceder a la descarga. Aunque es habitual en despliegues de eSIM para consumo, en arquitecturas IoT suele ser opcional, ya que la plataforma de conectividad puede encargarse directamente de orquestar la descarga de perfiles. EID (eUICC Identifier) Identificador único asignado a cada eUICC. Permite identificar de forma segura la SIM durante los procesos de aprovisionamiento remoto eIM (eSIM IoT Manager) Capa de control introducida con SGP.32. Permite gestionar de forma remota la descarga, activación, desactivación, eliminación y cambio de perfiles en dispositivos y flotas. El eIM puede funcionar como una plataforma independiente o integrarse en un portal de gestión de conectividad, como es el caso de emnify. Portal de gestión de conectividad (CMP) Aunque no es un concepto nuevo, es el entorno desde el que se gestiona la conectividad, como la activación o desactivación de zonas de cobertura y la modificación de planes. Es en el CMP donde puede integrarse el eIM, permitiendo gestionar funcionalidades de SGP.32, como añadir o eliminar perfiles desde una única interfaz. IPA (IoT Profile Assistant) Sustituto nativo para IoT del LPA utilizado en dispositivos de consumo. Se ejecuta en el propio dispositivo y se encarga de la detección y descarga de perfiles sin necesidad de pantalla ni intervención del usuario. Código de activación Código necesario para activar la SIM, que debe introducirse en el CMP o en el eIM para iniciar el proceso de aprovisionamiento. Perfil de arranque (bootstrap) Perfil de conectividad mínimo que permite que el dispositivo se conecte por primera vez a la red, de modo que pueda descargar su perfil operativo. Perfil operativo Perfil principal del operador utilizado durante el funcionamiento normal del dispositivo. Una misma SIM puede almacenar múltiples perfiles operativos. Perfil de respaldo (fallback) Perfil secundario de operador almacenado en la misma SIM que puede activarse en caso de fallo del perfil principal, garantizando la disponibilidad del servicio y la continuidad operativa. Intervalo de sondeo (polling interval) Frecuencia con la que el dispositivo se conecta al eIM para comprobar si hay nuevos perfiles disponibles. ¿Cómo es la arquitectura eSIM para IoT en SGP.32? Flujo de gestión remota de perfiles en SGP.32 El dispositivo se conecta con su perfil actual El dispositivo ya está en línea, normalmente mediante un perfil de arranque o un perfil operativo. Se programa la descarga de un perfil en el eIM Un perfil de operador se registra en el eIM mediante su código de activación, quedando preparado para su descarga en el dispositivo. El dispositivo consulta el eIM en busca de operaciones pendientes En función de su intervalo de sondeo, el dispositivo se conecta al eIM y detecta que hay un nuevo perfil disponible, incluyendo el servidor SM-DP+ donde está alojado y el código de activación necesario. The IPA prepares the device El IPA establece la sesión segura necesaria para descargar el perfil. El perfil se descarga desde el SM-DP+ El perfil de operador cifrado se transfiere de forma segura desde el SM-DP+ al dispositivo. La eUICC almacena el nuevo perfil de forma segura El perfil se instala en la eUICC, aunque no necesariamente se activa de inmediato. Se programa la activación del perfil en el eIM Un usuario o un proceso automatizado programa la activación del nuevo perfil. El dispositivo activa el perfil En el siguiente ciclo de sondeo, el dispositivo recibe la instrucción desde el eIM y el IPA activa el perfil en la eUICC. El dispositivo cambia de conectividad El dispositivo comienza a operar con el nuevo perfil de operador sin necesidad de sustituir físicamente la SIM. ¿Qué requisitos de cumplimiento y estándares define SGP.32? SGP.32 va más allá de un nuevo modelo de orquestación. Es un estándar definido por la GSMA que se fundamenta en estrictos requisitos de seguridad, interoperabilidad y transporte. Estos requisitos están integrados directamente en la especificación y son fundamentales para garantizar despliegues IoT seguros y a gran escala. Seguridad Todas las operaciones del ciclo de vida de los perfiles entre el eIM y la eUICC están autenticadas criptográficamente y protegidas en cuanto a su integridad. Esto garantiza que los perfiles no puedan descargarse, modificarse ni cambiarse sin la debida autorización. Protocolos de transporte SGP.32 es compatible con comunicaciones estándar TCP/IP, así como con protocolos ligeros como CoAP sobre UDP con cifrado DTLS. Esto permite operar de forma eficiente en una amplia variedad de entornos IoT, incluidos aquellos con limitaciones de energía y ancho de banda, como NB-IoT y LTE-M. ¿Qué desafíos y consideraciones implica la implementación de SGP.32? Ecosistema en evolución La adopción de SGP.32 aún está en desarrollo entre fabricantes, plataformas y organismos de estandarización. Las interpretaciones y el nivel de soporte pueden variar a medida que el ecosistema madura. Madurez de las plataformas No todas las plataformas IoT ofrecerán inicialmente una funcionalidad completa de eIM, soporte para IPA o herramientas de orquestación a gran escala. El nivel de implementación varía según el proveedor. Ecosistema abierto frente a implementaciones cerradas Aunque SGP.32 permite técnicamente la gestión de perfiles de múltiples operadores, no todos los proveedores admiten la orquestación de perfiles de terceros en entornos abiertos. Algunas implementaciones pueden limitar la gestión de perfiles a su propio ecosistema de red. Las empresas que evalúen soluciones basadas en SGP.32 deben analizar cuidadosamente si la flexibilidad entre operadores se ofrece realmente en la práctica y no solo a nivel teórico. Compatibilidad con versiones anteriores No es posible la migración desde estándares anteriores como SGP.02 o SGP.22. ¿Cómo impulsa emnify despliegues IoT compatibles con SGP.32? A medida que SGP.32 evoluciona desde la especificación hacia su implementación en entornos reales, la cuestión clave ya no es solo el cumplimiento, sino cómo se implementa en la práctica. El estándar permite la orquestación de múltiples perfiles y operadores. Sin embargo, su implementación real depende de la plataforma que opera la capa eIM. La arquitectura cloud-native de emnify ha sido diseñada en torno a una gestión centralizada del ciclo de vida de los perfiles, basada en API. Gracias a sus capacidades integradas de eIM, las empresas pueden descargar, activar, desactivar y cambiar perfiles tanto de emnify como de operadores de terceros en toda la flota de dispositivos desde un único plano de control. Este enfoque responde directamente al objetivo arquitectónico de SGP.32: independencia del operador a nivel de perfil, y no solo a nivel de hardware. En lugar de vincular los despliegues a un único ecosistema de red, emnify permite diseñar arquitecturas IoT en las que la conectividad puede evolucionar con el tiempo, ya sea incorporando nuevos operadores, adaptándose a nuevas regiones o añadiendo perfiles de respaldo para mejorar la resiliencia. En la práctica, SGP.32 no solo es compatible, sino que se implementa de forma que garantiza la flexibilidad a largo plazo. Descubra nuestra propuesta exclusiva basada en SGP.32: emnify Advanced eSIM. Conclusión: ¿por qué SGP.32 es clave? GSMA SGP.32 marca un cambio estructural en la forma de diseñar y operar la conectividad IoT. Representa la transición de la gestión basada en SIM físicas a una orquestación de perfiles impulsada por software, diseñada específicamente para flotas de dispositivos sin interfaz y a gran escala. Al permitir una gestión segura del ciclo de vida de los perfiles orquestada desde el servidor, SGP.32 ofrece a las empresas la capacidad de añadir, modificar y gestionar perfiles de operador de forma remota, sin intervención física. Los dispositivos pueden salir de fábrica ya conectados mediante un perfil de arranque, lo que reduce la necesidad de múltiples SKU regionales y elimina gran parte de la complejidad logística asociada a las SIM en despliegues globales. Además, SGP.32 introduce una verdadera independencia de proveedor. Las empresas pueden adaptar la conectividad a medida que sus despliegues se expanden a nuevas regiones, incorporar nuevos operadores con el tiempo y evitar la dependencia de un único proveedor durante todo el ciclo de vida del dispositivo. Asimismo, refuerza la resiliencia operativa. Al permitir almacenar y gestionar múltiples perfiles en una única eSIM, las organizaciones pueden implementar opciones de conectividad de respaldo que garantizan la disponibilidad del servicio y reducen el riesgo operativo ante incidencias de red o cambios en la cobertura. Para las organizaciones que desarrollan despliegues IoT globales, comprender SGP.32 ya no es opcional: es un elemento fundamental para diseñar arquitecturas de conectividad flexibles, escalables y sostenibles a lo largo de todo el ciclo de vida del dispositivo.

TI vs. TO en IoT: ¿realmente necesitamos las dos?

24.06.2026 –

En el mundo del IoT (Internet de las Cosas) existe un debate recurrente que con frecuencia se simplifica en una dicotomía: ¿necesitamos TI o necesitamos TO?

eSIM: un camino lleno de falsas promesas

24.06.2026 –

No faltan las grandes promesas en el mundo de la eSIM: libertad para cambiar de proveedor, gestión completa del ciclo de vida, control total. Pero si se observa más de cerca, se descubre algo oculto tras todo ese marketing: el fracaso. Hay un dicho en alemán: die Straße ist gepflastert mit Leichen (“la calle está pavimentada con cadáveres”). Significa que muchos lo han intentado, pero la mayoría ha fracasado. En el ámbito de la eSIM M2M (SGP.02), la expresión resulta bastante precisa. Ese camino está lleno de sistemas sobredimensionados, implementaciones retrasadas e ideas “revolucionarias” que se derrumbaron en cuanto se enfrentaron a la realidad. En emnify, elegimos un camino distinto: centrarnos en la realidad actual y resolver los problemas que existen hoy. Mientras otros persiguen lo que la eSIM podría llegar a ser en 18 o 24 meses, nosotros ya la hemos hecho funcionar hoy, a gran escala y para empresas reales.