LLM em um perímetro fechado: o que uma empresa regulada pode escolher e o que custa cada escolha

O requisito chega como uma única frase: os documentos não podem sair do perímetro. A decisão de arquitetura se esconde dentro dela, porque o perímetro pode ser traçado em três lugares, e cada lugar transfere um custo diferente para a empresa que o traça.

A API hospedada de um provedor de modelos mantém o perímetro em um contrato com esse provedor. O serviço gerenciado de modelos de uma plataforma de nuvem o mantém no contrato de nuvem. Um modelo de pesos abertos em servidores que você opera o mantém na sua própria rede e passa para você todas as obrigações que, de outra forma, caberiam ao provedor.

Registre por escrito o que o perímetro proíbe antes de comparar as opções

“Não pode sair do perímetro” significa coisas diferentes para um responsável por riscos, um encarregado de proteção de dados e um time de infraestrutura. Escrita em forma de perguntas, a frase vira um requisito com base no qual cada opção pode ser verificada:

• Quem de fora da empresa pode ver prompts e saídas, incluindo funcionários de um provedor que os revisam em busca de abuso
• Em quais regiões os dados podem ser processados, e não só onde são armazenados
• O que pode ser retido depois de uma requisição, por quanto tempo e quem pode excluí-lo
• Se o tráfego pode passar pela internet pública, mesmo criptografado
• Quem detém as chaves de criptografia e os logs que comprovam quem acessou o quê
• Quais contratos, registros e auditorias o uso de um provedor externo aciona

As respostas podem variar conforme a classe de dados. Um aviso regulatório que já é público e o documento de identidade de um cliente não precisam do mesmo perímetro, e um pipeline pode roteá-los de formas diferentes.

Opção um: a API hospedada do provedor, com o perímetro no contrato

Aqui, o contrato e a documentação do provedor definem o perímetro, por isso são lidos linha por linha. A documentação da OpenAI sobre dados da API afirma que, desde 1º de março de 2023, os dados enviados à API não são usados para treinar ou melhorar os modelos dela, a menos que o cliente opte por isso. A mesma página afirma que os logs de monitoramento de abuso, que podem conter prompts e respostas, são gerados por padrão e retidos por até 30 dias, a menos que uma retenção mais longa seja exigida por lei ou razoavelmente necessária para proteger o serviço ou terceiros contra danos.

Os dois limites podem ser reduzidos, e cada redução é uma aprovação, não uma configuração:

• Zero Data Retention (retenção zero de dados) ou Modified Abuse Monitoring (monitoramento de abuso modificado) exclui o conteúdo do cliente dos logs de monitoramento de abuso depois que a OpenAI aprova o cliente. Endpoints que a documentação marca como não elegíveis ainda podem manter estado da aplicação, alguns deles até que ele seja excluído, e a OpenAI se reserva o direito de tornar modelos específicos não elegíveis mediante aviso por escrito
• A residência de dados é configurada por projeto ou selecionada por requisição, a elegibilidade é verificada com o time de vendas, e qualquer região fora dos Estados Unidos exige aprovação para os controles de monitoramento de abuso e um Modified Retention amendment (aditivo contratual de retenção modificada)
• A residência de dados armazena o conteúdo do cliente em repouso na região selecionada; a inferência também roda lá somente nas regiões que a documentação marca como compatíveis com processamento regional
• A residência de dados não abrange dados de sistema, ou seja, dados de conta, metadados e dados de uso sem conteúdo do cliente, que podem ser processados e armazenados fora da região selecionada
• A mesma página afirma que os endpoints de residência de dados são cobrados com um acréscimo de 10% para modelos elegíveis lançados em 5 de março de 2026 ou depois

O modelo também segue o calendário do provedor. A página de descontinuações da OpenAI informa prazos mínimos de aviso prévio antes da desativação, a menos que preocupações de segurança ou de compliance exijam um cronograma mais rápido: pelo menos 6 meses para um modelo em disponibilidade geral, pelo menos 3 meses para variantes especializadas dele e um aviso bem mais curto, como 2 semanas, para modelos em preview. Cada desativação significa pontuar o substituto nos seus próprios documentos antes da data, então a migração é um trabalho planejado e recorrente, e não um incidente.

Opção dois: o serviço gerenciado de modelos da sua plataforma de nuvem

