What CMN Resolution 4.893 requires when a bank uses a cloud LLM

About this article

Published 2026-10-07 by Rafael Hickmann, Founder, Atlasberg. 9 minute read.

First, the framing

Resolution 4.893 of the National Monetary Council (CMN), dated February 26, 2021, replaced Resolution 4.658 and covers two things: the cybersecurity policy of institutions authorized by the Central Bank of Brazil (BCB), and the requirements for contracting data processing, data storage and cloud computing services. Payment institutions have an equivalent text in BCB Resolution 85 of 2021. None of this was written with language models in mind, and it still fits with uncomfortable precision.

Article 13 defines cloud computing and includes, in item III, the execution over the internet of applications deployed or developed by the service provider, using the provider's own computing resources. That is the definition of software as a service, and it is exactly what a language model API is. The resolution does not list which services are relevant. The criterion is in article 12, paragraph 1: the institution must consider the criticality of the service and the sensitivity of the data and information to be processed.

Let us be honest about what the rule says and what it does not. It does not say an LLM is a relevant service. It says the decision belongs to the institution and must be documented (paragraph 2 of the same article). Our reading, and the reading of people following the topic in the sector, is that when the model touches customer data, operations or credit decisions, it becomes very hard to argue it is not relevant. Zetta, the Brazilian fintech association, lists 4.893 among the rules that govern AI in the financial sector in its responsible AI guide. The practical question is no longer whether the resolution applies, but how to prove it is being followed.

What changed in December 2025

CMN Resolution 5.274, of December 18, 2025, amended 4.893 and set an adaptation deadline of March 1, 2026. For anyone using AI, the change that matters is in article 3. Paragraph 3 says the security controls apply including to the adoption of new technologies used in the institution's activities. And paragraph 7 spells out what the traceability mechanisms must include: end-to-end audit trails of data and information processing, including the definition and generation of logs; a defined retention period according to the type of processing; and secure retention of the audit trails.

Sending a prompt to a model and receiving the answer is data processing. End to end, in this case, means from the person or application that originated the request to the provider and back. Before 5.274 one could argue that the provider's log was enough. Now the trail has to exist along the whole path, with a retention period set by the institution, and stored in a way that cannot be altered.

What the resolution requires, article by article

One detail that usually surprises people: the notice to the Central Bank is not prior. It is due within ten days after contracting. The only prior act is the article 16 authorization, when the provider's country has no supervisory agreement with the BCB.

• Requirement: Assess the provider before contracting, with a record | Where: Art. 12, items I and II, and § 2 | What it means when the service is an LLM: Verify that the provider ensures the institution's access to the data, confidentiality, integrity and availability, independent audit reports and segregation of customer data. All documented.
• Requirement: Notify the Central Bank | Where: Art. 15, §§ 1 and 2 | What it means when the service is an LLM: Within ten days after contracting: provider name, services contracted and, if abroad, the countries and regions where data may be stored, processed and managed. Changes also within ten days.
• Requirement: Service provided abroad | Where: Art. 16 | What it means when the service is an LLM: There must be an information exchange agreement between the BCB and the supervisor of that country. Without one, prior BCB authorization sixty days in advance. Foreign law may not restrict the institution's and the BCB's access to the data.
• Requirement: Mandatory contract clauses | Where: Art. 17 | What it means when the service is an LLM: Data location, security measures, segregation and access control for the life of the contract, transfer and deletion at the end, access to certifications and audit reports, notice of subcontracting, and BCB access to the data and to information about its processing.
• Requirement: Incidents | Where: Art. 3, item IV and § 4 | What it means when the service is an LLM: Recording, root cause and impact analysis and control of the effects of relevant incidents, including information received from the provider. Customer data leaking in a prompt is an incident.
• Requirement: Traceability | Where: Art. 3, § 7 (Res. 5.274) | What it means when the service is an LLM: End-to-end audit trail with log generation, a retention period defined per type of processing and secure retention.
• Requirement: Document retention | Where: Art. 23 | What it means when the service is an LLM: Five years available to the BCB: the policy, the incident response plan, the annual report, the article 12 assessment documentation and the contracts, counted from the end of the contract.

Where the LLM makes it hard

A model provider's contract is, in most cases, a click-through agreement. Negotiating the article 17 clauses one by one is possible for large institutions and unlikely for everyone else. The data goes abroad, passes through subprocessors the provider may swap, and what the provider gives back as a record is an aggregated usage dashboard, in its own system, under its own control. Article 14 is clear about who answers for it: the contracting institution is responsible for the reliability, integrity, availability, security and confidentiality of the contracted services.

In other words, the trail paragraph 7 demands cannot live at the provider. It has to be under the institution's control, on the path between whoever asked and whoever answered. That is what an AI gateway is.

What the gateway returns as evidence

• One door: all of the institution's AI traffic goes through the gateway, and direct egress to providers is blocked at the firewall. Every request has an owner: a person, a team or an application.
• Policy before leaving: personal data is masked or blocked before the prompt reaches the provider, and the decisions are recorded by category. That feeds both traceability and the incident record.
• A hash-chained, signed trail: one event per request, with identity, model, provider, policy decision and a hash of the content. The prompt text never enters the trail. Editing one event breaks the chain.
• Residency by geography: the compliance report lists the providers used and where the data was processed, which is the information article 15 asks for and article 16 conditions.
• Banking retention profile: the banking audit profile turns on hourly anchors and five year retention, aligned with article 23.
• Independent verification: the atlasberg-verify tool runs offline and checks the trail, the exports and the reports without depending on us. It is what you hand to the auditor or the supervisor.
• Compliance panel: the evidence is organized article by article for 4.893, LGPD and the EU AI Act.

Checklist for the committee

• Decide, in writing, whether each AI service is relevant, using the criteria of article 12, paragraph 1. Keep the analysis for five years.
• List the processing countries and regions of each provider and check whether the BCB has an agreement with the local supervisor. Without one, request authorization sixty days ahead.
• Notify the BCB of the contract within ten days, with the content of article 15.
• Review the provider's contract against article 17. Where the provider will not accept a clause, record the limitation (item IX) and compensate with your own control.
• Make sure the end-to-end audit trail exists under the institution's control, with a defined retention period, as paragraph 7 requires.
• Include AI usage in the incident register and in the annual cybersecurity report of article 8.

What the gateway does not do

It does not replace the provider assessment, it does not negotiate the contract and it does not create a supervisory agreement where none exists. What it does is put under the institution's control the three things the resolution demands and the provider does not deliver: the trail, the residency and the policy. The rest remains the work of legal, risk and security. This article is the reading of the people who build the tool, not legal advice.

Going deeper: The documentation for the console's Compliance group shows the per-article panel, the trail and the approval queue. The atlasberg-verify page has the exact contract of the offline verification, with exit codes, for anyone who needs to audit it.

About Atlasberg

Atlasberg builds the control layer between a company and every AI model. Atlasberg Platform authenticates each request with a virtual key, filters it by policy and DLP, routes it to the right provider and writes it to a hash-chained audit trail, with an OpenAI-compatible API so applications only swap the base URL.

Articles on this blog are written by the engineering team and report measurements on real traffic, with the premises printed next to the result. To talk to the team, write to [email protected] or use https://atlasberg.com/contato.