Innobate/Blog

Notas de la agencia

Cuando una automatización dice que funcionó y no hizo nada

31 de agosto de 2026Jorge Almarza8 min de lectura

Una automatización que se cae te avisa. Se llena de rojo, alguien reclama, y la arreglas ese día.

La que no te avisa es la otra: la que corre todos los días, se anota a sí misma como exitosa, y no hace nada. Nadie reclama porque nadie sabe. El proceso que reemplazaste ya no lo hace ninguna persona, así que tampoco hay quien note el hueco.

Este mes encontramos tres así en nuestro propio sistema. Una llevaba un mes rota, otra diez días, la tercera dos meses. Las tres informaban éxito en cada ejecución. Ninguna la reportó un cliente ni la levantó una alerta: las tres aparecieron cuando dejamos de mirar lo que el sistema decía y fuimos a mirar si la cosa estaba hecha.

Lo que sigue son los tres casos y, al final, la pregunta concreta que puedes hacerle esta semana a cualquier automatización que tengas andando.

¿Por qué una automatización falla en silencio?

Porque casi todas están armadas para no detenerse. Y con razón: si un paso falla, no quieres que se caiga la cadena entera y se pierda lo que venía atrás. Entonces se configuran para que un error no interrumpa el flujo.

El problema es lo que pasa después. El paso falla, no interrumpe, y nadie lee el resultado de ese paso. El siguiente eslabón recibe una respuesta vacía, la trata como si fuera buena, y sigue. Al final de la cadena hay un mensaje que dice "listo".

Piénsalo así. Le pides a alguien que deje una encomienda en una dirección. Llega, la casa no existe, y en vez de llamarte sigue su ruta y al final del día te dice "terminé el recorrido". Y es verdad: terminó el recorrido. Nunca dijo que la encomienda quedó entregada, y tú nunca preguntaste.

Ese "terminé el recorrido" es lo que ves en el panel de casi cualquier herramienta de automatización. Verde quiere decir que corrió, no que hizo. Son dos preguntas distintas y hay una sola luz para las dos.

El mes en que archivamos cero documentos, todo en verde

Tenemos un flujo que toma las boletas que llegan por correo, las registra como gasto y guarda el archivo en la carpeta que corresponde en Google Drive.

La carpeta de destino estaba escrita con un identificador equivocado. La diferencia entre el bueno y el malo era un carácter: una ele minúscula donde iba una i mayúscula. En pantalla son idénticas. Google respondía, correctamente, que esa carpeta no existe.

Como el paso estaba configurado para no interrumpir, el error se propagaba como "carpeta vacía" hasta el final, y el flujo llegaba igual al aviso de siempre. El día que llegó la boleta real, el aviso salió tres segundos después de registrarla, como si todo hubiera ido bien.

Estuvo así un mes. Y lo que casi nos hace no revisarlo: en la carpeta sí había boletas de los meses anteriores. Parecían la prueba de que el flujo andaba. Las había puesto una persona a mano. Nos dimos cuenta porque la carpeta de julio fue creada media hora después del archivo que contenía, y eso ninguna automatización lo hace.

Piénsalo así. Ves el patio barrido y das por hecho que el robot aspirador funciona. Lo barrió alguien de tu casa, que no te lo mencionó. El robot lleva un mes dando vueltas con la bolsa desconectada.

¿Y si lo que se atasca bloquea todo lo que viene atrás?

El segundo caso empezó como dos notas de voz de WhatsApp que no se habían transcrito. Eran treinta y seis.

El proceso pedía siempre la más antigua pendiente. La más antigua era irrecuperable: por su antigüedad, el servidor de WhatsApp ya no la entregaba. Entonces nunca salía de la fila, y como siempre se pedía la primera, las treinta y cinco de atrás jamás llegaban a tocarse. El proceso corría cada dos minutos, no lograba nada, y se anotaba exitoso. Diez días.

Piénsalo así. Una fila de un solo cajero, donde el primero de la fila no trae los papeles y no se va. El cajero lo atiende, no puede resolver, y vuelve a llamar al mismo. Los treinta y cinco de atrás no avanzan un paso, y el reporte del día dice que el cajero atendió sin parar.

