Cada vez que automatizo algo con IA, la pregunta que más me hacen no es "¿cómo lo montaste?". Es "¿y si se equivoca, cómo te enteras?". Es la pregunta correcta, y la mayoría de las automatizaciones que veo fallar no fallan porque el modelo se equivoque, fallan porque nadie se entera hasta que el daño ya está hecho.

Automatizar y perder el control no tienen por qué ir juntos. Pero van juntos por defecto si no diseñas explícitamente para lo contrario.

El error de fondo: confundir "sin supervisión" con "sin control"

Sin supervisión significa que no estoy mirando cada paso en tiempo real. Sin control significa que no hay ningún mecanismo que me avise si algo sale mal. Son cosas completamente distintas, y la automatización buena solo elimina la primera, nunca la segunda.

Una tarea puede correr sola, de noche, sin que yo la vea ejecutarse, y aun así estar bajo control si tiene puntos de verificación que capturan el error antes de que se propague. Eso es lo que separa "automaticé esto" de "lo dejé suelto y recé".

Tres puntos de control que meto en cualquier automatización

  • Un criterio de éxito verificable, no asumido. Antes de automatizar nada, defino cómo sé que el resultado es correcto sin tener que revisarlo yo a mano. Si no puedo definir ese criterio, no automatizo esa tarea todavía: la ejecuto manualmente unas cuantas veces más hasta que el criterio de éxito se vuelva obvio.
  • Un límite de alcance explícito. La automatización solo puede tocar lo que decidí de antemano que puede tocar. No "lo que decida que necesita", lo que yo acoté con anterioridad. Esto es lo mismo que aplico a la autonomía de un agente de código: el radio de daño está limitado por diseño, no por el buen juicio del sistema en el momento.
  • Una alerta que dispara con la anomalía, no con el fallo total. Esperar a que la tarea "falle" del todo para enterarte es tarde. Lo que funciona mejor es una señal que se dispara cuando el resultado se sale de un rango esperado, aunque técnicamente la tarea se haya "completado". Un informe generado con la mitad de las filas que un día normal es una anomalía, no un fallo, y merece la misma atención.

Dónde automatizo sin miedo

Tareas repetitivas con un formato de entrada y salida estable, donde ya he visto decenas de casos y sé qué pinta tiene un resultado correcto. Ahí el criterio de éxito es fácil de verificar de forma automática, y el coste de un error ocasional es bajo y reversible.

Dónde no automatizo del todo, aunque técnicamente pueda

Cualquier tarea donde el criterio de "correcto" dependa de contexto que cambia con frecuencia, o donde un error no se note hasta mucho después. Ahí prefiero un sistema semi-automático: hace el trabajo pesado, pero deja un paso de confirmación humana antes de la acción que no se puede deshacer. No es desconfianza del modelo, es reconocer que el coste de un error silencioso ahí es mucho más alto que el tiempo que ahorro quitando ese último paso.

La recomendación

No automatices una tarea hasta que puedas responder con precisión a dos preguntas: cómo sabrás que salió mal, y qué pasa si nadie se entera durante una semana. Si la segunda respuesta te preocupa, todavía no has diseñado suficiente control, solo has quitado supervisión. Son cosas distintas, y solo una de las dos es progreso real.

Relacionado: Qué agentes de código merece la pena dejar sueltos y cuáles no