Cómo evitar que un agente de IA duplique pedidos o correos

Ilustración generada con IA para este artículo.

Imagina una distribuidora chilena que usa un agente de IA para preparar pedidos. El agente envía una orden al sistema de ventas, pero la conexión se corta antes de recibir la confirmación. Decide intentarlo otra vez. Ahora bodega podría recibir dos órdenes para el mismo encargo.

Es un ejemplo hipotético, no un caso de Pufers. Sirve para mostrar una diferencia importante: redactar una respuesta equivocada y ejecutar dos veces una operación tienen consecuencias distintas. Cuando la IA puede enviar correos o crear pedidos, el control debe estar también en el software que realiza esas acciones.

Un silencio no confirma un fracaso

Una solicitud puede haberse ejecutado aunque quien la envió no reciba respuesta. Por eso, un tiempo de espera agotado no demuestra que el pedido no exista. Antes de repetirlo, conviene consultar su estado usando una referencia estable.

AWS explica este problema al diseñar APIs con reintentos seguros. Su enfoque permite identificar la intención original mediante un identificador enviado por el cliente. Repetir esa misma solicitud puede devolver el resultado ya registrado sin crear otro recurso.

Esa propiedad se llama idempotencia. Para una integración de negocio significa que un reintento de la misma operación no debería producir un segundo efecto. Requiere soporte del servicio y reglas claras sobre cuánto tiempo conserva el identificador; no aparece por pedirle al modelo que tenga cuidado.

Distingue un reintento de un pedido nuevo

Dos encargos pueden contener exactamente los mismos productos y seguir siendo pedidos legítimos distintos. Comparar solo el texto, el monto o el destinatario puede bloquear una compra válida. AWS recomienda un identificador explícito de solicitud y rechazar cambios de parámetros asociados al mismo identificador.

Como propuesta de implementación, define una referencia por operación aprobada y consérvala cuando se reintente. Si una persona pide una segunda compra, debe nacer una operación nueva. Esa decisión merece quedar documentada antes de conectar el agente al sistema comercial.

Por ejemplo, en un escenario hipotético de reposición semanal, una orden de diez cajas de este lunes y otra del lunes siguiente son dos encargos. En cambio, dos intentos de transmitir la primera orden pertenecen al mismo encargo. El sistema debe poder distinguirlos sin depender de la memoria de la conversación.

Cuando el proveedor no ofrece esa protección

No todas las herramientas de correo o gestión tienen el mismo contrato de reintentos. Pregunta a quien implementa la integración qué ocurre si el proveedor acepta una operación y la aplicación se interrumpe antes de registrarlo.

Nuestra recomendación es conservar un estado de resultado desconocido y buscar evidencia antes de volver a enviar. Para un correo, puede existir un identificador del proveedor o un registro de entrega; para un pedido, una referencia consultable en el sistema receptor. La evidencia disponible depende de cada integración.

Un registro local, por sí solo, no garantiza que el efecto externo ocurra una sola vez. Si no puedes resolver la incertidumbre de manera fiable, deriva ese caso a revisión. Reintentar automáticamente porque falta una confirmación puede convertir una duda en un duplicado.

Da al agente herramientas acotadas

OWASP identifica la autonomía, los permisos y las funciones excesivas como causas de acciones perjudiciales en sistemas con modelos de lenguaje. Recomienda limitar las capacidades disponibles, aplicar la autorización en los sistemas que ejecutan las operaciones y requerir intervención humana para acciones de alto impacto.

Una aplicación práctica sería permitir que el agente prepare el pedido, pero exigir que una regla del sistema valide cantidades, destinatario y autorización antes de enviarlo. Si solo necesita redactar un correo, no necesita permisos para borrar mensajes ni modificar contactos.

Escribe estas restricciones en la integración. Una frase como “nunca envíes dos veces” puede orientar al modelo, pero no sustituye una comprobación del estado del pedido.

Prueba también lo que sale mal

La guía de Anthropic sobre construcción de agentes recomienda obtener evidencia del entorno durante la ejecución y establecer condiciones de parada, como un máximo de iteraciones. Es una referencia de diseño publicada en 2024, no un anuncio reciente.

Para un piloto, proponemos ensayar estos escenarios con datos ficticios:

• La solicitud llega, pero se pierde la respuesta.
• Dos trabajadores intentan procesar el mismo encargo al mismo tiempo.
• El servicio tarda más de lo esperado y después confirma.
• La aplicación se reinicia con una operación pendiente.
• El proveedor rechaza la solicitud por un dato incorrecto.

En cada caso, revisa qué recibió realmente el sistema externo y qué quedó registrado. Define cuándo consultar, cuándo reintentar y cuándo detenerse. Un error de validación no se arregla repitiendo lo mismo.

Antes de ampliar el piloto, pide una demostración de esos fallos. El objetivo es poder explicar qué ocurrió con cada operación y resolver la incertidumbre sin multiplicar sus efectos.

Fuentes consultadas el 21 de octubre de 2026. Los ejemplos y la propuesta de piloto son ilustrativos; no representan resultados de clientes.