Agente RaIA — Revisão Apoiada por Inteligência Artificial: relato de caso da construção no-code de um MVP de IA generativa para revisão de relatórios de auditoria interna

Agente RaIA — Revisão Apoiada por Inteligência Artificial: relato de caso da construção no-code de um MVP de IA generativa para revisão de relatórios de auditoria interna Resumo A revisão de relatórios de auditoria interna é um processo crítico para a qualidade, a rastreabilidade e a confiança das instâncias de governança. No fluxo atual, essa revisão é predominantemente manual, dependente da experiência individual dos revisores e sujeita a inconsistências de linguagem, retrabalho e riscos de não conformidade normativa. Este artigo relata o desenvolvimento e a implantação do Agente RaIA — Revisão Apoiada por Inteligência Artificial —, uma plataforma web criada como MVP. para apoiar a revisão preliminar de relatórios de auditoria interna, e a forma como esse MVP foi construído: por uma especialista de domínio, sem formação técnica, por meio de desenvolvimento no-code assistido por IA. A solução analisa documentos em cinco dimensões — ortografia, clareza, consistência, ausência de viés e conformidade normativa —, gera um score de conformidade de 0 a 100 e apresenta achados categorizados por severidade. O sistema está publicado e em uso de teste, com autenticação, controle de acesso por perfil, Base de Conhecimento normativa gerenciável, rastreabilidade parcial e mecanismo de feedback dos revisores — construído do zero, em poucos meses, por uma profissional sem formação em desenvolvimento de software. Uma conferência cruzada entre o banco de dados, o código-fonte, o histórico de commits e o PRD, com extração em 10 de setembro de 2026, confirmou essas capacidades, reconciliou divergências numéricas antes não explicadas e identificou pontos de ajuste a amadurecer antes de uma adoção institucional mais ampla. O caso evidencia o potencial da IA generativa como primeira camada de revisão técnica e do desenvolvimento no-code como via de redução da barreira técnica para especialistas de domínio, e é apresentado como um desenho preliminarmente alinhado a controles de governança de IA — não como conformidade certificada ou validada por terceiros.

Palavras-chave: auditoria interna; inteligência artificial; revisão assistida; LLM; governança de IA; human-in-the-loop; desenvolvimento no-code.

Introdução A qualidade final de um relatório de auditoria interna influencia diretamente a confiança depositada no trabalho da auditoria. Esses relatórios subsidiam decisões, registram achados, comunicam riscos, fundamentam recomendações e podem ser apreciados por instâncias superiores de governança, como Comitê de Auditoria, Diretoria Executiva, Conselhos e órgãos de controle externo. Por essa razão, a revisão de um relatório não se limita à correção gramatical: envolve clareza, consistência técnica, aderência normativa, imparcialidade de linguagem e conformidade com estruturas institucionais.

No processo descrito neste caso, a revisão de relatórios é predominantemente manual. Cada documento passa por leituras sucessivas, ajustes, devoluções e novas validações. Embora esse controle seja necessário, ele consome tempo especializado, gera retrabalho e permite que inconsistências formais ou normativas sejam identificadas apenas nas etapas finais. Um relatório pode atravessar até três ciclos de revisão, com cerca de cinco dias úteis por ciclo e até dez dias úteis no total para conclusão da análise. Esses números vieram da apresentação original do caso de uso, de 18 de dezembro de 2025. Tratam-se, portanto, de linha de base declarada pela autora, aparentemente fundamentada em conhecimento operacional, neste artigo como estimativa operacional preliminar, sujeita a validação por amostragem de relatórios e registros históricos, não como média histórica comprovada.

Esse cenário afeta diferentes atores. O auditor precisa produzir um texto claro, consistente e aderente às normas. O coordenador recebe documentos em diferentes níveis de maturidade e dedica parte relevante do tempo a ajustes formais, além da validação técnica. O Auditor Chefe precisa confiar que o relatório final está adequado, rastreável e pronto para tramitar em instâncias superiores. A consequência é a redução do tempo disponível para análise estratégica, o aumento do esforço operacional e o risco de inconsistência em documentos sensíveis.

Diante desse problema, foi concebido o Agente RaIA — Revisão Apoiada por Inteligência Artificial —, uma plataforma web de apoio à revisão de relatórios de auditoria interna, construída por uma especialista de domínio sem formação em desenvolvimento de software, com apoio de um agente de IA no-code.

É importante situar a origem dessa concepção. O RaIA nasceu como uma das quinze iniciativas propostas pela autora em um plano de trabalho para a Auditoria Interna, submetido em processo seletivo interno em outubro de 2025 — portanto, um documento de candidatura a uma posição de liderança da área, não um mandato institucional em exercício. A autora soma doze anos de experiência em auditoria interna, mas não integra operacionalmente essa área desde 2024, atuando desde então em estratégia institucional. Essa origem — candidatura, não mandato — é relevante para a leitura de todo o relato, em especial das seções de valor esperado e de dados de uso.

Pergunta orientadora deste relato: uma especialista de domínio, sem formação técnica, consegue conduzir — com apoio de um agente de IA no-code — a construção de uma solução de revisão assistida por IA que seja tecnicamente viável e compatível com os controles de governança exigidos por um ambiente regulado, mesmo sem evidência empírica de piloto totalmente consolidada? A conclusão retoma essa pergunta à luz do que foi efetivamente entregue, do que foi efetivamente medido e do que permanece em aberto.

Nota de transparência metodológica A autora deste relato é também idealizadora, responsável pela definição de requisitos e única desenvolvedora da solução por meio de ferramenta no-code. A autora não integra operacionalmente a Auditoria Interna desde 2024; o conceito do Agente RaIA nasceu como uma das quinze iniciativas propostas em um plano de trabalho elaborado pela autora para um processo seletivo interno, datado de 2 de outubro de 2025, e não como projeto comissionado pela liderança em exercício da Auditoria Interna.

Este artigo é avaliado pela própria idealizadora da solução, sem revisão técnica externa independente do código-fonte, da segurança ou dos controles de privacidade. Os dados de uso, a identificação normativa, o mecanismo de cálculo de score e os dados de proveniência técnica (versão do sistema, do prompt e do modelo) apresentados neste artigo resultam de uma conferência cruzada entre o banco de dados de produção, o código-fonte, o histórico de commits e o PRD, com extração de dados em 10 de setembro de 2026.

Objetivo do MVP O objetivo central do MVP foi demonstrar que uma solução baseada em IA generativa pode funcionar como primeira camada de revisão técnica de relatórios de auditoria interna. O sistema foi desenhado para identificar problemas relevantes de qualidade, reduzir o esforço manual das revisões preliminares e manter registro completo das análises realizadas. O sistema opera com banco de dados persistente, autenticação real, controle de perfis, integração com modelo de linguagem e fluxo de aprovação — o que o diferencia de uma prova de conceito isolada, ainda que, como este artigo detalha, nem toda regra documentada esteja hoje efetivamente aplicada no código e a publicação atual seja tecnicamente distinta de uma homologação formal.

