AutoCAD e SketchUp: do projeto a um fluxo de engenharia com IA

1. Escolha uma entrega, não um arquivo

O primeiro piloto precisa de uma pergunta operacional: quais itens mudaram entre duas revisões e que impacto isso gera na lista de materiais? Escolha uma disciplina, um conjunto de desenhos ou modelos e um responsável técnico. A saída pode ser uma planilha conferida de quantitativos, uma lista de diferenças ou uma solicitação de cotação preparada para compras.

Registre o levantamento atual, as horas de preparação e revisão e os erros encontrados. Não prometa orçamento automático a partir de qualquer DWG ou SKP: a utilidade depende de como os elementos foram modelados, identificados e classificados.

2. Extraia estrutura antes de interpretar

A documentação do AutoCAD descreve a extração de atributos de blocos e propriedades de objetos/desenhos para tabelas e arquivos externos. O Generate Report do SketchUp organiza atributos de componentes e permite agrupar informações. Esses recursos dão um caminho estruturado para o piloto, quando disponíveis na versão e no plano utilizados.

Proposta de implementação Zild: preserve a exportação original e entregue ao agente dados normalizados, junto com identificação de projeto e revisão. Se o projeto só contém linhas ou texto solto, trate a reconstrução de significado como uma etapa adicional a validar. OCR de uma prancha pode ajudar a ler anotações, mas não é uma medida geométrica confiável por si só.

3. Defina o contrato de dados

Para cada linha, exija: projeto, revisão, arquivo de origem, identificador do elemento, disciplina, descrição, material, unidade, quantidade, regra de cálculo e estado de validação. Inclua data de extração e referência da evidência. Quando um campo não existir, registre ausente; não peça ao modelo que complete o valor pelo que parece provável.

Exemplo de registro sintético: projeto P-001, revisão R02, elemento PORTA-014, material madeira, unidade un, quantidade 1, estado pendente de revisão. É apenas um exemplo de esquema, não uma extração real. A chave deve permitir localizar o elemento e distinguir instâncias repetidas.

4. Separe cálculo, interpretação e ação

Use regras determinísticas para somar quantidades, converter unidades e aplicar fórmulas aprovadas. O agente pode classificar descrições, reunir contexto, explicar diferenças e preparar a comunicação entre engenharia e compras. Não delegue ao texto gerado a definição de fórmulas estruturais, tolerâncias ou fatores de perda.

A integração precisa distinguir consultar, propor e executar. Preparar uma lista de compra é diferente de emitir uma ordem. Antes de escrever no ERP, confira cadastro do item, unidade comercial, versão aprovada, centro de custo, orçamento e alçada. O caminho exato por exportação, API ou plugin é definido no desenho da integração; não pressupõe um conector nativo para todo formato.

5. Controle revisões e duplicidades

Congele a referência do projeto usado no piloto. Compare inclusões, exclusões e alterações por identidade do elemento, não apenas por posição na planilha. Quando uma instância mudar de identificador, encaminhe para revisão em vez de assumir que é material novo. Preserve a diferença antes/depois e o motivo da aprovação.

No envio ao sistema de destino, use um identificador de operação para evitar lançamento duplicado após reprocessamento. Registre o vínculo entre projeto, revisão, lote de extração e registro criado. Se a extração ou classificação falhar, mantenha o item em uma fila de pendências sem liberar compras.

6. Construa um conjunto de avaliação

Separe exemplos de desenvolvimento e um conjunto reservado para avaliação. Inclua componentes aninhados, unidades diferentes, objetos duplicados, campos ausentes, revisões conflitantes e desenhos incompletos. Um engenheiro prepara a referência aprovada e os critérios de erro antes da execução. Não ajuste o fluxo repetidamente usando os mesmos casos que depois serão apresentados como teste final.

Registre ferramenta e versão, modelo, instruções, arquivos, regras e configuração dos conectores. Repita execuções relevantes para observar variação. Se a tarefa for comparar revisões, avalie também diferenças que não deveriam gerar uma compra e alterações que exigem consulta ao projetista.

7. Meça qualidade, esforço e custo juntos

Avalie completude de campos, correspondência de elementos, acerto de unidade e erro de quantidade conforme tolerâncias definidas pela engenharia. Separe erro crítico de divergência que pode ser corrigida na revisão. Uma média boa não compensa omitir um item crítico. Meça minutos de preparação, revisão e retrabalho até o aceite.

