Superinteligência e ERP: o que muda no software de gestão

Superinteligência e ERP: o que muda no software de gestão

Superinteligência e ERP se encontram em um ponto bem prático: o ERP não fica inteligente sozinho, mas a camada de agentes ao redor dele fica mais capaz de ler, cruzar e agir sobre os dados de gestão. Sem prever nada, a consequência para a empresa é clara: APIs previsíveis, permissões estreitas, dados limpos e registro de cada ação passam a valer mais do que a tela bonita do sistema. Quanto mais capaz o agente, mais o ERP precisa ser uma fonte de verdade confiável.

Principais pontos

• Superinteligência é um conceito hipotético. O que a empresa opera hoje são agentes com ferramentas, e é neles que as decisões de ERP e CRM devem se apoiar.
• A interface principal do ERP tende a deixar de ser só a tela e passar a ser o contrato de API que o agente consome.
• Um agente mais capaz não dispensa dado limpo. Ele pode contornar inconsistências sem avisar, o que esconde o problema em vez de resolvê-lo.
• Exija das APIs permissões granulares, idempotência, ambiente de teste, erros legíveis e trilha de auditoria.
• Comece com leitura, depois escrita limitada, sempre com aprovação humana nas ações que mexem em dinheiro, estoque ou cadastro.

O que superinteligência significa para quem opera um ERP?

O termo descreve um sistema hipotético que superaria pessoas em praticamente qualquer tarefa cognitiva. Não é algo que se contrata, instala ou integra ao ERP. Se você quer entender a diferença entre esse conceito e o que está disponível, vale ler o texto sobre a diferença entre AGI e superinteligência.

O que a empresa opera de fato é um agente: um modelo de linguagem que recebe um objetivo, usa ferramentas (consultar, calcular, criar um registro) e devolve um resultado. Neste artigo, mantemos três camadas separadas, como pede uma boa prática editorial:

• Documentação oficial: o que fornecedores e protocolos abertos descrevem sobre ferramentas, autorização e conexão com sistemas.
• Experiência de implementação: o que costuma dar errado quando um agente encontra um ERP real, com cadastro duplicado, campo livre e integração antiga.
• Hipótese: o que agentes mais capazes poderiam mudar. Tratamos como cenário de planejamento, não como previsão.

A pergunta útil para o gestor não é quando a superinteligência chega. É: se o agente que eu consigo usar amanhã for bem mais capaz do que o de hoje, meu ERP e meu CRM estão prontos para recebê-lo com segurança?

Como a relação com ERP e CRM muda quando o agente é mais capaz?

Hoje, grande parte do trabalho em sistemas de gestão é humano e manual: abrir a tela, filtrar, exportar para planilha, conferir, voltar e digitar. O sistema foi desenhado para uma pessoa navegar.

Com agentes, três mudanças aparecem na prática:

• O consumidor do sistema passa a ser, também, um programa. Ele não vê a tela, chama operações. O que não existe na API, o agente não faz de forma confiável.
• A pergunta vira linguagem natural. Em vez de montar um relatório, o responsável pergunta no WhatsApp ou no chat interno e o agente consulta ERP e CRM juntos.
• A ação sai do humano e vai para um intermediário. Criar um pedido, ajustar um prazo ou registrar uma reunião passa por uma ferramenta que o agente aciona, e isso exige limites explícitos.

Há uma armadilha aqui. Um agente mais capaz costuma lidar melhor com dados bagunçados: adivinha que dois cadastros são o mesmo cliente, interpreta um status ambíguo, preenche uma lacuna. Isso parece vantagem, mas é risco. Quando o agente resolve a inconsistência em silêncio, ninguém corrige a origem, e a decisão passa a depender de uma suposição que não ficou registrada.

No lado do CRM, o movimento é parecido. O registro de reunião, a atualização de etapa do funil e o histórico de contato são tarefas que um agente pode preparar. O texto sobre como atualizar o CRM com IA depois da reunião de vendas mostra como separar o que o agente propõe do que a pessoa confirma.

O que a empresa deve exigir das APIs do ERP e do CRM?

