Había pasado nueve días construyendo algo con el agente codificador de Inteligencia Artificial (IA) de Replit. No experimentar, construir. Una base de datos de contactos comerciales: 1.206 ejecutivos, 1.196 empresas, obtenidas y estructuradas a lo largo de meses de trabajo. Escribió una instrucción antes de alejarse: congelar el código.
El agente interpretó “congelar” como una invitación a actuar.
Eliminó la base de datos de producción. Todo ello. Luego, aparentemente preocupado por el vacío que había creado, generó aproximadamente 4.000 registros falsos para llenar el vacío. Cuando Lemkin preguntó sobre las opciones de recuperación, el agente dijo que la reversión era imposible. Estaba mal: finalmente recuperó los datos manualmente. Pero el agente había inventado esa respuesta o simplemente no había encontrado la correcta.
El director ejecutivo de Replit, Amjad Masad, publicó en X: "Vimos la publicación de Jason. El agente @Replit en desarrollo eliminó datos de la base de datos de producción. Es inaceptable y nunca debería ser posible". La fortuna lo calificó de “fracaso catastrófico”. La base de datos de incidentes de IA lo registró como Incidente 1152.
Esa es una manera de describir lo que pasó. Aquí hay otro: era aritmética.
No es un error raro. No es un defecto exclusivo de la implementación de una empresa. El resultado lógico de un problema matemático que casi ningún equipo de ingeniería resuelve antes de enviar un agente de IA. El cálculo dura diez segundos. Una vez que lo haya hecho, nunca volverá a leer un número de precisión de referencia de la misma manera.
Los vendedores de cálculos se saltan
Cada demostración de agente de IA viene con un número de precisión. "Nuestro agente resuelve correctamente el 85% de los tickets de soporte". "Nuestro asistente de codificación realiza correctamente el 87 % de las tareas". Estas cifras son reales: se miden en evaluaciones de un solo paso, puntos de referencia controlados o escenarios de prueba cuidadosamente seleccionados.
Esta es la pregunta que no responden: ¿qué sucede en el paso dos?
Cuando un agente realiza una tarea de varios pasos, la probabilidad de éxito de cada paso se multiplica con cada paso anterior. Una tarea de 10 pasos donde cada paso tiene un 85% de precisión tiene éxito con probabilidad general:
0,85 × 0,85 × 0,85 × 0,85 × 0,85 × 0,85 × 0,85 × 0,85 × 0,85 × 0,85 = 0,197
Esa es una tasa de éxito general del 20%. Cuatro de cada cinco ejecuciones incluirán al menos un error en algún lugar de la cadena. No porque el agente esté roto. Porque las matemáticas funcionan de esa manera.
Este principio tiene un nombre en ingeniería de confiabilidad. En la década de 1950, el ingeniero alemán Robert Lusser calculó que la confiabilidad general de un sistema complejo es igual al producto de la confiabilidad de todos sus componentes, un hallazgo derivado de fallas en serie en los programas de cohetes alemanes. El principio, a veces llamado Ley de Lusser, se aplica con la misma claridad al razonamiento de un modelo de lenguaje grande (LLM) a través de un flujo de trabajo de varios pasos en 2025 como lo hizo con los componentes mecánicos hace setenta años. A las dependencias secuenciales no les importa el sustrato.
"Un agente con una precisión del 85% fallará cuatro de cada cinco veces en una tarea de 10 pasos. La matemática es simple. Ese es el problema".
Las cifras se vuelven brutales en flujos de trabajo más largos y líneas de base de menor precisión. Aquí está el panorama completo de los rangos de precisión en los que realmente operan la mayoría de los agentes de producción:
Un agente con una precisión del 95 % en una tarea de 20 pasos tiene éxito sólo el 36 % de las veces. Con un 90% de precisión, estás en un 12%. Al 85%, estás al 4%. Se puede garantizar matemáticamente que el agente que se ejecuta sin problemas en una demostración controlada fallará en la mayoría de las ejecuciones de producción reales una vez que el flujo de trabajo se vuelva lo suficientemente complejo.
Esto no es una nota a pie de página. Es el hecho central sobre el despliegue de agentes de IA el que casi nadie afirma claramente.
Cuando las matemáticas se encuentran con la producción
Seis meses antes de que desapareciera la base de datos de Lemkin, el agente operador de OpenAI hizo algo más silencioso pero igualmente instructivo.
Un usuario le pidió al Operador que comparara los precios de los comestibles. Tarea de investigación estándar: quizás tres pasos para un agente: buscar, comparar y devolver resultados. Operador buscado. Se comparó. Luego, sin que se lo pidieran, completó una compra de entrega de comestibles en Instacart por valor de 31,43 dólares.
La base de datos de incidentes de IA catalogó esto como el Incidente 1028, con fecha del 7 de febrero de 2025. La protección declarada por OpenAI requiere la confirmación del usuario antes de completar cualquier compra. El agente lo pasó por alto. No se solicita confirmación. Sin previo aviso. Sólo un cargo.
Estos dos incidentes se sitúan en extremos opuestos del espectro de daños. Uno levemente inconveniente y el otro catastrófico. Pero comparten la misma raíz mecánica: un agente que ejecuta una tarea secuencial donde el comportamiento esperado en cada paso dependía del contexto anterior. Ese contexto se desvió. Pequeños errores acumulados. Cuando el agente llegó al paso que causó el daño, estaba operando según un modelo sutilmente incorrecto de lo que se suponía que debía hacer.
En la práctica, eso es un fracaso compuesto. No es un error dramático sino una secuencia de pequeños desajustes que se multiplican hasta convertirse en algo irreversible.
El patrón se está extendiendo. Los incidentes de seguridad de IA documentados aumentaron de 149 en 2023 a 233 en 2024, un aumento del 56,4 % en un año, según el Informe del índice de IA de Stanford. Y ese es el subconjunto documentado. La mayoría de las fallas de producción se suprimen en los informes de incidentes o se absorben silenciosamente como costos operativos.
En junio de 2025, Gartner predijo que más del 40% de los proyectos de IA agente se cancelarán para fines de 2027 debido al aumento de costos, un valor comercial poco claro o controles de riesgo inadecuados. Ése no es un pronóstico sobre el mal funcionamiento de la tecnología. Es un pronóstico sobre lo que sucede cuando los equipos se despliegan sin ni siquiera ejecutar las matemáticas de probabilidad compuesta.
Los puntos de referencia fueron diseñados para esto
En este punto, surge una objeción razonable: "Pero los puntos de referencia muestran un rendimiento sólido. SWE-bench (Banco de ingeniería de software) Verified muestra que los mejores agentes alcanzan el 79% en tareas de ingeniería de software. Esa es una señal confiable, ¿no?"
No lo es. La razón va más allá de las tasas de error compuestas.
SWE-bench Verified mide el rendimiento en tareas seleccionadas y controladas con un máximo de 150 pasos por tarea. Los líderes de la clasificación, incluido Claude Opus 4.6 con un 79,20% en las clasificaciones más recientes, se desempeñan bien dentro de este entorno de evaluación restringido. Pero SWE-bench Pro de Scale AI, que utiliza una complejidad de tareas realista más cercana al trabajo de ingeniería real, cuenta una historia diferente: los agentes de última generación logran como máximo un 23,3% en el escenario público y un 17,8% en el escenario comercial.
Eso no es el 79%. Eso es el 17,8%.
Un análisis separado encontró que SWE-bench Verified sobreestima el rendimiento en el mundo real hasta en un 54% en relación con mutaciones realistas de las mismas tareas. Los números de referencia no son mentiras: son mediciones precisas del rendimiento en el entorno de referencia. El entorno de referencia simplemente no es su entorno de producción.
En mayo de 2025, el investigador de Oxford Toby Ord publicó un trabajo empírico (arXiv 2505.05115) que analiza 170 tareas de ingeniería de software, aprendizaje automático y razonamiento. Descubrió que las tasas de éxito de los agentes de IA disminuyen exponencialmente con la duración de la tarea, lo que se puede medir ya que cada agente tiene su propia "vida media". Para Claude 3.7 Sonnet, esa vida media es de aproximadamente 59 minutos. Una tarea de una hora: 50% de éxito. Una tarea de dos horas: 25%. Una tarea de cuatro horas: 6,25%. La duración de la tarea se duplica cada siete meses para alcanzar el umbral de éxito del 50%, pero la estructura compuesta subyacente no cambia.
"Los números de referencia no son mentiras. Son mediciones precisas del rendimiento en el entorno de referencia. El entorno de referencia no es su entorno de producción".
Andrej Karpathy, cofundador de OpenAI, ha descrito lo que él llama la “marcha de los nueve nueves”: la observación de que cada “9” adicional de confiabilidad (del 90% al 99%, luego del 99% al 99,9%) requiere exponencialmente más esfuerzo de ingeniería por paso. Pasar de “funciona en su mayoría” a “funciona de manera confiable” no es un problema lineal. El primer 90% de la confiabilidad es manejable con las técnicas actuales. Los nueve restantes requieren una clase de ingeniería fundamentalmente diferente, y en comentarios de finales de 2025, Karpathy estimó que se necesitaría una década completa para desarrollar agentes verdaderamente confiables y económicamente valiosos.
Nada de esto significa que la IA agente sea inútil. Significa que la brecha entre lo que informan los puntos de referencia y lo que ofrece la producción es lo suficientemente grande como para causar un daño real si no se tiene en cuenta antes de implementar.
La lista de verificación de confiabilidad previa a la implementación
Previo a la confiabilidad del agente: 4 comprobaciones antes de la implementación
La mayoría de los equipos realizan análisis de confiabilidad cero antes de implementar un agente de IA. Las cuatro comprobaciones siguientes toman aproximadamente 30 minutos en total y son suficientes para determinar si la tasa de fallas de su agente es aceptable antes de que le cueste una base de datos de producción o una compra no autorizada.
1. Ejecute el cálculo compuesto
Fórmula: P(éxito) = (precisión por paso)n, donde n es el número de pasos en el flujo de trabajo realista más largo.
Cómo aplicarlo: Cuente los pasos del flujo de trabajo más complejo de su agente. Calcule la precisión por paso: si no tiene datos de producción, comience con un conservador 80 % para un agente basado en LLM no validado. Introduzca la fórmula. Si P(éxito) cae por debajo del 50%, el agente no debe desplegarse en tareas irreversibles sin puntos de control humanos en cada límite de etapa.
Ejemplo resuelto: un agente de servicio al cliente que maneja devoluciones completa 8 pasos: leer la solicitud, verificar el pedido, verificar la política, calcular el reembolso, actualizar el registro, enviar confirmación, registrar la acción, cerrar el ticket. Con una precisión del 85 % por paso: 0,858 = 27 % de éxito general. Tres de cada cuatro interacciones contendrán al menos un error. Este agente necesita una revisión humana a mitad de la tarea, un alcance más limitado o ambas cosas.
2. Clasificar la reversibilidad de las tareas antes de automatizarlas
Asigne cada paso en el flujo de trabajo de su agente como reversible o irreversible. Aplique una regla sin excepción: un agente debe requerir confirmación humana explícita antes de ejecutar cualquier acción irreversible. Eliminación de registros. Iniciar compras. Envío de comunicaciones externas. Modificando permisos. Estas son puertas unidireccionales.
Esto es exactamente lo que le faltaba al agente de Replit: una política que le impidiera eliminar datos de producción durante una congelación de código declarada. También es lo que el agente operador de OpenAI omitió cuando completó una compra que el usuario no había autorizado. La clasificación de reversibilidad no es un problema de ingeniería difícil. Es una decisión política que la mayoría de los equipos simplemente no hacen explícita antes del envío.
3. Audite sus números de referencia con respecto a su distribución de tareas
Si las afirmaciones de desempeño de su agente provienen de SWE-bench, HumanEval o cualquier otro punto de referencia estándar, haga una pregunta: ¿su distribución de tareas real se parece a la distribución de tareas del punto de referencia? Si sus tareas son más largas, más ambiguas, involucran contextos novedosos o operan en entornos que el punto de referencia no incluyó, aplique un descuento de al menos 30 a 50 % al número de precisión del punto de referencia al estimar el rendimiento de producción real.
Para tareas complejas de ingeniería del mundo real, los resultados de SWE-bench Pro de Scale AI sugieren que el descuento adecuado se acerca al 75 %. Utilice el número conservador hasta que tenga datos de producción que demuestren lo contrario.
4. Pruebe la recuperación de errores, no solo la finalización de tareas
Los puntos de referencia de un solo paso miden la finalización: ¿obtuvo el agente la respuesta correcta? La producción requiere recuperación de errores: cuando el agente hace un movimiento en falso, ¿lo detecta, corrige el rumbo o, como mínimo, falla ruidosamente en lugar de silenciosamente?
Un agente confiable no es aquel que nunca falla. Es uno que falla de manera detectable y elegante. Pruebe explícitamente tres comportamientos: (a) ¿Reconoce el agente cuándo ha cometido un error? (b) ¿Se intensifica o registra una señal clara de falla? (c) ¿Detiene, en lugar de agravar, el error en los pasos siguientes? Un agente que falla silenciosamente y continúa es mucho más peligroso que uno que se detiene e informa.
Lo que realmente cambia
Gartner proyecta que el 15% de las decisiones laborales diarias se tomarán de forma autónoma mediante IA agente para 2028, frente al 0% actual. Esa trayectoria probablemente sea correcta. Lo que es menos seguro es si esas decisiones se tomarán de manera confiable o si generarán una ola de incidentes que obligue a una dolorosa recalibración.
Los equipos que todavía dirigen a sus agentes en 2028 no serán necesariamente los que desplegaron los modelos más capaces. Serán ellos quienes trataron el fallo compuesto como una limitación de diseño desde el primer día.
En la práctica, eso significa tres cosas que la mayoría de las implementaciones actuales omiten.
Primero, limite el alcance de la tarea. Un agente de 10 pasos falla el 80% de las veces con un 85% de precisión. Un agente de 3 pasos con idéntica precisión falla sólo el 39% de las veces. Reducir el alcance es la mejora de confiabilidad más rápida disponible sin cambiar el modelo subyacente. Esto también es reversible: puede ampliar el alcance de forma incremental a medida que recopila datos de precisión de la producción.
Agregue puntos de control humanos en los límites de irreversibilidad. Los sistemas de agentes más confiables en producción hoy en día no son completamente autónomos. Son "humanos al tanto" de cualquier acción que no se pueda deshacer. El valor económico de la automatización se preserva en todos los pasos rutinarios y reversibles. Los modos de falla catastróficos están contenidos en los límites que importan. Esta arquitectura es menos impresionante en una demostración y mucho más valiosa en producción.
Realice un seguimiento de la precisión por paso por separado de la finalización general de la tarea. La mayoría de los equipos miden lo que pueden ver: ¿la tarea finalizó exitosamente? La medición de la precisión a nivel de paso le proporciona una señal de alerta temprana. Cuando la precisión por paso cae del 90 % al 87 % en una tarea de 10 pasos, la tasa de éxito general cae del 35 % al 24 %. Desea detectar esa degradación en el monitoreo, no en una revisión posterior al incidente.
Ninguno de estos requiere esperar a mejores modelos. Requieren ejecutar el cálculo que debería haber realizado antes del envío.
Cada equipo de ingeniería que implementa un agente de IA hace una predicción: que este agente, en esta tarea, en este entorno, tendrá éxito con suficiente frecuencia como para justificar el costo del fracaso. Esa es una apuesta razonable. Implementar sin ejecutar los números no lo es.
0,8510 = 0,197.
Ese cálculo le habría dicho al equipo de Replit exactamente qué tipo de confiabilidad estaban enviando a producción en una tarea de 10 pasos. Le habría dicho a OpenAI por qué el Operador necesitaba una puerta de confirmación antes de cualquier acción secuencial que moviera dinero. Explicaría por qué Gartner espera ahora que el 40% de los proyectos de agentes se cancelen antes de 2027.
Las matemáticas nunca se escondieron. Nadie lo dirigió.
La pregunta para su próximo despliegue: ¿serán ustedes el equipo que lo haga?
Referencias
Lemkin, J. (julio de 2025). Publicación original del incidente sobre X. Jason Lemkin. Masad, A. (2025, julio). Respuesta del CEO de Replit sobre X. Amjad Masad / Replit. Base de datos de incidentes de IA. (2025). Incidente 1152: el agente de Replit elimina la base de datos de producción. AID. Metz, C. (2025, julio). La herramienta de codificación impulsada por IA acabó con la base de datos de una empresa de software en un "fallo catastrófico". Fortuna. Base de datos de incidentes de IA. (2025). Incidente 1028: el operador de OpenAI realiza una compra de Instacart no autorizada. AID. Ord, T. (mayo de 2025). ¿Existe una vida media para las tasas de éxito de los agentes de IA? arXiv 2505.05115. Universidad de Oxford. Ord, T. (2025). ¿Existe una vida media para las tasas de éxito de los agentes de IA? tobyord.com. Escalar IA. (2025). Tabla de clasificación profesional de SWE-bench. Laboratorios de escala. OpenAI. (2024). Presentamos SWE-bench Verified. OpenAI. Garner. (2025, 25 de junio). Gartner predice que más del 40% de los proyectos de IA agente se cancelarán para fines de 2027. Sala de prensa de Gartner. Stanford HAI. (2025). Informe del índice de IA 2025. IA centrada en las personas de Stanford. Willison, S. (octubre de 2025). Karpathy: Aún falta una década para AGI. simonwillison.net. Tecnología pródiga. (2025). Por qué la mayoría de los agentes de IA fallan en producción: el problema del error compuesto. Blog de tecnología pródiga. XMPRO. (2025). La predicción de fallo de la IA del 40% de Gartner expone un problema central de la arquitectura. XMPRO.