O falso paradoxo do ROI em tecnologia: gestão não é desculpa para entregar mal

O investimento que não aparece no balanço

Todo CTO já passou por isso. Você apresenta o roadmap do próximo trimestre, com entregas de infraestrutura, adoção de novas ferramentas de IA e modernização de sistemas legados. O CFO pergunta: "quando isso vai aparecer no P&L?" E você responde algo como "no médio prazo", enquanto sente o desconforto de não ter uma régua objetiva para a conversa. O dado de que 35% das empresas não conseguem demonstrar retorno mensurável sobre seus investimentos em tecnologia não me surpreende. Ele apenas cristaliza um sintoma que venho observando em dezenas de organizações — incluindo algumas onde trabalhei diretamente.

A narrativa corrente, reforçada pelo artigo da Falconi Consultoria publicado no Valor, coloca a culpa na gestão. Diz que o problema é a falta de alinhamento entre tecnologia e estratégia de negócios. Isso é verdadeiro, mas incompleto. Trata-se de uma meia-verdade perigosa porque absolve times de engenharia e produto de suas próprias responsabilidades técnicas. O paradoxo só existe se insistirmos em separar gestão e execução como se fossem camadas independentes. Na prática, uma decisão de arquitetura mal tomada gera o mesmo efeito que uma decisão de portfólio equivocada: valor que não se materializa.

Onde o ROI realmente morre: dentro do repositório de código

Passei os últimos anos observando um padrão incômodo. Empresas contratam plataformas caras de inteligência artificial, montam squads ágeis com nomes de pokémon, compram ferramentas de observabilidade e, ainda assim, os indicadores de negócio não se movem. A explicação convencional é que "a cultura não mudou" ou "o patrocínio executivo é fraco". Discordo. Na maioria dos casos que vivenciei, o valor simplesmente não foi construído — porque a engenharia tratou a feature como um projeto de tecnologia, não como um produto de negócio.

Um exemplo concreto: uma empresa de logística decidiu implementar um modelo de roteirização baseado em machine learning para reduzir custos de combustível. O time de dados passou seis meses treinando modelos, comparando accuracy, montando pipelines em Spark. O modelo funcionava lindamente nos testes offline. No mundo real, o custo de combustível não caiu. Por quê? Porque a roteirização ótima esbarrava em restrições operacionais que a engenharia não modelou — janelas de entrega dos clientes, disponibilidade de motoristas, regras sindicais. O time entregou a funcionalidade certa do ponto de vista técnico, mas errada do ponto de vista do negócio. Isso não é falha de gestão. É falha de engenharia de produto.

A multiplicação não acontece por acaso: ela exige um integrador

A tese central do artigo da Falconi é que gestão e tecnologia se multiplicam, não se somam. Concordo plenamente, mas com uma ressalva importante: essa multiplicação só acontece quando existe uma função integradora que traduz decisões técnicas em resultados de negócio em tempo real. O CTO não pode ser apenas o guardião da arquitetura. Ele precisa ser o tradutor entre o que o modelo de IA faz e o impacto que isso gera no fluxo de caixa.

Nas empresas onde vi isso dar certo, existia um papel que informalmente chamávamos de "engenheiro de valor". Não era um PM genérico nem um arquiteto corporativo. Era alguém capaz de olhar para um sprint de desenvolvimento e dizer: "essa história entrega 0,3% de redução de churn nos próximos 30 dias, e aqui está o experimento que vamos rodar para comprovar". Esse papel não aparece em organogramas tradicionais, e é justamente por isso que 35% das empresas patinam. Elas têm diretores de tecnologia e diretores de negócio, mas não têm conectores que operem na interseção.

O modelo mental errado sobre tecnologia como centro de custo

Outro ponto que o artigo tangencia, mas não aprofunda, é a armadilha contábil de tratar tecnologia como centro de custo. Ouvi recentemente um CFO dizer: "a área de TI custa 15 milhões por ano, e eu não vejo o retorno". O problema começa aí. Enquanto a tecnologia for tratada como despesa, o ROI será medido em redução de custo — e não em geração de valor. É um viés que leva a decisões míopes: terceirizar o que deveria ser core, comprar SaaS barato que não escala, cortar squads de produto no deserto da otimização fiscal.

A alternativa não é virar a chave magicamente para "centro de lucro". É criar mecanismos de rastreabilidade que liguem cada commit a um resultado de negócio. Isso não é utopia. Empresas como a Amazon fazem isso há décadas com seus "flying memos" e métricas de unidade econômica. Na prática, significa que todo time de engenharia precisa ter uma definição clara de qual métrica de negócio está tentando mover. Não adianta ter OKRs que dizem "aumentar disponibilidade do sistema para 99,99%". Isso é métrica técnica, não de negócio. O desdobramento precisa chegar a "cada 0,01% de indisponibilidade custa R$ 200 mil em vendas perdidas". Quando a equipe entende o custo real, as prioridades mudam.

