Você definiu até onde o Joule pode agir sozinho? Se não, o agente decide por você.

Uma pergunta que a governança corporativa precisa fazer antes de qualquer entusiasmo

Toda tecnologia nova que chega ao ambiente SAP passa por um ciclo previsível de recepção: o entusiasmo do primeiro contato, a pergunta comercial sobre quanto ela substitui, e, meses depois, a constatação sobre o que de fato mudou e o que continuou exatamente igual. O SAP Joule não é exceção a esse ciclo, e a governança corporativa tem uma responsabilidade específica diante dele: separar, desde o início, o que a tecnologia resolve por si só do que continua dependendo de decisão e responsabilidade humana, para que a adoção não seja guiada por expectativa e sim por critério.

A separação que sustenta essa decisão tem três camadas, e confundir uma com a outra é o que produz proposta comercial cara e piloto sem critério. A primeira é o que o Joule entrega nativamente, sem qualquer trabalho adicional relevante. A segunda é o que ele entrega, mas depende de configuração e preparação prévia da base. A terceira é o que nenhuma versão futura do Joule deveria assumir sozinha, porque a responsabilidade ali é, por natureza, humana e nomeada.

O que o Joule resolve sozinho, sem ajuda de consultoria

É preciso começar por aqui, e começar com honestidade. Como copiloto de IA generativa integrado ao ecossistema SAP Business AI, o Joule entrega, de forma nativa, capacidade real de navegação e consulta em linguagem natural sobre dados já existentes no sistema. Perguntar por uma transação, localizar um relatório, resumir um conjunto de informações já disponíveis, essas são tarefas que o Joule executa por conta própria, sem que uma consultoria precise intervir para que a capacidade exista.

O mesmo vale para a integração já anunciada como disponibilidade geral (GA) com o Microsoft 365 Copilot: segundo fonte oficial (documentação da Microsoft e da SAP, lida em 2026-08-30), um usuário do Microsoft 365 já consegue acessar dados e ações do SAP via Copilot, e o inverso também, sem que isso dependa de um projeto de integração customizado. Essa é uma capacidade entregue pela própria SAP, pronta para uso dentro do escopo em que foi construída. Dizer isso com clareza importa por um motivo específico de credibilidade: uma consultoria que afirma ser necessária para tudo perde autoridade no momento em que o cliente descobre, na prática, que uma parte relevante do valor já vem pronta. A DFSpro não vende a ideia de que o Joule precisa de intervenção humana para tudo. Precisa para uma parte concreta, detalhada abaixo, e não para o conjunto inteiro do produto.

O que exige configuração antes de funcionar bem

Entre o que funciona sozinho e o que exige decisão humana permanente, existe uma faixa intermediária relevante: capacidade que o Joule tem, mas que só entrega valor real depois de um trabalho de preparação que não é trivial. São três exemplos concretos.

1. Arquitetura Clean Core: o Joule consulta a estrutura semântica do S/4HANA para responder com contexto de negócio. Se o core estiver carregado de customização não padrão, essa camada fica comprometida e a qualidade da resposta cai proporcionalmente. Não é falha do Joule: é dependência de arquitetura, que se resolve antes e com configuração, não com uso.

2. Qualidade do dado mestre: um copiloto responde com base no dado que existe. Cadastro de material duplicado, classificação fiscal divergente entre filiais e regra de exceção configurada sem documentação limitam o que o Joule entrega com segurança, mesmo com a capacidade técnica intacta. Aqui a consultoria tem papel concreto: mapear e corrigir essa base antes de qualquer expectativa de automação mais ampla.

3. Joule Studio: o ambiente para construir agentes personalizados descrevendo a automação em linguagem natural. Criar o agente é capacidade nativa. Definir com precisão o objetivo, o limite de atuação e o critério de sucesso, de forma que ele execute com segurança dentro de um processo fiscal específico, é configuração que exige conhecer a ferramenta e o processo. Ter acesso ao Studio não é ter a combinação de conhecimento técnico e fiscal que a configuração segura exige.

O que continua exigindo decisão humana com responsabilidade nomeada

Esta é a categoria que mais importa, porque nenhuma evolução futura do Joule deveria mudar essa resposta, independentemente de quantos agentes novos a SAP anunciar. A interpretação de uma regra fiscal, quando há ambiguidade real de enquadramento, é decisão que exige responsabilidade profissional nomeada: um contador, um responsável fiscal, um corpo jurídico, alguém que responde formalmente pela tese adotada perante o fisco. Nenhuma automação, por mais sofisticada, transfere essa responsabilidade. Ela pode acelerar o acesso à informação que sustenta a decisão, nunca substituir quem a assina.

A aprovação de uma ação que um agente Joule executaria de forma mais autônoma dentro de um processo fiscal também pertence a essa categoria. Executar uma ação dentro do sistema não é o mesmo que decidir se essa ação deveria acontecer. Quando a autonomia do agente aumenta, a pergunta que a governança precisa responder não muda de natureza, apenas de urgência: quem aprovou o perímetro dentro do qual esse agente pode agir sem intervenção humana em cada passo, e quem revisa esse perímetro periodicamente.

A responsabilidade pela trilha de auditoria também continua humana. Um sistema pode registrar com precisão o que aconteceu. Decidir se aquele registro sustenta uma posição perante uma fiscalização, é decisão de quem responde pela empresa, não do sistema que gerou o registro. E, de forma mais ampla, a decisão sobre onde vale a pena investir tempo e atenção em automação, dado o custo de oportunidade de não investir em outra prioridade da operação, é uma decisão de gestão. Tecnologia não prioriza a si mesma. Alguém, com visão do conjunto da operação, decide o que vale automatizar agora e o que pode esperar.

Por que essa separação evita dois erros opostos

