Como conectar um agente de IA ao ERP: o que verificar primeiro

Para conectar um agente de IA ao ERP, dê a ele o menor acesso que sustente uma tarefa bem definida, verifique os dados que ele vai ler e coloque toda escrita atrás de validação e aprovação. Siga os controles nesta ordem: acesso, qualidade dos dados e segurança de escrita. Um agente que lê com precisão e escreve com cautela pode ganhar mais escopo depois. Um agente que escreve cedo demais é difícil de desfazer.

Principais pontos

• Comece com uma identidade própria e um perfil limitado a uma tarefa, não com o login emprestado de um funcionário nem uma conta de administrador.
• Deixe o agente ler antes de escrever e comprove que a leitura está correta usando registros que sua equipe já conhece bem.
• Trate duplicidades, status inconsistentes e campos de texto livre como riscos de qualidade de dados que o agente vai herdar e amplificar.
• Torne a escrita segura com rascunhos, validação, idempotência e aprovação para tudo que lança, paga, aprova ou exclui.
• Defina um responsável, registre cada chamada e teste o botão de desligar antes de entrar em produção, não depois do primeiro incidente.

Por que um ERP exige mais cuidado que outras conexões?

O ERP costuma ser o sistema de registro da empresa. Pedidos, notas fiscais, estoque, fornecedores e contabilidade vivem ali e se referenciam entre si. Um valor errado em um registro raramente fica só nele: ele chega a relatórios, pagamentos, pontos de reposição e promessas feitas a clientes.

A maioria dos ERPs também é customizada. Campos têm significados locais, status seguem o processo da própria empresa e regras de aprovação existem porque alguém um dia se deu mal. Um agente que nunca viu essas convenções lê o esquema ao pé da letra, e o esquema não explica por que um status chamado "encerrado" às vezes ainda tem itens em aberto.

Por fim, um agente se comporta de forma diferente de um script. O script faz exatamente o que foi programado. O agente interpreta e-mails, documentos e anotações e decide qual ferramenta chamar. Essa flexibilidade é o valor dele, e é também o motivo pelo qual os limites em torno do ERP precisam ser impostos pelo sistema, não apenas pedidos em um prompt.

Quais verificações de acesso vêm primeiro?

Decida para que o agente serve antes de decidir o que ele pode alcançar. Uma descrição de papel como "conferir confirmações de fornecedores com pedidos de compra em aberto e sinalizar divergências" já implica uma lista curta de objetos e ações. Tudo fora dela deve ser negado por padrão, e quem nega deve ser o ERP, não o agente. O princípio é detalhado em menor privilégio para agentes de IA, e a orientação de autorização da OWASP descreve a mesma ideia: negar por padrão e verificar cada requisição.

Antes de conectar, confirme cada item:

• Identidade própria: o agente tem sua conta de serviço, e suas ações se distinguem das de qualquer pessoa na trilha de auditoria.
• Perfil por tarefa: o perfil concede apenas os objetos, empresas, depósitos ou livros contábeis que a tarefa exige, sem nada herdado de um modelo.
• Leitura primeiro: a primeira fase usa permissões somente de leitura, e as de escrita entram uma ação por vez.
• Exposição por campo: campos sensíveis, como dados bancários, folha de pagamento ou preço de custo, ficam de fora, a menos que a tarefa realmente precise deles.
• Tratamento de credenciais: segredos ficam em um cofre gerenciado, são rotacionados com periodicidade definida e nunca aparecem em prompts, anotações ou na memória do agente.
• Ambientes separados: existe uma instância de teste ou homologação, com credenciais diferentes das de produção.
• Revogação: alguém já testou desativar a conta e confirmou que o agente para sem causar problemas.
• Responsável nomeado: uma pessoa responde pela conexão e revisa as permissões com regularidade.

A distinção entre ler, preparar e enviar vale diretamente para o ERP. Ler, preparar e enviar são permissões diferentes, e no ERP os equivalentes são consultar, criar em estado de rascunho e lançar. Conceda cada uma em uma etapa separada, com revisão própria.

Como verificar a qualidade dos dados antes de o agente ler qualquer coisa?

O agente não sabe quais registros sua equipe desconfia em silêncio. Se o cadastro de fornecedores tem três entradas para o mesmo fornecedor, o agente vai escolher uma, e talvez seja justamente a que ninguém usa. Problemas de dados que as pessoas contornam viram erros silenciosos quando o agente segue o dado literalmente.