El arreglo fue de una línea de lógica: si lo que se pidió no llega, márcalo como no recuperable, avisa, y sigue con el siguiente. En diez minutos la fila bajó de 36 a 16, y de todo eso hubo un solo audio realmente perdido. Los otros treinta y cinco estaban bien y esperando detrás de él.

Y el aviso que agregamos para que esto no volviera a ser mudo tenía su propio defecto: el nombre técnico que iba en el texto llevaba un guion bajo, y por cómo interpreta el formato la aplicación de mensajería, el mensaje entero era rechazado. O sea: la alerta se caía justo cuando tenía algo que avisar. La encontramos porque probamos el aviso, no porque lo diéramos por bueno.

¿Y si el que revisa también está roto?

El tercer caso es el que más incomoda, porque el que fallaba era un control.

Tenemos un respaldo diario de la base de datos. El archivo se generaba puntual todos los días y pesaba lo suyo. Estaba corto. El servidor entrega como máximo mil filas por consulta y no avisa que hay más: si pides cinco mil, te manda mil y responde con normalidad. Había que pedir el resto en tandas, y no se estaba pidiendo. Cada respaldo guardaba las primeras mil filas de cada tabla y se anotaba completo.

El mismo defecto, la misma semana, apareció en otra parte: una pantalla interna que muestra cuánto gastamos en modelos de IA estaba mostrando menos de la mitad del gasto real, por la misma razón.

Fíjate en la dirección del error, que es lo peligroso: mientras más grande la tabla, menos muestra. Un total que baja no se lee como una falla. Se lee como una buena noticia.

Piénsalo así. Cuentas la caja y te da menos de lo que esperabas. Piensas que vendiste menos. En realidad estás contando solo el primer fajo, y mientras más plata haya, mayor es la parte que no estás contando.

¿Cómo se comprueba que un control sirve?

Rompiéndolo a propósito.

Un control que nunca falló no es un control probado: es un control del que no sabes nada. Puede estar vigilando bien, o puede estar mirando el lugar equivocado desde el primer día. Desde afuera se ven igual, porque los dos están en verde.

Lo comprobamos midiéndonos. Tomamos veinticinco de nuestras propias verificaciones automáticas, rompimos a propósito el código que cada una debía cuidar, y las volvimos a correr. Las veinticinco pasaron en verde. Buscaban una palabra dentro del archivo, y la palabra seguía estando, aunque fuera en un comentario o en otra parte. Estaban comprobando que el texto existía, no que la cosa funcionara.

Piénsalo así. Instalas una alarma y nunca suena. Puede ser que nadie haya entrado, o que esté desconectada. La única forma de saberlo es abrir una puerta a propósito y ver si suena. Si no lo haces nunca, esos dos mundos son idénticos para ti.

Desde entonces cada control nuestro tiene que demostrar que muerde: se rompe la cosa que vigila, se verifica que grita, y se deja como estaba. Si no grita, el control no existe, por muy verde que se vea.

¿Qué puedes revisar esta semana?

No necesitas ser técnico para hacer esta pregunta, y es la única que hace falta:

Somos una agencia de automatizaciones. Que estos tres casos hayan sido nuestros no es un descargo: es justamente el punto. Si le pasa al que construye estas cosas todos los días, le pasa a cualquiera que las tenga corriendo. La diferencia no está en no equivocarse nunca, está en revisar el destino en vez del reporte.

Si el tema te interesa por el lado de la web, el otro artículo que publicamos va de un problema de la misma familia: cómo saber si ChatGPT puede leer tu sitio. También ahí todo se ve perfecto y nadie te avisa.

Innobate diseña, conecta y opera infraestructura de IA para empresas en Chile. Si algo de esto te sirvió y quieres verlo aplicado a tu operación, conversemos — la primera conversación es un diagnóstico, no una presentación de ventas.

INNOBATE SpA · Puente Alto, Región Metropolitana, Santiago · [email protected] · Política de privacidad