Cómo calculo cuánto me cuesta de verdad un agente que falla

El miércoles que casi aprobé el email con el precio desactualizado —lo monté un agente en MailerLite con el precio de la semana anterior, listo para salir a toda la lista— se lo conté a un colega dos días después.

Me preguntó algo que no supe responder bien: "¿por qué revisaste ese y los cuarenta y dos thumbnails de la noche anterior los aprobaste sin mirar ni uno?". Dije "depende del riesgo". Se quedó esperando un número. No lo tenía.

"Depende" no es un criterio, es decidir a ojo. Y a ojo, tarde o temprano, fallas por el lado que más duele.

Me senté a calcular, en números y no en corazonadas, cuánto cuesta un agente de IA que falla. La misma cuenta que hago hoy antes de aprobar lo que entrega cualquier agente.

En corto: para decidir si reviso lo que entrega un agente de IA antes de aprobarlo, comparo dos números: el coste esperado de que falle sin que yo lo vea (probabilidad × daño) contra el coste de verificarlo yo mismo. Si el primero es mayor, reviso siempre. Si es menor, delegar sin mirar es la decisión más barata — no la más cómoda.

¿Qué es el coste esperado de no verificar una tarea delegada?

El coste esperado de no verificar es la probabilidad de que la tarea delegada falle, multiplicada por todo lo que te cuesta cuando falla: detectarlo tarde, arreglarlo y el daño que ya hizo antes de que te dieras cuenta.

El coste de verificar es más simple: es el tiempo que te cuesta a ti —o a quien revise— leer, entender y aprobar esa tarea antes de que se vuelva irreversible.

La regla de decisión sale sola al poner los dos números uno al lado del otro. Si el coste esperado de no verificar es mayor que el coste de verificar, revisas siempre. Si es menor, delegas sin revisión — no por pereza, sino porque es la opción matemáticamente más barata.

Este principio —revisar antes de que algo se vuelva irreversible— es el corazón del método que dejé completo y gratis en el ebook Revisión por Contrato: cómo definir de antemano qué necesita aprobación humana y qué no.

Por qué no tomo prestado el "100x más caro en producción" de la industria

Antes de construir esta fórmula tuve la tentación de usar el número que todo el mundo repite: que un bug en producción cuesta cien veces más arreglarlo que uno detectado en desarrollo. Aparece en charlas, en posts de blog, en pitch decks de herramientas de testing.

Ese número, rastreado hasta la fuente, puede que no exista tal como se cita. Un hilo de Hacker News de 2021, con 159 puntos y 130 comentarios —"The 'bugs are 100x more expensive to fix in production' study might not exist"— sigue la cadena de citas hasta el estudio original y no encuentra una medición limpia detrás, solo cita tras cita.

El usuario nerdponx lo resume mejor de lo que yo podría: "No es un caso de investigación falsificada. Es un caso de alguien citando algo apócrifo como si fuera un hecho, y luego otra gente citando esa cita" —traducido del inglés.

Por eso, abajo, no uso ningún multiplicador prestado de la industria. Los números de probabilidad y de coste son míos, ilustrativos, pensados para mostrar el mecanismo — no una estadística que puedas citar como un dato medido.

El cálculo real: el email con el precio equivocado

Uso $50 la hora como referencia ilustrativa de mi propio tiempo — no es una tarifa de mercado. Cambia el número por el tuyo: el mecanismo de la fórmula no varía.

Releer el asunto y el precio antes de aprobar el envío me costó entre 2 y 3 minutos: unos $2,50. Ese es el coste de verificar.

La probabilidad de que el precio hubiera cambiado justo esa semana, sin que yo lo notara, era baja — pongamos, ilustrativamente, un 5%.

Pero si fallaba, el coste no era pequeño. Arreglarlo —corrección más responder a quien preguntara— son unas 2 horas: $100. Y está el daño ya hecho antes de detectarlo: la credibilidad del precio frente a miles de bandejas que ya leyeron una cifra falsa. No tiene cifra exacta, pero tiene un piso conservador — ilustrativamente, $200. Total si falla: ≈ $300.

Coste esperado de no verificar = 5% × $300 = $15.

$15 es mayor que $2,50. La fórmula dice: verifica siempre. Y lo que gana la decisión no es la probabilidad —era baja— sino la magnitud del daño si el evento raro ocurre.

El contraste: 42 thumbnails, probabilidad alta, coste casi cero

La noche anterior había dejado al mismo agente generando cuarenta y dos thumbnails para posts antiguos: prompt, imagen, nombre de archivo, carpeta correcta. Los aprobé todos sin abrir ni una carpeta.

Aquí la probabilidad de que algo saliera mal era, ilustrativamente, alta — un 30%: con cuarenta y dos piezas generadas en patrón, algo se cuela con frecuencia.

Pero si falla, el coste es casi nada. Se ve al abrir la carpeta —dos minutos, unos $1,70— y se regenera con un comando. No hay corrección pública ni daño reputacional: nadie fuera de mí ve el error antes de que lo arregle.

Coste esperado de no verificar = 30% × $1,70 ≈ $0,51.

Verificar las 42 imágenes una por una, a un minuto cada una, cuesta $35. $0,51 es muchísimo menor que $35. La fórmula dice: delega sin revisar. Aquí la probabilidad alta no importa, porque el daño y la irreversibilidad son casi cero.

