IA para escritório de engenharia: submittals e notas de campo

Um agente de IA para um escritório de engenharia de consultoria funciona melhor como um papel bem delimitado: ele acompanha o status dos submittals (pacotes de dados de produto, desenhos de fábrica ou amostras enviados para análise), registra as notas de campo no projeto certo e prepara atualizações que um profissional habilitado revisa antes de qualquer coisa chegar a um cliente, empreiteiro ou órgão público. Ele não aprova submittals, não decide questões de projeto e não envia mensagens por conta própria. Para um escritório pequeno, o primeiro agente útil cobre um único registro e um único fluxo de notas, com limites de aprovação escritos e um critério de sucesso que alguém consiga verificar.

Principais pontos

• Comece com um registro, como o log de submittals de um projeto ativo, e um fluxo de notas, como as anotações de visita à obra, antes de acrescentar qualquer outra coisa.
• Cada registro que o agente escrever deve trazer a referência da origem: a seção da especificação, o desenho, o e-mail ou a nota de onde veio.
• Clientes, empreiteiros e órgãos públicos não recebem nada do agente até que um engenheiro responsável tenha aprovado.
• As permissões devem ser de leitura por padrão, com escrita limitada aos campos do log e a uma pasta de rascunhos, e sem nenhuma permissão de envio.
• Avalie o agente pelo menos de itens de acompanhamento esquecidos e pela rapidez das revisões, medidos em uma avaliação curta e recorrente, e não pela impressão geral.

Quais informações um log de submittals precisa registrar?

Um submittal é um pacote do empreiteiro com dados de produto, desenhos de fábrica ou amostras enviados para análise frente às especificações do projeto. Para um escritório pequeno, o log é o registro de trabalho do que foi enviado, a qual seção da especificação responde, quando chegou, quem está com ele e em que situação de análise se encontra. Um submittal atrasado ou perdido costuma ser percebido apenas quando uma equipe fica parada esperando o material. Por isso o log importa mais do que a caixa de entrada onde o pacote chegou pela primeira vez.

Uma entrada útil no log reúne os seguintes campos:

• Número do submittal e a seção da especificação a que responde
• Descrição do item e o empreiteiro ou fornecedor que enviou
• Data de recebimento, data de devolução e o profissional responsável pela análise
• Status: recebido, em análise, devolvido com comentários, reenvio solicitado ou aprovado
• Dependência a jusante, como a data de compra ou a atividade de instalação que ele libera
• Questões em aberto levantadas nos comentários, ligadas ao arquivo original

O trabalho do agente é manter esses campos atualizados e apontar as entradas atrasadas em relação ao cronograma. A decisão sobre o que um submittal devolvido significa continua com o engenheiro. Escritórios que já organizam propostas e registros de projeto de forma estruturada vão reconhecer esse padrão, e a mesma disciplina aparece em IA para escritórios de arquitetura: memória de projeto e briefings.

Como transformar notas de campo em registros que alguém consegue usar

Notas de campo costumam ser digitadas no celular, dentro de um carro, em forma de abreviações, com fotos e medidas que só fazem sentido para quem as tirou. Um arquivo de projeto precisa de algo mais confiável: a observação, o local, a data, quem viu, o que foi medido e se isso pode afetar escopo, prazo ou conformidade. O agente consegue fazer boa parte da triagem, mas só se o modelo de nota definir o que é uma nota utilizável antes de o agente começar a trabalhar.

Um modelo que funciona separa fatos de interpretação:

• Projeto, área da obra, data e autor
• Observação, descrita em palavras simples sobre o que foi visto
• Medições ou leituras, sempre com unidade
• Fotos referenciadas pelo nome do arquivo, e não incorporadas ao texto
• Ação solicitada, com o responsável identificado
• Sinalização de possível alteração, preocupação de segurança ou dúvida para o engenheiro responsável

Quando o agente recebe uma nota que não se encaixa no modelo, ele deve pedir o elemento que falta, em vez de preenchê-lo sozinho. Uma medida sem unidade ou uma foto sem localização é uma lacuna a ser reportada, não um detalhe a ser adivinhado. É uma regra simples, e ela evita a maior parte dos erros que tornam um registro de campo inútil depois.

Onde fica a etapa de revisão