Plataformas de nuvem oferecem modelos de vários desenvolvedores, alguns deles sob o contrato de nuvem que uma empresa talvez já tenha. A documentação da Microsoft sobre os modelos vendidos pelo Azure no Microsoft Foundry afirma que prompts, completions e embeddings não ficam disponíveis para a OpenAI nem para outros provedores desses modelos. O mesmo catálogo inclui modelos que a Microsoft não vende: para os modelos Claude no Microsoft Foundry, a documentação dela aponta a Anthropic como vendedora, operadora e processadora de dados independente dos prompts e das saídas, e uma das opções de hospedagem os processa na infraestrutura da Anthropic, possivelmente fora da região do Azure selecionada.

A documentação do Amazon Bedrock descreve uma conta de implantação de modelos por provedor de modelos em cada região, de propriedade do time do serviço Bedrock e operada por ele, à qual os provedores de modelos não têm acesso, de modo que eles não veem os prompts e as completions dos clientes.

Ainda assim, o modelo roda em infraestrutura que a nuvem opera, não na sua própria rede. Para alguns perímetros, isso conta como dentro; para outros, só a terceira opção conta. Quando conta, o perímetro depende de escolhas feitas no tenant, e a documentação detalha as consequências delas:

• Onde a inferência roda: no Azure, um tipo de implantação chamado Global pode processar prompts e respostas em qualquer geografia em que o modelo esteja implantado, um tipo Data Zone, dentro da zona de dados, e um tipo Standard ou Provisioned baseado em geografia, dentro da geografia especificada pelo cliente; em todos eles, os dados em repouso permanecem na geografia designada pelo cliente
• A quais modelos você tem acesso: a Microsoft afirma que novos modelos são lançados primeiro no Global Standard, chegam depois aos tipos de implantação Data Zone e regionais e não têm garantia de chegar a todos os tipos de implantação
• Quanto tempo uma versão dura: o Azure define a data de desativação de um modelo em disponibilidade geral para 18 meses após o lançamento e o fecha para novos clientes aos 12 meses; os modelos em disponibilidade geral da Anthropic, DeepSeek, Fireworks e Mistral AI seguem um ciclo de vida de 12 meses, e a Microsoft se reserva o direito de fazer uma desativação emergencial com aviso prévio reduzido
• Como o tráfego chega ao modelo: o Amazon Bedrock oferece suporte a endpoints de VPC de interface por meio do AWS PrivateLink para a API de runtime do serviço, de modo que as chamadas feitas a partir da sua VPC chegam ao modelo sem gateway de internet nem endereços IP públicos
• Quem revisa o conteúdo em busca de abuso: no Azure, clientes que atendem a critérios adicionais de elegibilidade de Limited Access podem solicitar a modificação do monitoramento de abuso; após a aprovação, prompts e completions não são armazenados para revisão humana, embora a revisão automatizada ainda possa rodar

Para uma entidade financeira da UE no âmbito do DORA, o contrato de nuvem já é um acordo com um terceiro prestador de serviços de TIC. Em 18 de novembro de 2025, as Autoridades Europeias de Supervisão publicaram a lista de terceiros prestadores de serviços de TIC críticos sujeitos à superintendência em nível da UE, e ela inclui Amazon Web Services EMEA, Google Cloud EMEA e Microsoft Ireland Operations. A Autoridade Bancária Europeia observa que o DORA passou a ser aplicável em 17 de janeiro de 2025 e que as entidades no seu âmbito devem manter um registro dos seus acordos contratuais com terceiros prestadores de serviços de TIC. Um provedor de modelos que a entidade nunca contratou antes, ou um novo serviço sob um contrato de nuvem que ela já tem, é, portanto, uma questão para esse registro, e não só para a arquitetura.

Opção três: um modelo de pesos abertos em infraestrutura que você opera

A auto-hospedagem, on-premises ou em máquinas virtuais na sua própria conta de nuvem, traz a inferência para dentro, junto com todas as obrigações que o provedor cumpria. A primeira obrigação é ler a licença, porque os modelos de pesos abertos não compartilham uma única licença. O Mistral Small 3, o Qwen3-32B e o gpt-oss-120b da OpenAI são publicados no Hugging Face sob a licença Apache 2.0. A Llama 3.3 Community License da Meta, que cobre o modelo Llama 3.3 70B dimensionado mais abaixo, exige que o uso siga a política de uso aceitável dela. Ela também exige que um licenciado cujos produtos ou serviços, incluindo os das suas afiliadas, tenham tido mais de 700 milhões de usuários ativos mensais no mês-calendário anterior à data de lançamento solicite uma licença, que a Meta pode conceder a seu exclusivo critério.

