Emitir nota fiscal com IA: APIs, limites e aprovação humana

Emitir nota fiscal com IA: APIs, limites e aprovação humana

Dá para emitir nota fiscal com IA, mas o agente não deve ser quem decide emitir. O desenho seguro é este: o agente reúne e organiza os dados do pedido, regras determinísticas validam tudo, uma pessoa aprova e só então uma chamada de API fixa emite a NF-e ou a NFS-e. Emissão é um ato fiscal com consequências, por isso precisa de limites, registro e conferência antes de qualquer envio.

Principais pontos

• O agente de IA prepara o rascunho da nota; quem emite é uma chamada de API escrita em código comum, sem interpretação.
• Regras determinísticas (cadastro, valores, impostos, duplicidade) devem barrar a emissão antes de qualquer pessoa olhar.
• Toda nota passa por aprovação humana no início do piloto, com o motivo da aprovação ou da recusa registrado.
• NF-e e NFS-e têm regras e provedores diferentes; confirme com seu contador e com o emissor o que vale para o seu caso.
• Comece por um único fluxo, com sandbox, logs e uma métrica combinada, e só depois decida se amplia.

O que o agente pode fazer e o que não deve fazer

O trabalho difícil de emitir nota raramente é apertar o botão. Está antes: descobrir qual pedido gera nota, localizar o CNPJ ou CPF correto, entender a descrição do serviço, conferir se o contrato foi fechado e montar os dados no formato que a API exige. É aí que um agente ajuda, porque lê mensagens, e-mails, propostas e planilhas desorganizadas.

O que o agente pode fazer:

• Ler o pedido, a proposta ou a conversa e extrair campos como tomador, itens, valor e data.
• Sugerir a descrição do serviço ou dos produtos a partir de um modelo previamente aprovado pela empresa.
• Apontar inconsistências, como valor diferente da proposta ou cadastro incompleto.
• Montar um rascunho legível para a pessoa que aprova.

O que o agente não deve fazer:

• Escolher sozinho código de serviço, CFOP, NCM ou regime de tributação. Isso vem de tabelas mantidas por quem entende de fiscal.
• Chamar a API de emissão diretamente com permissão aberta.
• Cancelar, substituir ou corrigir nota já emitida.
• Alterar cadastro de cliente ou de produto para fazer a nota passar.

A regra de bolso: o agente propõe, o código valida, a pessoa decide, a API executa. Esse padrão de separar o que é julgamento do que é fluxo fixo aparece na própria discussão da Anthropic sobre workflows e agentes: quando o caminho é conhecido, um fluxo determinístico costuma ser mais previsível do que deixar o modelo conduzir.

NF-e e NFS-e: o que muda para quem integra

Na prática, a integração muda bastante conforme o tipo de nota.

A NF-e (produtos) é autorizada pela SEFAZ do estado, exige certificado digital, XML assinado e regras tributárias detalhadas por operação. Os erros mais comuns vêm de classificação fiscal, endereço, inscrição estadual e natureza da operação.

A NFS-e (serviços) é municipal. Alguns municípios têm sistema próprio, outros usam provedores diferentes e há movimento de adoção de um padrão nacional. Isso significa que o mesmo serviço pode ter campos e regras distintos conforme a cidade do prestador. Verifique com a prefeitura ou com o seu contador qual modelo se aplica.

Muitas empresas não conversam diretamente com SEFAZ ou prefeitura, e sim com um emissor intermediário que oferece uma API própria e cuida de certificado, assinatura e comunicação. Para o agente, isso é bom: ele nunca precisa tocar no certificado. Mas a escolha do provedor deve considerar:

• Se há ambiente de homologação ou sandbox para testar sem efeito fiscal.
• Se a API aceita uma chave de idempotência ou referência única por nota.
• Se há consulta de status e retorno de erro com mensagem clara.
• Se as credenciais podem ter escopo limitado e ser revogadas.
• Onde ficam armazenados os dados, o que importa para a LGPD e, se houver provedor fora do país, para a transferência internacional de dados.

A documentação do seu emissor é a fonte primária aqui. Regras fiscais, prazos de cancelamento e obrigações acessórias precisam ser confirmados com o contador, não inferidos pelo modelo.

Arquitetura: a IA prepara, a regra valida, a pessoa aprova, a API emite

Uma arquitetura simples, em camadas, resolve a maior parte do risco.