O MVP não substitui a decisão humana. Toda saída da IA é tratada como sugestão. A aprovação final de um relatório permanece sob responsabilidade de um Coordenador ou do Auditor Chefe. Assim, o RaIA foi concebido como mecanismo de apoio ao julgamento especializado, não como automação decisória autônoma.

Descrição da solução O Agente RaIA é uma plataforma web na qual o auditor pode submeter um relatório por digitação direta ou por upload de arquivo nos formatos PDF, DOCX ou TXT. Após a submissão, a IA analisa o conteúdo do relatório em cinco dimensões: ortografia (erros de grafia, gramática e pontuação), clareza (objetividade, precisão e ausência de ambiguidade), consistência (coerência entre achados, evidências e recomendações), ausência de viés (linguagem imparcial, sem julgamentos subjetivos) e conformidade normativa (aderência às normas internas aplicáveis).

Como resultado, o sistema gera um score geral de conformidade entre 0 e 100, acompanhado de achados categorizados por tipo e severidade — crítico, alto, médio ou baixo. Cada achado inclui o trecho original, uma sugestão de melhoria e, quando aplicável, a referência normativa que fundamenta a recomendação. O desenho documentado do fluxo utiliza o score como critério de triagem: relatórios com pontuação igual ou superior a 80 avançariam para revisão humana; abaixo de 80, retornariam ao auditor para ajuste. Em nenhum caso a IA aprova o relatório — o score é elemento de apoio, não decisão final. Como detalhado nas Seções 7.1 e 7.2, porém, nem o cálculo do score nem essa regra de corte funcionam hoje como uma fórmula ou um roteamento determinístico e verificado; ambos dependem, em graus distintos, do próprio modelo de linguagem e de comportamento do código ainda não confirmado em produção. A Figura 1 ilustra a diferença entre o fluxo documentado e o fluxo hoje implementado.

Figura 1: Fluxo de roteamento documentado no PRD (verde) versus comportamento implementado no código (âmbar).

Transcrição da figura

Conteúdo de imagem. Fluxo documentado no PRD (roteamento por score)

Fluxo implementado no código (Seção 7.2)

Auditor submete relatório

IA analisa 5 dimensões + checklist

Score geral + achados por severidade

Seção 3

DOCUMENTADO NO PRD

Score ≥ 80 → fila de revisão humana

Score < 80 → retorna ao auditor

IMPLEMENTADO NO CÓDIGO

Toda análise concluída → mesma fila de revisão (score não roteia)

Revisão humana (Coordenador ou Auditor Chefe)

Decisão final: aprovação ou devolução (a IA nunca aprova) Essa lógica posiciona o RaIA como revisor técnico de primeira camada: analisa rapidamente pontos que exigiriam esforço humano preliminar, padroniza critérios de qualidade, indica trechos específicos para ajuste e registra o histórico das análises para fins de rastreabilidade. A descrição funcional completa do que foi entregue no MVP está consolidada no Quadro 6 para evitar repetição ao longo do texto.

Comparação com o estado da prática Para situar a contribuição do RaIA, é necessário compará-lo a alternativas já conhecidas, em vez de descrevê-lo isoladamente. Quatro categorias de solução competem, hoje, pelo mesmo problema: a revisão manual tradicional; corretores de texto genéricos (verificadores ortográficos e gramaticais de propósito geral); um LLM de uso geral, consultado sem base normativa própria; e ferramentas comerciais de GRC ou copilotos de auditoria, quando existentes no ambiente institucional.

Quadro 1: Comparação do RaIA com abordagens alternativas para o mesmo problema.

É importante precisar o que essa comparação significa e o que ela não significa. Ferramentas de GRC e copilotos de auditoria comerciais tipicamente oferecem workflow, trilha de auditoria e integrações corporativas — mas, mesmo quando configurados com as mesmas normas internas do RaIA, não foram desenhados para avaliar a qualidade textual e a conformidade linha a linha do conteúdo de um relatório específico: eles gerenciam o processo de auditoria, não escrutinam a prosa do relatório contra um checklist estrutural de nove seções e cinco dimensões de qualidade. Essa distinção — gestão de processo versus revisão de conteúdo — é o que um copiloto comercial genérico não replicaria automaticamente apenas por receber a mesma Base de Conhecimento normativa.

Três novidades distintas coexistem neste caso, e é importante não as tratar como uma só. A novidade de produto é modesta: cada componente técnico isolado do RaIA — LLM, prompt estruturado, injeção de normas no contexto, human-in-the-loop — é, individualmente, prática já consolidada no estado da técnica de 2025–2026 em aplicações de IA generativa para domínios regulados, como documentam Berger et al. (2023) para verificação de conformidade regulatória com LLMs em auditoria financeira, e Jezierski et al. (2025) em experimento controlado sobre o efeito de LLMs na qualidade de auditoria. A novidade está, isso sim, no arranjo desses componentes no domínio de auditoria interna de uma instituição financeira pública, com checklist estrutural de nove seções e triagem por score. A segunda novidade é de processo de desenvolvimento: a literatura sobre citizen development — o uso de plataformas low-code/no-code por profissionais sem formação técnica para construir software (Woo, 2020; Binzer & Winkler, 2022) — descreve exatamente o padrão observado aqui, embora normalmente aplicado a aplicações de negócio menos sensíveis do que um sistema de revisão de auditoria interna em instituição regulada; este caso estende essa literatura a um domínio de maior criticidade. A terceira é a adaptação institucional específica: o checklist de nove seções, os cinco eixos de análise e a Base de Conhecimento normativa foram desenhados para o contexto de auditoria interna bancária pública, e não seriam transferíveis sem adaptação a outro domínio.

O desenho de governança do RaIA dialoga com referenciais já publicados para IA em contextos regulados: o International Professional Practices Framework (IPPF), na edição de 2024 do The Institute of Internal Auditors (IIA), referência internacional para a prática de auditoria interna; a Lei Geral de Proteção de Dados (Lei nº 13.709/2018), aplicável ao tratamento de dados pessoais eventualmente presentes nos relatórios; a norma ISO/IEC 42001:2023, primeiro padrão internacional de sistema de gestão para IA; o NIST AI Risk Management Framework (AI RMF 1.0, 2023); o OWASP Top 10 for Large Language Model Applications, referência de segurança para aplicações baseadas em LLM; e a técnica de Retrieval-Augmented Generation, descrita originalmente por Lewis et al. (2020), da qual a arquitetura conceitual inicial do RaIA se aproximava antes de ser simplificada para injeção direta de contexto. A literatura acadêmica sobre uso prático de LLMs em auditoria interna — como os relatos de Emett et al. (2023) e Eulerich e Wood (2023) sobre o uso do ChatGPT no processo de auditoria interna de uma multinacional — reforça que a fronteira entre suporte e substituição do julgamento humano, central ao desenho do RaIA, é também um tema ativo de pesquisa empírica, não uma escolha isolada deste caso.

