La notificación de fuerza mayor de Oracle expone el cuello de botella energético de la IA
Oracle emitió una notificación de fuerza mayor después de que retrasos en el suministro eléctrico amenazaran Project Jupiter, su proyectado campus de centros de datos de IA de 2,45 gigavatios en Nuevo México. La notificación de fuerza mayor de Oracle no cancela el proyecto ni demuestra que su apertura vaya a retrasarse. Sí revela un conflicto cada vez mayor entre los contratos de infraestructura de IA y los sistemas, más lentos, necesarios para suministrarles electricidad.
Se espera que Project Jupiter respalde a OpenAI mediante el programa de infraestructura Stargate. STACK Infrastructure, propiedad de Blue Owl Capital, está desarrollando el campus. Oracle sigue siendo el principal inquilino y afirma que la construcción avanza conforme al calendario previsto.
La notificación importa porque Oracle ha vinculado enormes compromisos financieros a una capacidad que todavía no existe. OpenAI y otros clientes quieren más potencia informática, mientras Oracle necesita edificios terminados, equipos energéticos, permisos, combustible e infraestructura de transmisión antes de poder reconocer buena parte de esa demanda como ingresos.
Esto genera la inversión central. Las empresas de IA pueden pedir procesadores y firmar acuerdos de nube más rápido de lo que los desarrolladores pueden asegurar energía fiable. El componente más escaso del plan de expansión de Oracle ya no es necesariamente la GPU. Es un sitio operativo con suficiente electricidad para hacer funcionar miles de ellas de manera continua.
Qué cambió realmente con la notificación de fuerza mayor de Oracle
Oracle ha reservado una defensa contractual frente a retrasos relacionados con la electricidad, pero no ha abandonado Project Jupiter.
Oracle envió la notificación a una unidad de Blue Owl que desarrolla el campus de Nuevo México, según un informe sobre el retraso energético publicado por Reuters. El informe indicó que posibles retrasos para asegurar el suministro eléctrico motivaron la medida.
La fuerza mayor es una cláusula contractual que cubre circunstancias extraordinarias fuera del control razonable de una parte. Su efecto legal depende del contrato, del hecho desencadenante y de si la parte afectada siguió los procedimientos exigidos.
Por tanto, una notificación es distinta de un incumplimiento confirmado. Puede preservar derechos contractuales mientras las partes continúan trabajando para completar el proyecto. También puede iniciar una disputa sobre quién asumió un riesgo concreto de desarrollo.
Blue Owl afirmó que la notificación no modificaba los compromisos financieros del proyecto. La compañía también señaló que las partes seguían alineadas respecto al desarrollo plurianual. Por separado, Oracle sostuvo que Project Jupiter continuaba según el calendario previsto.
Estas declaraciones limitan las conclusiones posibles. No existe evidencia verificada de que Oracle haya cancelado el campus, terminado su relación con STACK o retirado su compromiso con Nuevo México.
La disputa inmediata se refiere, en cambio, a la protección frente a costes si los problemas eléctricos retrasan la ocupación. Las condiciones de arrendamiento comunicadas indican que Oracle podría intentar aplazar el inicio del pago de alquiler durante tres años si ambas partes reconocen un evento de fuerza mayor que reúna los requisitos.
Ese resultado no es automático. El desarrollador tendría que aceptar la reclamación, o las partes tendrían que resolver cualquier desacuerdo mediante el proceso de resolución de disputas previsto en su contrato.
Según los informes, Oracle seguiría cubriendo determinados costes del proyecto durante un aplazamiento. También seguiría siendo responsable del alquiler durante todo el plazo del arrendamiento una vez que comenzaran los pagos. Estos detalles hacen que la notificación sea más defensiva que terminal.
La distinción importa para los inversores y los clientes de nube. Una instalación cancelada señalaría una demanda debilitada o una ruptura fundamental del proyecto. Un aplazamiento de pagos, en cambio, modificaría el calendario y la asignación del riesgo de construcción.
La escala prevista de Project Jupiter explica por qué ese calendario importa. El campus fue diseñado para una capacidad de 2,45 gigavatios, según el informe de Bloomberg. Un sitio de tal tamaño necesita un sistema energético comparable a la infraestructura que da servicio a una gran área metropolitana.
No puede depender de una conexión comercial ordinaria. El proyecto necesita generación dedicada, suministro de combustible, equipos eléctricos, aprobaciones locales y sistemas capaces de funcionar bajo exigentes requisitos de disponibilidad.
Eso convierte la electricidad en una dependencia de construcción, en vez de una compra mensual de servicios públicos. Si un componente crítico llega tarde, salas de datos ya terminadas podrían seguir sin poder alojar equipos informáticos que generen ingresos.
La notificación convierte esa dependencia física en una cuestión financiera. ¿Quién paga mientras un campus de IA prácticamente construido espera energía utilizable?
La demanda de IA ha avanzado más rápido que la infraestructura energética
Project Jupiter muestra que la demanda contratada de IA y la capacidad informática que puede entregarse ahora avanzan con calendarios distintos.
La cartera de nube de Oracle sugiere que el interés de los clientes sigue siendo sólido. Su presentación trimestral de agosto de 2026 informó de 664.000 millones de dólares en obligaciones de desempeño restantes.
Las obligaciones de desempeño restantes representan ingresos contratados que aún no se han reconocido. No equivalen a ventas cobrables de inmediato, beneficios garantizados ni efectivo en la cuenta bancaria de Oracle.
Oracle esperaba reconocer cerca del 13% de esa cartera durante los 12 meses siguientes. Otro 37% se esperaba durante los meses 13 a 36, y un 34% estaba programado durante los meses 37 a 60.
Ese calendario hace que la ejecución de la infraestructura sea central para la narrativa financiera de la compañía. Oracle no puede convertir a tiempo un gran contrato de nube en ingresos a menos que instale equipos y ponga a disposición la capacidad prometida.
La misma presentación reveló 288.000 millones de dólares en compromisos adicionales de arrendamiento. La mayoría se relacionaba con acuerdos de centros de datos que se esperaba que comenzaran entre los ejercicios fiscales de 2027 y 2029, con plazos de entre 15 y 19 años.
Esos arrendamientos aún no se reflejaban en el balance de Oracle porque no habían comenzado. Aun así, su escala muestra cuánta capacidad futura ha contratado Oracle antes de que los sitios subyacentes entren en funcionamiento.
Oracle también informó de 34.200 millones de dólares en obligaciones de compra incondicionales y de otro tipo con duración superior a un año. Estos compromisos cubrían principalmente componentes de infraestructura de nube y acuerdos de suministro eléctrico para centros de datos.
La oportunidad comercial de la compañía se corresponde, por tanto, con una larga cadena de obligaciones físicas. Necesita que procesadores, equipos de red, edificios, sistemas de refrigeración, electricidad, financiación y clientes estén disponibles en la secuencia correcta.
La electricidad es particularmente difícil de acelerar. Los fabricantes de chips pueden ampliar la producción, aunque hacerlo lleva tiempo. Los proyectos eléctricos también afrontan planificación de empresas de servicios públicos, acceso a terrenos, revisión ambiental, colas de equipos y participación pública.
Las cifras nacionales muestran por qué esas colas se están saturando. Una estimación federal situó el consumo de los centros de datos de Estados Unidos en 176 teravatios-hora durante 2023.
El Departamento de Energía proyectó un consumo de entre 325 y 580 teravatios-hora para 2028. En el extremo superior, la demanda se triplicaría con creces en cinco años.
Ese crecimiento no se distribuye de forma uniforme por el país. Un único campus de hiperescala puede crear una demanda concentrada en una zona cuyo sistema existente nunca fue diseñado para ello.
Las empresas de servicios públicos deben determinar si la nueva generación y transmisión pueden atender la carga sin debilitar la fiabilidad. Los reguladores deben decidir quién financia esas mejoras y quién asume el riesgo si desaparece la demanda prevista.
Las comunidades locales también quieren pruebas de que los proyectos no elevarán las facturas de los hogares, consumirán agua escasa ni crearán contaminación sin aportar los beneficios prometidos. Estas preocupaciones pueden influir en los calendarios de permisos incluso cuando los responsables políticos nacionales apoyan la construcción para IA.
Esto genera presión sobre todos los participantes. Los desarrolladores necesitan permisos antes de que los prestamistas liberen capital. Las empresas de servicios públicos necesitan previsiones creíbles de carga antes de construir infraestructura. Las empresas tecnológicas necesitan fechas firmes de finalización antes de prometer capacidad a los clientes.
Oracle se encuentra en medio de estas dependencias. Sus acuerdos con clientes generan urgencia, pero sus socios de infraestructura no pueden eliminar los plazos regulatorios mediante un contrato de nube.
El plan energético de Project Jupiter sigue cambiando
La búsqueda del proyecto de electricidad fiable ya ha obligado a un importante rediseño técnico.
Project Jupiter propuso originalmente turbinas de gas natural y generadores diésel de respaldo. Posteriormente, Oracle sustituyó ese diseño por una microrred de celdas de combustible que utiliza tecnología de Bloom Energy.
Una microrred es un sistema eléctrico local capaz de suministrar energía a un sitio definido. En este caso, las celdas de combustible convertirían gas natural en electricidad mediante un proceso electroquímico, en lugar de combustión convencional.
El plan energético actualizado de Oracle indicó que el nuevo diseño reduciría las emisiones y el uso de agua en comparación con la propuesta anterior. Esa es la evaluación de Oracle, no una conclusión independiente sobre el campus terminado.
El cambio respondió a algunas objeciones relacionadas con el anterior plan de turbinas. No eliminó la dependencia del proyecto de la infraestructura de combustible, la aprobación regulatoria ni la entrega oportuna de equipos.
Las celdas de combustible pueden proporcionar generación in situ sin esperar una conexión convencional a la red dimensionada para todo el campus. Esto las hace atractivas para desarrolladores de IA que afrontan largas colas de las empresas de servicios públicos.
Sin embargo, las celdas de combustible siguen necesitando un suministro fiable de gas natural. Su instalación también requiere integración eléctrica, revisión de la calidad del aire, controles de seguridad y equipos suficientes para respaldar una carga inusualmente grande.
El gasoducto propuesto para abastecer a Project Jupiter afrontó sus propios problemas. El comisionado de tierras estatales de Nuevo México rechazó permisos que afectaban a una ruta planificada, añadiendo incertidumbre al calendario de suministro de combustible.
Posteriormente, el desarrollador del gasoducto afrontó un retraso en su fecha prevista de entrada en servicio. Ese contratiempo es importante porque el campus no puede resolver una limitación de la red con generación in situ si el combustible no puede llegar a los generadores.
La secuencia ilustra un problema recurrente de infraestructura. Sustituir un cuello de botella a menudo crea una dependencia diferente, en lugar de eliminar el riesgo original.
Una conexión a la red depende de las empresas de servicios públicos, la capacidad de transmisión y la asignación regulatoria de costes. Un sistema de generación dedicado depende del suministro de combustible, la producción de equipos, los permisos de emisiones y las aprobaciones del sitio.
El enfoque basado en celdas de combustible aún ofrece ventajas potenciales. Las unidades modulares pueden instalarse por fases, lo que podría permitir a Oracle energizar secciones del campus a medida que los edificios estén listos.
La instalación por fases también se alinea mejor con un despliegue gradual de servidores. Oracle no necesitaría necesariamente los 2,45 gigavatios completos el primer día de operaciones.
Sin embargo, la construcción por fases añade complejidad de programación. Cada sala de datos utilizable necesita generación suficiente, refrigeración, redes, sistemas de respaldo y aprobaciones de seguridad antes de que los clientes puedan desplegar cargas de trabajo de producción.
Por tanto, una apertura parcial solo ayudaría si la energía disponible coincide con la capacidad informática prometida en los contratos de Oracle con sus clientes. Las divulgaciones públicas no proporcionan ese nivel de detalle.
La insistencia de Oracle en que el proyecto sigue según lo previsto puede reflejar confianza en rutas alternativas o en fases de construcción revisadas. La notificación de fuerza mayor sugiere que la compañía también se prepara para un resultado menos favorable.
Esas posiciones no son necesariamente contradictorias. Una empresa puede esperar una finalización puntual y, al mismo tiempo, preservar sus derechos contractuales si falla una dependencia externa.
El problema es informativo. Los inversores no pueden confirmar de forma independiente el calendario de construcción, la ruta crítica del gasoducto ni las condiciones necesarias para que comiencen las obligaciones de pago de alquiler de Oracle.
Esa incertidumbre convierte a Project Jupiter en una prueba de ejecución más que de demanda. Oracle cuenta con clientes que buscan capacidad. La cuestión abierta es si su plan energético puede transformar edificios y procesadores en infraestructura cloud utilizable a tiempo.
El conflicto está entre los contratos de IA y la realidad física
El modelo de expansión de Oracle presupone que los compromisos financieros a largo plazo pueden sincronizarse con una infraestructura expuesta a retrasos locales.
El mercado de la nube de IA recompensa a las empresas que aseguran capacidad con antelación. Esperar a que una instalación reciba todos los permisos antes de firmar con clientes podría dejar a Oracle por detrás de rivales más grandes.
Amazon, Microsoft y Google pueden distribuir cargas de trabajo entre amplias regiones cloud y relaciones energéticas ya existentes. Oracle tiene una presencia de infraestructura menor, aunque persigue algunos de los mayores acuerdos de IA del sector.
Por tanto, la estrategia de Oracle depende en gran medida de futuros campus. Esto genera un rápido crecimiento del backlog declarado, pero también concentra el riesgo de ejecución en proyectos que requieren años de construcción.
Project Jupiter pone esa tensión de manifiesto. La demanda de clientes de Oracle se sitúa aguas abajo de OpenAI y otros desarrolladores de modelos. Sus obligaciones de arrendamiento se sitúan aguas arriba, con desarrolladores, prestamistas, empresas de servicios públicos y proveedores de equipos.
Si el campus abre según lo previsto, la estructura puede funcionar bien. Oracle obtiene ingresos por computación, mientras que los socios de infraestructura cobran pagos contratados durante largos plazos de arrendamiento.
Si la energía llega tarde, los ingresos y los costes de ocupación pueden separarse. Oracle podría afrontar pagos antes de disponer de capacidad utilizable, mientras que los desarrolladores y prestamistas siguen esperando rendimientos sobre el capital comprometido.
La notificación de fuerza mayor de Oracle parece diseñada para limitar ese desajuste. Ofrece a la empresa una base para argumentar que retrasos extraordinarios en el suministro eléctrico deberían posponer algunos pagos.
Los desarrolladores ven el riesgo de otra manera. Financian la construcción en parte porque un gran inquilino tecnológico ha aceptado un compromiso de largo plazo. Si ese inquilino puede retrasar pagos, los proveedores de capital asumen más riesgo de calendario.
Por eso Blue Owl subrayó que los compromisos financieros del proyecto no habían cambiado. La declaración tranquiliza a prestamistas e inversores sin resolver cómo operaría la disposición de fuerza mayor.
El argumento es más amplio que un solo arrendamiento. La financiación de infraestructura de IA utiliza cada vez más proyectos de propósito especial respaldados por contratos a largo plazo de empresas tecnológicas.
Esos contratos ayudan a los desarrolladores a recaudar fondos sin trasladar todos los costes de construcción al balance de un proveedor cloud. También crean dependencias entre clientes, inquilinos, desarrolladores, fondos de crédito privado, empresas de servicios públicos y proveedores de energía.
Un retraso puede propagarse por esa cadena. El inquilino pospone la ocupación, el desarrollador espera el alquiler y los prestamistas reevalúan el valor de la deuda del proyecto.
La reacción del mercado reflejó esa preocupación. Las acciones de Oracle y Blue Owl cayeron tras los informes sobre la notificación, aunque una sola sesión de negociación no puede determinar la economía del proyecto a largo plazo.
La visión escéptica sostiene que Oracle está tratando un desafío energético previsible como un acontecimiento extraordinario. Los grandes centros de datos evidentemente necesitan energía, y las aprobaciones en Nuevo México siempre formaron parte del proceso de desarrollo.
Desde esa perspectiva, la disponibilidad de energía pertenece al riesgo ordinario de construcción. Calificarla como fuerza mayor debilitaría la certeza que hace posible la financiación de proyectos a largo plazo.
La opinión contraria es que denegaciones específicas de permisos o acciones gubernamentales pueden cumplir los requisitos incluso si se conocía la categoría general de riesgo. El resultado legal depende de un lenguaje contractual que no es público.
Ninguna interpretación se ha establecido de manera concluyente. La notificación no prueba que la reclamación de Oracle vaya a prosperar, y la declaración de la empresa sobre el calendario no demuestra que se haya resuelto cada dependencia.
La conclusión más segura es más limitada. Oracle ha identificado suficiente incertidumbre para preservar un recurso contractual, mientras todas las partes siguen presentando Project Jupiter como un proyecto activo.
La escasez de energía se está convirtiendo en competencia cloud
Los proveedores cloud compiten cada vez más por megavatios que puedan entregarse, no solo por clientes, procesadores o funciones de software.
Los modelos de IA requieren densos clústeres de aceleradores conectados mediante redes de alta velocidad. Los trabajos de entrenamiento y los grandes servicios de inferencia pueden mantener esos equipos funcionando a alta utilización durante periodos prolongados.
Ese patrón operativo crea una carga eléctrica grande y constante. Los sistemas de refrigeración, el almacenamiento, los equipos de red y la infraestructura de respaldo se suman al consumo directo de los servidores.
Las nuevas instalaciones también quieren electricidad antes de que los proyectos convencionales de generación y transmisión puedan proporcionarla. La construcción de la red suele requerir más tiempo que equipar una sala de datos.
El resultado es un mercado emergente para instalaciones con energía asegurada. Un proveedor cloud con procesadores disponibles pero sin un edificio energizado no puede vender la capacidad de computación que necesitan los clientes.
Esto cambia el significado de la escala. La expansión cloud anterior solía implicar añadir servidores dentro de una región existente. Los proyectos actuales de IA pueden requerir sistemas eléctricos completamente nuevos, medidos en gigavatios.
Amazon, Microsoft, Google, Meta y Oracle han impulsado contratos nucleares, proyectos renovables, acuerdos con la red y generación in situ. Cada enfoque equilibra velocidad, fiabilidad, coste, emisiones y exposición regulatoria.
La energía de red puede ofrecer una generación eficiente a escala de sistema, pero las colas de conexión pueden ser largas. La generación a gas puede llegar más cerca de la carga, aunque enfrenta restricciones de gasoductos y medioambientales.
Las centrales nucleares proporcionan electricidad fiable y baja en carbono, pero requieren plazos de desarrollo prolongados. La generación renovable puede construirse relativamente rápido, aunque los grandes clústeres de IA también necesitan almacenamiento o capacidad de respaldo firme.
Las pilas de combustible ocupan otra posición en esta combinación. Su diseño modular permite el despliegue in situ, pero las grandes instalaciones siguen dependiendo del gas natural y de una amplia infraestructura de apoyo.
Project Jupiter representa por tanto un experimento más amplio para el sector. Oracle intenta reunir capacidad de computación y energía a una escala que los sistemas locales no fueron diseñados para suministrar rápidamente.
Los competidores de la empresa enfrentan una presión similar, pero sus posiciones de partida difieren. Los operadores cloud más grandes tienen más regiones, mayor generación de efectivo y carteras de infraestructura más amplias.
El gran backlog de Oracle le da un fuerte incentivo para expandirse con rapidez. Sus compromisos de arrendamiento también reducen el margen para retrasos prolongados en múltiples proyectos.
Por eso la advertencia va más allá de los accionistas de Oracle. OpenAI depende de socios para proporcionar la infraestructura que sustenta sus servicios, mientras que las empresas dependen de esos servicios para cargas de trabajo de IA en producción.
Un campus retrasado no interrumpe de inmediato una aplicación existente. Puede afectar a cuándo estarán disponibles entrenamiento adicional de modelos, capacidad de inferencia y recursos cloud empresariales.
Las restricciones de capacidad pueden influir en las decisiones de asignación y despliegue antes de que los clientes experimenten una interrupción. Los proveedores podrían priorizar grandes contratos, retrasar nuevas regiones o trasladar cargas de trabajo a ubicaciones más costosas.
Por ello, los compradores empresariales deberían evaluar más que los recuentos anunciados de GPU. La pregunta relevante es si un proveedor puede entregar capacidad sostenida y con energía en las regiones y plazos que requiere un despliegue.
Para los desarrolladores, el problema aparece de forma indirecta mediante cuotas, listas de espera, reservas de capacidad y disponibilidad regional. Esas señales operativas revelan más que la representación de un campus lejano.
Los trabajadores del conocimiento no seguirán los permisos de gasoductos durante el uso normal de IA. Aun así, pueden encontrarse con las consecuencias mediante una expansión de productos más lenta, funciones restringidas o mayores costes organizativos.
La notificación de fuerza mayor de Oracle hace visible esa cadena. La planificación energética se ha convertido en parte de la fiabilidad del producto cloud, aunque el usuario final nunca vea la fuente de energía.
Tres señales mostrarán si la advertencia de Oracle se extiende
Las próximas pruebas deberían proceder del calendario del proyecto, las divulgaciones financieras de Oracle y los términos de financiación utilizados en nuevos campus de IA.
La primera señal es el calendario de combustible y energía de Project Jupiter. Oracle necesita avances claros en el gasoducto, la instalación de pilas de combustible y las aprobaciones necesarias para la operación por fases.
Una fecha firme de servicio del gasoducto reforzaría la afirmación de Oracle de que el campus sigue según lo previsto. Más contratiempos con los permisos harían que su advertencia contractual pareciera más relevante.
La segunda señal es el momento de los arrendamientos de Oracle y sus obligaciones de desempeño restantes. Sus informes deberían mostrar si los compromisos de centros de datos comienzan según lo previsto y si el backlog se convierte en ingresos.
Los inversores deberían observar los cambios en arrendamientos aún no iniciados, obligaciones de compra de energía, gasto de capital y reconocimiento proyectado de ingresos. Ninguna de estas medidas por sí sola confirmará el estado de Project Jupiter.
En conjunto, pueden mostrar si la infraestructura está alcanzando a la demanda contratada. Un backlog creciente junto con retrasos de capacidad repetidos ampliaría la brecha entre las promesas comerciales y la entrega física.
La tercera señal es cómo los desarrolladores y prestamistas valoran el riesgo de calendario en proyectos posteriores. Los nuevos contratos podrían asignar la responsabilidad energética de forma más explícita o exigir mayores garantías a los inquilinos tecnológicos.
Esa respuesta indicaría que Project Jupiter cambió las prácticas de financiación incluso si el campus termina abriendo a tiempo. También elevaría el coste de trasladar la infraestructura fuera del balance de un proveedor cloud.
Por el contrario, unos términos de financiación sin cambios y una demanda continua de los prestamistas sugerirían que el mercado considera la notificación una precaución específica del proyecto.
Los lectores deberían resistirse a tratar cada notificación de fuerza mayor como prueba de un colapso de la IA. Los retrasos de proyectos pueden ocurrir durante un ciclo de expansión duradero, especialmente cuando la construcción alcanza una escala desconocida.
También deberían evitar desestimar la notificación como mera gestión legal. Oracle tiene cientos de miles de millones en backlog y futuros compromisos de arrendamiento vinculados a infraestructura que debe recibir energía fiable.
La prueba esencial es la conversión. Oracle debe transformar contratos en capacidad energizada y, después, transformar esa capacidad en ingresos cloud reconocidos.
Project Jupiter sigue en desarrollo y Oracle afirma que su calendario permanece intacto. Blue Owl afirma que los compromisos financieros siguen vigentes.
Lo que sigue sin resolverse es si el sistema energético llegará cuando lo requieran los contratos de computación. La notificación de fuerza mayor de Oracle es la señal más clara de que ya no puede darse por sentado ese calendario.
Durante los próximos meses, siga el calendario del gasoducto, las aprobaciones de las pilas de combustible y las divulgaciones de arrendamientos de Oracle. Esas señales mostrarán si Project Jupiter está superando un retraso local o revelando una debilidad repetible en la construcción de IA. Para los compradores empresariales, la respuesta práctica es cuestionar las fechas de entrega, la capacidad regional y los planes de contingencia antes de depender de la infraestructura prometida. Para los inversores, el backlog debe evaluarse junto con el acceso a la energía y el inicio de los arrendamientos, no de forma aislada. La expansión de la IA sigue teniendo clientes, capital y procesadores. Su próxima restricción es si los proyectos energéticos y las aprobaciones públicas pueden igualar la velocidad de esos compromisos.
