IBM afirma que el gasto en IA retrasó acuerdos de mainframes, pero el daño es temporal

IBM sufrió una histórica venta masiva de acciones tras admitir que el gasto en infraestructura de IA contribuyó a descarrilar su segundo trimestre. Sin embargo, el análisis de TechCrunch posterior a los resultados plantea un giro tajante: IBM insiste en que los clientes están retrasando las compras de mainframes, no abandonándolas.

El CEO Arvind Krishna afirma que las grandes empresas redirigieron capital hacia servidores, almacenamiento y memoria durante las últimas semanas de junio. Los compradores querían asegurar el suministro antes de los aumentos de precio previstos. Los acuerdos de mainframes y software relacionado no alcanzaron entonces las fechas de cierre previstas por IBM.

Esa explicación enfrenta directamente dos interpretaciones. Los inversores vieron pruebas de que los presupuestos de IA estaban canibalizando los negocios consolidados de IBM. IBM vio una secuencia temporal de compras dentro de presupuestos corporativos fijos, seguida de acuerdos retrasados que aún podrían cerrarse.

La diferencia importa mucho más allá de un trimestre. Los mainframes siguen siendo fundamentales para el procesamiento de transacciones en bancos, aerolíneas, redes de pago y organismos gubernamentales. Si el gasto en IA solo pospone las actualizaciones, IBM puede recuperarse. Si la IA cambia de forma permanente qué infraestructura recibe prioridad presupuestaria, la empresa afronta un problema más profundo.

La advertencia de IBM convirtió un trimestre débil en una prueba de credibilidad

IBM no se limitó a no cumplir las expectativas. Advirtió temprano a los inversores, atribuyó el resultado a un cambio tardío en el gasto de los clientes y reconoció que sus equipos no reaccionaron.

El 14 de julio, Krishna publicó los resultados preliminares del segundo trimestre más de una semana antes del anuncio de resultados programado por IBM. Los ingresos alcanzaron los 17.200 millones de dólares, un aumento del 1 por ciento frente al año anterior. Los ingresos de infraestructura cayeron un 7 por ciento, mientras que el software creció un 5 por ciento y la consultoría se mantuvo prácticamente estable.

Esos resultados quedaron por debajo de las expectativas de Wall Street. Los analistas encuestados por FactSet habían previsto ingresos de 17.860 millones de dólares y beneficios ajustados de 3,01 dólares por acción. IBM informó de beneficios ajustados de 2,93 dólares por acción.

La respuesta del mercado fue severa. Las acciones de IBM cayeron cerca de un 25 por ciento el 14 de julio, el mayor descenso diario de la empresa en más de un siglo. La venta masiva también extendió la inquietud entre las compañías de software expuestas a los presupuestos de tecnología empresarial.

La inusualmente directa carta a los inversores de Krishna explicó la causa inmediata. IBM esperaba que los ingresos de infraestructura disminuyeran a medida que el mainframe z17 entraba en una comparación interanual más exigente. La caída real fue peor porque no se cerraron grandes acuerdos de sistemas Z y software de procesamiento de transacciones.

El momento hizo que la advertencia fuera más perjudicial. IBM había descrito el lanzamiento del z17 como el inicio más sólido de un programa de mainframes en su historia. Por ello, los inversores tenían motivos para esperar que el ciclo de producto respaldara los ingresos, incluso a medida que las comparaciones con el lanzamiento inicial se volvían más difíciles.

En cambio, IBM reconoció que el comportamiento de los clientes cambió rápidamente cerca del final del trimestre. Las empresas redirigieron gasto de capital, es decir, dinero destinado a activos de larga duración, hacia servidores, almacenamiento y memoria. Las restricciones de suministro y los aumentos de precio previstos hicieron más urgentes esas compras.

Según IBM, las preocupaciones de ciberseguridad también distrajeron a los clientes. Sin embargo, Krishna no presentó las condiciones externas como una defensa completa. Escribió que IBM “tropezó”, no logró adaptarse con suficiente rapidez y permitió que numerosos grandes acuerdos se retrasaran más allá de los plazos esperados.

Esa admisión transformó el asunto, de un descenso rutinario del ciclo de producto, en una cuestión de ejecución. La presión sobre el suministro puede explicar por qué los clientes reordenaron sus compras. No explica del todo por qué IBM no anticipó la magnitud del cambio ni protegió suficientes acuerdos para cumplir las expectativas.