Faça estas verificações no recorte de dados que a tarefa toca, não no ERP inteiro:

• Duplicidades no cadastro mestre: clientes, fornecedores e itens que aparecem mais de uma vez, com grafias ou códigos diferentes.
• Campos obrigatórios: campos dos quais o processo depende, mas que costumam ficar vazios ou preenchidos com valores de enchimento.
• Significado dos status: o que cada valor de status quer dizer na prática, escrito por quem trabalha com ele todos os dias.
• Unidades, moedas e datas: se quantidades, códigos de moeda e formatos de data são consistentes entre registros e empresas.
• Registros desatualizados: pedidos em aberto ou fornecedores inativos que nunca foram encerrados e pareceriam atuais para um agente.
• Campos customizados: qualquer campo cujo nome já não corresponde ao uso real.
• Campos de texto livre: observações, linhas de memorando e anexos que podem conter instruções, dados de contato ou texto colado de fora.

O último item merece atenção. Tudo que o agente lê pode influenciar o que ele faz em seguida, inclusive um texto que um fornecedor ou cliente digitou em um campo de comentário. Mantenha esses campos fora do contexto confiável do agente sempre que possível e trate o conteúdo como dado, nunca como instrução. Isso é o que se chama de injeção de prompt em documentos de negócio, e vale proteger.

Depois, faça um teste de comparação. Escolha um conjunto de registros reais, peça ao agente que os resuma ou classifique e peça ao responsável pelo processo que confira as respostas com o que ele sabe. As divergências normalmente apontam para uma definição de dado que precisa ser escrita, não para um problema do modelo. Registre essas definições na descrição das ferramentas, para que o agente as receba sempre.

O que torna seguras as escritas no ERP?

Segurança de escrita é um conjunto de mecanismos, e prompt não é um deles. Uma frase pedindo que o agente tenha cuidado não impede uma chamada malformada. Quem impede são os controles que ficam na camada de ferramentas e no próprio ERP.

Use este guia de decisão para classificar cada ação que o agente possa executar:

• Criar em estado de rascunho: permitido logo no início, com registro em log, porque uma pessoa ou uma regra ainda precisa liberar o registro.
• Atualizar campos de baixo risco, como observações, etiquetas ou datas de acompanhamento: permitido após testes, com revisão humana por amostragem.
• Atualizar quantidades, datas que geram compromissos ou cadastros mestres de fornecedores e clientes: permitido apenas com validação e etapa de aprovação.
• Lançar, aprovar, pagar, liberar, cancelar ou excluir: aprovação humana sempre, até que o responsável pelo processo decida o contrário por escrito.
• Qualquer coisa irreversível ou que afete a contabilidade: fique fora das ferramentas do agente no começo.

Em torno desse guia, acrescente quatro mecanismos. Primeiro, validação: a ferramenta verifica se os campos obrigatórios existem, se os valores estão em faixas esperadas e se os registros referenciados são reais antes de chamar o ERP. Segundo, idempotência: se o agente tentar de novo após um tempo esgotado, o ERP não pode criar um segundo pedido de compra nem uma segunda nota. Idempotência em agentes de IA explica o padrão, e a documentação da Stripe sobre requisições idempotentes é um bom exemplo de como um provedor define isso. Terceiro, limites: restrinja quantos registros o agente pode tocar por execução e por dia, para que um erro continue pequeno. Quarto, uma chave de parada: uma única ação que suspende todas as escritas e mantém leituras e logs funcionando.

O desenho das ferramentas também importa. Ferramentas estreitas, como "criar linha de pedido de compra em rascunho", são mais seguras e mais fáceis de testar do que uma ferramenta genérica do tipo "executar qualquer operação do ERP". A orientação da Anthropic sobre como escrever ferramentas para agentes aponta o mesmo: entradas claras, saídas claras e erros descritivos ajudam o agente a se recuperar sem adivinhar. Veja também contratos de ferramentas de IA.

O agente deve usar a API ou a tela?

Prefira a API oficial do ERP ou uma integração mantida pelo fornecedor sempre que existir. Uma API oferece entradas tipadas, permissões explícitas, erros previsíveis e uma trilha de auditoria compatível com a do próprio sistema. A automação de navegador, em que o agente clica pela interface, alcança funções sem API, mas herda a fragilidade das telas e muitas vezes exige credenciais mais amplas.

