Há pouco mais de um ano , participei de uma reunião de inovação em uma grande empresa industrial brasileira. O CTO e o Diretor de Supply Chain apresentaram um piloto brilhante: uma torre de controle com inteligência artificial embarcada para orquestrar a logística e distribuição de uma das maiores empresas de Telecom do Brasil. Os dashboards eram impecáveis, desenhados com apoio de uma consultoria estratégica de renome, e os resultados preliminares, promissores.

Alguns meses depois, o projeto chegou à mesa do CIO para avaliação de integração, escalabilidade e segurança da informação. A resposta foi direta, quase cirúrgica:

"Isso não vai funcionar aqui nem por um milagre."

A torre de controle exigiria integrações com o ERP, TMS, WMS e uma infinidade de outros sistemas legados e havia sido concebida em uma arquitetura que não suportaria os volumes de dados reais, tampouco atendia aos requisitos de cibersegurança e privacidade dos dados da empresa. O custo de transformar a prova de conceito em piloto, e o piloto em uma aplicação corporativa, tornava o projeto economicamente inviável. A PoC era impecável, mas era incompatível com a arquitetura tecnológica das aplicações em produção na empresa.

Essa história não é ficção. E, mais importante: não é exceção. É a regra.

Uma verdade amarga sobre a qual ninguém quer falar

A McKinsey acompanha esse fenômeno há anos e suas pesquisas mostram consistentemente que cerca de 70% das iniciativas de transformação digital não entregam os resultados esperados. Um estudo conduzido com mais de 600 empresas em 2022 revelou que apenas 20% atingiram mais de três quartos dos ganhos de receita projetados e somente 17% alcançaram as economias de custo que esperavam.

A Gartner vai além: estima que 80% das organizações que buscaram escalar modelos de negócio digital simplesmente falharam ao longo dos últimos anos. A principal razão apontada não é a falta de tecnologia. É a falta de governança e de arquitetura para absorvê-la.

A Bain & Company, em análise de 2024, chegou a um número ainda mais sombrio: 88% das transformações corporativas não alcançam seus objetivos originais. Não porque as ideias fossem ruins. Mas porque a distância entre o laboratório e a operação real nunca foi devidamente endereçada.

No Brasil, o cenário é igualmente revelador. Grandes empresas como Bradesco, Itaú, Vale e diversas industriais investiram bilhões em ecossistemas de inovação, hubs digitais e programas de aceleração.

Resultados pontuais existem. Mas a pergunta que raramente se faz em público é: quantas dessas iniciativas realmente chegaram à escala operacional?

Dois executivos, duas agendas, um problema

Para entender por que isso acontece, é preciso primeiro compreender quem são os protagonistas desse conflito silencioso. E que as vezes nem é tão silencioso assim!

O CTO (Chief Technology Officer) é, em essência, o explorador. Sua missão é identificar novas plataformas, novas arquiteturas e novas aplicações e que em muitas vezes advêm de startups com soluções ainda não totalmente (ou minimamente) seguras, estáveis e confiáveis para, com isso, habilitar novos modelos de negócio por meio da tecnologia. Segundo pesquisa da Deloitte, 65% dos CTOs apontam inovação como prioridade número um. É um papel naturalmente orientado ao futuro, ao experimento, ao que ainda não existe dentro da empresa. Ele tende a ser a alegria das áreas de negócio: pragmático, orientado a soluções diretas, capaz de demonstrar resultados rápidos em ambiente controlado. E, sejamos honestos, há muita hype em torno de cada iniciativa — o que gera visibilidade e autopromoção para todos os envolvidos.

O CIO (Chief Information Officer) opera em outra lógica. Sua responsabilidade é fazer a empresa funcionar, hoje, amanhã e com segurança. Aqui sim, enquanto a segurança, estabilidade e confiabilidade são questões relevantes e, por sua vez, a governança, integração de sistemas, compliance, infraestrutura crítica, gerenciamento de risco tecnológico, auditorias anuais de SOX e de segurança da informação. Um relatório da Harvard Business Review Analytic Services revelou que, na percepção de muitos executivos, o CIO ainda passa boa parte do tempo em controle de custos e gestão de crises de TI — quando deveria, idealmente, estar co-criando estratégia de negócios.

