Ahora la IA va de vatios, tokens y márgenes

Hasta hace poco, comparar los distintos LLMs en el mercado era básicamente mirar benchmarks: “este responde mejor”, “aquel razona peor”.

Hoy esa lectura se queda corta. La batalla se está decidiendo por costes y por infraestructura: quién puede servir tokens útiles a gran escala con coste por token competitivo (chips, energía, red, refrigeración) y convertirlo en producto sin que la cuenta de resultados reviente.

Este artículo va de eso: del stack físico que hay debajo, de por qué el margen ya no es “SaaS puro”, y de qué tipo de jugadores tienen ventaja cuando la limitación real no es creatividad, sino vatios y eficiencia.

De dónde venimos: el salto no fue solo técnico, fue de distribución

La IA moderna y la fiebre de los LLMs que conocemos hoy no despegó porque alguien encontrara una receta mágica de la noche a la mañana.

Despegó porque se alinearon tres piezas que, por separado, ya existían pero que por separado eran insuficientes:

1. una arquitectura que escala de forma predecible (transformers)
2. un enfoque industrial de entrenamiento (preentrenamiento masivo + post-entrenamiento para darle forma), y
3. (la que casi siempre se subestima) una distribución agresiva al usuario final.

Antes de 2022 ya había modelos potentes, papers brillantes y demos muy prometedoras. Lo que no había era una interfaz que convirtiera ese poder estadístico en un hábito diario.

Ese fue el “último kilómetro” que cambió el juego: cuando metes el modelo dentro de un producto sencillo, accesible, conversacional, tolerante a errores del usuario y útil desde el minuto uno, haces que la IA deje de ser una tecnología restringida a unos pocos y pase a ser mainstream.

ChatGPT fue ese punto de inflexión por dos razones muy concretas.

Demostró que la capa decisiva no era solo el modelo, sino la experiencia completa. No basta con que el sistema “sepa cosas”; tiene que ser fácil de usar, rápido, fiable, y capaz de manejar la ambigüedad humana sin romperse.

Elevó el estándar psicológico del mercado. Desde ese momento, el usuario medio dejó de comparar “IA vs no IA” y empezó a comparar “mi herramienta actual vs una herramienta que entiende lenguaje y me ahorra trabajo”.

A partir de ahí, el asunto se convirtió en un problema de operación a escala. Un modelo puede ser excelente en laboratorio, pero el mundo real te impone restricciones reales: latencia, picos de demanda, costes de inferencia, disponibilidad, degradación de calidad cuando optimizas, y un detalle clave: que cada interacción tiene coste variable.

Por eso la pregunta cambió. Antes ganaba quien entrenaba el modelo más capaz. Ahora se compite para seguir empujando la frontera técnica y, a la vez, construir una “fábrica” capaz de producir inferencia de manera estable.

Y la realidad es que en cuanto tienes millones de usuarios, la inferencia deja de ser un servicio cloud genérico y empieza a parecerse a un proceso industrial con cuellos de botella físicos (chips, memoria, red, energía) y métricas económicas (coste por token, coste por usuario activo, margen por producto).

Ese es el cambio estructural: la IA pasó de ser I+D con demos bonitas a ser I+D + producción industrial de tokens útiles, distribuida en productos que la gente usa todos los días. Y cuando una tecnología entra ahí, las ventajas cambian de naturaleza: no solo importa ser “más listo”, importa ser más eficiente, más escalable y más barato sirviendo inteligencia en condiciones reales.

Stack de cómputo y coste por token

El stack de cómputo es una cadena física muy concreta que va desde el silicio hasta la pantalla del usuario. En la base están las GPUs y aceleradores especializados. Sobre ellas, la red que las conecta, la memoria que alimenta los cálculos, las fuentes de alimentación que sostienen el consumo brutal de energía y los sistemas de refrigeración que evitan que todo eso se funda. Encima de todo ello vive el software que orquesta cientos de miles de chips como si fueran un solo cerebro distribuido, y por último las interfaces que convierten ese monstruo físico en algo utilizable por un humano.

Si una pieza de esa cadena falla o está mal dimensionada, el modelo más sofisticado del mundo se convierte en un experimento caro que no escala.

Sobre este stack se impone una variable que raramente aparece en las notas de prensa, pero manda: el coste por token.

Un token es un trozo de texto o información que el modelo procesa, y cada token implica ciclos de cómputo, movimiento de datos y electricidad. No es magia, es simplemente consumo físico.

