Retenção de dados em LLMs e ZDR: quem lê seus prompts

Seu prompt não vai simplesmente para “a empresa de IA”. Em uma stack de agentes, ele passa em texto puro por vários participantes. Quais deles terão acesso depende da arquitetura: a telemetria do framework de agentes, uma plataforma de tracing, um armazenamento de memória, uma ferramenta de analytics, um gateway de IA e um de três tipos de provedor de inferência. Cada um tem sua própria política de retenção, região de armazenamento e cláusula de treinamento. Em geral, quem guarda seus prompts por mais tempo está do seu lado da API. Os fornecedores de modelos apagam os logs padrão em cerca de 30 dias, enquanto serviços de tracing e memória normalmente mantêm os dados até você apagá-los. A retenção zero de dados (ZDR) é um acordo real e útil, mas define apenas um desses participantes em apenas um de três eixos. Este artigo mapeia toda a cadeia, o que cada parte retém e por quanto tempo, além do que o ZDR cobre e não cobre.

TL;DR

• Todo ponto que recebe texto puro pode coletá-lo. Tracing e armazenamento de memória no lado do agente guardam prompts por muito mais tempo do que qualquer provedor de modelos.
• A retenção dos provedores varia por recurso: na API do Claude, o cache pode usar ZDR, os jobs em lote persistem por 29 dias e o Fable 5 exige retenção por 30 dias.
• A localização dos dados depende de onde o serviço roda: a API oficial do DeepSeek armazena dados na China e não oferece outra opção.
• Endpoints gratuitos são o maior risco: o direito de usar os dados para treinamento geralmente é o preço da capacidade gratuita.
• O ZDR resistiu a uma ordem judicial: a ordem de preservação no processo do NYT isentou apenas clientes da API com retenção zero.

Quem pode ler seu prompt em uma stack de agentes?

Todos no caminho. E esse caminho é mais longo do que aparece nos diagramas da maioria das equipes:

Siga o fluxo da esquerda para a direita. A camada do agente é sua, mas raramente só sua. Frameworks incluem telemetria. Plataformas de tracing e observabilidade existem justamente para armazenar prompts e respostas completos. Recursos de memória gravam conversas em bancos vetoriais que não expiram sozinhos. Um script de analytics com replay de sessão na interface web pode capturar o prompt enquanto o usuário digita, antes mesmo de o backend recebê-lo. O gateway representa um participante quando você mesmo o opera e dois quando usa SaaS. Gateways SaaS se dividem em dois tipos. O primeiro é o agregador multiprovedor: uma única API distribui cada requisição entre os provedores integrados. A postura de dados é sempre a soma da política do gateway com a política do host que recebeu aquela requisição. O segundo tipo vem de fornecedores de segurança: gateways de prevenção contra perda de dados (DLP) e guardrails. O produto existe para inspecionar payloads, fazer redação e aplicar políticas. Ler cada prompt faz parte da funcionalidade, e prompts sinalizados normalmente são retidos de propósito como eventos de segurança.

Atrás do gateway há três tipos de provedor de inferência: a API do próprio fornecedor do modelo, um provedor de cloud hospedando o modelo dentro da sua conta e hosts de GPU servindo pesos abertos segundo suas próprias políticas de logging. O caminho alternativo, inferência self-hosted em um tenant dedicado ou nas suas próprias GPUs, é o único em que terceiros não processam o texto puro. Mas existe uma ressalva, à qual voltaremos.

A regra que organiza todo o restante é: ver e guardar são questões diferentes. Tecnicamente, qualquer componente pode coletar os dados. Saber quais fazem isso exige examinar configurações padrão, ajustes e contratos. E os padrões variam muito ao longo da cadeia.

Quem realmente guarda seus prompts?

Na maioria das vezes, suas próprias ferramentas, e por mais tempo do que qualquer outro participante. Os períodos de retenção dos provedores que dominam os questionários de segurança são medidos em dias. Os armazenamentos no lado do agente que ninguém inclui nesses questionários retêm os dados para sempre.

