IBM Diz que Gastos com IA Adiaram Acordos de Mainframe, mas o Impacto é Temporário

A IBM sofreu uma histórica liquidação de suas ações após admitir que os gastos com infraestrutura de IA ajudaram a prejudicar seu segundo trimestre. Ainda assim, a reportagem do TechCrunch após os resultados traz uma reviravolta contundente: a IBM insiste que os clientes estão adiando compras de mainframes, não abandonando-as.

O CEO Arvind Krishna diz que grandes empresas redirecionaram capital para servidores, armazenamento e memória nas últimas semanas de junho. Os compradores queriam garantir o fornecimento antes dos aumentos de preço previstos. Acordos de mainframes e softwares relacionados acabaram não sendo fechados nas datas esperadas pela IBM.

Essa explicação coloca duas interpretações em conflito direto. Investidores viram indícios de que os orçamentos de IA estavam canibalizando os negócios estabelecidos da IBM. A IBM viu uma sequência temporária de compras dentro de orçamentos corporativos fixos, seguida por acordos adiados que ainda poderiam ser concluídos.

A diferença importa muito além de um trimestre. Mainframes continuam centrais para o processamento de transações em bancos, companhias aéreas, redes de pagamento e órgãos governamentais. Se os gastos com IA apenas postergarem atualizações, a IBM pode se recuperar. Se a IA mudar permanentemente qual infraestrutura recebe prioridade no orçamento, a empresa enfrentará um problema mais profundo.

O Alerta da IBM Transformou um Trimestre Fraco em um Teste de Credibilidade

A IBM não apenas ficou abaixo das expectativas. Ela alertou os investidores com antecedência, atribuiu o resultado a uma mudança tardia nos gastos dos clientes e reconheceu que suas equipes não reagiram.

Em 14 de julho, Krishna divulgou resultados preliminares do segundo trimestre mais de uma semana antes do anúncio programado de resultados da IBM. A receita alcançou US$ 17,2 bilhões, alta de 1 por cento em relação ao ano anterior. A receita de infraestrutura caiu 7 por cento, enquanto software cresceu 5 por cento e consultoria permaneceu praticamente estável.

Esses resultados ficaram abaixo das expectativas de Wall Street. Analistas consultados pela FactSet projetavam receita de US$ 17,86 bilhões e lucro ajustado de US$ 3,01 por ação. A IBM reportou lucro ajustado de US$ 2,93 por ação.

A reação do mercado foi severa. As ações da IBM caíram cerca de 25 por cento em 14 de julho, registrando a maior queda diária da empresa em mais de um século. A liquidação também espalhou apreensão entre empresas de software expostas aos orçamentos de tecnologia corporativa.

A carta aos investidores incomumente direta de Krishna explicou a causa imediata. A IBM esperava que a receita de infraestrutura diminuísse à medida que o mainframe z17 entrava em uma comparação anual mais difícil. A queda real foi pior porque grandes acordos envolvendo sistemas Z e software de processamento de transações não foram fechados.

O momento tornou o alerta mais prejudicial. A IBM havia descrito o lançamento do z17 como o início mais forte de um programa de mainframe em sua história. Portanto, os investidores tinham motivos para esperar que o ciclo do produto sustentasse a receita, mesmo com as comparações do lançamento inicial se tornando mais difíceis.

Em vez disso, a IBM reconheceu que o comportamento dos clientes mudou rapidamente perto do fim do trimestre. As empresas redirecionaram despesas de capital, ou seja, dinheiro destinado a ativos de longa duração, para servidores, armazenamento e memória. Restrições de oferta e aumentos de preço esperados tornaram essas compras mais urgentes.

Preocupações com cibersegurança também desviaram a atenção dos clientes, segundo a IBM. No entanto, Krishna não apresentou as condições externas como uma defesa completa. Ele escreveu que a IBM “vacilou”, não conseguiu se adaptar com rapidez suficiente e permitiu que diversos grandes acordos ultrapassassem os prazos previstos.

Essa admissão transformou a questão de uma queda rotineira do ciclo de produto em uma dúvida sobre execução. A pressão de oferta pode explicar por que os clientes reordenaram suas compras. Ela não explica plenamente por que a IBM não conseguiu antecipar a magnitude da mudança nem proteger acordos suficientes para atingir as expectativas.

