Costo de automatización con IA: la cuenta es por ejecución
La automatización tradicional tiene costo fijo. Pagas para construirla una vez y cada ejecución siguiente sale prácticamente gratis. Cuando un modelo de lenguaje entra en el flujo, eso se invierte: el costo pasa a cobrarse por ejecución y crece junto con el volumen. La cuenta no cambia de tamaño, cambia de unidad.
¿Por qué cambia la cuenta cuando un modelo entra en el flujo?
Porque el trabajo deja de ejecutarse por una instrucción escrita una sola vez y pasa a producirse de nuevo en cada llamada. Un script que clasifica pedidos por regla corre diez mil veces por el costo de mantener el servidor encendido. Un modelo que clasifica pedidos leyendo el texto cobra diez mil veces.
Esa diferencia no aparece en el piloto. Con treinta casos por semana, cualquier diseño parece barato. Aparece cuando la automatización toca el volumen real de la operación, que es exactamente el momento en que la ganancia debía aparecer.
El efecto colateral es que el riesgo financiero del proyecto cambia de signo. En una automatización por reglas, el escenario malo es el uso bajo: pagaste para construirla y nadie la usa. En una automatización con modelo, el escenario caro es la adopción. Cuanto más la usa la operación, mayor es la factura del mes siguiente.
El precio por token cayó. ¿Por qué no cae la cuenta?
Precio y consumo son cosas distintas, y solo cayó el precio.
El AI Index 2025, de Stanford, midió la caída: para un modelo con 64,8 puntos en MMLU, la inferencia costaba US$ 20 por millón de tokens en noviembre de 2022 y US$ 0,07 por millón en octubre de 2024. En una prueba más difícil, GPQA, el mismo informe registra US$ 15 por millón en mayo de 2024 y US$ 0,12 en diciembre del mismo año. Epoch AI, citada allí, estima caídas de entre 9 y 900 veces por año según la tarea.
El consumo fue en dirección contraria. Los modelos que razonan antes de responder producen tokens intermedios, y tú los pagas. OckBench, preprint de noviembre de 2025 revisado en junio de 2026 y aún sin revisión por pares, evaluó 37 combinaciones de modelo y nivel de esfuerzo en 200 problemas de matemáticas, ingeniería de software y ciencia. El resultado que importa aquí: dos modelos con exactitud casi idéntica, 82,5% contra 82,0%, gastaron en promedio 83,6 mil y 3,2 mil tokens.
En otra línea de la misma tabla, una configuración con un precio por token bastante menor quedó un poco por debajo en exactitud y aun así salió más cara en la ronda completa, US$ 12,60 contra US$ 9,50, porque escribió mucho más.
Los autores llaman a este efecto el impuesto del exceso de razonamiento: un modelo puede parecer eficiente por su número de parámetros o por su precio por token y aun así salir caro, porque genera trazas de razonamiento largas y de bajo rendimiento.
Quien compara modelos de forma profesional ya cambió de unidad. Artificial Analysis publica costo por tarea y explica el motivo en su propia metodología: como el costo refleja el uso real de tokens, los modelos que producen respuestas más largas o más tokens de razonamiento tienen un costo por tarea mayor, incluso con un precio por token idéntico.
Para quien firma el presupuesto, la lectura práctica es corta. El precio de lista no es el costo de tu proceso, y elegir un modelo es una decisión de ingeniería con consecuencia financiera mensual.
¿Cuántas veces al mes corre ese proceso?
Esa es la pregunta que decide el proyecto, y casi nunca está en el presupuesto.
La automatización por reglas mejora con el volumen, porque el costo de construirla se diluye en cada ejecución. La automatización con modelo no diluye nada, ya que el costo es lineal. Las dos pueden tener el mismo valor de contrato y comportamientos financieros opuestos al mes siguiente.
Eso cambia la aritmética del retorno. El payback en meses describe bien una inversión que ocurre una vez. Aquí la unidad útil es otra: costo por caso procesado contra costo humano por caso, con un techo escrito para el primero. Sin techo, el éxito del proyecto es lo que revienta el presupuesto.
Y existe el costo que no es de inferencia. Alguien revisa la salida, alguien atiende el caso que el modelo rechazó, alguien nota cuando la calidad baja. Ese trabajo casi nunca aparece en la planilla de aprobación, y es el mismo que decide cuándo conviven procesos manuales y automatización.
Cómo se ve esto en una distribuidora
Un escenario, para dejar la aritmética a la vista. Los números de abajo son hipótesis de trabajo, no medición de un cliente.
Una distribuidora recibe pedidos por correo y WhatsApp en texto libre. Dos personas los transcriben al ERP. Son 300 pedidos por día, cerca de 6.600 al mes.
En el primer diseño, el modelo recibe el correo entero, el historial del cliente, la lista de precios completa y las reglas comerciales, y devuelve el pedido listo para cargar. Funciona en la demostración.
En el segundo, el sistema ya sabe quién es el cliente por el remitente, qué lista de precios le aplica y qué compró las últimas doce veces. El modelo recibe el texto del pedido y resuelve solo lo que está ambiguo en él.
Los dos entregan el mismo resultado, y la diferencia de costo por pedido no está en el modelo. Está en cuánto contexto hay que reenviar en cada ejecución porque el sistema no guardó nada. La aritmética la corres con tus propios precios: multiplica el tamaño del contexto de cada diseño por el precio por token de tu proveedor y después por el volumen del mes, que aquí es 6.600. En el primer diseño, la distribuidora paga 6.600 veces al mes para que el modelo redescubra lo que su propio registro debería saber.
Cómo están metiendo el modelo en el flujo las empresas
Fuera del escenario, la medición existe. La Encuesta sobre el uso de TIC y comercio electrónico en las empresas, del INE, encontró que el 21,1% de las empresas españolas de 10 o más empleados usaba tecnologías de inteligencia artificial en el primer trimestre de 2025, 8,7 puntos más que el año anterior. En el sector servicios la proporción llega al 25,7%.
El salto de 8,7 puntos en doce meses dice más que el nivel. La entrada fue rápida, y una entrada rápida rara vez viene acompañada de un rediseño del proceso que hay debajo.
Ese es el punto que produce el costo por ejecución: el modelo entra por encima del proceso que ya existía, y el proceso que ya existía no guarda contexto.
Cuatro decisiones antes de poner el modelo en el flujo
- Separa regla de juicio. Lista de precios, umbral de aprobación por importe, plazo por región y política de descuento son reglas, y una regla escrita no cobra por ejecución.
- Define la unidad de cobro del proceso: por pedido, por documento, por ticket. Escribe el techo de costo aceptable por unidad antes de aprobar y trata el exceso como defecto, no como éxito comercial.
- Lista lo que tiene que viajar en cada llamada y pregunta por qué eso no está guardado. Contexto reenviado es registro que falta.
- Escribe qué pasa cuando el volumen se duplica. A quién se avisa, cuál es el límite diario, qué se degrada primero. Esa conversación es la misma de orquestar equipos de TI y negocio en automatización.
Preguntas frecuentes
¿Cómo se calcula el retorno de una automatización que cobra por ejecución?
Mide el costo humano por caso de hoy, con el tiempo real de quien lo ejecuta, y compáralo con el costo por caso de la automatización, sumando inferencia, revisión y tratamiento de excepciones. Corre el cálculo con el volumen del mes más cargado del año, nunca con el promedio. Si el retorno solo existe mientras el volumen se mantiene bajo, no hay retorno.
Si el precio de los modelos cae todos los años, ¿conviene esperar?
Esperar el precio no resuelve lo que pesa en tu cuenta. En la misma tarea, la diferencia entre una automatización cara y una barata viene del diseño del flujo y de lo que el sistema guarda, y el precio por token baja para todos al mismo tiempo. Separar regla de juicio y ordenar el registro lleva meses de trabajo y no queda obsoleto.
No tengo equipo calificado para implementarlo. ¿Eso cambia la cuenta?
La cambia, en el punto que suele subestimarse: decidir dónde entra el modelo en el flujo vale más que elegir el modelo. Comprar una solución lista resuelve la operación básica y mantiene el costo unitario invisible, lo que funciona mientras el volumen es pequeño. Si el proceso es tu diferencial y corre miles de veces al mes, alguien tiene que responder por la arquitectura, interno o contratado.
El siguiente paso
Si estás por meter un modelo dentro de un proceso que corre miles de veces al mes, conviene mirar el flujo antes que el presupuesto: el Diagnóstico de Arquitectura Operacional es una conversación de 30 minutos sobre eso.
Cases relacionados
¿Reconociste tu operación en este artículo?
Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin propuesta en la primera conversación.
Agendar diagnóstico