Esta es una historia corta sobre un clic que no se dio.
Contexto: operamos parte de nuestra plataforma web con un equipo de agentes de IA bajo dirección humana. Una tarde, después de probar de punta a punta el formulario de contacto del sitio (envío, notificación por correo, registro en el CRM), vino la instrucción de rutina: reinicia los folios y limpia los datos de la prueba, para empezar desde cero.
Una instrucción perfectamente razonable. Los registros de prueba eran basura conocida: los acabábamos de generar nosotros.
El candado
El agente encargado no ejecutó. Se detuvo y preguntó: encontró dos registros recientes, no uno, y quería confirmar exactamente cuáles borrar antes de tocar la base de datos.
La pregunta se veía innecesaria. Era el equivalente digital de "¿estás seguro?", ese diálogo que todos hemos aprendido a descartar sin leer. Y de hecho así se descartó: la confirmación quedó sin responder mientras la operación seguía en otra cosa.
Minutos después cayó el veinte. Uno de los dos registros "de prueba" no era de prueba. Era el primer lead real de la plataforma: una persona de verdad, con un requerimiento de verdad, que había llenado el formulario minutos después de nuestras pruebas. Llegó tan pegado a la basura conocida que se camuflajeó con ella.
Se borró únicamente el registro de prueba, verificado uno por uno. El lead sobrevivió, se atendió, y hoy encabeza el CRM con el folio 000001 — un lugar que estuvo a un clic de ocupar la nada.
Por qué las limpiezas "obvias" no lo son
El incidente es pequeño, pero la anatomía es la de los desastres grandes. Tres cosas se alinearon, y las tres son universales.
Primera: la instrucción era correcta cuando se formuló, y el mundo cambió antes de ejecutarse. Entre "limpia los datos de prueba" y el momento de borrar, llegó un dato real. Toda operación destructiva basada en una foto vieja del sistema carga ese riesgo, y las bases de datos en producción cambian mientras hablamos de ellas.
Segunda: lo real se parecía a la basura. El lead auténtico tenía la misma forma, la misma fecha y casi la misma hora que los registros de prueba. Ningún filtro por "lo reciente" lo habría salvado; solo distinguirlos uno por uno.
Tercera: el humano descartó la confirmación. Vale la pena decirlo sin adornos, porque es el hallazgo más incómodo: el eslabón que falló primero no fue la máquina. Los diálogos de confirmación nos han entrenado durante décadas a cerrarlos por reflejo. La diferencia fue que este candado no se conformó con preguntar: se negó a ejecutar hasta obtener respuesta explícita. Un "¿seguro?" que se puede ignorar no es un control; es un trámite.
Lo que cambió en nuestra operación
Del incidente salieron tres reglas que hoy aplican para cualquier operación destructiva, la ejecute un humano o un agente. Enumerar antes de borrar: toda limpieza empieza listando exactamente qué se va a eliminar, registro por registro, y esa lista es la que se autoriza — no la descripción general. Confirmación bloqueante para lo irreversible: si la operación no tiene vuelta atrás, el silencio no es un sí. Y desconfiar de la palabra "obvio": si la justificación de un borrado es que es obviamente basura, esa es precisamente la señal para verificar.
Nada de esto es nuevo para quien opera infraestructura — son los mismos reflejos de un cambio en producción. La novedad es confirmarlos en la era de los agentes: la seguridad no vino de que la IA fuera lista, sino de que tenía prohibido ser rápida con lo irreversible.
Conclusión práctica
Si estás integrando agentes de IA a tu operación, el diseño importante no es qué pueden hacer, sino qué no pueden hacer sin ti. Nuestros candados no evitaron un error de la máquina; evitaron uno nuestro. Esa es, quizá, la lección completa: los buenos controles no asumen que la IA se va a equivocar y el humano la va a corregir. Asumen que cualquiera de los dos puede ser el que se equivoca ese día.