Los resultados trimestrales finales confirmaron ingresos de 17.162 millones de dólares. Infraestructura generó 3.835 millones de dólares, una caída interanual del 7,4 por ciento. Su margen de beneficio por segmento también descendió del 23,3 por ciento al 21,8 por ciento.

El software siguió siendo el mayor segmento, con 7.761 millones de dólares en ingresos y un crecimiento del 5,1 por ciento. La consultoría aportó 5.327 millones de dólares, un alza de apenas el 0,2 por ciento. Estas cifras muestran por qué el déficit de mainframes fue importante pese a la cartera más amplia de IBM.

El hardware de mainframes sustenta una estructura económica mayor. Los clientes también compran software operativo, herramientas de procesamiento de transacciones, soporte y consultoría en torno a estos sistemas. Por ello, el retraso de una máquina puede frenar varias fuentes de ingresos conectadas.

La repercusión posterior en TechCrunch no sostenía que los mainframes hubieran dejado de funcionar de repente. Advertía que el ciclo de producto más fiable de IBM había chocado con una categoría más urgente de gasto en infraestructura.

Por qué la infraestructura de IA se adelantó a los mainframes de IBM

La IA no sustituyó al mainframe durante el trimestre. Cambió qué compras de hardware consideraban los clientes imposibles de aplazar.

Los presupuestos de tecnología empresarial no son infinitamente flexibles. Las grandes organizaciones planifican el gasto anual de capital, pero pueden reordenar compras cuando cambian la disponibilidad y los precios. IBM afirma que eso fue lo que ocurrió a finales de junio.

Los clientes priorizaron servidores de propósito general, sistemas de almacenamiento y memoria necesarios para proyectos de IA. La memoria fue especialmente importante porque los sistemas modernos de IA consumen grandes cantidades de memoria de alto ancho de banda y memoria convencional en cargas de trabajo de entrenamiento, inferencia y procesamiento de datos.

La inferencia es el proceso de ejecutar un modelo de IA entrenado para producir una respuesta o predicción. A medida que las empresas llevan aplicaciones de IA de los experimentos a producción, la inferencia genera una demanda sostenida de servidores, aceleradores, redes, almacenamiento y memoria.

Las actualizaciones de mainframes operan con un calendario distinto. Las empresas suelen planificarlas cuidadosamente porque respaldan cargas de trabajo sensibles y de gran volumen. Un banco no puede trasladar sin más el procesamiento de pagos de una arquitectura a otra porque haya un nuevo servidor de IA disponible.

Esa estabilidad también facilita aplazar un acuerdo de mainframe. Un cliente puede seguir utilizando la capacidad existente durante otro trimestre mientras asegura hoy hardware de IA escaso. La carga de trabajo permanece, pero la orden de compra se desplaza.

Los propios resultados de IBM respaldan parte de esta explicación. La infraestructura distribuida, incluidos los sistemas Power y el almacenamiento, creció un 37 por ciento durante el trimestre. IBM afirmó que ese negocio cerró junio con una cartera de pedidos de aproximadamente 500 millones de dólares.

El contraste dentro de IBM resulta revelador. Los clientes seguían comprando infraestructura, pero favorecían productos alineados con restricciones inmediatas de capacidad. La demanda no desapareció del mercado. Se desplazó entre categorías.

Este es el mecanismo detrás del argumento de IBM sobre una interrupción temporal. La infraestructura de IA recibe prioridad porque retrasar el acceso puede ralentizar un nuevo proyecto o exponer al comprador a mayores costes de componentes. Una renovación de mainframe a veces puede esperar sin interrumpir las operaciones actuales.

El argumento resulta menos tranquilizador al observarse a lo largo de varios ciclos presupuestarios. Si el hardware de IA consume repetidamente la primera parte del capital anual, los supuestos retrasos temporales de IBM pueden repetirse. El aplazamiento reiterado acaba comportándose como una demanda más débil, incluso si los clientes conservan todas las cargas de trabajo existentes en mainframes.

Por tanto, IBM debe demostrar más que el uso continuado de mainframes. Debe mostrar que ese uso se traduce en crecimiento oportuno de capacidad e ingresos de software. Los sistemas instalados pueden seguir siendo esenciales mientras las ventas de nuevos sistemas decepcionan.

Esta distinción ayuda a explicar la intensa reacción de los inversores. Los mainframes suelen generar ingresos cíclicos, con fuerte crecimiento tras el lanzamiento de una nueva generación y descensos a medida que madura ese ciclo. Los inversores esperan esos patrones. Reaccionan con más fuerza cuando un lanzamiento emblemático rinde por debajo de lo previsto porque los clientes han encontrado un destino más urgente para el capital.

