Loops de IA na prestação de contas de subvenção Finep

MIT-ANPEI Brazil Summit 2026 · Call for Cases Loops de IA na prestação de contas de subvenção Finep Como sair do prompt e chegar a uma auditoria rastreável: 1.200 registros conferidos, 55 chamadas ao modelo, 70% menos horas de trabalho e um papel de trabalho por decisão.

70% menos horas de auditoria (88 h para 26 h) 1.200 registros processados 4,6% dos registros chegam ao modelo R$ 9 a 16 custo de API por rodada completa

Proponente: Hub.Fomento (Vitória, ES), plataforma e consultoria de gestão de fomento à inovação.

Autor: Thiago Bionde de Araujo, contador (CRC SP-264354/O, CNPC 6563), fundador do Hub.Fomento e Head de Fomento em operadora de saúde.

Categoria: IA aplicada, dados e rastreabilidade em gestão de fomento.

Período medido: 20 a 28 de agosto de 2026. Estágio: em operação real; prestação de contas protocolada e em análise na Finep.

O cliente beneficiário da subvenção é descrito de forma anonimizada ao longo deste documento, por decisão do autor. Números, documentos e resultados são os do trabalho real.

1. Resumo executivo

Toda empresa que recebe subvenção econômica da Finep precisa prestar contas. O instrumento é a DDR (Demonstrativo de Despesas Realizadas), assinado sob pena civil e criminal, e dele depende a liberação da parcela seguinte. O trabalho por trás de uma DDR é conferência: cruzar planilha de controle com extratos bancários, notas fiscais, relação de itens aprovada e Termo de Outorga, item por item, rubrica por rubrica. É manual, repetitivo, sujeito a erro e caro. Para uma empresa pequena, é frequentemente o gargalo entre o dinheiro aprovado e o dinheiro na conta. A própria Finep já mediu isso: em 2013, quase metade das prestações de contas de convênios FNDCT analisadas voltou com impropriedade, e dez tipos de erro, quase todos de conferência, respondiam por 90% das ocorrências (Azevedo, 2014).

Este case relata a primeira prestação de contas de um contrato de subvenção Finep de uma empresa agrícola familiar de produção orgânica no interior de Minas Gerais, executada com um método que chamamos de Fábrica de Loops: em vez de pedir a um modelo de linguagem que "analise a planilha", o trabalho foi decomposto em loops, cada um repetindo uma pergunta única sobre uma unidade pequena e independente (uma despesa, uma alínea, um item remanejado). Tudo o que cabe numa regra determinística é resolvido em código; o modelo só entra onde existe julgamento genuíno, e a resposta dele é validada mecanicamente antes de ser aceita. Cada decisão gera um registro de papel de trabalho.

O resultado medido entre 20 e 28 de agosto de 2026: as quatro frentes do trabalho (relatórios e pareceres, remanejamentos, conciliações e papéis de trabalho), que consomem 88 horas quando feitas à mão com planilhas e extratos, foram concluídas em 26 horas. É uma redução de 70%, ou 3,4 vezes mais rápido, com 1.200 registros processados, 55 chamadas ao modelo e custo de API entre R$ 9 e R$ 16 por rodada completa. A DDR foi protocolada e está em análise na Finep para liberação da segunda parcela, de R$ 800.778,88.

O que se replica não é um software, e sim um método: cinco decisões para desenhar um loop, cinco princípios para mantê-lo auditável e uma bancada de testes que transforma cada erro real do órgão em teste de regressão permanente. Qualquer organização com Python, uma chave de API de LLM e as planilhas que já tem consegue repetir o caminho.

2. O problema: prestar contas é conferir, e conferir não escala

A subvenção econômica é recurso público não reembolsável. Em troca, a empresa assume um conjunto de obrigações que, na prática, viram trabalho de conferência documental:

• A DDR é uma declaração sob pena. Quem assina responde civil e criminalmente pelo que está lá. Erro de classificação, item fora da relação aprovada ou despesa sem lastro vira glosa, diligência ou devolução com correção.
• O remanejamento tem teto. Movimentos entre rubricas acima de 20% precisam de anuência prévia. Quem não controla isso ao longo da execução descobre o problema quando já é tarde.
• A contrapartida precisa ser demonstrada. Pró-labore, folha e despesas de contrapartida entram na conta e precisam bater com extrato, mês a mês, ao longo de toda a vigência.
• Cada peça conversa com outra. Planilha de controle, extrato bancário, nota fiscal, relação de itens, Termo de Outorga e relatório técnico precisam contar a mesma história. Uma inconsistência em qualquer ponto contamina a DDR inteira.

