Não mandar documento para a IA: três objeções e o custo de cada

"Não podemos mandar nossos documentos para a OpenAI." A frase aparece na reunião, alguém concorda, e o projeto de IA volta para a gaveta. Ela parece uma objeção só. São três, com respostas e preços diferentes:

1. a IA vai aprender com os nossos documentos e entregar o conteúdo para outra empresa;
2. alguém do fornecedor vai ler o que mandamos;
3. o documento vai sair do Brasil.

Nos projetos, a frase costuma chegar antes de alguém ter lido o contrato do fornecedor. Separar os três medos muda a conversa, porque os dois primeiros se resolvem com contrato e configuração, sem mudar o preço por token. Só o terceiro decide a arquitetura.

As políticas citadas abaixo foram conferidas nas páginas oficiais em 5 de outubro de 2026.

A IA vai aprender com os nossos documentos?

Pela API, não. É a parte mais fácil de responder e a mais repetida como objeção.

A OpenAI declara que, desde 1º de março de 2023, o que entra pela API não é usado para treinar nem melhorar os modelos dela, a menos que o cliente opte por compartilhar. A Anthropic escreve que dado retido "nunca é usado para treinar modelo" sem permissão expressa. A Microsoft, para os modelos que vende pelo Foundry (incluindo os da OpenAI hospedados na Azure), diz que prompts e respostas não ficam disponíveis para a OpenAI e não treinam modelo de fundação sem instrução do cliente. No Amazon Bedrock, os modelos rodam em contas operadas pela própria AWS, e os fabricantes não têm acesso aos logs nem ao conteúdo das chamadas.

O medo tem fundamento em outro lugar: o plano de consumo. Funcionário colando contrato no chat gratuito, com a conta pessoal, está fora de todas essas garantias. O problema ali não é a IA, é o canal. A resposta é dar ao time uma ferramenta oficial pela conta corporativa, que custa a assinatura dela e nada mais.

Alguém do fornecedor pode ler o que mandamos?

Aqui a resposta é "depende do que você pediu no contrato".

Por padrão, a OpenAI guarda logs de monitoramento de abuso por até 30 dias, e esses logs podem conter o prompt e a resposta. Existem dois controles para tirar o conteúdo desses logs, a retenção zero (Zero Data Retention) e o monitoramento modificado, e os dois exigem aprovação prévia da OpenAI. A Anthropic, na API, não retém conversa por padrão, com exceção de alguns modelos que exigem 30 dias; a retenção zero é pedida ao time comercial e ligada por organização. Na Azure, amostras sinalizadas como possível abuso podem passar por revisão humana de funcionários autorizados da Microsoft, e o cliente pode pedir o monitoramento modificado; aprovado, o recurso passa a mostrar ContentLogging como false, o que dá para conferir no portal.

O custo dessa resposta não está na tabela de preço. Está no processo: pedido ao fornecedor, aprovação e, no caso da OpenAI, aceite de requisitos adicionais. Vale pedir antes do primeiro documento real entrar, e não depois de o piloto ter rodado com dado de produção.

O documento sai do Brasil?

Esta é a objeção que tem fundamento técnico, e a única que custa token a mais para resolver.

Nem a OpenAI nem a Anthropic processam no Brasil pela API própria. A lista de regiões de residência de dados da OpenAI tem dez localidades: Estados Unidos, Europa, Austrália, Canadá, Japão, Índia, Singapura, Coreia do Sul, Reino Unido e Emirados Árabes Unidos. Nenhuma na América do Sul. Na Anthropic, o parâmetro de geografia aceita só "global" e "us". E escolher geografia custa: a OpenAI cobra 10% a mais nos endpoints de residência para modelos lançados a partir de março de 2026, e a Anthropic aplica 1,1x em todo token quando a inferência fica nos Estados Unidos.

Para o leitor brasileiro, isso quer dizer que pela API direta a escolha é entre "qualquer lugar" e "outro país específico". Se o contrato com o seu cliente ou uma regra do seu setor exige que o dado fique no Brasil, a API direta do fabricante não atende hoje, e a conversa passa para a nuvem.

