Cuando la automatización toca al cliente

El modelo te entrega un script para recorrer el portal de Astilla y recoger páginas, y lo escribe «para ir rápido»: decenas de peticiones en paralelo, sin pausa entre ellas. Contra un servicio pequeño, eso no es recoger datos: es una carga que puede ralentizarlo o dejarlo caído. Y si el portal de Astilla se cae durante tu prueba, el daño —clientes sin servicio, una interrupción real— es tuyo, aunque el engagement esté autorizado.

Autorizado no es lo mismo que inofensivo. Un trabajo que puede afectar la disponibilidad del cliente se mide y se dosifica, no se lanza a toda velocidad porque el script lo permita.

La distinción que ordena todo esto es sencilla: automatizar el procesamiento de lo que ya tienes —ordenar notas, resumir, cruzar datos en tu estación— no toca a Astilla y se puede hacer sin más. Automatizar acciones que salen hacia los sistemas vivos del cliente es otra cosa, porque consume sus recursos y puede afectar su operación. El mismo modelo sirve para las dos, pero solo la segunda necesita cuidado con el ritmo y el alcance.

Antes de dejar correr un script, la pregunta es dónde cae su efecto: si se queda en tu máquina o si golpea la del cliente. Esa frontera decide cuánto cuidado hace falta.

Cuando un script sí va a tocar los sistemas de Astilla, se prepara para no hacer daño: se le pone una pausa entre peticiones, se baja la concurrencia, se acuerda una ventana con el cliente o se apunta contra la réplica de pruebas en vez de la producción en vivo. Perder unos minutos añadiendo ese freno es barato; provocar una caída del servicio del cliente por ir rápido, no. El modelo no pone ese freno solo: lo pone el operador al leer el script.

Ir rápido no es una virtud si el precio es la disponibilidad del cliente. La automatización bien hecha ayuda sin que el cliente note que estuviste.

Abre la estación. El modelo entregó un script que golpea el portal en vivo sin freno. Léelo y contrástalo con la nota de impacto que marca el riesgo de disponibilidad.