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, 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:

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.

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:

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:

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 (Claude) 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) 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, cerca de 1.145 foram resolvidos exclusivamente por regras. Só 55 chegaram ao modelo. Isso explica o custo e explica a rastreabilidade.

4. O fluxo, de ponta a ponta

Transcrição da figura

Conteúdo de imagem. Fluxo de um loop de prestação de contas: código decide o que dá para decidir, o modelo julga o que resta

CAMADA DETERMINÍSTICA (Python + pandas). Nenhum número vem do modelo.

1. Entradas

Planilha de controle do cliente Extratos bancários Notas fiscais e recibos Termo de Outorga (referência) Relação de itens aprovada

2. Extração e ancoragem

Adaptador lê o formato do cliente Normaliza rubricas (sigla e nome) Tetos, vigência e cláusulas vêm de arquivo de referência, nunca da memória do modelo

3. Checagens determinísticas

Somas, de-para, datas, duplicidade, limite de 20% de remanejamento, item fora da relação aprovada Se cabe numa regra de código, resolve aqui.

~95% dos 1.200 registros param neste passo

4. Montagem do dossiê

Um dossiê por unidade de julgamento (despesa, alínea, item) Só o mínimo suficiente: campos da unidade + trecho da referência Nunca a planilha inteira

Achados mecânicos Contrato fixo por checagem:

id, campo, problema, valor

Inconsistência se reporta, nunca se corrige no dado do cliente

CAMADA DE JULGAMENTO (LLM): uma pergunta por unidade, veredictos em lista fechada

Spec YAML + prompt de julgamento Papel, critério, formato JSON, veredictos permitidos e campos obrigatórios da justificativa

5. Julgamento pelo modelo

Uma chamada por dossiê, contexto constante 55 chamadas para 1.200 registros (4,6%)

6. Validação mecânica da saída

id existe? veredicto está na lista? soma bate?

cláusula citada existe na referência? Se não, rejeita

7. Revisão humana do consultor

Só o que o código e o modelo não fecharam.

O consultor assina; a máquina documenta.

RASTREABILIDADE E ENTREGA

Registro JSONL por unidade Dossiê, prompt, resposta, validação: papel de trabalho

CSV de veredictos e achados Alimenta o próximo loop e a composição da DDR

DDR, ofícios e relatório de achados Formulário oficial e documento de ação para o cliente

Biblioteca de Loops (Notion) Versão, execuções, melhorias, casos de teste 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 daí 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

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

6.2 Os loops fabricados para esta prestação de contas

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. Segue os procedimentos da norma técnica NBC TP 01 (exame, vistoria, indagação, investigação e mensuração), todos executáveis remotamente.

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. A coluna "manual" é a referência do autor para o mesmo escopo feito sem loops, com base em trabalhos anteriores de prestação de contas e auditoria de incentivos.

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

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.

Referência AZEVEDO, Carla Alessandra Rodrigues de Souza de. 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). Escola Brasileira de Administração Pública e de Empresas, Fundação Getulio Vargas, Rio de Janeiro, 2014. 84 f.

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.