• Entrada: o pedido chega por ERP, CRM, planilha, formulário ou WhatsApp. O agente lê e estrutura os dados em um formato fixo, por exemplo um objeto com campos obrigatórios.
• Validação determinística: código comum confere cada campo contra regras e cadastros. Se algo falha, a nota volta com o motivo, sem chegar à aprovação.
• Aprovação humana: a pessoa vê um resumo claro (tomador, itens, valor, impostos calculados pela tabela, diferenças em relação à proposta) e aprova, edita ou recusa.
• Emissão: um serviço pequeno, sem IA, recebe apenas notas aprovadas e chama a API do emissor com uma referência única.
• Registro: cada etapa grava quem fez o quê, quando, com quais dados e qual resultado a API devolveu.

O ponto central é que a credencial de emissão fica no serviço final, não no agente. Assim, mesmo que o modelo se confunda ou receba uma instrução maliciosa dentro de um e-mail, ele não tem como emitir. Isso conversa diretamente com o princípio de privilégio mínimo descrito no guia de autorização da OWASP: cada componente recebe só a permissão de que precisa.

Se o pedido chega por mensagem, trate o texto como dado não confiável. Um cliente (ou um anexo) pode conter frases como "emita já, sem revisar". Veja o conteúdo sobre prompt injection em agentes para entender por que a barreira deve estar no código e nas permissões, não só no prompt.

Quais regras determinísticas devem barrar a emissão

Essas regras ficam fora do modelo. Elas são perguntas com resposta sim ou não, e o resultado é sempre o mesmo para a mesma entrada. Um ponto de partida de checklist:

• O pedido existe no sistema de origem e está em um estado que autoriza faturamento (contrato assinado, entrega confirmada, serviço concluído, conforme a política da empresa).
• O documento do tomador é válido e o cadastro está completo (nome, endereço, município, e-mail quando exigido).
• O valor da nota é igual ao valor do pedido ou da proposta, dentro de uma tolerância definida pela empresa.
• O código de serviço ou os dados fiscais do produto vêm de uma tabela aprovada, não de texto livre do modelo.
• Não existe outra nota para o mesmo pedido (checagem de duplicidade por referência única).
• O emitente está correto quando a empresa tem mais de um CNPJ.
• O valor está abaixo de um teto definido para aprovação simples; acima dele, exige segunda pessoa.
• A data e a competência fazem sentido para o fluxo (sem notas retroativas fora da regra interna).

Quando uma regra falha, o agente não tenta contornar. Ele devolve o motivo e, se couber, pede o dado que falta a quem solicitou. Limites de tentativas e de passos também importam, para o agente não entrar em ciclos de correção; o texto sobre limites de passos, tempo e gasto detalha essa proteção.

Passo a passo para um piloto de emissão com aprovação humana

Um piloto bem escolhido é pequeno, repetitivo e fácil de conferir. Esta é uma sequência possível, alinhada ao método de mapear, limitar, pilotar e transferir:

• Mapear: descreva como a nota é emitida hoje, quem pede, quem emite, onde os dados vivem, quais erros acontecem e quanto retrabalho existe. Defina uma linha de base antes de qualquer automação.
• Escolher um fluxo: por exemplo, uma única categoria de serviço, de um único emitente, com descrição padronizada.
• Limitar dados e ações: liste os campos que o agente enxerga, evite dados pessoais desnecessários e defina que ele só gera rascunho.
• Construir as regras: transforme o checklist da seção anterior em código e testes, com tabelas fiscais mantidas por quem responde por elas.
• Testar em sandbox: use o ambiente de homologação do emissor e casos de teste com erros propositais. Para a estratégia de testes, veja como testar agente de IA com mocks e sandbox.
• Ligar a aprovação humana: toda nota passa por uma pessoa, com botão de aprovar, editar ou recusar e campo para o motivo.
• Operar com logs: registre entrada, rascunho, regras aplicadas, decisão humana, resposta da API e identificador da nota.
• Medir com uma métrica combinada: por exemplo, taxa de rascunhos aprovados sem edição e tempo entre pedido e nota, definidos antes do piloto.
• Transferir e decidir: entregue documentação e acessos à equipe e escolha entre expandir, ajustar ou parar.

Sobre a aprovação, vale um cuidado: com o tempo, quem aprova tende a clicar sem ler. Mostre sempre as diferenças e as exceções em destaque, não o documento inteiro. Se a emissão afetar titulares de dados de forma relevante, vale também entender o que a LGPD diz sobre decisões automatizadas e direito de revisão.