Aquél que consigue generar tokens útiles quemando menos chips, menos energía y menos infraestructura adquiere una ventaja desproporcionada: puede bajar precios antes que nadie, soportar planes gratuitos más generosos y seguir ganando dinero donde otros apenas cubren costes.

Este punto conecta directamente con el concepto de margen. El software clásico ha vivido cómodo durante décadas porque vender una copia más de un programa tenía un coste marginal prácticamente cero, lo que sostenía márgenes brutos del 70–80 % en muchos SaaS.

La IA rompe esa lógica.

Cada respuesta requiere recomputar. Cada usuario intensivo tiene un coste directo que escala casi linealmente con su uso.

Para competir en esta liga, hay que aceptar que el negocio de IA va a tener márgenes brutos más bajos que el software tradicional, y aun así a los principales players no les queda más remedio que empujarlo. Aquí el margen es el precio de entrada: si no puedes asumirlo, no puedes jugar. Y si puedes asumirlo, compras escala, datos y distribución.

Entendiendo las leyes de escalado

Cuando hablamos de leyes de escalado hablamos de una regla práctica que permite convertir I+D en planificación industrial. Entrenar un modelo, al final, es minimizar una métrica muy concreta (la loss): cuánta “sorpresa” tiene el modelo cuando intenta predecir el siguiente token. Si la loss baja, el modelo está comprimiendo mejor el mundo en forma de probabilidades: entiende patrones, contexto, lenguaje, y cada vez se equivoca menos (en promedio) en su predicción.

Lo importante es que esa loss no mejora de forma caprichosa. Para una arquitectura y una receta de entrenamiento relativamente estables, la mejora suele seguir curvas bastante regulares: si multiplicas recursos por 10, no obtienes 10x de calidad, obtienes una mejora incremental bastante predecible. Por eso se llama “ley”: porque, con suficientes experimentos, deja de ser intuición y se vuelve ingeniería.

Y eso cambia el juego: ya no estás “probando a ver qué pasa”, estás decidiendo cuánto estás dispuesto a pagar por cada punto adicional de error que quieres reducir.

¿De qué depende esa curva? De tres palancas que están acopladas entre sí.

1. el tamaño del modelo, es decir, sus parámetros: la capacidad del sistema para representar funciones complejas. Un modelo más grande puede, en teoría, capturar más regularidades… pero solo si tiene con qué aprenderlas. Ahí entra la segunda palanca...
2. la cantidad de datos (tokens) y, más importante de lo que parece, su diversidad y calidad. Si el modelo es grande pero no le das suficientes tokens variados, no “se vuelve genio”; se vuelve caro y subentrenado: tiene capacidad que no aprovecha y tiende a aprender peor de lo que podría. Si, al revés, le das un océano de datos a un modelo demasiado pequeño, el modelo no tiene “anchura” para absorberlos: se queda corto y desaprovechas parte del esfuerzo.
3. la tercera es el cómputo, que en la práctica es el producto de las dos anteriores: cuántas operaciones haces para entrenar (cuántos pasos, cuántos tokens procesas, cuántas veces ajustas pesos). Por eso el escalado real no es “meto más GPUs y ya”: es “balanceo tamaño y datos para que cada dólar de compute baje la loss lo máximo posible”. Aquí aparece una idea clave, muy poco intuitiva para el público: con un presupuesto fijo de compute, no siempre gana el modelo más grande. Muchas veces, el óptimo es un modelo algo más pequeño entrenado con muchos más datos. Dicho en cristiano: hay modelos que salen mejores no por ser más enormes, sino por estar mejor alimentados.

Y ahora viene el matiz clave.

Estas leyes no te dicen “cuánto IQ” va a ganar el modelo. Te dicen algo más básico y más fiable: cuánto vas a mejorar la predicción media del siguiente token. Esa mejora suele correlacionar con rendimiento en muchas tareas… pero no captura todo. Hay comportamientos que aparecen cuando cruzas ciertos umbrales, hay mejoras que vienen por cambios de receta (post-entrenamiento, RL, herramientas, verificación), y hay saltos que no se explican solo con preentrenamiento.

Aun así, como brújula industrial, las leyes de escalado siguen mandando: ponen un precio aproximado a la calidad, y convierten la carrera de modelos en una cuestión de asignación óptima de recursos, no de magia.