El z17 se presentó como un mainframe diseñado para la era de la IA. Incluye capacidades para ejecutar modelos de IA junto a cargas de trabajo de transacciones, lo que permite a las organizaciones evaluar datos sin trasladar cada registro a otro entorno.

Ese diseño debería situar a IBM en el lado ganador del gasto en IA. Sin embargo, el segundo trimestre mostró una división presupuestaria entre la infraestructura comprada específicamente para ampliar la IA y la infraestructura comercializada como capaz de añadir IA a cargas de trabajo consolidadas.

Las dos categorías resuelven problemas distintos. Los sistemas con gran carga de GPU se dirigen al entrenamiento de modelos y la inferencia a gran escala. Los mainframes se dirigen al procesamiento seguro de transacciones, la disponibilidad y el control centralizado, con IA integrada en esas operaciones existentes.

El desafío de IBM es hacer que el caso de uso combinado sea urgente. Si los clientes consideran útil pero no esencial la IA en mainframes, seguirá perdiendo competencias de calendario frente a servidores y memoria escasos.

TechCrunch después del desplome: IBM afirma que el mainframe está retrasado, no muriendo

La defensa de IBM se basa en datos de capacidad de clientes y acuerdos retrasados, no en afirmar que el trimestre fue secretamente sólido.

Durante la llamada de resultados del 22 de julio, Krishna rechazó la idea de que los clientes estuvieran alejándose de los mainframes. Afirmó que IBM no veía pruebas de que los clientes abandonaran la plataforma. En cambio, la empresa caracterizó el déficit como un problema de calendario concentrado en grandes acuerdos de capital.

IBM informó que el rendimiento del z17 se mantenía cerca del 130 por ciento del programa z16 comparable. “Programa a programa” compara ventas o capacidad instalada en el mismo punto de ciclos de producto sucesivos.

La empresa también afirmó que los clientes que representan el 85 por ciento de los MIPS instalados habían mantenido o ampliado su capacidad. MIPS, o millones de instrucciones por segundo, es una medida tradicional utilizada para describir la capacidad de procesamiento de mainframes.

Esas cifras respaldan el argumento de que las cargas de trabajo esenciales siguen vigentes. También encajan con la durabilidad histórica de los mainframes. Las organizaciones continúan utilizándolos porque sustituir sistemas de transacciones profundamente integrados implica riesgos operativos, de seguridad y de cumplimiento normativo.

Un gran banco, por ejemplo, podría ejecutar actualizaciones de cuentas, autorizaciones de tarjetas, controles de fraude y procesos de liquidación mediante aplicaciones de mainframe. Trasladar estos sistemas requiere más que reescribir código COBOL antiguo. La organización debe preservar la integridad de los datos, el tiempo de actividad, los controles de auditoría y las conexiones con cientos de servicios posteriores.

Las herramientas de programación con IA pueden reducir parte del trabajo de modernización. Pueden documentar aplicaciones antiguas, explicar código desconocido y ayudar a traducir componentes seleccionados. No eliminan el riesgo institucional de sustituir sistemas que gestionan transacciones críticas cada segundo.

Por tanto, la posición de IBM tiene una sólida base técnica. Los mainframes son difíciles de desplazar porque se encuentran dentro de los procesos operativos, no simplemente dentro de los centros de datos. El coste de un fallo puede superar cualquier ahorro previsto por la migración.

Sin embargo, la persistencia técnica no garantiza un ciclo de hardware fluido. Los clientes pueden mantener las cargas de trabajo en sistemas IBM mientras prolongan la vida útil de los equipos, utilizan capacidad de reserva, negocian con mayor dureza o trasladan aplicaciones incrementales a otros lugares.

Esa brecha entre el uso instalado y el nuevo gasto es la tensión central. Las cifras de IBM muestran que la plataforma sigue activa. Aún no demuestran que cada compra retrasada vaya a regresar a la escala original.

Krishna ofreció un dato de corto plazo durante la discusión de resultados. Afirmó que aproximadamente un tercio de los grandes acuerdos que no lograron cerrarse en el segundo trimestre ya se habían cerrado durante el tercer trimestre.

Esa es una evidencia significativa de un problema de calendario. No es una recuperación completa. Dos tercios aún no se habían cerrado cuando habló, e IBM no prometió que todos llegarían sin cambios en tamaño, calendario o condiciones.