Para uma empresa familiar no interior, com uma pessoa cuidando do financeiro e nenhuma estrutura de compliance, isso é intransponível sem apoio externo. E o apoio externo tradicional (consultoria de prestação de contas) cobra por hora de um trabalho que é, em grande parte, conferência mecânica.

2.1 O que a própria Finep já mediu sobre isso A dificuldade não é impressão de consultor. Um estudo de mestrado da FGV EBAPE (Azevedo, 2014), feito com dados do departamento de prestação de contas da Finep, mediu o problema no universo de convênios com recursos do FNDCT. Dos 2.476 convênios analisados pela Finep em 2013, 1.248 foram aprovados e 1.228, quase metade, voltaram com ao menos uma impropriedade. O estudo registra ainda o acúmulo de 45,7 mil prestações de contas a analisar ou não enviadas em todo o governo federal em 2010, e aponta que o temor de prestar contas de forma indevida, com devolução de recursos, é um dos motivos que levam pesquisadores e gestores a desistir de captar.

O ponto mais útil do estudo para este case é a concentração dos erros. As dez impropriedades mais recorrentes respondem por 90% de todas as ocorrências no período de 2001 a 2012; as cinco primeiras, por 68%. Em ordem de frequência:

Impropriedade mais recorrente (Azevedo, 2014) Ocorrências Onde o loop atua Ausência ou inconsistência nos anexos do formulário de acompanhamento financeiro 1.322 De-para e geração do formulário por código Ausência ou inconsistência no termo de responsabilidade sobre equipamentos 686 Checagem de bens contra relação de itens Ausência de comprovação da execução da contrapartida 648 Loop de contrapartida, mês a mês contra extrato Ausência de extratos bancários 505 Conciliação: débito sem extrato vira achado Prestação de contas sem assinatura do responsável cadastrado 398 Lista de verificação final do consultor Ausência de cópia do recibo de DOACI 312 Lista de verificação final do consultor Aquisição de equipamentos não previstos na relação de itens 292 Item fora da relação aprovada vira achado mecânico Ausência do termo de aceitação definitiva de obras 288 Não aplicável ao caso Aplicação intempestiva ou não aplicação dos recursos no mercado financeiro 173 Conciliação de rendimentos contra extrato Ausência de comprovação da devolução do saldo 121 Conciliação de saldo final Tabela 1. As dez impropriedades mais frequentes nas prestações de contas de convênios FNDCT analisadas pela Finep em 2013, e a camada do método que as ataca. Fonte: Azevedo (2014), com anotação do autor.

O estudo trata de convênios com ICTs, não de subvenção a empresas, mas a natureza dos erros é a mesma: formulário incompleto, contrapartida sem prova, extrato faltando, item fora da relação aprovada, conciliação que não fecha. Sete dos dez itens são conferências mecânicas, do tipo que uma regra de código resolve sem julgamento. A resposta da Finep, segundo o mesmo estudo, foi orientação: palestras presenciais desde 2006, um FAQ e uma metodologia de análise por Pareto. Orientar ajuda, e a curva de impropriedades caiu a partir de 2007. Mas a orientação transfere para o beneficiário uma conferência que ele continua fazendo à mão. O método deste case ataca o outro lado: faz a conferência antes do protocolo, com o mesmo rigor que o analista da Finep aplicaria depois.

Por que isso importa para o ecossistema: a Finep, o BNDES e as FAPs aprovam mais projetos do que as empresas conseguem executar e prestar contas com segurança. A fricção da prestação de contas é um dos motivos de parcelas travadas, devoluções e empresas que desistem de captar de novo. Reduzir o custo de conferir, sem reduzir o rigor, destrava capital que já foi aprovado.

3. A inovação: loop, não prompt

A primeira tentativa de usar IA nesse tipo de trabalho costuma ser a mais óbvia: anexar a planilha, colar o Termo de Outorga e pedir ao modelo que "revise a prestação de contas". Fizemos isso. Não funciona para o que o órgão exige. O modelo erra soma, inventa cláusula, mistura rubricas e, principalmente, não deixa rastro que um revisor possa assinar embaixo. A resposta é plausível e indefensável.

A mudança de abordagem foi tratar o modelo de linguagem como um analista júnior muito rápido e muito disciplinado, e não como um auditor. Um analista júnior recebe uma unidade de trabalho de cada vez, com o dossiê mínimo para decidir, uma pergunta única e uma lista fechada de respostas possíveis. E tudo o que ele devolve é conferido por um sênior antes de entrar no papel de trabalho. O loop é a formalização disso em código.

3.1 Cinco princípios que definem um loop

