Son la 1am. A veces las 3am — cuando hay menos usuarios conectados y el riesgo de impacto es menor.
Primero, validación: los dashboards muestran que el servicio opera normal. Todo verde. Se puede proceder.
Empieza el primer script. Se monitorea. Se revisa el output. Se anota en el ticket. Trabajo manual en medio. Otro script. Más monitoreo.
Cuando termina la ejecución, no se cierra el cambio. Viene la revalidación — otro equipo que confirma que todo sigue estable. Eso toma tiempo. Siempre más del estimado.
Aprobado. Se redacta el resumen para los stakeholders. Se cierra el CR.
Son las 5am. O las 5:30.
Pero si algo salió fuera de lo esperado — un comportamiento distinto al de staging, un paso que no respondió igual — lo más probable es que el cambio se revierta. Y revertir no es gratis: duplica el impacto, consume el tiempo que queda, y pone al equipo contra el reloj.
A las 6am el servicio tiene que estar estable. Igual que antes. Sin excusas.
Si te fue mal: reporte post-mortem. Reuniones. Explicaciones.
Esto no es una historia de error. Es cómo se hace hoy en la mayoría de los equipos de telco — con ingenieros buenos, procesos definidos, y aun así con todo el peso de la coordinación cayendo sobre personas despiertas a las 3am.
Y honestamente, yo tampoco uso AI para esto hoy. Pero cada vez que termino un cambio de esos, la pregunta es difícil de ignorar: ¿cuánto de esto podría no depender de mí?
1️⃣ El trabajo que nadie pone en el roadmap
El problema no es que los equipos de telco no sean buenos. Es que una parte enorme de su energía se va en coordinación que nadie ve.
Change requests que necesitan cinco aprobaciones y tres correos antes de arrancar. Scripts que alguien corre a mano en producción porque “siempre se hizo así”. Revalidaciones que toman el doble del tiempo estimado porque el otro equipo tiene su propia cola. Resúmenes para stakeholders redactados a las 5am con la adrenalina todavía encima.
Todo eso existe. Y casi nada aparece en ningún backlog — porque técnicamente “ya está siendo manejado”.
La deuda operativa se acumula igual que la deuda técnica. Solo que nadie la mide.
2️⃣ No es solo telco — esto está pasando en todos lados
Cuando cuento esta historia a colegas de otros sectores, la reacción es siempre la misma: “eso también nos pasa a nosotros”.
Y hay algo importante que aclarar antes de seguir: el problema no es el upgrade. El problema es cualquier cambio en producción — y eso incluye modificar un parámetro de configuración, ajustar un timeout, cambiar una variable de entorno, activar un feature flag.
Un cambio de una línea. El mismo proceso alrededor.
Planning, análisis de impacto, aprobaciones, coordinación con otros equipos, ventana de mantenimiento, ejecución, validación, revalidación, comunicación a stakeholders, cierre del CR. La ejecución en sí puede tomar dos minutos. Todo lo demás puede tomar días — y la noche del cambio, horas.
Eso es lo que hace el proceso pesado. No la complejidad técnica del cambio, sino el peso organizacional que lo rodea.
En banca pasa exactamente igual. Un ajuste en los parámetros de un servicio de pagos, un cambio de configuración en el motor de riesgo, una actualización de certificados — cualquiera de esos requiere control de cambios, validaciones previas, equipo de revalidación, resumen para compliance. Si algo sale mal antes de que abran las sucursales, el impacto es inmediato y visible.
En plataformas SaaS críticas — billing, aprovisionamiento, herramientas internas — el desafío no es la ejecución técnica. Es garantizar que el cambio fue coordinado, validado, ejecutado en el orden correcto, y que alguien estaba mirando los dashboards en el momento justo. Hoy eso depende de personas. Un agente puede hacerse cargo de esa vigilancia y escalar solo cuando hay una anomalía real.
El patrón es transversal: industria distinta, stack distinto, mismo peso de coordinación. La complejidad no está en el cambio — está en todo lo que hay que hacer para que ese cambio sea seguro, trazable y comunicado.
3️⃣ Qué podría cambiar un agente en ese flujo
No voy a entrar en detalle de implementación — eso depende de cada organización, cada stack, cada nivel de riesgo.
Pero sí vale mostrar dónde están las oportunidades más claras:
Antes del cambio: validar que el CR cumple la política, cruzar con el calendario de cambios, confirmar que staging pasó las pruebas. Hoy eso lo hace una persona revisando tres sistemas distintos. Un agente puede hacer esa cadena en segundos y solo escalar si hay una excepción real.
Durante el cambio: monitorear el output de cada paso, comparar contra el comportamiento esperado, registrar automáticamente en el ticket. El ingeniero sigue presente — pero con ojos en lo que importa, no copiando logs a mano.
Después del cambio: generar el borrador del resumen para stakeholders, documentar los pasos ejecutados, actualizar el estado del CR. Lo que hoy depende de que alguien tenga energía a las 5am para escribir.
Si algo sale mal: el contexto completo ya está en el log. El rollback tiene historia. El post-mortem empieza con hechos, no con memoria.
En ninguno de estos casos el agente reemplaza al ingeniero. Lo que reemplaza es la carga de ser al mismo tiempo el que ejecuta, monitorea, documenta y comunica — todo a la vez, a las 4am.
4️⃣ Los roles que están cambiando — y los que no van a sobrevivir el cambio
Hay una conversación que los equipos de TI están evitando.
No es “¿nos van a reemplazar?”. Esa pregunta es fácil de descartar. La pregunta difícil es otra: ¿qué pasa con los profesionales cuyo valor está en ejecutar el proceso, no en diseñarlo?
El ingeniero que sabe correr los scripts, seguir el runbook, y documentar el cambio — ese perfil va a tener cada vez menos espacio. No porque sea malo. Sino porque eso es exactamente lo que un agente puede hacer más consistentemente, sin cansarse, sin cometer el error del turno de noche.
Lo que no se puede delegar tan fácilmente es el criterio. Saber que este cambio específico, aunque parece simple, toca un componente que tuvo problemas el mes pasado. Saber que la ventana de mantenimiento propuesta coincide con un evento comercial importante. Saber cuándo parar aunque el proceso diga que se puede continuar.
Ese conocimiento no está en ningún runbook. Está en años de operar sistemas reales.
El problema es que no todos van a hacer esa transición. Algunos equipos van a seguir haciendo lo mismo que hoy — hasta que la diferencia con los que ya automatizaron sea demasiado visible para ignorarla. Y para entonces, ponerse al día va a ser más difícil que empezar ahora.
No lo digo como crítica. Lo digo porque lo veo en el mundo en que trabajo. La brecha entre los equipos que están evolucionando su forma de operar y los que están esperando que alguien les diga qué hacer ya existe. Todavía es pequeña. No va a serlo por mucho tiempo.
Cierre
Sigo ejecutando cambios a las 3am. Sigo coordinando con el equipo de revalidación. Sigo redactando resúmenes para stakeholders cuando ya casi amanece.
No tengo un agente haciendo eso hoy. Y no voy a decir que la solución es simple ni que está al alcance de cualquier equipo mañana.
Pero lo que sí sé, desde adentro de este mundo, es que la conversación ya cambió. Antes la pregunta era si la IA podía hacer algo útil en operaciones. Ahora la pregunta es cuándo tu equipo va a dejar de hacer a mano lo que otros ya automatizaron.
Eso no me genera ansiedad. Me genera urgencia de entender bien el problema antes de que alguien más lo resuelva por mí.
Si trabajas en operaciones de TI — en telco, en banca, en cualquier industria donde un cambio mal coordinado tiene consecuencias reales — creo que vale la pena hacerse esa pregunta ahora, con calma, antes de que la presión te la haga responder apurado.
✍️ Claudio desde ViaMind
“Atrévete a imaginar, crear y transformar.”
Tags: agentes de IA, operaciones TI, automatización telco, change requests, upgrades de plataforma, banca, roles TI 2026
POST DESTACADOS
SOBRE MI
Ecosistema ViaMind
- ViaMind — El núcleo de ideas, tecnología y estrategia.
- NeuraPRO — Software práctico para gestionar operaciones reales.
- Consulting — Asesoría para decisiones complejas en IA y telecomunicaciones.