Como usei IA em uma consultoria de engenharia ao vivo

TL;DR

Conduzi uma consultoria hidráulica ao vivo usando IA como ferramenta assistente e bloco de notas. Em duas horas saímos com arquitetura definida, equipamentos especificados e documento técnico pronto. O método que funcionou tem três pilares: alimentação progressiva, filtro humano constante e saída em formato útil para o cliente.

Antes de continuar, uma observação importante: o documento técnico abaixo é a primeira versão gerada pelo agente, sem a minha revisão. Estou compartilhando propositalmente esse rascunho cru para você avaliar diretamente a qualidade do output da IA, sem nenhuma intervenção humana posterior. Informações específicas do projeto foram ocultadas ou alteradas para preservar o sigilo do cliente. Mais adiante no post eu explico exatamente os equívocos que encontrei na revisão e como o documento final ficou diferente.

A reunião que deveria durar uma semana

Semana passada estava em uma reunião de consultoria com uma colega engenheira. Ela precisava resolver um sistema hidráulico industrial que não fechava: torre de resfriamento, múltiplos consumidores em paralelo, pressão apertada, vazões descasadas. O tipo de problema onde você sai da reunião com uma lista de “vou pensar melhor e te respondo”.

Em vez disso, saímos de lá com a arquitetura definida, equipamentos especificados, dimensionamento validado em todos os pontos críticos e um documento técnico para levar aos contratantes.

Tudo parece muito complicado e difícil, mas, garanto que não é nada mágico. Vou contar como fiz.

O problema que não fechava nas contas

Era um sistema de recirculação de água fria para resfriamento industrial: múltiplos equipamentos em paralelo, alimentados por uma única bomba principal, descarregando em uma torre de resfriamento. Os pontos críticos:

• Pressão máxima limitada em cada consumidor, com perda de carga interna significativa em vazão nominal
• Torre de resfriamento exigindo vazão própria e pressão mínima no spray
• Vazão total da bomba acima da soma da demanda dos consumidores, sobrando excesso sem destino claro
• Sem equalização hidráulica entre os consumidores
• Operação 24/7 com necessidade de tirar consumidores de linha individualmente para manutenção

A conta básica já mostrava o aperto: depois de descontar a perda interna nos consumidores e a pressão exigida pela torre, restava margem mínima para vencer toda a perda de carga da tubulação. Não fechava.

Em consultoria tradicional, esse tipo de problema rende uma reunião de diagnóstico, alguns dias de cálculo, mais uma reunião apresentando alternativas, outra rodada de refinamento. No mínimo uma semana de calendário.

O que fiz diferente

Abri uma conversa com um modelo de linguagem ao lado da reunião, em uma janela paralela. Cada vez que minha colega trazia uma informação nova do sistema, eu alimentava o modelo. Cada hipótese que discutíamos, eu testava em diálogo. O modelo não substituiu nenhum de nós, ele acelerou o ciclo de raciocínio.

Mas isso só funcionou porque segui um protocolo específico. Sem ele, IA em consultoria vira ruído.

O protocolo que funcionou

1. O engenheiro define o problema

Não fui para a reunião com “vou usar IA para resolver isso”. Fui com a expertise técnica e a responsabilidade pelo resultado. A IA entrou como ferramenta de aceleração de raciocínio, não como oráculo.

Toda a estruturação inicial, entender o que minha colega estava enfrentando, identificar as restrições reais, separar o problema de pressão do problema de distribuição, foi trabalho humano. Eu já sabia o formato da resposta antes de pedir uma.

2. Alimentação progressiva, não pedido único

A tentação inicial é jogar todo o problema de uma vez e pedir uma solução completa. Não funciona. O modelo gera algo plausível mas genérico.

O que funciona: ir descobrindo o problema junto. Eu começava com a restrição mais óbvia (orçamento de pressão), avaliava a resposta, levava para discussão presencial, voltava com a próxima camada (distribuição entre os consumidores), avaliava de novo. A cada iteração o modelo refinava o entendimento e eu testava se a recomendação fazia sentido com o que eu sabia da prática.