• Determinístico antes de LLM. Se dá para escrever uma regra de código, não é tarefa de julgamento. Soma, de-para fixo, conversão de data, checagem de duplicidade e limite de 20% são pandas, não prompt. O modelo entra só onde há julgamento genuíno: a despesa é aderente ao objeto? A justificativa do remanejamento se sustenta?
• Número nenhum vem do modelo. Valores, datas e cláusulas chegam ao julgamento via dossiê montado por código. O veredicto só pode apontar para o que está no dossiê. Parâmetros do instrumento (tetos, vigência, cláusulas) vêm de arquivo de referência, nunca da memória do modelo.
• Validação mecânica da saída. Todo veredicto passa por validação antes de ser aceito: o id existe? A classificação está na lista permitida? A soma bate? A cláusula citada existe na referência? Se qualquer checagem falha, o veredicto é rejeitado e a unidade vai para revisão humana.
• Estado em arquivo, não em contexto. Loops encadeiam por CSV; cada um é reexecutável sozinho. O registro em JSONL, com dossiê, prompt, resposta e resultado da validação por unidade, é o papel de trabalho do consultor.
• Nenhum loop vai a produção sem bancada. Casos de teste com veredicto definido pelo consultor. Meta: 100% de acerto antes de rodar em dado real. Erro real do órgão (glosa, diligência) vira caso de teste permanente, um teste de regressão do conhecimento.

Nenhum desses princípios é invenção nossa, e vale dizer isso com clareza. O primeiro e o segundo são a versão de consultoria do que a literatura chama de geração ancorada em recuperação: o modelo só pode falar a partir do que lhe foi entregue como contexto, porque conhecimento guardado nos parâmetros não tem proveniência nem se atualiza (Lewis et al., 2020). O terceiro responde ao problema documentado da alucinação, a tendência dos modelos de produzir texto fluente sem lastro no dado de entrada (Ji et al., 2023), e adota a resposta padrão da engenharia atual: saída estruturada em esquema fixo e validação mecânica antes de aceitar. O quinto segue o que se consolidou como protocolo de avaliação de sistemas com LLM, um conjunto de casos com resposta de referência definida por humano, contra o qual toda versão é medida (Zheng et al., 2023). E a revisão humana no fim do fluxo é a forma que a literatura de sistemas com humano no circuito recomenda quando a decisão tem consequência legal: a máquina propõe e documenta, a pessoa responde (Mosqueira-Rey et al., 2023). Na contabilidade, a discussão sobre automatizar a parte formalizável da auditoria e reservar ao profissional o julgamento tem mais de uma década (Issa, Sun e Vasarhelyi, 2016; Kokina e Davenport, 2017).

O que é próprio deste trabalho está em quatro pontos. Primeiro, a transposição para a DDR Finep, com a regra do instrumento (Termo de Outorga, manual de prestação de contas, relação de itens) como única referência admitida. Segundo, o mapeamento das dez impropriedades mais frequentes medidas por Azevedo (2014) para camadas concretas do método, mostrando que a maioria é conferência mecânica. Terceiro, a bancada que converte cada glosa ou diligência real do órgão em teste de regressão permanente, o que institucionaliza o aprendizado regulatório em vez de deixá-lo na cabeça do consultor. Quarto, o padrão de papel de trabalho por decisão, que permite a um contador assinar embaixo do que a máquina fez.

3.2 Arquitetura: infraestrutura se escreve uma vez, loops se fabricam em minutos A Fábrica separa o que é comum do que é específico. A infraestrutura comum (dois arquivos Python: o núcleo do loop e o executor) cuida de ponto de retomada, registro, chamada de API, validação de veredictos e gravação. Ela nunca é editada ao fabricar um loop novo. Um loop é só configuração sobre essa base:

Componente O que contém Quem escreve Spec YAML As cinco decisões do loop: unidade de julgamento, campos do dossiê, veredictos permitidos, validações, destino da saída Consultor, com apoio de IA Prompt de julgamento Papel, critério, formato JSON de resposta e a instrução "baseie-se apenas no dossiê" Consultor, com apoio de IA Módulo de domínio Adaptador de extração do formato do cliente, checagens determinísticas, montagem do dossiê, validações extras de saída IA gera, consultor revisa Casos de teste Pares (dossiê, veredicto esperado) definidos pelo consultor. A skill só estrutura; o julgamento esperado é humano Consultor

3.3 As cinco decisões: quem decide e com base em quê Todo loop nasce de uma entrevista curta entre o consultor e o assistente de código. Quem decide é sempre o consultor; o assistente conduz as perguntas, extrai da conversa o que já foi dito e só pergunta o que falta. A regra que orienta cada resposta é o próprio instrumento: o Termo de Outorga, o manual de prestação de contas da Finep e a relação de itens aprovada. As cinco decisões são:

Decisão Pergunta que o consultor responde Exemplo no revisor do remanejamento

