O principal obstáculo à adoção de IA em projetos de AECO tem origem organizacional. A tecnologia, na maioria dos casos, funciona bem o suficiente, mas um padrão que se repete, em empresas de portes variados, é: piloto aprovado, equipe animada, resultado no ambiente de teste, e seis meses depois o projeto real continuando a ser executado da mesma forma que antes.
Este artigo mapeia as causas mais recorrentes: o conflito econômico embutido no modelo de faturamento por hora, a dependência de dados de terceiros sem contratualização adequada e os cinco padrões organizacionais que determinam se uma iniciativa chega ao projeto real ou para na prova de conceito.
O que separa adoção de captura de valor
Na prática, adotar IA e capturar valor com ela são processos com requisitos diferentes, embora o setor costume tratá-los como um só. A adoção é a parte mais simples, que basicamente é escolher uma ferramenta, treinar a equipe, rodar um piloto. A captura de valor exige mudanças na estrutura econômica da empresa, nos papéis das pessoas e na forma como os dados são governados.
O MIT NANDA GenAI Divide (2025) registrou que 95% dos pilotos de IA generativa não produzem resultado mensurável de P&L (MIT NANDA GenAI Divide, 2025). O RAND, com diagnóstico mais granular, chegou a uma conclusão complementar: mais de 80% dos projetos de IA falham, e em 84% dos casos as causas são organizacionais, não técnicas (RAND Root Causes of Failure for AI Projects, 2024).
Os dois estudos olham ângulos ligeiramente diferentes, mas chegam ao mesmo diagnóstico: o obstáculo está na estrutura da empresa. A explicação passa pelo modelo de negócio, e raramente aparece nos relatórios de adoção de tecnologia
O conflito econômico que ninguém menciona
Empresas de AECO que faturam por hora carregam um conflito estrutural com qualquer iniciativa de automação.
Quando um engenheiro ou arquiteto automatiza uma tarefa que levava 4 horas e passa a levar 40 minutos, o escritório precisa decidir entre cobrar menos pelo mesmo entregável, reduzindo a receita da hora já vendida, ou realocar esse profissional para outras atividades, reconhecendo que a estrutura precisa mudar.
Mas o que observamos na maioria das empresas é a inexistência de processos para fazer essa realocação de forma organizada. A automação vira ferramenta paralela, usada quando conveniente, nunca integrada ao fluxo principal de produção. O piloto “funciona” porque ninguém depende dele para nenhuma atividade crítica ou porque ele não faz parte de nenhum processo estrutural da empresa.
O Autodesk State of Design & Make (2025) registrou que 40% dos líderes de construção apontam controle de custos como principal desafio, contra 23% que citam tecnologia e IA (Autodesk State of Design & Make, 2025). Num ambiente assim, revisões estruturais no modelo operacional competem com pressões imediatas de margem, e perdem.
Esse conflito não aparece no pitch de nenhuma ferramenta de IA mas é o que mais frequentemente determina se uma iniciativa escala ou não.
O segundo problema: dados que chegam de fora
Em projetos de AECO de maior porte, parcela expressiva do trabalho passa por subcontratados e consultores externos. Em grande parte dessas relações, os dados gerados (modelos, cronogramas, registros de campo, modelos BIM) não chegam ao sistema de controle do escritório principal em formato estruturado e utilizável.
Quando a automação depende desses dados e o terceiro sai do projeto, a iniciativa para também. O insumo que alimentava o processo simplesmente deixa de existir.
Estruturar essa entrega começa nos contratos, com especificação clara de formato, nomenclatura e periodicidade. Em estágios mais avançados de maturidade digital, a adoção de um Ambiente Comum de Dados (CDE) como repositório central de informações do projeto reduz ainda mais essa vulnerabilidade.
Esse problema é particularmente crítico no contexto brasileiro, onde a fragmentação de subcontratados em obras de maior porte é estrutural e os contratos raramente especificam obrigações claras sobre entrega de dados digitais.
Os padrões de falha
Depois de acompanhar iniciativas de IA em empresas de AECO de portes variados, identificamos cinco padrões que se repetem com frequência suficiente para ser tratados como diagnóstico.
O piloto sem métricas de referência: a empresa começa sem documentar os indicadores de partida e, ao final, não consegue demonstrar ganho algum, nem para o cliente nem para a própria diretoria.
O ROI apresentado depois: o caso de negócio é construído para justificar o que já foi implementado, não para orientar o que precisava ser medido desde o começo. São dois momentos do mesmo equívoco de governança, e um alimenta o outro, já que quem não definiu métricas de partida não tem como construir o caso de negócio com honestidade depois.
A ferramenta sem processo: é o mais visível, a IA é inserida num fluxo que não foi redesenhado para recebê-la, a etapa automatizada acelera, os gargalos migram para as etapas vizinhas, e o resultado líquido no projeto real fica próximo de zero.
O BIM manager como porteiro aparece quando esse papel é posicionado como aprovador de acesso a dados e sistemas, não por má intenção, mas pelo desenho organizacional, que faz cada iniciativa depender de aprovação técnica e reduz a velocidade de adoção sem que ninguém perceba.
A dependência de dados externos não estabelecida em contrato: a automação foi desenhada sobre dados que chegam de terceiros, mas os contratos não especificam obrigação de entrega em formato utilizável. Quando o subcontratado sai, o insumo da iniciativa some com ele.
O que muda quando o diagnóstico vem antes
Na FF Solutions, nenhuma iniciativa de IA com clientes de AECO começa pela escolha da ferramenta. O primeiro passo é mapear os cinco padrões descritos acima: baseline, processo, papéis, governança de dados e critério de retorno. Esse mapeamento considera, entre outros aspectos, como os fluxos de aprovação e revisão de dados do projeto estão organizados, já que é nesse ponto que a maioria das iniciativas encontra resistência organizacional.
Esse mapeamento leva entre uma e três semanas, dependendo da complexidade da operação, e é o que determina se o piloto tem condição de chegar ao projeto real ou se já começa inviabilizado.
Vale ser honesto sobre o limite do diagnóstico, dado que ele não é uma garantia de sucesso. Há projetos em que os cinco padrões estão sob controle e a iniciativa trava mesmo assim, por mudança de liderança, contrato renegociado, prioridade redefinida no meio do caminho. O que o diagnóstico faz é eliminar as causas evitáveis antes de comprometer tempo e orçamento, e criar o registro de onde a operação estava quando o projeto começou (o único dado que permite avaliar com honestidade o que foi alcançado).
Nenhum dos cinco padrões tem origem técnica, todos têm resolução organizacional, o que significa que a empresa que decide trabalhar cada um deles, não depende de uma nova ferramenta para começar.
Você pode se interessar pelo episódio BIM e Inteligência Artificial: a nova era da transformação do nosso I Love BIM Cast:
