Existe uma diferença crucial entre citar um framework numa apresentação ao Conselho (ou só colocar na política) e implementá-lo de forma que um auditor externo consiga verificar. A primeira é fácil, cabe em um slide, já a segunda exige que cada controle documentado na política tenha uma evidência rastreável em produção: um log, uma configuração, um resultado de teste, um registro de treinamento.
Na Parte 2 desta série percorremos norma por norma o que BACEN, CVM, ANBIMA e LGPD exigem antes do primeiro prompt com dado real. Aquela parte fechou com uma frase: se as normas dizem o que precisa ser feito, os frameworks dizem como medir se foi bem feito. É esse fio que esta parte puxa. Cinco frameworks (quatro internacionais e um brasileiro) viram aqui pares de controle concreto e artefato verificável que um auditor efetivamente pede.
O eixo do artigo inteiro é uma só distinção: citar um framework não é o mesmo que implementá-lo de forma auditável. Conhecer GOVERN/MAP/MEASURE/MANAGE é trivial; produzir o log que prova que MEASURE roda em produção é o trabalho. As seções abaixo assumem os cinco frameworks como já conhecidos e vão direto ao par controle → artefato.
NIST AI RMF 1.0: a linguagem que o auditor reconhece
Já mapeei esses frameworks em um panorama geral em "Seven frameworks for governing LLM systems": o que cada um cobre e o que deixa de fora em um sistema LLM genérico. Aqui o recorte é outro: o que cada um exige como evidência dentro de uma instituição financeira brasileira regulada.
O valor do NIST AI RMF 1.0 não está na adoção formal, ele é voluntário, e nenhum regulador brasileiro exige certificação NIST. O valor está na linguagem. As quatro funções dão um vocabulário para documentar decisões de governança de um jeito que um auditor internacional, um conselheiro estrangeiro ou o BCB em uma inspeção reconhece como estruturado e proporcional. GOVERN é transversal: permeia as outras três. MAP enquadra o risco antes do deploy, MEASURE mede o que está em produção, MANAGE responde quando algo dispara.
A cada função corresponde um controle e, atrás de cada controle, um artefato datado:
Ampliar ↗O RMF não certifica nada: não há carimbo de organismo externo e não há auditoria de conformidade ao próprio framework. O que ele entrega é a gramática que faz a decisão de governança parecer estruturada para quem audita, e essa gramática só convence se cada artefato existe de fato. Política sem ata de revisão é intenção; MEASURE sem dashboard de SIEM é promessa. O auditor não pergunta se você organizou o programa em quatro funções; pergunta onde está o artefato de cada uma.
ISO/IEC 42001:2023: a única dos cinco que vira certificado na parede
Das cinco, a ISO/IEC 42001:2023 é a única certificável por organismo externo. É a primeira norma internacional para sistema de gestão de IA (AIMS - AI Management System), e essa distinção tem consequência prática direta: exigir ISO/IEC 42001 do fornecedor de modelo deixa de ser pedido vago e vira critério objetivo de due diligence. Você não avalia a impressão que o fornecedor passa, você pede o certificado.
A estrutura segue o ciclo PDCA (Plan, Do, Check, Act) das normas de gestão, com requisitos nas cláusulas 4 a 10. Cinco delas carregam o peso do que um auditor pode cobrar:
Ampliar ↗A cláusula 10 merece uma nota: tratar uma não-conformidade não termina no registro de que ela foi resolvida: em produção, a não-conformidade vira regra ativa que alimenta o ciclo de melhoria do sistema. Esse mecanismo de retroalimentação é tema da Parte 6 da série; aqui basta marcar que o artefato da cláusula 10 não é estático.
A ISO 42001 é, das cinco, a mais útil para cobrar de terceiros e não só de si mesmo. Ela transforma uma exigência de segurança em documento que se pede, se recebe e se arquiva. Quando o GAIG (mais abaixo) for avaliar o fornecedor, o certificado ISO/IEC 42001 é uma das peças de evidência objetiva que a planilha cobra.
OWASP LLM Top 10 2025: o catálogo que nomeia o que a CMN já exige
O ângulo que organiza esta seção é o seguinte: cada item do OWASP LLM Top 10 2025 mapeia para um controle que as Resoluções CMN 4.893/2021 e CMN 5.274/2025 já obrigam. Como a CMN 5.274 já tornou verificável (detalhado na Parte 2 desta série), o OWASP não cria obrigação nova. Apenas dá o nome técnico ao controle que o regulador brasileiro já exige. É a diferença entre "detector de exfiltração de dados sensíveis" na linguagem do compliance e "LLM02 Sensitive Information Disclosure" na linguagem do pentester.
A edição 2025 reflete como o mercado está amadurecendo. Três categorias novas entraram (LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses e LLM10 Unbounded Consumption) e o foco migrou para sistemas agênticos e com RAG. LLM09 Misinformation absorveu a antiga categoria Overreliance.
Ampliar ↗LLM09 Misinformation merece um parágrafo à parte, porque é onde o controle precisa interceder antes da entrega, não depois. Em "Guardrails regulatórios em assistentes de investimentos" descrevi por que o log que registra a violação não impede a violação: assim que a mensagem chega ao cliente, a infração está consumada. A CVM não aceita "o modelo gerou sozinho" como defesa (estabelecido na Parte 2 via art. 27-D da Lei 6.385/1976), e a LGPD art. 20 dá ao titular o direito à revisão humana. Os dois apontam para o mesmo lugar: o controle de LLM09 é um guardrail que avalia a resposta no intervalo entre o modelo gerar e o cliente receber. O artefato não é só o log do bloqueio, mas sim é a prova de que a revisão aconteceu antes da entrega.
O OWASP não inventa obrigação nova, mas sim dá ao controle da CMN um nome que o pentester e o auditor compartilham. Não a intenção: o artefato verificável.
OWASP Agentic Top 10 2026: a classe de risco que o LLM Top 10 não cobre
O OWASP Agentic Top 10 2026 foi publicado em dezembro de 2025 e trata especificamente de sistemas que planejam, executam e tomam decisões. O prefixo ASI (Agentic Security Issue) separa esses riscos dos de LLMs estáticos. Para um squad que já usa ferramentas agênticas no dia a dia, este Top 10 é mais relevante que o LLM Top 10.
A diferença não é cosmética. O LLM Top 10 protege o modelo; o Agentic Top 10 protege contra o que o modelo faz quando ganha mãos (quando lê arquivos, executa código, chama ferramentas e herda credenciais).
Ampliar ↗ASI06 Memory & Context Poisoning é a entrada catalogada de um problema antigo: estado persistente. Um agente que carrega memória entre sessões carrega também o que foi injetado nelas, e um dado malicioso plantado numa sessão envenena a próxima. A resposta de produção regulada não é detectar a memória envenenada, mas sim não manter memória persistente entre sessões. Retenção reduzida e execução sem estado não são restrições operacionais; são decisões deliberadas de controle, segurança e governança. O artefato é a config de retenção que prova que o estado não sobrevive ao fim da sessão.
ASI03 e ASI05 ganharam um caso concreto recente. A CVE-2026-21852 (vulnerabilidade no Claude Code, independente do OWASP) mostrou um repositório malicioso definindo ANTHROPIC_BASE_URL para um endpoint do atacante. Ao abrir o repositório, a ferramenta lia a config e emitia requisições antes do prompt de confirmação de confiança, exfiltrando a API key. É exatamente o cenário de abuso de identidade e execução inesperada que ASI03/ASI05 descrevem. O controle que neutraliza é distribuir essa config via managed-settings imutável por MDM, que o usuário não pode sobrescrever. O artefato é a própria config gerenciada, somada à evidência de que ela não é editável localmente.
GAIG (ANBIMA/Zetta): o framework brasileiro que vira tudo isso em due diligence
O GAIG foi apresentado na Parte 2 como ferramenta de due diligence orientativa (ANBIMA + Zetta, março de 2026). O que vale destrinchar agora são as cinco dimensões e a ficha de avaliação, que é o conteúdo novo. O GAIG não é framework de governança interna. É a peça que organiza os outros quatro em avaliação de fornecedor. É onde a ISO/IEC 42001, o SOC 2 e os controles agênticos reaparecem como evidência objetiva que se cobra de um terceiro.
As cinco dimensões e o artefato de fornecedor que cada uma exige:
Ampliar ↗A ferramenta concreta é uma planilha de perguntas com pontuação de maturidade: a instituição preenche, soma e recebe orientação de due diligence, fechando o loop. A ISO/IEC 42001 que você poderia certificar para si mesmo é a mesma que você cobra do fornecedor na dimensão ciclo de vida; o SOC 2 Type II que a dimensão cibersegurança pede é a evidência que sustenta o controle de LLM03 Supply Chain. O artefato-síntese do GAIG é a ficha de avaliação preenchida somada a um calendário de reavaliação anual.
O GAIG é o único dos cinco escrito para o mercado financeiro e de pagamentos brasileiro. Por isso a consequência é direta: não adotá-lo (ou um processo equivalente de due diligence documentada) é, por si só, uma falha que uma auditoria pode registrar.
A evidência que o auditor pode pedir
A tese do começo, agora em uma vista só. A diferença entre slide e produção é a coluna da direita de tudo acima: o artefato mínimo que cada framework deixa rastreável.
Antes da síntese, vale fixar o circuito que toda seção acima repetiu no fecho. As listas dizem qual artefato cada framework deixa; o que elas não desenham é o caminho entre o framework e o que o auditor abre, e o que acontece quando o artefato não está lá.
Ampliar ↗Fluxo: framework → controle na política → controle técnico em produção → evidência rastreável → auditor verifica. Se o artefato existe: conformidade demonstrada. Se o artefato está ausente: não-conformidade, que reabre o ciclo na política. É a cláusula 10 da ISO em forma de loop.
O artefato mínimo verificável por framework:
Ampliar ↗Nenhum item dessa tabela é teórico, cada um é um arquivo que existe (ou não). O auditor não pergunta se você conhece o framework, mas assume que conhece e pergunta onde está o artefato (não a intenção só registrada na política, mas sim o artefato verificável).
Dos frameworks à arquitetura
Os frameworks dizem qual evidência precisa existir. Eles nomeiam o gateway fail-closed que MANAGE pressupõe, a trilha de auditoria com retenção de 5 anos que a cláusula 9 da ISO exige, os hooks que funcionam como sensors de MEASURE.
Mas nomear não é construir.
A próxima parte mostra a arquitetura que produz essa evidência sem depender de boa vontade, onde a política e o framework viram controle técnico que o desenho força. Gateway self-hosted em VPC brasileira, detecção de PII antes da saída, fail-closed por padrão, residência de dados como restrição de projeto e não como nota de rodapé. Política sem arquitetura é documento, o controle só vira evidência quando o desenho técnico não deixa alternativa.
Fontes: NIST AI RMF 1.0: https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf ISO/IEC 42001:2023: https://www.iso.org/standard/42001 OWASP LLM Top 10 2025: https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/ OWASP Agentic Top 10 2026: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ CVE-2026-21852: https://nvd.nist.gov/vuln/detail/CVE-2026-21852
Parte 3 de 6 da série "IA Generativa em Instituição Financeira Regulada". A Parte 4 entra na arquitetura.