A camada do agente retém dados de propósito. O produto de uma plataforma de tracing é um banco de dados com seus prompts e outputs. A retenção é uma configuração do projeto, não um acidente de política. Os padrões variam conforme a ferramenta e precisam ser conhecidos. A integração OpenTelemetry do GitHub Copilot exporta estrutura de spans, tempos e contagens de tokens, mas não o conteúdo dos prompts, a menos que você habilite explicitamente a captura de conteúdo. Esse é o modelo conservador de privacidade que mais ferramentas de agentes deveriam copiar. O modo de privacidade do Cursor existe porque o modo padrão compartilha dados do código. Mesmo que o provedor do modelo apague tudo após 30 dias, seu armazenamento de traces ainda terá os dados no dia 300.

O gateway guarda aquilo que você decide guardar. Nenhum gateway pode evitar registros de uso, pois a cobrança depende de contagens de tokens, modelos e timestamps por requisição. Mas ele pode deixar de armazenar completamente os payloads: os corpos de prompts e respostas podem passar pela memória sem nunca serem gravados em armazenamento persistente. Dois recursos populares de gateway cruzam essa linha sem chamar muita atenção. Um console de inspeção de requisições ou observabilidade armazena payloads por definição, assim como um tracing SaaS no ponto anterior. O cache no gateway também armazena o conteúdo dos prompts nesse ponto da cadeia. Um cache semântico guarda um embedding do prompt e a resposta completa em cache. Um cache de respostas guarda os dois lados literalmente, no disco em que o gateway roda. Ao avaliar um gateway, seja SaaS ou self-hosted, faça a mesma separação em três perguntas: o que entra no registro da requisição, o que a interface de observabilidade persiste e o que o cache grava?

A retenção dos provedores varia por recurso, não por empresa. O melhor modelo mental vem diretamente da documentação de retenção da API da Anthropic, que informa a qualificação de cada recurso. O prompt cache pode usar ZDR porque o estado do cache fica apenas em memória. O processamento em lote armazena jobs por 29 dias porque jobs assíncronos precisam de armazenamento. Containers de execução de código persistem por até 30 dias. Arquivos enviados ficam disponíveis até você apagá-los. A página contém uma frase direta que merece ser citada: usar um recurso com estado “é uma escolha de deixar seu acordo de ZDR para aqueles dados específicos”. No caso da OpenAI, a documentação de controles de dados informa quais endpoints podem usar ZDR, mantém logs de monitoramento de abuso por até 30 dias por padrão e documenta que prompts em cache ficam como tensores chave-valor criptografados no armazenamento local da GPU, com TTL limitado. A exclusão comercial padrão na API do Claude ocorre em até 30 dias.

Onde os dados ficam fisicamente?

Onde estiver a infraestrutura que atende à requisição. Cada tipo de provedor responde de forma diferente. Um modelo hospedado em cloud oferece o caso mais sólido: no Amazon Bedrock, o provedor de cloud atua como operador dos dados e a inferência permanece na região escolhida. Por isso, empresas reguladas costumam começar por essa opção. A API do próprio fornecedor do modelo roda onde o fornecedor mantém sua infraestrutura. A OpenAI oferece processamento regional nos EUA e na UE para a maioria dos endpoints. Fornecedores menores muitas vezes não publicam nenhuma informação. No extremo mais claro está o DeepSeek. Sua política de privacidade informa que os dados pessoais são coletados, processados e armazenados na República Popular da China, sem opção nos EUA ou na UE para a API oficial. Os mesmos pesos abertos servidos por um host de GPU nos EUA não carregam essa localização. Isso mostra com clareza que o destino dos dados de um modelo depende de quem o serve, não do modelo.

Há dois prolongamentos além da cópia principal. Caches e arquivos de jobs em lote permanecem na região de processamento durante seus próprios períodos de vida, separados do log da requisição. Além disso, todo provedor depende de suboperadores, ou seja, seus próprios fornecedores, e de backups. Os compromissos de exclusão normalmente se referem à remoção dos sistemas ativos, com prazos adicionais para propagação aos backups. Se o seu diagrama de fluxo de dados termina no logotipo do fornecedor da API, faltam pelo menos essas duas caixas.

Quem exige retenção e quem treina com seus prompts?

Três forças diferentes mantêm os dados além dos prazos padrão. Apenas uma delas aparece no marketing do provedor.

Requisitos de política. Alguns modelos exigem retenção como condição de segurança. O Claude Fable 5 e o Mythos 5 exigem retenção por 30 dias até para clientes com ZDR. A aplicação falha de forma explícita: uma requisição feita por uma organização cuja configuração de retenção não atende ao requisito é rejeitada com um 400, em vez de ser aceita silenciosamente. Escalonamentos por abuso criam outro prazo. Conteúdo sinalizado por violações da política de uso segue um período de retenção completamente diferente. A política da Anthropic para consumidores documenta até 2 anos para inputs e outputs sinalizados e até 7 anos para pontuações de classificadores.

