Joule deixou de responder e passou a executar. Quem assina o que ele decide?

O SAP Joule nasceu como assistente conversacional. Uma pergunta em linguagem natural, uma resposta dentro do contexto do sistema, um caminho mais curto até uma tela ou um dado que, de outra forma, levaria minutos de navegação. Essa era a promessa de 2023: menos fricção para encontrar o que já existia dentro do SAP.

O Joule de agora não é mais isso, ou pelo menos não é só isso. A SAP está movendo a plataforma de um copiloto que responde para uma rede de agentes que executam. O número exato de agentes hoje não está consolidado em fonte oficial primária, mas o movimento em si é público: de um punhado de agentes especializados anunciados no fim de 2025 para um número bem maior divulgado ao longo de 2026, cobrindo fluxos como análise de propostas em procurement. O Joule Studio, lançado em versão mais madura na Sapphire de 2026, entrega a um usuário de negócio a capacidade de descrever uma automação em linguagem natural e receber um agente pronto para rodar. Não é mais preciso pedir para o Joule explicar um processo. É possível pedir para ele executar o processo.

Essa distinção parece técnica. Não é. É uma mudança de responsabilidade.

Um copiloto que responde erra de um jeito: entrega uma informação errada, e alguém, no meio do caminho, decide se usa aquilo ou não. Um agente que executa erra de outro jeito: a ação já aconteceu antes de qualquer pessoa validar. A pergunta que interessa para quem opera uma apuração fiscal em SAP não é "o Joule está certo com que frequência". É: quando ele estiver errado, em que ponto da cadeia alguém teria percebido, e alguém teria conseguido explicar depois por que aquilo foi feito daquele jeito.

O ponto cego que ninguém está discutendo em português

O que existe em português sobre SAP Joule cabe em três categorias: post de evento, introdução de blog de consultoria SAP genérica e uma nota sobre GRC. Nenhum desse material liga Joule à operação fiscal brasileira. Nenhum menciona SPED, apuração, obrigação acessória ou o tipo de regra que muda por CNPJ, por regime, por estado. O Joule aparece descrito como produtividade de escritório com sotaque SAP: fechamento mais rápido, faturas processadas mais rápido, RH mais rápido. Isso não é falso. É incompleto para quem responde pelo fiscal.

Fiscal brasileiro não é um processo de negócio genérico que só precisa de velocidade. É um processo em que a regra muda por competência, por operação, por norma editada no meio do trimestre, e em que a consequência de um erro não aparece no mesmo dia. Aparece na malha, na autuação, na divergência entre o que o sistema calculou e o que a legislação de fato exigia. Um agente de IA que executa dentro dessa realidade sem estar ancorado nela não está reduzindo risco. Está automatizando a velocidade com que um erro se propaga antes de alguém perceber que era erro.

Cinco cenários que quem opera SPED reconhece

Isso deixa de ser abstrato ao olhar para o que acontece toda semana numa apuração fiscal em SAP. Nenhum cenário abaixo é cliente real da DFSpro, são situações típicas de operação, do tipo que aparece em qualquer diagnóstico fiscal SAP de porte médio para cima.

Divergência entre o apurado e o escriturado: o cálculo bate no módulo fiscal, mas o valor que chega ao SPED não é o mesmo, porque uma regra de agregação mudou no meio do caminho. Um agente que executa poderia escolher qual dos dois valores prevalece e seguir sozinho, sem que ninguém tenha decidido antes qual fonte vale em caso de conflito.

Reclassificação de item por regra de UF: um produto muda de tratamento tributário ao cruzar fronteira estadual, e a regra de cálculo depende de tabela que nem sempre reflete a última alíquota publicada. Um agente executando essa reclassificação sem validar a tabela contra a norma vigente não erra mais devagar. Erra na mesma velocidade que acertaria, sem diferença visível até a malha acusar.

Exceção de produto que existe só no dado mestre: um item cadastrado de um jeito que só faz sentido por uma negociação antiga ou uma migração mal fechada. Regra automática trata exceção como erro de dado. Um agente que executa sem saber que aquela exceção é intencional corrige, rápido, algo que nunca deveria ser corrigido.

