IA para empresa de escavação: tickets de localização e diário de obra

Um agente de IA pode ajudar uma empresa de escavação a acompanhar tickets de localização, associar cada ticket a uma obra e a uma equipe, e rascunhar o diário de obra a partir de anotações de campo, mensagens de despacho e fotos. O ponto de partida útil são registros e lembretes, não o controle de equipamentos. Qualquer coisa que autorize a escavação, altere uma marcação de concessionária ou pare o trabalho deve continuar com uma pessoa nomeada, que aprova.

Principais pontos

• Um ticket de localização é o registro que comprova quando a escavação foi autorizada, então acompanhe o status, a validade e as áreas marcadas em um único lugar.
• Diários de obra são mais úteis quando registram fatos de campo em uma estrutura fixa, em vez de um resumo narrativo.
• Comece com um agente que lê, rascunha e lembra, e dê acesso de escrita apenas a campos de baixo risco.
• Ações críticas para segurança, como liberar uma escavação, confirmar marcações ou cancelar uma parada, continuam sob aprovação humana.
• Avalie a implantação pela capacidade de um supervisor rastrear cada registro até uma fonte e até a pessoa que o confirmou.

Por que os tickets de localização são o primeiro registro a acertar

Em muitas regiões, uma equipe solicita a localização de redes subterrâneas por meio de um serviço de consulta prévia às concessionárias antes de começar a quebrar o solo. As marcações desbotam, são danificadas ou perdem a validade, e a maioria das solicitações tem um prazo de validade depois do qual a equipe precisa pedir de novo. As regras mudam conforme a jurisdição, então confirme os requisitos locais com seu assessor jurídico ou de segurança do trabalho antes de incorporá-los a qualquer processo. Do ponto de vista operacional, o que importa é que o ticket seja encontrado no momento em que alguém precisa dele. Um ticket que existe apenas na caixa de entrada do escritório ou no celular do encarregado fica, na prática, perdido quando a equipe está na beira de uma vala.

Para cada ticket ativo, mantenha estes campos em um único registro: o número do ticket, o endereço da obra e uma descrição simples da área de escavação, a data da solicitação, o prazo de validade, as concessionárias notificadas, o status da marcação e a data da última confirmação, o nome da pessoa que confirmou as marcações no local, respostas em aberto ou divergências, e o gatilho que exige uma nova localização, como uma mudança de escopo ou a equipe se deslocando para uma área não marcada.

Uma sequência de implantação que não exige trocar suas ferramentas

Você não precisa de um software novo para começar. Uma planilha compartilhada ou o sistema de gestão de obras que você já usa basta para a primeira versão, desde que cada linha siga os mesmos campos. Execute a implantação nesta ordem:

• Crie um registro por ticket de localização com os campos acima, usando os mesmos nomes de campo em todas as obras.
• Atribua um responsável por ticket ativo, normalmente o encarregado ou o líder da obra, e registre o nome no próprio registro.
• Configure lembretes para as datas de vencimento e para os gatilhos de nova localização, enviados ao responsável e ao coordenador do escritório.
• Conecte o agente para ler os registros de tickets e o diário de obra, mas não permita que ele envie novas solicitações de localização por conta própria.
• Faça o agente rascunhar cada entrada do diário a partir das anotações de início de turno da equipe, e exija que o encarregado confirme ou corrija antes de salvar.
• Revise as exceções toda semana: tickets vencidos, trabalho registrado fora de uma área marcada e respostas de concessionárias ainda pendentes.

A sequência importa mais do que a ferramenta. Quando os campos estiverem estáveis, mover essas informações para um sistema dedicado será uma tarefa bem menor.

O que um diário de obra precisa ter para se sustentar depois

Um diário de obra deve responder às perguntas que um gerente de projeto, um fiscal ou uma seguradora farão semanas depois: quem estava no local, quais equipamentos operaram, qual ticket cobria o serviço, quais áreas foram escavadas, quais marcações foram confirmadas e por quem, se alguma tubulação foi atingida ou quase atingida, quais inspeções aconteceram, quais materiais chegaram e o que mudou no cronograma. Fotos são mais úteis quando trazem local e horário. Campos estruturados superam o texto corrido porque podem ser comparados de um dia para o outro, e um campo ausente é fácil de identificar.

Cenário ilustrativo: uma equipe instala uma linha de dutos numa terça-feira. A mensagem de voz do encarregado diz que as marcações do lado norte parecem boas. O agente rascunha a entrada com o ticket referenciado e registra as marcações como observação do encarregado, não como verificação. O encarregado edita o rascunho para acrescentar que as marcações da extremidade sul estão apagadas e que uma nova localização foi solicitada. Na quarta-feira de manhã, o agente sinaliza ao escritório a solicitação de nova localização em aberto. O agente não marca o ticket como liberado, e a extremidade sul continua fora do cronograma até que uma pessoa registre uma nova confirmação.

Onde os agentes ajudam e onde devem esperar uma pessoa

Dê ao agente acesso de leitura aos registros de tickets e aos diários de obra. Dê acesso de escrita apenas a rascunhos, lembretes e sinalizações. A autoridade sobre o status de segurança continua com as pessoas. Um guia de decisão simples torna esses limites concretos:

• Rascunhar uma entrada do diário a partir de anotações de campo: o agente pode rascunhar, e uma pessoa confirma antes de salvar.
• Enviar um lembrete sobre um ticket que vai vencer: o agente pode enviá-lo ao responsável nomeado.
• Solicitar uma nova localização: o agente redige o pedido, e uma pessoa o envia.
• Confirmar marcações, encerrar um ticket ou registrar uma resposta de concessionária como resolvida: uma pessoa faz isso, e o registro mostra quem e quando.
• Autorizar uma escavação, mudar o status de parada de obra ou aceitar uma marcação ausente: uma pessoa decide, e o agente não tem permissão para fazê-lo.

