Nexus ZDT -- Plataforma de Automação Inteligente para TOTVS Protheus

Nexus ZDT é uma plataforma SaaS B2B que automatiza rotinas operacionais e adiciona inteligência ativa ao TOTVS Protheus. Projetei e implementei o produto end-to-end, da arquitetura ao deploy em produção. Mais de 10 empresas clientes rodando, com resultados mensuráveis desde os primeiros meses.

O problema

O TOTVS Protheus é o ERP mais usado no Brasil corporativo. É robusto, mas exige um volume absurdo de operação manual.

Equipes de RH passam dias todo mês executando rotinas repetitivas: leitura de ponto, fechamento de folha, processamento de admissões e demissões. Processos que ninguém questiona porque sempre foram feitos assim. O dado que motivou o produto: em média, essas equipes gastam mais de 540 horas por mês em trabalho que pode ser automatizado.

O segundo problema é ainda mais sério: a operação é reativa. Problemas críticos como férias vencidas, excesso de horas extras e inconformidades de ponto só aparecem quando já geraram custo, risco jurídico ou multa. O ERP tem todos os dados para detectar esses problemas antes que aconteçam. O que falta é a camada de inteligência para extrair esse sinal e agir com antecedência.

A visão de produto

Transformar a operação no Protheus de reativa para preditiva.

Não apenas automatizar o que já existe, mas adicionar uma camada de inteligência que monitora, alerta e age antes que problemas aconteçam. O produto foi pensado em três pilares que trabalham juntos:

Agentes de IA e RPA executam as rotinas operacionais de forma autônoma. Leitura e apontamento de ponto, fechamento de folha, processamento em lote de admissões e demissões. Processos que antes levavam horas rodam sem intervenção humana, sem erro, 24/7.

Módulo de Insights transforma dados brutos do Protheus em dashboards acionáveis. Quem vence o período de experiência este mês, quais colaboradores têm excesso de horas extras, qual o custo real por setor. Informação que antes exigia relatórios manuais, disponível em tempo real.

IA Ativa monitora continuamente o banco de dados do cliente e dispara alertas proativos por email antes que situações críticas virem multas ou passivos trabalhistas. Férias vencendo, batidas incompletas, inconformidades de compliance, o sistema avisa antes, não depois.

Os problemas técnicos que ninguém vê no produto final

Multi-tenancy com Protheus

Cada cliente tem sua própria instância do TOTVS Protheus, com configuração de implantação diferente, banco de dados diferente (Oracle, SQL Server ou PostgreSQL) e regras de negócio que variam por módulo e por histórico de customização.

Isso significa que um agente que funciona perfeitamente para o cliente A pode falhar silenciosamente para o cliente B porque uma tabela tem nome diferente, um campo tem máscara diferente ou uma rotina foi customizada na implantação. O sistema precisava ser robusto o suficiente para lidar com essa variação sem exigir configuração manual por cliente.

A solução foi construir uma camada de abstração de contexto por tenant: cada cliente tem seu perfil de Protheus registrado na plataforma, incluindo banco, versão, módulos ativos e particularidades conhecidas. Os agentes consultam esse perfil antes de executar qualquer operação e adaptam o comportamento de acordo.

Isolamento de banco por cliente

A decisão arquitetural mais crítica do projeto: a plataforma nunca acessa o banco de dados do cliente diretamente.

Toda comunicação passa por um hub proprietário instalado no ambiente do cliente, com autenticação dedicada e comunicação criptografada. A plataforma central nunca tem acesso direto ao banco de dados corporativo. O hub expõe apenas os endpoints necessários, com controle granular do que pode ser lido e do que pode ser escrito.

Essa decisão foi determinante para o produto existir. Empresas com políticas rígidas de segurança de dados não permitem que sistemas externos acessem diretamente suas bases corporativas. Sem essa garantia arquitetural, metade dos contratos não teria acontecido. Segurança como argumento de vendas é tão importante quanto segurança como prática de engenharia.

O custo dessa decisão foi complexidade adicional de deploy e manutenção do hub. O benefício foi a capacidade de fechar contratos que de outra forma seriam inviáveis.

Controle de acesso em produto B2B

Produto B2B com múltiplos clientes exige controle de acesso granular. Não apenas autenticação, mas permissões específicas por perfil, por funcionalidade e por cliente.

O sistema usa RBAC (Role-Based Access Control) com políticas por perfil, autenticação JWT com refresh token rotativo e logs auditáveis de todas as operações. Esse nível de controle não é opcional em contexto corporativo: é pré-requisito para conformidade com LGPD e para passar por auditorias internas dos clientes maiores.