Ajuste manual do mês passado que ninguém documentou: alguém interveio para fechar o mês sem registrar o motivo em lugar nenhum além da própria memória. Um agente aprende o padrão final do sistema, não o motivo do ajuste, e repete esse padrão na próxima competência sem saber que era exceção.

Fechamento em que o número bate mas a memória de cálculo não se sustenta em auditoria: um agente executando etapas do fechamento sem deixar rastro equivalente ao de um analista não reduz esse risco. Só torna mais difícil percebê-lo, porque o número final continua parecendo confiável.

O que muda de fato quando o Joule executa

Três coisas mudam quando se sai do modo "Joule responde" para o modo "Joule age".

A primeira é o momento da validação. No modo copiloto, a validação acontece antes da ação: alguém lê a resposta, decide se usa. No modo agente, a validação precisa acontecer depois, sobre uma ação já tomada, ou antes, na forma de regra que restringe o que o agente pode fazer sozinho. Não existe meio-termo confortável. Ou a empresa define, com antecedência, o perímetro exato em que um agente pode agir sem supervisão humana em cada etapa, ou está delegando esse perímetro, por omissão, ao próprio agente.

A segunda é o que conta como contexto suficiente. Um copiloto pode errar uma resposta e o custo é o tempo de quem vai checar. Um agente que decide sozinho precisa de contexto de negócio correto no momento da decisão, não depois. Isso inclui a regra fiscal vigente, a exceção do CNPJ específico, o histórico de divergência daquela operação. Sem esse contexto disponível e correto dentro do SAP, dar ao Joule autonomia de execução em fluxo fiscal não é acelerar a operação. É apostar que o contexto ausente não vai importar desta vez.

A terceira é a rastreabilidade da decisão em si, não só do dado. Auditoria fiscal sempre soube perguntar de onde veio um número. A pergunta nova é de onde veio a decisão de agir daquele jeito, com aquele agente, naquele momento, com que regra ativa. Se a resposta for "o agente decidiu", sem trilha de qual contexto ele usou e qual regra aplicou, a decisão fica sem dono no momento em que mais precisa de um.

O que uma auditoria vai pedir da trilha do agente

Uma auditoria fiscal já sabe perguntar de onde veio um número: qual lançamento, qual regra, qual competência. O que muda com um agente executando é a pergunta seguinte, que hoje quase nenhuma trilha de sistema responde: qual contexto o agente tinha disponível no momento em que agiu, e qual alternativa ele descartou.

Log tradicional registra o que mudou, não por que um agente escolheu mudar daquele jeito com base em qual porção de contexto. Essa lacuna separa uma automação defensável de uma que só parece defensável até ser questionada. Antes de dar a um agente Joule autonomia de execução em etapa fiscal, vale perguntar: se essa ação for contestada daqui a dois anos, existe registro suficiente para reconstruir o raciocínio, ou só o resultado final vai sobrar? Um agente que executa sem essa trilha equivalente reduz o padrão de prova que a operação já tinha antes da automação entrar.

Onde a autonomia de agente é território genuinamente útil, e onde não é

Nem toda automação fiscal se beneficia igualmente da virada para agente. Faz sentido dar mais autonomia de execução onde a regra é estável, o dado de entrada é limpo e a consequência de um erro é reversível em prazo curto: triagem de exceção repetitiva, conciliação de lançamento já validado por regra fixa, geração de relatório interno que ainda passa por revisão antes de virar posição oficial.

Faz menos sentido, e exige controle explícito, onde a regra muda com frequência, o dado de entrada tem histórico de inconsistência, ou a ação alimenta diretamente uma obrigação acessória que vai para fora da empresa. Ali, o valor do Joule não está em decidir sozinho. Está em reduzir o tempo entre o sistema perceber um desvio e alguém com autoridade fiscal entender o que aconteceu e agir. Essa distinção não é sobre desconfiar de IA. É sobre desenhar, antes de ligar o agente, qual fatia do processo ele pode assumir sozinho e qual continua exigindo um humano no meio.