Arquitetura e implementação A proposta conceitual inicial previa um agente orquestrador coordenando agentes especializados para pré-processamento, conformidade normativa, linguagem e padronização, vieses e subjetividade, consistência interna e quality gate final, com recuperação de conhecimento normativo por RAG sobre índice vetorial. No MVP implementado, essa arquitetura foi simplificada: a lógica foi consolidada em uma análise única orientada por prompt estruturado, na qual o conteúdo integral dos documentos da Base de Conhecimento é injetado diretamente no prompt de cada análise, e o modelo retorna os cinco scores, o score geral e a lista de achados em formato estruturado.

Prompt único versus RAG e arquitetura multiagente: por que simplificar O Quadro abaixo compara as três abordagens arquiteturais consideradas, tornando explícitos os critérios de decisão que levaram à simplificação para prompt único.

Quadro 2: Comparação das três abordagens arquiteturais consideradas para o RaIA.

A escolha por injeção direta de contexto reduziu a complexidade de infraestrutura do MVP em troca das limitações técnicas listadas no Quadro 2, que devem ser reconhecidas explicitamente à medida que a Base de Conhecimento, a própria Base já contém duas instruções normativas federais distintas referidas genericamente como uma só no prompt, um sintoma concreto do risco de diluição de atenção discutido acima.

Stack tecnológica e proveniência técnica A definição de "produção" usada neste artigo se refere a uma publicação ativa na plataforma Replit (build com sucesso confirmado, acesso protegido por senha, commit de publicação 8b9f9bd de 15/06/2026), e não a uma homologação formal em ambiente de TI corporativo, nem a uso operacional consolidado por auditores em atividade. O serviço de publicação da Replit confirma a existência de um build ativo, mas não vincula tecnicamente esse build a um hash Git específico de forma auditável — 8b9f9bd é o melhor candidato documental disponível. O sistema também não possui uma tag de versão formal (ex.: v1.2.0) gravada na aplicação; "v1.2" é uma denominação do PRD, não uma versão técnica vinculada ao build. O commit mais recente do repositório, de 9 de setembro de 2026, é um script auxiliar de inspeção de PDF, sem alterações pendentes.

Quadro 3: Principais componentes técnicos do MVP publicado.

O prompt de análise também não possui identificador de versão formal — não há no banco de dados um campo prompt_version, hash do prompt, cópia do prompt usado em cada execução, nem registro do commit responsável por cada análise específica. A melhor identificação possível hoje é: prompt do RaIA no estado correspondente ao commit 86bbb1c (14/06/2026, aumento do limite de saída do modelo para 8.192 tokens), sem nomenclatura formal — uma denominação retroativa razoável seria raia-analysis-prompt-v1, ainda não adotada oficialmente. Quanto aos parâmetros do modelo, o sistema solicita claude-sonnet-4-6 com max_tokens de 8.192; temperature, top_p e top_k não são definidos explicitamente no código, o que significa que valem os padrões do provedor — padrões que não ficam registrados junto a cada análise, não há tentativa automática de nova chamada em caso de falha, e não há validação por schema da resposta recebida. Dos dez registros de análise em produção, apenas quatro têm o campo model_used preenchido (todos como claude-sonnet-4-6); os seis mais antigos são anteriores à implementação desse campo, e não é possível determinar retroativamente qual modelo foi efetivamente usado neles.

Base de Conhecimento e avaliação estrutural A solução se apoia em uma Base de Conhecimento gerenciável, contendo documentos normativos e templates de relatórios, carregados no sistema em 14 de junho de 2026. O upload e a exclusão de documentos são restritos ao Auditor Chefe; os demais perfis têm acesso de leitura. O prompt de análise diferencia documentos normativos de templates estruturais, o que permite que achados de conformidade normativa citem a fonte que os fundamenta — quando o prompt identifica corretamente qual norma se aplica.

Identificação verificada dos normativos Quadro 4: Identificação dos oito documentos na Base (sete normativos e um template), carregados em 14/06/2026.

Tabela 4 — A Base de Conhecimento cadastra, portanto, sete documentos normativos distintos — e não apenas os quatro citados nas primeiras versões deste artigo. Em especial, há duas instruções normativas federais distintas referidas genericamente como uma só "IN CGU" no PRD e no prompt de análise: atualizar o prompt para citar a instrução específica em cada critério é um ajuste simples e objetivo, já habilitado pelo fato de as duas normas estarem corretamente identificadas na Base de Conhecimento (tabela acima). Como as normas foram carregadas em 14/06/2026, análises anteriores a essa data provavelmente utilizaram uma base normativa resumida, escrita diretamente no código-fonte, e não os documentos completos da Base de Conhecimento — conclusão cronológica, não uma rastreabilidade persistida por execução, já que o sistema não registra quais documentos ou versões foram efetivamente usados em cada análise específica.

Avaliação estrutural Além da análise textual e normativa, o RaIA inclui uma avaliação estrutural: o prompt contém um checklist explícito de nove seções obrigatórias em um relatório de auditoria — Apresentação, Objetivo, Escopo, Metodologia, Conclusões, Observações ou Achados, Recomendações, Matriz de Risco e Conformidade com as normas. Seções ausentes ou incompletas geram achados da categoria estrutural, com severidade proporcional, e penalizam o score normativo.

Governança, segurança e privacidade O desenho de governança do RaIA parte de um princípio essencial: toda saída da IA é sugestão, nunca decisão. Esse princípio é operacionalizado por controles de fluxo, permissão e rastreabilidade: human-in-the-loop obrigatório (a aprovação de um relatório é sempre realizada por Coordenador ou Auditor Chefe; a IA não possui permissão para aprovar documentos); acesso baseado em perfis, com segregação funcional e middleware de autorização nas rotas protegidas; guardrails contra alucinação, com o prompt proibindo explicitamente a invenção de dados, evidências ou referências normativas ausentes no texto original; e rastreabilidade parcial de transições de status, incluindo, para quatro das dez análises registradas, o nome do modelo de IA utilizado.

Figura 2: O mesmo painel de controle, com escopo de dados diferente por perfil: o Auditor vê 8 relatórios (os seus); Coordenador e Auditor Chefe veem os 12 cadastrados. Nomes de usuários foram removidos das capturas por confidencialidade; apenas indicadores agregados são exibidos.

Transcrição da figura

Conteúdo de imagem. Visão do Auditor (8 relatórios visíveis)

RaIA Revisão Apoiada por IA

MENU PRINCIPAL

Painel Relatórios Base de Conhecimento

Auditor AP

Painel de Controle Visão geral dos seus relatórios de auditoria.

Total de Relatórios 0 este mês

Rascunho Aguardando envio para

Aguardando Revisão Analisados pela IA

Ajuste Solicitado Média de 1 ciclos

Aprovados Taxa de 25%

Visão do Coordenador (12 relatórios visíveis)

RaIA Revisão Apoiada por IA

MENU PRINCIPAL

Painel Relatórios Revisões IA Base de Conhecimento

Coordenador MC

Painel de Controle Visão geral de todas as auditorias e seus auditores.

Total de Relatórios 0 este mês

Rascunho Aguardando envio para

Aguardando Revisão Analisados pela IA

Ajuste Solicitado Média de 0.9 ciclos

Aprovados Taxa de 25%

Visão do Auditor Chefe (12 relatórios visíveis)

RaIA Revisão Apoiada por IA

