El número que hace que la IA parezca gratis
Pon precio a una misma pieza de trabajo de las dos formas. Un ticket de soporte clasificado por un modelo - leerlo, clasificarlo, enrutarlo, redactar el acuse de recibo - consume unos 500 tokens de entrada y 50 de salida, lo que con Haiku 4.5 a las tarifas publicadas suma $0.00075. El mismo ticket atendido por una persona con un coste cargado de $22 la hora, treinta tickets por hora, cuesta $0.73. Esa es una diferencia de aproximadamente 978 veces, y cada número que contiene es un supuesto que puedes cambiar: paga $30 la hora, atiende 20 tickets, usa un modelo más grande, la diferencia sigue siendo de tres órdenes de magnitud.
| Tarea | Coste / tarea |
|---|---|
| IA · Haiku 4.5 | $0,00075 |
| Una persona | $0,73 |
| Personas vs IA | ~978× |
Lo que cuesta una tarea
Clasificación de tickets, modelada · escala logarítmica, cada línea de cuadrícula es 10×
Modelado, no medido: clasificación con Haiku 4.5 a las tarifas publicadas (500 tokens de entrada a $1 / 1M, 50 de salida a $5 / 1M = $0.00075) frente a una persona con un coste cargado de $22 la hora que atiende 30 tickets por hora ($0.73). La escala es logarítmica. El salario, el rendimiento y los recuentos de tokens son datos de entrada que deberías sustituir por los tuyos; la diferencia sobrevive a cualquier conjunto realista de ellos.
Números como ese hacen que la IA parezca un sí automático, y son precisamente la razón por la que los dueños de negocio acaban decepcionados. Porque el precio por tarea no es la decisión. Es el número más pequeño de la sala.
El verdadero obstáculo es el desarrollo
Entre ti y esas fracciones de céntimo hay un coste fijo: alguien tiene que construir la funcionalidad. Conectarla a tu sistema de tickets, escribir y probar los prompts, gestionar los casos límite, poner una pantalla de revisión delante, desplegarla. Que sea un script de $3,000 o una integración de $20,000 depende del alcance, y se comporta como cualquier otra decisión de capital que toma tu empresa: hay que recuperarlo con los ahorros, mes a mes. La IA no eliminó esa lógica; solo hizo el coste marginal tan pequeño que el desarrollo es prácticamente toda la inversión. Si estás sopesando esto frente a comprar una herramienta ya hecha, esa es su propia decisión, pero la aritmética de abajo funciona igual en ambos casos.
La fórmula del punto de equilibrio
Todo el modelo cabe en una línea: amortización en meses = coste de desarrollo ÷ (tareas al mes × ahorro por tarea), donde el ahorro por tarea es lo que cuesta que una persona la haga menos lo que cuesta el modelo. El coste cargado por hora dividido entre tareas por hora da el lado humano; la cuenta de tokens da el lado de la IA. Tres datos de entrada, una división, y cada uno de ellos está en tus manos para corregirlo: tus salarios, tu rendimiento, tu presupuesto.
El mismo desarrollo a tres volúmenes
| Volumen | Punto de equilibrio |
|---|---|
| 10,000 tareas / mo | ~5 semanas |
| 3,000 tareas / mo | ~3,7 mo |
| 300 tareas / mo | ~3 yr |
El mismo desarrollo a tres volúmenes
Desarrollo $8,000; cada tarea: IA ~$0,00075 vs una persona ~$0,73 (modelado)
Coste acumulado de que personas hagan la tarea (tres volúmenes) frente a construir una vez por $8,000 y ejecutarla con IA. Supuestos de la tarea como en el gráfico de arriba; el uso de IA a estos volúmenes es de $0.23 a $7.50 al mes, por lo que la línea ámbar se dibuja plana. El punto de equilibrio cae en unas 5 semanas para 10,000 tareas al mes, 3.6 meses con 3,000 y aproximadamente 3 años con 300. Sustituye tu propio salario, rendimiento y presupuesto de desarrollo; lo importante es la forma.
Este es el gráfico que zanja la mayoría de las discusiones sobre construir o no, porque lo único que cambia entre las tres líneas es el volumen. Con 10,000 tareas al mes el desarrollo de $8,000 se recupera en unas cinco semanas; el mismo desarrollo con 300 tareas al mes se alarga durante aproximadamente tres años, lo que en términos de software es una decisión completamente distinta. Nada cambió en el modelo, en los prompts ni en la calidad. El volumen por sí solo movió la respuesta de un sí evidente a un probable no.
La tabla de amortización
Encuentra tu columna, encuentra tu presupuesto, y tienes una primera respuesta defendible antes de que nadie abra un IDE.
| 300 tareas / mo | 1,000 / mo | 3,000 / mo | 10,000 / mo | |
|---|---|---|---|---|
| Ahorro mensual | $220 | $733 | $2,198 | $7,326 |
| El desarrollo de $3,000 se amortiza en | 13.7 mo | 4.1 mo | 1.4 mo | 0.4 mo |
| Desarrollo de $8,000 | 36.4 mo | 10.9 mo | 3.6 mo | 1.1 mo |
| Desarrollo de $20,000 | 91.0 mo | 27.3 mo | 9.1 mo | 2.7 mo |
Dos lecturas honestas de esa tabla. Hacia abajo por una columna: la disciplina de alcance compensa, porque con 1,000 tareas al mes la diferencia entre un desarrollo de $3,000 y uno de $20,000 es la diferencia entre cuatro meses y dos años. A lo ancho de una fila: el volumen es palanca, porque el mismo desarrollo de $8,000 pasa de ser un error de redondeo a ser injustificable según cuántas tareas le des de verdad. Cuando una estimación cae en la zona gris del medio, el experimento más barato suele ser un desarrollo más pequeño que ponga a prueba el supuesto de volumen, no un desarrollo más grande que apueste por él.
Cuándo sí importa el precio por token
La clasificación es una tarea barata; no todo lo es. Un trabajo de redacción que lee un informe de 2,000 tokens y escribe un documento de 1,500 tokens con Opus 4.8 cuesta unos $0.05 por tarea, y el trabajo con contexto largo puede subir bastante más. Sigue comparándose con $0.37 de un solo minuto de tiempo humano, así que la diferencia sobrevive, pero con decenas de miles de tareas la línea marginal deja de ser decoración: es la diferencia entre que los tokens cuesten $8 al mes o $500. Ahí es donde los multiplicadores ocultos de la primera parte y las palancas de la segunda parte se conectan a este modelo: mueven el ahorro por tarea, lo que acorta la amortización. Rara vez cambian por sí solas la decisión de construir, pero deciden cuán buena llega a ser una buena decisión.
Lo que este modelo deja fuera
Honestidad sobre el cálculo del sobre. Si una persona sigue revisando cada resultado, tu ahorro por tarea es el delta de tiempo de revisión, no los $0.73 completos, y la amortización se alarga en consecuencia; el modelo se gana su sitio donde cierra por completo la mayoría de las tareas y escala el resto. Los errores tienen un precio que esta fórmula no ve, así que las tareas en las que una respuesta equivocada es cara necesitan una comprobación barata en el circuito antes de que la cuenta del volumen signifique algo. Y el desarrollo no es la última factura: los prompts se desvían, los sistemas cambian, alguien mantiene la integración. Nada de eso rompe el modelo; solo pertenece a la columna del desarrollo, y un piloto dimensionado para poner a prueba tu supuesto de volumen es la forma más barata de descubrir cuáles son de verdad los números.
