Classificação contábil com IA: regras, sugestão e revisão

Classificação contábil com IA: regras, sugestão e revisão

A classificação contábil com IA funciona melhor quando o trabalho é dividido em três camadas. Regras fixas resolvem o que é repetitivo e inequívoco, a IA sugere conta e histórico nos casos ambíguos, e o contador confere o que tem risco ou baixa confiança. Cada lançamento carrega a origem da decisão, a justificativa e quem aprovou, e é isso que dá rastreabilidade.

Principais pontos

• Não existe uma única etapa de IA: existem regras determinísticas, sugestões do modelo e conferência humana, cada uma com função e limite próprios.
• Regras fixas devem vir primeiro, porque são previsíveis, baratas de auditar e não mudam de resposta de um dia para o outro.
• A IA só sugere dentro do plano de contas da empresa e devolve uma justificativa curta, nunca cria contas nem grava sozinha no sistema.
• O contador define os critérios, revisa a fila de exceções e decide o que pode passar a ser regra.
• Sem log por lançamento (origem, versão da regra, sugestão, decisão final), o processo não é auditável, por mais que a sugestão pareça boa.

Por que não entregar o plano de contas inteiro para a IA?

A tentação é simples: exportar o extrato, colar o plano de contas e pedir que o modelo classifique tudo. Em um teste rápido, o resultado parece bom. O problema aparece depois, quando o mesmo fornecedor cai em contas diferentes em meses diferentes, quando uma conta nova aparece sem aprovação ou quando ninguém sabe explicar por que um lançamento foi para determinada conta.

Um modelo de linguagem é bom em interpretar texto desorganizado, como uma descrição de extrato abreviada, um histórico de cartão ou um nome de fornecedor truncado. Ele é pior em manter consistência estrita ao longo de milhares de itens e em respeitar políticas internas que não estão escritas em lugar nenhum. Por isso a divisão de papéis importa mais do que a escolha do modelo.

A documentação sobre construção de agentes da Anthropic faz uma distinção útil entre fluxos de trabalho com caminhos definidos em código e agentes que decidem o próprio caminho. Para contabilidade, a escolha prudente é começar pelo fluxo definido: etapas fixas, com o modelo chamado apenas onde há julgamento a fazer.

Camada um: quais lançamentos devem ser resolvidos por regra fixa?

Regra fixa é tudo o que o contador responderia sempre da mesma forma, sem pensar. Nessa camada não há IA, e isso é uma vantagem: o resultado é reproduzível e fácil de explicar.

Bons candidatos para regras:

• Tarifas bancárias recorrentes com descrição padronizada.
• Fornecedores identificados por CNPJ que sempre pertencem à mesma conta (por exemplo, a conta de energia ou de internet do escritório).
• Lançamentos vindos de notas fiscais eletrônicas com natureza da operação e itens já estruturados no XML.
• Transferências entre contas da própria empresa.
• Impostos e guias com código de barras ou código de receita reconhecível.

Uma regra bem escrita tem identificador, condição, conta de destino, data de criação e responsável. Prefira condições por campos estruturados (CNPJ, código, valor exato recorrente) a condições por trechos de texto livre, que geram falsos positivos. Se um trecho de texto como "posto" mandar tudo para combustível, uma compra de conveniência vai parar no lugar errado sem aviso.

Regras também precisam de versão. Quando o contador altera uma regra, os lançamentos já classificados devem continuar apontando para a versão anterior, e só os novos usam a versão atual. Isso evita reescrever a história sem perceber.

Camada dois: o que a IA deve sugerir e com quais dados?

O que sobra das regras é a fila de ambiguidade: descrições vagas, fornecedores novos, compras que podem ser despesa, custo ou ativo. Aqui a IA entra como sugestora, não como decisora.

O modelo deve receber um pacote mínimo e controlado:

• A descrição do lançamento, o valor e a data.
• O fornecedor ou favorecido, quando houver.
• A lista fechada de contas permitidas, com uma frase de explicação para cada uma.
• Alguns exemplos de lançamentos já aprovados pelo contador, parecidos com o caso atual.
• As políticas internas escritas, como limite para tratar item como ativo imobilizado.