MENU PRINCIPAL

Painel Relatórios Revisões IA Base de Conhecimento Usuários

Auditor Chefe DA

Painel de Controle Visão geral de todas as auditorias, auditores e coordenadores.

Total de Relatórios 0 este mês

Rascunho Aguardando envio para análise

Aguardando Revisão Analisados pela IA

Ajuste Solicitado Média de 0.9 ciclos

Aprovados Taxa de 25% Esses controles dialogam diretamente com referenciais de governança de IA já publicados. O Quadro abaixo relaciona cada controle implementado a categorias específicas de cinco referenciais: o NIST AI Risk Management Framework (AI RMF 1.0, 2023), organizado em quatro funções — Governar, Mapear, Medir e Gerenciar —; a ISO/IEC 42001:2023, primeiro padrão internacional de sistema de gestão para IA; o IPPF 2024 do IIA, referência de auditoria interna; a LGPD (Lei nº 13.709/2018); e o OWASP Top 10 for LLM Applications, referência de segurança para aplicações baseadas em LLM.

Quadro 5: Correspondência conceitual entre os controles do RaIA e cinco referenciais de governança de IA e auditoria. O Banco da Amazônia S.A. não adotou formalmente nenhum desses frameworks como base de certificação; a aderência aqui descrita é um desenho preliminarmente alinhado a controles, não o resultado de uma auditoria de conformidade independente.

Como o score e a severidade são calculados, e o que ainda falta formalizar O score de conformidade e a severidade dos achados são produzidos diretamente pelo modelo de linguagem, a partir de instruções textuais no prompt — não por uma fórmula numérica implementada no servidor. O prompt orienta o modelo a calcular os cinco eixos e um score geral como "média ponderada dos demais, com peso maior para o score normativo quando há seções ausentes"; o servidor recebe e persiste o número retornado, sem recálculo independente. A única regra de severidade formalizada no código é a de lacunas estruturais (seção ausente = severidade alta; incompleta = média); para as demais dimensões, a severidade é atribuída livremente pelo modelo. Formalizar essa fórmula e esse Quadro de severidade — hoje orientações textuais bem desenhadas, mas não auditáveis — é o próximo passo natural de maturação técnica do produto, e é o objeto do Apêndice Técnico (Parte C e D).

Como consequência, o score ainda não passou por um teste de concordância entre a avaliação da IA e o julgamento de um revisor humano especializado. A solução já inclui o mecanismo certo para isso — feedback estruturado por achado (Útil, não útil, Incorreto) —, mas a cobertura de uso até aqui ainda é pequena para sustentar essa validação de forma estatística.

Roteamento automático: o que está documentado e o que está em produção O PRD documenta uma regra de triagem por score — relatórios com 80 pontos ou mais avançam direto para revisão humana; abaixo disso, retornam ao auditor. A conferência cruzada com o código-fonte mostrou que essa regra ainda não foi ligada ao fluxo de roteamento automático: hoje, toda análise concluída segue para a mesma fila de revisão, independentemente do score (Figura 1). É um ajuste de implementação relativamente simples e já bem especificado, tratado no roadmap junto com a formalização da fórmula de score.

Um segundo ponto de rastreabilidade, identificado na verificação técnica mais recente, diz respeito ao comportamento do sistema quando a resposta da IA não contém um JSON interpretável: o sistema substitui automaticamente o resultado por um score de 70 em todos os cinco eixos, score global 70, nenhum achado e um resumo genérico — mas essa substituição não fica explicitamente registrada como tal. Um revisor humano vendo esse resultado não tem como distinguir, hoje, um score 70 genuíno de um score 70 gerado por falha de interpretação, o que é um risco concreto de falsa sensação de conformidade.

Quanto à privacidade, o PRD atribui ao Replit AI Integrations a garantia de que dados não são usados para treinamento. A documentação pública da Replit (consultada em 12 de setembro de 2026) confirma que, para contas self-service, endpoints pagos têm o treinamento desabilitado por padrão, enquanto endpoints gratuitos podem ter o treinamento habilitado e publicar prompts e respostas em conjuntos de dados públicos; contas Enterprise podem restringir-se a endpoints com Zero Data Retention (ZDR). Nenhuma dessas condições confirma, isoladamente, qual configuração específica se aplica à conta usada pelo RaIA — a formulação tecnicamente correta, até confirmação em contrato, é que as condições de retenção e uso para treinamento dependem do plano contratado e da configuração do endpoint efetivamente em uso.

A anonimização de dados pessoais antes do envio ao modelo e alertas automáticos para informações sensíveis foram identificados como necessários e permanecem planejados apenas para a versão pós-piloto — o que significa que, até lá, dados pessoais eventualmente presentes em um relatório trafegam para o provedor de IA sob as condições ainda não integralmente verificadas descritas acima, ponto relevante à luz da LGPD.

Desenvolvimento no-code assistido por IA A cronologia do caso ajuda a situar o que foi de fato construído e quando. Em outubro de 2025, o RaIA existia apenas como ideia — uma das quinze iniciativas de um plano de candidatura a processo seletivo interno de Auditoria Interna, sem código, protótipo ou detalhamento técnico. Em dezembro de 2025, a autora produziu uma apresentação conceitual detalhando problema, personas, arquitetura pretendida e stack tecnológica hipotética, já fora do contexto do processo seletivo. Entre essa apresentação e a publicação de 15 de junho de 2026, o MVP foi efetivamente implementado em código, por meio da abordagem no-code descrita a seguir — um intervalo de aproximadamente seis meses entre a ideia e um sistema publicado.

Um aspecto distintivo do caso é a forma de construção do MVP. A aplicação foi desenvolvida por meio de uma abordagem no-code assistida por IA utilizando o Replit Agent para gerar e evoluir a aplicação a partir de instruções em linguagem natural. É necessário precisar o que essa expressão significa: "no-code", aqui, descreve a ausência de escrita manual de código pela autora — não a ausência de código na solução resultante. O RaIA é uma aplicação com código-fonte completo em React, Express e SQL, gerado por um agente de IA a partir de instruções da autora; a literatura sobre citizen development chama esse papel de "citizen developer" — um profissional de domínio, sem formação técnica formal, que usa plataformas low-code/no-code para construir software (Woo, 2020; Binzer & Winkler, 2022). A autora, Gerente de Estratégia Institucional e sem formação em desenvolvimento de software, conduziu a construção da aplicação sem escrever código manualmente. Seu papel foi o de arquitetar o produto: definir requisitos, personas, regras de negócio, critérios de qualidade e controles de governança, traduzindo essas decisões em instruções ao agente de IA responsável pela geração do código.

Desafios técnicos superados durante a construção A apresentação conceitual original de dezembro de 2025 propunha uma arquitetura sobre Copilot Studio, Azure OpenAI, Power Automate, SharePoint e ServiceNow. O MVP efetivamente construído foi implementado em código, via Replit Agent — uma mudança de rota que, por si só, já exigiu da autora aprender a dialogar com um agente de IA em nível de arquitetura de software. Ao longo da construção, sem formação técnica prévia e sem equipe de engenharia, a autora identificou e resolveu, entre outros, os seguintes desafios:

Saída da IA truncada, corrigida elevando o limite de tokens de saída para 8.192, o que eliminou JSON inválido e achados vazios;

Equilíbrio entre velocidade e completude da resposta da IA, calibrado por tentativa e ajuste até um ponto estável;

Persistência de sessão em produção, resolvida ajustando a configuração de confiança no proxy da plataforma para permitir o cookie seguro;

Fluxo de criação de usuários e atribuição de perfis, incluindo o perfil de Auditor Chefe, ajustado e testado em produção;

Regras de permissão e visibilidade entre perfis — o que cada papel pode ver e fazer — refinadas em várias iterações;

Interface totalmente em português, com mensagens de progresso e indicação visual do andamento da análise;

Hierarquia de informação da tela de revisão ajustada, com o Score Global reposicionado acima do detalhamento por eixo, após teste de usabilidade.

Um ponto que este relato não conseguiu resolver integralmente, mesmo após a verificação técnica mais recente, é a ausência de um identificador único de execução (analysis_run_id) que amarre, para cada análise, a versão do prompt, os parâmetros do modelo e os documentos normativos efetivamente usados. É, provavelmente, a lição de instrumentação mais transferível para outro especialista de domínio que queira repetir o método: registrar proveniência desde a primeira versão, antes que o volume de análises torne a reconstrução retroativa inviável.

Escopo funcional entregue O MVP evoluiu em três ciclos. O Quadro 6 consolida o que foi entregue em cada versão.

Quadro 6: Escopo entregue por versão do MVP ("v1.2" é denominação do PRD, sem tag técnica correspondente).

Ficaram deliberadamente fora do escopo do MVP: aprovação totalmente automatizada sem intervenção humana; integração com sistemas corporativos externos (SEI, SAP, GRC); edição colaborativa em tempo real; dashboards analíticos avançados; notificações automáticas; assinatura digital; exportação do laudo em PDF; e suporte a múltiplos idiomas. Esses itens são tratados como evolução planejada, não como falhas do escopo inicial.

Dados de uso registrados em produção O que os registros de produção mostram Os números a seguir foram obtidos por conferência cruzada entre o banco de dados de produção, o código-fonte, o histórico de commits e o PRD, com extração de dados em 10 de setembro de 2026.

Quadro 7: Indicadores de uso registrados no ambiente publicado, extração de 10/09/2026.

Classificação dos 12 relatórios: reais versus teste/demonstração O banco de dados não possui, hoje, um campo formal que distinga relatório real de teste ou demonstração; a classificação abaixo foi feita pelas características do conteúdo (extensão, estrutura institucional, título) e deve ser lida como estimativa qualificada, não como dado gravado no sistema.

Quadro 8: Reconciliação da origem dos 12 relatórios e das 10 análises, com base em classificação qualitativa do conteúdo.

O Quadro a seguir reconcilia, num único quadro, os números que apareciam de forma dispersa nas Tabelas 5 e 6, explicitando a relação entre eles:

Quadro 9: Quadro único de reconciliação numérica. As relações entre "solicitações" e "aprovações" são inferidas da ordem esperada do fluxo (Figura 1), não de uma chave técnica persistida entre essas tabelas.

O sistema não possui um campo específico de duração da análise; um indicador aproximado foi calculado pareando, para cada relatório, os eventos report_submitted e review_completed em ordem cronológica (via ROW_NUMBER particionado por relatório), sem depender de um identificador único de execução — método e consulta SQL completos estão no Apêndice Técnico (Parte F). Foram pareados 13 ciclos: média bruta de 202 segundos (≈3min22s), mediana de 90 segundos, e média de 81 segundos desconsiderando registros zerados e acima de dez minutos. Esse número deve ser tratado como estimativa técnica aproximada, não como KPI auditado: há um par com duração zero e dois pares acima de dez minutos, além de mais eventos de conclusão do que análises persistidas — indício de dados demonstrativos, inconsistências históricas ou pareamento imperfeito entre ciclos, já que o pareamento por ordem cronológica desloca os pares seguintes caso falte um evento de início ou conclusão.

Dos 113 achados gerados, 4 foram avaliados pelos revisores — todos marcados como "Útil", nenhum como "Não útil" ou "Incorreto", nenhum com comentário textual —, o que corresponde a uma cobertura de feedback de 3,5% dos achados. Esses quatro achados fazem parte do caso real apresentado na sequência.

Os testes de uso do MVP ainda estão em andamento, o que explica o tamanho atual da amostra. São números reais registrados no banco de produção; o banco ainda não diferencia formalmente etapas de teste, demonstração e uso efetivo, e há timestamps repetidos e quantidades divergentes entre relatórios, análises e eventos, o que recomenda cautela na leitura de qualquer indicador antes de o piloto avançar.

Um caso real com atuação humana Para tornar concreto o mecanismo human-in-the-loop, esta seção apresenta um caso real e anonimizado, com participação de uma pessoa com perfil de Auditora Chefe. Trata-se de um relatório institucional importado (auditoria operacional, mais de 50 mil caracteres), analisado pelo modelo claude-sonnet-4-6, com score global 82 e 23 achados gerados. A Auditora Chefe avaliou individualmente quatro achados, classificando todos como "Útil", e aprovou o relatório cerca de 18 minutos após a conclusão da análise pela IA.

Quadro 10: Scores apresentados à revisora no caso real anonimizado.

Achado 1 — Referência normativa incorreta (severidade alta). O relatório citava "NP 001 — Auditoria Interna" ao descrever o acompanhamento de planos de ação; a IA identificou que a norma vigente e aplicável é a NP 006, não a NP 001, e sugeriu a substituição após confirmação. A Auditora Chefe marcou o achado como útil.

Achado 2 — Item normativo potencialmente incorreto (severidade média). Um critério citava "NP 001 — item 2.1.1"; a IA apontou que o assunto tratado provavelmente pertence à NP 006, recomendando confirmação da norma correta. Marcado como útil.

Achado 3 — Valores financeiros com sinais inconsistentes (severidade alta). O texto usava valores negativos para representar uma economia, o que a IA identificou como contraditório, recomendando revisão dos sinais e conciliação com as horas informadas. Marcado como útil.

Achado 4 — Divergência de horas planejadas e realizadas (severidade média). O relatório mencionava 138 horas planejadas, 386 horas realizadas e 1.074 horas no planejamento anual, sem explicar a diferença; a IA recomendou esclarecer se houve mudança de escopo ou de equipe. Marcado como útil, pouco antes da aprovação final.

O sistema comprova que uma pessoa com perfil de Auditora Chefe acessou a análise, avaliou individualmente os quatro achados, considerou todos úteis e tomou a decisão final de aprovação. O sistema não comprova se os quatro pontos foram corrigidos antes da aprovação, se os outros 19 achados foram revisados, por que o relatório foi aprovado apesar de dois achados classificados como altos, ou se houve alteração do documento fora do sistema — a aprovação não permite afirmar que todos os achados foram corrigidos ou validados, apenas que quatro possuem feedback explícito registrado. O caso ilustra, de forma concreta, tanto o valor do mecanismo (identificação de referências normativas incorretas e inconsistências numéricas que poderiam passar despercebidas) quanto seu limite atual de rastreabilidade (feedback parcial, sem confirmação de correção).