Con esto claro, ya se entiende por qué el debate se desplaza: si la calidad “comprable” por unidad de compute es relativamente modelizable, entonces la ventaja decisiva pasa a ser quién tiene el compute, quién lo organiza mejor, y quién lo convierte en producto sin que se le incendie la economía.

Gemini 3 como experimento de hardware: el escalado clásico no está muerto

Las leyes de escalado siguen vivas, pero a veces parece que “se paran” no porque falla la IA… falla la forma de construirla a escala. No es que el modelo no pueda mejorar, es que el sistema que lo entrena deja de ser eficiente cuando lo haces gigante.

Piensa en entrenar un modelo como en coordinar una obra con miles de operarios. Si añades más gente pero no mejoras la logística, llega un punto en el que hay más gente esperando instrucciones que trabajando. Con los clústeres pasa algo parecido: puedes comprar muchas GPUs, pero si no están bien conectadas y bien coordinadas, una parte creciente del tiempo se pierde en “ponerse de acuerdo” y mover datos. Ese “impuesto de coordinación” hace que cada salto extra de tamaño cueste muchísimo más para mejorar muy poco. Y desde fuera eso se interpreta como: “la IA ya no escala”.

¿Entonces qué pinta Gemini 3 aquí?

No es “este modelo es el mejor”. Gemini 3 sirve como ejemplo de una idea: cuando un laboratorio consigue un salto visible en un momento en el que muchos asumían rendimientos decrecientes, normalmente no es porque hayan encontrado una pócima mágica, sino porque han mejorado la fábrica (hardware + infraestructura + software de entrenamiento).

Es decir: han conseguido que el compute que ya estaban pagando se convierta en más “trabajo útil”, con menos pérdidas.

Dicho más llano: Gemini 3 aquí es un caso práctico de que el cuello de botella no era la teoría del escalado, sino la ejecución industrial.

Cambias la plataforma (mejor arquitectura de aceleradores, mejor interconexión, mejor eficiencia), y el motor clásico vuelve a empujar: metes más compute y la calidad sube de forma más “limpia”.

Y esto conecta con nuestra idea original. Ya no basta con “tener un modelo bueno”. La frontera real es producir inteligencia útil a escala sin que el coste se dispare. Por eso hablamos de “física y contabilidad”: porque si tu fábrica desperdicia recursos, tu coste por token sube y tu ventaja competitiva se derrite, aunque tu modelo sea excelente en una demo.

El segundo motor: reasoning y post-entrenamiento

Si todo el progreso reciente dependiera únicamente del motor clásico del pre-entrenamiento (más parámetros, más datos, más cómputo), 2024 y buena parte de 2025 habrían sido años planos. El hardware dominante estaba al límite, y la ley de escalado nos decía que ganar un poco más de calidad implicaba gastar muchísimo más dinero para muy poco retorno adicional.

Y, sin embargo, la experiencia del usuario sí mejoró, y mucho. Los modelos han pasado de ser buenos conversadores a comportarse más como asistentes que pueden razonar, descomponer problemas, seguir hilos largos, escribir código complejo y mantener sesiones extensas sin desintegrarse. Si el motor viejo estaba temporalmente agotado, tiene que haber aparecido un segundo motor en paralelo.

Ese motor es el reasoning y todo lo que ocurre en el post-entrenamiento. Y dentro de él dos ideas clave:

1. enseñar a razonar mejor
2. ser muy selectivo con el gasto de cómputo.

La forma más útil de entenderlo es separar dos fases:

En el preentrenamiento, el modelo aprende el mundo “por exposición”: lee muchísimo texto y aprende patrones. Es como un estudiante que ha leído bibliotecas enteras. Sabe mucho, pero no necesariamente sabe cómo usarlo para resolver un problema paso a paso, ni cómo comprobarse.

En el post-entrenamiento, el modelo aprende “a comportarse”: aprende a seguir instrucciones, a priorizar, a ser consistente, a no inventarse cosas cuando puede verificar, y a resolver tareas de forma más fiable. Es como pasar de “saber teoría” a “aprender a hacer exámenes” y, más importante aún, a trabajar.

Con software tradicional automatizas lo que puedes especificar; con IA automatizas lo que puedes verificar. Traducido: en el software clásico tú le dices al sistema exactamente qué pasos ejecutar. En IA, muchas veces no puedes escribir los pasos… pero sí puedes definir qué significa “esto está bien” y qué significa “esto está mal”. Y eso abre una puerta enorme.

