In a regulated financial institution, the criterion is not speed: it is demonstrability. This introduction establishes the thesis, the Product ≠ Provider principle, and the map of the next five parts.
Adopting generative AI in a startup and adopting generative AI in a financial institution regulated by the Central Bank of Brazil are different problems. In a startup, the main criterion is speed. In a financial institution, the main criterion is demonstrability: the ability to prove, to an external auditor or the regulator, that every decision made in the process was deliberate, documented, and proportionate to the risk.
This six-article series covers that construction: the corporate generative AI program within a regulated environment, with the pillars that, in practice, can determine the success or failure of such an initiative. It is what actually happens when governance, frameworks, architecture, process engineering, and agent infrastructure must work together within the real constraints of a financial institution subject to CMN Resolution 4.893/2021 (updated by CMN 5.274/2025), the LGPD, Complementary Law 105/2001, and guidance from CVM and ANBIMA.
Why this subject now
The Brazilian financial market is at a dual turning point.
On one side, technology leaders know that generative AI delivers real gains (McKinsey studies indicate gains between 20% and 45% in software engineering tasks), with adoption pressure coming from both the top and bottom of organizations. The figure is important and also misleading: the 2025 METR study, involving experienced developers working in large open-source repositories, found the opposite effect: tasks were 19% slower with AI. The gain depends on context.
On the other side, the Brazilian regulator has not stood still. CMN Resolution 4.893/2021, strengthened by CMN 5.274/2025 (published on 18/12/2025, with mandatory compliance by March 1, 2026), requires notification or prior BCB authorization for cloud processing abroad, verifiable minimum controls, and end-to-end traceability. The LGPD imposes obligations concerning legal basis and international transfers. Complementary Law 105/2001 leaves little room for creative interpretation of banking secrecy. CVM has insider-information rules that apply directly to AI use cases. And in March 2026, ANBIMA and Zetta launched GAIG (Generative AI Assessment Guide), signaling that the capital markets want verifiable standards for those contracting AI providers.
These subjects leave the abstract realm when they need to become code. I covered part of this in an earlier article about regulatory guardrails in an investment assistant, where the tension between CVM, ANBIMA, and the LGPD appears in the critique_node that decides whether an answer is released. This article operates one level above: before reaching the guardrail in code, someone needs to have designed the program that makes that guardrail possible.
The practical result can be a minefield. AI initiatives in financial institutions can fail not because of a lack of technology, but because decisions are made in the wrong order: contracting before having a policy, training before classifying data, putting users into production before having an audit trail.
A principle that must be clear from the start
Before the series map, one principle runs through all six articles and deserves emphasis now:
> Product ≠ Provider. The data regime is defined by the product, not by who makes it.
The regulatory assessment criterion for an AI tool is not “which provider,” but “which product, which data regime, which compliance coverage.”
The same provider may offer an API and an Enterprise interface with ZDR (Zero Data Retention, where the provider does not retain prompt or output data after inference), Audit Logs (complete records of every call, exportable to the institution's SIEM), and Compliance API (an administrative endpoint delivering those logs and metadata in an auditable format), while its desktop-agent product and design product have none of the three. Using them without distinction is a recipe for a compliance incident. In January 2026, there was already a publicly documented exfiltration incident through prompt injection in one of those parallel products, exactly the kind of surprise this principle exists to prevent. We will explore this further in part 4, which goes into the technical details.
Three surfaces from the same provider, three data regimes:
Enlarge ↗The name on the contract says nothing about what may go into the prompt.
The distinction must be explicit in three places: the usage policy, the catalog of authorized tools, and mandatory training. Without it, a competent, well-intentioned, and uninformed employee is all it takes to become the program's point of failure.
What is coming in the next five articles#
Part 2 The Brazilian regulatory maze: a regulation-by-regulation analysis of what BACEN, CVM, ANBIMA, and the LGPD require before the first prompt: CMN 4.893/2021 + CMN 5.274/2025, Complementary Law 105/2001, LGPD articles 20/33/46, CVM guidance, and GAIG. Includes the distinction between countries with and without a supervisory agreement with the BCB and an analysis of MoUs (Memoranda of Understanding); their nonbinding nature, declarations of intent, not legally enforceable agreements. Compares contracting directly with the provider, through a hyperscaler with a Brazilian region (AWS sa-east-1, Azure Brazil South, GCP São Paulo), and through SaaS with an embedded LLM.
Part 3 Frameworks in practice: NIST AI RMF 1.0, ISO/IEC 42001:2023, OWASP LLM Top 10 2025, OWASP Agentic Top 10 2026, and GAIG. Each framework translated into a concrete control and the evidence the auditor requests: a signed policy, SIEM dashboard, red-team report, human-review record; not intention, but a verifiable artifact.
Part 4 Architecture, where policy becomes a technical control: why the on-premises gateway (a self-hosted prompt-inspection gateway in a Brazilian VPC) needs to be in Brazil to address LGPD article 33, Complementary Law 105, and CMN 4.893 simultaneously. Fail-closed as a principle: if a control is absent or fails, the system stops; it does not degrade into a less secure mode. Data residency (where the data is physically processed, not the provider's legal headquarters). An audit trail with 5-year retention. A supplement on surfaces not recommended for regulated workloads.
Part 5 Spec-Driven Development with AI: five anti-patterns in using AI for engineering (including vibe coding), with the specific consequence for a regulated financial institution. The seven-stage flow with an explicit exit gate at each stage. The anatomy of a spec suitable for AI code generation.
Part 6 Harness Engineering: the discipline that systematizes everything. Agent = Model + Harness. Three maturity phases in AI engineering: prompt → context → harness. Five layers of the harness (the corporate infrastructure around the model that makes the agent reliable in production): guides, sensors, data context layer, orchestration, feedback. The inner harness/outer harness distinction (inner is what the provider delivers; outer is what the institution builds on top, and it is where CMN 4.893, the LGPD, and Complementary Law 105 become technical controls). The inner layer does not cover Brazilian regulatory obligations by design.
The common thread#
The six pillars are not independent. Governance policy defines what can be done. Frameworks provide the vocabulary and evidence structure the regulator recognizes. Architecture turns the rule into a technical control that does not depend on goodwill. The distinction between regulated and unregulated surfaces (the Product ≠ Provider principle) prevents successful adoption of one product from contaminating the program with another product's risk. Specification engineering ensures the developer produces auditable output. And the harness names and systematizes the infrastructure that makes all of this work sustainably in production.
In this case, sequence matters. An institution that implements architecture without policy does not know what it is protecting. One with policy but no corresponding technical architecture cannot enforce anything. Without understanding each product's data regime, it creates exposure where it believes it has control. Even with all of that in place, programs that do not train their teams fail at the first user. And anyone who reaches that point without building the harness has a system that works in a demonstration and breaks in production.
Failure in any one of the six means failure in all of them. The program needs the pillars and the sequence.
Who this series is for#
This series is for those who need to present an AI plan to the Board and the regulator, those designing the topology that carries that plan, those issuing a compliance opinion on what that topology does, and the engineer who will use AI without becoming an incident headline. It is also for professionals seeking a career at the intersection of generative AI and regulated environments, one of the scarcest and most sought-after areas in the Brazilian financial technology market in 2026.
Next: Part 2 The Brazilian regulatory maze.
#IAGenerativa #Compliance #BACEN #InstituiçãoFinanceira #LGPD #GovernançaDeIA #RegTech