La monetización de la inteligencia artificial está entrando en una fase incómoda. Después de una primera etapa dominada por suscripciones aparentemente simples, “paga una cuota mensual y usa el servicio”, muchos proveedores están migrando hacia modelos de pago por uso basados en créditos, tokens, peticiones premium o combinaciones opacas de todos ellos. La lógica empresarial es comprensible: ejecutar modelos avanzados cuesta dinero, especialmente cuando intervienen razonamiento extendido, contexto largo, agentes autónomos, búsqueda web, generación de código o procesamiento multimodal. Pero que el coste exista no implica que el modelo de precios sea claro, predecible ni justo para el usuario.
El problema central es que el token se está convirtiendo en la unidad económica de la IA, pero no es una unidad cognitivamente comprensible para la mayoría de los usuarios. OpenAI explica en su documentación que los tokens son fragmentos de texto que los modelos procesan: pueden ser caracteres, partes de palabras, palabras completas, espacios o signos de puntuación; como regla aproximada, en inglés un token equivale a unos cuatro caracteres o a tres cuartos de palabra. Esta definición tiene sentido desde el punto de vista técnico, pero resulta problemática desde el punto de vista comercial, pues nadie piensa una tarea en tokens. Un usuario no se pregunta “¿cuántos tokens consumirá esta consulta?”, sino “¿cuánto me costará resumir este informe?”, “¿cuánto gasto si genero diez propuestas comerciales?” o “¿cuánto me va a costar mantener un asistente para mi equipo?”.
La dificultad aumenta porque el consumo final no depende solo de lo que escribe el usuario. Depende también del modelo elegido, de la longitud del contexto, de los documentos adjuntos, de la respuesta generada, de los mensajes previos, de los tokens cacheados, de las herramientas activadas, del razonamiento interno, de las llamadas a agentes y de los reintentos. En consecuencia, el precio real de una interacción solo se conoce con precisión después de haberla consumido. Esta asimetría convierte el modelo en una forma de facturación ex post: el usuario acepta una operación sin conocer de antemano su coste efectivo, lo cual me lleva a pensar en si este tipo de monetización es acorde a la normativa de la UE.
Los precios oficiales muestran hasta qué punto la unidad de facturación se ha sofisticado. OpenAI publica tarifas por millón de tokens que distinguen entre entrada, entrada cacheada y salida; en su página de precios de API se observan importes distintos según modelo, longitud de contexto y tipo de token (OpenAI API Pricing). Anthropic sigue una lógica similar con Claude: su documentación diferencia entre tokens de entrada, escritura de caché, lectura de caché y tokens de salida (Claude API Pricing). Google también estructura Gemini API por millón de tokens, con precios diferenciados según modalidad —texto, imagen, vídeo, audio, salida, caché o uso de herramientas como búsqueda— (Gemini API Pricing).
Esto puede ser defendible desde la contabilidad interna del proveedor, pero no necesariamente desde la experiencia de cliente. La factura se vuelve técnicamente precisa, pero comercialmente confusa. La paradoja es evidente, ya que cuanto más exacto es el sistema para medir el coste computacional, menos intuitivo resulta para quien lo paga. Es algo parecido a las facturas de la luz o el gas.
El caso de GitHub Copilot ilustra bien esta transición. GitHub anunció que Copilot pasaría a un modelo de facturación basado en uso. En lugar de contar “premium requests”, cada plan incluye una asignación mensual de “GitHub AI Credits”, y el consumo se calcula según tokens de entrada, salida y caché, aplicando las tarifas API de cada modelo. Su documentación indica además que cada token se valora según el modelo utilizado y que el total se convierte en créditos, con una equivalencia de 1 crédito de IA = 0,01 dólares (GitHub Docs). La reacción de los usuarios ha sido furibunda. Business Insider informó de que algunos usuarios de Copilot estaban consumiendo sus créditos mensuales en pocos días y anticipaban costes de varios cientos de dólares bajo el nuevo esquema. Tom’s Hardware recogió críticas de clientes que denunciaban incrementos de hasta 100 veces y señalaban que el sistema resultaba especialmente difícil de estimar cuando intervenían modelos avanzados o agentes de larga duración. En España, El País sintetizó el cambio como el final de la “barra libre” de la IA y subrayó que quien controla el precio del token controla, en la práctica, las condiciones económicas de uso.
Conviene evitar una lectura simplista. No todo modelo de pago por uso es abusivo. En muchos contextos, puede ser más justo que una tarifa plana: quien consume poco paga poco, y quien ejecuta flujos intensivos soporta una parte mayor del coste. De hecho, el modelo de suscripción ilimitada tiene un problema estructural en IA generativa, ya que unos pocos usuarios intensivos pueden hacer inviable el servicio para el conjunto. Business Insider ha descrito este fenómeno como el de los inference whales: usuarios cuyo uso intensivo genera costes de inferencia muy superiores a lo que pagan en suscripciones planas, obligando a proveedores como Anthropic a introducir límites y esquemas más ligados al uso.
El problema, por tanto, no es pagar por uso. El problema es pagar por una unidad que el usuario no puede anticipar ni traducir fácilmente a valor económico. Una cosa es que una empresa cobre por consumo; otra muy distinta es que el consumidor no pueda saber razonablemente cuánto costará una operación antes de realizarla. En términos de transparencia comercial, el token se parece menos al kilovatio hora —una unidad regulada, medible y comparable— y más a una moneda virtual cuyo valor práctico depende de una conversión que el usuario no domina.
Desde la perspectiva empresarial, el riesgo tampoco es menor. Muchas organizaciones están incorporando IA en procesos comerciales, desarrollo de software, atención al cliente, análisis documental, marketing de contenidos, inteligencia competitiva o automatización interna. Si el coste unitario de esas operaciones fluctúa por modelo, longitud del contexto, herramientas activadas o comportamiento del agente, la presupuestación se complica. Un flujo aparentemente barato en una prueba piloto puede volverse caro cuando escala a miles de usuarios, documentos o interacciones. El problema se agrava con los agentes autónomos: no solo responden, sino que iteran, consultan herramientas, reescriben, verifican, ejecutan y vuelven a consultar. Cada paso añade consumo.
Los casos extremos funcionan como advertencia. Tom’s Hardware informó del caso de OpenClaw, un proyecto que habría consumido 1,3 millones de dólares en tokens de OpenAI en un mes, con cientos de miles de millones de tokens y millones de peticiones asociadas a agentes de codificación. No es un caso representativo para un usuario medio, pero sí revela la naturaleza económica del problema. Cuando la IA se despliega de forma agentiva y a gran escala, el coste deja de parecerse al software tradicional y se aproxima al consumo variable de infraestructura.
La transparencia debería avanzar en tres niveles
Primero, transparencia antes de la petición. Antes de ejecutar una tarea, el sistema debería ofrecer una estimación comprensible del coste: “esta operación costará aproximadamente entre 0,08 y 0,15 euros”, “consumirá entre el 3 % y el 5 % de tu cuota mensual” o “este agente puede consumir hasta X créditos si se completa el flujo”. No basta con mostrar una tabla abstracta de dólares por millón de tokens. El usuario necesita una traducción operacional: coste por resumen, por documento, por imagen, por conversación, por tarea de programación o por ejecución de agente.
Segundo, transparencia durante el uso. Las plataformas deberían mostrar un contador en tiempo real o casi real, especialmente en tareas largas: créditos consumidos, coste estimado acumulado, coste máximo autorizado y motivo del consumo. Si el incremento se debe a contexto largo, modelo premium, razonamiento extendido, búsqueda web o llamadas a herramientas, debe indicarse. La información no puede aparecer solo en un panel de facturación posterior.
Tercero, control presupuestario efectivo. Todo sistema de IA de pago por uso debería incluir límites duros por defecto, alertas configurables, presupuestos por usuario, por proyecto y por equipo, bloqueo automático de sobrecostes y degradación voluntaria a modelos más baratos. GitHub, por ejemplo, dispone de documentación para seguir y gestionar el gasto en Copilot, pero la controversia demuestra que la existencia de controles no basta si la unidad económica sigue siendo difícil de anticipar (GitHub Docs).
Para usuarios particulares, las recomendaciones son claras. Conviene activar límites de gasto siempre que existan, evitar dejar agentes funcionando sin supervisión, usar modelos avanzados solo cuando aporten valor diferencial, fragmentar tareas largas, revisar el coste de los archivos adjuntos y desconfiar de cualquier sistema que venda “créditos” sin mostrar su equivalencia práctica en euros por tarea. Si una plataforma no permite prever el coste aproximado de una operación, debería tratarse como un servicio de riesgo presupuestario.
Para empresas, la IA debe gestionarse como una categoría de gasto tecnológico variable, no como una suscripción SaaS convencional. Esto implica políticas internas de uso por tipo de tarea, selección de modelos según criticidad, medición de coste por proceso, cuadros de mando FinOps para IA, límites por unidad organizativa, auditorías de prompts y evaluación periódica del retorno. No todas las tareas justifican el modelo más potente; no todos los empleados necesitan el mismo nivel de acceso; no toda automatización reduce costes.
Para los proveedores, la sostenibilidad exige abandonar la comodidad de la opacidad. Un sistema razonable debería incorporar, como mínimo, cinco prácticas: mostrar siempre el precio equivalente en moneda real; ofrecer estimaciones previas por tarea; establecer límites duros por defecto; explicar qué elementos han generado el coste; y permitir comparaciones simples entre modelos, calidades y velocidades. La transparencia no es enemiga de la rentabilidad. Al contrario: sin confianza en la facturación, la adopción se frenará.
La IA generativa no puede vivir eternamente de subsidios ni de tarifas planas irreales. Pero tampoco debería construir su rentabilidad sobre unidades de consumo que el usuario no entiende. El pago por uso puede ser eficiente, incluso justo, si se convierte en un sistema auditable, predecible y traducible a valor. Si no, los créditos y tokens corren el riesgo de convertirse en la nueva letra pequeña de la economía digital: técnicamente exacta, comercialmente confusa y socialmente difícil de defender.
Deja una respuesta