El modelo mental está equivocado desde antes de la primera llamada
Los equipos presupuestan la IA como presupuestan el software: eligen una herramienta, pagan una cuota mensual fija y siguen adelante. Una API de modelos con cobro por uso rompe esa intuición. No se compra un asiento: se compran tokens, con precio por millón, cobrados tanto por lo que se envía como por lo que regresa. El costo es una función de volumen × tamaño del prompt × nivel del modelo, y los tres tienden a subir por sí solos a medida que crece un producto.
La distribución lo demuestra. En el AI Index de Ramp de junio de 2026, la mediana del gasto empresarial en IA fue de unos $11.38 por empleado al mes, mientras que el 1% que más gastaba llegó a cerca de $7,500 por empleado al mes; Ramp calculó la diferencia en unas 680×. Una diferencia tan grande no se explica por “usar más IA”. Se explica por la arquitectura.
Y buena parte del uso real ni siquiera es visible para el área de finanzas. El informe de 2025 de Menlo Security encontró un aumento del 68% en empleados que usan cuentas personales para acceder a herramientas de IA gratuitas en el trabajo: la “IA en la sombra” que nunca aparece en la factura de un proveedor. No se puede optimizar un gasto que no se ve.
Tres errores que se multiplican, no se suman
La mayor parte del gasto excesivo se remonta al mismo pequeño conjunto de errores estructurales. Cada uno, por separado, es soportable. El daño está en que se acumulan: una sola solicitud puede cargar con los tres a la vez.
Sin caché de prompts. Un prompt de sistema largo y estático se reenvía y se vuelve a cobrar en cada turno. Un bloque de sistema de 4,000 tokens, diez mensajes por sesión y mil sesiones al día suman cuarenta millones de tokens de entrada diarios, pagados una y otra vez para enviarle al modelo un texto que ya procesó en el turno anterior.
Enrutamiento excesivo. Los análisis de sentimiento, las decisiones de sí o no y los borradores de correo con plantilla se mandan a un modelo de frontera por costumbre. La diferencia de precio no es marginal: un modelo de primer nivel puede costar del orden de cien veces o más que un modelo pequeño y rápido por la misma llamada corta. Cualquier tarea que un modelo más ligero y económico resuelve bien, un modelo de frontera simplemente la paga de más.
Procesos sin tope. Sin un límite de costo por usuario o por sesión, sin límite de tasa. Un ciclo de reintentos, una página rota que se recarga sin parar o una cuenta de prueba olvidada pueden quemar el presupuesto de un día en una tarde. Hay equipos que reportan facturas que se multiplicaron varias veces en un solo trimestre antes de que alguien pudiera nombrar la causa: la clásica historia de “de repente tenemos una factura de $10k”.
Cómo se ve realmente ajustar el tamaño
La solución no es “usar menos IA”. Es enrutar cada tarea al modelo más económico que alcance el nivel de calidad requerido, y guardar en caché todo lo que se repite. Primero se clasifica la solicitud (de forma barata, o con una regla) y luego se envía al nivel que le corresponde:
Intención / sí-no / sentimiento → nivel 1, modelo pequeño (o local), a menudo casi gratis Extracción corta / resúmenes → nivel 1, modelo pequeño Borradores con plantilla → nivel 1, con el prompt estático en caché Razonamiento en varios pasos / código → nivel 2, modelo intermedio Lo realmente difícil o delicado → nivel 3, de frontera, y solo aquí
Combine eso con caché de prompts en los bloques estáticos, una caché de salidas para consultas idénticas repetidas y un tope estricto de gasto por sesión. Un flujo de trabajo construido así suele lograr un ahorro del 60–80% frente a la versión que usa solo modelos de frontera, con la misma calidad de salida, porque el modelo caro solo se ejecuta en las solicitudes que de verdad lo necesitan. No es una hipótesis: vea el caso de estudio del chatbot de soporte, donde el enrutamiento medido por acción hizo exactamente eso.
El umbral en el que gana el autoalojamiento
El precio por token es barato con poco volumen y castiga con mucho volumen. El hardware propio es lo contrario: un costo mensual fijo y un costo marginal por llamada cercano a cero. Las dos curvas se cruzan en un volumen concreto, no en una corazonada. Un modelo abierto de tamaño medio en una sola máquina de clase estación de trabajo se amortiza en unos noventa dólares al mes más la electricidad; con cien mil llamadas al mes, eso es del orden de una décima de centavo por llamada, menos que cualquier tarifa de API para la misma tarea.
Así que la pregunta nunca es “API o autoalojamiento” en abstracto. Es: con su volumen de llamadas y su mezcla de tareas, ¿de qué lado de la línea está, y son sus llamadas de alto volumen y baja complejidad las que todavía van al endpoint de un modelo de frontera con cobro por uso? Los perfiles de hardware de EyesInAI y las cifras de costo por tarea de la clasificación están ahí para encontrar esa línea en su carga de trabajo.
Qué hacer esta semana (sin cambiar la infraestructura)
Tres acciones recuperan la mayor parte de la fuga antes de tocar su arquitectura. Primero, active la caché de prompts para cualquier prompt de sistema estático; normalmente es una opción de configuración. Segundo, fije un tope de gasto por usuario o por sesión y un límite de tasa, para que un ciclo no termine en las noticias. Tercero, tome su tarea de mayor volumen y pregúntese si de verdad necesita el modelo en el que está; bájela un nivel y mida la calidad. La mayoría de los equipos descubre que sí, que estaba pagando de más, y eso resume todo el impuesto de tokens en una oración: le cobraron por la estructura, no por la inteligencia.
Ese es el porqué. El Manual contra el impuesto de tokens es el cómo: cuatro palancas concretas (enrutamiento, caché y topes, autoalojamiento y un ciclo de enrutamiento que se corrige solo), cada una basada en lo que de verdad usamos en el chatbot de DLR. La prueba medida está en los casos de estudio.
Leer el manual