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

24.06.2026
guide-image

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?

La verdad es que esa pregunta es una trampa. El IoT (especialmente en contextos industriales o de misión crítica) las necesita a ambas para existir. No se trata de elegir un ganador, sino de orquestar dos filosofías muy diferentes dentro de un solo ecosistema coherente.

Como cofundador de un proveedor de conectividad IoT, tengo una visión privilegiada de este choque diario entre TI y TO. Piense en ello como dos civilizaciones alienígenas intentando compartir el mismo planeta. Analicemos por qué ambas son esenciales, en qué puntos entran en conflicto y cómo podemos lograr que coexistan sin hacer explotar el planeta.

TI: el cerebro, el analista de datos, el protector de la seguridad digital

Cuando hablamos de TI (Tecnologías de la Información) en el contexto del IoT, nos referimos a todo lo que ocurre después de que los datos del sensor salgan del entorno local y lleguen a la nube o al centro de datos. TI es la parte de la arquitectura que se ocupa obsesivamente de los flujos de información, la integridad de los datos y la ciberseguridad. En el ecosistema IoT, TI es el sistema nervioso, responsable de garantizar que la información fluya correctamente, que los datos se mantengan íntegros y que la seguridad esté siempre protegida.

Dominios centrales de TI en IoT

  • Procesamiento y almacenamiento
    • Desde servicios de nube a gran escala (como AWS IoT Core o Azure IoT Hub) hasta clústeres locales de Kubernetes y arquitecturas híbridas en el borde.
    • TI garantiza una escalabilidad elástica para que un aumento repentino de 100 000 dispositivos no colapse el sistema.
  • Protocolos de datos y middleware
    • Incluye intermediarios mensajería como MQTT, AMQP o Kafka.
    • APIs (REST/GraphQL/gRPC) que facilitan la comunicación entre dispositivos y la nube.
    • Marcos de gemelos digitales, que permiten simular el funcionamiento de una turbina eólica o una bomba antes incluso de interactuar con el equipo real. 
  • Arsenal de ciberseguridad
    • Arquitecturas Zero Trust con IAM (Gestión de Identidad y Acceso). 
    • Cifrado: TLS 1.3 para las comunicaciones y PKI (Infraestructura de Clave Pública) para la autenticación de dispositivos. 
    • Mupervisión mediante SIEM/XDR para detectar anomalías en tiempo real 
  • Ciencia de datos y analítica 
    • Canales de aprendizaje automático orientados a la detección de anomalías, el mantenimiento predictivo y los algoritmos de optimización.  
    • Paneles de control en tiempo real basados en herramientas como Grafana o Power BI. 
    • Integración con sistemas ERP, CRM y MES, que permite una inteligencia empresarial de ciclo cerrado. 

Mentalidad de TI

La visión de TI es sencilla: los datos son el nuevo petróleo. La confidencialidad y la integridad son siempre la máxima prioridad, y todo lo que no pueda actualizarse o auditarse se considera un riesgo. Sin TI, el IoT se reduciría a un conjunto de dispositivos que parpadean, sin significado alguno detrás de sus señales.

TO, en cambio, vive bajo otro principio: “si funciona, no lo toque.” La seguridad física y el tiempo de actividad tienen más peso que la ciberseguridad. Los sistemas heredados no se perciben como vulnerabilidades, sino como la columna vertebral de la infraestructura industrial. Sin TO, el IoT seguiría siendo un experimento de laboratorio que nunca llega a interactuar con el mundo real.

TO: los músculos, el genio del tiempo real, el guardián de la seguridad operativa 

Pasemos ahora a hablar de TO (Tecnologías Operativas). Aquí es donde el IoT se encuentra con el mundo físico: la maquinaria, los sensores y los sistemas de control que interactúan directamente con la realidad. En TO, los milisegundos importan y el tiempo de inactividad no solo resulta costoso, sino que también puede ser peligroso.

