Você sabe nomear o dono de cada regra tributária configurada no seu SAP?

A pergunta que chega antes de qualquer demonstração

Quem trabalha com SAP dentro de operação fiscal brasileira, hoje, já ouviu falar do Joule. CIO comentou, um post no LinkedIn circulou, um consultor mencionou numa reunião. A pergunta que sobra depois disso quase nunca é "o que o Joule faz". É "vale a pena para a minha operação, agora".

Essa pergunta parece simples e não é. Ela mistura três perguntas diferentes que raramente são separadas: o Joule entrega valor técnico real (entrega, o copiloto é capacidade estabelecida do ecossistema SAP Business AI, isso não está em disputa), a minha operação está pronta para extrair esse valor sem risco novo, e o momento certo de avaliar isso é agora ou daqui a um tempo. As três respostas não são a mesma coisa, e tratar como se fossem é o erro mais comum que vemos quando uma empresa decide "testar IA no SAP" sem examinar essas três perguntas em separado.

Por que essa pergunta não tem resposta genérica

Um copiloto de IA generativa dentro do SAP responde com base no que consegue enxergar: dado mestre, regra de negócio configurada, contexto semântico da estrutura do sistema. Se esse fundamento estiver sólido, o Joule tende a acelerar acesso à informação e reduzir fricção em tarefas de consulta e navegação. Se esse fundamento tiver lacuna, o Joule não cria a lacuna, mas responde com base nela, e responde rápido, com uma confiança aparente que a lacuna subjacente não sustenta.

Isso significa que a resposta para "vale a pena" depende menos do Joule e mais da operação que vai recebê-lo. Duas empresas com o mesmo módulo SAP, na mesma versão, podem ter respostas opostas para a mesma pergunta, porque a condição real da base fiscal por baixo é diferente.

Em que situação faz sentido avaliar agora

Existem sinais concretos, verificáveis internamente, que indicam que vale a pena abrir uma avaliação real do Joule dentro da operação fiscal, e não só acompanhar o assunto de longe. São quatro.

1. Plataforma: o ambiente já está em S/4HANA Cloud, ou a migração está em andamento com data definida. O Joule opera sobre a arquitetura em nuvem do ecossistema SAP. Se a operação ainda está em ECC sem plano de migração, a pergunta sobre Joule é prematura, e o que precisa de atenção primeiro é a decisão de migração.

2. Dono da regra: a empresa já consegue nomear, sem hesitar, quem é o dono de cada regra fiscal configurada no sistema. Se a pergunta "quem decidiu essa regra de tributação e onde ela está documentada" gera silêncio ou resposta incerta, a base de governança que sustentaria uma automação assistida por IA ainda não existe, e o problema não desaparece por causa do Joule.

3. Caso de uso em uma frase: não "queremos usar IA no fiscal", mas algo como "queremos reduzir o tempo que o time gasta localizando o histórico de uma divergência de alíquota específica". Avaliação de tecnologia sem caso de uso concreto tende a virar projeto de exploração sem critério de sucesso.

4. Quem valida a resposta: existe capacidade interna, ou de um parceiro, para validar cada resposta relevante antes de qualquer decisão ser tomada com base nela. Se a resposta do Joule sobre um tema fiscal só vai ser usada depois de checada por alguém que entende a regra, o risco de erro cai muito. Se a expectativa é usar a resposta direto, sem essa camada, o risco sobe na mesma proporção.

Em que situação ainda não faz sentido avaliar

O inverso também precisa ser dito com a mesma clareza, porque a pressão do mercado empurra na direção contrária. Também são quatro sinais, e basta um deles.

1. Dado mestre inconsistente: cadastro de material, CFOP e classificação fiscal com divergência entre filiais, regra de exception configurada "provisoriamente" há dois anos. Um copiloto de IA não resolve inconsistência de dado: ele navega por cima dela e entrega resposta com a mesma inconsistência, só que mais rápido.

2. Planilha paralela no fechamento: o fechamento fiscal ainda depende de planilha para bater com o que o SAP mostra. Se a fonte de verdade real da operação é uma planilha e não o sistema, qualquer IA aplicada ao sistema responde com base numa fonte que a própria empresa não considera confiável o suficiente para fechar sozinha.

3. Ninguém sabe o que acontece no erro: ninguém no time consegue explicar, hoje, o que aconteceria se uma automação executasse uma ação errada em produção fiscal. Se essa pergunta nunca foi feita, falta a camada mínima de governança, que é quem aprova, quem reverte e quem responde.

4. Motivação só concorrencial: "o concorrente já está usando IA no SAP" é um dado relevante, mas não é critério de decisão. Avaliar tecnologia por pressão de mercado, sem pergunta interna clara, tende a gerar um piloto que não mede nada e não decide nada.

Perguntas para fazer internamente antes de qualquer avaliação

Quatro perguntas, nesta ordem, respondidas por escrito, ajudam a substituir intuição por critério:

1. Primeira: qual é a decisão específica que hoje demora mais do que deveria por falta de acesso rápido à informação dentro do SAP.

2. Segunda: essa demora vem de falta de acesso a dado, ou de falta de confiança no dado que já existe.

3. Terceira: se a resposta viesse mais rápido hoje, sem mudar mais nada, quem validaria essa resposta antes de agir sobre ela.

4. Quarta: o que muda de fato se essa avaliação esperar mais dois trimestres em vez de começar agora.

A última pergunta é a mais reveladora. Em boa parte dos casos que discutimos, a resposta honesta é "nada crítico muda", o que indica que a pressa vem de hype, não de necessidade. Em outros casos, a resposta é "o volume de transação vai crescer e o time não vai escalar junto", o que é um motivo real para não esperar.

Sinais que indicam que o ambiente ainda não está pronto

Além dos itens já listados, há sinais indiretos que merecem atenção porque costumam passar despercebidos: Rotatividade recente na equipe fiscal ou de TI que administra o SAP, sem documentação atualizada da regra de configuração vigente. Migração para S/4HANA concluída tecnicamente, mas sem validação completa do primeiro ciclo de fechamento pós go-live. Reforma Tributária (CBS e IBS) em fase de configuração ainda incompleta, com regra provisória sendo ajustada em paralelo. Qualquer um desses três sinais, isolado, já é motivo para adiar a avaliação até que a base estabilize, porque avaliar uma camada de IA sobre um fundamento em movimento tende a produzir resultado inconclusivo, não uma resposta clara sobre o valor real da tecnologia.

Como decidir sem depender de fé na tecnologia

A forma mais segura de decidir não é ler mais material sobre o Joule. É aplicar um teste simples e verificável: escolher uma única pergunta fiscal recorrente da operação, mapear com precisão de onde vem a resposta hoje (pessoa, planilha, transação do SAP), e verificar se essa fonte tem dado confiável e regra documentada suficiente para que uma resposta automática sobre ela seja, de fato, defensável. Se a resposta a esse teste for sim, a avaliação do Joule tem fundamento real para começar. Se for não, o trabalho que precisa começar primeiro não é sobre IA. É sobre a governança da base que qualquer IA, hoje ou no futuro, vai depender para responder com segurança.

O que muda conforme o tamanho e a complexidade da operação

O critério de decisão é o mesmo para qualquer porte, mas o peso de cada sinal muda conforme a complexidade da operação.

Numa operação com um único CNPJ, regime tributário estável e volume de transação moderado, a lacuna de governança costuma ser mais fácil de fechar antes de avaliar o Joule, porque há menos variável para mapear. Numa operação multi-CNPJ, com regime diferente por unidade, histórico de incentivo fiscal regional e integração com mais de um sistema satélite, a mesma pergunta ("quem é o dono de cada regra configurada") tende a exigir um trabalho bem mais extenso de levantamento antes de qualquer resposta confiável.

Isso não significa que operação grande deva esperar mais que operação pequena, e o inverso também não é verdade. Significa que o esforço de verificação prévia é proporcional à complexidade real, e que pular essa etapa custa mais caro exatamente onde a complexidade é maior, porque é ali que uma resposta errada do Joule tem mais chance de passar despercebida antes de virar decisão.

Como a conversa muda quando a resposta é não, por enquanto

Concluir que ainda não é a hora de avaliar o Joule não é uma resposta negativa em si. É uma resposta que aponta um trabalho concreto e imediatamente útil: qual parte da base fiscal precisa de atenção antes. Em geral esse trabalho se resume a três frentes, isoladas ou combinadas: fechar a lacuna de dado mestre identificada, documentar a regra de configuração que hoje só existe na memória de alguém, e reduzir a dependência de planilha paralela como fonte real de verdade do fechamento.

Nenhuma dessas três frentes depende do Joule para começar, e as três reduzem risco independentemente de qualquer decisão futura sobre IA. Esse é um ponto prático que vale registrar: o trabalho de preparar a base fiscal para uma eventual automação assistida por IA é o mesmo trabalho que reduz erro de fechamento e risco de autuação hoje, com ou sem Joule no horizonte. A avaliação da tecnologia deixa de ser urgente no momento em que se percebe que o ganho real está em outro lugar, mais próximo e mais sob controle da própria empresa.

O que isso significa na prática

Não existe resposta universal para "vale a pena". Existe uma resposta específica para a sua operação, e ela depende de uma verificação que a própria empresa consegue fazer antes de qualquer demonstração comercial ou piloto formal. A decisão de avaliar (ou não) o Joule agora é sempre da empresa. O papel da DFSpro, quando chamada, é ajudar a fazer essa verificação com método, não vender a conclusão de antemão.

Se a verificação descrita acima apontar que a base ainda não sustenta uma resposta automática, o trabalho seguinte é mapear onde a regra fiscal mora hoje no seu ambiente e quem responde por ela. É exatamente esse o recorte de um Diagnóstico Fiscal Estruturado.