Por qué los agentes de IA funcionan en una demo y fallan en producción

Una demo prueba que un camino puede funcionar. Un servicio en producción también debe manejar datos incompletos, dependencias lentas, permisos cambiantes, reintentos y usuarios que cierran el navegador a mitad de una tarea.

La diferencia suele estar en el software y la operación que rodean al modelo. Mejorar las instrucciones no convierte una integración poco confiable en una operación transaccional ni renueva una credencial vencida.

La demo oculta supuestos

Imaginá un agente que actualiza un cliente en el CRM después de revisar una conversación de soporte. En la demo tiene un cliente conocido, una transcripción clara, credenciales vigentes y un desarrollador mirando cada paso.

En producción, dos clientes pueden compartir nombre. La transcripción puede contener un identificador equivocado. El CRM puede aceptar el cambio y no devolver una respuesta. Otra persona puede modificar el registro mientras el agente razona.

Antes del lanzamiento, convertí cada supuesto en una condición verificable o en una falla que el sistema pueda manejar.

Cinco fallas que conviene probar

Falla	Consecuencia	Respuesta de implementación
Identidad ambigua	Se modifica otro registro	Exigir un identificador verificado o pedir aclaración
Resultado incierto de una herramienta	Se repite una acción ya completada	Identificar operaciones y consultar su estado
Pérdida del estado de ejecución	La tarea vuelve a empezar	Persistir avances y definir cómo reanudar
Permisos excesivos	Se accede a otra cuenta	Aplicar el alcance en la herramienta o servicio
Investigación interminable	Se consume presupuesto sin terminar	Limitar la ejecución y devolver un estado incompleto

Estas respuestas requieren comportamiento de la aplicación, no solo instrucciones para que el agente tenga cuidado.

Qué hacer cuando una actualización no responde

Si update_customer supera el tiempo de espera, la solicitud puede no haber llegado, haber fallado o haberse completado sin que la respuesta llegara de vuelta.

Reintentar ciegamente trata los tres casos como si fueran iguales. Asociá la tarea a un identificador persistente de operación. Si el sistema admite idempotencia, reutilizalo. Si no, diseñá una verificación o conciliación y no afirmes que la acción terminó hasta confirmar su estado.

También considerá cambios simultáneos. Una actualización basada en un registro viejo puede sobrescribir información más reciente. Según el sistema, harán falta controles de versión o escrituras condicionales. El agente debe recibir un conflicto comprensible y saber qué puede hacer después.

Evaluá el trabajo completado

Una respuesta que dice «actualizado correctamente» no basta. Verificá el estado real de la aplicación y que haya cambiado el registro correcto. En tareas de lectura, comprobá si la respuesta está respaldada por la evidencia recuperada.

Creá un conjunto de pruebas con datos que tengas permiso para usar. Incluí solicitudes normales, registros ausentes, instrucciones contradictorias, acceso revocado, una caída de servicio, una solicitud repetida y una tarea que deba rechazarse.

Repetí algunos casos porque el comportamiento puede variar. Medí por separado éxito, efectos incorrectos, escalamiento, duración y costo. Un promedio alto no compensa una violación de permisos.

La guía de evaluación de agentes de Anthropic distingue entre evaluar la ejecución y sus resultados. El registro explica el recorrido; el estado final muestra qué ocurrió.

Usá el piloto para ensayar la operación

Cada tarea fallida necesita un responsable. Alguien debe revisar excepciones, decidir qué resultado es aceptable y aprobar cambios. Sin esas responsabilidades, el proyecto puede quedar detenido aunque el modelo funcione.

Empezá con pocas herramientas y usuarios. Cuando sea útil, operá primero en modo de recomendación. Registrá versiones del modelo y de las herramientas para investigar regresiones. Conservá solo las trazas necesarias con controles adecuados de acceso y retención.

Servicios administrados como Amazon Bedrock AgentCore pueden aportar infraestructura, pero tu equipo sigue definiendo la tarea, los permisos y la aceptación.

Definí criterios propios de lanzamiento

No copies un objetivo arbitrario de «95% de precisión». Definí qué constituye un error, cuánto cuesta y qué fallas son inaceptables. Un borrador de resumen y una modificación de una cuenta requieren decisiones distintas.

Antes de ampliar el acceso, demostrá recuperación ante las fallas probadas, trazabilidad de acciones, límites de ejecución y derivación de tareas no resueltas. Incluí el costo de revisión en el presupuesto.

Revisá si un flujo fijo alcanza para el proceso y usá nuestro modelo de costos. Timewise Labs puede ayudarte a llevar el caso de uso a producción.

Adaptado del artículo de Dream Hatch Labs.