Ordens de preservação judicial. O processo NYT v. OpenAI produziu o experimento prático mais claro sobre promessas de retenção. Uma ordem de preservação de maio de 2025 obrigou a OpenAI a preservar logs de outputs que normalmente seriam apagados, inclusive chats excluídos pelos usuários, em planos de consumidores. A ordem foi restringida em setembro, e posteriormente um tribunal determinou a entrega de 20 milhões de logs de chats na fase de produção de provas. O detalhe relevante para compradores de API: clientes empresariais e com retenção zero foram excluídos da ordem porque não havia dados retidos a preservar. Uma política de exclusão cede diante de uma ordem judicial. Uma arquitetura que nunca armazenou os dados, não.

Intermediários que coletam dados. Intermediários da cadeia são descobertos monetizando texto puro, e o maior caso documentado estava no ponto mais próximo do usuário. Em dezembro de 2025, pesquisadores de segurança documentaram que uma extensão de VPN para navegador, vendida como ferramenta de “privacidade” e com milhões de instalações, injetava scripts em páginas de chats de IA. Ela interceptava todos os prompts e respostas no ChatGPT, Claude, Gemini e outros cinco assistentes, enviando as conversas para uma empresa afiliada de corretagem de dados. A coleta acontecia com a VPN ligada ou desligada e atingia cerca de 8 milhões de usuários da família de extensões da empresa. O incidente envolveu um interceptor no cliente, não um gateway de API, mas a lição vale para todas as caixas do diagrama: qualquer intermediário que processe texto puro pode coletá-lo, a monetização é um incentivo e a interceptação fica invisível nas duas pontas. Confiar em um intermediário é acreditar no modelo de negócio dele, não na lista de funcionalidades.

Cláusulas de treinamento. As APIs empresariais dos principais fornecedores não treinam com seus dados por padrão. Produtos de consumo fazem isso cada vez mais, a menos que você desative a opção. Esse é mais um motivo para executar tráfego de agentes com chaves de API, não com contas de consumidor. Um número crescente de produtos controla o treinamento por uma opção que você precisa encontrar sozinho: planos de consumo com treinamento habilitado por padrão e opt-out escondido nas configurações; ferramentas de desenvolvimento em que a configuração de telemetria ou compartilhamento de código também concede autorização para treinamento; programas de fornecedores que trocam o opt-in para compartilhamento de dados por descontos ou cota gratuita; e painéis de agregadores com controles separados para treinamento nos planos pagos e gratuitos. Cada opção vale por conta e, às vezes, por workspace. O padrão também pode mudar após uma atualização dos termos. “Verificamos uma vez” não é uma estratégia. A auditoria dessas opções deve fazer parte do mesmo checklist recorrente da rotação de chaves.

Modelos gratuitos, destacados de propósito. Todos os riscos acima se concentram em um único lugar: o plano gratuito. O lançamento de um modelo gratuito normalmente é subsidiado por quem se beneficia do tráfego, em geral o próprio fornecedor do modelo. Os prompts enviados à variante gratuita chegam a essa parte segundo a política dela. O direito de treinamento costuma fazer parte do acordo, e o processamento ocorre onde essa parte opera. Para fornecedores chineses, isso significa China. Gateways agregadores publicam políticas de dados por endpoint e oferecem um controle para excluir provedores que treinam com os dados justamente porque essas cláusulas aparecem nas rotas gratuitas. A regra prática é direta: trate um endpoint gratuito como envio de dados, não como uma chamada de API. Alguém paga pela inferência gratuita, e a moeda normalmente são seus prompts.

O que ZDR realmente significa?

O ZDR fixa um de três eixos para apenas um participante da cadeia e somente para recursos qualificados. Isso não é uma crítica. É a definição. Conhecer esses limites permite usar o recurso corretamente.