A implementação de RBAC em multi-tenant tem uma complexidade específica: um usuário pode ter permissões diferentes em clientes diferentes. O modelo de dados precisou acomodar essa dimensão sem tornar as consultas inviáveis.

A fronteira entre agente e RPA

Uma das decisões de design mais importantes foi definir o que cada camada faz.

RPA executa sequências determinísticas: navegar por telas do Protheus, preencher campos, confirmar operações. É previsível, auditável e não depende de modelo de linguagem. Para rotinas com fluxo fixo e dados estruturados, RPA é mais confiável e mais barato do que chamar um LLM.

Os agentes de IA entram quando há variabilidade: quando a pergunta é ambígua, quando a regra de negócio depende de contexto, quando é preciso interpretar dado antes de agir. O agente decide o que fazer; o RPA executa.

Essa divisão não é óbvia para quem vem só do mundo de LLMs. O instinto é colocar IA em tudo. Na prática, colocar LLM onde RPA é suficiente aumenta custo, aumenta latência e adiciona pontos de falha não determinísticos em operações que não precisavam deles.

Expansão além do RH

O produto nasceu focado em RH porque é onde o impacto é mais imediato e mensurável. Com a infraestrutura estabelecida, expandimos para outros módulos críticos.

O Monitor Fiscal cruza dados de NF-e do banco do cliente com registros da SEFAZ e identifica divergências antes do Fisco. É o mesmo padrão de monitoramento ativo do RH aplicado a outro domínio com regras diferentes.

O Monitor de Logs audita todas as operações no ERP, rastreia ações de usuários e identifica gargalos de performance. Útil tanto para conformidade interna quanto para diagnóstico de problemas.

A expansão foi possível porque a arquitetura foi desenhada para isso. O hub, o sistema de alertas, o pipeline de monitoramento e o controle de acesso são infraestrutura compartilhada. Adicionar um novo módulo é construir a lógica de negócio específica em cima de uma base que já existe.

Stack e decisões de infraestrutura

Backend em Python com FastAPI, pela performance assíncrona e integração natural com as bibliotecas de IA usadas no projeto.

Frontend em React com atualizações em tempo real nos dashboards de monitoramento.

Banco de dados em PostgreSQL para os dados da plataforma. Cada cliente tem seu próprio banco, com schema isolado, para garantir que dados de clientes diferentes nunca se misturem.

Deploy em cluster Docker Swarm. A escolha por Swarm em vez de Kubernetes foi deliberada: o volume de clientes e a complexidade das operações não justificavam a overhead operacional do Kubernetes nessa fase. Swarm entrega alta disponibilidade e escalabilidade horizontal com configuração muito mais simples para uma equipe pequena gerenciando múltiplos ambientes.

Stack completa: Python, FastAPI, React, PostgreSQL, Docker Swarm, LangChain, OpenAI, JWT, RBAC.

Resultados

Com mais de 10 empresas clientes em produção:

Mais de 540 horas de processos operacionais economizadas por mês por cliente
96% de redução no tempo de execução das rotinas automatizadas
Zero férias vencidas nos clientes após 90 dias de uso da IA Ativa
Monitoramento 24/7 de compliance trabalhista e fiscal
Implementação plug-and-play em 7 a 10 dias úteis, sem customização no Protheus e sem sobrecarga para o TI do cliente

O que aprendi construindo esse produto

Produto B2B para mercado corporativo tem dinâmicas muito diferentes de projeto interno. O cliente não compra tecnologia, compra redução de risco e liberação de tempo. Cada funcionalidade precisou ser justificada em termos de ROI mensurável, não de elegância técnica.

A decisão de nunca acessar o banco do cliente diretamente não surgiu de uma análise de segurança formal. Surgiu de uma conversa de vendas onde o cliente perguntou "vocês acessam meu banco diretamente?" com uma cara que deixou claro que a resposta "sim" encerraria a conversa. Às vezes a restrição arquitetural mais importante vem do contexto de negócio, não de um requisito técnico documentado.

A fronteira entre RPA e agente de IA foi refinada ao longo do tempo. A versão inicial tinha muito LLM onde RPA era suficiente. O custo por operação era alto e a confiabilidade era menor do que precisava. Deslocar para RPA nas etapas determinísticas e reservar o LLM para decisões com variabilidade foi um dos ajustes mais impactantes na vida do produto.

E o maior aprendizado: implementação não é o fim do projeto. O que diferencia produto de POC é o que acontece depois do go-live, monitoramento, suporte, iteração com feedback real de usuários reais. O Nexus ZDT é um produto vivo. O sistema que está em produção hoje é diferente do sistema que foi para o primeiro cliente, e vai continuar evoluindo.