Integrar IA ao TOTVS Protheus ou SAP: caminhos e cuidados

Integrar IA ao TOTVS Protheus ou SAP: caminhos e cuidados

Para integrar IA ao TOTVS Protheus, o caminho mais seguro é começar por leitura: a IA consulta dados do ERP por uma API REST ou por uma camada intermediária controlada, sem alterar nada. Só depois de medir a qualidade das respostas vale pensar em escrita, e sempre por rotinas oficiais do ERP, com aprovação humana. O raciocínio é o mesmo para o SAP, mudando as interfaces disponíveis e o nível de governança exigido.

Principais pontos

• A IA deve acessar o ERP por uma interface controlada (API REST ou middleware), não por credenciais amplas nem por consulta livre ao banco.
• Leitura primeiro: consultar pedido, estoque, título ou cadastro já resolve muitos fluxos e quase não traz risco de integridade.
• Escrever direto nas tabelas do Protheus ou do SAP ignora regras de negócio, validações fiscais e trilhas de auditoria do sistema.
• Quando a escrita for necessária, ela entra como proposta ou rascunho, passa por aprovação humana e usa a rotina oficial do ERP.
• Todo piloto precisa de log de cada consulta, permissões mínimas, tratamento de dados pessoais conforme a LGPD e uma métrica de sucesso combinada antes.

Quais são as formas de acessar o Protheus ou o SAP?

Existem quatro caminhos comuns. Cada um tem um perfil de risco diferente, e a escolha depende da versão do ERP, dos módulos instalados, do licenciamento e da equipe que mantém o ambiente. Confirme sempre a disponibilidade de cada recurso na documentação oficial da TOTVS ou da SAP para a sua versão, porque o que existe em uma instalação pode não existir em outra.

• API REST ou serviços expostos pelo próprio ERP: no Protheus, é possível publicar serviços REST (inclusive customizados pela equipe de desenvolvimento). No SAP, as interfaces variam conforme a versão e podem incluir OData, BAPIs e IDocs. É o caminho preferido, porque passa pelas regras do sistema.
• Acesso direto ao banco de dados: uma conexão de leitura, de preferência em réplica ou em visões criadas para esse fim. Funciona para relatórios e consultas, mas expõe a estrutura interna e exige muito cuidado com permissões.
• Middleware ou camada de integração: um serviço próprio entre a IA e o ERP, que traduz pedidos da IA em chamadas controladas. Pode ser uma plataforma de integração que a empresa já usa ou um serviço enxuto desenvolvido sob medida.
• Arquivos e exportações agendadas: planilhas, CSV ou relatórios gerados pelo ERP e lidos pela IA. É simples e seguro para começar, com o limite de que os dados envelhecem entre uma exportação e outra.

Na prática, a combinação mais saudável costuma ser API do ERP por trás de um middleware pequeno, que é o único componente que a IA enxerga. Esse mesmo desenho aparece em integrações com sistemas menores, como descrevemos em Integrar IA ao Bling, Omie ou Tiny, só que no ERP de médio e grande porte as regras são mais densas e o custo de um erro é maior.

Por que começar por leitura?

Leitura é o terreno onde a IA já entrega valor com risco baixo. Responder qual é o status de um pedido, quando um título vence, se um item está disponível ou qual é a condição de pagamento de um cliente são tarefas de consulta. Se a IA errar, o pior efeito é uma resposta incorreta que um humano pode corrigir, e não um lançamento errado no financeiro ou no fiscal.

Começar por leitura também ensina coisas que você precisa saber antes de qualquer escrita:

• Se os dados do ERP são bons o bastante. Cadastros duplicados, campos livres preenchidos de formas diferentes e status ambíguos aparecem rápido quando uma IA tenta usá-los.
• Quais perguntas as pessoas realmente fazem. O volume de consultas mostra quais endpoints valem a pena construir.
• Quanto o ERP aguenta. Consultas em excesso podem pesar em horários críticos, e é melhor descobrir isso com leitura controlada.
• Onde mora o dado pessoal. Cadastro de cliente, CPF, endereço e histórico de compras entram na LGPD, e o piloto de leitura mostra o que de fato precisa chegar ao modelo.

Um bom critério: se a tarefa pode ser feita por alguém com perfil somente consulta no ERP, ela é candidata a primeiro piloto.

Por que escrever direto no ERP é arriscado?

O maior erro é tratar o ERP como uma planilha que a IA pode editar. Um ERP como Protheus ou SAP concentra regras que não estão visíveis em uma tabela: validações fiscais, amarrações entre módulos, gatilhos, controle de estoque, reservas, alçadas de aprovação e rastreabilidade. Gravar direto no banco pula tudo isso.