Os resultados trimestrais finais confirmaram receita de US$ 17,162 bilhões. A infraestrutura gerou US$ 3,835 bilhões, queda de 7,4 por cento em relação ao ano anterior. Sua margem de lucro do segmento também caiu de 23,3 por cento para 21,8 por cento.

Software permaneceu como o maior segmento, gerando US$ 7,761 bilhões em receita e crescimento de 5,1 por cento. Consultoria contribuiu com US$ 5,327 bilhões, alta de apenas 0,2 por cento. Esses números mostram por que a deficiência em mainframes importou apesar do portfólio mais amplo da IBM.

O hardware de mainframe sustenta uma estrutura econômica maior. Os clientes também compram software operacional, ferramentas de processamento de transações, suporte e consultoria em torno desses sistemas. Uma máquina adiada pode, portanto, conter várias fontes de receita conectadas.

O impacto pós-resultados do TechCrunch não foi a alegação de que os mainframes de repente deixaram de funcionar. Foi um alerta de que o ciclo de produto mais confiável da IBM havia colidido com uma categoria mais urgente de gastos em infraestrutura.

Por que a Infraestrutura de IA Passou à Frente dos Mainframes da IBM

A IA não substituiu o mainframe durante o trimestre. Ela mudou quais compras de hardware os clientes consideravam impossíveis de adiar.

Os orçamentos de tecnologia empresarial não são infinitamente flexíveis. Grandes organizações planejam gastos anuais de capital, mas podem reordenar compras quando disponibilidade e preços mudam. É isso que a IBM diz ter acontecido no fim de junho.

Os clientes priorizaram servidores de uso geral, sistemas de armazenamento e memória necessários para projetos de IA. A memória foi especialmente importante porque os sistemas modernos de IA consomem grandes quantidades de memória de alta largura de banda e memória convencional em cargas de trabalho de treinamento, inferência e processamento de dados.

Inferência é o processo de executar um modelo de IA treinado para produzir uma resposta ou previsão. À medida que as empresas levam aplicações de IA de experimentos para produção, a inferência cria demanda contínua por servidores, aceleradores, redes, armazenamento e memória.

As atualizações de mainframes seguem outro cronograma. As empresas normalmente as planejam cuidadosamente porque sustentam cargas de trabalho sensíveis e de alto volume. Um banco não pode migrar casualmente o processamento de pagamentos de uma arquitetura para outra porque um novo servidor de IA se tornou disponível.

Essa estabilidade também torna um acordo de mainframe mais fácil de adiar. Um cliente pode continuar usando a capacidade existente por mais um trimestre enquanto garante hoje hardware de IA escasso. A carga de trabalho permanece, mas o pedido de compra é transferido.

Os próprios resultados da IBM sustentam parte dessa explicação. A infraestrutura distribuída, incluindo sistemas Power e armazenamento, cresceu 37 por cento durante o trimestre. A IBM disse que esse negócio encerrou junho com uma carteira de pedidos de aproximadamente US$ 500 milhões.

O contraste dentro da IBM é revelador. Os clientes continuaram comprando infraestrutura, mas favoreceram produtos alinhados a restrições imediatas de capacidade. A demanda não desapareceu do mercado. Ela se deslocou entre categorias.

Esse é o mecanismo por trás do argumento da IBM sobre uma interrupção temporária. A infraestrutura de IA recebe prioridade porque o atraso no acesso pode desacelerar um novo projeto ou expor o comprador a custos mais altos de componentes. Uma renovação de mainframe às vezes pode esperar sem interromper as operações atuais.

O argumento se torna menos reconfortante quando observado ao longo de vários ciclos orçamentários. Se o hardware de IA consumir repetidamente a primeira parcela do capital anual, os atrasos supostamente temporários da IBM podem se repetir. O adiamento recorrente acaba se comportando como demanda mais fraca, mesmo quando os clientes mantêm todas as cargas de trabalho existentes em mainframes.

Portanto, a IBM precisa provar mais do que o uso contínuo de mainframes. Ela precisa mostrar que esse uso se converte em expansão oportuna de capacidade e receita de software. Sistemas instalados podem continuar essenciais enquanto as vendas de novos sistemas ainda decepcionam.