• Unidade de julgamento O que se repete? Se a resposta for "o documento inteiro", não é loop Um item remanejado
• Dossiê O que o modelo precisa enxergar por unidade, e nada além disso? Campos do item, trecho do Termo sobre remanejamento, descrição da rubrica de destino
• Veredictos e pergunta Quais respostas são permitidas (lista fechada) e qual é a pergunta única? Sustenta, sustenta com ressalva, não sustenta, insuficiente para julgar
• Validações O que barra mecanicamente um veredicto errado? Id inexistente, cláusula citada fora da referência, justificativa sem os campos obrigatórios
• Destino Onde o resultado grava e quem consome? CSV de veredictos, documento de ação para o cliente, registro no Notion

Nada disso vem de um modelo. As perguntas são fixas porque são as mesmas que um revisor experiente faz antes de delegar uma tarefa: o que exatamente você vai olhar, o que precisa ter em mãos, que respostas aceito, como sei que você errou, e onde entrego. A entrevista só torna isso explícito e registrável.

3.4 A bancada: de onde vêm os casos de teste Nenhum loop roda em dado real sem antes acertar 100% de uma bancada de casos de teste. Um caso de teste é um par: um dossiê e o veredicto que o consultor considera correto para ele. Os casos vêm de três fontes:

• Experiência do consultor. Situações que ele já viu em trabalhos anteriores ou que sabe que o analista do órgão questiona. O consultor descreve a situação; o assistente estrutura o dossiê; o consultor fixa o veredicto esperado.
• Casos sintéticos gerados a partir da regra. O assistente lê a referência (Termo de Outorga, manual, relação de itens) e propõe dossiês fictícios que testam cada regra pelas bordas: valor no limite dos 20%, data no último dia da vigência, item com nome parecido mas fora da relação, justificativa que cita cláusula inexistente. Esses casos não são reais e não precisam ser; servem para provar que o loop reage à regra. O consultor revisa cada um e define o veredicto esperado. Um caso sintético que o consultor não validou não entra na bancada.
• Erros reais do órgão. Toda diligência, glosa ou ressalva recebida da Finep vira um caso de teste permanente no loop que deveria ter pegado o problema. A mesma coisa vale para feedback do cliente ou do próprio consultor em revisão. Esse é o mecanismo de retroalimentação: o loop nunca repete um erro que o órgão já apontou, porque a bancada passa a exigir aquele acerto em toda versão seguinte.

A bancada é o que separa automação de risco. Sem ela, um ajuste de prompt para resolver um caso pode quebrar outro sem que ninguém perceba. Com ela, cada versão do loop prova, antes de rodar, que continua acertando tudo o que já acertou.

O tempo de fabricação de um loop novo ficou em torno de uma hora, incluindo bancada. O conhecimento do consultor entra por dois caminhos: como regra no prompt, quando é critério de julgamento, ou como checagem em código, quando é regra mecânica. Uma frase dita em conversa ("no interior é comum pagar antes de emitir a nota") vira uma melhoria registrada, uma regra, um caso de teste e uma versão nova do loop.

3.5 O papel da IA em cada etapa A IA aparece em dois lugares distintos, e vale separar:

• Como fabricante. Um assistente de código (ex. Claude ou GPT) conduz a entrevista das cinco decisões, gera spec, prompt, módulo e casos de teste, roda a bancada e registra o loop na biblioteca. Aqui a IA acelera a construção da ferramenta.
• Como julgadora. Dentro do loop, o modelo (Claude Opus, que foi o modelo utilizado) responde uma pergunta por dossiê. Aqui a IA executa o trabalho, mas cercada por código antes (dossiê) e depois (validação).

Essa separação é o que permite dizer onde a IA decide e onde não decide. No trabalho relatado, dos 1.200 registros processados, 1.145 (95,4%) foram resolvidos exclusivamente por regras. Só 55 (4,6%) chegaram ao modelo. Isso explica o custo e explica a rastreabilidade.

4. O fluxo, de ponta a ponta

Figura 1. Fluxo de um loop de prestação de contas. As três camadas (determinística, julgamento, rastreabilidade) se repetem em todos os loops; o que muda é a unidade de julgamento e o critério.

Lendo a figura de cima para baixo: as entradas são os documentos que a empresa já tem. A extração normaliza o formato do cliente e ancora os parâmetros do contrato em arquivo de referência. As checagens determinísticas resolvem a maior parte e produzem achados mecânicos com contrato fixo (id, campo, problema, valor). Só o que sobra vira dossiê e vai ao modelo, uma unidade por chamada. A saída do modelo é validada, e o que não passa vai para o consultor. Tudo grava em arquivo: log por unidade, CSV de veredictos, e, com isso, o formulário oficial, os ofícios e o relatório de achados para o cliente.

5. Setup da ferramenta

