O Diagnóstico Que Ninguém Quer Vender

Por que 99% do investimento em AI vai para substituir sistemas que nunca foram compreendidos à partida.

Há algo quase enigmático na forma como as empresas adotam AI.

Gastam-se milhares de milhões. Milhares de projetos estão em marcha. Cada consultora tem uma prática dedicada. Cada fornecedor tem uma plataforma. Cada CTO tem um slide deck.

E 99% do esforço aponta na mesma direção: acrescentar AI como uma camada de automação. Substituir humanos. Traduzir código. Gerar de raiz. Construir agentes que fazem o que as pessoas costumavam fazer.

Quase ninguém está a fazer a pergunta que deveria vir primeiro.

E se usássemos a AI para compreender o que já temos — antes de nos apressarmos a substituí-lo?

A sequência que se repete sem parar

Uma organização opera uma plataforma que funciona. Funciona há anos. Talvez décadas. Processa milhões de transações, gere fluxos de trabalho críticos, trata operações batch de que o negócio depende todas as manhãs.

A plataforma não é glamorosa. Não fotografa bem para os relatórios anuais. Mas funciona.

Depois alguém decide que precisa de ser modernizada.

Não porque deixou de funcionar. Porque deixou de parecer moderna.

Um projeto é aprovado. Uma consultora é contratada. Apresenta-se um slide deck com palavras como transformação, agilidade, cloud-native, AI-enabled. O orçamento é aprovado. O calendário é ambicioso.

E a primeira coisa que acontece é: construir o substituto.

Não compreender o que existe. Não documentar as dependências. Não mapear o conhecimento que vive nas cabeças das três pessoas que operaram o sistema durante vinte anos. Não testar se os procedimentos de recuperação ainda funcionam com a infraestrutura de hoje.

Construir o substituto.

O diagnóstico é saltado. Todas as vezes.

Porquê?

Esta é a parte que devia inquietar quem pensa nisto com cuidado. O diagnóstico não é saltado porque as pessoas são estúpidas. É saltado porque todas as forças do ecossistema empurram contra ele.

A consultora não vende diagnóstico. Vende transformação. Uma avaliação diagnóstica dos sistemas existentes é um projeto pequeno — semanas, não anos. Margem baixa. Difícil de dotar com consultores júnior porque exige perícia de domínio profunda. E, pior de tudo, o diagnóstico pode concluir que o sistema existente não precisa de ser substituído — o que elimina por completo o projeto de transformação. Nenhuma consultora tem incentivo para vender o projeto que pode cancelar o maior.

O fornecedor não vende melhoria. Vende uma nova plataforma. Cada roadmap de fornecedor aponta para a frente: novas funcionalidades, novas versões, novas arquiteturas. A conversa é sempre sobre o que deve comprar a seguir, não sobre como extrair mais valor do que já possui. Não há modelo de receita para «ajudar o cliente a perceber que não precisa de comprar nada».

O CEO quer uma narrativa, não um diagnóstico. «Estamos a investir em transformação movida a AI» cabe num slide para o conselho. «Passámos três meses a compreender o que temos, e afinal a maior parte funciona bem — só precisávamos de melhor documentação e governação» não cabe. Os incentivos executivos recompensam a mudança visível, não a melhoria invisível. Um diagnóstico que conclui «melhorem o que existe» parece uma não-decisão, mesmo quando é a conclusão mais valiosa possível.

O fator medo é real. Quando a AI é enquadrada como uma tecnologia de substituição, toda a gente a jusante ouve a mesma mensagem: o teu emprego está em risco. Isto cria uma dinâmica perversa. As pessoas que melhor compreendem os sistemas existentes — aquelas cujo conhecimento é mais crítico para qualquer transição inteligente — são as menos propensas a contribuir abertamente para um projeto que se posiciona como a sua substituição. O conhecimento é acumulado, não partilhado. A cooperação torna-se defensiva. E a própria perícia necessária para tomar as decisões certas passa à clandestinidade.

A máquina de compras não o consegue processar. As compras empresariais estão desenhadas para projetos grandes e estruturados com entregáveis definidos ao longo de 12 a 24 meses. Uma avaliação diagnóstica de três semanas por um único especialista sénior não encaixa no modelo. É demasiado pequena para um RFP formal. Demasiado especializada para um acordo-quadro. Demasiado rápida para um comité de acompanhamento. O sistema está construído para comprar grande, não para comprar inteligente.

Estas forças não se coordenam. Não precisam. Empurram todas na mesma direção de forma independente — rumo à substituição, rumo ao novo, rumo à transformação. E para longe da única coisa que deveria acontecer primeiro.

O que se perde

Quando o diagnóstico é saltado, as consequências não aparecem de imediato. Acumulam-se.