• Os três eixos. Uso para treinamento, duração da retenção e acesso humano são independentes. APIs empresariais já não treinam com seus dados. O ZDR reduz a retenção dos payloads a zero. O acesso humano é regulado separadamente pelos processos de combate a abuso. Misturar esses conceitos faz o ZDR parecer mais abrangente do que realmente é.
• O que permanece com ZDR. Metadados de uso e registros de cobrança, outputs de classificadores de segurança e qualquer recurso com estado que você habilite. Os dois principais fornecedores agora projetam seus sistemas para contornar a exceção de monitoramento de abuso, não para usá-la: sinais de segurança sem payload de um lado e retenção apenas dos resultados dos classificadores do outro.
• O que o ZDR não alcança. Tudo que vem antes do provedor: seu armazenamento de tracing, os logs do gateway e sua memória vetorial. Um acordo de ZDR com o fornecedor do modelo, enquanto um tracing SaaS mantém todos os prompts indefinidamente, é a postura de retenção mais comum que encontramos, além de ser a menos coerente.
• A ressalva do self-hosting. Rodar pesos abertos nas suas próprias GPUs elimina todos os terceiros, mas sua infraestrutura passa a herdar o problema inteiro: logging de requisições do servidor de inferência, logs de acesso e arquivos de traces. O self-hosting apenas desloca a superfície de retenção. Só uma gestão deliberada dos logs consegue reduzi-la.

Como a Synthorai lida com isso

O gateway está sob nossa responsabilidade, então os compromissos são concretos. No modo de retenção zero, os corpos das requisições e respostas passam pela memória e não são gravados em armazenamento persistente. Só permanece o registro de uso necessário para cobrança: timestamps, modelo, contagens de tokens e um hash do conteúdo, que permite relacionar uma requisição durante uma contestação sem armazenar o que foi dito. Antes do roteamento, a lista de provedores é filtrada: a Synthorai só integra provedores que se comprometem com retenção zero para nosso tráfego, com uma exceção documentada, o Claude Fable 5. A retenção de 30 dias é exigida pelo fornecedor do modelo e não pode ser eliminada por contrato. Escolher o provedor também é escolher a retenção. O trabalho do gateway é deixar essa propriedade explícita em cada rota, em vez de escondê-la em um PDF de política. Uma rota do Fable 5 inclui seu requisito de retenção como metadado documentado, não como surpresa.

Perguntas frequentes

Os provedores de LLMs treinam com dados de API por padrão?

Não. As APIs empresariais dos principais fornecedores não treinam com dados dos clientes por padrão. Esse compromisso aparece na documentação de controles de dados de cada provedor. As exceções se concentram na cauda longa: produtos de consumo com opt-out em vez de opt-in, alguns hosts de GPU que servem pesos abertos e endpoints gratuitos em que o direito de treinamento faz parte do preço.

ZDR significa que o provedor não armazena absolutamente nada?

Não. ZDR significa que os payloads de prompts e respostas não são retidos nos recursos qualificados. Metadados de uso, registros de cobrança e outputs de classificadores de segurança permanecem. Recursos com estado, como jobs em lote ou upload de arquivos, armazenam dados por natureza e ficam fora do escopo do ZDR. Leia a tabela de qualificação por recurso, não apenas o título.

É seguro enviar dados de produção para modelos gratuitos?

Trate um endpoint gratuito como envio de dados, não como uma chamada de API. A capacidade gratuita é subsidiada por quem se beneficia do tráfego, o direito de treinamento costuma fazer parte do acordo e os dados são processados onde a parte que subsidia opera. Para experimentos descartáveis, essa troca pode ser aceitável. Para qualquer conteúdo com dados de clientes, código ou credenciais, quase nunca é.

Self-hosting é automaticamente a opção mais privada?

Ele remove todos os terceiros do caminho percorrido pelo texto puro, o que é uma vantagem real. Mas não elimina a retenção: servidores de inferência, proxies reversos e tracing geram logs por padrão. Uma stack self-hosted com logging padrão pode reter mais dados de prompts do que uma API com ZDR. A privacidade depende da configuração de logs, não do modelo de hospedagem.

Fontes verificadas em 2026-08-29: todas as afirmações sobre provedores acima apontam para a documentação do próprio fornecedor ou para registros judiciais primários. As políticas dessa área mudaram duas vezes no mês anterior à publicação, então consulte os links como fonte atualizada. Esta é uma análise de engenharia, não uma orientação jurídica.

Relacionado: requisito de retenção de 30 dias do Fable 5, como funciona o prompt cache, comparação do cache entre provedores.

← Voltar ao blog