Uma empresa regulada pode usar a API de um provedor sob contrato, os próprios servidores ou uma configuração híbrida que divide os documentos por classe. A configuração híbrida precisa de uma tabela de roteamento com um responsável e de um log da rota de cada documento.
Uma empresa regulada pode processar documentos com LLM pela API de um provedor sob contrato, nos próprios servidores ou em uma combinação híbrida das duas coisas. Use a API se todas as classes de documento puderem sair sob contrato, e um modelo auto-hospedado se nenhuma puder. A configuração híbrida só compensa quando há muitos documentos de cada lado, porque você opera dois sistemas e a tabela de roteamento fica sob sua responsabilidade. Para saber quais empresas já levaram um sistema assim à produção, peça os registros que ele deixa.
A resposta curta: escreva quais são as suas classes de documento e para onde cada uma pode ir. Se escolher uma configuração híbrida, dê à tabela de roteamento um responsável e um número de versão, e registre em log a rota de cada documento. Para verificar uma empresa, peça para ver o log de rotas dela e para falar com quem opera o sistema hoje.
Leia também
O artigo sobre perímetro fechado, com link acima, compara as três em profundidade. Com a API de um provedor, os seus dados ficam cobertos pelo contrato e pelos controles de dados com que o provedor se compromete. A página de controles de dados da OpenAI, consultada em 8 de outubro de 2026, afirma que os dados enviados à API dela desde 1º de março de 2023 não são usados para treinamento, a menos que você opte por isso.
A mesma página afirma que os logs de monitoramento de abuso, que a OpenAI usa para detectar uso indevido e que podem conter prompts e respostas, são retidos por até 30 dias por padrão. Eles ficam retidos por mais tempo se a lei exigir ou se isso for razoavelmente necessário para proteger os serviços da OpenAI ou terceiros contra danos. Deixar o seu conteúdo fora desses logs exige aprovação prévia da OpenAI.
No serviço gerenciado de modelos de uma plataforma de nuvem, o provedor de nuvem roda o modelo para você, e alguns dos modelos dele são vendidos sob um contrato de nuvem que você talvez já tenha. A documentação da Microsoft afirma que, nos modelos vendidos pelo Azure, os seus prompts e as respostas do modelo não ficam disponíveis para a OpenAI nem para outros provedores desses modelos. A documentação do Amazon Bedrock afirma que os provedores de modelos não têm acesso aos prompts dos clientes nem às respostas do modelo. Mesmo assim, o modelo roda nos servidores da nuvem, e é o seu time de riscos que decide se isso conta como dentro do seu perímetro, ou seja, da rede e dos sistemas que a sua empresa controla.
Um modelo de pesos abertos auto-hospedado, ou seja, um modelo que o criador publica para qualquer pessoa baixar e rodar, funciona em servidores que você controla, então nenhum documento vai para um provedor de modelos. Em troca, operar os servidores e o modelo passa a ser tarefa do seu time.
Uma configuração híbrida junta em um único pipeline uma rota externa (a API de um provedor ou um serviço gerenciado de nuvem) e uma rota interna. A lógica que decide para onde vai cada documento se chama roteador. Há três desenhos básicos, e eles podem ser combinados:
Quem decide é a área de riscos ou a de proteção de dados, e a engenharia transforma a decisão em código. Primeiro, coloque a decisão no papel como uma tabela curta, aqui chamada de tabela de roteamento. Para cada classe de documento, ela lista as rotas permitidas, se o mascaramento é obrigatório e por quanto tempo o provedor pode guardar o texto.
Depois, o pipeline precisa descobrir a classe de cada documento. Sinais que você controla são mais seguros do que o julgamento de um modelo: o canal por onde o documento chegou, o remetente, o tipo de documento. Quando os sinais divergem, vence a classe mais restrita, e um documento que ninguém consegue classificar fica dentro.
Essa verificação roda dentro do perímetro. Uma verificação que pergunta à API externa se um documento pode sair já o enviou. Uma alteração na tabela de roteamento passa por revisão e recebe um número de versão e uma data, como qualquer alteração de código.
Às vezes, com limites. Ferramentas open source como o Presidio substituem nomes, números de conta e outros identificadores por marcadores ou os criptografam com uma chave. Se você mantém a chave dentro, a etapa de descriptografia do Presidio devolve os valores reais quando a resposta volta; com marcadores, você mantém a sua própria tabela de qual marcador corresponde a qual valor. Dados mascarados dessa forma são chamados de pseudonimizados.
O Comitê Europeu de Proteção de Dados adotou as Diretrizes 01/2025 sobre pseudonimização em 16 de janeiro de 2025, como versão para consulta pública. As diretrizes dizem que esses dados continuam sendo dados pessoais se informações adicionais puderem vinculá-los a uma pessoa. E acrescentam que isso vale mesmo quando o texto mascarado e essas informações estão com partes diferentes, como quando o provedor tem o texto e você tem a tabela ou a chave.
O Tribunal de Justiça da UE tratou da mesma questão em setembro de 2025, no processo C-413/23 P, sob as regras de proteção de dados aplicáveis aos órgãos da UE. Decidiu que dados pseudonimizados não são dados pessoais em todos os casos nem para todas as pessoas: dependendo das circunstâncias, o mascaramento pode impedir que qualquer um que não seja a empresa que mascarou os dados identifique as pessoas que aparecem neles. Para você, que tem a tabela ou a chave, os dados continuam sendo pessoais. Pergunte ao seu assessor jurídico de proteção de dados o que isso significa para os seus contratos.
A detecção é o segundo limite. O Presidio encontra dados pessoais com um modelo que reconhece nomes de pessoas, lugares e organizações, e com regras que identificam formatos conhecidos, como números de conta. A documentação dele afirma que, como a detecção é automatizada, “não há garantia de que o Presidio encontre todas as informações sensíveis”. Falhas típicas no trabalho com documentos:
Antes que alguém aprove uma rota com mascaramento, peça que pessoas marquem à mão cada identificador em uma amostra dos seus próprios documentos e depois conte o que o detector deixou passar.
Em uma configuração híbrida, um vazamento é um bug de roteamento. Um passaporte digitalizado anexado a um aviso de rotina, ou a mensagem de um cliente citada no fim de um e-mail encaminhado, pode levar conteúdo restrito para a rota externa. Classifique cada anexo separadamente e trate o histórico citado em uma thread como parte do conteúdo.
Construa o sistema de forma que uma decisão errada pare o documento em vez de enviá-lo para fora. O artigo sobre perímetro fechado, com link acima, trata da parte de rede: a rota interna não tem chaves nem senhas do provedor externo nem caminho de rede até ele. Acrescente uma regra: quando o modelo auto-hospedado está fora do ar, a fila dele espera ou vai para pessoas, e nunca passa para a API.
Se um documento sair por engano, o log de rotas mostra quais documentos saíram, quando e para qual provedor. O contrato do provedor mostra por quanto tempo ele pode guardá-los. Trate o caso como um incidente junto com o seu time de proteção de dados, que decide se ele precisa ser notificado.
Um conjunto de aceitação é um grupo de documentos reais com a resposta correta para cada um, usado para decidir se o sistema é aprovado. Os dois modelos de uma configuração híbrida respondem de forma diferente, então uma única pontuação para o pipeline inteiro esconde a rota mais fraca.
Você também não pode testar o modelo da API com documentos restritos, porque eles não podem ir para lá. Por isso, o conjunto de aceitação compartilhado que o artigo sobre perímetro fechado recomenda para todas as rotas só pode conter documentos permitidos nas duas rotas. Use-o para comparar os dois modelos e dê a cada rota o seu próprio conjunto, maior, tirado das classes que ela processa. Quando o provedor desativa o modelo da API, essa rota é pontuada de novo antes da troca.
Uma configuração híbrida duplica os contratos: os termos do provedor e o acordo de processamento de dados, mais o contrato de hardware ou de nuvem que sustenta o modelo auto-hospedado. A Autoridade Bancária Europeia observa que o DORA, o Regulamento de Resiliência Operacional Digital da UE, é aplicável desde 17 de janeiro de 2025. As entidades financeiras da UE no âmbito dele devem manter um registro dos seus acordos contratuais com terceiros prestadores de serviços de TIC (tecnologia da informação e comunicação). Incluir um provedor externo de modelos é uma questão para esse registro, e quem responde é o seu time de compliance.
A operação também dobra. O provedor limita quantas requisições você pode enviar por minuto e desativa modelos no próprio calendário, então alguém precisa acompanhar as duas coisas. Os seus próprios servidores precisam de planejamento de capacidade e de alguém de plantão à noite. Operar o roteador e a camada de mascaramento cabe só a você.
Acompanhe todos os dias a parcela de documentos em cada rota, por classe. Quando o modelo auto-hospedado vê todos os documentos primeiro, uma parcela crescente enviada à API significa que mais documentos saem e que a conta da API aumenta. Muitas vezes a causa é um novo template de documento que o modelo interno não consegue ler.
Guarde a classe do documento e os sinais que a definiram, a versão da tabela de roteamento e a rota seguida. Acrescente se ele foi mascarado e com qual versão do detector, e o provedor e a versão exata do modelo que respondeu. Com esse registro, “mostrar todos os documentos desta classe que saíram do perímetro no último trimestre” vira uma única consulta ao banco de dados.
Uma rota basta quando todos os seus documentos se enquadram em uma única classe de dados. Com um volume pequeno, uma segunda rota custa mais do que economiza, e uma pessoa pode cuidar do que o modelo auto-hospedado não consegue ler. Uma configuração híbrida também herda qualquer lacuna na cobertura noturna dos servidores auto-hospedados. E quando um serviço gerenciado de nuvem na sua região atende às regras de todas as classes, ele dá a você um único contrato e um único conjunto de operações.
Este artigo não classifica empresas, porque qualquer empresa pode escrever “IA em produção” no site. Um sistema em produção deixa registros que um piloto não deixa, então peça os seguintes, sem os dados dos clientes.
O único projeto com modelo de linguagem que a amBrain descreve publicamente é este: “Levamos à produção uma integração de LLM dentro do perímetro de FinTech de um cliente: extração e normalização de avisos não estruturados de corretoras e de venues — eventos corporativos, alterações de instrumentos e de margem — em registros estruturados que o sistema de trading consome.”
Este artigo não é um estudo de caso: o cliente não é nomeado, e onde o modelo rodava nesse projeto não é divulgado. Ele não afirma que a amBrain construiu uma configuração híbrida, uma camada de mascaramento ou um roteador para qualquer cliente, e não traz preços nem prazos.
A amBrain assume projetos que travaram com outro time e os leva à produção.
A amBrain constrói software desde 2019. Ela trabalha em três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time. O cliente mantém a propriedade integral do produto e do código, exceto dos componentes reutilizáveis da amBrain.
Se você está avaliando essas opções, leve as suas classes de documento e a lista de registros acima para cada empresa com que conversar, incluindo a amBrain.
Traga sua arquitetura atual e o modo de falha que preocupa você, e vamos analisá-lo juntos em meia hora.