En el último post conté el método que uso para decidir dónde aplicar IA y dónde no. Hoy toca la parte que casi nadie explica bien y que, tarde o temprano, acaba encima de la mesa de cualquier comité: cuánto cuesta esto de verdad. Porque la IA no se compra una vez, como una licencia. Se consume, como la gasolina. Y quien no entienda eso va a llevarse sustos en la factura.
Qué es un token (y por qué te importa)
Un token es la unidad en la que un modelo de lenguaje trocea el texto: más o menos, un trozo de palabra. Esta frase que estás leyendo son unos veinte tokens. Cada vez que le pides algo a un modelo en la nube, pagas por los tokens que entran (tu pregunta, tus documentos, el contexto) y por los que salen (la respuesta). Nada más, y nada menos.
La consecuencia es directa: el coste de la IA escala con el uso. Un piloto con diez personas cuesta calderilla. Ese mismo caso desplegado a toda la plantilla, procesando documentos largos cada día, es otra película. Y aquí está la trampa habitual: los pilotos se aprueban mirando el precio del piloto, no el precio del despliegue. Luego la adopción funciona —que era el objetivo— y la factura crece justo por haber tenido éxito. Es el único proyecto de IT que conozco donde el éxito te sube el coste variable.
Por eso digo que los tokens son el nuevo petróleo: no porque valgan oro, sino porque son un consumible que alimenta el motor, con su precio fluctuante, sus proveedores dominantes y su dependencia estratégica. Y como con el petróleo, la pregunta inteligente no es «¿cuánto cuesta el litro?», sino «¿cuánto consume mi coche y cuántos kilómetros hago?».
Las tres formas de pagar la factura
Toda empresa que escala IA acaba delante de la misma decisión, con tres caminos posibles.
100% nube. Pagas por token a un proveedor (Anthropic, OpenAI, Google…). Ventajas evidentes: cero mantenimiento, siempre la última generación de modelos, empiezas mañana. Inconvenientes menos evidentes: el coste crece linealmente con el uso y no tiene techo, tus datos viajan a un tercero, y no controlas ni el precio ni la disponibilidad. Si mañana tu proveedor sube tarifas o deprecia el modelo que usas, te toca bailar al son que marquen.
100% local. Compras hardware, despliegas modelos abiertos en tu casa, y cada token pasa a costarte cero (bueno, electricidad y amortización). Los datos no salen nunca de tu infraestructura, que para según qué información no es un capricho, es un requisito. El peaje: inversión inicial seria, modelos algo por detrás de los punteros de nube, y necesitas equipo que sepa mantener esto vivo. Es cambiar coste variable por coste fijo más talento.
Híbrido. Lo crítico y lo sensible en casa; lo creativo, lo puntual y lo no sensible en la nube. Es la opción que defiendo casi siempre, porque replica algo que en IT llevamos décadas haciendo con la propia nube: no es todo o nada, es cada carga de trabajo donde le conviene. La productividad general de la plantilla va perfecta contra la nube; el proceso que toca dato de cliente o margen, mejor donde tú mandas.
No todos los motores gastan lo mismo
El segundo error de la factura es usar el modelo grande para todo. Es como hacer los recados del barrio en un camión de 40 toneladas: llegar, llegas, pero a qué precio.
Los modelos grandes son para razonamiento exigente: análisis complejos, redacción cuidada, decisiones con matices. Los modelos pequeños hacen tareas acotadas —clasificar un correo, extraer campos de una factura, etiquetar un ticket— igual de bien, muchísimo más rápido y por una fracción del coste; hablamos de diferencias de un orden de magnitud o más por token. Y los modelos especializados, entrenados para una sola cosa (prever demanda, leer albaranes), suelen ganar a todos en su terreno.
La arquitectura sensata casi nunca es «elegimos Claude o elegimos GPT». Es un enrutador con criterio: cada petición al modelo más barato que la resuelva bien, y el grande solo cuando de verdad hace falta. Ese ajuste, en un despliegue serio, puede recortar la factura a la mitad sin que nadie note diferencia en la calidad.
Cómo no llevarte sustos
Cuatro prácticas que me han funcionado para mantener esto bajo control:
Presupuesta el despliegue, no el piloto. Antes de aprobar un caso de uso, estima el consumo a plena adopción: usuarios × peticiones/día × tokens por petición. Es una multiplicación de servilleta y te ahorra la conversación incómoda de dentro de un año.
Mide el consumo por caso de uso desde el día uno. Igual que no aceptarías una factura eléctrica sin contador, no aceptes una factura de IA sin saber qué proceso consume qué. Sin esa trazabilidad no puedes optimizar ni defender el gasto.
Pon el coste al lado del retorno. Un caso que consume mucho pero ahorra veinte veces su coste es un caso magnífico. Uno baratísimo que no ahorra nada es caro. El token no es el problema; el problema es el token que no devuelve valor.
Diseña para poder cambiar de proveedor. El lock-in en IA es real: precios que cambian, modelos que se deprecian, condiciones que se endurecen. Si tu arquitectura permite sustituir el modelo de debajo sin reescribirlo todo, negocias desde otra posición.
En resumen
La IA se paga por uso, y eso cambia cómo hay que pensarla: menos «qué herramienta compro» y más «qué consumo asumo, dónde lo ejecuto y qué me devuelve». Nube para arrancar y para lo no sensible, local para el dato que no puede salir, híbrido como destino natural, y el modelo adecuado —no el más grande— para cada tarea.
El petróleo hizo ricas a las empresas que aprendieron a refinarlo y a consumirlo con cabeza, no a las que más quemaban. Con los tokens va a pasar exactamente lo mismo.
Lo difícil se hace, lo imposible se intenta. Pero conviene saber cuánto cuesta el intento.
Joan Garcia Camba es CIO de retail internacional en Barcelona. Ingeniero y MBA, escribe sobre tecnología, gestión y equipos desde 2008. Su perfil profesional completo está en joan.si.