Agentes também leem textos escritos por outras pessoas, incluindo respostas de concessionárias, atualizações por e-mail e notas coladas de uma conversa. Qualquer um desses textos pode conter instruções que um remetente descuidado ou mal-intencionado queira usar para direcionar o agente. Mantenha as instruções do agente separadas dos dados que ele lê, e não deixe que o conteúdo de um documento altere o que o agente pode fazer. As orientações da OWASP sobre prevenção de injeção de prompt tratam esse tipo de risco em detalhe.

Como a Be Human trata isso como uma operação gerenciada

A Be Human desenha o agente em torno de um papel bem definido, como um coordenador de localização e diário para uma equipe de obra específica. A primeira etapa define a memória que o agente pode ler, como registros de tickets, modelos de diário e a escala das equipes, as ferramentas que ele pode acionar, os limites de aprovação descritos acima e um critério de sucesso observável, por exemplo, que todo ticket ativo tenha um responsável nomeado e uma data de validade registrada. A operação gerenciada então cobre o monitoramento das exceções, a revisão periódica de permissões quando equipes ou sistemas mudam, a manutenção das conexões com suas ferramentas atuais e as alterações controladas nas instruções do agente, cada uma registrada com motivo e aprovador.

Equipes que mantêm registros rotineiros de outros tipos de trabalho de campo enfrentam uma estrutura semelhante. A abordagem usada para registros de incidentes e auditorias em equipes de SST se aplica diretamente aos diários de escavação, e a forma como construtoras começam a usar agentes é uma referência útil para manter os registros de campo rastreáveis.

Por que ações críticas para segurança ficam sob aprovação humana conforme os agentes melhoram

Um agente que se torna mais capaz não muda quem responde por um dano a uma rede subterrânea ou por uma escavação não autorizada. A responsabilidade deve definir o limite da autoridade. Agentes também falham de um jeito específico que importa aqui: seus resumos soam confiantes mesmo quando a anotação original era ambígua. Um encarregado que lê um rascunho limpo pode presumir que as marcações foram verificadas, quando na verdade apenas foram descritas.

Dois hábitos de engenharia ajudam. O primeiro é o menor privilégio, que as orientações de autorização da OWASP descrevem como negar acesso por padrão e conceder apenas o que uma tarefa específica precisa. O segundo é a observabilidade: cada ação do agente deve deixar um rastro que mostre quais dados ele usou, o que produziu e quem aprovou. O material introdutório da OpenTelemetry descreve os logs, traces e métricas que tornam possível esse rastro. Quando considerar dar mais autoridade a um agente, faça isso por meio de uma revisão escrita das permissões e das evidências, e não porque o modelo subjacente teve um bom desempenho em um teste genérico. O NIST AI Risk Management Framework oferece um vocabulário útil para essa revisão.

Como saber se a implantação está funcionando?

Não meça o sucesso pela quantidade de texto que o agente produz. Meça se os registros são confiáveis. Verifique se todo ticket ativo tem um responsável nomeado e uma data de validade, se toda entrada do diário tem uma fonte e uma pessoa que a confirmou, se as exceções são revisadas no calendário combinado e se nenhum status de segurança mudou sem uma aprovação humana registrada. Faça a mesma revisão em uma amostra de entradas passadas todo mês, comparando o rascunho com a versão final, para ver onde o agente precisa de instruções mais claras ou de permissões mais restritas. Se a implantação estiver sólida, as perguntas que você faz no campo devem ser respondidas mais rápido e com menos dúvida.

Para descobrir a primeira tarefa que vale entregar a um agente na sua empresa, faça o diagnóstico gratuito de IA da Be Human.

Perguntas frequentes

Preciso de software novo antes de usar um agente de IA para tickets de localização?

Não. Uma planilha compartilhada ou o sistema de obras atual pode guardar os campos do ticket e o diário de obra em uma primeira versão. O passo importante é combinar um conjunto único de campos e um responsável por cada ticket ativo. Ferramentas dedicadas podem vir depois, quando os registros estiverem estáveis e você souber o que precisa que elas façam.

O agente pode solicitar localizações ao serviço de consulta prévia para minhas equipes?

Ele pode rascunhar a solicitação, mas uma pessoa deve enviá-la. Pedidos de localização têm consequências legais e operacionais, e quem envia precisa conhecer o escopo da escavação e a área a ser marcada. Manter o envio com uma pessoa nomeada também deixa o registro mais claro caso surja uma divergência depois.

O que acontece se o agente cometer um erro em um diário de obra?

Uma pessoa deve identificar o erro na etapa de confirmação, e por isso essa etapa é obrigatória antes de salvar a entrada. Cada entrada deve manter suas notas de origem e o histórico de edições, para que a correção fique visível. Se o mesmo tipo de erro se repetir, revise as instruções e as permissões do agente, e restrinja-as antes de acrescentar qualquer coisa nova.

Como isso se encaixa nos requisitos de segurança que eu já sigo?

A implantação apoia seu processo de segurança em vez de substituí-lo. O agente mantém registros, lembretes e exceções organizados, enquanto seus profissionais habilitados, supervisores de obra e procedimentos obrigatórios continuam tomando as decisões que têm peso de segurança. Verifique as regras locais e as exigências da sua seguradora antes de alterar qualquer procedimento, e trate a saída do agente como um registro a ser verificado, não como uma decisão.

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