Cómo los operadores pueden convertir millones de sensores simples en una red industrial inteligente

Guillermo Solomon – Director de Telecomunicaciones, Medios y Tecnología (TMT) en Deloitte Spanish Latam.

En las últimas semanas he escuchado, con distintos clientes de manufactura y logística en México, la misma pregunta formulada de varias maneras: ¿nos conviene invertir en sensores más caros o en una red privada más cara? La pregunta parece técnica, pero en realidad está mal planteada. El verdadero dilema no es cuánto cuesta medir el dato, sino quién puede interpretar millones de señales simples y convertirlas en una decisión útil para la operación.

Durante años, el Internet de las Cosas industrial se vendió como una suma de sensores, conectividad y tableros de control. El sensor mide, la red transporta y la Nube analiza. Esa arquitectura funciona bien para reportes, mantenimiento histórico o visualización de tendencias. Pero no funciona igual cuando una alarma crítica debe tener prioridad, cuando una decisión debe tomarse cerca de una máquina o cuando una planta no puede enviar toda su información cruda a una Nube distante.

Ahí está la oportunidad real para el operador de telecomunicaciones. No se trata de que cada sensor se vuelva inteligente, ni de esperar a que toda Hispanoamérica tenga redes 5G standalone desplegadas de forma masiva. Se trata de usar la red que ya existe —móvil, privada, híbrida o fija— para convertir millones de dispositivos simples en una red industrial inteligente.

El operador puede hacerlo porque tiene tres activos que ningún fabricante de sensores ni proveedor de Nube tiene juntos: identidad del dispositivo mediante la tarjeta SIM, control sobre la ruta y prioridad del tráfico y capacidad de acercar el procesamiento al sitio industrial. 

Con eso, aun sin prometer particiones virtuales completas de red, puede separar tráfico crítico, procesar datos cerca de la planta, reducir dependencia de la Nube y convertir señales dispersas en decisiones operativas.

El costo de pedirle al sensor que piense

Un sensor industrial de vibración, temperatura, presión o corriente está diseñado para ser barato, resistente y durar años con mantenimiento mínimo. En muchos casos transmite lecturas simples, en intervalos definidos, con capacidad limitada de procesamiento local. Eso es parte de su valor: puede desplegarse por cientos o miles de unidades sin convertir cada punto de medición en un proyecto de cómputo.

Pero cuando se le pide al sensor que “piense” —que detecte una falla temprana de rodamiento, que distinga una vibración anómala de un ciclo normal de arranque o que entienda cuándo una variación de temperatura sí representa riesgo operativo— el modelo cambia. Ya no se trata de sensar; se trata de procesar, inferir y decidir.

Eso exige microcontroladores más potentes, más memoria, más consumo de energía, firmware más complejo y ciclos de actualización más delicados. En una planta con cientos de máquinas críticas, cambiar la inteligencia al extremo del sensor no es una mejora incremental. Es una reconversión de capital que compite directamente contra presupuesto de producción, mantenimiento y automatización.

El costo de pedirle todo a la Nube

La alternativa que más se propone es mantener sensores simples y mandar todo a la Nube para que ahí corran los modelos pesados. Esa arquitectura es útil para entrenamiento de modelos, analítica histórica, trazabilidad o reportes corporativos. Pero tiene límites claros cuando la operación requiere respuesta inmediata.

Una instrucción que debe detener una banda, aislar una máquina, priorizar una alarma o proteger a un operador humano no puede depender siempre de una ruta que sale de la planta, cruza varios dominios de red, llega a una región de Nube y regresa. 

Incluso cuando la latencia promedio parece aceptable, el problema industrial suele estar en la variabilidad: la congestión, la pérdida de paquetes y la falta de control sobre todos los saltos de la ruta.

Además, transmitir todo el dato crudo hacia la Nube puede volverse económicamente absurdo. Una planta moderna puede producir enormes volúmenes de telemetría, video, audio industrial, datos de controladores de línea, cámaras de inspección, sensores de vibración y registros de calidad. 

Mandar todo eso sin filtrar no sólo encarece la conectividad; también aumenta la superficie de riesgo y complica el cumplimiento contractual con clientes que exigen control sobre información sensible de procesos, proveedores o productividad.