Simplificando: o CTO explora o futuro com provações para mudar o negócio. O CIO precisa fazer esse futuro funcionar garantindo a continuidade do negócio.

Quando essas agendas convergem, a inovação escala. Quando divergem, e na maioria das empresas não-tech elas divergem sistematicamente, o resultado é o que o Vale do Silício já batizou de ‘PoC Graveyard’, o cemitério das provas de conceito.

A inovação que só funciona no PowerPoint ou no Figma

O problema tem uma anatomia bem definida. Laboratórios, áreas de inovação e equipes de P&D conseguem demonstrar tecnologias que parecem revolucionárias em escala reduzida. Um piloto com cinco usuários funciona. Um ambiente controlado, sem as rugosidades da operação real, entrega resultados impressionantes.

Por sua vez, o quadro muda completamente quando chega o momento de integrar essa inovação à operação da empresa, com seus sistemas legados acumulados ao longo de décadas, suas exigências de compliance regulatório, seus volumes reais de transações, seus requisitos de SOX e SIG, além da resistência cultural natural à mudança.

O CIO então faz a pergunta que o CTO raramente se faz durante o piloto: isso funciona para a empresa inteira? Uma solução que performa bem para cem usuários pode colapsar com mil. Uma plataforma que opera suavemente em ambiente isolado pode travar quando conectada a alguns poucos sistemas críticos. O custo de operação que parece razoável no piloto pode ser proibitivo em escala corporativa.

"Um pequeno grupo de inovação pode se dar ao luxo de enxergar pelo horizonte de três, cinco ou dez anos. Mas quando você tenta de fato dar esse passo — tornar a ideia real e escalá-la por toda a empresa — é aí que os desafios aparecem."

A observação é de Satya Jayadev, vice-presidente e CIO da Skyworks, e resume com precisão o problema. O desafio não é a inovação em si. É a ponte entre o laboratório e a operação.

Os casos que ensinam

No início dos anos 2010, o Walmart investiu pesado em laboratórios de inovação digital nos Estados Unidos. Muitas iniciativas eram tecnicamente sofisticadas. Mas apenas aquelas profundamente integradas à arquitetura existente da empresa, como suas plataformas de logística e analytics, sobreviveram ao teste da escala operacional. O restante foi silenciosamente descontinuado.

A GE, durante a criação da GE Digital, partiu de uma visão ambiciosa: transformar a empresa em uma potência de software industrial. A iniciativa gerou tecnologias genuinamente relevantes. Mas encontrou obstáculos severos para integrar essas soluções ao ecossistema global de uma companhia que opera em múltiplos setores industriais de altíssima complexidade. Parte da estratégia foi redimensionada, um eufemismo elegante para dizer que a realidade operacional venceu a visão do laboratório.

No Brasil, o caso mais emblemático é o do Bradesco. O inovabra (ecossistema de inovação do banco) se tornou referência no setor financeiro nacional. Em 2022, o banco investiu R$ 2,9 bilhões na área, com mais de 230 startups no ecossistema. Os resultados são reais: contratos firmados, soluções implementadas, cultura de inovação disseminada internamente. Mas o próprio Fernando Freitas, então superintendente de inovação do banco, foi honesto sobre o desafio: num processo interno, um projeto levava 13 meses para sair do piloto. A pressão crescente por startups em estágio maduro, séries A e B, reflete exatamente o aprendizado de que inovar é mais fácil do que absorver inovação em uma estrutura com décadas de sistemas críticos acumulados.