E deve devolver um formato fixo: conta sugerida (somente da lista), nível de confiança em categorias simples (alta, média, baixa), justificativa em uma ou duas frases e um campo para dizer quando faltam informações. Um "não sei" explícito vale mais do que uma resposta confiante e errada. Se faltar o comprovante ou a nota, a sugestão correta pode ser pedir o documento, e não classificar.

Duas proteções práticas. Primeiro, valide a saída em código: se a conta devolvida não existe no plano, o lançamento volta para a fila humana. Segundo, trate o texto dos lançamentos como dado, não como instrução. Descrições vêm de terceiros, e uma descrição maliciosa ou apenas estranha não pode alterar o comportamento do modelo. O guia da OWASP sobre injeção de prompt em aplicações com modelos de linguagem trata desse risco.

Se os documentos de origem são PDFs de notas e boletos, a extração dos campos é uma etapa separada, com conferência própria. O artigo sobre extrair dados de PDF com IA descreve como separar leitura do documento e decisão.

Camada três: quando o contador precisa conferir?

A conferência humana não deve ser uma revisão de tudo, nem um carimbo automático. Ela precisa de critérios claros sobre o que obrigatoriamente passa pelo contador. Um guia de decisão simples:

• Confiança baixa ou campo "faltam informações": sempre para revisão.
• Fornecedor nunca visto antes: revisão, com a decisão guardada para virar regra se se repetir.
• Valor acima do limite definido pelo contador: revisão, mesmo com confiança alta.
• Operações com efeito tributário, partes relacionadas, sócios ou folha: revisão obrigatória, sem exceção.
• Divergência entre a sugestão da IA e uma regra existente: revisão, porque indica regra desatualizada ou erro.
• Confiança alta, fornecedor conhecido e valor baixo: amostragem periódica em vez de revisão item a item.

A amostragem é o ponto delicado. Ela só é honesta se o contador também revisa uma amostra do que a IA classificou com confiança alta, porque é ali que erros silenciosos se escondem. Registre a taxa de correção dessa amostra com o tempo e use-a para decidir se o limite pode subir ou deve descer.

Quando o contador corrige uma sugestão, a correção é informação valiosa. Ela pode virar um novo exemplo para o pacote do modelo ou uma nova regra fixa, sempre por decisão dele, não do sistema. Responsabilidade técnica pela escrituração continua com o profissional; a IA reduz digitação e triagem, não transfere essa responsabilidade. Para uma visão geral do que deve ficar com pessoas, veja o que não delegar à inteligência artificial na empresa.

Como garantir rastreabilidade em cada lançamento?

Rastreabilidade significa responder, meses depois, três perguntas: quem classificou, com base em quê e quem aprovou. Para isso, cada lançamento deve guardar um registro com campos fixos:

• Identificador do lançamento e do documento de origem.
• Etapa que decidiu: regra, sugestão da IA ou ajuste manual.
• Identificador e versão da regra, quando foi regra.
• Para sugestões: modelo usado, versão do conjunto de instruções, conta sugerida, confiança e justificativa.
• Decisão final, quem a tomou e quando.
• Motivo da correção, quando o contador mudou a sugestão.

Guarde isso em uma tabela de log separada, que o fluxo só acrescenta e nunca sobrescreve. Os conceitos de observabilidade da OpenTelemetry (registros, métricas e rastros) ajudam a pensar em como esses eventos se conectam, mesmo que a implementação seja uma planilha bem controlada ou um banco simples no começo.

Sobre privacidade: extratos e notas contêm dados pessoais de sócios, funcionários e pessoas físicas. Envie ao modelo só o necessário, mascare CPF e dados bancários que não influenciam a classificação e defina por quanto tempo o log fica guardado. Se o modelo roda fora do Brasil, vale ler sobre transferência internacional de dados com IA e LGPD. A página da ANPD é a referência oficial para orientações.