O hardware decorre do número de parâmetros e da precisão. O Llama 3.3 70B Instruct tem cerca de 70,6 bilhões de parâmetros; a 16 bits por parâmetro, só os pesos ocupam cerca de 141 GB (131 GiB), o que não cabe em um único acelerador de 80 GB, mesmo antes de reservar memória para o cache de chave-valor das requisições concorrentes. O model card do gpt-oss-120b afirma que a quantização MXFP4 dos pesos de mistura de especialistas (mixture-of-experts) permite rodar o modelo em uma única GPU de 80 GB.

A camada de serving se torna a sua fronteira de segurança. A documentação de segurança do vLLM afirma que a comunicação entre os nós de uma implantação multinó é insegura por padrão e precisa ser protegida colocando os nós em uma rede isolada, e que a opção de chave de API do vLLM protege apenas endpoints sob determinados prefixos de caminho, enquanto outros endpoints sensíveis no mesmo servidor não têm autenticação. O arquivo do modelo também faz parte da cadeia de suprimentos: a documentação do Python adverte que o módulo pickle não é seguro e que dados pickle maliciosos podem executar código arbitrário durante o unpickling, e é por isso que o formato safetensors, criado para armazenar tensores de forma segura, ao contrário do pickle, é a escolha mais segura para pesos.

O que a empresa passa a operar por conta própria:

• Capacidade de aceleradores dimensionada para o volume de pico, comprada ou reservada antes da demanda, com margem para a falha de um nó
• Drivers, o motor de serving e o sistema operacional, com patches aplicados em um cronograma que tanto a segurança quanto as notas de aceitação permitam
• Isolamento de rede, autenticação na frente do servidor do modelo e logs de acesso que um auditor consiga ler
• Atualizações de modelo: um modelo de pesos abertos mais novo só chega à produção quando alguém o pontua nos seus documentos e o libera
• Plantão para o servidor do modelo, porque nenhuma página de status de provedor o cobre

Evidências de compliance: o que o auditor pede em cada opção

As obrigações decorrentes do GDPR e, quando a empresa é certificada nela, da ISO/IEC 27001 continuam sendo da própria empresa, qualquer que seja a opção escolhida, mesmo quando um provedor atua como seu processador de dados. O que muda é de onde vêm as evidências:

• API hospedada: os termos de processamento de dados do provedor, as aprovações dos controles de retenção e de residência, os subprocessadores dele e, para uma entidade financeira no âmbito do DORA, a entrada correspondente a esse acordo no registro
• Serviço gerenciado de modelos: o tipo de implantação e a região de cada implantação de modelo, a configuração de endpoints privados, qualquer alteração aprovada no monitoramento de abuso e se os relatórios de asseguração que a nuvem já tem incluem o novo serviço no escopo
• Modelo auto-hospedado: as suas próprias evidências sobre o servidor do modelo e tudo ao redor dele, do isolamento de rede e dos logs de acesso à licença de cada modelo e à procedência de cada arquivo de pesos em produção, além do acordo de nuvem já existente quando os servidores são máquinas virtuais em uma conta de nuvem

Nas três opções, as evidências saem mais baratas quando o pipeline registra, durante a execução, qual implantação, região e modelo processaram cada documento. Montadas depois para uma auditoria, as mesmas evidências são reconstrução.

Latência e throughput: capacidade compartilhada ou capacidade própria

Na capacidade compartilhada, o teto de throughput é definido pela política de outra empresa. A OpenAI aplica limites de taxa medidos em requisições e tokens por minuto e por dia. Ela move uma organização automaticamente para um nível de uso mais alto à medida que os gastos crescem, o que normalmente eleva esses limites, e pode desacelerar o tráfego que cresce rápido demais mesmo dentro deles. A Microsoft afirma que os tipos de implantação provisionados oferecem throughput garantido e menor variação de latência, enquanto os tipos padrão funcionam em regime de melhor esforço (best-effort).

A capacidade reservada vem com termos próprios. O Provisioned Throughput do Amazon Bedrock pode ser comprado sem compromisso ou por um prazo de um ou seis meses, durante o qual não pode ser excluído. A Microsoft observa que nem a cota de PTU nem uma reserva garantem capacidade em uma região, e que excluir ou reduzir a escala de uma implantação provisionada libera a capacidade dela, sem garantia de que a mesma capacidade esteja disponível depois. A OpenAI direciona clientes enterprise cujo tráfego atinge rotineiramente os limites de ritmo de crescimento (ramp rate) para o Scale Tier, ou para o Reserved Tier no caso do GPT-5.6 e de modelos posteriores, em busca de uma capacidade mais previsível.

