IA para empresa de escavação: tickets de locação e escalas de equipe

Um agente de IA pode ajudar uma empresa de escavação hoje em dois pontos: ler os tickets de locação (pedidos de localização de redes subterrâneas) que chegam e confrontá-los com as escavações planejadas, e manter as escalas de equipe coerentes com a validade dos tickets, a disponibilidade dos equipamentos e dos operadores. O agente trabalha com registros que você já mantém, como os avisos das concessionárias, a agenda de obras e o quadro de despacho, e prepara rascunhos e alertas para um despachante ou encarregado aprovar. Uma operação gerenciada vale uma conversa quando esses registros envolvem várias pessoas e sistemas, e alguém precisa manter o agente preciso depois das primeiras semanas.

Principais pontos

• Comece com um papel só: triagem de tickets de locação e verificação de validade, antes de tentar automatizar todo o despacho.
• Dê ao agente acesso de leitura aos avisos de ticket, à agenda de obras e aos registros de equipe, e acesso de escrita apenas a rascunhos.
• Considere um ticket válido para uma escavação somente quando local, datas e tipo de serviço baterem com o trabalho planejado.
• Mantenha os pedidos de locação, as mudanças de despacho e as realocações de equipe sob responsabilidade de uma pessoa nomeada.
• Avalie o resultado com uma verificação observável: toda escavação planejada tem um ticket correspondente e vigente no dia em que começa.

O que uma empresa de escavação pode entregar a um agente hoje

O trabalho de escavação depende de uma cadeia de registros que já existe na maioria das empresas: notificações às concessionárias, lista de obras, calendário de equipes, registros de equipamentos e as anotações que o encarregado faz no fim do dia. Um agente é útil onde essa cadeia é lenta de ler e fácil de interpretar errado. Isso envolve sobretudo leitura e cruzamento de informações, e não a escavação em si. Os tickets de locação são um bom primeiro candidato, porque chegam como avisos estruturados, com datas claras, e uma divergência entre o ticket e a escavação planejada é uma pergunta que uma pessoa responde rapidamente, desde que alguém a levante.

Algumas decisões devem continuar com pessoas. Definir como escavar perto de uma rede marcada, interpretar o que as marcações significam no terreno, acionar a concessionária quando a resposta não é clara e designar um operador para um local com risco conhecido dependem de julgamento e de condições que um agente não enxerga. O agente pode preparar as informações para essas decisões. Não deve tomá-las.

Como os tickets de locação dão errado em obra ativa

A maioria dos problemas de locação não é dramática. São pequenas divergências entre dois registros que passam despercebidas até a manhã da escavação. Os padrões que mais causam transtorno costumam ser estes:

• O ticket foi aberto para o endereço do projeto, mas a equipe deslocou a vala para o lote vizinho durante a montagem do canteiro.
• O ticket era válido quando a obra foi agendada, mas a data de início mudou e a janela do ticket já não cobre o trabalho.
• Duas pessoas abriram tickets para a mesma obra, e apenas um deles foi registrado no processo.
• As marcações no chão desbotaram ou foram parcialmente danificadas após a chuva, e ninguém no local sabia a quem recorrer.
• O escopo mudou de um reparo raso para uma escavação mais profunda, e o ticket ainda descreve o serviço antigo.

Cada um desses casos é uma comparação entre registros que já existem. Essa comparação é a tarefa central de um agente. Problemas que atravessam de uma obra para outra, como um ticket que vence durante um início atrasado, seguem a mesma lógica de tratamento de exceções descrita em planejamento da cadeia de suprimentos.

As regras que o agente verifica importam mais do que o software. Os requisitos de notificação e as janelas de validade são definidos pelas normas locais e pelo sistema de notificação de redes da sua região. Copie essas regras da fonte oficial, peça que o responsável por conformidade as confirme e não deixe o agente nem um fornecedor inventá-las.

Um plano passo a passo para o primeiro agente de tickets