El enfoque de TechCrunch tras los resultados captura esta distinción. La IA no ha eliminado la demanda del trabajo que realizan los mainframes. Ha puesto de manifiesto que incluso los sistemas esenciales deben competir por aprobación dentro de presupuestos empresariales limitados.

IBM también redujo su previsión de crecimiento anual de ingresos a moneda constante a un rango de 4 % a 5 %. Antes esperaba un crecimiento superior al 5 %. Una reducción de la previsión es difícil de conciliar con la idea de que cada operación perdida simplemente se desplazó unas semanas.

La dirección puede creer que el negocio subyacente sigue siendo sólido y, al mismo tiempo, reconocer que la oportunidad de ingresos del año se ha debilitado. Ambas afirmaciones pueden ser ciertas. La plataforma puede perdurar, pero IBM aún debe ejecutar dentro del calendario que utilizan los inversores.

La Verdadera Competencia Es la Prioridad Presupuestaria, No los Mainframes Frente a la IA

El rival de IBM no es un modelo de IA ni otro proveedor de mainframes. Es la urgencia asociada a cada compra competidora de infraestructura de IA.

Plantear la historia como IA frente a mainframes crea una falsa disyuntiva técnica. Las grandes empresas necesitan tanto sistemas transaccionales como capacidad de IA. El conflicto inmediato surge cuando los responsables de finanzas y tecnología deciden qué compra recibe financiación primero.

Los proyectos de IA ahora atraen la atención de los consejos de administración, los directores ejecutivos, los equipos de seguridad y los líderes de unidades de negocio. Muchas organizaciones temen quedarse atrás frente a sus competidores o perder acceso a componentes con disponibilidad limitada. Esa presión incrementa el coste percibido de esperar.

Las actualizaciones de mainframes tienen una justificación distinta. A menudo protegen la resiliencia, la capacidad y la eficiencia de sistemas que ya generan valor empresarial. Sus beneficios pueden parecer incrementales frente a una nueva iniciativa de IA que promete automatización o una nueva línea de productos.

Esta asimetría afecta a IBM incluso si su tecnología funciona como se anuncia. Una plataforma probada puede perder prioridad presupuestaria frente a un proyecto especulativo cuando la dirección considera que este último es estratégicamente urgente.

Los proveedores de infraestructura competidores se benefician de esa urgencia. Los sistemas centrados en Nvidia capturan gasto destinado a computación acelerada. Los proveedores de nube a hiperescala ofrecen acceso a modelos e infraestructura de IA sin exigir que cada cliente posea el hardware subyacente.

Los proveedores de servidores, almacenamiento, redes y memoria también se benefician cuando las empresas construyen entornos privados de IA. IBM participa en partes de este mercado, pero la economía de sus mainframes sigue expuesta cuando los compradores separan la capacidad de IA de la infraestructura transaccional.

IBM ha intentado conectar estos mundos. El z17 admite procesamiento de IA integrado, mientras que watsonx proporciona herramientas para crear, gobernar e implementar IA. El software de nube híbrida de Red Hat ayuda a las organizaciones a ejecutar cargas de trabajo en entornos privados y públicos.

La idea estratégica es coherente: las empresas deberían gestionar la IA junto con los sistemas y datos en los que ya confían. Sin embargo, los compradores no siempre adquieren tecnología como una arquitectura integrada. Los responsables de presupuesto pueden financiar ahora un clúster urgente de IA y revisar la capacidad de mainframe más adelante.

La consultoría debería ayudar a IBM a cerrar esa brecha. Sus asesores pueden conectar los planes de IA con las aplicaciones existentes, los requisitos de gobernanza y los datos operativos. Sin embargo, los ingresos de consultoría crecieron solo un 0,2 % en el trimestre, lo que limita la evidencia de un amplio aumento de implementaciones.

El software mostró más impulso. Los ingresos de Red Hat crecieron un 11 %, mientras que los activos recientemente adquiridos de HashiCorp y Confluent tuvieron un sólido desempeño, según IBM. Estos negocios se alinean con la infraestructura híbrida, la implementación de aplicaciones y el movimiento de datos en tiempo real.

Ese desempeño ofrece a IBM varias formas de beneficiarse del gasto empresarial en IA. También complica la historia. La compañía puede ganar a través de Red Hat o del software de datos mientras sufre retrasos en las ventas de mainframes y procesamiento transaccional.

Los inversores deben evaluar la combinación, no solo la exposición total a la IA. El desplazamiento de ingresos desde una pila consolidada de alto margen hacia productos diferentes puede alterar la rentabilidad, el calendario de ventas y las relaciones con los clientes.