CBS/IBS, o agravante específico que a Reforma Tributária cria

A Reforma Tributária troca a base de regras do modelo atual em etapas, ao longo de anos de transição. IA aprende padrão a partir de histórico, e um período de transição de regra é exatamente o cenário em que padrão histórico deixa de ser guia confiável: o comportamento correto de ontem pode já não ser o correto amanhã, mesmo com a mesma operação e o mesmo produto.

Um agente Joule configurado sobre o comportamento histórico do sistema pode aplicar, com toda confiança, uma lógica que era correta no regime anterior e deixou de ser correta na fase de transição vigente naquele mês. O risco não está em o agente não saber da Reforma. Está em aplicar, de forma consistente e rápida, uma regra que já mudou sem que a mudança tenha chegado ao contexto que ele consulta.

Qualquer piloto de automação fiscal com Joule durante a convivência com CBS/IBS precisa validar se a regra que o agente vai aplicar reflete a fase de transição vigente naquela competência, não a fase vigente quando o agente foi configurado. Sem isso, automatizar durante a transição não acelera a adequação. Acelera a chance de aplicar regra vencida com a mesma confiança de uma regra vigente.

O que cada papel precisa perguntar antes de autorizar execução automática

A pergunta muda conforme quem está decidindo, porque cada papel enxerga uma parte diferente do risco.

1. CFO: qual é a exposição financeira de um erro de execução automática que só seja percebido depois do fechamento publicado, e se essa exposição é menor ou maior do que a exposição já existente com o processo manual atual.

2. Diretor Fiscal: em qual fluxo específico a automação está autorizada a agir sozinha, e em qual fluxo ela só pode sugerir, deixando a decisão com uma pessoa. Sem essa fronteira escrita, a fronteira acaba sendo decidida pelo próprio agente, por omissão.

3. CIO e Gerente SAP: se o contexto de negócio que o agente consulta antes de agir está atualizado no mesmo ritmo da regra fiscal real, e se existe forma de auditar, depois do fato, qual contexto o agente de fato usou naquela execução específica.

4. Compliance: se a trilha deixada por uma execução automática satisfaz o mesmo padrão de prova que já se exige de uma decisão fiscal tomada por pessoa, ou se essa trilha é mais fraca só porque quem executou foi um agente de IA em vez de um analista.

Nenhuma dessas perguntas tem resposta padrão. Cada uma delas só tem resposta boa depois que a base fiscal estiver desenhada para respondê-las, o que é trabalho de governança, não de ativação de produto.

O que perguntar antes de qualquer piloto

Antes de ligar um agente Joule sobre rotina fiscal, quatro critérios verificáveis, não um checklist genérico de adoção de IA: existe hoje, escrito, o perímetro exato do que esse agente pode executar sozinho? O contexto que ele consulta está atualizado no mesmo ritmo que a realidade fiscal muda? Se essa execução for contestada em auditoria, existe trilha suficiente para reconstruir o raciocínio, não só o resultado? Esse fluxo atravessa algum período de transição de regra, como CBS/IBS, em que o padrão histórico pode estar desatualizado?

Se a resposta a qualquer um dos quatro for não ou não sei, o problema não é o Joule. É que a base ainda não está governada o suficiente para sustentar execução autônoma naquele ponto. A decisão sobre tese tributária, crédito ou enquadramento continua sendo do cliente, sempre. O papel de quem desenha o ambiente é garantir que, quando a IA executar algo dentro do SAP, exista contexto correto, perímetro definido e trilha suficiente para que essa decisão, se questionada depois, continue defensável.

A virada de copiloto para agente já aconteceu do lado da SAP. O trabalho de decidir onde ela entra, com que controle, em qual fluxo fiscal, ainda não tem dono declarado na maioria das operações brasileiras. É exatamente aí que a conversa deveria começar.

O Diagnóstico Fiscal Estruturado é o ponto de partida dessa conversa: mapeia onde a base fiscal já sustenta execução autônoma e onde a governança ainda precisa de dono nomeado antes de qualquer piloto com IA.