Uma primeira implantação pode ser pequena. Esta sequência mantém o escopo honesto:

• Nomeie, do lado da empresa, um responsável que aprove as regras de cruzamento e as regras de vencimento.
• Liste as fontes que o agente pode ler: a caixa ou exportação do portal de notificações, a agenda de obras e a planilha de alocação de equipes. Deixe de fora tudo o que o primeiro papel não precisa.
• Descreva os campos de cruzamento em linguagem simples: endereço ou contorno do local, número do ticket, tipo de serviço, início planejado, período de validade do ticket e concessionárias notificadas.
• Defina as saídas. No começo, um resumo diário pela manhã e um rascunho de mensagem ao escritório para cada problema bastam. O agente não envia nada.
• Dê a todas as fontes acesso somente de leitura, e use a pasta de rascunhos como único lugar onde o agente pode escrever.
• Teste com obras passadas. Peça a um despachante que classifique cada alerta como correto, errado ou perdido, e mantenha esse registro.
• Gere o resumo em todo dia útil por um período fixo, e revise as classificações semanalmente antes de ampliar o escopo.
• Só acrescente sugestões de equipe depois que as verificações de ticket forem confiáveis por tempo suficiente para que o responsável confie nos alertas.

Trate cada aviso de ticket, e-mail de cliente e anotação de campo como texto não confiável. Um aviso pode conter frases que parecem instruções para o agente, e ele deve tratar essas frases como dados, nunca como comandos. As orientações da OWASP sobre injeção de prompt descrevem esse padrão e as escolhas de projeto que reduzem seu impacto, como limitar as ações que o agente pode disparar sem aprovação.

Escalas de equipe: onde o agente ajuda e onde não deve decidir

A programação de equipes envolve muitas restrições que o quadro já mostra: operadores, máquinas, transporte, horários de acesso ao local, visitas de fiscalização e clima. Um agente pode varrer essas informações em busca de conflitos. Exemplos típicos são um operador agendado em dois locais, uma escavadeira designada a uma obra enquanto a carreta está comprometida em outra, uma escavação no calendário sem ticket correspondente, ou uma janela de acesso ao local que fecha antes de o trabalho planejado terminar.

Cenário ilustrativo: uma empresa mantém três equipes. Uma obra de rede de água é adiantada em um dia, a pedido do cliente. O agente percebe que o ticket existente cobre a data original, mas não a nova, e que o único operador certificado para aquela máquina está alocado em outro local na nova data. Ele monta um resumo para o despachante com os dois problemas, um rascunho de pedido para renovar o ticket na nova data e duas opções alternativas de operador, retiradas da planilha de equipes. O despachante decide qual opção usar. O agente não envia a renovação nem altera a alocação.

Empresas de serviço que alocam equipes a obras com data enfrentam padrões parecidos. A mesma disciplina aparece em empresas de mudança, onde disponibilidade de equipe e datas de obra precisam coincidir antes de o caminhão ser carregado. A disponibilidade de equipamentos e as datas de devolução, que afetam as escalas de escavadeiras e compactadores, seguem a lógica descrita para locadoras de equipamentos.

Onde devem estar os limites de aprovação

O agente deve ter o menor acesso que o papel exige. Na prática, isso significa leitura da caixa de avisos, da agenda de obras, da planilha de equipes e do registro de equipamentos, e escrita apenas na pasta de rascunhos e no resumo diário. O agente não deve guardar credenciais capazes de enviar pedidos de locação, alterar despacho ou mensagens a clientes. Cada permissão deve estar anotada com um responsável nomeado e ser revisada sempre que uma fonte ou ferramenta mudar. As orientações de autorização da OWASP são uma referência útil para verificar o acesso a cada ação, e não apenas no momento da configuração inicial.

Uma lista simples de limites ajuda a equipe a combinar as regras antes da primeira execução:

• O agente pode ler: a caixa de avisos, a agenda de obras, a planilha de equipes e o registro de equipamentos.
• O agente pode escrever: rascunhos e o resumo diário. Nada é enviado.
• Uma pessoa deve aprovar: qualquer pedido de locação, qualquer envio de renovação de ticket, qualquer mudança de despacho e qualquer mensagem a cliente.
• Uma pessoa deve revisar mensalmente: a lista de permissões, a lista de fontes e o registro de alertas.

A Be Human projeta, implanta e opera esse tipo de estrutura para empresas. Uma primeira contratação define um papel útil, a memória e as ferramentas que esse papel precisa, os limites de aprovação e um critério de sucesso observável, que, para um agente de tickets, é saber se toda escavação planejada tem um ticket correspondente e vigente na data de início. A operação gerenciada pode então cobrir o acompanhamento dos alertas, avaliações periódicas com base nas classificações do despachante, manutenção quando uma integração de caixa de entrada ou calendário muda, revisões de permissões e resposta a incidentes caso uma fonte ou o agente se comporte de forma inesperada. O NIST AI Risk Management Framework é uma referência útil para mapear esses riscos e registrar quem aprovou o quê.

Quando uma operação gerenciada vale uma conversa

Muitas empresas de escavação conseguem rodar uma primeira versão com uma planilha compartilhada e uma pessoa cuidadosa no escritório. Uma operação gerenciada passa a valer a conversa quando o trabalho já superou esse arranjo. Sinais típicos incluem:

• Os tickets chegam por vários canais, e a mesma obra aparece com nomes diferentes em cada um.
• Equipes, equipamentos e subcontratados são programados em mais de uma ferramenta, e ninguém é responsável pela ligação entre elas.
• Encarregados ou pessoas do escritório mudam de função, e as regras de cruzamento vivem na cabeça das pessoas, não em um arquivo escrito.
• Os alertas estão sendo ignorados porque erram com frequência, e alguém precisa ajustá-los por avaliação, e não por tentativa e erro.
• As permissões foram crescendo com o tempo, e ninguém revisou o que o agente consegue acessar.

Se isso se aplica a você depende mais dos seus registros e das suas pessoas do que de qualquer modelo de IA. Se a resposta não estiver clara, comece com um papel e um critério de verificação, e mantenha cada decisão com as pessoas que já são responsáveis por ela. Faça o diagnóstico gratuito de IA da Be Human para identificar a primeira tarefa da sua operação que vale repassar a um agente.

Perguntas frequentes

Um agente de IA pode fazer os pedidos de locação para nós? Não no começo, e não é preciso começar por aí. O agente pode ler os avisos, comparar com o processo da obra e preparar um rascunho de pedido para uma pessoa conferir e enviar. Dar a ele permissão de envio é uma decisão separada, que deve vir depois de um histórico estável de alertas e de uma revisão de permissões por escrito.

Precisamos de um novo software de programação antes de começar? Normalmente não. Uma primeira versão pode ler as planilhas, exportações de calendário ou dados de quadro que você já mantém, desde que nomes de obras, endereços e datas sejam consistentes o bastante para cruzar. Se os registros forem inconsistentes, o primeiro trabalho útil costuma ser limpar esses campos, o que uma pessoa deve aprovar, mesmo que o agente ajude a listar as divergências.

E os e-mails ou avisos que trazem instruções fora do comum? Avisos de ticket, e-mails de clientes e anotações de campo são texto não confiável. Qualquer instrução dentro deles deve ser tratada como dado, não como comando, e o agente não deve ter ferramentas que permitam que esse texto dispare ações sem aprovação. As orientações da OWASP sobre injeção de prompt tratam desse padrão com mais detalhe.

Como saber se o agente está fazendo o trabalho dele? Comece com uma medida: se toda escavação planejada tem um ticket correspondente e vigente no dia de início. Compare os alertas do agente com as classificações do despachante toda semana, e acompanhe os problemas perdidos com o mesmo cuidado que os falsos alarmes. Amplie o escopo somente quando esse histórico tiver ficado estável por tempo suficiente para que o responsável confie nele.

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