O contraponto mais revelador vem de onde menos se espera: o Cirque du Soleil. A empresa é conhecida por desafiar os limites da criatividade humana nos palcos. Nos bastidores, enfrentava um desafio diferente e igualmente complexo: uma infraestrutura de TI envelhecida, com décadas de customizações acumuladas e um time de tecnologia que chegou a encolher de 150 para apenas 13 pessoas durante a pandemia. Em vez de lançar pilotos de inovação desconectados da operação, Philippe Lalumière, VP de TI da companhia, fez o oposto: priorizou primeiro a reconstrução da fundação migrando para um Cloud ERP em menos de dois anos, com uma abordagem de MVP em duas fases para então avançar para iniciativas de inteligência artificial. O resultado foi um assistente de IA para gestão de faturas que reduziu o tempo de atendimento de 30 minutos para 2 minutos por consulta, já em produção e com potencial de evolução para um agente autônomo. A sequência fez toda diferença para escalar a inovação, criando primeiro uma fundação robusta simplificada e renovada para aí então construir a inovação sob esta arquitetura mais moderna.

A Amazon e a Netflix constroem a narrativa oposta ao PoC graveyard e por uma razão estrutural. Ambas nasceram digitais e construíram suas arquiteturas tecnológicas com escalabilidade como premissa, não como otimização posterior. A cultura de microserviços da Netflix e os princípios de arquitetura distribuída da Amazon, que geraram o AWS, não foram acidentes. Foram escolhas arquiteturais feitas antes de o problema existir.

É esse o ponto que separa quem escala inovação de quem acumula pilotos mal-sucedidos: uma arquitetura robusta, fundamentada em tecnologia de ponta vem antes da inovação.

O CIO não é o vilão, é o arquiteto da realidade

Há uma narrativa conveniente nas organizações que trata o CIO como o executivo que 'freia a inovação'. Na prática, ele é o executivo que protege a empresa da inovação mal estruturada que pode ser ainda mais cara do que simplesmente não inovar e provocar instabilidade sobre o negócio.

Segundo pesquisa da MIT Sloan, 71% dos CIOs já esperam exercer papel ativo na estratégia de negócios e na inovação nos próximos anos. O papel não é mais apenas de guardião da continuidade do negócio. É de engenheiro de mudança e um engenheiro que conhece o terreno, que sabe onde estão as fundações instáveis, os sistemas que não podem ser tocados sem risco, as interdependências invisíveis que qualquer piloto de laboratório ignora por definição.

Um levantamento da Harvard Business Review identificou que 54% dos CIOs acreditam que estratégia de TI e estratégia de negócio não estão suficientemente alinhadas em suas organizações. Curiosamente, 49% dos CTOs admitem que suas iniciativas tecnológicas não se refletem adequadamente nos objetivos estratégicos da empresa. Os dois lados reconhecem o problema. Mas raramente constroem a ponte juntos e antes do piloto começar.

O diagnóstico real: inovação sem arquitetura não escala

A raiz do problema não é tecnológica. É estrutural e cultural.

A McKinsey identificou que as empresas que investem em mudança cultural têm 5,3 vezes mais chances de sucesso em transformações do que aquelas que focam apenas em tecnologia. Cultura, mais do que ferramenta, determina se a inovação vira produto ou vira descarte.

No contexto específico do conflito CTO-CIO, isso significa que a inovação precisa ser desenhada para a empresa real, não para o laboratório ideal. Três mudanças concretas fazem a diferença:

Michael Porter já dizia que eficiência operacional não é estratégia. Da mesma forma, laboratório de inovação não é transformação. Inovação que não encontra caminho para a operação real é apenas custo sofisticado.

O elo perdido: o bridger

Mesmo quando as três condições acima estão presentes, o CIO envolvido desde o início, métricas de conversão estabelecidas e patrocínio do negócio garantido ainda existe um gap frequentemente invisível: quem, na prática, constrói e mantém as pontes entre esses mundos no dia a dia do projeto?