Os riscos mais frequentes:

• Integridade: um registro inserido sem passar pela rotina oficial pode ficar sem os vínculos que outros módulos esperam, e o problema só aparece no fechamento ou na emissão de nota.
• Auditoria: alterações fora das rotinas do sistema podem não deixar a trilha que contabilidade e auditoria exigem.
• Suporte e garantia: escrever diretamente nas tabelas costuma ser desaconselhado pelos fornecedores e pode complicar o suporte e as atualizações de versão. Verifique o contrato e a política do seu fornecedor.
• Erro do modelo: modelos de linguagem podem interpretar mal uma instrução, e o excesso de autonomia (o que o OWASP chama de excessive agency) é um risco listado no OWASP Top 10 para aplicações com LLM. Dar a um agente poder de escrita sem limites multiplica o efeito de qualquer erro.
• Repetição: se uma chamada falha e é repetida, o mesmo pedido pode ser criado duas vezes. É o problema que as chaves de idempotência resolvem, como mostra a documentação de requisições idempotentes da Stripe, usada aqui apenas como exemplo do conceito.

Escrever pela API oficial reduz esses riscos, mas não os elimina. Por isso a escrita merece um desenho próprio, descrito mais abaixo.

Como desenhar a camada intermediária para a IA

O middleware é o que transforma um ERP complexo em um conjunto pequeno de ações seguras. Em vez de dar à IA acesso genérico, você expõe operações nomeadas e limitadas, como consultar_pedido, listar_titulos_em_aberto ou verificar_estoque. Cada operação recebe parâmetros validados e devolve apenas os campos necessários.

Princípios que costumam funcionar:

• Permissões mínimas: uma credencial exclusiva para a integração, com perfil somente leitura no começo. As recomendações da folha de referência de autorização do OWASP ajudam a pensar em menor privilégio e negação por padrão.
• Escopo por usuário: se o atendente de uma filial só vê clientes dela no ERP, a IA que age em nome dele deve herdar essa restrição, e não usar uma credencial que enxerga tudo.
• Campos mínimos: não envie ao modelo o cadastro inteiro. Se a resposta só precisa de status e previsão de entrega, é isso que sai do middleware.
• Registro de tudo: quem perguntou, o que foi consultado, o que voltou e o que o modelo respondeu. Sem isso não há como investigar um erro nem provar o que aconteceu.
• Limites de taxa: proteja o ERP de rajadas de consulta, inclusive as geradas por loops do agente.

Se o plano é usar o protocolo MCP para expor essas operações a um agente, vale ler a introdução oficial ao Model Context Protocol e o nosso texto sobre como criar um servidor MCP para o sistema interno com leitura primeiro. O MCP é uma forma de padronizar a ponte, mas as regras de permissão e de log continuam sendo responsabilidade de quem constrói.

Passo a passo para um primeiro piloto de leitura

Um roteiro simples, que cabe em um fluxo real e pequeno:

• Passo 1, escolher um fluxo: uma pergunta repetida, com resposta que já existe no ERP. Exemplo: situação de um pedido ou segunda via de informações de cobrança.
• Passo 2, medir o ponto de partida: quanto tempo a equipe leva hoje, quantas vezes a pergunta aparece e onde ocorrem os erros. Sem baseline, não há como saber se melhorou.
• Passo 3, listar os dados necessários: quais campos, de quais tabelas ou serviços, e quais deles são dados pessoais.
• Passo 4, escolher o caminho de acesso: API do ERP ou visão de banco somente leitura, sempre atrás do middleware.
• Passo 5, definir permissões e limites: credencial exclusiva, escopo por usuário, taxa máxima de consultas e lista do que a IA nunca responde.
• Passo 6, construir as operações: poucas, nomeadas e com retorno enxuto.
• Passo 7, testar com casos reais anonimizados: compare a resposta da IA com o que o ERP mostra e registre as divergências.
• Passo 8, rodar em paralelo: a IA sugere ou responde, uma pessoa confere durante um período combinado.
• Passo 9, decidir: expandir, ajustar ou parar, com base na métrica definida no início. Nosso texto sobre como medir um piloto de automação com IA detalha métricas e pontos de decisão.

Cenário ilustrativo: status de pedido para a equipe comercial

