Si para actualizar el modelo de churn hay que apagar toda la plataforma, el problema no es el modelo 🔧
Se cree que en telecomunicaciones la IA falla por datos insuficientes. En la mayoría de los casos falla porque la arquitectura no permite que la predicción llegue a quienes deben actuar. No es un problema de datos, es un problema de estructura.
Las telecomunicaciones combinan alto volumen, múltiples canales y decisiones que no esperan. Un operador detectando una falla, un agente en una reclamación y un portal de autoservicio comparten infraestructura pero sirven a propósitos distintos. Cuando esa infraestructura no puede moverse por partes, la IA pierde la velocidad que necesita para ser útil.
Imagina una plataforma donde churn, autoservicio y tickets comparten código. Mejorar el modelo de abandono obliga a congelar despliegues, coordinar con otros módulos y planear una ventana de mantenimiento. El cliente que iba a cancelar lo hace mientras el equipo espera la aprobación. No es falta de análisis, es incapacidad de actuar.
Ahí es donde los microservicios, donde cada capacidad del negocio vive como componente separado que puede actualizarse sin detener los demás, cambian el escenario. El modelo de churn se reentrena y despliega sin que el portal ni los tickets sepan que algo cambió. Según IBM, el 87% de quienes ya usan esta arquitectura cree que el esfuerzo vale (IBM, 2021).
Pero separar servicios no resuelve todo. Una app móvil, un portal web y un agente no necesitan el mismo formato de respuesta. El patrón BFF, del inglés Backend for Frontend, coloca una capa que adapta la respuesta al canal que la solicita. Así el modelo de incidentes entrega lo justo al agente en la llamada sin saturar otros canales.
Lo mismo ocurre cuando la red detecta una anomalía o facturación identifica un patrón inusual. Una arquitectura orientada a eventos permite que esa señal llegue a quien la necesita sin paralizar el resto. Nvidia halló en 2024 que cerca del 90% de las empresas de telecomunicaciones ya usa IA en algún punto (Nvidia, 2024). La pregunta no es cuántas empezaron, sino cuántas logran que actúe a tiempo.
Si para actualizar el modelo de churn hay que apagar toda la plataforma, el problema no es el modelo.
Primero, separar las capacidades en componentes que evolucionen sin coordinación masiva. Luego, conectar esos componentes por eventos para que la información fluya sin que nadie la solicite. Después, adaptar la respuesta al canal que consume la inteligencia. Por último, gobernar con visibilidad centralizada para que la autonomía no se vuelva opacidad.
→ Explora el hub de IA en Producción →
Versión en inglés
If You Have to Shut Down the Platform to Update the Model, the Problem Is Not the Model 🔧
It's believed that in telecommunications AI fails because of insufficient data. In most cases it fails because the architecture doesn't allow prediction to reach those who must act. It's not a data problem, it's a structure problem.
Telecommunications combine high volume, multiple channels, and decisions that don't wait. An operator detecting a failure, an agent on a complaint, and a self-service portal share infrastructure but serve different purposes. When that infrastructure can't move by parts, AI loses the speed it needs to be useful.
Imagine a platform where churn, self-service, and tickets share code. Improving the abandonment model forces deployment to freeze, coordinate with other modules, and plan a maintenance window. The customer about to cancel does so while the team waits for approval. It's not lack of analysis, it's inability to act.
That's where microservices, where each business capability lives as a separate component that can be updated without stopping the others, change the scenario. The churn model is retrained and deployed without the portal or tickets knowing something changed. According to IBM, 87% of those already using this architecture believe the effort is worth it (IBM, 2021).
But separating services doesn't solve everything. A mobile app, a web portal, and an agent don't need the same response format. The BFF pattern, Backend for Frontend, places a layer that adapts the response to the channel requesting it. This way the incident model delivers exactly what the agent needs on the call without saturating other channels.
The same thing happens when the network detects an anomaly or billing identifies an unusual pattern. Event-driven architecture allows that signal to reach whoever needs it without paralyzing the rest. Nvidia found in 2024 that about 90% of telecommunications companies already use AI somewhere (Nvidia, 2024). The question isn't how many started, but how many manage to have it act on time.
If you have to shut down the platform to update the churn model, the problem is not the model.
First separate capabilities into components that evolve without massive coordination. Then connect those components by events so information flows without anyone requesting it. Then adapt the response to the channel consuming the intelligence. Finally govern with centralized visibility so autonomy doesn't become opacity.