Burbuja de IA: la apuesta de Larry Ellison

La burbuja de IA no se entiende solamente mirando los modelos, las aplicaciones o la velocidad de adopción. También hay que observar quién está financiando la infraestructura, cuánto tarda en llegar el retorno y qué ocurre si la demanda esperada no crece al ritmo de las inversiones.

La apuesta de Larry Ellison, fundador de Oracle, sirve como caso para analizar esa tensión. Según el documento de referencia, Ellison decidió acelerar la transformación de Oracle para convertirla en un actor relevante de la infraestructura que necesitan los sistemas de inteligencia artificial. La estrategia puede ser una visión de futuro, pero también expone los riesgos de crecer con deuda, contratos concentrados y expectativas difíciles de sostener.

El punto de partida: la IA necesita infraestructura

Cuando una empresa habla de inteligencia artificial a gran escala, suele concentrarse en la calidad del modelo. Sin embargo, detrás de cada servicio hay una base física y financiera: centros de datos, servidores, chips especializados, conectividad, energía y sistemas de refrigeración.

La inteligencia artificial generativa hizo visible esa necesidad de cómputo. Después del lanzamiento de ChatGPT, en noviembre de 2022, la tecnología dejó de ser percibida como un asunto limitado a laboratorios y pasó a convertirse en una carrera comercial y geopolítica. Para compañías como Oracle, el cambio representó una oportunidad para vender capacidad de nube, pero también una amenaza: quedar fuera de una transformación capaz de modificar el negocio del software empresarial.

El documento describe que Oracle ya venía invirtiendo en su nube y que la expansión de la IA aceleró esa estrategia. El desafío era competir con empresas de mayor escala, como Alphabet, Amazon y Microsoft. Para hacerlo, necesitaba construir rápido. Y construir rápido requiere comprometer grandes volúmenes de capital antes de que aparezcan los ingresos.

Project Stargate y la lógica de apostar primero

El 21 de enero de 2025, Ellison apareció en la Casa Blanca junto a Donald Trump y Sam Altman, de OpenAI, durante el anuncio de Project Stargate. Según el material analizado, el proyecto contemplaba inversiones de hasta 500.000 millones de dólares en cuatro años para desarrollar enormes centros de datos.

Más allá de la cifra, el anuncio muestra la escala que empezó a asociarse con la IA. Ya no se trata únicamente de desarrollar una herramienta digital, sino de desplegar una infraestructura comparable, por su consumo de recursos, con la de industrias enteras. Los centros de datos requieren electricidad, agua, redes y permisos. También generan tensiones con comunidades, reguladores y gobiernos.

Para los líderes de negocio, este punto deja una enseñanza concreta: una estrategia de IA no se ejecuta en el vacío. Depende de proveedores, costos operativos, disponibilidad tecnológica, regulaciones y capacidad de financiar el período que separa la inversión del retorno.

La hipótesis del escalado y el riesgo financiero

Una de las ideas que sostiene la carrera por la infraestructura es la llamada scaling hypothesis, o hipótesis del escalado. En términos simples, plantea que al aumentar de manera significativa el cómputo y los datos, los modelos pueden mejorar de forma relevante. La expectativa más ambiciosa es llegar a sistemas con capacidades generales cada vez más amplias.

En el plano empresarial, esa hipótesis se transforma en una carrera por el gasto de capital. Si más cómputo produce mejores modelos y los mejores modelos atraen más usuarios, quien construya primero podría capturar una parte importante de la economía de la IA.

El problema aparece cuando la lógica tecnológica se encuentra con la lógica financiera. Los costos de los centros de datos, los chips, la energía y el mantenimiento llegan antes que los ingresos esperados. Si los grandes contratos empiezan a cobrarse varios años después, la empresa debe sostener durante mucho tiempo una estructura de deuda y obligaciones.

Por eso, la pregunta relevante no es solamente cuánto puede crecer la demanda, sino también cuánto tiempo puede financiarse ese crecimiento. Una proyección tecnológica atractiva no reemplaza la necesidad de contar con clientes capaces de pagar, contratos sostenibles y un flujo de caja compatible con las inversiones.

Geopolítica, regulación y recursos físicos

La expansión de la IA también se convirtió en un asunto de política pública. El documento señala que durante la administración de Joe Biden existía una preocupación por limitar el acceso de China y de algunos países del Golfo a capacidad de cómputo de origen estadounidense. En paralelo, Oracle buscaba expandirse en otros mercados y mantener vínculos comerciales relevantes.

Con el cambio de administración en Estados Unidos, el marco político y tecnológico se reconfiguró. El texto describe un escenario con menos restricciones para algunas iniciativas y una posición más favorable para la expansión de Oracle y sus acuerdos.