Imagine, como cenário ilustrativo, uma distribuidora que usa Protheus e cujos vendedores perguntam o tempo todo ao financeiro e à logística se determinado pedido foi faturado, quando sai e se há bloqueio de crédito. A empresa cria um middleware com duas operações de leitura: situação do pedido e situação de crédito do cliente. O agente de IA, acessado por um canal interno de mensagens, recebe a pergunta do vendedor, identifica o número do pedido e chama a operação.

O middleware confere se aquele vendedor tem direito de ver aquele cliente, devolve só status, data prevista e motivo do bloqueio (sem dados bancários nem documentos), e registra a consulta. Se o pedido não for encontrado ou houver dúvida, o agente encaminha a pessoa ao setor responsável em vez de adivinhar. Nada é gravado no ERP. Depois de um período de comparação com as respostas humanas, a empresa decide se amplia para outras perguntas.

Quando e como liberar escrita com segurança?

Há fluxos em que escrever faz sentido: criar uma proposta, registrar uma ocorrência, abrir um pedido de compra rascunho. A regra é que a IA nunca grave diretamente no resultado final. Um desenho prudente:

• A IA produz uma proposta estruturada (por exemplo, um pedido em rascunho) em uma fila ou área de pré-lançamento.
• Uma pessoa revisa e aprova, vendo exatamente o que será gravado.
• A gravação acontece por rotina oficial do ERP (API ou serviço do próprio sistema), nunca por SQL direto.
• Cada operação usa chave de idempotência ou verificação de duplicidade.
• Há limite de valor, de quantidade e de tipo de operação, e um botão para desativar a escrita sem derrubar a leitura.
• Tudo fica em log, com a decisão humana associada.

Se o fluxo afeta pessoas, como decisões de crédito ou de elegibilidade, considere também o direito de revisão previsto na LGPD, que explicamos em decisões automatizadas na LGPD. E para validar entradas, saídas e ações do agente antes que cheguem ao ERP, veja guardrails para agentes de IA.

E o SAP, muda alguma coisa?

A lógica não muda: acesso controlado, leitura primeiro, escrita por rotina oficial e aprovação humana. O que muda é o ecossistema. Em ambientes SAP, a integração costuma passar por uma camada de integração corporativa e por times de TI com processos de mudança mais formais, o que alonga o prazo, mas também ajuda a garantir governança. Pergunte à equipe de basis e de integração quais interfaces estão liberadas para uso externo na sua versão e quais exigem licenciamento adicional. Em ambos os ERPs, envolver quem mantém o sistema desde o início evita retrabalho e surpresas.

Como aplicamos o método: mapear, limitar, pilotar, transferir

No trabalho de integração com ERP, o método segue quatro etapas. Mapear: entender o processo atual, quem pergunta o quê e qual é o baseline. Limitar: definir quais dados e quais ações a IA pode usar, começando por leitura. Pilotar: rodar um fluxo real, com logs e uma métrica de sucesso acordada. Transferir: entregar a operação documentada para a equipe e decidir, com evidência, entre expandir, ajustar ou encerrar. Quando a empresa prefere não operar sozinha, a manutenção e o monitoramento podem ser feitos de forma gerenciada pela Be Human.

Perguntas frequentes

Dá para ligar a IA direto no banco de dados do Protheus? Tecnicamente dá, mas não é o caminho recomendado. Se for inevitável, use uma réplica ou visões somente leitura, uma credencial exclusiva e um middleware no meio, e nunca permita escrita. Prefira a API sempre que ela cobrir a necessidade.

Preciso de um servidor MCP para integrar IA ao ERP? Não é obrigatório. O MCP é uma forma de padronizar como o agente acessa ferramentas, mas um middleware com endpoints bem definidos também resolve. O importante é que o acesso seja limitado, registrado e validado, independentemente do protocolo.

A IA pode lançar pedidos ou notas no ERP sozinha? Não recomendamos no início, e em fluxos fiscais e financeiros a aprovação humana tende a continuar necessária. O desenho mais seguro é a IA gerar um rascunho, uma pessoa aprovar e a gravação ocorrer por rotina oficial, com proteção contra duplicidade e registro completo.

Os dados do ERP podem ser enviados a um modelo de IA em nuvem? Depende do dado e do contrato. Envie o mínimo necessário, evite dados pessoais sensíveis quando não forem essenciais e avalie a base legal e a necessidade de um relatório de impacto, conforme o caso. Envolva o jurídico e o encarregado de dados antes do piloto, e consulte as orientações da ANPD.

Fontes

• Model Context Protocol: introdução
• OWASP: guia de autorização
• OWASP Top 10 para aplicações com LLM
• Stripe: requisições idempotentes (exemplo do conceito)