Guardrails regulatórios em assistentes de investimentos: CVM, ANBIMA e o paradoxo da LGPD

Esses dias falei sobre a taxonomia de memória (episódica, semântica e procedural) e como cada tipo exige uma camada diferente de infraestrutura num assistente financeiro.

Hoje quero falar sobre o problema que nenhuma camada de armazenamento resolve sozinha: o que acontece entre o LLM gerar uma resposta e ela chegar ao cliente.

Esse intervalo de milésimos de segundos de processamento, é onde a instituição pode cometer uma infração regulatória sem intenção, sem malícia, e sem qualquer possibilidade de reverter depois que a mensagem foi entregue.

O problema que o arquivo legal não resolve

Você pode ter o S3 WORM configurado em Compliance Mode, o Data Warehouse com todas as tabelas de auditoria, o Redis Checkpointer guardando cada turno da conversa. Tudo isso é indispensável, mas serve para provar o que aconteceu depois do fato.

Se o LLM entregou ao cliente a frase "invista agora, não perca essa oportunidade", o log vai registrar que a violação ocorreu. Isso não impede a infração. A Resolução CVM 30 não aceita "o modelo gerou sozinho" como defesa.

O que impede é um guardrail que intercede antes da entrega:

O critique_node não é uma feature. É uma obrigação arquitetural quando o domínio é investimentos.

As violações que o LLM comete naturalmente

O modelo não vai gerar essas frases de propósito. Mas vai gerar, porque foi treinado em texto humano, e texto humano está cheio de linguagem de vendas e opiniões sobre portfólios.

Cada violação tem origem legal específica. Não são apenas regras de UX arbitrárias, são obrigações com número de resolução e sanção associada.

A arquitetura de três camadas dentro do critique_node

A validação acontece em cascata, com velocidade e profundidade crescentes:

A lógica de três camadas não é overhead, é custo proporcional ao risco. Violação 1 é detectável em milésimos de segundos via regex. Violação 3 não requer bloqueio, apenas injeção. Só a violação 2 exige raciocínio semântico, e aí entra o DSPy.

O código que implementa cada violação

A solução para a violação 3 não é bloquear, é injetar cirurgicamente. O LLM gerou uma resposta válida. Ela só estava incompleta:

O Circuit Breaker: quando o guardrail semântico falha

O DSPy faz a avaliação mais profunda: detecta alucinações comparando a resposta com o contexto real retornado pelas tools, avalia se o modelo opinou sobre suitability sem ter os dados necessários, e reescreve quando necessário.

Mas o DSPy depende de infraestrutura externa. Se ele cair, o que acontece? Fail-open puro (deixar passar tudo) é a resposta errada para um assistente financeiro. A resposta certa é um fallback explícito:

O Circuit Breaker evita que uma falha no DSPy vire cascata de timeouts que degrade a latência de todas as respostas, ao mesmo tempo que mantém a barreira regulatória ativa via regex. É resiliência com conformidade.

Os disclaimers que o ANBIMA exige por tipo de resposta

Não é um disclaimer único para tudo. A obrigação muda conforme o conteúdo apresentado:

O paradoxo LGPD vs PLD (e uma saída arquitetural)

Com guardrails e arquivo legal no lugar, aparece a última tensão: a LGPD (Art. 18) garante ao titular o direito de solicitar a exclusão dos seus dados. O Banco Central exige que operações financeiras fiquem guardadas por até 10 anos para fins de PLD/FT.

Como você implementa DELETE num storage WORM?

A resposta da indústria é Crypto-Shredding (Trituração Criptográfica):

O arquivo continua no S3, o WORM não foi violado, a integridade regulatória está preservada. Mas sem a chave, os dados do indivíduo são matematicamente destruídos. O fluxo ainda consegue contar transações agregadas. A privacidade do titular foi respeitada.

É uma solução que satisfaz simultaneamente o Art. 18 da LGPD e a Circular BCB 3.978.

Os prazos que você precisa configurar antes de ir para mar aberto:

Um detalhe que pode passar despercebido e é muito importante: guardrail acionado com violação CVM também vai para o arquivo de 10 anos, não como prova contra a instituição, mas como prova a favor. Demonstra que o sistema detectou e bloqueou a violação antes da entrega.

Resumo

Guardrails em investimentos não são validação de output, são controle regulatório automatizado. A diferença importa porque muda como você os projeta: não é verificar se a resposta está boa, é verificar se a resposta está dentro dos limites legais que o Banco Central e a CVM definem.

A arquitetura apresentada possui três camadas de defesa:

• regex para as violações óbvias e imediatas;
• injeção automática para os disclaimers obrigatórios;
• DSPy para as violações semânticas que regex não alcança.

Com Circuit Breaker garantindo que a falha de uma camada não comprometa as outras.

E tudo isso precisa ser gravado, porque o arquivo legal que guarda "guardrail acionado com violação 2 bloqueada" é tão importante quanto o arquivo que guarda a transação. É a prova de que o sistema estava funcionando.