A regra que se sustenta na prática é simples. O agente pode ler amplamente e escrever em registros internos e rascunhos, mas nada sai do escritório sem que uma pessoa nomeada aprove. Um e-mail de status, uma carta de transmissão, um pedido de reenvio ou uma nota informando a um empreiteiro que uma observação de campo pode afetar o escopo é comunicação externa no momento em que é enviada. O NIST AI Risk Management Framework é uma referência útil para pensar esse tipo de responsabilidade, porque trata as pessoas que governam um sistema como parte do desenho desse sistema.

Um guia de decisão para a maioria das equipes de engenharia fica assim:

• Atualização interna do log com referência da origem: o agente pode escrever diretamente.
• Resumo interno para o líder do projeto: o agente rascunha, e o líder lê.
• Carta ou e-mail ao empreiteiro sobre um submittal devolvido: o agente rascunha, e o engenheiro aprova e envia.
• Qualquer posicionamento de projeto, aprovação ou conclusão normativa: somente o engenheiro responsável decide, e o agente não redige a conclusão.
• Qualquer assunto que toque honorários, compromissos de prazo ou mudança de escopo: uma pessoa decide, e o agente apenas reúne os fatos.

A mesma lógica de portões vale para eventos de qualidade. Quando uma observação de campo pode virar uma não conformidade, o agente sinaliza e monta o registro, mas quem decide é o responsável pela qualidade. A abordagem é paralela à de agentes de IA para equipes de SST, que trata de incidentes e auditorias.

Quais ferramentas e permissões o agente deve ter?

Um agente que lê pacotes de submittal e notas de campo precisa de acesso à pasta do projeto, à caixa compartilhada de submittals e ao log, além de uma pasta de rascunhos. Ele não precisa da capacidade de enviar e-mails, aprovar itens em um sistema de documentos ou apagar registros. Conceda cada permissão separadamente e revise-as em uma agenda fixa, porque um acesso dado para um projeto costuma continuar existindo depois que o projeto termina. As orientações de autorização da OWASP descrevem esse princípio: conceder apenas o que a tarefa exige e verificar se a concessão ainda faz sentido.

Os documentos são uma segunda preocupação. O PDF de um empreiteiro ou uma carta de transmissão digitalizada são dados, não instruções, e podem conter texto que tenta direcionar um sistema de IA, por acidente ou de propósito. As orientações da OWASP sobre injeção de prompt recomendam tratar conteúdo de origem externa como não confiável e manter as instruções do agente separadas do material que ele lê. Na prática, isso significa que o agente resume o documento, em vez de agir sobre o que o documento diz que ele deveria fazer.

Na abordagem gerenciada da Be Human, a primeira etapa define o papel único, o registro e o fluxo de notas que o agente cobre, a memória que ele mantém, as ferramentas que pode acionar, os limites de aprovação e um critério de sucesso observável. A operação contínua pode incluir monitoramento, revisões de permissão, manutenção das conexões com o e-mail e com os sistemas de arquivos, resposta a incidentes quando algo sai errado e mudanças controladas nas instruções do agente. O sentido dessas etapas posteriores é manter o escopo onde o escritório o definiu, mesmo quando as necessidades da equipe mudam.

Uma semana ilustrativa com um submittal de ligação metálica

O cenário a seguir é ilustrativo e não descreve um escritório ou projeto específico. Em uma segunda-feira, um fabricante envia um submittal de detalhe de ligação metálica. O agente registra o item na seção de especificação correspondente, anexa o arquivo, marca o status como em análise e o coloca na fila do engenheiro responsável, com a data de instalação extraída do cronograma atual.

Na quarta-feira, uma nota de visita à obra registra que uma ligação foi modificada em campo para dar passagem a um duto. O agente arquiva a nota na área correta, sinaliza como possível alteração e rascunha uma pergunta ao engenheiro responsável perguntando se a modificação exige um pedido formal de análise. O engenheiro lê o rascunho, decide que a modificação exige pedido formal, reescreve o texto e envia ao empreiteiro. O agente não decide o que a modificação significa.

Na sexta-feira, a revisão semanal mostra que o submittal de aço ainda está em análise, com instalação prevista para a semana seguinte. O agente rascunha um lembrete ao líder do projeto com o item, a dependência e o comentário em aberto. O líder sobe o item na fila de revisão. Nada daquela semana saiu do escritório sem que uma pessoa o lesse antes, e cada entrada pode ser rastreada até a sua origem.

Um plano por etapas para a primeira implantação