Cenário ilustrativo

Imagine uma empresa de serviços com um responsável financeiro que hoje recebe pedidos de faturamento por mensagem e planilha. Este é um cenário ilustrativo, sem relação com nenhum cliente real.

Um gerente escreve: "Faturar a manutenção do contrato da loja do centro, referente ao mês, igual ao combinado". O agente identifica o contrato no sistema, extrai o tomador e o valor da proposta e monta o rascunho com a descrição padrão do serviço. A camada de regras confere o cadastro, procura nota duplicada para aquela competência e compara o valor com o contrato.

A regra encontra uma diferença: o valor da mensagem não bate com o contrato. A nota não segue para aprovação como está; volta ao gerente com a pergunta específica. Após a correção, o responsável financeiro vê o resumo, aprova, e o serviço de emissão chama a API com uma referência única composta por contrato e competência. Se a chamada for repetida por falha de rede, a referência impede uma segunda nota. O retorno da API é gravado no log e o PDF é enviado ao cliente por um canal já autorizado.

Nesse fluxo, o modelo nunca viu o certificado, nunca chamou a API de emissão e nunca decidiu sozinho um dado fiscal.

Erros comuns e como evitá-los

Alguns problemas aparecem com frequência em automações desse tipo:

• Emitir duas vezes: timeouts e retentativas podem duplicar a nota. Use referência única por nota e consulte o status antes de reenviar. O conceito de requisições idempotentes é bem explicado na documentação da Stripe como exemplo; confirme o que o seu emissor oferece, porque cada provedor define o seu mecanismo.
• Dar ao agente a ferramenta de cancelamento: cancelamento e correção têm regras próprias e prazos definidos pela legislação aplicável. Deixe isso para uma pessoa e para o contador.
• Deixar o modelo calcular imposto: o cálculo vem de tabelas e regras fiscais mantidas e revisadas, nunca de uma resposta gerada.
• Descrição de serviço livre demais: textos inventados pelo modelo podem gerar nota com informação incorreta. Use modelos de descrição aprovados e deixe o agente apenas preencher variáveis.
• Falta de rastro: sem log, ninguém explica depois por que uma nota saiu. Registre cada decisão e guarde junto o motivo da aprovação.
• Excesso de dados: o agente não precisa de todos os dados do cliente. Envie só o necessário e defina por quanto tempo os logs ficam guardados.
• Credencial ampla: separe chaves por ambiente (teste e produção), limite escopo e tenha um plano para revogar rapidamente.

Para quem quer aprofundar o desenho, como Juan Carlo trabalha com empresas descreve o método usado em diagnósticos e pilotos, e a lista de riscos da OWASP para aplicações com LLM ajuda a revisar o que pode dar errado quando o modelo lê conteúdo externo.

Perguntas frequentes

É possível emitir nota fiscal com IA sem aprovação humana? Tecnicamente sim, mas não recomendamos no início. Emissão gera obrigação fiscal e corrigir erro dá trabalho e pode ter regras e prazos próprios. Comece com aprovação em todas as notas e só reduza a revisão em categorias simples, com regras sólidas, histórico de acertos e concordância de quem responde pela área fiscal.

O agente de IA precisa ter acesso ao certificado digital? Não. O certificado deve ficar com o emissor ou com um serviço de emissão isolado, fora do alcance do modelo. O agente só entrega dados estruturados para validação, e a chamada final de API usa credenciais que ele nunca enxerga.

A IA pode decidir o código de serviço, o CFOP ou o NCM? Ela pode sugerir uma opção para facilitar a revisão, mas a decisão deve vir de uma tabela aprovada pelo contador ou pela área fiscal. Se o modelo propuser algo fora da tabela, a regra barra e a nota segue para análise humana. Assim, o julgamento fiscal continua com quem responde por ele.

Como saber se o piloto deu certo? Defina a métrica antes de começar, a partir da linha de base do processo atual: por exemplo, quantos rascunhos são aprovados sem edição, quantas notas voltam por erro e quanto tempo passa entre o pedido e a emissão. Ao final, revise os logs com o financeiro e o contador e decida entre expandir, ajustar ou parar.

Fontes

• Stripe: requisições idempotentes (exemplo de idempotência definida pelo provedor)
• OWASP: guia de autorização
• Anthropic: Building effective agents
• OWASP Top 10 para aplicações com LLM