Essa distinção ajuda a explicar a intensa reação dos investidores. Mainframes frequentemente geram receita cíclica, com forte crescimento após o lançamento de uma nova geração e quedas à medida que esse ciclo amadurece. Os investidores esperam esses padrões. Eles reagem mais fortemente quando um lançamento emblemático tem desempenho abaixo do esperado porque os clientes encontraram um destino mais urgente para o capital.

O z17 foi apresentado como um mainframe projetado para a era da IA. Ele inclui recursos para executar modelos de IA ao lado de cargas de trabalho de transações, permitindo que organizações avaliem dados sem mover todos os registros para outro ambiente.

Esse projeto deveria colocar a IBM no lado vencedor dos gastos com IA. No entanto, o segundo trimestre revelou uma divisão orçamentária entre infraestrutura comprada especificamente para expansão de IA e infraestrutura comercializada como capaz de adicionar IA a cargas de trabalho já estabelecidas.

As duas categorias resolvem problemas diferentes. Sistemas com grande uso de GPU visam o treinamento de modelos e a inferência em larga escala. Mainframes visam processamento seguro de transações, disponibilidade e controle centralizado, com IA integrada a essas operações existentes.

O desafio da IBM é tornar urgente o caso de uso combinado. Se os clientes enxergarem a IA em mainframes como útil, mas não essencial, ela continuará perdendo disputas de cronograma para servidores e memória escassos.

TechCrunch Após a Queda: IBM Diz que o Mainframe Está Adiado, Não Morrendo

A defesa da IBM se baseia em dados de capacidade dos clientes e em acordos adiados, não na alegação de que o trimestre foi secretamente forte.

Durante a teleconferência de resultados de 22 de julho, Krishna rejeitou a ideia de que os clientes estivessem se afastando dos mainframes. Ele disse que a IBM não viu evidências de clientes abandonando a plataforma. Em vez disso, a empresa caracterizou a deficiência como um problema de timing concentrado em grandes acordos de capital.

A IBM informou que o desempenho do z17 permaneceu próximo de 130 por cento do programa z16 comparável. “Programa a programa” compara vendas ou capacidade instalada no mesmo ponto de ciclos sucessivos de produtos.

A empresa também disse que clientes representando 85 por cento dos MIPS instalados haviam mantido ou ampliado a capacidade. MIPS, ou milhões de instruções por segundo, é uma medida tradicional usada para descrever a capacidade de processamento de mainframes.

Esses números sustentam o argumento de que as cargas de trabalho centrais permanecem em operação. Eles também se ajustam à durabilidade histórica dos mainframes. As organizações continuam a usá-los porque substituir sistemas de transações profundamente integrados envolve riscos operacionais, de segurança e de conformidade.

Um grande banco, por exemplo, pode executar atualizações de contas, autorizações de cartões, verificações de fraude e processos de liquidação por meio de aplicações de mainframe. Migrar esses sistemas exige mais do que reescrever código COBOL antigo. A organização precisa preservar a integridade dos dados, o tempo de atividade, os controles de auditoria e as conexões com centenas de serviços posteriores.

Ferramentas de programação com IA podem reduzir parte do trabalho de modernização. Elas podem documentar aplicações antigas, explicar código desconhecido e ajudar a traduzir componentes selecionados. Elas não eliminam o risco institucional de substituir sistemas que processam transações críticas a cada segundo.

A posição da IBM, portanto, tem uma forte base técnica. Mainframes são difíceis de substituir porque estão inseridos em processos operacionais, não apenas em data centers. O custo de uma falha pode superar qualquer economia esperada com a migração.

No entanto, persistência técnica não garante um ciclo de hardware tranquilo. Os clientes podem manter cargas de trabalho em sistemas IBM enquanto prolongam a vida útil dos equipamentos, usam capacidade ociosa, negociam com mais firmeza ou transferem aplicações incrementais para outros ambientes.

Essa lacuna entre uso instalado e novos gastos é a tensão central. Os números da IBM mostram que a plataforma permanece ativa. Eles ainda não estabelecem que cada compra adiada retornará na escala original.

Krishna ofereceu um dado de curto prazo durante a discussão dos resultados. Ele disse que aproximadamente um terço dos grandes acordos que não foram fechados no segundo trimestre já havia sido concluído durante o terceiro trimestre.

Isso é uma evidência significativa de um problema de timing. Não representa uma recuperação completa. Dois terços ainda não haviam sido fechados quando ele falou, e a IBM não prometeu que todos se concretizariam sem mudanças de tamanho, prazo ou condições.

A interpretação pós-resultados da techcrunch captura essa distinção. A IA não eliminou a demanda pelo trabalho realizado pelos mainframes. Ela expôs como até sistemas essenciais precisam disputar aprovação dentro de orçamentos empresariais limitados.

A IBM também reduziu sua projeção de crescimento anual da receita em moeda constante para uma faixa de 4% a 5%. Antes, esperava crescimento acima de 5%. Uma redução na previsão é difícil de conciliar com a ideia de que cada negócio perdido apenas foi adiado por algumas semanas.

A administração pode acreditar que o negócio subjacente continua saudável, ao mesmo tempo em que reconhece que a oportunidade de receita do ano enfraqueceu. As duas afirmações podem ser verdadeiras. A plataforma pode perdurar, mas a IBM ainda precisa executar dentro do calendário usado pelos investidores.

A Verdadeira Disputa É Pela Prioridade Orçamentária, Não Mainframes Contra IA

O adversário da IBM não é um modelo de IA nem outro fornecedor de mainframes. É a urgência atribuída a cada compra concorrente de infraestrutura de IA.

Enquadrar a história como IA versus mainframes cria uma falsa escolha técnica. Grandes empresas precisam tanto de sistemas transacionais quanto de capacidade de IA. O conflito imediato surge quando líderes financeiros e de tecnologia decidem qual compra receberá financiamento primeiro.

Projetos de IA agora atraem a atenção de conselhos de administração, CEOs, equipes de segurança e líderes de unidades de negócio. Muitas organizações temem ficar para trás em relação aos concorrentes ou perder acesso a componentes escassos. Essa pressão aumenta o custo percebido de esperar.

Atualizações de mainframe têm uma justificativa diferente. Elas frequentemente protegem a resiliência, a capacidade e a eficiência de sistemas que já geram valor para o negócio. Seus benefícios podem parecer incrementais diante de uma nova iniciativa de IA que promete automação ou uma nova linha de produtos.

Essa assimetria afeta a IBM mesmo que sua tecnologia funcione conforme anunciado. Uma plataforma comprovada pode perder prioridade orçamentária para um projeto especulativo quando a liderança considera este último estrategicamente urgente.

Fornecedores concorrentes de infraestrutura se beneficiam dessa urgência. Sistemas centrados na Nvidia capturam gastos com computação acelerada. Provedores de nuvem em hiperescala oferecem acesso a modelos e infraestrutura de IA sem exigir que todos os clientes possuam o hardware subjacente.

Fornecedores de servidores, armazenamento, redes e memória também se beneficiam quando empresas constroem ambientes privados de IA. A IBM participa de partes desse mercado, mas a economia de seus mainframes continua exposta quando os compradores separam a capacidade de IA da infraestrutura transacional.

A IBM tentou conectar esses mundos. O z17 oferece suporte a processamento de IA integrado, enquanto o watsonx disponibiliza ferramentas para criar, governar e implantar IA. O software de nuvem híbrida da Red Hat ajuda organizações a executar workloads em ambientes privados e públicos.

A ideia estratégica é coerente: as empresas deveriam gerenciar IA ao lado dos sistemas e dados nos quais já confiam. No entanto, os compradores nem sempre adquirem tecnologia como uma arquitetura integrada. Responsáveis pelo orçamento podem financiar agora um cluster de IA urgente e revisitar a capacidade de mainframe mais tarde.

A consultoria deveria ajudar a IBM a superar essa divisão. Seus consultores podem conectar planos de IA a aplicações existentes, requisitos de governança e dados operacionais. Contudo, a receita de consultoria cresceu apenas 0,2% no trimestre, limitando as evidências de uma ampla aceleração nas implementações.

O software mostrou mais impulso. A receita da Red Hat cresceu 11%, enquanto os ativos adquiridos recentemente da HashiCorp e da Confluent tiveram desempenho forte, segundo a IBM. Esses negócios se alinham à infraestrutura híbrida, à implantação de aplicações e à movimentação de dados em tempo real.

Esse desempenho oferece à IBM várias formas de se beneficiar dos gastos empresariais com IA. Também torna a história mais complexa. A empresa pode ganhar por meio da Red Hat ou de software de dados enquanto sofre com vendas adiadas de mainframes e processamento transacional.

