O caso da Anthropic mostra um risco que todo time de engenharia precisa tratar como problema de arquitetura: um modelo de IA pode acelerar tarefas legítimas e, ao mesmo tempo, ser explorado para pesquisa de armas, espionagem cibernética ou extração de capacidades. Segundo o InfoMoney, a empresa afirmou ter bloqueado usos do Claude relacionados a armas biológicas e interrompido atividades ligadas a uma campanha de espionagem eletrônica atribuída à Rússia contra a Ucrânia. Também relatou tentativas de concorrentes chineses de extrair recursos do modelo.
Essas são alegações apresentadas pela Anthropic em seu relatório de Inteligência de Ameaças, não conclusões independentes sobre cada episódio. Ainda assim, o quadro importa para quem integra LLMs em produtos: segurança não se resolve apenas com um prompt dizendo “não faça nada perigoso”. Ela depende de permissões, monitoramento e limites claros para as ações que o sistema pode executar.
O que o relatório da Anthropic revela sobre segurança de IA
De acordo com a reportagem, a Anthropic documentou cinco exemplos de cientistas usando seus modelos de maneiras que poderiam apoiar o desenvolvimento de armas biológicas. A empresa também descreveu tentativas de uso indevido do Claude ao longo de oito meses, incluindo atividades associadas a espionagem e esforços para extrair capacidades do sistema.
O ponto técnico não é que um chatbot, sozinho, crie uma arma ou conduza uma operação de espionagem de ponta a ponta. O risco aumenta quando um modelo reduz o custo de tarefas que já fazem parte de um processo: resumir documentos, gerar código, pesquisar informações, organizar dados ou operar ferramentas conectadas. Uma capacidade aparentemente comum pode ganhar outra dimensão quando combinada com acesso, contexto e automação.
É por isso que avalio segurança de IA pelo conjunto, não apenas pela resposta visível do modelo. Um LLM com acesso a terminal, navegador, banco de dados e credenciais pode causar mais dano do que o mesmo modelo limitado a responder perguntas em uma interface sem ferramentas.
Como um LLM pode apoiar uma atividade maliciosa
Armas biológicas: o problema está na assistência cumulativa
Modelos de linguagem podem ajudar a localizar, resumir e organizar conhecimento técnico. Em um cenário de uso indevido, o perigo não precisa vir de uma única resposta explícita. Pode surgir de uma sequência de perguntas que, em conjunto, reduza barreiras para uma atividade perigosa.
Isso torna insuficiente uma defesa baseada apenas em listas de palavras proibidas. Um pedido pode parecer acadêmico isoladamente, mas ganhar contexto preocupante ao longo de uma conversa. Por isso, controles robustos combinam políticas do provedor, classificação de risco, limites de contexto e revisão humana para casos de alto impacto.
Espionagem eletrônica: automação amplia o alcance
Na área cibernética, um assistente pode ser conectado a ferramentas que leem alertas, consultam sistemas ou executam ações. Essa integração é útil em operações defensivas, como triagem de incidentes, mas também aumenta o impacto de uma instrução maliciosa ou de uma falha de autorização.
Um erro comum é tratar a saída do modelo como confiável porque ela vem de um fornecedor conhecido. O modelo ainda pode interpretar mal uma solicitação, ser influenciado por conteúdo externo ou sugerir uma ação inadequada. A decisão de executar uma operação sensível precisa ficar sob controle do software, não do texto gerado.
Extração de capacidades: o que significa “destilação” de modelos
A acusação sobre concorrentes chineses envolve tentativas de extrair recursos do Claude. Uma técnica relacionada, chamada destilação, usa respostas de um modelo mais capaz para treinar ou melhorar outro sistema. A destilação também pode ser legítima: empresas a usam para criar modelos menores, mais baratos e especializados.
O contexto e a autorização fazem diferença. Uso permitido, avaliação de qualidade e treinamento próprio não são automaticamente equivalentes a uma campanha de extração não autorizada. Para provedores, padrões anormais de consultas, volume elevado e tentativas sistemáticas de mapear comportamentos podem servir como sinais de alerta. Para clientes, isso reforça a necessidade de ler os termos do serviço e entender como dados e resultados podem ser usados.
Por que filtros de prompt não bastam
Na minha experiência com sistemas de software, a regra mais confiável é aquela aplicada no ponto em que a ação acontece. Um prompt pode orientar o modelo, mas não é uma fronteira de segurança. Se a aplicação deixa o LLM executar comandos arbitrários, uma instrução bem escrita não corrige o problema de arquitetura.
Também é arriscado confiar apenas em filtros por palavras-chave. Eles podem bloquear usos legítimos e deixar passar pedidos maliciosos formulados de outra maneira. Classificadores ajudam, mas devem ser uma camada adicional. O controle decisivo precisa ser feito por permissões explícitas, validação de argumentos e autorização para ações sensíveis.
Uma arquitetura mais segura separa a interpretação da execução: o modelo propõe uma ação; o backend verifica se aquela ação é permitida; e operações de maior impacto exigem aprovação humana. Assim, um erro de geração não se transforma automaticamente em alteração de produção, exclusão de dados ou acesso indevido.
Na Prática: crie uma barreira entre o LLM e as ferramentas
O exemplo abaixo mostra um dispatcher simples em Python. Ele aceita apenas ferramentas registradas, bloqueia a execução de ações de escrita sem aprovação e registra a decisão. É um ponto de partida didático, não um sistema completo de segurança: em produção, eu também validaria os argumentos com schemas, autenticaria o usuário e manteria logs protegidos contra alteração.
from datetime import datetime, timezone
from typing import Any, Callable
def read_status() -> dict[str, str]:
return {"service": "api", "status": "operational"}
def create_ticket(title: str) -> dict[str, str]:
# Em produção, esta função chamaria um serviço autenticado.
return {"created": "true", "title": title}
TOOLS: dict[str, Callable[..., Any]] = {
"read_status": read_status,
"create_ticket": create_ticket,
}
WRITE_TOOLS = {"create_ticket"}
def dispatch_tool(
tool_name: str,
arguments: dict[str, Any],
*,
human_approved: bool = False,
) -> Any:
if tool_name not in TOOLS:
raise PermissionError(f"Ferramenta não permitida: {tool_name}")
if tool_name in WRITE_TOOLS and not human_approved:
raise PermissionError("Ação de escrita exige aprovação humana")
if tool_name == "create_ticket":
title = arguments.get("title")
if not isinstance(title, str) or not title.strip():
raise ValueError("O campo 'title' é obrigatório")
result = TOOLS[tool_name](title=title.strip())
else:
if arguments:
raise ValueError("Esta ferramenta não aceita argumentos")
result = TOOLS[tool_name]()
audit = {
"time": datetime.now(timezone.utc).isoformat(),
"tool": tool_name,
"approved": human_approved,
"result": result,
}
print(audit)
return result
print(dispatch_tool("read_status", {}))
# Para criar ticket, a aplicação precisa de uma aprovação explícita:
# dispatch_tool("create_ticket", {"title": "Investigar alerta"}, human_approved=True)O ganho dessa abordagem é limitar o que o modelo pode fazer mesmo que ele gere uma solicitação inesperada. A lista de ferramentas funciona como uma allowlist: não existe execução genérica de shell nem acesso implícito a todos os serviços. A aprovação humana também cria uma pausa deliberada antes de uma ação com efeito externo.
- Defina as ferramentas necessárias. Se o assistente só precisa consultar status, não dê acesso a escrita ou terminal.
- Valide cada argumento no backend. Não presuma que o JSON produzido pelo modelo está correto ou seguro.
- Separe leitura de escrita. Exija aprovação adicional para enviar mensagens, alterar dados ou iniciar processos.
- Registre decisões relevantes. Guarde usuário, ferramenta, horário e resultado, respeitando privacidade e retenção.
- Teste abuso e falhas. Inclua instruções maliciosas em documentos recuperados, argumentos inválidos e tentativas de chamar ferramentas não autorizadas.
Alternativas e controles para escolher um modelo
Claude, modelos da OpenAI, Gemini e opções abertas executadas em infraestrutura própria podem atender a necessidades diferentes. Eu não escolheria um modelo só por uma demonstração impressionante ou por um benchmark isolado. Compararia qualidade na tarefa real, custo, latência, limites de uso, controles administrativos, política de dados e disponibilidade de recursos de auditoria.
Uma API gerenciada reduz o trabalho de operar infraestrutura e pode oferecer mecanismos de segurança integrados. Em contrapartida, exige avaliar dependência do fornecedor, localização e tratamento dos dados e limites do serviço. Um modelo aberto dá mais controle sobre implantação e configuração, mas transfere para o time a responsabilidade por atualização, monitoramento, segurança do ambiente e avaliação de comportamento.
Em ambos os casos, o modelo não substitui controles tradicionais. Use autenticação por usuário, privilégios mínimos, segregação de ambientes, gestão de segredos e revisão de dependências. Se o sistema processa código ou documentos não confiáveis, trate esse conteúdo como entrada potencialmente hostil, não como instrução com autoridade.
Erros comuns ao integrar IA em produtos
- Dar acesso amplo demais. Conectar o assistente a todas as ferramentas “para facilitar” aumenta o impacto de qualquer falha.
- Colocar segredos no contexto. Chaves e credenciais não devem ser enviadas ao modelo sem uma necessidade muito bem justificada e controles específicos.
- Tratar resposta como comando confiável. Saídas do LLM precisam passar por validação antes de virar consulta, ação ou conteúdo publicado.
- Confiar em uma única camada de segurança. Filtros, políticas do provedor e revisão humana têm funções diferentes; nenhum deles, sozinho, cobre todos os riscos.
- Não guardar evidências. Sem registros adequados, fica difícil investigar abuso, reproduzir falhas e ajustar permissões.
- Confundir bloqueio com segurança completa. Um modelo pode recusar uma pergunta e ainda assim estar conectado a ferramentas mal configuradas. A segurança precisa existir também fora do chat.
O que muda para quem desenvolve com Claude e outros LLMs
O relatório reforça uma tendência que já deveria estar no radar de qualquer equipe: modelos de IA passaram a fazer parte da superfície de ataque da aplicação. Isso vale para chatbots, agentes de programação, automações internas e fluxos de atendimento. Quanto maior a capacidade de agir, mais importante fica restringir o que cada agente pode acessar e executar.
Minha recomendação prática é começar com o menor conjunto de permissões possível e aumentar o acesso apenas quando houver uma necessidade concreta, testada e monitorada. A pergunta não é só “o modelo responde bem?”, mas também “o que acontece se ele interpretar uma instrução da pior maneira possível?”.
Perguntas frequentes
A Anthropic comprovou que o Claude foi usado para criar armas biológicas?
A reportagem do InfoMoney descreve o que a Anthropic afirmou em seu relatório: a empresa documentou cinco exemplos de cientistas usando os modelos de maneiras que poderiam apoiar o desenvolvimento de armas biológicas e disse ter frustrado essas tentativas. Isso deve ser apresentado como uma declaração da empresa, não como uma confirmação independente de que armas foram criadas.
O que é destilação de modelos de inteligência artificial?
É uma técnica em que respostas ou comportamentos de um modelo mais capaz ajudam a treinar outro modelo. Pode ser usada de forma legítima, mas tentativas não autorizadas de extrair capacidades de um serviço são uma preocupação para quem oferece modelos comerciais.
Um filtro de prompt consegue impedir o uso malicioso de um LLM?
Não sozinho. Filtros podem ajudar a identificar solicitações de risco, mas podem falhar ou ser contornados. Use também permissões mínimas, validação no backend, limites de ferramentas, logs e aprovação humana para operações sensíveis.
Como reduzir o risco ao usar IA com ferramentas internas?
Conecte apenas as ferramentas necessárias, valide cada chamada no servidor e exija autorização explícita para ações que alteram dados ou afetam usuários. Nunca deixe o modelo executar comandos arbitrários só porque gerou uma resposta que parece plausível.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.