--- title: "Anthropic e a destilação: segurança também é controle de uso" author: "Ricardo Pupo Larguesa" date: "2026-09-11 13:26:00-03" category: "Opinião" url: "http://aintuicao.scale.press/portal/aintuicao/post/2026/09/11/anthropic-e-a-destilacao-seguranca-tambem-e-controle-de-uso/md" --- ## Resumo - A Anthropic relatou cerca de 300 mil pedidos encaminhados ao Claude pela Moonshot AI em dez dias, usando 5.380 contas fraudulentas. - O relatório atribui à Alibaba 151 milhões de interações voltadas ao treinamento da família Qwen, com pico de 3 milhões por dia. - Moonshot AI e DeepSeek teriam usado replay entre sessões para reconstruir assinaturas de raciocínio do Claude. - Os redirecionamentos silenciosos podem ter exposto dados sensíveis de usuários a terceiros sem consentimento. - A análise defende que segurança de modelos envolve identidade, finalidade, telemetria e atribuição, além de filtros contra prompts maliciosos. - A Anthropic respondeu com pensamento preservado no Fable 5.1, resumos de raciocínio e exigências maiores de verificação de identidade. - Como o relatório foi produzido pela própria Anthropic, suas atribuições devem ser tratadas como alegações que ainda exigem cautela. --- **Cerca de 300 mil requisições** foram direcionadas ao Claude em um período de dez dias, segundo uma análise sobre o relatório mais recente da Anthropic. A empresa afirma que Moonshot AI e DeepSeek teriam redirecionado silenciosamente solicitações de seus próprios usuários para o modelo da Anthropic, usando as respostas como se fossem geradas por seus sistemas. O episódio coloca a destilação no lugar correto do debate: ela não é apenas um problema de prompt ou de propriedade intelectual, mas também de identidade, observabilidade e controle de acesso. A questão é: Quando uma API é usada para treinar outro modelo, o provedor consegue distinguir pesquisa legítima de captura sistemática de capacidade? ## Uma acusação que precisa ser lida com cautela O relatório **"Detecting and countering misuse of AI"** foi produzido pela própria Anthropic e publicado em 10 de setembro de 2026. Isso dá à empresa acesso privilegiado aos próprios registros, mas também significa que estamos diante da versão de uma parte diretamente envolvida na disputa. A [reportagem da TechCrunch sobre o relatório](https://techcrunch.com/2026/09/10/anthropic-details-distillation-campaigns-from-alibaba-moonshot-ai-and-deepseek) descreve as alegações como campanhas de "destilação ilícita", e não como uma conclusão independente de auditoria. Eu não trataria, portanto, cada atribuição como fato encerrado, mas descartá-la por esse motivo seria igualmente ingênuo. Mesmo com essa ressalva, a escala apresentada pela Anthropic foge da imagem de um desenvolvedor fazendo alguns testes com uma API. O relatório identifica **sete laboratórios baseados na China** em campanhas sistemáticas voltadas às capacidades de raciocínio do Claude. A Alibaba teria concentrado o maior esforço, com **151 milhões de interações** entre maio e julho de 2026, chegando a um pico de 3 milhões de interações por dia para treinar a família Qwen. Quando o volume deixa de ser incidental e passa a seguir uma finalidade de treinamento, a fronteira entre uso de serviço e extração de capacidade fica muito mais difícil de ignorar. ## Quando a API vira matéria-prima para outro modelo O caso atribuído à Moonshot AI é o dado mais fácil de entender e, justamente por isso, o mais perturbador. Em dez dias, a empresa teria roteado cerca de **300 mil pedidos por meio de 5.380 contas fraudulentas**, segundo a análise publicada pela ExplainX. O detalhe não é apenas a quantidade de chamadas, mas o suposto redirecionamento silencioso: o usuário acreditaria estar falando com um serviço, enquanto a resposta viria do Claude. Isso transforma a segurança do provedor em uma questão de transparência para o cliente final, que pode enviar informação sensível sem saber qual empresa está processando seus dados. A técnica descrita também teria tentado capturar mais do que a resposta final. Moonshot AI e DeepSeek foram associadas a **ataques de replay entre sessões**, usados para reconstruir o chain-of-thought a partir de assinaturas de pensamento capturadas. Tecnicamente, a diferença importa: uma resposta isolada pode ensinar um comportamento, mas uma sequência estruturada de raciocínio oferece material mais útil para treinar um sistema concorrente. Não estou dizendo que toda saída de modelo revela seu funcionamento interno, porque a fonte não sustenta essa generalização; estou dizendo que o padrão alegado mostra por que o controle de sessão e a forma de exposição do raciocínio entram na arquitetura de segurança. A acusação ganha outra dimensão quando envolve os usuários finais dos serviços acusados. A análise da ExplainX afirma que os redirecionamentos poderiam ter exposto **dados sensíveis de clientes a terceiros sem consentimento**. Esse é o ponto que costuma desaparecer quando a discussão fica restrita à disputa entre laboratórios: o usuário não autorizou necessariamente que sua requisição fosse enviada a outro provedor, muito menos que ela servisse de insumo para o treinamento de um modelo concorrente. Para quem constrói produto com LLM, a pergunta sobre quem recebe o prompt precisa aparecer no contrato, na telemetria e na interface, não apenas na documentação técnica da API. ## Segurança de modelo começa antes do prompt Durante anos, boa parte das conversas sobre segurança de aplicações com LLM ficou concentrada em jailbreaks, injeção de prompt e retenção de dados. Esses riscos continuam existindo, mas o episódio descrito pela Anthropic mostra uma camada anterior: **quem está usando a integração e para qual finalidade**. Uma conta legítima de pesquisa, um integrador comercial e uma operação de coleta em massa podem usar a mesma rota de API, porém deixam sinais administrativos e comportamentais diferentes. Se o provedor olha somente para o texto enviado, ele pode perder o abuso que acontece na combinação entre identidade, volume, repetição e destino. Se eu estivesse desenhando os controles de uma integração, não começaria por uma lista fixa de palavras proibidas. Eu observaria a coerência entre a identidade declarada e o padrão de chamadas, a concentração de solicitações em contas relacionadas, a repetição de estruturas de consulta e a finalidade informada no cadastro. **Volume sozinho não prova destilação**, porque pesquisadores e empresas também podem executar testes em larga escala; o problema aparece quando o volume se combina com identidades artificiais, redirecionamento oculto ou tentativa de reconstruir sequências de raciocínio. A decisão precisa ser graduada: investigar, limitar, solicitar verificação adicional e só então interromper, em vez de bloquear qualquer uso intenso por reflexo. Esse equilíbrio importa porque controles ruins punem o uso legítimo e controles permissivos subsidiam concorrentes. A Anthropic afirma ter recorrido a **redes de atribuição de proxy** e a exigências maiores de verificação de identidade para enfrentar campanhas de mau uso. Não é uma solução mágica, mas aponta para uma mudança de foco: segurança passa a depender da capacidade de atribuir ações a uma conta, a um grupo de contas e a uma finalidade operacional. Sem essa trilha, o provedor tem poucos meios para separar uma integração real de uma operação que apenas tenta parecer distribuída. ## O que muda para quem coloca IA em produção A lição não é transformar toda integração em uma barreira burocrática. É registrar o suficiente para responder a perguntas que normalmente só aparecem depois do incidente: qual aplicação originou a chamada, qual usuário a acionou, que política autorizou o envio e o que acontece quando o provedor muda suas regras? Na **[T2S](https://t2s.com.br)**, eu levaria essa preocupação para o desenho inicial de qualquer solução que dependa de modelos externos, porque uma arquitetura que não sabe explicar o caminho de uma requisição também não sabe investigar seu uso indevido. O custo de registrar identidade e finalidade costuma ser menor do que reconstruir uma cadeia de acesso depois que os dados já saíram do controle. Essa preocupação se conecta à discussão sobre dependência de provedores que já tratei ao analisar [restrições de acesso a modelos da Anthropic](https://scale.press/portal/aintuicao/post/2026/06/16/restricoes-dos-eua-a-modelos-da-anthropic-e-a-soberania-que-so-vem-de-casa). Há duas perguntas diferentes, mas relacionadas: a empresa consegue continuar operando se perder o fornecedor e o fornecedor consegue provar que controla quem usa sua capacidade? A primeira trata de continuidade; a segunda, de governança. Em ambos os casos, depender de uma API sem telemetria própria, política de fallback e registro de finalidade deixa o sistema vulnerável a decisões tomadas fora da equipe que mantém o produto. ## O próximo movimento é controlar a exposição A resposta da Anthropic já inclui mudanças técnicas na forma de entregar raciocínio. A empresa introduziu **"pensamento preservado" na versão Fable 5.1**, passou a usar resumos de raciocínio por padrão e aumentou as exigências de identidade para contas suspeitas. Essas medidas reduzem o valor de determinadas técnicas de extração, mas não eliminam o problema: qualquer serviço que responda a milhões de requisições continua sendo uma superfície de observação para quem deseja reproduzir comportamentos. Esconder parte da cadeia de raciocínio pode ajudar, mas não substitui governança de acesso. O próximo passo, para provedores e clientes, é tratar cada requisição como um evento que precisa de contexto. Para o provedor, isso significa decidir quais padrões exigem investigação sem destruir a experiência de pesquisadores e integradores legítimos. Para a empresa que usa LLM, significa exigir transparência sobre roteamento, retenção, identidade do subcontratado e uso secundário dos dados. **Segurança de modelos não termina no filtro do prompt**: ela começa quando alguém consegue responder quem chamou, por quê, em qual escala e o que foi feito com a resposta. O relatório da Anthropic pode estar correto em todos os detalhes, em parte deles ou ainda exigir contestação das empresas citadas. A tese que permanece de pé é mais ampla: uma API de IA não entrega somente respostas, entrega acesso mensurável a uma capacidade que alguém pode tentar copiar. Por isso, o erro mais caro é tratar autenticação como etapa administrativa e observabilidade como luxo de operação madura. Se o provedor não consegue distinguir uso legítimo de coleta sistemática, ele não controla de fato o próprio modelo. Para acompanhar outras análises sobre IA, engenharia de software e segurança, conecte-se comigo pelas [minhas redes sociais](https://linktr.ee/ricardo.pupo).