Em São Paulo, quase todo modelo fechado roda em modo global

A saída natural é contratar o modelo pela nuvem que a empresa já usa, na região de São Paulo. É onde mora a surpresa.

Em 30 de setembro conferimos a tabela de disponibilidade por região do Amazon Bedrock para os modelos do comparativo de modelos de IA da X-Apps. Dos 11 modelos do comparativo que aparecem no Bedrock, 10 têm em São Paulo apenas a inferência global marcada: a chamada entra pela região brasileira e pode ser processada fora dela. Estão nesse grupo todos os Claude e GPT-5.6 do comparativo que o Bedrock oferece. O único com inferência dentro da região é o Mistral Large 3, que tem pesos abertos.

A Azure tem a mesma divisão com outros nomes. A implantação padrão processa na geografia escolhida pelo cliente. A implantação "Global" pode processar em qualquer geografia onde o modelo esteja, e a "DataZone" em qualquer ponto da zona, como Estados Unidos ou União Europeia. Nos dois casos o dado guardado (arquivos, histórico) fica na geografia do cliente; o que muda é onde o modelo pensa.

Duas consequências práticas. Selecionar "São Paulo" no console não basta: é preciso olhar o tipo de inferência de cada modelo, e conferir de novo quando trocar de modelo. E quando existe endpoint regional, ele pode custar mais: a Anthropic documenta 10% de acréscimo sobre o global nos endpoints regionais do Bedrock e do Google Cloud.

O que o RAG muda: a base fica com você, sai o trecho

Boa parte do medo vem de imaginar o arquivo inteiro sendo despachado para o fornecedor. Num assistente bem construído não é isso que acontece.

Num RAG, a base de documentos fica num banco da empresa. Quando alguém pergunta, o sistema busca os trechos relevantes e manda ao modelo só esses trechos, junto com a pergunta. A Microsoft descreve assim o recurso equivalente dela: o dado continua na fonte que o cliente designou e o serviço não cria uma cópia. O contrato de 80 páginas não viaja; viajam os três parágrafos que respondem à pergunta, na hora da pergunta.

Isso não elimina o envio, mas muda o tamanho do problema. O que sai passa a ser controlável: dá para filtrar por permissão antes da busca, mascarar CPF e nome antes do envio e registrar o que foi mandado. Esse trabalho está detalhado no guia de dados sensíveis em RAG, e é ele que transforma "mandamos documento para a IA" em "mandamos um trecho, autorizado, sem dado pessoal".

Quando a resposta honesta é modelo aberto na sua infraestrutura

Existe o caso em que nenhuma das saídas acima basta: o dado não pode sair do país por contrato, ou não pode sair da rede da empresa por regra do setor. A resposta, então, é um modelo de pesos abertos rodando em servidor que a empresa controla, numa nuvem em São Paulo ou na própria sala.

A troca é de natureza de custo. Some o preço por token e entra o custo de máquina ligada, com placa de vídeo, mais a operação: atualizar o modelo, medir a qualidade, manter a fila funcionando de madrugada. O que vemos nos projetos: o modelo aberto que cabe nesse orçamento fica atrás dos fechados mais recentes em tarefas difíceis, o que obriga a escolher bem o que ele vai fazer. Em extração, classificação e busca em documento interno, a diferença pesa pouco; em raciocínio longo, pesa mais.

É a opção que a X-Apps desenha quando o requisito é esse, na nossa frente de IA local e privada. Ela não é o ponto de partida. É o que sobra quando a pergunta três tem resposta "não pode sair", por escrito.

Qual pergunta levar ao jurídico

A terceira linha merece a pergunta por escrito, porque a resposta "sim" muda a arquitetura e a resposta "não" libera quase tudo. Se o dado for pessoal, a transferência para fora do país tem regra própria na LGPD, explicada em o que a LGPD já obriga antes do marco legal.

Nas reuniões em que a frase aparece, é comum a resposta para a terceira pergunta ser "ninguém sabe". Descobrir isso custa uma conversa com o jurídico, e é a conversa mais barata do projeto inteiro.