5.1 Requisitos mínimos Requisito O que foi usado no case Custo aproximado Linguagem e bibliotecas Python 3 com pandas, openpyxl e PyYAML Zero Modelo de linguagem Claude Opus via API, modo dossiê (uma chamada por unidade). Qualquer modelo com saída JSON estruturada serve R$ 9 a 16 por rodada completa Assistente de fabricação Claude (Claude Code e Claude Desktop) para gerar spec, prompt, módulo e casos de teste Assinatura plano Max 5x Registro e governança Notion com seis bancos ligados: Trabalhos, Atividades, Biblioteca de Loops, Execuções, Melhorias, Registros Plano gratuito ou básico Máquina Notebook comum. Nenhum processamento local pesado; o loop é I/O e chamadas de API Já disponível Referência de ancoragem Termo de Outorga, normas Finep e relação de itens convertidos para texto e YAML Tempo do consultor

5.2 Passo simplificado para fabricar um loop

• Responder as cinco decisões: o que se repete (unidade)? o que o modelo precisa ver (dossiê)? quais veredictos são permitidos e qual é a pergunta única? o que barra mecanicamente um veredicto errado? onde o resultado grava e quem consome?
• Gerar os artefatos a partir dos templates: spec, prompt, módulo de domínio e casos de teste.
• Rodar a bancada com os casos de teste. Meta: 100%. Falhou, ajusta prompt, dossiê ou validação e roda de novo.
• Executar em dado real, registrando a execução (data, versão, números, itens para revisão humana, link do registro).
• Evoluir: todo problema ou aprendizado vira melhoria registrada com gatilho (erro real, experiência do consultor, diligência do órgão, ideia) e incrementa a versão do loop.

6. Entradas, processamento e saída no trabalho real

6.1 Documentos de entrada Documento Papel no trabalho Planilha de controle da empresa (execução financeira por rubrica e item) Fonte primária de cada lançamento; alimenta todos os loops Extratos bancários da conta vinculada e da conta de contrapartida Conciliação e demonstração da contrapartida Notas fiscais, recibos e comprovantes de diárias e passagens Lastro documental por despesa Termo de Outorga e normas Finep Referência de ancoragem: rubricas, tetos, vigência, cláusulas Relação de itens aprovada e remanejamentos solicitados Base para conferir aderência e o limite de 20% Relatório técnico da execução Cruzamento entre execução física e financeira (metas com desvio)

6.2 Os loops fabricados para esta prestação de contas Loop Unidade de julgamento Números da execução De-para da DDR Cada lançamento da planilha do cliente mapeado para rubrica e alínea do formulário oficial Todo o universo de lançamentos Contrapartida demonstrada Cada mês de contrapartida (pró-labore, folha) contra o extrato 82 lançamentos, 17 meses, 50 unidades de débito, 6 achados (todos sobre competência de pró-labore) Revisor do remanejamento Cada item remanejado: justificativa, aderência e limite 67 itens, 33 achados determinísticos, 38 veredictos de LLM, 22 aceitos na validação, 16 para revisão humana Composição de diárias, passagens e locomoção Cada diária ou deslocamento contra comprovante e regra 45 itens, 4 alertas de risco (prestador PJ recebendo diária), 1 anomalia de data Folha de pontos para o parecer Cada afirmação do parecer de auditoria ancorada em achado ou veredicto Consolida os demais loops no relatório final

6.3 Um loop por dentro: o revisor do remanejamento Vale abrir um loop para mostrar que não há mágica. O revisor do remanejamento existe porque a empresa precisou mover recursos entre rubricas ao longo da execução, e cada movimento precisa de justificativa defensável e respeito ao limite de 20%.

• Unidade: um item remanejado (origem, destino, valor, justificativa da empresa).
• Camada determinística: o item existe na relação aprovada? O valor bate com a planilha? O acumulado de movimentos na rubrica ultrapassa 20%? A data está dentro da vigência? Aqui saíram 33 achados sem nenhuma chamada ao modelo.
• Dossiê: os campos do item, o trecho do Termo de Outorga sobre remanejamento e a descrição da rubrica de destino. Nada mais.
• Pergunta ao modelo: a justificativa apresentada sustenta o remanejamento diante do objeto do projeto e da regra citada? Veredictos possíveis, em lista fechada: sustenta, sustenta com ressalva, não sustenta, insuficiente para julgar. Justificativa obrigatória com fundamento, consequência e saída recomendada.
• Validação: id existe, veredicto está na lista, cláusula citada existe no arquivo de referência. Dos 38 veredictos, 22 passaram; 16 foram para o consultor, na maioria por citar cláusula fora da referência ou por justificativa sem os campos obrigatórios.
• Saída: CSV de veredictos, registro JSONL e um documento de ação para o cliente com cinco achados priorizados, cada um com fundamento, consequência e o que fazer.