Custo por pacote aprovado = custo de APIs, processamento e trabalho humano do conjunto avaliado ÷ pacotes aprovados. Inclua todas as tentativas e falhas no numerador; se nenhum pacote for aprovado, não há custo unitário de sucesso calculável. Compare o mesmo escopo com o processo atual e reporte tamanho da amostra, exclusões e limitações.

8. O que a pesquisa permite concluir

Dell’Acqua e coautores estudaram 758 profissionais em um experimento com tarefas de consultoria. O efeito da assistência por IA variou entre tarefas: houve melhoria dentro da fronteira de capacidade avaliada e pior desempenho em uma tarefa fora dela. O estudo foi publicado em Organization Science em 2026.

Isso não demonstra desempenho em engenharia, AutoCAD, SketchUp ou na Zild. A implicação prática que adotamos é avaliar tarefas e exceções separadamente. Não copie percentuais de produtividade de consultoria para um orçamento de obra; obtenha evidência no seu processo com revisão técnica.

9. Decida o próximo passo com evidências

Antes do piloto, defina com o responsável técnico quais erros bloqueiam avanço, quais campos precisam estar completos e qual esforço de revisão é aceitável. A decisão pode ser aprovar um escopo restrito, corrigir e repetir, ou manter a execução manual. Não existe um percentual universal que autorize a automação de qualquer projeto.

Para começar com a Zild, traga arquivos autorizados, uma revisão de referência, o levantamento aprovado, o destino dos dados e as regras do processo. A equipe pode desenhar a integração e ligar extração, agente, aprovação e sistema de gestão. Amplie por disciplina e tipo de entrega, preservando as evidências de cada versão.

10. Execute a ficha de avaliação

A ficha CSV ao final deste guia contém oito casos sintéticos e resultados NOT_RUN. Não contém desenhos nem resultados de uma execução da Zild. Cada linha é um cenário independente: adapte os identificadores ao seu conjunto autorizado e prepare os arquivos correspondentes antes de executar. Os casos cobrem contagem simples, conversão de 2500 mm para 2,5 m, unidade ausente, duplicidade, revisão antiga, componente aninhado, área em m² e elemento omitido.

ACCEPT significa que a extração desse cenário pode ser aceita na avaliação; não autoriza emissão de compra ou aprovação de projeto. REVIEW exige encaminhamento para revisão sem inventar valores. Deixe quantidade e unidade vazias quando não há valor de referência seguro. Preencha observed_quantity, observed_unit e observed_decision com a saída obtida, sem substituir a referência pelo resultado do agente. Registre evidência, revisor e run_id; use uma cópia por execução.

Marque PASS apenas quando decisão, identidade, revisão e campos aplicáveis correspondem à referência aprovada. Uma revisão solicitada corretamente pode ser PASS. Uma resposta plausível para um campo ausente é FAIL. NOT_RUN continua visível e não conta como acerto. Tolerâncias, erros críticos e critérios de aprovação do pacote devem ser definidos pelo responsável técnico antes do teste.

11. Não esconda omissões na média

Exemplo didático de correspondência: a referência contém 10 elementos, a extração retorna 9 e 8 correspondem corretamente por identidade e revisão. Precisão = 8 ÷ 9 = 88,9%; cobertura dos elementos esperados = 8 ÷ 10 = 80%. Há duas omissões e um elemento extra ou incorreto. Não descarte a linha incorreta para melhorar a precisão. Uma instância duplicada não pode contar duas vezes como correspondência correta.

Avalie unidade e quantidade separadamente entre os elementos corretamente correspondidos. Se 7 dos 8 têm unidade e quantidade válidas, reporte 7/8 = 87,5%, junto dos dois elementos omitidos e da linha incorreta. Esse percentual não representa qualidade de ponta a ponta nem elimina um erro crítico. Para comparar revisões, mantenha também referência de inclusões, exclusões e alterações esperadas.

Reporte os números absolutos, as regras de correspondência, as exclusões e as execuções repetidas. Os oito casos da ficha são um roteiro inicial, não uma amostra representativa de projetos de engenharia. Amplie com disciplinas, estruturas e exceções reais antes de decidir sobre uso operacional.