El conflicto de gasto también afecta a los líderes tecnológicos que gestionan sistemas existentes. Deben decidir si modernizar cerca del mainframe, trasladar cargas de trabajo seleccionadas o crear servicios de IA que accedan a datos establecidos mediante interfaces controladas.

Esa decisión requiere un registro claro de elecciones arquitectónicas, afirmaciones de proveedores, restricciones de seguridad y dependencias operativas. Una base de conocimiento técnico con capacidad de búsqueda puede ayudar a los equipos a comparar esos materiales sin separar las decisiones de sus documentos de origen.

Aun así, la documentación no puede resolver la disyuntiva de inversión. IBM debe demostrar que actualizar su plataforma impulsa ahora los objetivos de IA, en lugar de limitarse a preservar una infraestructura que los clientes ya consideran indispensable.

Lo Que la Explicación de IBM Aún No Demuestra

La narrativa de retrasos temporales es plausible, pero un trimestre de seguimiento no puede establecer que el gasto en IA haya dejado intacta la economía a largo plazo de IBM.

La primera incertidumbre se refiere a las operaciones retrasadas restantes. Cerrar aproximadamente un tercio durante el tercer trimestre respalda la explicación de IBM. También deja sin resolver una parte sustancial.

Las grandes compras empresariales pueden cambiar después de aplazarse. Los clientes pueden reducir capacidad, dividir pedidos, exigir condiciones diferentes o trasladar decisiones de software relacionadas a otro ejercicio presupuestario. Una operación retrasada no es idéntica a una cartera contratada.

La segunda incertidumbre se refiere a la presión recurrente sobre los componentes. IBM vinculó la disrupción de junio con infraestructura de suministro limitado y aumentos de precios previstos. Si la disponibilidad de memoria y servidores sigue siendo complicada, los clientes podrían continuar priorizando esas compras.

Eso convertiría una secuencia temporal en un patrón repetido. Los mainframes seguirían funcionando, pero cada nuevo ciclo podría comenzar detrás de la infraestructura de IA en la cola de asignación de capital.

La tercera incertidumbre implica la ejecución de IBM. Krishna afirmó explícitamente que la compañía no se adaptó con la rapidez suficiente. Esa admisión impide a la dirección atribuir el incumplimiento por completo a condiciones externas.

Los equipos de ventas deberían comprender los ciclos de aprobación de los clientes y las demandas presupuestarias competidoras. Los sistemas de previsión deberían identificar grandes operaciones expuestas a cambios al cierre del trimestre. Los equipos de producto deberían hacer que el valor de IA del z17 sea lo bastante concreto como para proteger la urgencia de compra.

IBM afirma que el z17 sigue por delante del ciclo comparable del z16. Esa métrica merece una interpretación cuidadosa porque los programas de producto pueden variar en calendario de lanzamiento, combinación de capacidad, concentración de clientes y reconocimiento de ingresos.

La cifra de MIPS instalados también mide la actividad de la plataforma de forma más directa que los nuevos ingresos. Los clientes que mantienen capacidad demuestran compromiso con las cargas de trabajo. No necesariamente demuestran entusiasmo por acelerar las compras de hardware.

La cobertura independiente refuerza ambos lados. La cobertura de resultados preliminares documentó la brecha frente a las expectativas de los analistas y la magnitud de la caída inicial de la acción. Los resultados posteriores mostraron que IBM siguió generando crecimiento en software y varios productos de infraestructura distribuida.

Puede decirse que el mercado castigó más que un único fallo de hardware. La advertencia de IBM planteó dudas sobre si el gasto de capital en IA desplaza al software y la infraestructura empresariales consolidados. Preocupaciones similares pueden afectar a cualquier proveedor cuyos productos compitan con proyectos de IA por presupuestos fijos.

Sin embargo, el caso de IBM no debería convertirse en una regla universal. Sus resultados reflejan su combinación de productos, ejecución comercial, ciclo de mainframes y base de clientes. Otra empresa de software podría enfrentarse a estructuras de renovación diferentes o a una menor exposición a compras de capital.

También existe el riesgo de tratar la reacción de la acción como un veredicto técnico. Los mercados reajustan expectativas, no arquitecturas. Una caída pronunciada indica que los beneficios y las previsiones difirieron notablemente de las hipótesis de los inversores. No demuestra que el mainframe haya perdido su función operativa.