Esse vai-e-vem é o que permitiu chegar em uma solução específica para o sistema dela, não em um manual genérico de bombeamento.

3. Eu era o filtro de qualidade

Em vários momentos, o modelo me deu sugestões que eu rejeitei ou modifiquei:

• Quando ele sugeriu uma arquitetura com bomba reposicionada para a sucção, eu sabia que a geometria da fábrica não permitia. Descartei e fui adiante.
• Quando ele propôs uma solução de balanceamento estático, eu apontei que minha colega tinha mencionado operação parcial: alguns consumidores podem ficar desligados. Isso mudou completamente a especificação das válvulas.
• Quando ele me deu links de produtos, eu pedi para verificar fontes oficiais antes de levar a recomendação adiante.

Cada vez que eu corrigi, refinei ou rejeitei, a conversa avançou. A IA é boa para gerar opções e estruturar raciocínio. O engenheiro é responsável pelo julgamento.

4. Saída em formato útil para o cliente

No final, pedi para o modelo gerar um documento técnico estruturado: diagrama hidráulico, especificação de equipamentos com modelos sugeridos, orçamento de pressão validado ponto a ponto, análise de cenários operacionais, estimativa de investimento. Não para entregar como está, mas como base para minha revisão técnica final.

Cinco minutos de geração. Comparado a duas tardes de elaboração manual, é uma diferença material. E o conteúdo era meu, só que organizado, formatado, com diagrama renderizado.

O que saiu da reunião

Saímos com:

• Arquitetura definida: bomba principal, boosters in-line individuais por consumidor, válvulas combinadas de controle de vazão e pressão, válvulas de alívio mecânicas como segunda linha de defesa, bypass dimensionado
• Famílias de equipamento sugeridas para cotação (válvulas combinadas de classe industrial, bombas centrífugas in-line)
• Orçamento de pressão validado em todos os pontos do circuito, com margens de segurança documentadas
• Análise de sete cenários operacionais, incluindo falhas de equipamento individual e operação parcial
• Estimativa de CAPEX para apresentação ao cliente
• Lista de pendências para fechamento do projeto (medições de campo, decisões de redundância, layout vertical)

Tudo isso em uma única reunião de aproximadamente duas horas.

A parte que ninguém conta: a revisão

Aqui é onde preciso ser honesto, porque o resto do artigo soaria propaganda sem isso.

Em um momento posterior à reunião, sentei para revisar a documentação com calma. Gastei cerca de 30 minutos analisando o que tinha sido produzido, e encontrei equívocos. Componentes especificados que não eram necessários para a arquitetura final. Sistemas redundantes que entraram no documento mas que, revisando, não faziam sentido. Sugestões dimensionadas com folga excessiva.

Removi o que sobrava, ajustei o que estava errado, pedi para a IA refazer trechos com instruções mais precisas. O documento final é diferente, e melhor, do que saiu da reunião.

Mas aqui está o ponto que importa: mesmo contando esses 30 minutos de revisão, o resultado final foi de uma qualidade que eu não conseguiria entregar pelo método tradicional. Por uma razão simples: tempo.

Se eu não tivesse adotado esse fluxo, o que eu teria entregue? Provavelmente um documento de Word ou um bloco de notas com os pontos principais. Passaria para minha colega em outra reunião os detalhes faltantes. Ela teria que voltar com dúvidas, ou o cliente teria perguntado por dados que eu não documentei porque “não considerei essencial naquele momento”. O ciclo se arrasta.

Com esse fluxo, o entregável virou outra coisa: ficha técnica completa de cada equipamento, links para datasheets oficiais, modelos de referência específicos, dados reais extraídos da documentação do fabricante, diagrama hidráulico interativo onde a pessoa clica e tem uma seção dedicada aos detalhes. Coisas que eu jamais teria tempo de produzir manualmente para um cliente, mesmo sabendo que agregariam valor.

