La semana pasada un agente de ventas redactó una factura de $0.00 para un plan empresarial de 14 asientos.

No estaba en blanco. No era un null. No era un error de sistema. Tenía los renglones correctos, el cliente correcto, las fechas correctas, y un total de cero dólares escrito con la misma seguridad con la que habría escrito cualquier otra cifra. Si el ejecutivo de cuenta hubiera ido con prisa y le hubiera dado a “aprobar”, esa cotización salía por la puerta.

La historia es real. La contó un equipo en el foro r/AI_Agents y la amplificó Fabio Marcello Salvadori en LinkedIn. Vale la pena contarla completa, porque el final no es el que esperas.

Y porque el modo de falla que de verdad frena la adopción de IA en las empresas no es la alucinación ruidosa, esa que escupe una respuesta absurda y se nota a un kilómetro. Es esta otra: una salida impecable, bien formateada, que pasa todas las revisiones menos una. La única que importa. ¿Este número es de verdad?

El bug no estaba en ningún paso que alguien escribió

El equipo hizo lo que haría cualquiera con experiencia. Primera hipótesis: la API de precios devolvió un cero. No fue así. Los logs mostraban que el número correcto había vuelto de la API. El agente simplemente decidió no usarlo.

Revisaron el prompt: sin cambios, el mismo que llevaba tres meses corriendo. Corrieron la misma entrada en el ambiente de pruebas y salió la factura correcta. No lograron reproducirlo. Lo archivaron como un hipo del modelo, una de esas rarezas de una sola vez, y siguieron. Hasta que volvió a pasar dos veces más ese mismo día.

Cuando por fin jalaron la traza completa de una ejecución fallida, ahí estaba: un paso que nadie había puesto a propósito. Después de llamar a la herramienta de precios, el agente había corrido su propia “validación” contra un objeto de contrato que el equipo había soltado en el contexto semanas antes, para una funcionalidad distinta y ya olvidada. Ese objeto tenía un campo de descuento que para esos clientes siempre venía vacío. El modelo leyó ese vacío como un descuento del 100%, y escribió $0.00 con total convicción.

Aquí está la parte que debería incomodar a cualquiera que esté metiendo agentes en producción: ninguno de los logs individuales habría atrapado esto. Un printf clásico te habría mostrado la herramienta de precios devolviendo el número correcto, y después la salida volviéndose cero de manera misteriosa. La única razón por la que encontraron el paso de validación es que apareció como su propio span en la traza, sentado entre la llamada a la herramienta y la síntesis final.

Llevo depurando sistemas desde 1990. Durante treinta y seis años, un bug vivía en una línea que yo podía señalar con el dedo: la escribí mal, la escribió mal otro, pero estaba ahí, en el código, esperando. El cambio real con los agentes no es que se equivoquen más. Es que el bug ahora vive en un paso que nadie escribió. El modelo lo improvisó en medio de tu flujo, y si no estás grabando cada movimiento, ese paso es invisible.

Por eso la observabilidad dejó de ser un lujo. Las trazas completas de ejecución, del tipo que dan herramientas como Langfuse, no son una mejora que agregas después del primer susto. Son la condición para soltar un agente cerca de algo que importa. No puedes depurar un paso que no sabías que el modelo iba a inventarse. Y no lo vas a ver en un log por paso, porque cada paso, por separado, se veía bien.

El equipo de Sentry lo resume en una frase que debería estar pegada en la pared de cualquiera que despliegue agentes: “los tableros muestran totales; las trazas muestran decisiones”. Un tablero te dice que la facturación corrió y devolvió 200. La traza te dice que, en el camino, el modelo tomó una decisión que nadie le pidió.

Un null que nadie le explicó al modelo

La causa raíz no fue el modelo. Fue el objeto viejo.

Alguien dejó un contrato en el contexto del agente para una funcionalidad que ya ni existía, y nadie lo sacó. Quedó ahí, como esos cables que nadie se atreve a desconectar del rack porque no sabe a dónde van. Un campo en null, sin una sola instrucción de cómo leerlo, frente a un modelo que por naturaleza llena huecos con la interpretación más fluida que encuentre. Vacío se volvió gratis. Gratis se volvió $0.00.

El contexto que le das a un agente no es una bolsa donde echas todo por si acaso. Es superficie de ataque. Cada objeto que dejas ahí es una suposición que el modelo puede tomar en el peor momento, en la dirección que menos esperas. La higiene de contexto, decidir qué entra, qué sale y cuándo se limpia, es una decisión de arquitectura, no un detalle de implementación. Es el mismo principio que ya escribí cuando la falla de nueve segundos no era del agente sino de cómo estaba armado: el modelo casi nunca es el problema, el andamiaje sí.