O que o cliente recebeu não foi "a IA disse que está errado". Recebeu: item tal, valor tal, regra tal, consequência tal, faça isso. Com o registro de como cada conclusão foi produzida. É a diferença entre um chat e um papel de trabalho de revisor.

6.4 Entregas

• Rastreabilidade: registro JSONL por unidade julgada, com dossiê, prompt, resposta e resultado da validação. O registro foi desenhado com o rigor da perícia contábil: cada procedimento previsto na NBC TP 01 (R1) (CFC, 2020) tem um correspondente concreto no fluxo, como mostra a tabela abaixo.

Procedimento (s, itens 20 a 26) Como a norma o define Onde acontece no loop Exame Análise de livros, registros das transações e documentos Camada determinística: cada lançamento é lido e conferido contra extrato, nota e relação de itens Vistoria Verificação e constatação de situação, coisa ou fato Achado mecânico com contrato fixo (id, campo, problema, valor) Indagação Busca de informação com quem conhece o objeto Pergunta única ao dossiê e, quando o modelo não fecha, pergunta do consultor ao cliente, registrada como nota Investigação Pesquisa que traz ao laudo elementos que não estavam nos autos Cruzamento entre planilha, extrato e relatório técnico; metas com desvio Mensuração Quantificação física ou monetária Todo achado carrega valor e o total por rubrica é conciliado em planilha com fórmula conferível Tabela 4. Correspondência entre os procedimentos periciais da NBC TP 01 (R1) e as etapas do loop. A norma se dirige à perícia; aqui ela é usada como régua de rigor para um trabalho de revisão.

• Documentação: Biblioteca de Loops no Notion com spec, prompt, versão, status e casos de teste de cada loop; bancos de Execuções e Melhorias ligados ao trabalho.
• Papéis de trabalho: planilhas de composição por rubrica (resumo, detalhe, conciliação) com fórmulas conferíveis, geradas por código.
• Relatórios: DDR pronta para o formulário oficial, ofícios de esclarecimento e relatório de achados com prioridade e ação para o cliente.

7. Resultados medidos

7.1 Horas de auditoria, manual contra loops A medição cobre a execução completa do trabalho, com base em controles por planilha, documentos e extratos bancários, no período de 20 a 28 de agosto de 2026. As horas com loops foram apontadas por dia de trabalho, somando o tempo de execução de cada rodada (data e hora registradas automaticamente no banco de Execuções) e o tempo de revisão humana anotado pelo consultor ao fim de cada sessão. A coluna "manual" não foi medida neste trabalho: é a referência do autor para o mesmo escopo feito sem loops, em blocos de meio dia, com base em trabalhos anteriores de prestação de contas e auditoria de incentivos em estrutura de consultoria. Por isso os números manuais são redondos e devem ser lidos como ordem de grandeza, não como apontamento.

Frente de trabalho Manual (h) Com loops (h) Redução Relatórios e pareceres (DDR e ofícios) 32 8 75% Remanejamentos 16 4 75% Conciliações 24 8 67% Papéis de trabalho 16 6 63% Total 88 26 70% Tabela 2. Horas por frente. Total: 88 h manuais contra 26 h com loops, redução de 70,5%, ou 3,4 vezes mais rápido.

7.2 Processamento e custo Métrica Valor Registros processados 1.200 Chamadas à API do modelo 55 (4,6% dos registros) Tokens de entrada / saída 152 mil / 37 mil Modelo Claude Opus Custo de API por rodada completa R$ 9,00 a R$ 16,00 Tabela 3. O custo é baixo porque a maior parte dos registros nunca chega ao modelo: é resolvida pelas regras em código.

7.3 O que mudou de fato

• Cruzamentos, checagens e conferências que eram manuais passaram a ser automáticos, com o modelo como copiloto de análise apenas nos itens que exigem julgamento.
• Achados que teriam passado. Seis discrepâncias de competência de pró-labore, quatro prestadores PJ recebendo diária e uma anomalia de data foram identificados e tratados antes do protocolo, com nota explicativa em vez de ajuste silencioso no dado.
• Escala. O mesmo conjunto de loops serve a qualquer contrato de subvenção Finep com ajuste de referência; a fabricação de um loop novo leva cerca de uma hora.
• Estágio: a DDR foi protocolada e está em análise na Finep. O desfecho do órgão (aceite, diligência ou glosa) será incorporado como caso de teste permanente, seja qual for.

8. Replicabilidade: o que outra organização precisa

O método foi desenhado para não depender de plataforma proprietária. Para repetir o caminho:

• Uma pessoa que conheça a regra do instrumento. O loop não substitui esse conhecimento; ele o codifica. Os casos de teste e o critério de julgamento são do consultor.
• Python e uma chave de API. Sem infraestrutura dedicada. A infraestrutura de loop cabe em dois arquivos.
• Os documentos que já existem. Planilha de controle, extratos, notas, contrato. O adaptador de extração absorve o formato do cliente.
• Disciplina de bancada. Nenhum loop entra em produção sem casos de teste com veredicto humano. Esse é o passo que separa automação de risco.
• Um lugar para registrar. Biblioteca, execuções e melhorias. Pode ser Notion, planilha ou repositório; o que importa é versão e rastreabilidade.

Onde o método não serve: quando a unidade de julgamento é "o documento inteiro" (aí é chamada única, não loop) e quando o caminho da investigação é imprevisível, como uma resposta a diligência complexa, em que um agente com ferramentas dinâmicas pode fazer mais sentido. Para conferência de prestação de contas, o pipeline cobre o resto, mais barato e mais auditável.

Aprendizados que valem para quem for repetir

• A leitura da saída do modelo precisa de tolerância: modelos devolvem o JSON envolto em marcação de texto com frequência; um limpador em cascata na infraestrutura resolve para todos os loops de uma vez.
• A ancoragem na referência falha em detalhe pequeno: rubricas escritas por sigla numa referência e por nome na planilha derrubam a validação. Normalizar nos dois lados antes de comparar.
• Inconsistência no dado do cliente se reporta, nunca se corrige. Corrigir silenciosamente destrói a rastreabilidade e transfere responsabilidade indevida ao consultor.
• Fórmulas de planilha geradas por código precisam de intervalo explícito; soma de coluna inteira captura linhas de total e dobra o valor.

9. Lastro tecnológico e aderência ao tema

O valor do case não vem do modelo de linguagem em si. Vem da arquitetura que decide o que o modelo pode e não pode fazer. Sem a camada determinística, o custo seria vinte vezes maior e a saída indefensável. Sem a validação mecânica, cada veredicto exigiria releitura humana e o ganho de tempo desapareceria. Sem o registro por unidade, não haveria papel de trabalho e o consultor não poderia assinar. A tecnologia é o que permite que uma empresa de uma pessoa entregue, com rastreabilidade de auditoria, um serviço que antes exigia equipe. É também o que muda a forma de vender esse serviço: quando a conferência é feita por loops e o consultor entra só no julgamento, o que se contrata deixa de ser hora de trabalho e passa a ser o trabalho entregue, a prestação de contas conferida e protocolada. O Hub.Fomento já opera nessa lógica, de serviço entregue como software, em que o cliente paga pelo resultado e não pelo esforço.

Sobre o tema do Summit, "cooperar para competir em um mundo fragmentado": fomento público é cooperação entre Estado e empresa, e a prestação de contas é o ponto em que essa cooperação mais frequentemente falha, por fricção e não por má-fé. Rastreabilidade de dados e IA aplicada, dois eixos da chamada, são exatamente os instrumentos que reduzem essa fricção. O que se propõe aqui é uma forma de tornar a confiança entre agência e beneficiário verificável, item por item, a um custo que empresa pequena consegue pagar.

10. Equipe

Thiago Bionde de Araujo (Hub.Fomento): desenho do método, regra do instrumento, casos de teste, revisão humana e assinatura dos papéis de trabalho. Contador, com passagem por Big 4 em incentivos a P&D e atuação como Head de Fomento em operadora de saúde.

Empresa beneficiária (anonimizada): CEO e responsável financeiro forneceram documentos, validaram achados e executaram as correções antes do protocolo.

Ferramentas: Claude (Anthropic) como fabricante e julgador; Python, pandas, openpyxl; Notion como sistema de registro.

Hub.Fomento · Vitória, ES · Setembro de 2026. Documento preparado para o Call for Cases do MIT-ANPEI Brazil Summit 2026. Os dados do cliente beneficiário foram omitidos por decisão do autor; números, documentos e resultados são os do trabalho real.

Anexo A. Artefatos do loop, simplificados e anonimizados Cinco peças do revisor do remanejamento, reduzidas ao essencial para caber em uma página cada. Nomes, valores e cláusulas foram mascarados; a estrutura é a real.

A.1 Trecho da spec YAML loop: revisor_remanejamento versao: 0.4 unidade: item_remanejado dossie:

campos: [id, rubrica_origem, rubrica_destino, valor, justificativa_empresa] referencia: [termo_outorga.clausula_remanejamento, rubricas.descricao_destino] veredictos: [sustenta, sustenta_com_ressalva, nao_sustenta, insuficiente] justificativa_obrigatoria: [fundamento, consequencia, saida] checagens_deterministicas: [item_na_relacao, valor_bate_planilha, acumulado_rubrica_max_20pct, data_na_vigencia] validacoes_saida: [id_existe, veredicto_na_lista, clausula_na_referencia] destino: saidas/revisor_remanejamento/veredictos.csv