Palanca 1: recompensas verificables (cuando el modelo aprende porque puede comprobar si acertó)

Durante mucho tiempo, gran parte del ajuste fino dependía de humanos diciendo “esta respuesta me gusta más que esta otra”. Funciona, pero tiene dos límites: es caro y es subjetivo. En cambio, en muchas tareas reales puedes construir un verificador. No un humano. Una regla o un test.

Ejemplos sencillos: “¿el resultado de la suma es correcto?”, “¿el código compila y pasa tests?”, “¿la consulta a la base de datos devuelve lo que debía?”, “¿la reserva existe de verdad?”, “¿la respuesta cumple un formato?”. Cuando puedes verificar, puedes entrenar a escala, iterando millones de veces: intento → chequeo → premio/castigo → ajuste.

Esto no convierte al modelo en una calculadora perfecta, pero sí cambia su comportamiento: aprende a ser menos impulsivo, a no dar la primera respuesta que “suena bien”, y a buscar consistencia porque sabe que será evaluado.

Palanca 2: test-time compute (dejarle “pensar más” cuando el problema lo exige)

La segunda palanca es aún más intuitiva: hay preguntas que se resuelven en un segundo y preguntas que requieren parar, probar, descartar y revisar.

Los modelos antiguos trataban casi todo como “una pasada y ya”: generaban una respuesta rápida y listo.

El salto reciente vino de aceptar lo obvio: para algunos problemas es mejor gastar más cómputo en el momento de uso. Es decir, permitir que el modelo “piense más tiempo” durante la inferencia. Eso puede significar que el modelo explore varias rutas, haga comprobaciones, compare alternativas, o use herramientas externas. Desde fuera solo ves que tarda un poco más. Por dentro, lo importante es que reduce errores porque no apuesta todo a una única tirada.

Y esto conecta directamente con el tema central del artículo: el coste por token y el coste por respuesta útil. El reasoning y el test-time compute mejoran calidad, sí… pero también consumen más. Por eso la ventaja competitiva no es solo “qué tan bien razonas”, sino “cuánto te cuesta razonar así y si tu economía lo soporta”.

Volvemos de nuevo a la misma tesis: física y contabilidad.

El coste por token como arma competitiva

Como estamos viendo, el salto reciente no es solo “modelo más listo”, sino modelo que aguanta el mundo real: millones de usuarios, latencia decente y una cuenta de resultados que no explota.

Aquí entra una variable que es decisiva: coste por token.

En el software clásico, servir un usuario más cuesta casi cero. En IA no. Cada respuesta quema cómputo, mueve datos, consume energía y ocupa capacidad de data center. Si además añades reasoning y test-time compute (como comentábamos), la calidad sube… pero también el coste. Por eso la pregunta deja de ser “quién responde mejor” y pasa a ser “quién puede permitirse responder mejor, a escala”.

El margen no es infinito ni tiende a cero.

Durante esta fase, Google ha disfrutado de una ventana importante como productor de tokens especialmente barato gracias a la combinación de sus TPUs, una infraestructura muy optimizada y una escala colosal de uso.

Y aquí está lo estratégico: el low-cost producer puede convertir física en producto. No necesita ganar el benchmark; necesita ganar el coste unitario. Porque, en IA, cada token regalado le duele mucho más al que fabrica caro que al que fabrica barato.

Blackwell y el GB300: cuando el data center se convierte en planta industrial

Todo esto ocurre justo antes de la llegada de Blackwell de NVIDIA… que no es una simple iteración incremental de GPU. Con Hopper ya estábamos en el límite razonable de densidad y consumo. Blackwell cruza otra frontera.

Blackwell no trae “un poquito más” de potencia, sino que empuja el sistema a un régimen distinto: el data center deja de sentirse como “IT grande” y empieza a parecerse a una planta industrial.

Como ya hemos dicho, a estas alturas la pregunta no es quién “parece” más listo en las demos, sino quién puede producir inteligencia útil a escala sin que la física y la cuenta de resultados le exploten en la cara.

Y justo ahí es donde Blackwell pone el foco. Con Blackwell, el rendimiento por rack sube, pero también suben de golpe las exigencias de potencia, disipación de calor y fiabilidad operativa. Volvemos al mismo campo de batalla: no se compite solo comprando GPUs... se compite construyendo y operando infraestructura capaz de alimentarlas y enfriarlas sin perder eficiencia.

