A resposta é direta: a maioria das empresas brasileiras já testou IA, mas só 13% conseguiu transformar esse teste em operação. É o que mostra um levantamento divulgado em outubro pela BearingPoint — quase três quartos das empresas pesquisadas já relatam resultado financeiro positivo com IA, mas menos de um terço passou do piloto. O gargalo citado com mais frequência não é convencer a liderança a testar: é fazer o piloto sobreviver ao encontro com o resto da empresa.
Os dois obstáculos mais citados no estudo são regulamentação (40%) e integração com sistemas de TI legados (34%). Para uma empresa de médio porte, isso tem um significado prático específico: o piloto de IA costuma nascer fora da TI — numa área de negócio, com uma ferramenta nova, um protótipo rápido — e trava exatamente no momento em que precisa conversar com o ERP, o CRM ou o sistema de dez anos que sustenta a operação. Resolver esse gargalo não depende de comprar mais IA. Depende de decidir, antes do piloto, como ele vai operar dentro do perímetro de sistemas que a empresa já tem.
Principais aprendizados
- Só 13% das empresas que testam IA conseguem escalar o piloto para operação, segundo levantamento divulgado em outubro pela BearingPoint — a barreira não é adoção, é execução.
- Os dois obstáculos mais citados são regulamentação (40%) e integração com sistemas de TI legados (34%), não falta de interesse ou de orçamento.
- Casos que escalam de fato têm em comum um escopo estreito e uma métrica de negócio clara — conversão, erro evitado, tempo de ciclo — em vez de “adoção de IA” como meta abstrata.
- Construir dentro do perímetro de ferramentas já aprovado pela TI evita o gargalo de integração, porque elimina a etapa de aprovar software novo antes de medir resultado.
- O tempo entre piloto e operação cai de meses para semanas quando o time de negócio participa da construção, com a TI definindo governança em vez de executar a demanda.
Por que só 13% das empresas conseguem escalar IA além do piloto?
Porque o piloto e a operação têm requisitos diferentes, e a maioria dos projetos de IA é desenhada só para o primeiro. Um piloto prova que o modelo funciona num recorte controlado de dados e processo. A operação exige que esse mesmo modelo continue funcionando quando alimentado pelos dados reais do ERP, quando precisa respeitar as mesmas regras de acesso que o resto do sistema, e quando o time jurídico ou de compliance pergunta como aquela decisão automatizada pode ser auditada. É nesse segundo conjunto de exigências — não no primeiro — que a maioria dos pilotos brasileiros está travando hoje, segundo o próprio levantamento.
O contraste fica claro em casos que já escalaram: o nível avançado de maturidade de IA no Brasil ainda é raro, mas quem chegou lá tratou a IA como parte de um processo de negócio com métrica própria, não como ferramenta genérica. O Banco do Brasil, por exemplo, levou 85% das transações mais usadas pelos clientes para o modo conversacional no app, divulgado em agosto — e o resultado que a empresa escolheu medir não foi “uso de IA”, foi conversão de Pix (+69%) e erro de digitação de chave (-21%). Esse é o padrão: escala vem de métrica de processo, não de ambição de ferramenta.
Minha empresa de médio porte tem o mesmo gargalo de integração com sistemas legados?
Provavelmente sim, e o sintoma mais comum é o piloto que funciona na demonstração e para na hora de entrar em produção — porque alguém precisa aprovar acesso a um sistema, ou porque o dado que o modelo precisa está em uma planilha paralela, não no sistema oficial. A saída que vemos funcionar na prática não é contratar mais ferramenta: é inverter a ordem do projeto. Em vez de a TI definir e construir a solução para o negócio — fila que em empresa média costuma levar meses —, o primeiro passo é mapear com a própria TI quais ferramentas e dados já estão aprovados para uso (Google Workspace, Microsoft Copilot, modelos corporativos já contratados), e então deixar o time de negócio construir dentro desse perímetro.
É essa lógica que estrutura o programa AMPLIFICA da HAIA: diagnóstico de ecossistema e governança primeiro, depois mapeamento dos gargalos por frequência × tempo × retrabalho, e só então construção — feita por quem conhece o processo, não por quem programa. Numa empresa de tecnologia B2B de médio porte, esse desenho permitiu estruturar um portfólio inteiro de controles de cibersegurança em 8 semanas, frente a uma estimativa tradicional de 9 a 12 meses para o mesmo escopo. Os resultados refletem o contexto, a maturidade e os processos de cada organização, e não constituem promessa de resultado equivalente em outros ambientes. O ponto não é a velocidade isolada: é que o gargalo de integração com sistema legado deixou de existir porque o projeto nunca saiu do perímetro que a TI já havia aprovado.
Quanto tempo leva, na prática, para transformar um piloto em operação?
Depende menos da complexidade técnica e mais de quanto tempo a empresa gasta esperando aprovação formal antes de testar dentro de um processo real. Em um programa de automação para o time de desenvolvimento (7 pessoas) de uma empresa de tecnologia, 60 dias de trabalho direto no gargalo produziram mais avanço mensurável em qualidade e segurança de produto do que 9 meses de execução de um plano formal de 18 meses que já estava em andamento antes do programa começar. A diferença não foi o modelo de IA usado — foi o projeto ter entrado direto no fluxo de trabalho real, com mentoria, em vez de passar por uma fase de especificação longa antes de qualquer teste em produção.
Para a empresa de médio porte, o critério prático para decidir se vale a pena acelerar um piloto específico é simples: ele já tem um processo claramente priorizado (não “a área toda”, um fluxo específico), um responsável de negócio nomeado, e uma métrica de resultado que pode ser medida em semanas, não em um relatório anual. Sem esses três elementos, qualquer piloto — mesmo tecnicamente bem-sucedido — tende a ficar estacionado na mesma fase em que 87% das empresas brasileiras estão hoje.
Perguntas frequentes
Por que meu piloto de IA funciona em teste mas não entra em produção?
Na maioria dos casos, porque o piloto foi desenhado para um recorte controlado de dados e não para o sistema real da empresa. Quando o modelo precisa acessar o ERP, respeitar as regras de permissão e passar por aprovação de TI, aparecem os mesmos dois gargalos que travam 87% das empresas brasileiras: integração com sistema legado e incerteza regulatória. Resolver isso exige desenhar o perímetro de dados e ferramentas aprovadas antes de escalar, não depois.
Preciso trocar de sistema para escalar um projeto de IA?
Normalmente não. O gargalo mais comum não é a capacidade técnica do sistema legado, é a ausência de um processo definido para aprovar e integrar uma solução nova dentro dele. Construir a automação usando as ferramentas que a TI já aprovou — em vez de contratar software adicional — costuma resolver boa parte do problema sem exigir substituição de sistema.
Quem deve liderar o projeto para ele sair do piloto: TI ou a área de negócio?
As duas, mas em papéis diferentes. A TI define o perímetro de governança — o que pode ser usado, com qual dado, sob quais regras. A área de negócio, que conhece o processo e sente o gargalo todos os dias, constrói e opera a solução dentro desse perímetro. Projetos que dependem só da TI para construir tudo tendem a entrar na fila e demorar meses a mais para escalar.
Quanto tempo leva para uma empresa de médio porte sair do piloto e chegar à operação?
Em programas estruturados, as primeiras automações já entram em operação durante o próprio programa, com ciclos de semanas em vez de meses — mas o fator decisivo é ter um processo priorizado e um responsável nomeado, não o tamanho da equipe de tecnologia. Sem esses dois elementos, mesmo um piloto tecnicamente maduro tende a ficar parado, como mostra o levantamento sobre os 13% que escalam.