Dominios centrales de TO en IoT

  • Sistemas de control
    • PLCs (Controladores Lógicos Programables)
    • SCADA (Supervisión, Control y Adquisición de Datos)
    • DCS (Sistemas de Control Distribuido)
    • RTUs (Unidades Terminales Remotas)
  • Protocolos de campo (los dinosaurios que aún hacen funcionar el mundo)
    • Modbus RTU/TCP
    • Profibus, EtherCAT, CANbus
    • OPC UA para la interoperabilidad moderna
    • BACnet en automatización de edificios 
  • Requisitos fundamentales
    • Latencias determinista: tiempos de respuesta inferiores a un segundo; los milisegundos cuentan cuando se trata de detener un brazo robótico. 
    • Alta disponibilidad: funcionamiento continuo con un 99,999 % de disponibilidad, porque cada minuto de inactividad puede traducirse en pérdidas millonarias.
    • Seguridad ante todo: sistemas de respaldo, redundancia e interbloqueos. Mientras que TI se preocupa por una “brecha de datos”, TO piensa en una “lesión del operador”.
  • Realidades del ciclo de vida
    • Los dispositivos de TO suelen tener una vida útil de 20 a 30 años, y en muchos casos operan con firmware que no se ha actualizado desde hace décadas.
    • Muchos de ellos están construidos sobre infraestructuras propietarias sin ningún tipo de seguridad incorporada.

Mentalidad de TO

TO, en cambio, funciona con una filosofía muy diferente. El principio que la guía es sencillo: si algo funciona, no lo toque. La seguridad operativa y la disponibilidad continua son siempre más importantes que aplicar parches de ciberseguridad o realizar actualizaciones. Los sistemas heredados no se consideran vulnerabilidades, sino la columna vertebral de la infraestructura crítica. Para los ingenieros de TO, las mayores amenazas son el tiempo de inactividad, los daños físicos o una lesión del operador. Sin TO, el IoT seguiría confinado en los laboratorios de investigación, sin lograr ningún impacto en el mundo físico.

IoT: el matrimonio complicado entre TI y TO

Afrontemos una verdad incómoda: el IoT no es TI O TO, sino TI Y TO, integradas mediante una capa de conectividad IoT que permite su funcionamiento conjunto.

Piense en el IoT como un traductor entre dos mundos:

  • IT habla JSON, Kubernetes y Zero Trust.
  • TO habla lógica de escalera, Modbus y tiempo de actividad.
  • Los proveedores de conectividad IoT (como nosotros) nos aseguramos de que esos dos “idiomas” no entren en conflicto.

Ejemplo práctico

Un brazo robótico en una planta de producción:

  • TO garantiza que el brazo se mueva con una precisión de milisegundos y se detenga de inmediato si algo se interpone en su trayectoria. 
  • TI se encarga de que los datos generados por el brazo se registren, analicen y alimenten un modelo de aprendizaje automático que predice cuándo está a punto de fallar un motor.
  • IoT conecta ambos mundos, asegurando que las señales de seguridad nunca se retrasen por una interrupción en la nube, mientras permite que TI ejecute análisis de datos en paralelo.

Por qué el IoT necesita tanto TI como TO

El control en tiempo real proviene de TO. Los interbloqueos de seguridad, las señales de parada de emergencia y el rendimiento determinista garantizan que unos milisegundos no pongan en riesgo vidas humanas ni generen pérdidas millonarias por interrupciones operativas. En una refinería de petróleo, por ejemplo, un sensor de presión debe activar una válvula de inmediato, no después de un recorrido por la nube.

La inteligencia y la escalabilidad pertenecen al ámbito de TI. Los canales de datos masivos procesan terabytes de información cada día, mientras que los modelos de inteligencia artificial predicen fallos con semanas de anticipación. Piense en una flota logística global: los sistemas de TI procesan datos de GPS y telemetría para optimizar rutas en tiempo real.

La seguridad entre dominios es donde ambos mundos chocan. Los sistemas de TO fueron diseñados para entornos aislados, pero la conectividad IoT ha derribado esas barreras. Las prácticas de TI, como el cifrado, la gestión de identidades (IAM) y la microsegmentación, deben adaptarse a las redes de TO sin comprometer la capacidad de respuesta en tiempo real.

