La Economía de los Tokens

Para la mayoría de las empresas, el gasto en software ha sido históricamente relativamente fácil de clasificar. Hay licencias, infraestructura, costos de desarrollo, contratos de soporte y servicios en la nube. La inteligencia artificial introduce un componente menos familiar: el trabajo realizado por el propio software puede tener ahora un costo directo y variable.

A pequeña escala, esto resulta fácil de ignorar. Unos pocos empleados utilizando un asistente de IA, o una aplicación experimental realizando llamadas ocasionales a un modelo, rara vez producirán una factura suficiente como para condicionar una decisión de negocio. La economía empieza a cambiar cuando la IA deja de ser solamente una interfaz conversacional y comienza a integrarse en aplicaciones y procesos operativos.

Una solicitud de un cliente puede disparar una llamada a un modelo. Un sistema de cotizaciones puede utilizar IA para interpretar requerimientos. Una aplicación de soporte puede resumir un caso, recuperar documentación, compararla con reglas internas y preparar una respuesta. Lo que para el usuario aparece como una sola operación puede implicar en realidad varias llamadas independientes a uno o más modelos, cada una consumiendo recursos computacionales y sumando costo al proceso.

Por eso la planificación de IA no puede reducirse a elegir el modelo más capaz. Arquitectura, volumen de uso, manejo de datos, rendimiento y costo deben analizarse en conjunto.

De las suscripciones al consumo

Los productos de chat ocultan buena parte de esta complejidad. Una empresa compra suscripciones para sus empleados y obtiene un gasto mensual relativamente predecible. El usuario abre la aplicación, hace una consulta y recibe una respuesta. La relación entre uso y costo existe, pero permanece en gran medida abstraída.

Las aplicaciones funcionan de otra manera. Cuando un software se conecta directamente con modelos de IA mediante APIs, la empresa determina qué información se envía, cuánto contexto acompaña cada solicitud, con qué frecuencia se realizan las llamadas y si hacen falta operaciones adicionales para verificar, transformar o actuar sobre la respuesta.

Pensemos en un flujo de procesamiento de documentos. Un modelo puede clasificar un documento entrante, otro paso puede extraer la información relevante, una llamada posterior puede comparar el resultado con las reglas de la compañía y una última operación puede redactar una respuesta o recomendar una acción. Para el empleado, todo eso constituye un único proceso. Para la infraestructura, pueden ser cuatro o cinco operaciones de IA distintas.

La diferencia importa porque los tokens, aunque son útiles como unidad de facturación, no constituyen una métrica empresarial particularmente útil. La dirección no suele pensar en millones de tokens. Piensa en cotizaciones, casos de soporte, documentos, transacciones y clientes.

La pregunta relevante, por lo tanto, no es simplemente cuántos tokens consume una aplicación, sino cuánto cuesta el componente de IA por cada unidad de trabajo completada. Costo por cotización, por caso de soporte, por documento procesado o por operación automatizada exitosa son métricas que permiten comparar el gasto en IA con el resto del negocio.

Este enfoque también expone un problema importante con los modelos aparentemente baratos. Dos sistemas pueden consumir una cantidad similar de tokens y, aun así, tener economías muy diferentes. Uno puede resolver correctamente una tarea en el primer intento; otro puede necesitar reintentos, contexto adicional o validación mediante un modelo más avanzado. El modelo más barato puede terminar generando el proceso más caro.

El diseño de la aplicación produce el mismo efecto. Enviar el historial completo de un cliente en cada solicitud es económicamente muy distinto de recuperar únicamente la información necesaria para la operación en curso. Reprocesar información estable una y otra vez tampoco es equivalente a almacenarla, reutilizarla o incorporar mecanismos de caching. El costo de la IA es, por lo tanto, una cuestión de precio del modelo, pero cada vez más también una cuestión de ingeniería.

No todas las tareas necesitan el mejor modelo

Cuando la IA pasa a formar parte de un sistema productivo, la selección de modelos se convierte en una forma directa de control de costos.

Hay pocas razones económicas para enviar cada operación al modelo más capaz disponible. Un análisis contractual complejo puede justificar un sistema avanzado de razonamiento. Detectar el idioma de un correo entrante, probablemente no. Clasificación, extracción, resumen, traducción y generación de datos estructurados pueden resolverse muchas veces con modelos más pequeños, reservando los más costosos para los casos realmente difíciles.