Esto conecta directamente con el hilo conductor del artículo: el coste por token. Si la IA es un negocio donde cada respuesta cuesta electricidad, chips y capacidad de centro de datos, entonces la ventaja real es convertir cada megavatio en el máximo de “tokens útiles”.

Blackwell, bien desplegado, es una palanca para eso: más trabajo útil por unidad de energía y por euro de infraestructura ya amortizada. Y aquí aparece el matiz estratégico: el ganador no será solo quien tenga acceso al chip, sino quien tenga el “stack” completo para explotarlo —edificios preparados, refrigeración líquida, acuerdos de energía, red, software de orquestación y disciplina de operación. En otras palabras, Blackwell no es solo hardware nuevo; es un filtro.

Obliga a la industria a admitir lo que ya veníamos insinuando: la frontera de IA se está decidiendo en ejecución industrial, no en titulares.

Quién está de verdad en la frontera (y por qué son tan pocos)

Si quitamos el ruido y miramos la realidad operativa, “estar en la frontera” no significa ganar un benchmark. Significa algo más incómodo: ser capaz de empujar varias cosas a la vez —capacidad pura, fiabilidad, razonamiento, multimodalidad, coste/latencia y despliegue a escala— sin que el sistema se rompa cuando lo usa el mundo real. La frontera, hoy, es tanto laboratorio como fábrica.

Con esa definición, los nombres que se repiten con más consistencia suelen ser pocos: OpenAI, Google/DeepMind (Gemini), Anthropic y xAI. No porque el resto sea irrelevante o “malo” —hay actores excelentes construyendo modelos y productos muy útiles— sino porque mantener el ritmo de frontera exige una combinación rara de ingredientes que no se compra solo con talonario.

El primer ingrediente es el que más se malinterpreta: no es “tener GPUs”, es “saber exprimirlas”. Puedes gastar miles de millones y aun así entrenar peor que otro con menos hardware si tu “stack” está mal afinado. Entrenar un modelo grande no es poner chips en una habitación y darle a “start”. Es coordinar decenas de miles de aceleradores como si fuesen un solo organismo: que los datos lleguen a tiempo, que la red interna no ahogue el flujo, que la memoria no sea el cuello de botella, que los fallos inevitables (un nodo que cae, un enlace que degrada, una máquina que se calienta) no te tiren semanas de trabajo. Aquí aparece una diferencia brutal que desde fuera no se ve: utilización efectiva. Dos compañías pueden “tener” el mismo clúster en un slide. Una lo convierte en progreso real la mayor parte del tiempo; la otra pasa media vida apagando fuegos, reintentando jobs y perdiendo rendimiento por latencia, desincronización o inestabilidad.

Ese punto conecta directamente con lo que ya veníamos diciendo en el artículo: la frontera ya no se decide solo por “genialidad de investigación”, sino por ingeniería industrial. La pregunta práctica es: ¿cuánto de tu energía y tu silicio acaba convertido en entrenamiento útil? Porque si no conviertes megavatios en gradientes con eficiencia, tu ventaja en hardware es un espejismo caro.

El segundo ingrediente es la cadena de datos, y aquí también hay mucha fantasía. “Más datos” no es “mejor”. A gran escala, la calidad se decide por la mezcla: qué entra, qué se filtra, cómo se deduplica, cómo se balancea por dominios, cuánto código metes, cuánto texto conversacional, cuánto material técnico, cuánto ruido toleras y cuánto veneno estás alimentando sin querer. En la práctica, la diferencia entre un modelo “muy listo pero raro” y uno “muy útil y fiable” suele ser menos el tamaño y más la receta: limpieza, ponderaciones, currículum de entrenamiento, y sobre todo el post-entrenamiento (preferencias, seguridad, estilo, capacidad de seguir instrucciones sin volverse frágil). Eso es trabajo de artesanía a escala industrial. Y cuando lo haces mal, lo pagas con alucinaciones, inconsistencia y comportamientos que parecen magia un día y desastre al siguiente.

El tercer ingrediente es el más humano y el menos copiables: criterio para experimentar. Cada experimento serio cuesta tiempo, dinero y capacidad de cómputo que podrías estar usando en otra cosa. No puedes probarlo todo. Así que el “gusto” —qué hipótesis merece un run grande, qué señal de mejora es real y cuál es overfitting a tu evaluación, qué cambio de datos arregla un problema sin romper tres— se convierte en ventaja compuesta. Esto no se compra fichando dos estrellas. Se construye encadenando generaciones: fallar, medir, entender por qué fallaste, y codificar ese aprendizaje en tooling interno y procesos. Con los años, eso se vuelve un activo invisible: pipelines, métricas propias, baterías de evaluación, y un modo de trabajar que convierte compute en progreso con menos desperdicio.