Elemento del cálculo	Email de lanzamiento	42 thumbnails
Coste de verificar antes de aprobar	3 min ≈ $2,50	42 min (1 min c/u) ≈ $35
Probabilidad ilustrativa de que falle	5% — evento infrecuente	30% — patrón repetido, muchas piezas
Coste si falla (arreglar + daño ya hecho)	≈ $300 (corrección + credibilidad)	≈ $1,70 (se regenera con un comando)
Coste esperado de NO verificar (P × coste si falla)	≈ $15	≈ $0,51
Qué inclina la balanza	La magnitud del daño, no la probabilidad	Lo barato y rápido que es detectar y arreglar
Decisión de la fórmula	Verificar siempre	Delegar sin revisar

La fila que importa es la penúltima. No decide la probabilidad: decide qué tan caro sale el daño si el evento raro ocurre, y qué tan barato es deshacerlo si no.

Es el mismo cálculo que aplico al diseñar los agentes que uso a diario, y es lo que enseño paso a paso en Construye con IA: no solo montar el agente, también decidir qué parte de su trabajo se aprueba sin mirar y cuál se revisa siempre.

Si esto te suena al criterio de blast radius que ya usaba antes de tener la fórmula, es porque es el mismo criterio con números detrás. Para el ángulo más amplio de por qué creo que el techo de los agentic systems es económico y no técnico, lo desarrollé en este otro post.

Cuándo esta fórmula no sirve

No es una máquina de la verdad. Tiene límites que conviene decir en voz alta antes de que alguien la use como excusa para no pensar.

Estimar la probabilidad es subjetivo, y es fácil engañarte a ti mismo minimizándola. Si el agente acertó las últimas diez veces, tu cerebro te dirá que la probabilidad de fallo es más baja de lo real. Ese sesgo no lo corrige la fórmula — el número lo pones tú, con tu sesgo incluido.

El coste del daño reputacional no tiene un número exacto. La fórmula te obliga a poner una cifra, pero esa cifra es una estimación conservadora, no una medición. Si la subestimas para que el cálculo te dé el resultado que ya querías, el cálculo miente a tu favor.

Esta fórmula evalúa una tarea aislada, no un sistema. No sustituye un gate automático —tests, tipos, criterios de aceptación que corran solos— que verifique sin depender de que te acuerdes de hacer la cuenta cada vez. Es la capa manual para cuando ese gate todavía no existe.

Qué hacer hoy con esto

No necesitas una hoja de cálculo. Coge las tres tareas que más delegas esta semana a un agente y, para cada una:

1. Escribe cuánto te cuesta verificarla antes de aprobarla.
2. Ponle una probabilidad ilustrativa a que falle.
3. Estima cuánto costaría si falla —arreglo más daño ya hecho antes de detectarlo.
4. Multiplica los puntos 2 y 3: ese es tu coste esperado de no verificar.

Compara ese resultado con el coste de verificar del punto 1. Donde gane verificar, sigue revisando sin culpa —no es desconfianza en el agente, es aritmética—. Donde pierda, suelta esa tarea del todo.

Si quieres ver cómo aplico esta cuenta cada semana en un negocio real que opero solo, sin nadie más que revise detrás de mí, en Dominicode Labs comparto los números actualizados y las tareas concretas que delego o audito según van cambiando mis agentes.

---

Preguntas frecuentes

¿Cómo calculo cuánto me cuesta que un agente de IA falle?

Multiplica la probabilidad de que la tarea falle por el coste total si falla: detectarlo tarde, arreglarlo y el daño ya hecho antes de que lo notes. Ese resultado es el coste esperado de no verificar. Compáralo con el coste de verificar antes de aprobar — el que sea menor gana.

¿Qué diferencia hay entre esta fórmula y el criterio de blast radius?

Ninguna en el fondo — son el mismo criterio en dos niveles. El blast radius es la versión cualitativa: cuánto daño hace algo y qué tan reversible es. Esta fórmula es la versión cuantitativa: le pones números a ese daño y a esa probabilidad para comparar dos tareas objetivamente, no a ojo.

¿Cómo estimo la probabilidad de que una tarea delegada a un agente falle?

Con honestidad, sabiendo que es una estimación y no una medición. Fíjate en cuántas veces has visto fallar ese tipo de tarea, cuánto contexto de negocio necesita que pueda haber cambiado sin que el agente lo sepa, y desconfía de tu propia racha reciente de aciertos.

¿Esta fórmula sustituye tener tests automáticos o un gate de verificación?

No. Decide sobre una tarea puntual, cuando no existe todavía un mecanismo automático que verifique el resultado por ti. Si puedes construir ese gate —tests, tipos, criterios de aceptación que corran solos— constrúyelo: es más fiable que cualquier cálculo manual que dependa de que te acuerdes de hacerlo cada vez.

¿Qué hago si no puedo poner un número exacto al daño reputacional?

Pon un piso conservador y dilo explícitamente: es una estimación, no una medición. El objetivo no es acertar la cifra exacta, sino evitar el error más común, que es tratar el daño reputacional como si costara cero solo porque no tiene un precio de catálogo.

---

Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.