Controllership Copilot

Contexto

Em empresas com ERP SAP de grande porte, a controladoria vive um paradoxo: o ERP inteiro já está replicado no data lake e, ainda assim, cada pergunta de fechamento vira um chamado. Quem conhece a contabilidade não escreve SQL; quem escreve SQL não conhece a contabilidade. No meio, um modelo de dados com mais de mil tabelas, nomes de coluna de quatro letras em alemão e regras que não estão escritas em lugar nenhum: o sinal do valor mora em outra coluna, o estorno se identifica por um campo de significado contraintuitivo e cada documento pode ter várias versões no lake.

Desafio

• Um modelo de dados que ninguém lê inteiro: tabelas técnicas e regras de negócio na cabeça de poucas pessoas.
• Custo por pergunta: a tabela de itens contábeis tem terabytes e é particionada pela chegada no lake, não pela data contábil. Uma pergunta mal escrita varre centenas de gigabytes.
• Erro que ninguém percebe: um número errado no fechamento não quebra nada, ele circula.
• IA em processo crítico: alucinação, consulta que escreve no banco, prompt injection e, o mais caro, resposta plausível sem base na regra contábil.
• Auditoria: quem perguntou, qual modelo respondeu, com que parâmetros, por que aquele SQL e se o arquivo entregue é o mesmo que saiu do sistema.

Solução

Um copiloto que transforma a pergunta em SQL, mas trata o SQL como proposta que precisa passar por controles antes de rodar. O modelo recebe um contexto montado por RAG sobre o dicionário de dados, o plano de contas e as regras de negócio escritas em português. A consulta passa por um guardrail que só aceita leitura, por uma estimativa de custo antes da execução e por uma revisão humana que mostra tabelas, colunas e contas envolvidas. Se a estimativa recusa, o agente corrige lendo o erro, mas só antes da aprovação: erro depois do "pode rodar" volta como nova proposta, nunca como reexecução automática. Consultas aprovadas viram rotinas recorrentes exportáveis para orquestração.

Arquitetura

• 01Ingestão: ERP replicado para o lake pelo SAP Datasphere, em captura de mudanças, por conexão privada e usuário técnico só de extração
• 02Lake em camadas: zona bruta fiel ao ERP, zona refinada por domínio e zona semântica com dicionário, plano de contas e regras
• 03Agente: RAG sobre o dicionário, geração determinística com raciocínio declarado, guardrail de leitura, estimativa de custo e autocorreção limitada
• 04Execução com teto de bytes, tempo máximo, limite de linhas e rótulo de custo por área e usuário
• 05Entrega: exportação do resultado, painel de caixa conciliado contra o extrato e rotinas recorrentes em n8n, inativas por padrão e sem credencial no arquivo
• 06Observabilidade: logs, métricas e rastros correlacionados pelo identificador da interação

Governança e segurança

• Somente leitura, por construção: qualquer comando de escrita é recusado antes de chegar ao banco, inclusive nas rotinas recorrentes
• Custo é controle: estimativa obrigatória, aceite explícito acima do teto e um teto absoluto que nem o aceite libera
• A decisão é humana: o agente propõe; quem aprova vê as tabelas, colunas e contas que a consulta usa
• Trilha encadeada por hash: cada chamada ao modelo, cada SQL com o raciocínio, cada execução com o custo e cada arquivo com seu hash
• Identidade, não senha: login corporativo, conta de serviço de leitura e segredos em cofre gerenciado
• Suíte de regressão dos guardrails e testes adversariais contra injeção de instrução a cada mudança de prompt ou modelo

Estado atual

• Em avaliação
• As regras de GRC do ERP (segregação de funções, perfis, aprovações) continuam no próprio ERP; o copiloto opera só em leitura
• A demonstração abaixo usa dados e nomes de lake fictícios; as tabelas e campos SAP são os reais