O resumo é desconfortável de admitir mas verdadeiro: investi menos tempo e entreguei um resultado melhor. E parte do “melhor” veio justamente por ter usado um assistente de IA e entregar todo contexto do sistema de forma clara, em vez de gastar essas horas montando o documento do zero.

A revisão é parte do método, não exceção dele. Quem usa IA esperando entrega perfeita está confiando demais em um algoritmo probabilístico. Quem usa esperando rascunho de alta qualidade para refinar, e tem a consciência de que é o único responsável pelo resultado, está em um bom caminho.

Onde a IA não funciona

Para ser honesto sobre os limites:

Não funciona se você não tem o conhecimento técnico de base. Em vários momentos, tive que corrigir o meu assistente de IA e direcioná-lo para o caminho certo apenas porque eu já entendia hidráulica. Um engenheiro júnior teria aceitado as sugestões inadequadas sem perceber.

Não funciona como única fonte de especificação. Cada equipamento sugerido precisou ser validado contra informações reais antes de virar especificação para cotação. A IA é boa indicando categorias de produto e modelos prováveis. A confirmação é manual.

Não funciona sem o engenheiro humano no centro. Se a IA gerou a recomendação e ninguém revisou com olhar crítico, você acaba de produzir um relatório bonito e tecnicamente frágil. A IA não entende as nuances do projeto e não consegue equilibrar todas as variáveis para atender o cliente e os riscos de cada decisão.

Como aplicar isso na próxima reunião

Para os colegas que querem testar, aqui vai o fluxo destilado em três fases.

Fase 1: antes da reunião

Alimente o agente com contexto da sua empresa. Esse é provavelmente o maior salto de qualidade que existe. Se você tem documentação de projetos anteriores, padrões internos, normas técnicas que a empresa adota, especificações recorrentes, coloca tudo isso em um Project do Claude (ou equivalente). A diferença entre uma resposta genérica e uma resposta no padrão da sua empresa é simplesmente o contexto oferecido antes.

Para projetos com modelo BIM, vale criar automações para extrair dados estruturados (lista de equipamentos, quantitativos, especificações) e jogar no contexto. Plugins Revit que exportam JSON, scripts em Dynamo, parsers de IFC, qualquer coisa que transforme o modelo em texto interpretável pelo agente.

Defina o objetivo da reunião antes de abrir a IA. A pior forma de usar é chegar na reunião e improvisar. A melhor é ter clareza do que entregar. O agente acelera execução, não substitui qualificação técnica e experiência de campo.

Fase 2: durante a reunião

Use uma plataforma com transcrição automática. Gemini no Google Meet, Otter.ai, Read.ai, Fathom, qualquer um que faça transcrição em tempo real. Você fica liberado para conversar com o cliente sem tomar notas paralelas.

Troque o bloco de notas pelo Claude. Cada vez que surge uma informação técnica, hipótese ou restrição, você alimenta. Isso preserva o ritmo da reunião, você continua engajado com o cliente, mas paraleliza o raciocínio técnico.

Não tente capturar tudo via IA. O foco principal continua sendo a conversa humana. A IA roda em segundo plano, complementando. Se você se distrair no chat com a máquina, perde a reunião.

Fase 3: depois da reunião

Alimente a transcrição completa no agente. Esse é o momento onde a transcrição automática vira ouro. Você joga o texto integral da reunião e pede para gerar: ata estruturada, lista de pendências com responsáveis, decisões tomadas, próximos passos com prazos. Em poucos minutos você tem o follow-up profissional que normalmente levaria uma manhã para escrever.

Reserve tempo para revisão crítica. No meu caso foram 30 minutos. Pode ser mais, dependendo da complexidade. O ponto é: nunca entregue o que a IA produziu sem passar pelo seu filtro técnico. Equívocos vão aparecer. Componentes desnecessários, dimensionamentos exagerados, sugestões fora do contexto. Sua revisão é o que transforma rascunho em entregável.