A.2 Prompt de julgamento Você é o revisor de remanejamentos de um contrato de subvenção Finep.

Responda UMA pergunta sobre o item abaixo: a justificativa apresentada sustenta o remanejamento diante do objeto do projeto e da regra citada?

Baseie-se apenas no dossiê. Não cite cláusula que não esteja nele.

Não faça contas: os valores já foram conferidos.

Responda somente em JSON: {"id": ..., "veredicto": <um da lista>, "fundamento": ..., "consequencia": ..., "saida": ...} Veredictos permitidos: sustenta | sustenta_com_ressalva | nao_sustenta | insuficiente

--- DOSSIÊ ---

{dossie}

A.3 Uma linha do registro JSONL (uma unidade julgada) {"id": "REM-014", "loop": "revisor_remanejamento", "versao": "0.4", "dossie": {"rubrica_origem": "Material de consumo", "rubrica_destino": "Serviços de terceiros PJ", "valor": 4830.00, "justificativa_empresa": "Análise laboratorial terceirizada", "clausula_ref": "Cl. 5ª, item 5.2"}, "checagens": {"item_na_relacao": true, "valor_bate_planilha": true, "acumulado_rubrica_max_20pct": true, "data_na_vigencia": true}, "resposta_modelo": {"veredicto": "sustenta_com_ressalva", "fundamento": "Serviço ligado à meta 3; cláusula 5.2 admite remanejamento até 20%", "consequencia": "Sem anuência prévia, exige nota explicativa na DDR", "saida": "Incluir nota e comprovante do serviço"}, "validacao": {"id_existe": true, "veredicto_na_lista": true, "clausula_na_referencia": true, "aceito": true}, "revisao_humana": null, "timestamp": "2026-08-22T14:31:07"}

A.4 Um caso de teste da bancada id: T-07 (sintético, validado pelo consultor) dossie: valor 12.400,00 de "Equipamentos" para "Diárias"; acumulado da rubrica destino chega a 23% do previsto; justificativa: "viagens não planejadas" esperado: nao_sustenta motivo: acumulado acima de 20% sem anuência; diária não substitui equipamento origem: regra do Termo de Outorga (limite de remanejamento) + experiência do consultor

A.5 Um achado do documento de ação para o cliente Achado 2 de 5 | Prioridade alta | Item REM-014 O que foi encontrado: remanejamento de R$ 4.830,00 de Material de consumo para Serviços de terceiros PJ, sem anuência prévia registrada.

Regra: Termo de Outorga, cláusula de remanejamento (limite de 20% por rubrica).

Consequência se nada for feito: glosa do valor na análise da DDR.

O que fazer: anexar nota explicativa à DDR e o comprovante do serviço; registrar o pedido de anuência para os próximos movimentos.

Rastro: registro JSONL REM-014, versão 0.4, 22/08/2026.

Referências AZEVEDO, C. A. R. S. Prestação de Contas de Convênios com Recursos do FNDCT na FINEP: Proposta de Orientações aos Convenentes. Dissertação (Mestrado Profissional em Administração Pública). FGV EBAPE, Rio de Janeiro, 2014. 84 f.

CONSELHO FEDERAL DE CONTABILIDADE. NBC TP 01 (R1): Perícia Contábil. Brasília, 2020.

ISSA, H.; SUN, T.; VASARHELYI, M. A. Research Ideas for Artificial Intelligence in Auditing: The Formalization of Audit and Workforce Supplementation. Journal of Emerging Technologies in Accounting, v. 13, n. 2, p. 1-20, 2016.

JI, Z. et al. Survey of Hallucination in Natural Language Generation. ACM Computing Surveys, v. 55, n. 12, p. 1-38, 2023.

KOKINA, J.; DAVENPORT, T. H. The Emergence of Artificial Intelligence: How Automation is Changing Auditing. Journal of Emerging Technologies in Accounting, v. 14, n. 1, p. 115-122, 2017.

LEWIS, P. et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems, v. 33, p. 9459-9474, 2020.

MOSQUEIRA-REY, E. et al. Human-in-the-loop machine learning: a state of the art. Artificial Intelligence Review, v. 56, p. 3005-3054, 2023.

ZHENG, L. et al. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. Advances in Neural Information Processing Systems, v. 36, 2023.

Documentos operacionais: Termo de Outorga de subvenção econômica (Finep, 2025) e Manual de Prestação de Contas de Subvenção Econômica da Finep, versão vigente na data do protocolo. O número do contrato é omitido para preservar a anonimização.