Este componente geopolítico modifica la evaluación de cualquier proyecto de IA. Una empresa puede tener la demanda, el capital y la tecnología, pero enfrentar límites regulatorios para operar en determinados territorios. También puede depender de redes eléctricas que necesitan ampliaciones, de permisos ambientales o de comunidades que cuestionan el uso intensivo de agua y energía.

La infraestructura es poder, pero también dependencia. Cada cuello de botella puede convertirse en un problema de costos, disponibilidad o legitimidad social.

Cuando la euforia choca con la deuda

El documento describe un momento de fuerte entusiasmo alrededor de Oracle. En septiembre, según el texto, la compañía informó un crecimiento importante de sus obligaciones de desempeño pendientes: contratos firmados que todavía no habían sido reconocidos como ventas. También menciona un acuerdo con OpenAI por aproximadamente 300.000 millones de dólares en varios años, con pagos que comenzarían en 2027.

El mercado reaccionó con optimismo y la riqueza de Ellison aumentó de manera marcada. Pero el mismo relato muestra el otro lado de la apuesta: emisión de bonos, ampliación de líneas de crédito, obligaciones vinculadas con alquileres de infraestructura y una mayor presión sobre los indicadores financieros.

El descalce temporal es central. La empresa debe invertir y operar hoy, mientras que una parte relevante de los ingresos puede llegar más adelante. Si un cliente demora pagos, reduce su consumo o no consigue monetizar sus propios servicios, el proveedor de infraestructura queda expuesto.

Según el documento, también aparecieron señales de estrés: una rebaja de la calificación crediticia de Oracle por parte de S&P hasta un nivel cercano a la categoría especulativa y un aumento del costo de asegurarse contra un posible incumplimiento. Estas referencias deben leerse como datos del material de origen, no como una conclusión universal sobre toda la industria de IA.

¿Por qué Oracle funciona como termómetro de la burbuja?

La tesis del documento es que Oracle puede funcionar como un barómetro de una posible burbuja de IA por tres motivos: el nivel de apalancamiento, la dependencia de grandes clientes y la velocidad con la que se expandió la infraestructura.

También aparece una estructura de responsabilidades interconectadas. Algunas empresas invierten en actores que, a su vez, deberían convertirse en compradores de capacidad de cómputo. Si esos compradores no logran generar ingresos suficientes, el impacto puede alcanzar al proveedor, a los bancos, al sector inmobiliario, a la energía y a los inversores.

Eso no significa que la IA sea una moda sin valor. La tecnología puede resolver problemas reales y modificar procesos concretos. La advertencia es otra: una aplicación útil no garantiza que todas las inversiones, valuaciones o proyectos de infraestructura sean sostenibles.

Para un equipo de negocio, conviene separar tres preguntas:

• ¿Qué problema concreto se quiere resolver?
• ¿Qué costo tiene implementar y mantener la solución?
• ¿Cómo se va a medir si el valor generado justifica la inversión?

Qué pueden aprender las empresas

La historia de Ellison deja criterios aplicables a organizaciones de cualquier tamaño, incluso aquellas que no construyen centros de datos.

Empezar por el problema, no por la tecnología

Antes de elegir un modelo o una plataforma, hay que identificar el cuello de botella: consultas repetitivas, documentos difíciles de procesar, seguimiento comercial insuficiente o conocimiento interno disperso. La IA tiene más posibilidades de aportar valor cuando se conecta con una tarea específica y medible.

Validar antes de escalar

El entusiasmo del mercado puede empujar a implementar demasiado alcance de entrada. Un enfoque más prudente consiste en diseñar una primera solución funcional, definir una métrica y observar el desempeño en la operación real. Recién después tiene sentido ampliar canales, procesos o integraciones.

Evaluar las dependencias

Una solución de IA depende de datos, procesos, personas, proveedores y reglas. El análisis debe contemplar qué sucede si cambia el costo, si la información está incompleta o si una regulación modifica el flujo de trabajo.

Mantener supervisión humana donde corresponde

Automatizar no equivale a delegar toda decisión. Los equipos necesitan definir qué puede resolver el sistema, cuándo debe pedir información adicional y en qué situaciones tiene que derivar el caso a una persona.

Conclusión: crecer con IA sin confundir velocidad con valor

La apuesta de Larry Ellison todavía puede interpretarse de dos maneras: como la anticipación de una economía basada en inteligencia artificial o como un ejemplo de lo que ocurre cuando el financiamiento y las expectativas avanzan más rápido que el retorno.

La lección para las empresas no es evitar la IA, sino implementarla con criterio. El futuro no se define solamente por quién tiene el modelo más potente. También por quién entiende mejor su problema, mide el valor de una solución y puede sostenerla en el tiempo.

Si tu organización enfrenta un cuello de botella que no encaja directamente en una herramienta estándar, Soluciones a medida UAMI trabaja bajo el enfoque Built to Solve: entender el problema operativo, diseñar un alcance funcional, implementarlo sobre la operación real y medir antes de escalar. Podés conocer más en Soluciones a medida UAMI.