Os investidores precisam avaliar a composição, não apenas a exposição total à IA. A transferência de receita de uma pilha consolidada de alta margem para produtos diferentes pode alterar a rentabilidade, o timing das vendas e os relacionamentos com clientes.

O conflito de gastos também alcança os líderes de tecnologia que gerenciam sistemas existentes. Eles precisam decidir se modernizam perto do mainframe, migram workloads selecionados ou criam serviços de IA que acessam dados consolidados por meio de interfaces controladas.

Essa decisão exige um registro claro de escolhas arquiteturais, alegações de fornecedores, restrições de segurança e dependências operacionais. Uma base de conhecimento técnico pesquisável pode ajudar equipes a comparar esses materiais sem separar as decisões de seus documentos de origem.

Ainda assim, a documentação não pode resolver o dilema de investimento. A IBM precisa demonstrar que atualizar sua plataforma promove objetivos de IA agora, em vez de apenas preservar uma infraestrutura que os clientes já consideram indispensável.

O Que a Explicação da IBM Ainda Não Prova

A narrativa de atrasos temporários é plausível, mas um trimestre de continuidade não pode estabelecer que os gastos com IA deixaram inalterada a economia de longo prazo da IBM.

A primeira incerteza diz respeito aos negócios adiados restantes. O fechamento de aproximadamente um terço durante o terceiro trimestre sustenta a explicação da IBM. Mas também deixa uma parcela substancial sem resolução.

Grandes compras empresariais podem mudar após um adiamento. Clientes podem reduzir a capacidade, dividir pedidos, exigir condições diferentes ou transferir decisões de software relacionadas para outro ano orçamentário. Um negócio adiado não é o mesmo que uma carteira contratada.

A segunda incerteza envolve a pressão recorrente sobre componentes. A IBM vinculou a disrupção de junho à infraestrutura com oferta limitada e à expectativa de aumentos de preços. Se a disponibilidade de memória e servidores continuar difícil, os clientes poderão seguir priorizando essas compras.

Isso transformaria uma sequência temporária em um padrão repetido. Os mainframes continuariam operando, mas cada novo ciclo poderia começar atrás da infraestrutura de IA na fila de capital.

A terceira incerteza envolve a execução da IBM. Krishna afirmou explicitamente que a empresa não conseguiu se adaptar com rapidez suficiente. Essa admissão impede a administração de atribuir o resultado abaixo do esperado inteiramente a condições externas.

As equipes de vendas devem compreender os ciclos de aprovação dos clientes e as demandas orçamentárias concorrentes. Os sistemas de previsão devem identificar grandes negócios expostos a mudanças no fim do trimestre. As equipes de produto devem tornar o valor de IA do z17 suficientemente concreto para proteger a urgência da compra.

A IBM afirma que o z17 continua à frente do ciclo comparável do z16. Essa métrica merece interpretação cuidadosa, pois os programas de produto podem variar em timing de lançamento, composição de capacidade, concentração de clientes e reconhecimento de receita.

O número de MIPS instalados também mede a atividade da plataforma de forma mais direta do que a nova receita. Clientes que mantêm capacidade demonstram compromisso com os workloads. Isso não demonstra necessariamente entusiasmo em acelerar compras de hardware.

Reportagens independentes reforçam ambos os lados. A cobertura dos resultados preliminares documentou a diferença em relação às expectativas dos analistas e a dimensão da queda inicial das ações. Resultados posteriores mostraram que a IBM ainda gerou crescimento em software e em diversos produtos de infraestrutura distribuída.

O mercado possivelmente puniu mais do que uma única falha no hardware. O alerta da IBM levantou dúvidas sobre se os investimentos de capital em IA estão deslocando software e infraestrutura empresariais consolidados. Preocupações semelhantes podem afetar qualquer fornecedor cujos produtos disputem orçamentos fixos com projetos de IA.

No entanto, o caso da IBM não deve se transformar em uma regra universal. Seus resultados refletem sua composição de produtos, execução de vendas, ciclo de mainframes e base de clientes. Outra empresa de software pode enfrentar estruturas de renovação diferentes ou menor exposição a compras de capital.

Também há risco em tratar a reação das ações como um veredito técnico. Os mercados reprecificam expectativas, não arquiteturas. Uma queda acentuada indica que os resultados e as projeções divergiram fortemente das premissas dos investidores. Ela não demonstra que o mainframe perdeu seu papel operacional.

