amBrain
FinTechOct 8, 202610 min de leitura

API, auto-hospedado ou híbrido: como uma empresa regulada pode processar documentos com LLM e quem leva isso à produção

Processamento de documentosConfiguração híbrida de LLMSetores reguladosQuem constrói
Erro ao carregar a imagem

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.

Como as três abordagens se comparam?

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.

Como é uma configuração híbrida na prática?

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:

  • Documentos públicos ou de baixo risco, como normas e orientações publicadas, vão para a API, e os documentos de identificação dos clientes ficam dentro
  • Todo documento passa primeiro pelo modelo auto-hospedado, e aqueles em que ele falha só saem se a classe deles permitir
  • Identificadores como nomes são substituídos por marcadores dentro do perímetro antes de o texto ir para a API

Quem decide quais documentos podem ir para uma API?

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.

Podemos mascarar o texto e mandá-lo para a API mesmo assim?

À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:

  • O reconhecimento óptico de caracteres (OCR), a etapa que transforma digitalizações em texto, lê um nome errado, e o detector deixa de enxergar ali um nome
  • Uma pessoa é identificada sem nenhum nome, por um cargo em uma empresa pequena ou por um valor único em uma data específica
  • O campo mascarado é justamente o que você precisa: se a tarefa é extrair o nome da contraparte, o texto mascarado não o contém mais

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.

O que acontece quando um documento segue a rota errada?

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.

Como testar a qualidade quando dois modelos fazem o trabalho?

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.

O que é preciso para operar as duas rotas?

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.

O que a trilha de auditoria deve mostrar para cada documento?

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.

Quando uma configuração híbrida é a escolha errada?

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.

Como verificar se uma empresa levou isso do piloto à produção?

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.

  • A tabela de roteamento como documento versionado e o nome da pessoa que aprova as alterações
  • Algumas linhas do log de rotas, com classe, rota, versão da tabela de roteamento e versão do modelo de cada documento
  • A execução mais recente de um teste que envia um documento restrito em direção ao provedor externo e mostra que ele é barrado
  • Pontuações de aceitação por rota e por release, incluindo a release feita quando um provedor desativou um modelo
  • Se o desenho mascara texto, as falhas medidas do detector nos documentos de um cliente
  • O runbook (instruções escritas para os operadores) para uma indisponibilidade de cada rota, e quem está de plantão
  • Uma ligação com a pessoa que opera o sistema hoje

Quais são os sinais de alerta?

  • O mascaramento é apresentado como a resposta completa de privacidade, sem taxa de falhas medida
  • A verificação que decide o que pode sair consulta a própria API externa
  • O tráfego passa para a API quando o modelo interno cai, o que leva junto documentos restritos para fora
  • Nenhuma pontuação por rota, apenas um número de acurácia para o pipeline inteiro

Onde a amBrain se encaixa?

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.

Perguntas comuns

  • O mascaramento nos permite mandar todos os documentos para a API? Não. Um texto mascarado que você consegue vincular de volta a uma pessoa continua sendo dado pessoal para você, e os detectores deixam passar alguns identificadores. Use o mascaramento para reduzir a exposição em classes que já podem sair
  • Um modelo auto-hospedado consegue igualar a qualidade do modelo da API? Em alguns tipos de documento, sim. Pontue os dois no conjunto compartilhado de documentos permitidos nas duas rotas antes de decidir como dividir o trabalho
  • Podemos começar com uma rota e adicionar a segunda depois? Sim, e muitas vezes esse é o caminho mais barato. Construa o roteador e o log de rotas desde o primeiro dia, para que adicionar a segunda rota depois não signifique reconstruir o pipeline

Tem um projeto assim na mesa?

Traga sua arquitetura atual e o modo de falha que preocupa você, e vamos analisá-lo juntos em meia hora.