Inteligência artificial: o multiplicador que também pode ser o divisor

Dado que a categoria editorial é IA aplicada, é obrigatório abordar o papel específico da inteligência artificial nessa equação. A IA é, potencialmente, o maior multiplicador de performance organizacional desde a internet. Mas ela também carrega uma armadilha singular: a ilusão de que tecnologia sozinha resolve problemas de processo.

Em 2023, atuei na revisão de uma implementação de LLM para atendimento ao cliente em uma fintech. O modelo era excelente — respostas precisas, latency baixa, compreensão contextual avançada. O NPS do atendimento, porém, caiu. A razão? O modelo respondia corretamente, mas o fluxo de escalonamento continuo manual. O cliente recebia a resposta correta, mas se o problema não era resolvido ali, caía em um funil de atendimento humano que não estava preparado para lidar com o contexto já processado pela máquina. O ganho de eficiência na primeira camada foi anulado pela ineficiência na segunda. A IA não é um patch que corrige processos quebrados. Ela é um amplificador: acelera o que já funciona e acelera também o que não funciona.

Métrica que importa: do deploy ao resultado de negócio

A discussão sobre ROI em tecnologia frequentemente esbarra em um problema metodológico: o que medir? Em engenharia de software, somos obcecados por DORA metrics — frequência de deploy, lead time, MTTR. São métricas excelentes para saúde do time de engenharia, mas péssimas para demonstrar valor ao negócio. O CFO não se importa se o deploy passou de semanal para diário. Ele quer saber se a receita aumentou ou o custo diminuiu.

A ponte entre esses dois mundos é o que chamo de "métrica de impacto intermediário". Por exemplo: não basta medir que a equipe de dados reduziu o tempo de treinamento do modelo de 4 horas para 30 minutos. É preciso conectar isso a quanto mais experimentos o time de produto conseguiu rodar, e quantos desses experimentos geraram aumento de conversão. No fim da cadeia, cada 30 minutos economizados em treinamento de modelo pode representar X mil reais em receita incremental.

Construir essa cadeia de causalidade é o trabalho mais difícil em tecnologia hoje. Exige instrumentação de produto, engenharia de plataforma madura e, acima de tudo, disciplina para não pular etapas. Muitas empresas tentam pular direto para o ROI sem ter as métricas intermediárias. O resultado é um dashboard bonito que não convence ninguém — especialmente o conselho.

Quando investir em tecnologia não vale a pena

Aqui vai uma opinião impopular: nem todo investimento em tecnologia precisa ter ROI demonstrável. Existem investimentos defensivos — segurança da informação, compliance, modernização de dívida técnica — que não geram valor imediato, mas evitam perdas catastróficas. O problema é quando toda a carteira de investimentos é composta por projetos desse tipo. Aí a tecnologia vira um seguro caro, não uma alavanca de crescimento.

Na minha experiência, a proporção saudável é 70/20/10: 70% dos investimentos em tecnologia com ROI claro e mensurável (geralmente automação e otimização), 20% com ROI provável mas de prazo mais longo (plataformas, capacitação de times) e 10% com ROI incerto mas potencial disruptivo (P&D em IA, novos mercados). Quando uma organização não consegue demonstrar retorno em 35% dos projetos, isso indica que a maior parte da carteira está no quadrante errado — ou, pior, que a medição é tão falha que mesmo projetos bons não conseguem se provar.

O papel real do CTO nesse cenário

Encerro com uma reflexão sobre o papel da liderança técnica. Durante anos, o CTO idealizado era aquele que dominava arquitetura, escolhia tecnologias e mantinha os sistemas no ar. Isso não é mais suficiente. O CTO de 2026 e 2027 precisa ser, acima de tudo, um tradutor de valor. Precisa sentar com o CFO e explicar por que investir em uma plataforma de feature flags vai acelerar o time-to-market e, consequentemente, a receita. Precisa mostrar ao conselho que a migração para cloud não é só redução de custo de data center, mas sim capacidade de rodar experimentos de IA que nenhum concorrente consegue.

A tecnologia está deixando de ser uma função de suporte para se tornar o motor central de estratégia empresarial. Mas isso impõe uma responsabilidade que muitos tech leaders ainda não abraçaram: aprender a falar a língua do negócio sem perder a profundidade técnica. O custo de não fazer isso é o dado de 35%. E esse número, acredite, é otimista — em muitos mercados que atendo, é bem maior.

O paradoxo que o artigo da Falconi descreve não é insolúvel. Mas a solução não está em melhorar apenas a gestão ou apenas a tecnologia. Está em construir uma organização onde cada linha de código escrita tenha um endereço de entrega de valor. E isso, meu caro colega engenheiro, não é problema do gerente. É seu.