La conclusión más defendible es más limitada. El gasto en IA alteró la secuencia prevista de operaciones de IBM, e IBM no logró absorber esa disrupción. La compañía ha presentado indicios iniciales de que la demanda retrasada está regresando, pero la recuperación sigue incompleta.

Esa conclusión respeta la diferencia entre una explicación creíble y un cambio de rumbo verificado. IBM no necesita demostrar que la IA y los mainframes pueden coexistir. Ya lo hacen. Debe demostrar que esa coexistencia genera el calendario de ingresos y el crecimiento que esperaban los inversores.

Tres Señales Decidirán si la Recuperación de IBM se Mantiene

El próximo trimestre debe convertir la explicación de IBM en resultados medibles en operaciones retrasadas, capacidad de mainframes y la cartera empresarial más amplia.

La primera señal es la tasa de cierre de las grandes operaciones que se aplazaron desde el segundo trimestre. IBM afirmó que aproximadamente un tercio ya se había cerrado. La próxima actualización debería mostrar si la mayor parte del resto siguió el mismo camino y si mantuvieron el alcance previsto.

Una tasa de cierre alta reforzaría el argumento del calendario. Los retrasos continuados sugerirían que los clientes están reconsiderando algo más que las fechas de las órdenes de compra.

La segunda señal es el desempeño del z17 frente al ciclo del z16. IBM afirma que el z17 se mantiene cerca del 130 % entre programas comparables. Los inversores deberían observar si esa ventaja persiste tras el trimestre volátil.

Una capacidad instalada estable o en expansión respaldaría la afirmación de IBM de que los clientes siguen comprometidos. Unas adiciones de capacidad más lentas debilitarían la conexión entre cargas de trabajo esenciales e ingresos por nuevos sistemas.

La tercera señal es la combinación de ingresos de IBM. La recuperación del mainframe sería más convincente si el software de procesamiento transaccional mejora junto con la infraestructura. La fortaleza continuada de Red Hat, almacenamiento y Power mostraría que IBM está captando gasto relacionado con la IA en otros ámbitos.

Esa combinación importa porque IBM redujo su previsión anual de ingresos. Unas pocas operaciones recuperadas podrían corregir el calendario trimestral sin restaurar la expectativa de crecimiento anterior. Una mejora sostenible requiere contribuciones de software, infraestructura y consultoría.

La cuestión más amplia es si IBM puede convertir el mainframe en parte del presupuesto urgente de IA, en lugar de la compra que espera detrás de él. Eso exige resultados específicos para los clientes, no otra afirmación general de que el z17 fue diseñado para la IA.

Las empresas deberían observar cómo los clientes de IBM implementan IA cerca de datos transaccionales regulados. Entre los ejemplos útiles se incluyen la detección de fraude en tiempo real, el análisis de riesgos, la previsión operativa y el soporte automatizado para aplicaciones heredadas.

La seguridad también seguirá siendo fundamental. Las organizaciones necesitan acceso controlado a registros sensibles, pistas de auditoría fiables y una gobernanza clara sobre las salidas de los modelos. Los mainframes tienen ventajas en esos entornos, pero IBM debe traducirlas en proyectos con presupuestos aprobados.

La narrativa de TechCrunch posterior al trimestre acabará siendo juzgada por pedidos, capacidad, crecimiento del software y previsiones. No se resolverá por la antigüedad de COBOL ni por otra predicción de que los sistemas heredados están a punto de desaparecer.

IBM ha sobrevivido a varias generaciones de tecnología que se esperaba que sustituyeran al mainframe. La supervivencia ya no es la prueba exigente. La prueba exigente es si IBM puede convertir una base instalada duradera en crecimiento mientras la infraestructura de IA absorbe una proporción creciente de la atención de los clientes.

Para los compradores empresariales, la respuesta práctica es seguir dónde cada inversión retrasada crea riesgo. ¿Qué compras de IA son realmente sensibles al suministro? ¿Qué actualizaciones de mainframe protegen la capacidad o el cumplimiento normativo? ¿Qué proyectos dependen de datos compartidos y, por tanto, pertenecen a una única decisión arquitectónica?

Mantén esas respuestas vinculadas a registros de reuniones, documentos de proveedores y evidencia operativa. Un sistema de conocimiento personal puede preservar el razonamiento a medida que cambian las premisas.

IBM afirma que el mainframe está retrasado, no en vías de desaparecer. El próximo ciclo de resultados deberá demostrar que esa demanda aplazada regresa antes de que otra oleada de inversión en IA lo vuelva a relegar al final de la lista.