Valor esperado A introdução do RaIA como camada de revisão preliminar tem, como valor esperado, a redução do esforço dedicado a revisões formais e retrabalho. O material de dezembro de 2025 estima redução potencial de até 70% do esforço nas revisões preliminares e redução do ciclo total de revisão de cerca de cinco dias por etapa para até dois dias no estado futuro. Esses números são estimativa operacional preliminar apresentada, os dados de uso hoje disponíveis são reais, porém pequenos e ainda em fase de testes.

Quadro 11: Métricas de sucesso definidas para acompanhamento futuro. O indicador aproximado de tempo de análise já se aproxima da meta de 30s, mas não é diretamente comparável por não ser um KPI auditado.

O valor esperado varia por perfil. Para o auditor, o sistema oferece feedback imediato e objetivo. Para o coordenador, promete reduzir retrabalho e liberar tempo para validação técnica. Para o Auditor Chefe, reforça padronização e rastreabilidade. Para a organização, aponta para eficiência operacional, redução de risco e fortalecimento de governança. A realização desse valor, entretanto, depende de piloto institucional com amostra maior e classificação adequada dos dados de uso.

Pontos de atenção e limitações A conferência cruzada confirmou que o MVP funciona e está em produção, com a maior parte dos controles de governança descritos efetivamente implementada. Também mapeou pontos que precisam amadurecer antes de adoção institucional ampla.

Quadro 12: Maturidade consolidada: requisito, evidência e estado, substituindo menções dispersas ao longo do texto.

Nenhum desses pontos invalida o que já está entregue: autenticação, perfis, Base de Conhecimento, checklist estrutural e fluxo human-in-the-loop funcionam como descrito, e o caso real demonstra o mecanismo em uso efetivo. Eles definem, com precisão, o que falta para que a afirmação de viabilidade avance de técnica e preliminar para institucionalmente validada.

A autora deste artigo é também a idealizadora, responsável pelos requisitos e única desenvolvedora da solução relatada. Além disso, os 12 relatórios cadastrados e os 8 usuários registrados foram, foram selecionados ou criados pela própria autora para fins de teste e demonstração. A autora testou o sistema sob mais de um perfil, com contas distintas — como Coordenadora e como Auditora Chefe, responsável pela aprovação do caso relatado.

Em razão dessas limitações, a afirmação de que o MVP demonstra "viabilidade" deve ser lida com precisão: o que este relato documenta é um desenho preliminarmente alinhado a controles de governança, com viabilidade técnica parcialmente verificada por conferência cruzada — não uma conformidade certificada, validada de forma independente ou confirmada contratualmente.

Lições aprendidas e condições de transferência O caso oferece elementos reaproveitáveis por outra área de auditoria ou controle: o desenho de governança (HITL obrigatório, segregação por perfil, base normativa curada por perfil único, feedback estruturado por achado); o checklist estrutural de nove seções; a decisão — e o trade-off associado (Tabela 2) — de simplificar a arquitetura de multiagentes com RAG para prompt único com normas injetadas; e a lista de desafios técnicos superados na construção no-code, provavelmente a lição mais diretamente transferível deste relato para outro especialista de domínio que queira repetir o método.

Limites de aplicabilidade Quadro 13: Limites de aplicabilidade do desenho do RaIA a outros contextos

Custo operacional recorrente: estimativa ilustrativa Usando o preço público do modelo utilizado (claude-sonnet-4-6: US$ 3,00 por milhão de tokens de entrada e US$ 15,00 por milhão de tokens de saída) e supondo, de forma ilustrativa, cerca de 40 mil tokens de contexto normativo (Base de Conhecimento integral), 12 mil tokens de relatório (médio, dentro da faixa de 25 a 104 mil caracteres observada) e 3 mil tokens de resposta estruturada, cada análise custaria, aproximadamente, US$ 0,20 (cerca de US$ 0,16 de entrada mais US$ 0,045 de saída). Para as 10 análises registradas, isso equivaleria a cerca de US$ 2 — um valor baixo em termos absolutos, mas com um driver de custo relevante: como a Base de Conhecimento inteira é reenviada em toda análise, o custo de entrada cresce de forma aproximadamente linear com o número de documentos normativos cadastrados, e não apenas com o volume de relatórios analisados. Uma área com uma Base de Conhecimento cinco vezes maior teria, sob esta mesma estimativa, um custo de entrada por análise cerca de cinco vezes maior.

Roteiro de implantação e gestão de adoção Um roteiro de implantação transferível para outra área ou instituição incluiria, no mínimo, as etapas a seguir.

Quadro 14: Roteiro de implantação com etapas, responsáveis, controles mínimos e critérios de interrupção.

Quanto ao comportamento esperado em áreas com base normativa menos formalizada do que a Auditoria Interna a expectativa razoável é que o RaIA perca precisão proporcionalmente à informalidade da base: sem normas identificadas por número e data, o prompt não tem como citar uma referência verificável, e os achados de conformidade normativa tenderiam a ficar genéricos ou a não ser gerados. Nesses contextos, o primeiro investimento recomendado não é o RaIA em si, mas a curadoria normativa que o antecede — uma lição de transferência tão importante quanto o desenho técnico do sistema.

Roadmap A versão 1.3, prevista para o pós-piloto, contempla anonimização de dados pessoais, alertas para conteúdo sensível, exportação do laudo em PDF e notificações por e-mail. Também devem ser priorizadas a ativação do roteamento automático por score e a formalização da fórmula de cálculo, por serem elementos fundamentais para confiabilidade.

A versão 2.0 prevê integração com sistemas corporativos, como SEI, SAP e GRC, dashboards analíticos avançados, templates por tipo de auditoria e análise de risco baseada em histórico de achados. Como melhorias futuras, o material indica edição colaborativa em tempo real, assinatura digital, API pública, suporte multilíngue, modelo de IA ajustado com corpus interno e aprendizado contínuo com base no feedback dos revisores.

Conclusão Retomando a pergunta orientadora deste relato — se uma especialista de domínio, sem formação técnica, consegue conduzir a construção de uma solução de revisão assistida por IA tecnicamente viável e compatível com controles de governança de um ambiente regulado —, a resposta é: parcialmente sim, com ressalvas importantes. O MVP está publicado, com autenticação, controle de perfis, Base de Conhecimento normativa identificada, checklist estrutural, feedback de revisores e fluxo human-in-the-loop demonstrado em um caso real, construído inteiramente por meio de desenvolvimento no-code assistido por IA em poucos meses, sem equipe de engenharia. A conferência cruzada realizada para este artigo confirma que a maior parte dessas capacidades está, de fato, presente no sistema.

O mesmo exercício de verificação mapeou um conjunto de pontos a amadurecer antes de uma adoção institucional mais ampla — consolidados no Quadro 12 — entre eles a ativação do roteamento automático por score, a formalização da fórmula de cálculo, a rastreabilidade completa de modelo e prompt por análise, e a confirmação contratual das condições de privacidade. A descrição mais precisa do estado atual não é "viabilidade demonstrada", mas compatibilidade parcial: um desenho preliminarmente alinhado a controles de governança de IA reconhecidos, ainda sem validação independente, sem confirmação contratual de privacidade e sem patrocínio institucional formal.

