Por que IA TOTVS exige quem nasceu dentro do Protheus

Quando alguém pergunta qual ERP roda o mid-market brasileiro, a resposta não é SAP, não é Oracle, não é Dynamics. É TOTVS. Isso não é uma curiosidade de mercado: é o ponto de partida de qualquer projeto de inteligência artificial para operações industriais, de distribuição ou de serviços no país. Quem chega com uma plataforma de agentes afinada para SAP descobre que acertou a tecnologia e errou o país.

Por que o mid-market brasileiro converge no TOTVS

A TOTVS controla, segundo análises de mercado e relatórios setoriais amplamente citados no Brasil, uma fatia próxima de metade do segmento de ERP para médias empresas no país. A empresa está listada na B3 desde 2006, acumula dezenas de milhares de clientes ativos e reporta bilhões de reais em receita anual, números publicados em seus próprios balanços trimestrais. O Protheus, seu ERP principal para médias empresas, está instalado em indústrias, mineradoras, distribuidoras e prestadoras de serviço de norte a sul do país. Existe também uma segunda camada dessa realidade: o Protheus não é um produto que a TOTVS entrega padronizado. Em três décadas de mercado, ele acumulou camadas de customização em cada cliente. Cada empresa tem sua versão, seus campos adicionais, suas rotinas personalizadas em ADVPL, a linguagem proprietária do sistema. Quando um projeto de IA chega a esse ambiente, está integrando um sistema que, na prática, não tem dois clientes iguais.

O que torna o Protheus tecnicamente distinto de qualquer outro ERP

Integrar IA ao SAP tem uma literatura enorme, comunidades ativas e um ecossistema global de parceiros certificados. O Protheus tem ADVPL. Essa linguagem proprietária da TOTVS governa desde a lógica de negócio até os pontos de extensão do sistema, e o seu comportamento surpreende quem chega de fora. Há o ExecAuto, mecanismo de automação de rotinas que trava silenciosamente sob carga ou quando a sequência de parâmetros está fora de ordem. Há APIs REST que, dependendo da versão e do patch instalado, retornam erros HTTP 422 por razões não documentadas na superfície: um campo de fornecedor com dois caracteres acima do limite, um produto cadastrado com custo R$ 0,00 tratado pelo sistema como cortesia, um encoding CP1252 que vira caracteres ilegíveis no momento em que o agente tenta gravar uma descrição com acento. Quem não passou por esses cenários em produção real não escreve o tratamento correto na primeira tentativa. Em produção, a primeira tentativa é exatamente quando o custo aparece. Há ainda o modelo de permissões: cada rotina do Protheus exige perfis de acesso específicos para o usuário de serviço que o agente utiliza. Um perfil incorreto não gera erro claro. Gera um processo que inicia, não completa e deixa registros inconsistentes no banco de dados.

Por que consultorias nascidas em Azure não ocupam esse terreno

As grandes consultorias globais e as boutiques de transformação digital que cresceram sobre Azure, AWS ou Google Cloud construíram excelência em SAP, Salesforce, Dynamics 365. Seus engenheiros têm certificações, seus templates têm casos de uso documentados em centenas de implantações internacionais. Nenhum desse capital técnico se traduz para o Protheus. O mercado de TOTVS foi historicamente servido por uma rede de parceiros regionais focados em implantação, configuração e suporte operacional, sem desenvolvimento paralelo de competência em automação inteligente. Quando a onda de IA chegou, esse vácuo ficou visível: de um lado, grandes consultorias com o capital técnico errado; do outro, parceiros TOTVS sem capital de agentes. O meio do mapa ficou vazio. Isso é uma consequência estrutural do mercado: profundidade em Protheus só existe em quem cresceu dentro dele. Você não a desenvolve servindo clientes em Frankfurt e Chicago.

O mercado de IA TOTVS não tem um líder global estabelecido. Tem um espaço aberto que será preenchido por quem souber falar os dois idiomas: orquestração de agentes e ADVPL.