Esto conduce de manera natural a una arquitectura por niveles. El trabajo rutinario puede enviarse a modelos de menor costo, mientras que la capacidad más cara queda reservada para aquellas situaciones en las que aporta un beneficio medible. La separación puede ocurrir incluso dentro de un mismo proceso: un modelo pequeño realiza la clasificación inicial y uno más potente se invoca únicamente cuando el caso cae fuera de los parámetros normales.

El objetivo no es utilizar IA barata en todas partes. Es evitar pagar inteligencia premium para tareas que no requieren inteligencia premium.

La misma lógica se aplica a la infraestructura. Las empresas cuentan hoy con varias formas prácticas de ejecutar IA. Pueden consumir modelos propietarios directamente de sus proveedores, acceder a modelos comerciales mediante grandes plataformas cloud, desplegar modelos open-weight sobre infraestructura administrada o ejecutarlos en servidores dedicados o locales.

Cada alternativa modifica la ecuación económica. El acceso directo a un proveedor comercial suele ser la forma más sencilla de comenzar. Los requerimientos de infraestructura son mínimos, las capacidades avanzadas están disponibles inmediatamente y los costos acompañan el uso. A cambio, la empresa acepta cierto nivel de dependencia respecto del precio, disponibilidad, condiciones contractuales y entorno técnico del proveedor.

Los modelos open-weight ofrecen otro equilibrio. Pueden desplegarse en la nube, en servidores dedicados o dentro de la propia organización, dando mayor control sobre los datos y la infraestructura, pero trasladando también más responsabilidad operativa hacia la empresa. Hardware, mantenimiento, seguridad, actualizaciones, capacidad y soporte técnico pasan a formar parte de la ecuación.

No existe un modelo universalmente superior. La decisión correcta depende del workload.

Esto se vuelve especialmente interesante después de que un proceso de IA lleva cierto tiempo funcionando. Durante el desarrollo, utilizar un modelo comercial muy potente puede ser la manera más rápida de comprobar si una idea funciona. Meses después, la empresa dispone de algo mucho más valioso que una hipótesis: datos reales de operación. Sabe qué tareas son repetitivas, cuáles requieren razonamiento sofisticado, qué volumen de tráfico existe y cuánta información se está procesando.

En ese momento, una parte del workload puede convertirse en candidata para modelos más pequeños u open-weight. Un sistema comercial premium puede continuar resolviendo las excepciones complejas, mientras que tareas rutinarias de clasificación, extracción o consulta interna pasan a otra infraestructura. No hace falta convertir esto en una discusión ideológica entre IA propietaria y abierta. Es, sencillamente, asignación de carga de trabajo.

Nube, infraestructura local y utilización

Los servicios cloud tienen una ventaja económica evidente al comienzo: requieren poca inversión inicial y permiten pagar en gran medida de acuerdo con el consumo. Esto los vuelve especialmente atractivos para workloads variables, proyectos piloto y aplicaciones cuya demanda futura todavía es difícil de prever.

La infraestructura dedicada funciona de otra manera. Hardware, electricidad, redundancia, mantenimiento y soporte técnico se convierten en costos fijos. Una vez que esa capacidad existe, sin embargo, el costo marginal de realizar inferencias adicionales puede ser relativamente bajo.

El factor decisivo es la utilización. Comprar hardware costoso para un proceso que se ejecuta ocasionalmente tiene poco sentido. Mantener ese mismo hardware trabajando sobre una carga elevada y predecible puede producir una economía completamente diferente.

Los ejecutivos no necesitan convertirse en especialistas en utilización de GPU, pero sí deberían esperar que el equipo de arquitectura comprenda este punto de cruce. Antes de comprometer una carga de IA significativa de forma permanente con un proveedor o esquema determinado, debería existir una comparación seria entre el costo por consumo y el costo de operar capacidad dedicada.

El compliance también pertenece a ese cálculo. La arquitectura técnicamente más barata no siempre es la arquitectura empresarial más barata. Registros de clientes, información financiera, documentos legales o datos operativos internos pueden imponer restricciones geográficas, contractuales o regulatorias. Enviarlos a un servicio externo puede requerir controles adicionales, procesos de aprobación y condiciones contractuales específicas. Ejecutar los modelos internamente puede reducir algunas de esas preocupaciones, pero introduce otras responsabilidades relacionadas con control de acceso, seguridad, mantenimiento y gobernanza.