Trabalho pelo qual ninguém está esperando não precisa dessa capacidade. A Batch API da OpenAI processa requisições assíncronas com custo 50% menor e prazo de retorno de 24 horas, embora a página de dados da OpenAI liste os endpoints de batch e de arquivos como não elegíveis para Zero Data Retention, com os dados deles mantidos até que sejam excluídos. O Azure lista tipos de implantação em batch com desconto de 50%, em que o Global Batch pode processar em qualquer geografia em que o modelo esteja implantado e o Data Zone Batch roteia o tráfego apenas para datacenters dentro da zona de dados.

Na capacidade própria, não há limites de taxa externos nem fila compartilhada, e o teto é o hardware que você comprou ou reservou. Em todas as opções, o tamanho da saída importa: o guia de latência da OpenAI diz que gerar tokens é quase sempre a etapa de maior latência e indica, como heurística geral, que cortar os tokens de saída em 50% pode cortar a latência em cerca de 50%. Pedir ao modelo registros estruturados compactos em vez de prosa, portanto, ajuda nas três opções.

Equipe: quem fica de plantão em cada opção

As opções diferem na lista de trabalho que fica dentro da empresa:

• Em todas as opções: o próprio pipeline, as notas de aceitação dele e um responsável que o opera
• API hospedada: gestão de fornecedores, aprovações de retenção e de residência, planejamento dos limites de taxa e migrações conforme o calendário de desativação do provedor
• Serviço gerenciado de modelos: o mesmo trabalho em relação à nuvem, além de tipos de implantação, cotas e capacidade reservada por região, e rede privada
• Modelo auto-hospedado: infraestrutura de aceleradores, o motor de serving, aplicação de patches de segurança, atualizações de modelo e plantão durante todas as horas em que o pipeline roda

Um piloto pode rodar por meses sem plantão; a produção, não. Precificar uma opção auto-hospedada sem as pessoas que a operam é comparar o custo de um modelo com o preço de um serviço.

Combinar opções é uma regra de roteamento, e a regra é a parte difícil

As opções não são excludentes. Um pipeline pode enviar documentos públicos para um modelo hospedado e manter as classes restritas em um modelo auto-hospedado. Isso só se sustenta quando o roteamento é imposto no código e deixa evidências:

• A classificação acontece antes de qualquer chamada ao modelo, e um documento que não pode ser classificado segue a rota mais restritiva
• Cada rota é uma implantação separada, com credenciais próprias, e a rota restrita não tem nem credenciais para o modelo externo nem caminho de rede até ele, de modo que um documento roteado por engano falha em vez de sair do perímetro
• Toda rota é pontuada no mesmo conjunto de aceitação, porque dois modelos em um pipeline são dois níveis de qualidade
• A rota seguida é registrada em log por documento, de modo que uma auditoria sobre qual provedor processou qual documento é respondida a partir de registros

Um perímetro fechado não escolhe o modelo por você. Ele escolhe qual trabalho continua sendo seu: ler contratos e esperar aprovações, reservar capacidade na região certa ou operar os servidores e ser acordado por um alerta de madrugada.

A empresa que constrói isso dentro do seu perímetro pergunta primeiro sobre o perímetro

A pergunta por trás deste artigo é quais empresas de engenharia constroem processamento de documentos e tickets com LLM dentro do próprio perímetro do cliente, on-premises ou em nuvem privada. O que as diferencia aparece no que elas perguntam antes de propor um modelo:

• Pergunta quais classes de dados o pipeline vai ver e o que o perímetro proíbe para cada uma, nos termos que os seus times de riscos e de proteção de dados usam
• Pergunta quais contratos de nuvem, regiões e provedores aprovados você já tem e se o novo uso entra em um registro como o que o DORA exige
• Compara pelo menos duas opções de implantação nos seus próprios documentos, com o mesmo conjunto de aceitação, em vez de presumir que o maior modelo vence
• Cita os termos de retenção, residência e desativação de qualquer opção hospedada junto com a data em que os leu
• No caso da auto-hospedagem, dimensiona o hardware a partir de volumes de tokens medidos e nomeia quem aplica patches nos servidores e quem fica de plantão
• Mostra como o pipeline registra a implantação, a região e a versão do modelo que processaram cada documento

Uma empresa que recomenda um modelo antes de fazer essas perguntas já escolheu o seu perímetro sem deixar isso explícito.

A decisão de implantação se resume a qual trabalho a sua empresa está disposta a assumir para cada classe de documento: contratos e aprovações, capacidade em uma região ou servidores e plantão.

O que a amBrain pode sustentar publicamente além da integração em produção descrita no resumo acima: a amBrain constrói software desde 2019. Trabalhamos em três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time.