Por eso la discusión no debe ser “sensor inteligente o Nube inteligente”. La pregunta correcta es qué parte de la inteligencia debe vivir en el sitio, qué parte debe vivir en servidores cercanos del operador y qué parte debe permanecer en la Nube corporativa.

Lo que sí tiene el operador y nadie más tiene junto

El operador móvil tiene una posición privilegiada no porque pueda hacerlo todo solo, sino porque ya controla tres capas que, combinadas, son difíciles de replicar por un fabricante de sensores o por un proveedor de Nube.

Primero, tiene identidad. Cada tarjeta SIM o eSIM puede funcionar como una credencial verificable para un activo industrial. No es sólo una forma de conectar un dispositivo; es una forma de saber qué máquina es, qué permisos tiene, a qué red puede entrar y qué instrucciones puede recibir.

Segundo, tiene cercanía. El cómputo en servidores ubicados dentro de la planta, en una red privada o en un nodo metropolitano permite correr modelos de análisis cerca de donde ocurre el evento. Eso reduce viajes innecesarios hacia la Nube y permite que una decisión llegue cuando todavía importa.

Tercero, tiene control del tráfico. El operador puede diseñar rutas privadas, separar dispositivos por cliente, dar prioridad a una alarma real sobre lecturas rutinarias y evitar que el tráfico crítico compita en igualdad de condiciones contra miles de mensajes de baja prioridad.

Por separado, identidad, cercanía y control de red no resuelven el problema. Juntas, convierten al operador en el lugar natural donde puede vivir el criterio operativo: no en el sensor, que debe seguir siendo simple y barato; no únicamente en una Nube lejana, que seguirá siendo indispensable para entrenamiento y analítica; sino en una capa intermedia que interpreta, prioriza y actúa.

No hace falta esperar al 5G standalone para empezar

Hay una precisión importante para Hispanoamérica: buena parte de las redes 5G desplegadas en la región todavía no son standalone. Es decir, usan antenas 5G, pero siguen apoyándose en parte de la infraestructura 4G para el control de la red. Eso permite avanzar más rápido en cobertura y capacidad, pero limita la posibilidad de ofrecer particiones virtuales de red plenamente garantizadas de punta a punta.

Por eso el operador no debe prometer “slicing” completo si todavía no tiene una red 5G standalone o una red privada dedicada que permita controlar toda la arquitectura. Sería técnicamente débil y comercialmente riesgoso.

Pero eso no significa que la oportunidad industrial tenga que esperar. Muchos casos de Internet de las Cosas industrial no requieren slicing desde el primer día. Requieren algo más básico, más urgente y más realista: que los datos críticos no se mezclen con tráfico rutinario; que la información sensible no viaje innecesariamente a una Nube distante; que las alarmas tengan prioridad; que los modelos de análisis corran cerca de la planta; y que cada dispositivo tenga una identidad confiable dentro de la red.

Eso sí puede hacerse con arquitecturas previas a 5G standalone. El operador puede usar redes privadas LTE, redes 5G no independientes, rutas privadas de datos, salida local del tráfico, servidores cercanos a la planta y políticas de priorización. No es slicing completo, pero sí es una capa industrial de inteligencia sobre dispositivos simples.

La diferencia es importante. En lugar de vender una promesa futurista de 5G, el operador puede vender una arquitectura ejecutable hoy: dispositivos simples conectados de forma segura, tráfico industrial separado, procesamiento cercano y decisiones más rápidas. En mercados como México, Colombia, Perú, Argentina, Chile o Centroamérica, ese enfoque es más creíble que esperar a que toda la red pública evolucione primero a 5G standalone.

La pregunta correcta, entonces, no es si el operador ya puede ofrecer slicing. La pregunta correcta es si puede garantizar suficiente separación, prioridad, seguridad, cercanía y control para que una planta industrial tome mejores decisiones con los dispositivos que ya tiene desplegados.

Lo que el operador debe tener listo para ejecutar este modelo

La oportunidad es atractiva, pero no se puede vender con un brochure genérico de Internet de las Cosas. Para ejecutar este modelo, el operador necesita tener lista una arquitectura técnica y operativa específica. 

No basta con decir “tenemos 5G” o “tenemos servidores cercanos”. En una planta industrial, eso no significa nada si no se traduce en latencia medible, integración con los sistemas de producción, seguridad, operación continua y responsabilidad clara.

Lo primero es una arquitectura de conectividad industrial, no una extensión comercial de la red móvil. El operador debe poder decidir cuándo el caso requiere una red privada 5G standalone, cuándo basta una red privada LTE, cuándo conviene una red 5G no independiente, cuándo debe combinar red móvil con fibra y cuándo una red inalámbrica industrial o cableada sigue siendo la mejor opción. 

No todos los casos industriales necesitan 5G. Pero los casos de movilidad, alta densidad de dispositivos, baja latencia y priorización sí requieren una arquitectura distinta a la conectividad móvil tradicional.

Esa arquitectura debe incluir planeación de cobertura dentro de la planta, medición real de señal, análisis de interferencia, capacidad de subida de datos y diseño por zonas críticas. 

En manufactura, la subida suele ser tan importante como la descarga, porque la planta no sólo recibe información: envía telemetría, video, alarmas, imágenes de inspección y datos de control. Un diseño pensado para teléfonos inteligentes no necesariamente sirve para máquinas.

Lo segundo es una política de tráfico realista. Si el operador ya cuenta con 5G standalone, puede diseñar particiones virtuales de red para distintos usos industriales: alarmas críticas, video, mantenimiento remoto, sensores rutinarios o aplicaciones administrativas. 

Pero si todavía opera sobre 5G no independiente o sobre LTE, debe ser más preciso en la promesa. En ese caso puede ofrecer rutas privadas de datos, separación de tráfico por cliente, priorización, seguridad reforzada y salida local hacia servidores cercanos, pero no debe presentar eso como slicing completo.

Lo tercero es salida local del tráfico. Si el dato industrial sale de la planta para regresar a la planta, la arquitectura está mal diseñada. El operador debe poder mantener el tráfico crítico dentro del sitio o en un servidor cercano, con reglas claras para decidir qué información se procesa localmente, qué información se manda a la Nube corporativa y qué información se descarta porque no tiene valor operativo.

Lo cuarto es una plataforma de cómputo cercana que sea operable, no un servidor aislado. El análisis industrial debe correr en una plataforma capaz de administrar versiones de modelos, regresar a una versión anterior si algo falla, registrar eventos, monitorear desempeño y operar con redundancia. 

Si el modelo de mantenimiento predictivo falla, el operador no puede decir simplemente que “el servidor se cayó”. Necesita disponibilidad, monitoreo, control de cambios, respaldo, ciberseguridad y procedimientos de recuperación.

Lo quinto es integración con los sistemas industriales de planta. Aquí muchos operadores fallan porque intentan vender conectividad como si toda la planta hablara el mismo idioma digital. La realidad industrial está llena de controladores de línea, sistemas de supervisión, sensores legados, protocolos propietarios y equipos que no fueron diseñados originalmente para convivir con una red móvil. 

El operador no necesita convertirse en integrador industrial de tiempo completo, pero sí necesita un modelo claro: gateways certificados, conectores, interfaces de programación, normalización de datos y alianzas con integradores que entiendan cómo opera una planta.

Lo sexto es identidad de activo, no sólo identidad de línea. Una tarjeta SIM identifica una conexión; una planta necesita identificar una máquina, una ubicación, una función operativa, un responsable de mantenimiento y una política de riesgo. 

El operador debe poder mapear tarjeta SIM, equipo, máquina, zona, criticidad y política de acceso. De lo contrario, sabrá que un dispositivo está conectado, pero no sabrá si está conectado a una prensa crítica, a un montacargas autónomo o a un sensor secundario de ambiente.

La séptima es una capa de datos preparada para tomar decisiones en tiempo real. No basta con transportar mensajes o subir información a un tablero. El operador debe poder recibir flujos de datos, limpiarlos, normalizarlos, enriquecerlos con contexto de red y de activo y entregarlos a un modelo de análisis con latencia consistente.