Esos costos son reales aunque nunca aparezcan en la factura del proveedor del modelo.

La IA necesita observabilidad financiera

Las empresas ya monitorean sus aplicaciones productivas en términos de disponibilidad, errores y rendimiento. Los sistemas con IA necesitan además una forma adicional de observabilidad: el consumo.

Para cada proceso relevante debería ser posible saber qué modelos están siendo utilizados, con qué frecuencia se los invoca, cuánto cuestan y qué volumen de actividad empresarial está generando ese gasto. La información no necesita presentarse en lenguaje técnico.

Un dashboard de gestión podría mostrar, por ejemplo, que la automatización de atención al cliente procesó 18.000 casos durante el mes con un costo promedio de IA de catorce centavos por caso. Podría mostrar que el 82 por ciento fue resuelto por un modelo más pequeño mientras que el 18 por ciento restante fue escalado a uno más capaz, y también si el costo promedio por caso está subiendo o bajando.

Eso le dice algo útil a la dirección. Una factura del proveedor con una gran cantidad de tokens, no.

La escala también debería incorporarse al análisis antes del despliegue. Los pilotos de IA suelen ser baratos porque sucede muy poco. Los sistemas productivos exitosos son otra cosa. Una funcionalidad que inicialmente utiliza un grupo reducido puede terminar ejecutándose miles o millones de veces, mientras que un asistente interno puede integrarse progresivamente en los procesos de toda una organización.

Las preguntas relevantes son, en realidad, preguntas tradicionales de capacity planning: cuánto cuesta el proceso con el volumen actual, qué sucede si ese volumen se multiplica por cinco o por diez, en qué momento otro modelo se vuelve económicamente más conveniente y a partir de qué nivel de utilización empieza a tener sentido una infraestructura dedicada.

La IA introduce una variable nueva, pero la disciplina necesaria para administrarla no es nueva.

Diseñar alrededor de capacidades, no de modelos

Hay una decisión arquitectónica que puede facilitar considerablemente todo lo anterior: las aplicaciones deberían mantenerse razonablemente independientes de los modelos específicos que utilizan.

El mercado de IA se mueve demasiado rápido como para suponer que el modelo preferido de hoy seguirá siendo el más adecuado durante toda la vida útil de una aplicación empresarial. Las capacidades mejoran, los precios cambian, aparecen nuevos proveedores, los modelos open-weight avanzan y el hardware se vuelve más eficiente.

Una aplicación construida demasiado cerca de un modelo específico puede convertir una simple decisión comercial en un proyecto de reingeniería de software.

Una arquitectura mejor separa la capacidad de negocio del sistema que la proporciona. La aplicación solicita una función: clasificar este documento, extraer estos campos, analizar este caso, generar esta respuesta. Una capa de routing u orquestación decide cómo satisfacerla.

Esa capa puede tomar en cuenta precio, latencia, seguridad, capacidad del modelo o incluso disponibilidad en tiempo real. Una solicitud rutinaria puede ir a un modelo económico. Una más difícil puede escalarse. La información sensible puede mantenerse dentro de infraestructura controlada. Una carga de alto volumen puede migrar a hardware dedicado una vez que su utilización sea suficientemente predecible.

La elección del modelo se convierte entonces en una decisión de routing y no en un compromiso arquitectónico permanente.

Es probable que esto termine siendo habitual. La IA empresarial será, probablemente, más heterogénea y no más estandarizada. Una compañía puede utilizar simultáneamente varios proveedores comerciales, distintos modelos open-weight y cierta infraestructura local, destinando cada alternativa a los workloads para los que tenga sentido económico y operativo.

Las empresas mejor preparadas para ese escenario conocerán tres cosas: cuánto cuestan realmente sus procesos habilitados por IA, qué partes de esos procesos requieren de verdad inteligencia costosa y con qué facilidad pueden mover sus cargas de trabajo cuando cambien la tecnología, los precios o la regulación.

Los tokens son solamente el mecanismo actual utilizado para medir consumo. El tema de gestión más importante es que la IA introduce un costo variable directamente dentro de los procesos de negocio.

Cuando las aplicaciones comienzan a consumir inteligencia de manera continua, ese consumo deja de ser un experimento. Se convierte en un recurso de producción y, como cualquier otro recurso de producción, debe ser diseñado, medido y optimizado.