Fazer essa separação com clareza evita dois erros que aparecem com frequência quando uma empresa avalia tecnologia nova.

O primeiro erro é superestimar a automação: tratar o Joule como se ele absorvesse responsabilidade que continua sendo humana por definição, seja legal, seja de governança corporativa. Esse erro tende a aparecer sob pressão de tempo, quando uma equipe busca reduzir esforço e confunde redução de esforço com transferência de responsabilidade. O segundo erro, menos discutido mas igualmente custoso, é subestimar a automação: contratar consultoria para tarefas que o Joule já resolve nativamente, por desconhecimento do que o produto entrega sem intervenção. Esse erro custa dinheiro e tempo sem necessidade, e uma consultoria que se preze evita ativamente esse desperdício, em vez de se beneficiar dele.

O que muda com o avanço dos Joule Agents, e o que não muda

A SAP tem ampliado o escopo de agentes do Joule com frequência. Segundo release oficial da própria SAP (lido em 2026-08-30, resumo de busca, comunicado não lido por completo), o número de soluções e agentes ligados ao Joule cresceu de forma relevante entre outubro de 2025 e o primeiro trimestre de 2026. Há também, segundo fonte de mercado (ERP Today, lida na mesma data), agentes já em produção em processos de procurement, como Ariba e Fieldglass. É natural perguntar se esse avanço muda essa fronteira. Do ponto de vista de governança, a resposta é parcial. O avanço muda a quantidade de tarefas que podem ser executadas com menor intervenção humana em cada etapa, e isso é um ganho real de eficiência operacional. O que o avanço não muda é a natureza da responsabilidade sobre o resultado dessa execução. Um agente mais capaz, executando mais etapas sozinho, aumenta a importância de definir bem o perímetro dentro do qual ele opera, exatamente porque menos intervenção humana por etapa significa menos oportunidades de correção no meio do caminho.

Em outras palavras, quanto mais autônomo o agente, mais relevante (não menos) se torna a decisão humana anterior, que definiu esse perímetro, e a decisão humana posterior, que revisa periodicamente se ele continua adequado. Isso vale hoje, com o escopo atual de agentes, e provavelmente vai valer com qualquer escopo futuro, porque a responsabilidade jurídica e fiscal não acompanha automaticamente a capacidade técnica.

Um checklist executivo para essa avaliação

Para quem precisa levar essa discussão a um conselho, a um comitê de risco ou a uma diretoria, três perguntas ajudam a estruturar a conversa sem depender de jargão técnico.

1. Primeira o que exatamente está sendo avaliado, entre as três categorias descritas: uso nativo, uso que exige preparação, ou automação com decisão humana embutida. Confundir essas categorias numa única proposta comercial é um sinal de alerta, porque cada uma tem custo, prazo e risco diferentes.

2. Segunda quem, dentro da empresa, seria formalmente responsável por uma decisão acelerada por Joule, caso ela precise ser defendida perante um órgão regulador ou um auditor. Se essa pergunta não tem resposta clara antes de qualquer piloto começar, a preparação de governança ainda não está completa, independentemente da maturidade técnica da ferramenta.

3. Terceira com que frequência o perímetro de atuação de qualquer automação mais autônoma será revisado, e por quem. Tecnologia evolui, mas a decisão sobre onde ela pode agir sozinha não deve ser tomada uma vez e esquecida, deve ser parte de um ciclo de governança contínua, com dono nomeado e periodicidade definida.

Onde a NTT DATA entra nessa conversa

A NTT DATA é a detentora do Guepardo Tax, produto de apuração fiscal que a DFSpro governa dentro do ambiente SAP de seus clientes. Qualquer decisão de arquitetura ou roadmap do Guepardo Tax, incluindo eventual integração futura com IA, é responsabilidade da NTT DATA, não da DFSpro. Não há, hoje, documentação pública confirmando integração entre o SAP Joule e o Guepardo Tax. São sistemas distintos, e qualquer afirmação de integração entre os dois segue sem fonte que a sustente.

O papel da DFSpro nessa fronteira

O trabalho da DFSpro, quando envolve SAP Joule, começa exatamente na fronteira descrita acima: identificar, na operação específica de cada cliente, o que já funciona nativamente e não precisa de intervenção, o que exige preparação de arquitetura e dado antes de gerar valor, e onde a responsabilidade continua sendo, por definição, do cliente e de quem responde formalmente pela decisão fiscal dele. Não decidimos a tese tributária de ninguém. Desenhamos, configuramos e provamos como o sistema se comporta a partir de uma decisão já tomada por quem tem essa responsabilidade.

O custo de credibilidade de inflar a dependência

Um comparativo honesto entre tecnologia nativa e trabalho de consultoria expõe a consultoria a um risco comercial direto: o leitor pode concluir, com razão, que precisa de menos ajuda do que imaginava em algumas frentes. A alternativa, inflar a dependência de intervenção humana onde ela não existe, compra uma vantagem comercial de curto prazo e paga um custo de credibilidade de longo prazo, cobrado na primeira vez que o cliente percebe a diferença entre o que foi prometido e o que a tecnologia realmente exige. A decisão de investir em avaliar o Joule agora ou depois pertence a quem responde pelo resultado da operação, com base no próprio critério de risco, prioridade e capacidade interna. O que muda com a separação em três camadas não é a decisão: é a precisão com que ela pode ser tomada, porque capacidade técnica pronta, trabalho de preparação e responsabilidade indelegável deixam de ser cobrados no mesmo pacote.

Separar, no seu ambiente, o que o Joule já resolve do que depende de preparação de arquitetura e dado é um levantamento concreto, com transação, cadastro e ponto de fechamento nomeados. É o mesmo levantamento que abre um Diagnóstico Fiscal Estruturado.