A principal contribuição do caso está em combinar um desenho de governança compatível com a criticidade da auditoria interna e um método de construção — o desenvolvimento no-code por especialista de domínio, no sentido descrito pela literatura de citizen development — que reduz a barreira técnica entre identificar um problema institucional e entregar uma solução funcional, incluindo o relato honesto dos desafios técnicos superados no caminho e de um caso real de uso do mecanismo human-in-the-loop. Vale registrar também o contexto de origem: o RaIA nasceu em outubro de 2025 como uma entre quinze iniciativas de um plano de candidatura da autora a um processo seletivo interno, não como projeto comissionado pela liderança em exercício da Auditoria Interna — a autora não integra operacionalmente essa área desde 2024, e este artigo carece de revisão técnica externa independente. Os próximos passos naturais são a implementação dos itens do Quadro 12, seguindo o roteiro do Quadro 14, e a consolidação de um piloto institucional com patrocínio formal e avaliação por terceiros, para transformar a hipótese de valor já demonstrada tecnicamente em resultado validado.

Referências THE INSTITUTE OF INTERNAL AUDITORS (IIA). International Professional Practices Framework (IPPF), edição 2024 — Global Internal Audit Standards, vigente desde 9 de janeiro de 2025. Disponível em: https://www.theiia.org/en/standards/international-professional-practices-framework/. Acesso em: 12 set. 2026.

BRASIL. Lei nº 13.709, de 14 de agosto de 2018 (Lei Geral de Proteção de Dados Pessoais — LGPD).

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system.

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). AI Risk Management Framework (AI RMF 1.0), 2023.

OWASP FOUNDATION. OWASP Top 10 for Large Language Model Applications, versão vigente em 2025.

LEWIS, P. et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS, 2020.

WOO, M. The rise of no/low code software development — no experience needed? Engineering (Beijing), v. 6, n. 9, p. 960–961, 2020. DOI: 10.1016/j.eng.2020.07.007.

BINZER, B.; WINKLER, T. J. Democratizing Software Development: A Systematic Multivocal Literature Review and Research Agenda on Citizen Development. In: International Conference on Software Business. Cham: Springer, 2022. p. 244–259.

EMETT, S. A.; EULERICH, M.; LIPINSKI, E.; PRIEN, N.; WOOD, D. A. Leveraging ChatGPT for Enhancing the Internal Audit Process – A Real-World Example from a Large Multinational Company. SSRN Working Paper nº 4514238, 2023.

EULERICH, M.; WOOD, D. A. A Demonstration of How ChatGPT Can be Used in the Internal Auditing Process. SSRN Working Paper nº 4519583, 2023.

BERGER, A.; HILLEBRAND, L.; LEONHARD, D.; DEUSSER, T.; DE OLIVEIRA, T. B. F.; DILMAGHANI, T.; KHALED, M.; KLIEM, B.; LOITZ, R.; BAUCKHAGE, C. et al. Towards automated regulatory compliance verification in financial auditing with large language models. In: 2023 IEEE International Conference on Big Data (BigData). IEEE, 2023. p. 4626–4635.

JEZIERSKI, M.; KALTENPOTH, S.; MÜLLER, O.; WEISSENBERGER, B. E. The Effect of Large Language Models on Audit Quality: Causal Evidence from a Randomized Field Experiment. SSRN Working Paper nº 6095166, 2025.

REPLIT. AI Integrations — documentação oficial. Disponível em: https://docs.replit.com/replitai/replit-ai-integrations. Acesso em: 12 set. 2026.

REPLIT. Information Security — documentação oficial. Acesso em: 12 set. 2026.

BANCO DA AMAZÔNIA S.A. NP 006 — Auditoria Interna. Norma de Procedimento, ID documental 6385, revisão 3. Vigência: 1º de novembro de 2018.

BANCO DA AMAZÔNIA S.A. POL 001 — Política de Auditoria Interna. ID documental 6829, versão 3. Publicação: 16 de março de 2022. Classificação: público interno.

BANCO DA AMAZÔNIA S.A. Regimento Interno da Auditoria Interna. ID documental 6850, versão 3. Publicação: 16 de março de 2022.

BANCO DA AMAZÔNIA S.A. Código de Ética da Auditoria Interna. ID documental 6644, versão 3. Publicação: 31 de dezembro de 2020.

BRASIL. Instrução Normativa SFC nº 3, de 9 de junho de 2017. Secretaria Federal de Controle Interno / Ministério da Transparência e Controladoria-Geral da União. Aprova o Referencial Técnico da Atividade de Auditoria Interna Governamental do Poder Executivo Federal. Publicação: 12 de junho de 2017.

BRASIL. Instrução Normativa Conjunta MP/CGU nº 1, de 10 de maio de 2016. Diário Oficial da União, 11 de maio de 2016, Edição 89, Seção 1, p. 14. Dispõe sobre controles internos, gestão de riscos e governança no âmbito do Poder Executivo federal.

APÊNDICE TÉCNICO

Este documento reúne, em formato reutilizável, três artefatos citados no artigo principal: (A) uma versão de referência do prompt estruturado de análise, reconstruída a partir da documentação do PRD e do código para fins de reuso e auditoria — não uma cópia literal do prompt em produção; (B) o checklist estrutural de nove seções, já implementado no MVP; e (C) uma proposta de formalização do esquema de severidade, respondendo diretamente ao ponto de atenção relativo a severidade das dimensões não estruturais ser atribuída livremente pelo modelo, sem tabela auditável. Itens marcados como "implementado" refletem o comportamento verificado do sistema; itens marcados como "proposta" são formalizações sugeridas por este anexo, ainda não aplicadas em produção.

A. Prompt Estruturado de Análise — Versão de Referência O prompt abaixo consolida, em um único template reutilizável, a estrutura documentada do Agente RaIA — papel do modelo, entradas, tarefa, checklist estrutural, guardrails e formato de saída —, incorporando duas correções já recomendadas no artigo principal: (1) a exigência de citar a norma específica (em vez de "IN CGU" genérica) e (2) a aplicação do esquema de severidade formalizado na Parte C deste anexo, em vez de severidade livre.

Template A: prompt de referência, com as duas correções já incorporadas.

