There is a crucial difference between citing a framework in a Board presentation (or merely putting it in a policy) and implementing it so that an external auditor can verify it. The first is easy and fits on a slide; the second requires every control documented in the policy to have traceable production evidence: a log, configuration, test result, or training record.
In Part 2 of this series, we went regulation by regulation through what BACEN, CVM, ANBIMA, and the LGPD require before the first prompt containing real data. That part ended with a sentence: if regulations say what needs to be done, frameworks say how to measure whether it was done well. That is the thread this part follows. Five frameworks (four international and one Brazilian) become pairs of concrete controls and verifiable artifacts that an auditor actually requests.
The whole article revolves around a single distinction: citing a framework is not the same as implementing it auditably. Knowing GOVERN/MAP/MEASURE/MANAGE is trivial; producing the log that proves MEASURE runs in production is the work. The sections below assume the five frameworks are already familiar and go straight to the control → artifact pair.
NIST AI RMF 1.0: the language the auditor recognizes
I have already mapped these frameworks in a general overview in "Seven frameworks for governing LLM systems": what each covers and leaves out in a generic LLM system. Here, the scope is different: what each requires as evidence within a regulated Brazilian financial institution.
The value of NIST AI RMF 1.0 is not formal adoption: it is voluntary, and no Brazilian regulator requires NIST certification. Its value lies in the language. The four functions provide a vocabulary for documenting governance decisions in a way that an international auditor, foreign board member, or BCB inspector recognizes as structured and proportionate. GOVERN is cross-cutting: it permeates the other three. MAP frames risk before deployment, MEASURE measures what is in production, and MANAGE responds when something triggers.
Each function corresponds to a control, and behind every control is a dated artifact:
Enlarge ↗The RMF certifies nothing: there is no stamp from an external body and no audit of compliance with the framework itself. What it provides is the grammar that makes a governance decision look structured to an auditor, and that grammar is convincing only if every artifact actually exists. A policy without review minutes is intent; MEASURE without a SIEM dashboard is a promise. The auditor does not ask whether you organized the program into four functions; they ask where each function's artifact is.
ISO/IEC 42001:2023: the only one of the five that becomes a certificate on the wall
Of the five, ISO/IEC 42001:2023 is the only one certifiable by an external body. It is the first international standard for an AI Management System (AIMS), and that distinction has a direct practical consequence: requiring ISO/IEC 42001 from a model provider stops being a vague request and becomes an objective due diligence criterion. You do not assess the impression the provider gives; you request the certificate.
The structure follows the PDCA (Plan, Do, Check, Act) cycle of management standards, with requirements in clauses 4 to 10. Five of them carry the weight of what an auditor may demand:
Enlarge ↗Clause 10 deserves a note: addressing a nonconformity does not end with recording that it was resolved; in production, the nonconformity becomes an active rule feeding the system's improvement cycle. This feedback mechanism is the subject of Part 6 of the series; here, it is enough to note that the clause 10 artifact is not static.
Of the five, ISO 42001 is the most useful for making demands of third parties, not just yourself. It turns a security requirement into a document that is requested, received, and archived. When GAIG (below) assesses the provider, the ISO/IEC 42001 certificate is one piece of objective evidence the spreadsheet requests.
OWASP LLM Top 10 2025: the catalog that names what CMN already requires
This section is organized around the following angle: each item in the OWASP LLM Top 10 2025 maps to a control that CMN Resolutions 4.893/2021 and 5.274/2025 already mandate. Since CMN 5.274 has already made it verifiable (detailed in Part 2 of this series), OWASP creates no new obligation. It merely gives a technical name to the control the Brazilian regulator already requires. It is the difference between "sensitive-data exfiltration detector" in compliance language and "LLM02 Sensitive Information Disclosure" in the pentester's language.
The 2025 edition reflects the market's maturation. Three new categories were added (LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses, and LLM10 Unbounded Consumption), and the focus shifted toward agentic and RAG systems. LLM09 Misinformation absorbed the former Overreliance category.
Enlarge ↗LLM09 Misinformation deserves its own paragraph because it is where control needs to intervene before delivery, not afterward. In "Regulatory guardrails in investment assistants", I described why a log recording a violation does not prevent the violation: once the message reaches the customer, the offense is complete. CVM does not accept "the model generated it on its own" as a defense (established in Part 2 through article 27-D of Law 6.385/1976), and LGPD article 20 gives the data subject the right to human review. Both point to the same place: the control for LLM09 is a guardrail that evaluates the answer between model generation and customer receipt. The artifact is not just the blocking log, but proof that review happened before delivery.
OWASP does not invent a new obligation; it gives the CMN control a name shared by the pentester and auditor. Not intent: a verifiable artifact.
OWASP Agentic Top 10 2026: the risk class the LLM Top 10 does not cover
The OWASP Agentic Top 10 2026 was published in December 2025 and specifically addresses systems that plan, execute, and make decisions. The ASI (Agentic Security Issue) prefix separates these risks from those of static LLMs. For a squad already using agentic tools in daily work, this Top 10 is more relevant than the LLM Top 10.
The difference is not cosmetic. The LLM Top 10 protects the model; the Agentic Top 10 protects against what the model does when it gets hands (when it reads files, executes code, calls tools, and inherits credentials).
Enlarge ↗ASI06 Memory & Context Poisoning is the cataloged entry for an old problem: persistent state. An agent that carries memory between sessions also carries what was injected into them, and malicious data planted in one session poisons the next. The regulated-production response is not detecting poisoned memory, but not keeping persistent memory between sessions. Reduced retention and stateless execution are not operational restrictions; they are deliberate control, security, and governance decisions. The artifact is the retention configuration proving that state does not survive the end of a session.
ASI03 and ASI05 recently gained a concrete case. CVE-2026-21852 (a Claude Code vulnerability, independent of OWASP) showed a malicious repository setting ANTHROPIC_BASE_URL to an attacker endpoint. On opening the repository, the tool read the configuration and issued requests before the trust-confirmation prompt, exfiltrating the API key. This is exactly the identity-abuse and unexpected-execution scenario ASI03/ASI05 describe. The control that neutralizes it is distributing this configuration through immutable managed-settings via MDM, which the user cannot overwrite. The artifact is the managed configuration itself, together with evidence that it cannot be edited locally.
GAIG (ANBIMA/Zetta): the Brazilian framework that turns all this into due diligence
GAIG was introduced in Part 2 as an advisory due diligence tool (ANBIMA + Zetta, March 2026). What is worth unpacking now are the five dimensions and the assessment form, which are the new material. GAIG is not an internal governance framework. It is the piece that organizes the other four into provider assessment. It is where ISO/IEC 42001, SOC 2, and agentic controls reappear as objective evidence demanded from a third party.
The five dimensions and the provider artifact each requires:
Enlarge ↗The concrete tool is a question spreadsheet with maturity scoring: the institution completes it, adds the scores, and receives due diligence guidance, closing the loop. The ISO/IEC 42001 you could certify yourself against is the same one you require from the provider in the lifecycle dimension; the SOC 2 Type II requested by the cybersecurity dimension is the evidence supporting the LLM03 Supply Chain control. GAIG's summary artifact is the completed assessment form plus an annual reassessment calendar.
GAIG is the only one of the five written for Brazil's financial and payments market. The consequence is therefore direct: not adopting it (or an equivalent process of documented due diligence) is, in itself, a failure that an audit may record.
The evidence the auditor may request
The opening thesis, now in one view. The difference between a slide and production is the right-hand column of everything above: the minimum artifact each framework leaves traceable.
Before the synthesis, it is worth establishing the circuit repeated at the end of every section above. The lists say which artifact each framework leaves; what they do not draw is the path between the framework and what the auditor opens, and what happens when the artifact is not there.
Enlarge ↗Flow: framework → control in policy → technical control in production → traceable evidence → auditor verifies. If the artifact exists: demonstrated compliance. If the artifact is absent: nonconformity, which reopens the cycle in the policy. It is ISO clause 10 as a loop.
The minimum verifiable artifact per framework:
Enlarge ↗Nothing in this table is theoretical; each item is a file that exists (or does not). The auditor does not ask whether you know the framework, but assumes you do and asks where the artifact is (not merely the intent recorded in policy, but the verifiable artifact).
From frameworks to architecture
Frameworks say what evidence must exist. They name the fail-closed gateway MANAGE presupposes, the audit trail with 5-year retention that ISO clause 9 requires, and the hooks that serve as MEASURE sensors.
But naming is not building.
The next part shows the architecture that produces this evidence without relying on goodwill, where policy and framework become technical controls enforced by design. A self-hosted gateway in a Brazilian VPC, PII detection before egress, fail-closed by default, data residency as a design constraint rather than a footnote. Policy without architecture is a document; control becomes evidence only when the technical design leaves no alternative.
Sources: 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
Part 3 of 6 of the "Generative AI in a Regulated Financial Institution" series. Part 4 goes into the architecture.