Antes de falar em modelo, fale em contrato. Estes são os requisitos que usamos como lista de verificação ao avaliar um ERP ou CRM para uso com agentes:

• Cobertura real: as operações que o processo usa existem na API, e não apenas na tela. Se o fornecedor diz que existe, peça a documentação da operação específica.
• Permissões por escopo: leitura separada de escrita, e escrita separada por tipo de objeto. O agente precisa de credencial própria, nunca a de um usuário humano compartilhada.
• Autenticação padrão: fluxos como OAuth 2.0, com expiração e revogação, em vez de senha fixa guardada em um fluxo de automação.
• Idempotência: repetir a mesma chamada, por falha de rede ou nova tentativa, não pode duplicar um pedido, uma cobrança ou um lançamento.
• Erros legíveis: mensagens que dizem o que faltou e o que corrigir. O agente (e quem audita) depende disso para não inventar uma explicação.
• Ambiente de teste: um sandbox ou homologação com dados fictícios, para exercitar o agente sem risco.
• Trilha de auditoria: cada alteração registra qual credencial agiu, quando e com quais parâmetros.
• Eventos ou webhooks: o agente fica sabendo de mudanças sem consultar o sistema a cada instante.
• Versionamento e documentação estável: uma mudança de campo não pode quebrar o fluxo em silêncio.

Sobre conectar agentes a sistemas, o Model Context Protocol é um padrão aberto que descreve como expor ferramentas e dados a modelos de forma organizada. Ele ajuda na conexão, mas não substitui uma API bem desenhada nem a autorização feita do lado do sistema. A Anthropic também publica orientações sobre como escrever ferramentas para agentes: poucas, com propósito claro, nomes e parâmetros sem ambiguidade e respostas enxutas. Isso vale para quem for expor operações do ERP.

A regra de autorização merece destaque: a decisão sobre o que o agente pode fazer deve ser aplicada pelo sistema, com o princípio do menor privilégio, e não por uma instrução no prompt. Prompt é pedido, permissão é barreira.

O que são dados limpos na prática?

Dado limpo não é perfeição. É dado com significado único e dono definido. Use esta lista como ponto de partida:

• Cadastro de clientes sem duplicidade, com um identificador único e regra para tratar CNPJ e CPF conforme a LGPD.
• Status com definição escrita. O que é pedido aprovado, faturado, entregue e concluído precisa significar a mesma coisa para financeiro, comercial e operação.
• Produtos e serviços com código, unidade e descrição consistentes.
• Datas, unidades de medida e formatos padronizados entre ERP e CRM.
• Campos obrigatórios realmente preenchidos, e não preenchidos com um texto qualquer só para salvar o registro.
• Fonte de verdade definida para cada dado quando ERP e CRM divergem, por exemplo qual sistema manda no endereço de cobrança.
• Dados pessoais minimizados: o que o agente não precisa ver não deve sair do sistema nem ir para o contexto do modelo.
• Campos de texto livre tratados como entrada não confiável, já que podem conter qualquer coisa colada por clientes ou por outros sistemas.

Se a empresa só puder corrigir uma coisa antes de piloto, corrija a definição de status e a duplicidade de cadastro. São as duas causas mais comuns de resposta errada com aparência de resposta segura.

Para quem pensa na arquitetura inteira, o artigo sobre a camada de superinteligência da empresa em cinco blocos descreve onde dados, ferramentas, memória e controle se encaixam.

Cenário ilustrativo: consulta de pedido por WhatsApp

Cenário ilustrativo, sem relação com nenhuma empresa real. Uma distribuidora quer que o time comercial pergunte a um agente, no WhatsApp interno, se um pedido já foi faturado e quando sai.

Na primeira versão, o agente só tem permissão de leitura no ERP. Ele consulta o pedido, cruza com o cadastro do CRM e responde com o status e a fonte da informação. Quando o cliente pede para mudar o prazo, o agente não altera nada: cria uma solicitação para um responsável aprovar, com os dados já preenchidos.