PAPEL Você é um revisor técnico de relatórios de auditoria interna. Sua função é identificar problemas de forma, consistência e conformidade normativa — nunca aprovar, reprovar ou substituir o julgamento de um revisor humano. ENTRADAS - relatorio_texto: conteúdo integral do relatório submetido pelo auditor - base_conhecimento_normas: lista de normas cadastradas, cada uma com {norma_id, titulo, tipo, data_vigencia, conteudo} - base_conhecimento_templates: estrutura e redação padrão esperadas TAREFA Analise relatorio_texto em cinco dimensões e produza um achado para cada problema identificado: 1. ortografia — grafia, gramática, pontuação 2. clareza — objetividade, precisão, ausência de ambiguidade 3. consistencia — coerência entre achado, evidência e recomendação 4. ausencia_de_vies — linguagem imparcial, sem juízo subjetivo 5. conformidade_normativa — aderência às normas em base_conhecimento_normas CHECKLIST ESTRUTURAL (obrigatório) Verifique a presença e completude de cada uma das nove seções listadas na Parte B deste anexo. Seção ausente ou incompleta gera achado de categoria "estrutural", com severidade conforme a Parte B. REGRAS (guardrails) - NUNCA invente dado, evidência ou referência normativa ausente no relatorio_texto. Se uma seção esperada não existir, aponte a lacuna — não a preencha. - Toda referência normativa em um achado DEVE citar norma_id exato de base_conhecimento_normas (ex.: "IN SFC nº 3/2017", nunca "IN CGU" genérico). Se duas normas tratarem do mesmo tema, cite ambas e indique qual se aplica ao achado específico. - Atribua severidade a cada achado seguindo, sem exceção, a matriz da Parte C deste anexo — não decida severidade livremente. - Não avalie ou comente sobre pessoas; avalie apenas o texto. FORMATO DE SAÍDA (JSON) { "scores": { "ortografia": 0-100, "clareza": 0-100, "consistencia": 0-100, "ausencia_de_vies": 0-100, "conformidade_normativa": 0-100 }, "score_geral": 0-100, "formula_score_geral": "ver Parte D deste anexo", "achados": [ { "dimensao": "ortografia|clareza|consistencia|ausencia_de_vies| conformidade_normativa|estrutural", "severidade": "baixa|media|alta|critica", "trecho_original": "string", "sugestao": "string", "norma_id": "string ou null", "justificativa_severidade": "critério da matriz da Parte C usado" } ] } B. Checklist Estrutural de Nove Seções Checklist já implementado no MVP. Cada seção ausente ou significativamente incompleta gera um achado estrutural, com severidade conforme a coluna à direita.

Quadro B: checklist estrutural. "Ausente" = seção não existe no relatório; "Incompleta" = seção existe mas não cumpre o critério de verificação.

C. Esquema de Severidade — Proposta de Formalização O artigo principal constatou que apenas a severidade estrutural é objetivamente implementada; para as demais quatro dimensões, o modelo escolhe a severidade livremente, sem tabela que vincule tipo de problema, materialidade, risco e probabilidade a um nível resultante. Esta seção formaliza esse quadro para uso — e teste de concordância — a partir de agora.

Definição geral dos níveis Quadro C.1: Definição geral de severidade, independente da dimensão.

Matriz por dimensão Quadro C.2: critérios de severidade por dimensão, referenciáveis pelo campo "justificativa_severidade" do Template A.

D. Proposta de Fórmula para o Score Geral O artigo principal constatou que o prompt atual descreve o score geral apenas como "média ponderada, com peso maior para o score normativo quando há seções ausentes" — uma instrução textual ao modelo, sem fórmula recalculada de forma independente pelo servidor. A fórmula abaixo é uma proposta ilustrativa de formalização, a validar antes de uso, não a fórmula hoje em produção.

Template D: Proposta de Fórmula para o Score Geral score_geral = 0,15 × ortografia + 0,20 × clareza + 0,20 × consistencia + 0,10 × ausencia_de_vies + 0,35 × conformidade_normativa − penalidade_estrutural penalidade_estrutural = 8 pontos por seção ausente (Parte B) + 4 pontos por seção incompleta (Parte B) (máximo de 40 pontos de penalidade) F. Metodologia de Extração dos Indicadores de Uso Status: implementado, com limitação reconhecida. Esta seção documenta o método usado para calcular o indicador aproximado de tempo de análise apresentado, respondendo à recomendação de explicitar a query e o método de pareamento dos ciclos.

O sistema não possui um identificador único de execução (analysis_run_id) que ligue diretamente um evento de início a seu evento de conclusão. Na ausência desse campo, o método adotado pareia os eventos report_submitted e review_completed por ordem cronológica dentro de cada relatório, numerando-os sequencialmente com a função de janela ROW_NUMBER() e unindo os pares pelo número de sequência (cycle) e pelo report_id.

Query F.1: pareamento cronológico de eventos de início e conclusão de análise, usado para estimar o indicador de tempo.

WITH starts AS ( SELECT report_id, created_at AS started_at, ROW_NUMBER() OVER (PARTITION BY report_id ORDER BY created_at) AS cycle FROM activity WHERE type = 'report_submitted' ), finishes AS ( SELECT report_id, created_at AS finished_at, ROW_NUMBER() OVER (PARTITION BY report_id ORDER BY created_at) AS cycle FROM activity WHERE type = 'review_completed' ), paired AS ( SELECT starts.report_id, starts.cycle, starts.started_at, finishes.finished_at, EXTRACT(EPOCH FROM (finishes.finished_at - starts.started_at)) AS seconds FROM starts INNER JOIN finishes USING (report_id, cycle) WHERE finishes.finished_at >= starts.started_at ) SELECT COUNT(*) AS pairs, ROUND(AVG(seconds)::numeric, 2) AS mean_seconds, ROUND(PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY seconds)::numeric, 2) AS median_seconds, COUNT(*) FILTER (WHERE seconds = 0) AS zero_pairs, COUNT(*) FILTER (WHERE seconds > 600) AS over_10_minutes, ROUND(AVG(seconds) FILTER (WHERE seconds > 0 AND seconds <= 600)::numeric, 2) AS trimmed_mean_seconds FROM paired;

Resultado obtido na extração de 10/09/2026:

Quadro F.1: resultado da Query F.1.

Este é um pareamento aproximado. O Quadro activity não possui identificador único de execução, review_id no evento, nem campos started_at/completed_at na própria análise. Se faltar um evento de início ou conclusão para um relatório, a numeração sequencial desloca os pares seguintes daquele relatório, o que pode gerar pares tecnicamente incorretos sem que isso seja detectável apenas pela query. Por isso, os 13 ciclos servem como estimativa, não como medição plenamente auditável. O método correto para medições futuras é atribuir um analysis_run_id a cada execução, usado tanto no evento de início quanto no de conclusão, permitindo correspondência direta em vez de correspondência por ordem.

Como Reutilizar Este Artefato Substituir o prompt em produção pelo Template A (Parte A), após validação da equipe técnica, para corrigir a referência genérica a "IN CGU" e introduzir severidade guiada por matriz;

Implementar o recálculo determinístico do score geral no servidor (Parte D), em vez de aceitar o valor agregado devolvido pelo modelo;

Usar o Quadro C.2 como rubrica de concordância entre a severidade atribuída pela IA e a avaliação de um revisor humano, alimentando o teste de concordância hoje inexistente;

Adaptar a Parte A para outra área de auditoria ou controle substituindo apenas base_conhecimento_normas e as nove seções da Parte B pelo padrão local de relatório, mantendo estrutura, guardrails e esquema de severidade;

Tratar este anexo como versão viva: cada norma_id citado na Parte A deve ser validado contra a identificação completa antes de uso em produção.