O conhecimento sai porta fora. Os especialistas que construíram e mantiveram os sistemas existentes estão a reformar-se. Em todos os ambientes onde trabalhei ao longo das últimas três décadas, o mesmo padrão repete-se: três a cinco pessoas carregam 80% do conhecimento operacional. Esse conhecimento nunca foi documentado — não porque a documentação tenha sido recusada, mas porque o conhecimento operacional é experiencial, contextual, e está embebido em decisões tomadas há anos que ninguém registou. Quando essas pessoas saem, o conhecimento sai com elas. Permanentemente.

A AI é a primeira tecnologia da história que poderia ajudar a captar este conhecimento à escala — a ler código, a mapear dependências, a extrair regras de negócio, a documentar o que existe. Mas em vez de usar a AI para este trabalho urgente de preservação, estamos a usá-la para construir substitutos dos sistemas cujo conhecimento ainda não captámos.

A ironia é atordoante.

As migrações acrescentam em vez de substituir. Quando não se compreende o que se tem, não se consegue desligá-lo. A nova plataforma entra em produção. A velha plataforma fica. O que era suposto ser uma migração torna-se uma adição. Onde havia um sistema, há agora dois — ou três, ou quatro — cada um com os seus próprios modos de falha, modelo de suporte, e equipa de consultores a tentar compreender interfaces entre componentes que nunca foram desenhados para coexistir.

Vi este padrão consumir centenas de milhões de euros em várias organizações. Não porque a tecnologia falhou, mas porque ninguém diagnosticou o que precisava de migrar, o que podia ser melhorado no lugar, e o que devia simplesmente ser deixado em paz.

Os pontos únicos de falha multiplicam-se. Cada dependência não documentada é uma falha à espera de ser descoberta. Cada regra de negócio embebida em código que ninguém analisou é um risco que nenhum plano de testes cobre. Cada batch job a correr sem um responsável documentado é um incidente potencial que ninguém saberá como resolver.

Estes não são riscos teóricos. Materializam-se às 3 da manhã, quando um processo crítico falha e a única pessoa que sabia como funcionava deixou a empresa há dezoito meses.

A sequência certa

Há uma abordagem diferente. Não é revolucionária. Não é entusiasmante o suficiente para uma keynote de conferência. Mas funciona.

Passo um: diagnosticar. Antes de mudar seja o que for, compreenda o que existe. Mapeie as dependências. Documente as regras de negócio. Identifique o conhecimento que vive nas cabeças das pessoas e não foi escrito. Encontre os processos mortos que consomem recursos sem servir qualquer função de negócio. Classifique cada componente por risco, criticidade e manutenibilidade. Este é o trabalho que a AI acelera de forma extraordinária — e o trabalho que quase nunca é financiado.

Passo dois: melhorar. Corrija o que pode ser corrigido sem introduzir nova complexidade. Otimize os caminhos de execução. Documente os procedimentos de recuperação e verifique que de facto funcionam. Remova código morto, jobs mortos, processos mortos. Capte o conhecimento dos especialistas que estão mais perto da reforma. Só isto — sem qualquer mudança de plataforma, sem qualquer migração, sem qualquer transformação — entrega muitas vezes mais melhoria mensurável do que os primeiros dois anos de um programa de substituição.

Passo três: decidir. Agora — com um quadro completo do que existe, do que funciona, do que não funciona, e do que está em risco — tome a decisão sobre o que, se é que algo, precisa de ser substituído. O diagnóstico pode revelar que uma migração é genuinamente necessária. Pode revelar que a plataforma existente, devidamente mantida e documentada, tem mais uma década de vida. Ou pode revelar uma abordagem híbrida: modernizar alguns componentes, preservar outros, retirar o resto.

O ponto é que a decisão é tomada com evidência, não com slide decks.

Por que isto importa agora

A pressão para agir é real. Requisitos regulatórios como o DORA e a NIS2 exigem resiliência operacional. Os especialistas que construíram sistemas críticos estão a aproximar-se da idade da reforma em todos os setores. As capacidades de AI avançam a um ritmo que cria urgência genuína.

Mas urgência sem diagnóstico é pânico. E o pânico produz erros caros.

As organizações que navegarão esta transição com sucesso não são as que se movem mais depressa. São as que compreendem o que têm antes de decidir o que mudar.

Essa compreensão — essa capacidade diagnóstica — é o serviço mais valioso e mais subvalorizado nas TI empresariais hoje. Não porque seja tecnicamente difícil, mas porque ninguém no ecossistema tem incentivo para o vender.

Exceto, talvez, os especialistas que passaram décadas a construir os sistemas que todos os outros se apressam agora a substituir.

Da próxima vez que alguém lhe apresentar um programa de transformação, faça uma pergunta: «O que é que o diagnóstico encontrou?».

Se não houve diagnóstico, não está a comprar transformação. Está a comprar pressupostos.