O artigo anterior argumentou que as dificuldades da adoção de IA em AEC são estruturais, não motivacionais. Este post mostra o que fazer a respeito, com quatro pilares que se encaixam em como o segmento AEC realmente funciona, em vez de como os playbooks de SaaS presumem que funciona.
Os pilares são diagnóstico de maturidade por função, mensuração de ROI vinculada à lógica econômica de projetos, gestão de mudança desenhada para execução subcontratada, e um caminho de protótipo à produção que não depende de ter uma equipe interna de desenvolvimento.
Adotar IA de forma estruturada em AEC exige quatro frentes trabalhando juntas, diagnóstico de maturidade por função, mensuração de ROI separada por categoria de ganho, gestão de mudança pensada para cadeias subcontratadas e um caminho de protótipo à produção que não dependa de equipe de TI dedicada.
A Parte 1 desta série mostrou que os bloqueios são de ordem estrutural, este post mostra o que fazer com essa leitura na prática, pilar a pilar.
Como fazer o diagnóstico de maturidade de IA em AEC
A maioria dos modelos de maturidade avalia a empresa como um todo, esse enquadramento é útil para apresentações executivas, mas praticamente inútil para colocar em prática. As funções dentro de uma empresa do segmento AEC têm formatos de dados diferentes, atritos culturais diferentes e perfis de ROI diferentes. Tratá-las como um bloco único achata decisões que deveriam ser tomadas no nível da função.
Os dados do 2025 State of Design & Make sugerem essa mudança. Entre 2024 e 2025, a parcela de respondentes que se descreveu no “meio do esforço” de adoção de IA subiu de 25% para 31%, enquanto os que relataram estar “perto da meta” caiu de 48% para 31%. O dado é global, o relatório não isola essa métrica por segmento, mas nada indica que AECO fuja do padrão. Empresas que achavam estar perto da maturidade perceberam que estavam no meio de um processo mais longo. O quadro por função era mais confuso do que qualquer média sugere.
Uma leitura função por função produz uma triagem mais precisa. A autoria de projetos é majoritariamente um trabalho individual, preso a arquivos e sujeito às limitações das ferramentas, enquanto a coordenação é ainda mais complexa, sendo multidisciplinar e lenta por ciclos de revisão que envolvem pessoas que não compartilham o mesmo parque tecnológico. As operações de projeto são um problema diferente, altamente centradas em produção documental e limitadas pelo volume de solicitações de revisão e submissões. Cada uma dessas funções exige um primeiro passo diferente, o que explica por que tratá-las como uma iniciativa única produz o resultado “compramos uma ferramenta e nada aconteceu” como mencionado no artigo anterior.
Medir o ROI segundo a lógica econômica de projetos de AEC
Não existe um conjunto de dados público e claro sobre ROI de IA específico para AEC. O estudo da PwC com 1.217 empresas encontrou que os 20% mais aptos em IA alcançam 7,2 vezes o desempenho financeiro gerado por IA em relação ao restante. Esse número é de vários setores do mercado e direcional, vindo de uma consultoria com interesse comercial em reforçar a urgência de agir, então trate o 7,2x como um sinal sobre a distância entre líderes e o restante, não como um benchmark para AEC.
Um enquadramento mais útil para AEC é separar três categorias de ROI e medir cada uma pelos seus próprios critérios.
Economia de tempo em autoria: Fácil de medir em horas por entregável. A força real está na agregação, porque a economia, multiplicada por muitos usuários que poupam algumas horas por semana, se torna significativa mesmo em nível executivo. O desafio está na conversão, já que não dá para saber com certeza se as horas poupadas viram produtividade ou se dissipam em outras tarefas.
Economia de tempo em coordenação: Reflete diretamente a lógica econômica do projeto. Redução de clashes, redução de solicitações de revisão, ciclos de aprovação mais rápidos. Valor médio em dinheiro quando o projeto é grande, às vezes mais alto. O problema é a atribuição, porque a maioria das empresas não mantém métricas de comparação, então mesmo equipes que alcançam ganhos reais de coordenação muitas vezes não conseguem provar que os ganhos vieram da IA, e não de uma melhora no próprio trabalho.
Retrabalho evitado: Maior valor em dinheiro, o mais difícil de medir com precisão. O argumento de “se não tivéssemos identificado isso, teria custado X” é difícil de comprovar, mas a magnitude importa.
Uma empresa que mede apenas o tempo de autoria no nível do fluxo de trabalho vai concluir que a IA trouxe ganhos de um dígito só, enquanto uma empresa que acompanha as três categorias em todo o portfólio de projetos enxerga o quadro real.
Gestão de mudança para um setor que subcontrata a execução
O Wharton Blueprint for AI Agent Adoption identifica três atritos psicológicos à adoção: competência percebida, confiança e delegação de controle. A pesquisa mostra que preocupações com controle sozinhas respondem por 26% da decisão de adoção. As pessoas não delegam a sistemas que não conseguem revisar, pausar ou reverter com facilidade.
Em AEC há uma nuance a mais. A empresa que adota a IA frequentemente não é a que realiza o trabalho em campo. Uma empresa de projeto pode automatizar a detecção de clashes dentro do Revit. O subcontratado que lê os desenhos revisados está em outro parque tecnológico, com outros incentivos e métricas de performance. A gestão de mudança, portanto, acontece duas vezes: uma dentro da empresa que adota, outra na transição para a execução.
O BIM manager está exatamente nesse ponto de junção. Quando posicionado como filtro de acesso a dados e sistemas, o BIM manager desacelera a adoção, posicionado como ponto de conexão entre intenção de projeto e execução subcontratada, ele acelera. O enquadramento da Deloitte no State of AI Agents Report de 2026 é direto: “workforce transformation will determine who wins” (a transformação da força de trabalho vai determinar quem vence). Em AEC, a transformação da força de trabalho não diz respeito só à sua própria equipe, mas também a como o próximo elo da cadeia absorve o que a IA acabou de produzir.
O caminho do protótipo à produção
O playbook diz: definir um caso de uso, financiar um ciclo de desenvolvimento de 12 meses, avaliar os resultados e só então escalar. Poucas empresas do segmento AEC fora do primeiro escalão têm a capacidade de TI para sustentar esse ciclo, e é isso que deixa a premissa de “implantar IA em toda a empresa” escondendo um backlog de desenvolvimento que, na prática, não existe.
O que mudou no último ano foi o quanto a prototipagem ficou mais barata. Frameworks como o Model Context Protocol permitem que especialistas de domínio, incluindo BIM managers, construam ferramentas funcionais conectadas a softwares em uso, sem passar por um ciclo de desenvolvimento tradicional. A equipe da Accenture entrevistada para o State of AI Agents Report de 2026 da Anthropic descreve o MCP como peça-chave de infraestrutura para comunicação de agentes com estado e resiliente. Na prática, isso significa que ferramentas que antes exigiam trimestres de esforço de TI agora podem ser prototipadas em poucos dias pela própria pessoa que precisa delas.
Isso não resolve a implantação em escala corporativa, mas resolve o gargalo identificado no primeiro artigo: a baixa capacidade de TI por empresa. Um BIM manager capaz de montar um dashboard funcional conectado ao Revit em uma semana muda a lógica de custo do desenvolvimento interno de ferramentas.
Mais que a soma das partes
Pilares implementados isoladamente produzem dashboards. Pilares implementados em conjunto produzem capacidade.
Uma empresa que diagnostica a maturidade por função, mas nunca ajusta como mede o ROI, vai reportar progresso sem ver retorno. Uma empresa que acerta a mensuração de ROI, mas ignora a transição para o subcontratado, vai ver os ganhos de autoria evaporarem na camada de execução. E empresas que resolvem as duas coisas, mas não têm um caminho de protótipo à produção, continuam esbarrando na parede da capacidade de TI em ferramentas que deveriam levar uma semana para ficar prontas.
O próximo artigo desta série demonstra como é uma dessas ferramentas na prática: um dashboard conectado ao Revit, construído como um artifact do Claude usando MCP, que acompanha a evolução de um modelo ao longo dos ciclos de revisão. É uma fatia pequena do gap de implementação, mas mostra a forma do que o playbook produz quando os pilares estão alinhados.
Uma versão em inglês deste conteúdo também foi publicada na comunidade Autodesk Expert Elite.
FAQ – Perguntas frequentes
Os quatro pilares são diagnóstico de maturidade por função, mensuração de ROI separada por categoria de ganho, gestão de mudança adaptada para cadeias subcontratadas e um caminho de protótipo à produção que não dependa de equipe de TI dedicada. Implementados como sistema, produzem capacidade operacional. Tratados de forma isolada, produzem relatórios de progresso sem retorno visível.
Funções de autoria, coordenação e operações de projeto têm formatos de dados distintos, atritos culturais diferentes e perfis de ROI que não se somam. Um diagnóstico por empresa produz uma média que serve para apresentação executiva, mas não orienta nenhuma decisão prática. O primeiro passo correto para adoção de IA varia conforme a função que será trabalhada.
O enquadramento mais útil separa três categorias: economia de tempo em autoria (mensurável em horas por entregável), economia em coordenação (refletida em redução de clashes e ciclos de revisão) e retrabalho evitado (maior valor em dinheiro, mais difícil de atribuir). Empresas que medem só autoria veem ganhos modestos. Quem acompanha as três categorias no portfólio enxerga o retorno de outra forma.
Em AEC, a empresa que adota IA frequentemente não executa o trabalho em campo. A gestão de mudança precisa acontecer dentro da equipe que adota a ferramenta e também na transição para o subcontratado que recebe os entregáveis. Ignorar o segundo momento faz os ganhos de produtividade evaporarem na camada de execução.
MCP é um framework que permite conectar ferramentas de IA a softwares já em uso, como o Revit, sem passar por um ciclo de desenvolvimento tradicional. Na prática, reduz semanas de esforço de TI para dias de prototipagem. Para empresas de AEC com baixa capacidade de TI interna, esse caminho muda a lógica de custo de desenvolver ferramentas próprias.