Lo octavo es operación continua de los modelos. Los modelos no son estáticos. Una línea cambia, una máquina envejece, un proveedor modifica un componente y una vibración normal puede dejar de ser normal. El operador que quiera vender criterio operativo necesita procesos para probar modelos, desplegarlos por sitio, medir desviaciones, auditar decisiones y regresar a una versión anterior si el modelo empieza a generar falsas alarmas o a omitir eventos relevantes.

Lo noveno es seguridad de extremo a extremo. En una red industrial, una instrucción equivocada no sólo genera una mala experiencia de usuario; puede detener la producción o crear riesgo físico. La arquitectura debe incluir segmentación, cifrado, autenticación fuerte, listas de control por aplicación, monitoreo de anomalías, gestión de vulnerabilidades, endurecimiento de gateways y separación clara entre la red administrativa, la red de producción y la red de proveedores.

Lo décimo es un compromiso de servicio industrial. Un operador móvil está acostumbrado a compromisos de cobertura, disponibilidad y capacidad. Una planta necesita algo más específico: latencia máxima por caso de uso, disponibilidad por zona crítica, tiempo de restauración, procedimiento de escalamiento, ventanas de mantenimiento, pruebas de contingencia y responsabilidad compartida con el integrador y el cliente. Vender Internet de las Cosas industrial sin un modelo operativo de este tipo es vender una promesa que el área técnica no podrá sostener.

Un caso cercano: autopartes en el Bajío

Pensemos en una planta de autopartes en Querétaro o Guanajuato con doscientas máquinas críticas: prensas, brazos robóticos, líneas de ensamble, hornos, compresores y sistemas de inspección. La empresa quiere reducir paros no programados y anticipar fallas antes de que se conviertan en pérdida de producción.

La opción de “sensor más inteligente” implicaría cambiar instrumentación en buena parte de las máquinas, con proveedores distintos, protocolos distintos y un ciclo de reemplazo de años. La opción de “todo a la Nube” exigiría transportar grandes volúmenes de datos hacia un centro de datos externo, con costos de conectividad, dudas de soberanía y latencia variable.

La tercera opción es más interesante: conservar buena parte de la instrumentación existente, conectar activos críticos mediante una red privada o híbrida, normalizar los datos en gateways industriales y correr el análisis en servidores dentro de la planta o en un nodo cercano del operador. La Nube sigue participando, pero para entrenamiento, analítica histórica y mejora de modelos; la decisión operativa ocurre cerca de la máquina.

En ese escenario, el operador no vende “conectividad de sensores”. Vende menos paros, menor tiempo de diagnóstico, priorización de alarmas críticas y una arquitectura capaz de actuar antes de que el problema escale.

El ángulo regulatorio: México ya abrió una ventana

México está entrando a una etapa especialmente relevante para este debate. La consulta pública de la Licitación CRT-RRI-01, orientada al Servicio de Provisión de Capacidad para Redes de Radiocomunicaciones Inteligentes, abre la posibilidad de discutir espectro, cobertura y modelos de prestación para redes industriales de forma más concreta.

Ese lenguaje importa. No se trata únicamente de vender espectro móvil tradicional, sino de habilitar redes orientadas a productividad industrial, automatización y nuevos modelos de servicio. Para operadores, integradores y clientes industriales, la discusión deja de estar en el terreno abstracto de “5G para la industria” y empieza a ubicarse en polígonos, plantas, parques industriales, puertos y corredores logísticos.

La oportunidad, sin embargo, también trae complejidad. Un cliente con plantas en distintos estados podría enfrentar distintos proveedores, distintos niveles de cobertura, distintos modelos de operación y distintas condiciones comerciales. Por eso cualquier propuesta seria debe resolver tres preguntas antes de salir a vender.

La primera es espectro. ¿El servicio se ofrecerá sobre espectro propio, espectro licenciado industrial, espectro de un tercero, red pública con capacidades privadas o una combinación? La respuesta define cobertura, prioridad, responsabilidad y escalabilidad.