A edição de março/abril de 2026 da Harvard Business Review traz uma resposta direta. No artigo "Por que as grandes inovações falham ao escalar", Linda Hill (professora da Harvard Business School e uma das maiores autoridades em liderança de inovação) e seus coautores identificam o principal fator diferenciador entre organizações que escalam inovação e as que acumulam pilotos. Não é a tecnologia. Não é o orçamento. É um tipo específico de liderança que eles chamam de bridging, a capacidade de colaborar efetivamente através de fronteiras organizacionais.

"Nenhuma equipe ou empresa isolada tem todas as capacidades, ferramentas ou autoridade necessárias para mover ideias do protótipo à escala."

Os bridgers, como Hill os define, são líderes com inteligência emocional e contextual suficientes para construir confiança mútua, traduzir entre mundos com lógicas distintas e integrar os esforços de parceiros com agendas frequentemente conflitantes. Eles não fazem isso por meio de autoridade hierárquica. Fazem por meio de relacionamento, credibilidade e uma capacidade rara de fazer cada parte sentir que seus interesses estão sendo considerados.

No contexto do conflito CTO-CIO, o bridger é o executivo que consegue sentar ao mesmo tempo com o time de inovação e com o time de arquitetura e ser levado a sério pelos dois. Ele fala a língua do possível com o CTO e a língua do sustentável com o CIO. Ele não minimiza as restrições operacionais como burocracia nem descarta as ambições inovadoras como ingenuidade. Ele transforma a tensão entre essas perspectivas em design.

O caso da Delta Air Lines ilustra bem o que está em jogo. Nicole Jones, que construiu e liderou o The Hangar, o primeiro laboratório global de inovação da Delta, enfrentou exatamente o problema da integração entre inovação e operação. Quando seu time produziu uma tecnologia de embarque biométrico que exigia a coordenação de startups, times internos de TI e agências federais como a TSA, as tensões eram inevitáveis: o time de TI da Delta tinha aversão profunda ao risco depois de um apagão custoso no ano anterior. Jones não resolveu isso com autoridade formal. Resolveu lembrando constantemente a todos qual era a ambição compartilhada — melhorar a experiência de milhões de passageiros — e tornando explícito para cada parte como isso se conectava com suas próprias prioridades. A Delta foi, naquele ano, a primeira grande companhia aérea a estrear no Consumer Electronics Show.

O que torna o conceito de bridger especialmente relevante para o contexto das empresas não-tech é que ele não exige a criação de um novo cargo no organograma. É uma competência e uma que pode ser cultivada deliberadamente. Hill e seus coautores identificam que as organizações que colocam bridgers em posições-chave de inovação não apenas escalam mais rápido: elas criam um ambiente onde a confiança entre os times que precisam colaborar se torna um ativo permanente, não uma conquista frágil a cada novo projeto.

Em suma: arquitetura resolve o problema técnico da escalabilidade. Patrocínio do negócio resolve o problema de relevância estratégica. Enquanto o bridger  resolve o problema humano e faz as pessoas com agendas, incentivos e linguagens diferentes trabalharem juntas em direção a um objetivo que ainda não existe.

O equilíbrio que faz a diferença

O futuro das empresas que competem em um ambiente de intensa transformação tecnológica não depende apenas de quem lidera tecnologia. Depende de como esses papéis trabalham juntos e, principalmente, de quando e como começam essa conversa.

O CTO precisa explorar o que é possível. O CIO precisa garantir que o possível seja sustentável. O negócio precisa garantir que o que é sustentável seja também desejado com metas claras, KPIs definidos e comprometimento real com a adoção. E o bridger precisa garantir que essas três perspectivas se encontrem no momento certo, antes que os silos organizacionais transformem a divergência natural em conflito paralisante.

Quando esse quadrilátero funciona, inovação deixa de ser um laboratório caro e passa a ser vantagem competitiva real. Quando não funciona, quando o CTO constrói no vácuo, o CIO rejeita no final, o negócio não assume responsabilidade e não há ninguém construindo a ponte, o que deveria ser transformação vira apenas mais uma linha de custo no balanço.

Enterrada no cemitério silencioso das boas ideias que ninguém conseguiu escalar.