Regulatory guardrails in investment assistants: CVM, ANBIMA, and the LGPD paradox
Between the LLM generating a response and it reaching the customer is where a regulatory violation can happen - without intent, without malice, and with no possibility of reversing it.
The other day I talked about the memory taxonomy (episodic, semantic, and procedural) and how each type requires a different infrastructure layer in a financial assistant.
Today I want to talk about the problem no storage layer solves on its own: what happens between the LLM generating a response and it reaching the customer.
That millisecond interval of processing is where the institution can commit a regulatory violation without intent, without malice, and with no possibility of reversing it after the message has been delivered.
The problem the legal archive doesn't solve
You can have S3 WORM in Compliance Mode, the data warehouse with every audit table, the Redis Checkpointer storing every conversation turn. All of that is indispensable, but it serves to prove what happened after the fact.
If the LLM delivered the phrase "invest now, don't miss this opportunity" to the customer, the log will record that the violation occurred. That doesn't prevent the infraction. CVM Resolution 30 doesn't accept "the model generated it on its own" as a defense.
What prevents it is a guardrail that intervenes before delivery:
The critique_node isn't a feature. It's an architectural obligation when the domain is investments.
The violations the LLM commits naturally
The model doesn't generate these phrases on purpose. But it will generate them, because it was trained on human text, and human text is full of sales language and opinions on portfolios.
Each violation has a specific legal origin. They're not arbitrary UX rules - they're obligations with a resolution number and an associated sanction.
The three-layer architecture inside critique_node
Validation happens in cascade, with increasing speed and depth:
The three-layer logic isn't overhead - it's cost proportional to risk. Violation 1 is detectable in milliseconds via regex. Violation 3 doesn't require blocking, only injection. Only violation 2 demands semantic reasoning, and that's where DSPy comes in.
The code that implements each violation
The solution for violation 3 isn't to block - it's to inject surgically. The LLM generated a valid response. It was just incomplete:
The Circuit Breaker: when the semantic guardrail fails
DSPy does the deepest evaluation: it detects hallucinations by comparing the response to the actual context returned by the tools, evaluates whether the model opined on suitability without the necessary data, and rewrites when needed.
But DSPy depends on external infrastructure. If it goes down, what happens? Pure fail-open (let everything through) is the wrong answer for a financial assistant. The right answer is an explicit fallback:
The Circuit Breaker prevents a DSPy failure from cascading into timeouts that degrade latency for every response, while keeping the regulatory barrier active via regex. Resilience with conformance.
The disclaimers ANBIMA requires by response type
It isn't a single disclaimer for everything. The obligation changes with the content shown:
The LGPD vs PLD paradox (and an architectural way out)
With guardrails and the legal archive in place, the last tension shows up: LGPD (Article 18) gives the data subject the right to request deletion. The Brazilian Central Bank requires that financial operations be kept for up to 10 years for AML/CFT purposes.
How do you implement DELETE on WORM storage?
The industry's answer is Crypto-Shredding:
The file stays in S3, WORM is not violated, regulatory integrity is preserved. But without the key, the individual's data is mathematically destroyed. The flow can still count aggregated transactions. The data subject's privacy was respected.
It's a solution that simultaneously satisfies LGPD Art. 18 and BCB Circular 3.978.
The retention periods you need to set before going to open sea:
A detail that can pass unnoticed and is very important: a triggered guardrail with CVM violation also goes to the 10-year archive - not as evidence against the institution, but as evidence in its favor. It demonstrates that the system detected and blocked the violation before delivery.
Summary
Guardrails in investments aren't output validation - they're automated regulatory control. The difference matters because it changes how you design them: it's not checking whether the response is good, it's checking whether the response is within the legal limits the Central Bank and CVM define.
The architecture presented has three defense layers:
- regex for the obvious, immediate violations;
- automatic injection for the mandatory disclaimers;
- DSPy for the semantic violations that regex can't reach.
With Circuit Breaker ensuring that one layer's failure doesn't compromise the others.
And all of it needs to be recorded, because the legal archive that stores "guardrail triggered with violation 2 blocked" is as important as the archive that stores the transaction. It's the proof that the system was working.