La segunda es jurisdicción de datos. Si la telemetría cruda se procesa dentro de la planta o en servidores ubicados en México, el argumento de soberanía y control de datos es mucho más sólido. Pero debe poder demostrarse contractualmente y técnicamente: dónde se procesa, dónde se almacena, quién accede, cuánto tiempo se retiene y qué sale hacia la Nube.

La tercera es responsabilidad. Cuando el operador deja de transportar datos y empieza a participar en una cadena de decisión automatizada, la pregunta legal cambia. Si una instrucción baja desde el servidor cercano y detiene una máquina —o si no la detiene a tiempo—, el contrato debe decir con precisión dónde termina la responsabilidad del operador como proveedor de red y dónde empieza la responsabilidad del cliente, del integrador, del fabricante de la máquina o del proveedor del modelo.

Por qué no ha pasado todavía

Si el argumento es tan claro, vale preguntar por qué la mayoría de los operadores en Hispanoamérica siguen vendiendo Internet de las Cosas como conectividad pura: una tarjeta SIM, un plan de datos, una plataforma genérica y un tablero.

La primera razón es organizacional. Muchas áreas comerciales todavía se miden por líneas activas, tráfico vendido o ingresos de conectividad. Un modelo que procesa localmente, reduce tráfico innecesario y vende valor por resultado puede parecer, internamente, una amenaza a la métrica tradicional. Aunque el ingreso potencial sea mayor, el incentivo inmediato apunta en sentido contrario.

La segunda razón es comercial. Vender una plataforma horizontal de Internet de las Cosas a cualquier industria suele ser lento, caro y difícil de defender. 

Vender una solución de mantenimiento predictivo, seguridad operativa o inspección crítica a tres plantas de un cliente ancla es distinto. Tiene un caso de negocio más claro, un patrocinador interno más identificable y un retorno medible en pesos: paros evitados, desperdicio reducido, menos accidentes, menos visitas de mantenimiento y mayor disponibilidad de línea.

La tercera razón es técnica. Muchos operadores todavía no tienen integrada la cadena completa entre red privada, cómputo cercano, seguridad, datos, modelos y operación industrial. Tienen piezas, pero no producto. Tienen laboratorio, pero no arquitectura replicable. Tienen acuerdos con proveedores de Nube, pero no necesariamente integración con los sistemas de planta. Tienen conectividad, pero no siempre control de punta a punta sobre el compromiso operativo que la planta necesita.

La Nube no desaparece; cambia de lugar

Este argumento no debe leerse como una oposición a los grandes proveedores de Nube. La Nube seguirá siendo fundamental para entrenamiento de modelos, almacenamiento histórico, analítica corporativa, integración con sistemas empresariales, simulaciones, tableros ejecutivos y escalamiento regional. Lo que cambia es el lugar donde ocurre la decisión crítica.

En una arquitectura industrial madura, el sensor mide, el servidor cercano decide, la red prioriza y la Nube aprende. El operador no reemplaza a la Nube; la complementa. Pero si el operador no ocupa ese espacio intermedio, alguien más lo hará: un integrador industrial, un proveedor de automatización, un operador especializado o incluso el propio proveedor de Nube mediante acuerdos directos con el cliente.

El verdadero negocio

El Internet de las Cosas industrial en México y en Hispanoamérica no se va a ganar con el sensor más caro ni con la Nube más grande. Se va a ganar con la arquitectura que permita decidir a tiempo, cerca de la máquina, con identidad confiable, prioridad de red, seguridad industrial y responsabilidad clara.

Ese lugar lo puede ocupar el operador. Pero sólo si llega preparado y si evita vender una promesa que su red todavía no puede soportar. Si tiene 5G standalone, podrá avanzar hacia particiones virtuales de red más sofisticadas. Si no lo tiene, todavía puede construir una capa industrial de inteligencia con redes privadas, rutas de datos separadas, procesamiento cercano, salida local y compromisos operativos realistas.

La oportunidad no está en conectar más dispositivos simples. Está en convertirlos en una red que entiende prioridades, reconoce activos, procesa señales y ayuda a decidir. El operador que logre hacer eso dejará de vender conectividad y empezará a vender criterio operativo. Y en una planta industrial, el criterio vale mucho más que los bytes.