Peça a versão final em formato útil para o cliente. O formato pode ser documento HTML interativo, um PDF estruturado ou um markdown. Você pode pedir elementos como um diagrama clicável, planilha de especificação, apresentação. O agente entrega no formato pedido. Esse é o detalhe que diferencia “resposta de IA” de “entregável de consultoria”.

Diagrama do fluxo

Outras práticas que aplico

Algumas práticas que não usei nessa reunião específica mas que rendem em outros cenários:

Conectar o agente diretamente às suas ferramentas. O Claude tem suporte a MCP (Model Context Protocol), o que permite conectar Google Drive, Notion, ClickUp, GitHub e outras fontes diretamente. Em vez de copiar e colar documentos toda vez, o agente busca sozinho na hora que precisa. Para consultor com biblioteca extensa de projetos, isso muda o jogo.

Criar skills ou instruções persistentes. Definir uma vez como o agente deve formatar especificações técnicas, qual estrutura a sua empresa usa para parecer técnico, ou quais normas devem sempre ser checadas. O agente passa a aplicar isso automaticamente em todas as conversas.

Manter biblioteca de prompts por tipo de tarefa. Especificação de equipamento, ata de reunião, parecer técnico, análise de viabilidade: cada um tem um formato ideal de prompt. Construir essa biblioteca uma vez economiza tempo permanentemente.

Validação cruzada em decisões críticas. Para situações onde o erro custa caro, vale rodar a mesma pergunta em dois modelos diferentes (Claude e Gemini, por exemplo) e comparar. Quando ambos convergem, sua confiança aumenta. Quando divergem, é sinal de que vale aprofundar manualmente antes de decidir.

Gravar reuniões internas com a equipe. Não só reuniões com cliente. Reuniões de alinhamento técnico, definição de escopo, brainstorm: tudo isso vira material de contexto valioso para projetos futuros se transcrito e arquivado de forma estruturada.

Documentar padrões emergentes. Cada vez que você refina um prompt e ele funciona bem, salve. Cada vez que define um formato de entregável que o cliente aprovou, salve. Aos poucos isso vira um sistema de conhecimento operacional da sua consultoria, replicável entre projetos e entre membros da equipe.

O ponto não é que IA substitui consultoria de engenharia. O ponto é que mudou o ritmo do trabalho. Antes da reunião, eu teria saído com uma lista de tarefas. Hoje saio com a solução estruturada e o documento pronto para revisão.

A engenharia continua sendo do engenheiro. Só que o tempo entre a pergunta e a resposta encolheu de dias para horas.

P.S.: para quem quer ir além

Se essa ideia de “alimentar a IA com contexto da empresa” interessou, tem um caminho que vale estudar: LLM Wikis, bases de conhecimento estruturadas especificamente para serem consumidas por modelos de linguagem.

A diferença para uma wiki tradicional é sutil mas profunda. Em vez de organizar informação para humanos navegarem por links, você organiza para o modelo recuperar contexto sob demanda. Padrões de projeto da empresa, decisões arquiteturais históricas, especificações recorrentes, lições aprendidas, memórias de cliente, normas técnicas internas: tudo viável de virar conhecimento ativo do agente.

O resultado é uma consultoria, ou departamento de engenharia, onde o conhecimento institucional fica disponível em qualquer conversa com a IA. Não está só na cabeça do sócio sênior, não está perdido em pasta de Drive que ninguém abre, não desaparece quando alguém sai da empresa.

É um campo novo, ainda em formação. Os termos para pesquisar incluem knowledge graphs para LLM, RAG (Retrieval Augmented Generation), context engineering e justamente LLM wikis. Vale dedicar algumas horas para entender: quem montar primeiro a base de conhecimento da própria empresa terá uma vantagem operacional difícil de copiar.

Fica o convite para pesquisar. O resto deixo para vocês descobrirem.

Você já usou IA ao vivo em uma reunião técnica? Qual foi o maior obstáculo: o modelo gerando coisas erradas, ou perder o fio da conversa com o cliente enquanto alimenta o chat? Comenta no canal.