O que acontece quando IA encontra o Protheus sem quem conheça o sistema

Segundo a McKinsey, a maioria dos projetos de inteligência artificial corporativa não chega à produção: ficam em piloto, em prova de conceito, em apresentações para o comitê executivo. A Deloitte reporta o mesmo padrão em relatórios sobre adoção de IA em empresas. No Protheus, o problema se aprofunda: o piloto funciona porque a equipe de implementação controla o ambiente, prepara os dados de teste e contorna manualmente os casos de borda. Quando o agente vai a produção e encontra um pedido de compra com fornecedor novo, um produto sem cadastro completo ou uma rotina que exige usuário de serviço com permissão específica, o sistema para. Com um timeout, com um registro inconsistente no banco, ou com um processo ERP que fica em aberto e exige intervenção manual para ser fechado. Esses cenários não aparecem na demo. Aparecem no segundo mês de operação, quando a equipe interna foi deslocada para outro projeto e o fornecedor já recebeu o pagamento final do contrato.

Como agentes de IA realmente funcionam dentro do Protheus

A diferença entre um agente que funciona e um que trava no Protheus está nos detalhes de integração que só existem em quem já operou o sistema em produção. Validar o cadastro do fornecedor antes de submeter o pedido. Tratar o retorno HTTP 422 com o contexto do campo específico que falhou, não apenas com o código de status. Usar usuários de serviço com as permissões mapeadas rotina a rotina. Garantir encoding correto antes de qualquer gravação em campo de texto. Em um projeto de automação de compras em mineração, esses cuidados resultaram em 30 minutos por pedido reduzidos para 5 minutos, 6 vezes mais capacidade de processamento para a mesma equipe e zero erros de integração no ERP ao longo de toda a operação. O diferencial operacional veio do conhecimento de onde o Protheus quebra sob carga e com os dados de produção reais, que são imperfeitos por natureza.

Trinta minutos por pedido virou cinco. A mesma equipe passou a processar seis vezes mais volume. Zero erros de integração no ERP. O diferencial foi saber onde o Protheus quebra antes que ele quebrasse em produção.

Por que a arquitetura do agente precisa ser projetada para esse contexto

Ter um engenheiro que conhece Protheus e outro que conhece LLMs não resolve o problema de arquitetura. O agente precisa de uma camada de orquestração que lide com falhas parciais: o que acontece quando o pedido é criado no ERP mas a aprovação não retorna? Como o agente distingue um timeout de rede de uma falha de negócio? Quando ele precisa escalar para um humano e quando pode tentar novamente com segurança? Essas perguntas exigem uma infraestrutura projetada para o contexto do Protheus, construída com tratamento de estado persistente, filas de retry com backoff configurável e logs de auditoria que o time de TI da empresa consegue ler sem treinamento adicional. A nossa fábrica de agentes foi desenvolvida para exatamente esse tipo de integração. A rastreabilidade do que o agente fez dentro do ERP é tão importante quanto o que ele fez corretamente.

O que isso significa para quem decide sobre IA hoje

Se a sua operação roda Protheus, a pergunta certa ao avaliar um projeto de IA não é qual modelo de linguagem será utilizado. É: essa equipe já colocou agente em produção dentro do Protheus? Já tratou erro 422 de ExecAuto em ambiente real? Já operou com encoding CP1252 em campo de texto sob carga de produção? Se a resposta for não, o que está sendo vendido é um piloto com alta probabilidade de ficar onde a maioria dos pilotos fica. O mid-market brasileiro tem uma infraestrutura de negócio específica, desenvolvida por uma empresa brasileira ao longo de três décadas, com histórico de customizações que tornam cada instalação única. A IA que vai transformar essas operações precisa ter nascido dentro desse contexto. Chegar de fora com um toolkit validado em outro mercado e tentar adaptar depois é o caminho mais caro para o resultado mais incerto.

Para o mid-market brasileiro, IA sem Protheus é uma solução projetada para um mercado que não existe aqui.

Quer ler a sua operação a fundo?