Se a automação de navegador for a única opção, aperte todo o resto: conta dedicada, perfil restrito, registro gravado da sessão e nenhum acesso a telas de aprovação ou lançamento. Os prós e contras estão em API ou automação de navegador para agentes de IA.

Verifique também o que acontece quando o ERP está lento, fora do ar ou em manutenção. O agente deve parar e avisar, não tentar em loop nem seguir por outro caminho que pule um controle.

Como é uma primeira implantação segura?

Este é um cenário ilustrativo, não um caso real. Uma distribuidora quer que um agente confira e-mails de confirmação de fornecedores com pedidos de compra em aberto e sinalize diferenças de quantidade ou de data de entrega.

A equipe começa com acesso somente leitura aos pedidos de compra em aberto de um grupo de compras. Compara as correspondências do agente com dez pedidos que o comprador conhece de cor e descobre que um campo de status é usado de duas maneiras. Documenta o significado e o inclui na descrição da ferramenta. Em seguida, o agente passa a poder gravar um alerta em um campo de observações e criar uma solicitação de alteração em rascunho, nada além disso. Um comprador revisa cada rascunho durante um período de teste. Só depois que a revisão mostra resultados consistentes a equipe considera deixar o agente propor uma mudança de data, ainda exigindo aprovação antes de o ERP ser atualizado.

A mesma sequência serve como plano geral:

• Defina por escrito o papel único e os registros que ele toca.
• Crie a identidade dedicada com acesso somente leitura em ambiente de teste.
• Faça as verificações de qualidade no recorte relevante e registre as definições de status e campos.
• Rode o teste de comparação com registros reais e alguém que os conheça.
• Adicione ferramentas de escrita apenas em rascunho, com validação, idempotência, limites e logs.
• Teste os casos de falha: credenciais expiradas, envios duplicados, campos ausentes, ERP fora do ar.
• Passe para produção com o mesmo escopo, revisão humana em toda escrita e chave de parada testada.
• Revise os logs periodicamente e amplie as permissões uma ação por vez.

Se as credenciais expirarem durante esse processo, o agente deve parar e perguntar, como descrito em o que um agente deve fazer quando uma conexão expira. Antes de entrar em produção, percorra os itens do checklist para aceitar uma integração de agente de IA.

Como a Be Human cuida da conexão com o ERP?

A Be Human trata a conexão com o ERP como parte da configuração operacional do agente, não como uma instalação única. Um primeiro projeto define um papel útil, os registros e ferramentas de que ele precisa, os limites de aprovação e um critério de sucesso observável. O acesso é restrito a esse papel, as escritas começam como rascunhos e as aprovações ficam com as suas pessoas. Na operação gerenciada, a Be Human pode monitorar a integração, executar avaliações recorrentes, revisar permissões, manter a conexão quando o ERP mudar e responder a incidentes, com as mudanças controladas e documentadas.

Perguntas frequentes

O agente deve se conectar primeiro à produção ou a uma cópia de teste? Comece por uma cópia de teste ou homologação, para experimentar casos de falha sem consequências. Depois passe para produção com o mesmo escopo estreito, somente leitura, e adicione escritas só quando os testes de comparação forem aprovados. Garanta que as credenciais de teste não funcionem em produção.

Precisamos limpar todos os dados do ERP antes de conectar um agente? Não. Limpe e defina apenas o recorte de dados que a tarefa do agente toca, porque uma limpeza total pode atrasar o projeto sem melhorar o primeiro papel. Documente as definições que importam, como o significado dos status e os campos customizados, e amplie a limpeza conforme o escopo do agente crescer.

Quais ações do ERP um agente nunca deve executar sozinho? Lançar na contabilidade, aprovar ou liberar pagamentos, excluir registros e alterar dados bancários ou cadastros mestres devem exigir aprovação humana, pelo menos no começo. O agente pode preparar o rascunho, reunir as evidências e explicar o raciocínio, para que quem aprova decida rápido e com o contexto completo.

Quem deve ser o responsável pela conexão dentro da empresa? Uma pessoa nomeada, em geral o dono do processo ou um líder de operações, deve responder pelo escopo, pela revisão e pela chave de parada. A TI ou um fornecedor pode cuidar da parte técnica, mas quem decide o que o agente pode fazer é a área de negócio. Registre isso por escrito na definição do papel.

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