Da política ao controle técnico - Parte 4 de "IA Generativa em Instituição Financeira Regulada".
Política de uso de IA sem arquitetura técnica correspondente é apenas um documento; a governança existe no papel enquanto o risco em produção. A distância entre os dois é o que um incidente ou uma inspeção regulatória acaba revelando.
Nas três primeiras partes desta série montei o mapa, percorri norma por norma e traduzi frameworks em controles auditáveis. Agora a pergunta muda: como desenhar uma arquitetura em que o cumprimento da política não dependa apenas da boa vontade de quem está usando a ferramenta?
A resposta começa por um princípio agnóstico de fornecedor e de ferramenta: fail-closed. Na ausência ou falha de um controle de segurança, o sistema não degrada silenciosamente para um caminho menos protegido, não abre uma conexão direta com o provedor nem aciona um fallback que contorne a inspeção. O gateway ficou indisponível? A ferramenta de assistência ao desenvolvimento (seja Claude Code, Codex ou outra) interrompe as chamadas ao modelo, sem uma rota alternativa que contorne os mesmos controles. Isso não significa abrir mão de continuidade operacional: uma rota de contingência pode existir, desde que preserve controles equivalentes de inspeção, identidade, rastreabilidade e residência. O que não pode existir é um fallback que transforme a indisponibilidade do controle em bypass.
A Resolução CMN 4.893/2021, alterada pela Resolução CMN 5.274/2025, não utiliza o termo fail-closed, ela estabelece requisitos de segurança, rastreabilidade, proteção de redes, configurações seguras e controles aplicáveis também à adoção de novas tecnologias. Neste desenho, fail-closed é uma forma defensável de operacionalizar essas exigências. Não estou citando uma determinação literal da norma, mas traduzindo objetivos regulatórios em uma decisão de arquitetura.
É dessa decisão que decorre a tese central deste artigo: residência, custódia e controle sobre o caminho do dado não são detalhes de hospedagem: são restrições de projeto.
Ao longo deste artigo, uso o Claude Code como exemplo concreto para detalhar a arquitetura e seus mecanismos de controle. O princípio, porém, permanece o mesmo para qualquer ferramenta: a implementação deve ser adaptada às capacidades de cada produto, mas nenhuma delas pode operar fora do caminho corporativo de inspeção.
Cada decisão de design responde a um risco específico#
Nem toda escolha arquitetural é imposta literalmente por uma norma. Algumas são decisões que podem ser adotadas pela empresa para atender, de maneira verificável, aos objetivos estabelecidos por diferentes normas.Essa distinção importa. O regulador estabelece o resultado esperado enquanto a arquitetura define como demonstrá-lo.
Ampliar ↗O ponto central não é afirmar que existe apenas uma arquitetura possível. É exigir que a instituição consiga demonstrar por que escolheu determinado desenho e como ele atende aos riscos identificados.
O mesmo controle pode responder a mais de um risco#
A configuração do endpoint é um bom exemplo. Na Parte 3, o ANTHROPIC_BASE_URL apareceu sob o ângulo da cadeia de suprimentos. A vulnerabilidade CVE-2026-21852 permitia que, em versões anteriores à correção, um repositório malicioso influenciasse a configuração do endpoint e redirecionasse requisições antes da confirmação de confiança do projeto. O primeiro controle para essa vulnerabilidade é atualizar o Claude Code para uma versão corrigida. Managed settings, restrições de rede e bloqueio de configurações locais são camadas adicionais de defesa, não substitutos do patch.
Aqui, a mesma configuração aparece por outro motivo: governança e rastreabilidade. Quando cada desenvolvedor acessa diretamente o endpoint público, a instituição pode até identificar a chave ou a conta utilizada, mas perde uma trilha central e uniforme que correlacione:
identidade corporativa
dispositivo
sessão
repositório
política aplicada
modelo e versão
conteúdo detectado
decisão de bloqueio ou liberação
resposta do provedor
Fixar o destino por política corporativa ajuda, mas não resolve sozinho. O desenho precisa ser reforçado pela rede, que bloqueia conexões diretas aos endpoints públicos e permite apenas o gateway autorizado. Configuração local e controle de rede se complementam: um evita alterações acidentais ou maliciosas na ferramenta, enquanto o outro impede que uma ferramenta diferente contorne o mesmo caminho.
Duas camadas, dois papéis#
Um erro nesse tipo de arquitetura é confundir o controle de rede com o gateway de conteúdo. Ferramentas SSE (Security Service Edge) e SASE (Secure Access Service Edge) podem, tecnicamente, inspecionar tráfego, aplicar DLP, identificar aplicações de IA e até analisar prompts e respostas. O ponto aqui não é negar essa capacidade, mas sim identificar qual componente será o ponto canônico de decisão sobre o conteúdo regulado e onde essa inspeção ocorrerá?
Neste desenho, as responsabilidades são separadas.
A camada de rede#
A camada de rede controla o caminho:
bloqueia acesso direto a provedores e ferramentas não autorizadas
força o tráfego para um destino corporativo
identifica Shadow AI
aplica controles de acesso por usuário, grupo e dispositivo
pode utilizar DLP como barreira complementar
registra tentativas de contorno
O gateway de conteúdo#
O gateway aplica a política sobre cada chamada:
autentica e identifica o usuário
correlaciona dispositivo, sessão e repositório
inspeciona prompts, arquivos e respostas
detecta dados pessoais, credenciais, segredos e código sensível
aplica bloqueio, redação, tokenização ou aprovação humana
controla modelos, ferramentas e limites de uso
registra a política e a versão utilizadas
produz evidência sob custódia da instituição
O fluxo completo fica assim:
Ampliar ↗Existem dois caminhos explícitos de bloqueio:
Ampliar ↗A rede impede que o gateway seja contornado e o gateway impede que a confiança no destino seja confundida com confiança no conteúdo.
Ampliar ↗Se a camada de rede também inspeciona prompts, esse processamento precisa aparecer no inventário de dados, nos contratos, na avaliação de terceiros e no mapa de transferências. Não é automaticamente proibido, mas altera a postura regulatória da arquitetura.
O comparativo de mercado para a camada de rede#
A categoria SSE/SASE é madura e oferece recursos relevantes para o controle de ferramentas de IA. A escolha, no entanto, não deve se basear apenas na existência de uma funcionalidade chamada “AI Security” ou “GenAI DLP”.
O que importa é entender:
onde o tráfego é processado
onde as políticas são administradas
onde os logs são armazenados
quais conteúdos são retidos
quem possui acesso administrativo
quais planos de dados, controle e gestão permanecem na jurisdição desejada
quais recursos dependem de produtos ou contratos adicionais
Ampliar ↗O comparativo acima não tem como intenção escolher um vencedor, mas sim demonstrar que “o fornecedor tem presença no Brasil” e “todo o processamento e toda a evidência permanecem no Brasil” são afirmações diferentes. Um PoP local pode melhorar a latência e manter parte do data plane próximo ao usuário, mas isso não permite inferir automaticamente onde ficam:
configuração
telemetria
logs
suporte
análise de ameaças
processamento complementar
backups
plano de administração
O mesmo vale para expressões como “Sovereign SASE” (modelo de segurança de rede onde o processamento de dados e a inspeção de tráfego ocorrem inteiramente dentro da infraestrutura privada ou local da empresa): elas podem representar controles relevantes, mas precisam ser decompostas em compromissos verificáveis de arquitetura e contrato.
Por que, neste desenho, o gateway precisa estar no Brasil#
Manter o gateway de conteúdo no Brasil não é uma obrigação literal e universal de localização imposta pela LGPD. A LGPD permite transferências internacionais quando uma das hipóteses do artigo 33 é atendida. A LC 105 estabelece o dever de preservar o sigilo das operações e serviços financeiros, mas também não determina que todo componente técnico esteja necessariamente em território nacional.
Por que, então, adotar essa restrição? Porque o local da inspeção altera o fluxo de dados: se o gateway está fora do Brasil, o conteúdo precisa atravessar a fronteira antes de ser analisado. A transferência internacional já ocorreu, ainda que o sistema bloqueie o prompt logo depois.
Isso não significa que a transferência seja automaticamente ilegal. Significa que ela precisa estar:
mapeada
justificada
apoiada em um mecanismo jurídico aplicável
refletida nos contratos
incluída na análise de fornecedores
submetida aos controles técnicos correspondentes
Quando a inspeção ocorre no Brasil, a instituição consegue detectar e bloquear determinados conteúdos antes da transferência. O que sai pode ser reduzido, redatado ou tokenizado. Aqui um ponto importante: não podemos confundir redação com anonimização: um prompt sanitizado ainda pode conter dados pessoais ou informações confidenciais, dependendo do contexto e da possibilidade de reidentificação. O tráfego restante também precisa passar pela análise jurídica e contratual aplicável. O gateway local não elimina todos os riscos, ele reduz a superfície de exposição e centraliza uma etapa crítica sob controle da instituição.
Essa decisão oferece quatro benefícios principais:
Minimização antes da transferência: conteúdos proibidos podem ser bloqueados antes de sair do país.
Custódia da decisão: a política aplicada e sua evidência permanecem sob controle direto da instituição.
Redução da dependência: a produção da trilha de auditoria não depende exclusivamente de um fornecedor externo.
Consistência: diferentes ferramentas passam pelo mesmo ponto de inspeção e aplicação de políticas.
O gateway também não precisa estar necessariamente em um datacenter físico próprio. Pode operar on-premises, em nuvem privada ou em uma VPC dedicada em região brasileira, desde que a instituição controle:
identidade e acesso
chaves
configuração
política
disponibilidade
logs
retenção
operação
resposta a incidentes
cadeia de fornecedores
A pergunta não é apenas “em qual nuvem ele roda?”, mas quem controla o componente, quem vê o conteúdo e quem consegue produzir a evidência.
Os hooks que defendem antes do gateway#
Antes de o tráfego chegar à rede ou ao gateway, existe uma camada de defesa na máquina do desenvolvedor. No Claude Code, hooks podem ser associados a eventos do ciclo de execução. Eles não substituem o gateway nem o controle de rede, mas permitem bloquear ou detectar comportamentos no ponto mais próximo do usuário.
Ampliar ↗Esse detalhe sobre o é importante: um hook executado depois da escrita não impede que o segredo seja gravado no disco. Ele precisa ser combinado com controles que interrompam o ciclo seguinte, impeçam commit e push, removam o conteúdo e gerem um evento de segurança. A prevenção de vazamento não pode depender de uma única expressão regular. O desenho deve combinar:
padrões determinísticos
scanners de segredos
classificação contextual
regras por repositório
proteção de commit e push
DLP no gateway
resposta automática
revisão humana para casos ambíguos
Os hooks podem ser distribuídos por managed settings. No caso do Claude Code, a opção impede que hooks locais do usuário ou do projeto sejam utilizados fora da política gerenciada, mas existe uma nuance: hooks provenientes de plugins corporativos explicitamente aprovados e forçados pela administração também podem ser permitidos. Portanto, a formulação correta não é apenas hooks instalados pelo MDM executam, mas:
Somente hooks definidos pela política gerenciada ou por extensões corporativas explicitamente aprovadas podem executar.
A distribuição pode ocorrer por MDM, como Intune ou Jamf, por políticas administrativas da própria ferramenta ou por mecanismos corporativos de configuração. Ansible pode participar dessa distribuição, mas é uma ferramenta de automação e gerenciamento de configuração, não um MDM.
Hooks, managed settings e gateway são controles construídos pela instituição sobre a superfície oferecida pelo fornecedor. Eles formam uma camada corporativa que não vem pronta com o produto.
Fail-closed também precisa existir na rede#
Configurar o endpoint dentro da ferramenta não basta.Mesmo que aponte para o gateway corporativo, um usuário, script ou ferramenta diferente ainda poderia tentar acessar diretamente o endpoint público. Por isso, o fail-closed precisa ser reforçado por controles de egress:
resolução DNS controlada
proxy obrigatório
bloqueio de endpoints públicos não aprovados
autenticação mútua ou identidade de workload
credenciais disponíveis apenas no gateway
monitoramento de tentativas de acesso direto
regras específicas para ambientes de CI/CD
segmentação entre desenvolvimento, teste e produção
A estação não deve possuir a credencial de longa duração do provedor. Idealmente, ela se autentica no gateway com sua identidade corporativa, e o gateway injeta ou obtém a credencial necessária para a chamada externa. Isso melhora a revogação, reduz a exposição de chaves e permite aplicar políticas diferentes por usuário, aplicação, repositório ou ambiente.
A trilha de auditoria: o que registrar#
Existe uma decisão deliberada no centro do modelo de auditoria: não registrar o prompt completo por padrão. Guardar integralmente prompts, arquivos e respostas amplia a superfície de tratamento e cria um novo repositório de:
dados pessoais
informações sujeitas a sigilo
código-fonte
credenciais
documentos internos
estratégias comerciais
vulnerabilidades
Essa retenção pode ser necessária em situações específicas, mas precisa de justificativa clara de finalidade, necessidade, acesso, proteção e prazo. Não deve acontecer apenas porque “o log suporta”. A trilha precisa demonstrar o que aconteceu sem reproduzir desnecessariamente todo o conteúdo. Entre os elementos que podem ser registrados estão:
identidade corporativa autenticada
dispositivo
aplicação e repositório
identificador da sessão
ferramenta e versão
modelo e versão
identificador da requisição
HMAC do conteúdo
categorias de dados detectadas
preview redatado, quando realmente necessário
política e versão aplicadas
ação tomada
justificativa de bloqueio
aprovação ou intervenção humana
metadados da resposta
latência e custo
horário
resultado da chamada
Um HMAC com chave sob controle da instituição é preferível a um hash simples quando o objetivo é produzir um identificador verificável sem armazenar o conteúdo original. Um hash comum de textos previsíveis pode ser testado por tentativa e comparação. Ainda assim, HMAC não resolve todos os requisitos de prova. A instituição precisa definir quais evidências demonstram integridade, autoria, sequência temporal e política aplicada.
Fontes da trilha
Ampliar ↗A API de compliance do fornecedor não deve ser tratada como substituta da trilha interna. Seu escopo varia por produto, plano e funcionalidade. Além disso, a disponibilidade de um evento administrativo não significa que o conteúdo completo, o dispositivo ou o repositório estejam disponíveis para correlação. O gateway interno é o ponto em que a instituição consegue construir uma taxonomia consistente entre diferentes provedores e ferramentas.
Por quanto tempo registrar#
Não existe um prazo universal de cinco anos para todos os logs de IA. A Resolução CMN 5.274 determina que a instituição defina o período de retenção de acordo com o tipo de processamento e mantenha os registros de forma segura. O prazo de cinco anos aparece especificamente relacionado à documentação de testes de intrusão e aos respectivos planos de correção. Aplicar cinco anos indiscriminadamente a prompts, respostas, logs de gateway, telemetria de endpoint e eventos administrativos seria uma interpretação excessiva e poderia entrar em conflito com a minimização de dados.
O correto é construir uma matriz de retenção.
Ampliar ↗A retenção também precisa considerar a origem. Alguns eventos podem permanecer disponíveis no fornecedor por períodos limitados. Se forem necessários como evidência institucional, precisam ser exportados para um repositório sob controle da instituição antes de expirarem. O objetivo não é guardar tudo. É preservar evidência suficiente, íntegra e rastreável pelo tempo necessário, sem transformar a observabilidade em um novo passivo.
Superfícies do mesmo fornecedor, regimes diferentes#
O princípio "Produto ≠ Fornecedor" abriu esta série, na Parte 1 (O mapa do que vem pela frente). Aqui ele deixa de ser slogan e vira matriz de decisão. O regime de dados é definido pelo produto, não por quem o assina; e o mesmo fornecedor entrega superfícies com regimes incompatíveis entre si. O mesmo fornecedor pode oferecer:
uma API
uma ferramenta local
uma interface web
uma superfície agentica
um ambiente remoto
uma funcionalidade em alfa/beta
Essas superfícies não compartilham necessariamente o mesmo regime de retenção, auditoria, rede, identidade e administração. A matriz abaixo representa o estado verificado em 29 de junho de 2026. Como essas capacidades mudam rapidamente, devem ser reconfirmadas na documentação e no contrato antes de uma decisão de produção.
Ampliar ↗A conclusão não é que uma superfície seja “boa” e outra “ruim”. É que a aprovação concedida a um produto não pode ser automaticamente estendida aos demais produtos da mesma empresa. ZDR também não deve ser tratado como uma propriedade permanente do nome do fornecedor. Ele depende de:
plano
contrato ou addendum
organização
workspace
modelo
funcionalidade
modalidade de execução
eventuais exceções legais ou de segurança
Uma organização pode possuir ZDR em um workspace de API e, ao mesmo tempo, utilizar outra superfície com retenção diferente.
Uma demonstração concreta do risco#
Em janeiro de 2026, pesquisadores da PromptArmor publicaram uma prova de conceito envolvendo o Claude Cowork. A demonstração utilizava instruções ocultas em um documento para induzir o agente a localizar arquivos e enviar conteúdo para uma conta controlada pelos pesquisadores. A exfiltração utilizava a própria infraestrutura da Anthropic como destino.
Não foi um incidente confirmado em uma instituição financeira mas sim uma demonstração de segurança. Mesmo assim, ela evidencia uma fragilidade importante: confiar apenas no nome do destino não é suficiente. Se a rede considera todo tráfego para “Anthropic” confiável, um agente comprometido por prompt injection pode tentar utilizar justamente esse destino permitido como canal de exfiltração.
É por isso que o controle de rede e o gateway de conteúdo resolvem problemas diferentes.
Enquanto a rede responde:
Esta ferramenta pode se comunicar com esse destino?
O gateway responde:
Este usuário, nesta sessão, pode enviar este conteúdo, para este modelo, com esta finalidade?
Um gateway não é uma garantia absoluta contra prompt injection. Ele pode, contudo, impor limites que a allowlist de destino não consegue oferecer:
bloquear arquivos ou classes de dados
limitar volume e frequência
restringir ferramentas
detectar credenciais e identificadores
impedir uploads
exigir aprovação
registrar a decisão
interromper padrões anômalos
A confiança precisa estar no conjunto de controles, não apenas no domínio para o qual a conexão está sendo aberta.
O que o desenho prova#
A residência de dados foi tratada aqui como uma restrição arquitetural adotada, não como uma obrigação literal aplicável a qualquer cenário. Dessa restrição saíram:
gateway sob controle da instituição
inspeção antes da transferência
egress restrito
fail-closed
contingência com controles equivalentes
hooks gerenciados
identidade central
retenção baseada no tipo de evidência
trilha de auditoria minimizada
avaliação separada por produto
Nenhuma dessas peças, isoladamente, garante conformidade: o gateway pode ser mal configurado; um hook pode falhar; a classificação pode gerar falso negativo; o fornecedor pode alterar uma funcionalidade; telemetria pode ficar incompleta; um modelo com ZDR pode ser substituído por outro que exige retenção. Por isso, arquitetura regulada não é um desenho estático. É um sistema de controles que precisa ser:
versionado
testado
monitorado
revisado
evidenciado
adaptado quando a superfície muda
Política sem arquitetura é uma promessa e arquitetura sem operação é apenas um diagrama. O controle existe quando o desenho, a configuração, a evidência e o processo apontam para a mesma direção.
A Parte 5 troca de pergunta. A arquitetura garante por onde o dado passa e quais controles são aplicados, mas não garante que o código gerado esteja correto. “A IA gerou” não é defesa para um requisito inventado, uma validação omitida ou uma vulnerabilidade introduzida no repositório.
É aí que entra o desenvolvimento orientado por especificação. A Parte 6 fecha o conceito que atravessou este artigo inteiro. Hooks, managed settings, gateways, identidade, observabilidade e políticas são a camada construída pela instituição sobre aquilo que o fornecedor entrega.
A política promete, a arquitetura restringe, a operação evidencia. E, diante de um auditor, não basta mostrar o que deveria acontecer. É preciso demonstrar o que o sistema impediu, permitiu e registrou.
A Parte 3, “Frameworks na prática”, traduziu NIST AI RMF, ISO/IEC 42001, OWASP e GAIG em controles e evidências. A Parte 5 entra em spec-driven development com IA.
Links:
Parte 1 - O mapa do que vem pela frente: https://bit.ly/4oXLCsi
Parte 2 - O labirinto regulatório brasileiro: o que BACEN, CVM, ANBIMA e LGPD exigem antes do primeiro prompt: https://bit.ly/4wfQRG1
Parte 3 - Frameworks na prática: NIST AI RMF, ISO 42001, OWASP e GAIG traduzidos em controle e evidência: https://bit.ly/4vzlXZf
CVE-2026-21852: https://nvd.nist.gov/vuln/detail/CVE-2026-21852