Una automatización puede funcionar y seguir rota

Una de las frases más tranquilizadoras en tecnología es «la tarea ha terminado correctamente». También puede ser una de las más engañosas.

Que un proceso acabe sin lanzar una excepción no demuestra que haya conseguido aquello para lo que lo creamos. Demuestra, en el mejor de los casos, que se ha ejecutado hasta alcanzar el punto que consideramos final.

Si ese punto estaba mal definido, podemos tener una automatización impecable desde el punto de vista técnico y completamente inútil desde el punto de vista operativo.

Es una diferencia que se vuelve especialmente visible cuando dejamos de ejecutar algo a mano y lo convertimos en una tarea recurrente.

El éxito de la ejecución no es el éxito del negocio

Pensemos en un proceso que prepara contenidos para una web. Puede generar archivos, construir una versión estática y almacenarla sin errores. Nada de eso demuestra que el contenido esté publicado.

En un sistema de publicación con versiones controladas hay, al menos, tres estados distintos: versión preparada, versión aprobada y versión activa. Cada uno exige evidencias diferentes.

Almacenar una versión no equivale a aprobarla, y aprobarla no significa que ya sea la que está sirviendo la web. Incluso si verificamos una activación concreta, esa comprobación no certifica por sí sola todas las ejecuciones posteriores.

La lección vale incluso cuando el código no tiene ningún defecto: observar un caso correcto no equivale a haber comprobado una serie entera.

Lo que una tarea sabe de sí misma

Una automatización suele conocer bien sus acciones internas: hizo una consulta, generó un fichero, ejecutó un comando, devolvió un estado.

Lo que no siempre sabe es si alguien puede utilizar el resultado.

Una exportación puede haberse generado, pero contener registros incompletos. Un informe puede existir, pero estar desactualizado. Una notificación puede haberse enviado, pero no incluir la única incidencia que requería intervención. Un proceso puede marcar como resuelto algo que quedó simplemente pendiente.

La forma de evitarlo no es añadir más logs sin límite. Es definir mejor qué significa «terminado».

Para una tarea recurrente suelo necesitar tres respuestas: qué debía cambiar, qué evidencia demuestra que cambió y qué queda pendiente si no ocurrió.

Si no puedo responderlas, probablemente aún no tengo una automatización verificable.

Los estados importan más que la narrativa

En sistemas complejos aparecen palabras que parecen equivalentes hasta que ocurre un problema: solicitado, aprobado, preparado, ejecutado, verificado, publicado.

No lo son.

Una petición aprobada no se convierte automáticamente en una acción realizada. Una acción realizada no significa que su resultado se haya observado. Y un resultado observado una vez no asegura que permanezca válido indefinidamente.

Conviene guardar esos estados de forma explícita y utilizar nombres que no prometan más de lo que sabemos.

Esta disciplina también es útil al trabajar con agentes de IA. Un agente puede redactar una respuesta convincente sobre lo que iba a hacer. Pero si no existe confirmación de la herramienta o una comprobación posterior, el relato no sustituye a la evidencia.

Diseñar el informe para detectar excepciones

Un error frecuente consiste en pensar que una tarea recurrente debe narrar todos sus pasos para demostrar que ha trabajado.

En realidad, cuanto más a menudo recibo un informe, menos tiempo quiero dedicar a leer que todo está bien. Lo que necesito encontrar en pocos segundos es si debo hacer algo.

Un formato útil podría responder, al principio, a una sola pregunta: «¿Requiere mi atención?».

Después vendrían las evidencias: qué se comprobó, qué no pudo comprobarse y qué criterio se utilizó. Si hay incidencias, deberían aparecer con la acción concreta que falta, no escondidas entre veinte párrafos de actividad normal.

El detalle técnico sigue teniendo su lugar. No debe ocupar el espacio que necesita una decisión humana.

Cuando un fallo no lanza excepciones

Los casos más incómodos no son los procesos que se detienen claramente. Son los que terminan en verde y dejan un resultado incompleto.

Ahí ayudan controles independientes: verificar que el artefacto existe, comprobar que contiene lo esperado, contrastar un estado de salida, medir la frescura de los datos o registrar el identificador exacto de una operación.

También importa la idempotencia. Si una tarea se reintenta, no debería crear dos veces lo que solo debía ocurrir una. Y si no puede determinar si ya lo hizo, conviene detenerse antes de duplicar efectos.

La comprobación posterior no es un adorno del proceso. Forma parte de su definición de éxito.

Automatizar también exige una política de silencio

Una buena tarea puede realizar muchas operaciones internas y entregar un resumen mínimo: «Sin incidencias. No requiere intervención».

Otra puede haber realizado casi todo el trabajo y necesitar una respuesta más larga porque ha encontrado una discrepancia relevante.

Ambas son salidas correctas si reflejan honestamente el estado.

El objetivo no es que el sistema parezca ocupado ni que produzca informes extensos. Es reducir la probabilidad de que algo importante pase desapercibido.

Por eso, antes de llamar completa a una automatización, intentaría comprobar cuatro cosas: que ejecuta lo previsto, que verifica el resultado, que distingue estados y que comunica de forma visible cuándo hace falta intervención.

Una tarea puede funcionar perfectamente y seguir rota. A menudo la reparación no consiste en cambiar el algoritmo, sino en definir con más precisión qué consideramos un trabajo terminado.