No teste, aparece o problema típico: o mesmo cliente existe duas vezes no cadastro, e o agente encontra dois pedidos com status diferentes. Um modelo mais capaz poderia escolher um dos dois por inferência. A decisão correta do desenho é outra: quando houver mais de um candidato, o agente informa a ambiguidade, mostra as duas opções e pede confirmação. Depois, a empresa corrige o cadastro na origem.

O exemplo mostra o princípio: a capacidade do agente decide o quanto ele ajuda, mas a qualidade do dado e o limite de ação decidem o quanto ele é seguro.

Como aplicar mapear, limitar, pilotar e transferir

O método que usamos com empresas segue quatro passos, e cada um tem um efeito direto sobre ERP e CRM. Um fluxo de teste com dados fictícios também faz parte do caminho, como descrito em como testar agente de IA com mocks e sandbox.

• Mapear: descreva o processo atual e registre a linha de base, com quem faz, em qual sistema, quanto tempo leva e onde erra. Liste quais dados do ERP e do CRM entram.
• Limitar: defina o que o agente lê, o que ele pode escrever e o que exige aprovação humana. Reduza os dados enviados ao modelo ao necessário.
• Pilotar: escolha um fluxo real, com registro de cada consulta e ação, e uma métrica de sucesso combinada antes de começar. Teste primeiro em ambiente de homologação.
• Transferir: entregue documentação, permissões, logs e responsáveis. Então decida com a equipe se expande, ajusta ou encerra.

A decisão de parar é parte do método. Um piloto que mostra que o dado ainda não está pronto já cumpriu um papel útil.

Quais riscos continuam mesmo com modelos melhores?

Modelo mais capaz não elimina os riscos de operação. Os principais:

• Injeção de instruções: um texto em campo de observação, e-mail ou mensagem pode tentar mandar o agente fazer algo. A recomendação da OWASP é tratar todo conteúdo externo como não confiável e limitar o que o agente pode acionar.
• Excesso de permissão: uma credencial ampla demais transforma um erro pequeno em prejuízo grande.
• Falta de rastreio: sem log de consulta e ação, não há como explicar uma decisão a um cliente, ao auditor ou à própria equipe.
• Dados pessoais: LGPD exige finalidade, necessidade e cuidado com o que sai da empresa. Se uma decisão automatizada afetar alguém, acompanhe também o direito de revisão. Para o cenário regulatório, vale seguir o marco legal da IA no Brasil.
• Custo e dependência: acompanhe o volume de chamadas e o que fica fora da empresa, para não descobrir a dependência só na renovação.

O NIST AI Risk Management Framework oferece uma estrutura geral para organizar esse tipo de gestão de risco, útil quando a empresa precisa documentar responsáveis e controles.

Perguntas frequentes

A superinteligência vai substituir o ERP? Não há base para afirmar isso, e este artigo não faz previsões. O que dá para planejar é que agentes mais capazes passarão a consultar e operar o ERP por API, e por isso o sistema precisa continuar sendo a fonte de verdade, com regras e auditoria.

Preciso trocar de ERP para usar agentes de IA? Nem sempre. Se o seu ERP tem API documentada, permissões por escopo e ambiente de teste, é possível começar por leitura e por um fluxo pequeno. Se não tem, a conversa com o fornecedor sobre esses requisitos vem antes de qualquer decisão de troca.

Posso dar permissão de escrita no ERP ao agente? Pode, mas de forma gradual. Comece com leitura, depois permita criar rascunhos ou solicitações, e mantenha aprovação humana para ações que movimentam dinheiro, estoque, preço ou cadastro. A permissão deve ser aplicada pelo sistema, e cada ação precisa ficar registrada.

Por onde começar se meu cadastro está bagunçado? Comece pelo mapeamento: onde há duplicidade, quais status têm definição ambígua e qual sistema manda em cada dado. Corrigir isso em um escopo pequeno já melhora o trabalho humano e prepara o terreno para um piloto com agente.

Fontes

• Model Context Protocol: introdução
• Anthropic: Writing effective tools for agents
• OWASP: Authorization Cheat Sheet
• NIST AI Risk Management Framework