Ahora, la reacción de internet a esta historia fue tan instructiva como la historia misma. Debajo del post, los comentarios se llenaron de soluciones con mayúscula y símbolo de marca registrada: doctrinas de intención compilada, kernels árbitro, provenance soberano firmado con criptografía, capas que cortan el socket TCP si el byte no cuadra. Mucha física de bóveda blindada para un problema que, en el fondo, era un objeto olvidado en una variable.

El propio Fabio propone algo más sensato: que antes de una acción de alto impacto, el agente declare qué datos y campos va a usar, y que un verificador liviano bloquee todo lo que se salga de ese contrato. Es una idea razonable. Pero conviene recordar cómo se arregló el caso real, porque fue vergonzosamente barato: sacaron el objeto de contrato del camino de facturación, agregaron una evaluación que marca cualquier factura por debajo de un umbral para revisión explícita, y conservaron la capa de trazas. Lo resolvieron en una tarde, una vez que supieron dónde mirar.

Esa es la lección que se pierde entre tanto acrónimo. El valor no estaba en un protocolo nuevo. Estaba en ver el problema, y en una eval (evaluación automática) de diez líneas que pregunta lo único que nadie le había pedido al sistema que preguntara: ¿una factura de cero dólares tiene sentido aquí?

La compuerta humana no es una muleta temporal

Lo único que evitó que esa factura saliera fue una persona revisando antes de aprobar.

Y aquí hay una idea que conviene decir sin rodeos, porque hay toda una corriente que vende la revisión humana como una vergüenza pasajera, un parche que vas a quitar cuando el modelo “madure”. Es al revés. Tu empresa ya exige que varias personas revisen una decisión material de dinero antes de que sea definitiva. Nadie en finanzas firma un cheque grande solo porque el cálculo “se veía bien”. ¿Por qué un agente debería operar con menos supervisión que un empleado humano para esa misma decisión?

Las trazas, la observabilidad, las evaluaciones y la revisión humana no son señales de que la IA agéntica esté fallando. Son las señales de que estás construyendo sistemas de producción como adulto. El agente acelera el trabajo, reúne la información, ejecuta el flujo, levanta la mano en las excepciones. La compuerta sigue siendo humana en lo que toca dinero, contratos, nómina, cumplimiento. Eso no es desconfianza en la IA. Es la misma disciplina que aplicarías a cualquier sistema con autoridad para mover plata.

Y no lo dice un escéptico. Anthropic, en su propia guía de cómo construir agentes, recomienda que el agente se detenga a pedir aprobación humana en puntos de control, sobre todo cuando la acción tiene consecuencias. Cuando el laboratorio que hace Claude te dice que pongas un humano en la compuerta, vale la pena no tratarlo como un trámite que vas a borrar el mes que viene.

Gartner proyecta que cerca del 30% de los proyectos de IA generativa se abandonan después del piloto. La razón rara vez es que el modelo no pueda hacer la tarea. Es que nadie confía en una salida que pasa todas las pruebas menos la realidad. La factura de $0.00 es esa estadística en miniatura: la prueba de concepto funcionaba, hasta el día que casi factura gratis a un cliente empresarial.

Lo que hacemos en IQ Source con esto

Cuando una empresa nos pide meter un agente en un proceso que toca ingresos, la primera pregunta nunca es “¿qué modelo usamos?”. Es “¿cómo vamos a ver lo que hace cuando se equivoque?”. Porque se va a equivocar, y el día que lo haga, la diferencia entre un susto y un desastre es si tenías la traza prendida o no.

AI Maestro es el discovery donde eso se decide antes, no después del primer incidente. Mapeamos el proceso real, no el del organigrama, e identificamos exactamente en qué pasos un modelo podría meter su propia lógica entre los tuyos. De ahí salen cuatro cosas concretas que dejamos instaladas antes de que el agente toque un solo cliente: trazas completas de ejecución para ver cada span, evaluaciones automáticas que marcan los montos y resultados fuera de rango, una compuerta humana en toda acción de alto impacto, y disciplina de contexto para que no quede ningún objeto viejo contaminando al modelo.

Es lo contrario de no dejar que la IA sea la dueña de la verdad del negocio: el número correcto vive en un sistema determinista, y el agente lo usa, no lo reinventa. Y va de la mano con preguntar, antes que nada, si ese proceso siquiera necesita un agente. Muchos no lo necesitan, y un flujo determinista jamás se habría inventado el descuento del 100%.

La próxima vez que alguien en tu empresa te muestre un agente “listo para producción”, no preguntes si funciona en la demo. Casi siempre funciona en la demo. Pregunta una sola cosa: cuando este agente haga algo que nadie le pidió, entre dos pasos que sí controlamos, ¿lo vamos a ver? Si la respuesta es un silencio incómodo, todavía no está listo. Está esperando su propia factura de cero dólares.

Ver dónde tu agente puede facturar $0.00