El gran choque cultural: las prioridades de TI y TO

Las diferencias más profundas no son solo técnicas, sino también culturales. Aquí es donde las cosas se ponen interesantes:

Atributo

Mentalidad de TI 

Mentalidad de TO 

Prioridad de seguridad

Tríada CIA (Confidencialidad, Integridad, Disponibilidad)

Tríada AIC (Disponibilidad, Integridad, Confidencialidad)

Ciclo de vida del sistema

Entre 3 y 5 años

Entre 20 y 30 años

Frecuencia de actualizaciones

Frecuentes, automatizadas

Escasas, “solo si la planta se detiene”

Consecuencia del fallo

Brecha de datos -> pérdida de reputación

Fallo físico -> inactividad, pérdidas económicas, posibles lesiones

Vector de ataque

Malware, ransomware, phishing

Intrusión de red, abuso de protocolos, sabotaje físico

Convergencia: el ingrediente secreto del éxito en IoT

El IoT solo alcanza su verdadero valor cuando se logra integrar de manera sólida TI y TO. Esta convergencia no es una única tecnología ni una herramienta específica, sino un enfoque por capas que equilibra infraestructura, seguridad y cultura organizacional.

La primera capa es la TI industrial. En ella, las pasarelas seguras traducen los protocolos heredados de TO, como Modbus o Profibus, a formatos compatibles con TI, como MQTT o HTTPS. El almacenamiento temporal en el borde (edge buffering) evita que la nube se sature con telemetría de alta frecuencia, mientras que la toma de decisiones local garantiza la continuidad de las operaciones incluso cuando la conectividad se interrumpe.

La segunda capa es la seguridad en el borde, donde los principios de Zero Trust adquieren mayor relevancia. Cada dispositivo debe tener su propia identidad: sin contraseñas compartidas ni accesos anónimos. La microsegmentación mantiene los sistemas aislados, evitando que una sola brecha afecte a toda la red, y los modelos de detección de anomalías actúan como sistemas de alerta temprana cuando las máquinas muestran comportamientos fuera de lo previsto.

Por último, la convergencia exige un cambio cultural. Los equipos de TI y TO deben aprender el lenguaje del otro: los profesionales de TI necesitan comprender la criticidad de los sistemas SCADA, mientras que los ingenieros de TO deben aceptar que los parches y la ciberseguridad ya no pueden ser opcionales. Los indicadores de desempeño unificados (KPI) que miden tanto la disponibilidad operativa como la resiliencia cibernética ayudan a alinear objetivos, y las hojas de ruta a largo plazo aseguran que los sistemas heredados puedan integrarse gradualmente en las redes modernas de TI sin interrupciones.

Resumen: TI y TO, el yin y yang del IoT

Desmitifiquemos esto de una vez por todas: el IoT no nos obliga a elegir entre TI y TO. Nos obliga a hacer que trabajen bien juntas.

  • Sin TO, solo hay ciencia de datos sofisticada sin impacto en el mundo real.
  • Sin TI,  las máquinas funcionan, pero sin inteligencia, optimización ni visibilidad global.
  • Con ambas, se libera el verdadero poder del IoT: un sistema ciberfísico seguro, inteligente y escalable. 

Como proveedores de conectividad IoT, nuestra misión no se limita a transferir paquetes de datos, sino a construir puentes seguros donde TI y TO se encuentren, sin colapsar bajo el peso de la complejidad.

En términos más técnicos: el IoT no es un duelo entre “TI y TO”, sino un desafío de integración, donde el verdadero desafío está en la interfaz.

La división entre TI y TO no se resolverá tomando partido, sino construyendo los puentes adecuados. La pregunta es: ¿avanzamos lo suficientemente rápido hacia una convergencia real? Nos encantaría conocer sus experiencias y perspectivas sobre los puntos donde TI y TO aún chocan, y dónde ha visto que logran trabajar con éxito en conjunto.

Podemos ayudarle a impulsar un IoT seguro, escalable e inteligente

Artículos relacionados

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

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

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.