A conclusão mais defensável é mais restrita. Os gastos com IA desorganizaram a sequência esperada de negócios da IBM, e a IBM não conseguiu absorver essa disrupção. A empresa apresentou evidências iniciais de retorno da demanda adiada, mas a recuperação continua incompleta.

Essa conclusão respeita a diferença entre uma explicação crível e uma reviravolta comprovada. A IBM não precisa provar que IA e mainframes podem coexistir. Eles já coexistem. Ela precisa provar que essa coexistência produz o timing de receita e o crescimento esperados pelos investidores.

Três Sinais Decidirão se a Recuperação da IBM se Sustenta

O próximo trimestre precisa transformar a explicação da IBM em resultados mensuráveis nos negócios adiados, na capacidade de mainframes e no portfólio empresarial mais amplo.

O primeiro sinal é a taxa de fechamento dos grandes negócios que foram adiados a partir do segundo trimestre. A IBM afirmou que cerca de um terço já havia sido fechado. A próxima atualização deve mostrar se a maior parte do restante foi concluída e se manteve o escopo esperado.

Uma alta taxa de fechamento reforçaria o argumento do timing. Novos adiamentos sugeririam que os clientes estão reconsiderando mais do que as datas dos pedidos de compra.

O segundo sinal é o desempenho do z17 em relação ao ciclo do z16. A IBM afirma que o z17 continua próximo de 130% na comparação entre programas. Os investidores devem observar se essa vantagem persiste após o trimestre volátil.

Capacidade instalada estável ou em expansão sustentaria a alegação da IBM de que os clientes continuam comprometidos. Adições mais lentas de capacidade enfraqueceriam a conexão entre workloads essenciais e receita de novos sistemas.

O terceiro sinal é a composição da receita da IBM. A recuperação dos mainframes seria mais convincente se o software de processamento transacional melhorasse junto com a infraestrutura. A força contínua da Red Hat, do armazenamento e do Power mostraria que a IBM está capturando gastos relacionados à IA em outras áreas.

Essa composição é importante porque a IBM reduziu sua projeção anual de receita. Alguns negócios recuperados poderiam corrigir o timing trimestral sem restaurar a expectativa anterior de crescimento. Uma melhora sustentável exige contribuições de software, infraestrutura e consultoria.

A questão mais ampla é se a IBM consegue tornar o mainframe parte do orçamento urgente de IA, em vez da compra que espera atrás dele. Isso exige resultados específicos para os clientes, e não outra alegação geral de que o z17 foi criado para IA.

As empresas deveriam observar como os clientes da IBM implantam IA perto de dados transacionais regulados. Exemplos úteis incluem triagem de fraudes em tempo real, análise de risco, previsão operacional e suporte automatizado para aplicações legadas.

A segurança também continuará central. As organizações precisam de acesso controlado a registros sensíveis, trilhas de auditoria confiáveis e governança clara sobre as saídas dos modelos. Os mainframes têm vantagens nesses ambientes, mas a IBM precisa traduzi-las em projetos com orçamentos aprovados.

A narrativa pós-trimestre da techcrunch será, no fim, julgada por pedidos, capacidade, crescimento de software e projeções. Ela não será resolvida pela idade do COBOL nem por outra previsão de que sistemas legados estão prestes a desaparecer.

A IBM sobreviveu a várias gerações de tecnologia que deveriam substituir o mainframe. A sobrevivência já não é o teste exigente. O teste exigente é se a IBM consegue converter uma base instalada duradoura em crescimento enquanto a infraestrutura de IA absorve uma parcela cada vez maior da atenção dos clientes.

Para compradores empresariais, a resposta prática é acompanhar onde cada investimento adiado cria risco. Quais compras de IA são realmente sensíveis à oferta? Quais atualizações de mainframe protegem capacidade ou conformidade? Quais projetos dependem de dados compartilhados e, portanto, pertencem a uma única decisão arquitetural?

Mantenha essas respostas vinculadas a registros de reuniões, documentos de fornecedores e evidências operacionais. Um sistema pessoal de conhecimento pode preservar o raciocínio à medida que as premissas mudam.

A IBM afirma que o mainframe está atrasado, não morrendo. O próximo ciclo de resultados precisa mostrar que essa demanda adiada retorna antes que outra onda de gastos com IA o empurre para o fim da fila.