Cenário ilustrativo: um mês de conciliação em uma empresa de serviços

Imagine uma empresa de serviços com um extrato mensal de tamanho médio, feito por uma pessoa do financeiro e revisado por um contador externo. Este cenário é ilustrativo, sem relação com cliente real.

O fluxo recebe o arquivo do extrato e as notas do período. As regras fixas reconhecem tarifas, transferências entre contas próprias, guias de impostos e fornecedores recorrentes por CNPJ. Esses lançamentos são classificados e registrados no log com o identificador da regra.

O restante vai para a IA. Um débito com descrição abreviada de um fornecedor desconhecido recebe a sugestão de uma conta de serviços de terceiros, confiança média e a justificativa de que o nome sugere uma prestação de serviço, mas falta a nota. Como é fornecedor novo e a confiança não é alta, vai para a fila do contador. Ele pede a nota, confirma a conta e marca o fornecedor para virar regra.

No mês seguinte, esse fornecedor já cai na camada um. A fila humana encolheu por decisão do contador, não porque o modelo "aprendeu" sozinho. No fechamento, o contador também revisa uma amostra do que foi classificado com confiança alta, registra os erros encontrados e ajusta limites e regras.

Como começar: mapear, limitar, pilotar e transferir

O método que usamos em projetos de IA aplicados a processos segue quatro passos, e se encaixa bem aqui.

• Mapear: levante como a classificação é feita hoje, quais sistemas e documentos entram, quem decide e qual é o ponto de partida de tempo e retrabalho. Sem esse retrato, não há como saber se melhorou.
• Limitar: defina quais dados o modelo vê, quais contas pode sugerir e que ele nunca grava direto no sistema contábil. A saída é uma sugestão em uma fila, não um lançamento.
• Pilotar: escolha um fluxo real e pequeno, como uma conta bancária ou um tipo de despesa, com log completo e uma métrica combinada com o contador, como a proporção de sugestões aceitas sem correção.
• Transferir: entregue a documentação das regras, dos critérios de revisão e do log, e decida com o contador se expande, ajusta ou para.

Para medir a qualidade da sugestão antes de ligar o fluxo, monte um conjunto de teste com lançamentos já classificados e aprovados, e compare a sugestão do modelo com a decisão do contador. O guia de avaliações da OpenAI descreve essa lógica de testar sistemas com modelos contra casos conhecidos, e o princípio vale independentemente do fornecedor. Repita o teste sempre que mudar o modelo, as instruções ou o plano de contas.

Se o fluxo tocar decisões sobre pessoas, como remuneração ou pagamentos individuais, vale conferir o direito de revisão previsto na LGPD, explicado em decisões automatizadas e o artigo 20.

Perguntas frequentes

A IA pode lançar direto no sistema contábil sem revisão? Não é recomendável no início. O desenho mais seguro grava a sugestão em uma fila e só passa para o sistema depois de regra ou aprovação humana. Com o tempo, o contador pode autorizar a passagem direta para categorias de baixo risco, mantendo amostragem e log.

Preciso treinar um modelo próprio com o histórico da empresa? Normalmente não. Para esse tipo de tarefa, costuma bastar um modelo geral com o plano de contas, as políticas escritas e exemplos aprovados no pacote de contexto, mais validação em código. Treinar ou ajustar um modelo é um passo posterior, só se os testes mostrarem que o contexto não basta.

Como evitar que a IA invente uma conta que não existe? Entregue uma lista fechada de contas e valide a resposta em código antes de aceitar. Se a conta devolvida não estiver na lista, o lançamento vai automaticamente para a fila do contador, com o registro do erro no log.

Esse processo substitui o contador ou o escritório de contabilidade? Não. Ele reduz triagem e digitação, mas critérios, exceções e responsabilidade técnica continuam com o profissional. O ganho está em usar o tempo dele nos casos que exigem julgamento, com um histórico claro de cada decisão.

Fontes

• Anthropic: Building effective agents
• OpenAI: evals guide
• OpenTelemetry: observability concepts
• OWASP: prompt injection prevention