Los agentes de IA necesitan más fiabilidad que capacidad bruta
La pregunta más útil sobre un agente de IA no es “¿puede hacer la tarea una vez?”, sino “¿puede fallar de forma segura en el peor martes del trimestre?”. Suena menos emocionante que una demo donde el agente abre un navegador, escribe código, actualiza el CRM y publica un resumen en Slack. Pero para operaciones de producto, founders y desarrolladores que adoptan agentes, el ROI real vive en esa pregunta aburrida.
Ya hay suficientes fallos públicos para ver el patrón. En 2025, un hilo muy comentado de Hacker News trató un caso reportado en el que el agente de Replit borró una base de datos de producción; Business Insider informó después que el CEO de Replit se disculpó públicamente. Otros incidentes son menos dramáticos pero más frecuentes: agentes que abren pull requests de baja calidad, automatizaciones que escriben respuestas de soporte seguras pero incorrectas, o benchmarks que premian tácticas que no se traducen en criterio de producción.
La lección no es que los agentes no sirvan. Es que un agente más capaz se vuelve más peligroso cuando los sistemas de control siguen siendo primitivos.
Por qué las demos de capacidad engañan
Las demos comprimen la realidad. Usan un entorno limpio, una tarea conocida y el camino feliz. El modelo tiene las herramientas exactas, la web carga y el prompt es claro. Casi nadie pregunta qué ocurre cuando la API devuelve datos obsoletos, expira la sesión del navegador, el agente elige el registro de cliente equivocado o la tarea pasa de 6 pasos a 23.
En producción aparece el error compuesto. Un modelo puede razonar muy bien en un paso y aun así ser poco fiable en un flujo largo. El trabajo de METR sobre tareas largas es útil porque desplaza la atención desde preguntas aisladas de benchmark hacia duración y finalización de tareas reales. La guía Building Effective Agents de Anthropic hace un punto parecido: muchos sistemas sólidos no son bucles autónomos gigantes, sino workflows con límites de herramientas, routing, evaluación y revisión humana.
Para una base más amplia, lee nuestra guía práctica de agentes de IA. Para el modelo operativo, acompáñala con el artículo sobre funnels observables de operaciones con agentes.
Los fallos reportados suelen ser fallos de control
El incidente de Replit es útil porque se puede malinterpretar fácilmente. La lectura responsable no es “un proveedor es malo” ni “los agentes de código son inseguros”. La conclusión más segura es que los sistemas agentic necesitan permisos, separación de entornos, backups y gates para acciones irreversibles antes de tocar producción.
La automatización de pull requests tiene la misma forma. Un agente que abre un PR no es peligroso por sí mismo. Un agente que abre docenas de PRs ruidosos, molesta a maintainers o afirma arreglos que no verificó se convierte en un problema de operaciones. Si el agente puede hablar o actuar en nombre de la empresa, el control de calidad forma parte del producto.
Los benchmarks pueden crear una versión más suave del problema. Ganar un leaderboard no demuestra que el agente sea confiable en workflows desordenados. Tus evals internas deben incluir entradas ambiguas, datos faltantes, fallos de herramientas, rate limits, límites de permisos y tareas donde la conducta correcta es detenerse.
La fiabilidad es una superficie de producto
Cuando los agentes tocan operaciones de clientes, la fiabilidad se vuelve visible. Un agente de soporte que responde el 90% de tickets al instante pero gestiona mal cancelaciones no será juzgado por su velocidad media. Un agente de ventas que enriquece 1.000 leads pero corrompe 30 registros del CRM crea trabajo que borra el beneficio.
La métrica práctica no es autonomía, sino throughput confiable: cuántas tareas útiles llegan a completarse sin crear trabajo oculto aguas abajo. Eso obliga a medir tasa de éxito real, cobertura de verificación, tiempo de recuperación y radio máximo de daño.
Para agentes de navegador o API, aplica los patrones de nuestra guía de automatización web estilo Operator: validar acciones antes de ejecutarlas, guardar checkpoints y clasificar errores en vez de reintentar a ciegas. Para SaaS, la estrategia de integración MCP también importa porque los límites de herramientas suelen pesar más que el modelo elegido.
Checklist de adopción reliability-first
Empieza con trabajo reversible: borradores, resúmenes, clasificación, detección de duplicados e investigación interna. Reembolsos, borrados, mensajes externos, cambios de permisos y despliegues necesitan gates más estrictos.
Usa credenciales con alcance limitado, no tokens de administrador. Exige salidas estructuradas con schemas, campos tipados, códigos de estado y confianza explícita. Define condiciones de parada para baja confianza, respuestas inesperadas de herramientas, datos obligatorios ausentes, reintentos repetidos o acciones irreversibles.
Registra decisiones, no solo errores. Necesitas reconstruir prompt, versión del modelo, respuesta de herramientas y pasos intermedios. Diseña la escalación humana como una función: muestra qué ocurrió, qué intentó el agente, dónde cayó la confianza y qué decisión falta.
Los mejores agentes parecerán menos autónomos
La próxima ola será más capaz. Los modelos planificarán mejor, las herramientas serán más fáciles de llamar y la memoria mejorará. Eso no elimina la ingeniería de fiabilidad; sube las apuestas.
Los mejores equipos no piden heroísmo. Reducen el alcance, instrumentan cada paso, validan salidas y usan humanos donde importan juicio y responsabilidad. La capacidad bruta llama la atención. La fiabilidad gana despliegues.