A primeira implantação deve ser pequena o bastante para ser conferida à mão. A sequência a seguir funciona para a maioria dos escritórios com um ou dois projetos ativos:

• Escolha um registro e um projeto. Selecione o log de submittals de uma única obra ativa, e não de todo o portfólio.
• Escreva o modelo de nota de campo e combine-o com as pessoas que vão registrar as notas.
• Mapeie as fontes. Liste cada caixa de e-mail, pasta e local de arquivo que o agente vai ler, e confirme quem é o responsável por cada um.
• Defina os portões. Anote quais saídas o agente pode escrever diretamente, quais só pode rascunhar e quais ficam reservadas a uma pessoa nomeada.
• Conceda permissões separadamente. Comece com acesso de leitura e acrescente escrita em rascunhos e no log somente quando as etapas anteriores estiverem estáveis.
• Execute em modo de sombra. O agente produz suas entradas e rascunhos enquanto a equipe mantém o processo habitual, e os dois são comparados toda semana.
• Revise as diferenças. Cada divergência é classificada como referência ausente, status errado, detalhe inventado ou um acerto que a equipe tinha deixado passar.
• Expanda apenas quando o critério de sucesso se sustentar. Acrescente um segundo projeto ou um segundo fluxo de notas somente depois que o primeiro tiver se mostrado estável por tempo suficiente para confiança.

O período de sombra é a parte mais valiosa do plano. Ele revela se o modelo é claro o bastante, se as pastas de origem estão completas e se os revisores têm o tempo que os portões pressupõem.

Como saber se o agente está funcionando?

O escritório precisa de um critério de sucesso que alguém diferente de quem construiu o agente consiga verificar. Um critério prático é um conjunto fixo de submittals e notas de campo passados, cujos resultados corretos já são conhecidos. Execute o agente sobre esse conjunto em intervalos regulares e avalie o status correto, as referências de origem corretas e a ausência de detalhes que não aparecem em nenhum material de origem. As orientações da Anthropic sobre avaliações de agentes de IA descrevem esse padrão de testar contra tarefas realistas, e o guia de evals da OpenAI trata da mesma ideia por outro ângulo.

Registre o que o agente faz de um modo que possa ser revisado depois, incluindo quais arquivos leu, quais entradas escreveu e quais rascunhos produziu. Os conceitos de observabilidade da OpenTelemetry descrevem a prática geral de capturar esse tipo de rastro, e isso facilita a investigação de incidentes quando uma entrada de log se revela errada. Uma análise mensal dos resultados de avaliação, da lista de permissões e das notas de incidentes costuma ser suficiente para manter o sistema honesto.

Se você quer descobrir qual é a primeira tarefa que vale a pena entregar a um agente no seu escritório, o diagnóstico gratuito de IA da Be Human é um ponto de partida prático.

Perguntas frequentes

Um agente de IA pode aprovar um submittal em nosso nome?

Não, e ele não deve ser configurado para tentar. O agente pode registrar o submittal, acompanhar o status, conferi-lo com o cronograma e rascunhar um comentário de análise para um engenheiro. A decisão de aprovação é do engenheiro responsável, que responde por ela segundo os contratos do escritório e suas obrigações profissionais.

Precisamos conectar o agente ao nosso software de gestão de projetos?

Não na primeira etapa. Muitos escritórios começam com uma caixa compartilhada de submittals, a pasta do projeto e um log que o agente pode ler e escrever de forma controlada. Integrações mais profundas podem vir depois que os portões e o critério de sucesso estiverem comprovados, e cada nova conexão deve passar por sua própria revisão de permissões.

E as fotos de obra que mostram trabalhadores ou pessoas do público?

Fotos de campo podem conter dados pessoais, então o agente deve referenciar as fotos pelo nome do arquivo e não deve copiar imagens identificáveis para resumos ou rascunhos. O acesso à pasta de fotos deve ficar restrito às pessoas que precisam dele, e o escritório deve confirmar suas obrigações de retenção e privacidade com os próprios assessores. As permissões do agente devem refletir essa mesma restrição.

Precisamos de uma pessoa dedicada para supervisionar o agente?

Alguém precisa ser o responsável, mas o papel não precisa ser de tempo integral. O responsável revisa os rascunhos que saem para fora, confere a avaliação semanal, aprova mudanças de permissão e decide quando o escopo pode crescer. Muitos escritórios atribuem essa função a um engenheiro de projeto ou a um líder de operações que já conhece o processo de submittals.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.