El cuarto ingrediente es el que cierra el círculo: distribución y feedback real. Los labs que despliegan productos masivos no solo “sirven respuestas”; generan un flujo continuo de señales del mundo real: dónde el modelo se equivoca, qué tareas importan de verdad, qué comportamientos son útiles y cuáles son puro circo. Ese feedback, cuando se convierte en entrenamiento (con verificadores, con evaluación automática, con iteración de prompts/sistemas, con refuerzo y ajustes finos), acelera el aprendizaje. Y aquí hay una asimetría que la gente subestima: quien tiene tráfico aprende más rápido, y quien aprende más rápido mejora el producto, y quien mejora el producto atrae más tráfico. Es un círculo virtuoso bastante despiadado.

Ahora, ¿por qué esto deja fuera a empresas enormes que “podrían” estar ahí? Porque para entrar en frontera necesitas acertar simultáneamente en varias capas: hardware, redes, sistemas, datos, entrenamiento, post-entrenamiento, evaluación, producto y operación. Si fallas en una, el resto no compensa. Puedes tener el mejor equipo de investigación y aun así estar limitado por una infraestructura que no escala. Puedes tener un clúster gigante y desperdiciarlo con un stack inmaduro. Puedes clavar el preentrenamiento y arruinarlo en post-entrenamiento por falta de señal o mal diseño de objetivos. La frontera no perdona los cuellos de botella.

Y aquí viene el matiz importante, para que el lector no se lleve una conclusión equivocada: “no estar en frontera” no significa “no tener un negocio ganador”. Muchísimos productos de IA serán enormes usando modelos que no sean #1. De hecho, la mayoría del valor se capturará en integración, verticales, datos propios, workflow y distribución. Pero si la pregunta concreta es quién está empujando el límite de capacidad general de forma recurrente, los que pueden permitirse —y ejecutar— esa combinación de laboratorio + fábrica suelen ser pocos.

La forma útil de leer esto, como inversor o como operador, no es enamorarse de una demo. Es vigilar los indicadores de realidad: velocidad de iteración, calidad del stack, disciplina de datos, capacidad de desplegar a escala sin incendiar costes, y consistencia de progreso generación tras generación. Porque en esta fase, la frontera no la gana “el modelo más listo en Twitter”. La gana quien convierte física en producto, sin perder la cabeza ni la cuenta de resultados.

Conclusión: física, estructura económica y coraje estratégico

Mirado con ojos de inversor, el relato de la IA es menos glamuroso que las keynotes, pero mucho más útil.

La IA ha dejado de ser una historia de demos espectaculares y benchmarks en redes sociales: es una historia de física, capex y decisiones de margen que pueden marcar la vida o muerte de empresas enteras. Quien se equivoca eligiendo arquitectura, desplegando Blackwell o sus equivalentes, negociando energía o decidiendo si acepta o no márgenes distintos en su negocio de IA, no está perdiendo un trimestre; está entregando años de ventaja compuesta.

La verdadera ventaja no se construye en el nivel del prompt que ve el usuario, sino muchos estratos por debajo: en la eficiencia del clúster, en la calidad del pipeline de datos, en el checkpoint interno disponible hoy para entrenar el siguiente modelo, en cuántos tokens útiles se obtienen por vatio y por dólar frente a la competencia. A estas alturas, la pregunta relevante ya no es si la IA va a generar ROI, porque los ejemplos cuantitativos de mejora en ingresos, reducción de costes o ambos a la vez ya existen. El debate serio es quién se está posicionando para capturar ese retorno de forma sostenible y quién está renunciando a él por miedo a empeorar un par de ratios contables.

Los próximos años no van a premiar a quien tenga la demo más vistosa, sino a quien entienda que este ciclo va de física y estructura económica: de transformar energía, silicio y datos en tokens útiles al menor coste posible y de tener el coraje de reescribir la propia cuenta de resultados para seguir siendo relevante en un mundo donde la interfaz por defecto ya no será un menú, sino un agente inteligente sentado entre el usuario y todo lo demás.