Levar a gestão fiscal para uma conversa com ChatGPT ou Claude muda a forma de pedir informações. Não demonstra, por si só, que o sistema calcula tributos corretamente, restringe acessos ou impede uma ação indevida. Para a equipe fiscal, a primeira decisão não é quais perguntas fazer à IA, mas quais dados e operações autorizar.
A Spedy aparece em um anúncio de lançamento de MCP para integração com ChatGPT e Claude, publicado em 3 de novembro de 2026. O registro disponível identifica a proposta, mas não detalha o catálogo de funcionalidades nem a arquitetura de segurança.
Por isso, não há evidência suficiente para afirmar que a integração emite documentos, cancela notas, altera cadastros ou executa apurações. Esses pontos precisam ser demonstrados. O caminho para avaliar a oferta é separar interface, integração e regra tributária — e exigir provas em cada etapa.
MCP, sigla de Model Context Protocol, é um protocolo para conectar aplicações de IA a fontes de dados e ferramentas. Em uma arquitetura desse tipo, a conversa pode funcionar como porta de entrada para uma consulta ou solicitação de operação em outro sistema.
Isso não significa que todos os conectores ofereçam as mesmas capacidades. Uma implementação pode expor somente consultas. Outra pode permitir operações que modificam registros. O alcance depende das ferramentas disponibilizadas, da configuração do ambiente e das autorizações concedidas. Essa descrição é geral, não uma confirmação das funções da Spedy.
Também é necessário separar a resposta redigida pela IA do resultado produzido pelo sistema fiscal. Uma explicação convincente não comprova cálculo correto nem enquadramento tributário válido. Se a consulta envolve imposto, a evidência deve chegar à regra aplicada, à base de cálculo e ao documento de origem. É a mesma disciplina dos testes do motor tributário antes de atualizar o ERP.
A avaliação precisa começar com um inventário escrito. Para cada função, o fornecedor deve indicar o que ela consulta ou modifica, quais parâmetros aceita, quais dados devolve e quais restrições aplica. Compatibilidade com um assistente não esclarece esse escopo.
Considere um exemplo hipotético: “mostre as notas com divergência de imposto no período”. Antes de aceitar a resposta, a equipe precisa saber o significado de divergência. O sistema comparou valores com uma regra fiscal? Consultou uma ocorrência já registrada? Ou a IA inferiu o problema a partir de informações parciais? São resultados diferentes, com exigências distintas de revisão.
Na demonstração, vale exigir respostas objetivas para estas perguntas:
Uma instrução como “não altere documentos” não substitui controle de acesso. A restrição deve existir no serviço que recebe a operação e no sistema responsável pelos dados. O desenho recomendado é começar com leitura e liberar outras capacidades apenas mediante necessidade comprovada.
A preocupação encontra contexto no IMTT — Índice de Maturidade Tecnológica em Tax, da Confeb, de 2026. Entre as empresas respondentes, representadas por 190 profissionais de Tax, 93% não têm governança oficial de IA e 51% usam IA generativa por iniciativa individual. Os números mostram uma distância entre experimentar a tecnologia e incorporá-la com regras formais à operação fiscal.
Na prática, peça testes com perfis diferentes. Um usuário sem acesso a determinado estabelecimento deve continuar impedido de consultá-lo pelo assistente. A mesma verificação precisa abranger exportações e operações em lote. Também devem ser demonstradas a revogação de acesso e a proteção das credenciais. O princípio é o já discutido sobre agentes de IA e responsabilidade pela decisão tributária: automatizar a tarefa não transfere o risco fiscal.
Se houver operações que alterem dados, a confirmação precisa ocorrer antes da execução e apresentar o efeito esperado. Um botão genérico de aprovação é insuficiente quando o usuário não consegue identificar quais registros serão afetados.
Em um cenário hipotético de alteração em lote, a tela de confirmação deveria mostrar empresa, estabelecimento, período, quantidade de registros e campos modificados. Se a solicitação estiver ambígua, o fluxo deve pedir esclarecimento, não escolher silenciosamente uma interpretação. Essas são exigências recomendadas para homologação, não recursos já verificados no produto anunciado.
Também convém separar quem solicita de quem aprova, conforme o risco da operação. A prova deve incluir tentativas de contornar essa separação e de executar novamente uma ação após falha de conexão. Sem controle de repetição, uma solicitação reenviada pode gerar duplicidade. A documentação deve explicar como o sistema identifica o que já foi concluído.
Guardar a conversa ajuda, mas não reconstrói sozinho uma operação fiscal. O registro técnico precisa permitir relacionar solicitação, usuário, ferramenta acionada, parâmetros, aprovação e resultado no sistema de destino. Erros e recusas também devem deixar evidências.
Quando houver cálculo, a trilha deve preservar a versão da regra e os dados utilizados naquele momento. Uma resposta posterior, baseada no cadastro atualizado, pode não explicar o resultado original. Esse cuidado se conecta à necessidade de rastrear o cálculo fiscal no ERP sem perder o histórico.
Outro bloco de perguntas trata do compartilhamento. Quais campos saem da plataforma fiscal? O assistente recebe documentos completos ou resultados filtrados? Há dados em mensagens de erro e registros técnicos? Quem armazena cada conteúdo e por quanto tempo? As respostas devem constar da documentação e dos termos aplicáveis ao ambiente contratado. Não é possível presumir essas condições apenas pelo nome do assistente utilizado.
O piloto deve usar ambiente controlado e dados sintéticos ou devidamente protegidos. Antes de iniciá-lo, a área fiscal precisa definir o resultado esperado de cada caso. Sem essa referência, uma demonstração fluida pode esconder consulta incompleta ou interpretação equivocada.
Uma bateria mínima deve incluir consulta correta, período sem movimento, documento inexistente, acesso negado e indisponibilidade do sistema de origem. Se houver escrita, entram aprovação recusada, solicitação ambígua e repetição após falha. O teste precisa verificar não apenas se a ferramenta responde, mas se deixa de agir quando deveria.
Benefício operacional exige medição. Compare o processo atual com o piloto, incluindo tempo de conferência, correções e tratamento de exceções. Uma resposta mais rápida não representa ganho líquido se aumentar o trabalho de revisão. O fornecedor deve demonstrar o resultado sobre tarefas equivalentes, sem substituir evidências por estimativas comerciais.
Para a oferta anunciada, permanecem sem confirmação o catálogo de consultas e ações, a matriz de permissões, os mecanismos de aprovação e os fluxos de dados. Também faltam evidências sobre rastreabilidade e desempenho operacional. A ausência desses detalhes no registro disponível não prova que os controles não existam; impede afirmar que existem.
Antes de liberar dados de produção, a empresa deve obter documentação, executar a demonstração com seus casos e registrar o aceite conjunto de Fiscal, TI e Segurança. A integração fiscal com IA deve ser aprovada pelo que consegue provar sob controle — não pela naturalidade da conversa.
Este conteúdo foi produzido com apoio de inteligência artificial e revisado pela equipe editorial da Live University.