El 5G brasileño es mejor que el alemán. La latencia hasta la nube es la peor de 22 países. El puente roto. Analizamos los datos y la señal es clara: el problema no está en el radio, está en lo que ocurre entre el radio y la nube.
Esa es la contradicción que define la infraestructura brasileña de conectividad en 2026. El país entregó 5G de clase mundial. El país no entregó el backhaul que conecta ese 5G a la nube. El resultado es un gap de latencia que inviabiliza exactamente los workloads para los cuales el 5G fue construido: inferencia de IA en tiempo real, AR, agentes autónomos, voz conversacional.
El 5G brasileño es de clase mundial
Ookla publicó en julio un estudio que nadie esperaba. "Beyond Download Speed: Benchmarking 5G Mobile Networks Against AI Workloads" midió 22 mercados y 86 operadoras. Brasil tiene 5G de clase mundial.
Según Ookla, Claro entrega 32,9 ms de latencia en el radio. Mejor que Deutsche Telekom (33 ms). Mejor que el promedio del Reino Unido (46,4 ms) y de España (50,2 ms). El 5G brasileño cumple el estándar de voz conversacional para IA: menos de 40 ms. En el radio, estamos en la cima del ranking global.
Esto no es un outlier puntual. Es el resultado de años de inversión en subasta de espectro, despliegue de torres y modernización de la red móvil. El radio brasileño está listo para la próxima generación de workloads. El problema es que el radio es solo el primer hop.
El problema comienza cuando el tráfico sale de la red móvil
Latencia hasta la nube: 149,7 a 163,6 ms. Peor resultado entre los 22 países medidos, según Ookla. El Reino Unido registra 44 a 49 ms. Alemania, 42 a 45 ms. Corea del Sur, 39 a 48 ms.
Brasil es 3 veces peor que el líder europeo. El gap es 4 veces. El radio entrega en 37,6 ms. La nube responde en hasta 163,6 ms. ¿Qué ocurre en el medio?
El diagnóstico de Ookla: infraestructura concentrada y peering escaso
Según Ookla, la causa es directa: infraestructura concentrada en São Paulo y peering directo escaso. El mercado de ISPs brasileño es fragmentado. La mayoría no tiene peering directo con AWS, Azure, Google Cloud u OCI. El tráfico pasa por varios intermediarios antes de llegar a cualquier servidor.
Cada hop añade latencia. Cada intermediario añade costo. El 5G fue construido para entregar clase mundial en el radio. El puente hasta la nube quedó en el camino. No es un problema de tecnología de radio, es un problema de infraestructura de interconexión entre la red móvil y los datacenters de los grandes cloud providers.
La concentración en São Paulo significa que un usuario en Recife, en Fortaleza o en Manaus necesita rutear su tráfico hasta el eje Sudeste antes de alcanzar cualquier punto de presencia de los grandes cloud providers. La distancia física ya añade decenas de milisegundos. Los intermediarios en el camino añaden el resto. El resultado es un país con radio de punta y backhaul de segunda clase.
La consecuencia para IA es directa
Los workloads de inferencia sensibles a la latencia se vuelven inviables con 163 ms de ida. Asistentes de voz en tiempo real, AR, agentes autónomos, todos exigen respuestas que el camino hasta la nube brasileña no entrega hoy. El 5G fue construido para esto. El puente hasta la nube rompe el presupuesto de latencia antes de que la respuesta llegue.
El estándar de voz conversacional para IA es menos de 40 ms. El radio brasileño lo entrega. La nube brasileña entrega 4 veces más. Para cualquier workload que necesite respuesta en tiempo real, el gap entre radio y nube es el cuello de botella, no el 5G.
El problema no es teórico. Cuando un asistente de voz necesita esperar 163 ms de ida más 163 ms de vuelta por cada token de inferencia, la experiencia se convierte en frustración. El usuario siente el retraso. El agente autónomo pierde la ventana de decisión. La AR se desincroniza de la realidad. La latencia no es un detalle de performance, es lo que separa una workload viable de una inviable.
Es donde la arquitectura importa
Elegir la región de cloud correcta. Usar edge computing cuando la latencia sea crítica. Implementar caching agresivo para inferencia local. Evaluar inferencia on-prem cuando el camino hasta la nube no cabe en el presupuesto. En Tech86, hemos trabajado con clientes corporativos en este punto exacto: mapear el camino entre usuario y nube antes de elegir dónde corre la workload.
La pregunta correcta no es "¿qué cloud es más barata?", es "¿qué camino entre usuario y workload cabe en el presupuesto de latencia?". A veces la respuesta es una región de cloud con peering directo. A veces es edge computing cerca del usuario. A veces es inferencia on-prem donde nace el dato. A veces es caching que elimina la ida a la nube por completo. La arquitectura decide.
El 5G brasileño entrega clase mundial. El puente hasta la nube entrega retraso. La corrección no es más radio, es arquitectura.