MIT Technology Review alerta: confiamos demais nas recusas dos modelos de IA

Na edição de 9 de outubro da newsletter The Download, a MIT Technology Review coloca em primeiro plano uma tese que muita gente no setor trata como axioma: confiamos demais na capacidade da IA de dizer «não». Os modelos de hoje são treinados para recusar um grande número de pedidos. Pergunte a um chatbot como envenenar alguém e, muito provavelmente, ele se recusará a responder. Para a publicação, é justamente nessa recusa que o setor deposita expectativas demais. A segunda reportagem da edição trata dos efeitos colaterais de medicamentos para emagrecer e não tem relação com IA.

Uma ressalva importante: o texto da newsletter traz apenas o ponto de partida do argumento, sem dados e sem nomes. A posição completa dos autores deve ser lida no original. A seguir, explicamos como as recusas funcionam do ponto de vista técnico e onde estão seus pontos fracos.

Como os modelos aprendem a dizer «não»

A recusa não vem embutida de fábrica no LLM. O modelo base simplesmente continua o texto e descreve, com a mesma disposição, tanto uma receita de bolo quanto um procedimento perigoso. O comportamento «não posso ajudar com isso» surge depois, nas etapas de ajuste fino: pessoas e outros modelos avaliam as respostas, e o sistema aprende a escolher as que são consideradas seguras. Por cima disso entram prompts de sistema e filtros externos, que verificam o pedido na entrada e a resposta na saída.

O resultado parece uma fronteira, mas na prática é uma tendência estatística. O modelo não «entende» que o pedido é perigoso; ele reconhece padrões familiares de pedidos perigosos.

Onde a recusa falha

Essa proteção tem três pontos fracos conhecidos.

• Contorno pela formulação. Cenários de interpretação de papéis, reformulações, troca de idioma e a divisão de uma tarefa perigosa em etapas inofensivas continuam sendo técnicas de jailbreak eficazes há anos.
• Intenção desconhecida. Perguntas sobre venenos são feitas por toxicologistas, autores de romances policiais, estudantes e criminosos. Só pelo texto do pedido não dá para distingui-los, então o sistema precisa escolher entre recusas desnecessárias e falhas de bloqueio.
• Custo do erro nos dois sentidos. Um modelo rígido demais deixa de ser útil para médicos, pesquisadores de segurança e jornalistas. Um modelo brando demais entrega o que não deveria entregar.

Os agentes trazem um problema à parte. Quando o modelo tem acesso a navegador, e-mail, código e ferramentas de pagamento, uma recusa educada no chat não garante nada. Uma ação perigosa pode ser montada a partir de uma série de passos que, isoladamente, parecem inocentes.

Como a proteção se compõe na prática

Se a recusa não for a única barreira, o quadro passa a ter várias camadas:

• treinamento com exemplos de recusa e preferências humanas;
• instruções de sistema do operador, descrevendo o que é permitido e o que não é;
• classificadores separados na entrada e na saída, independentes do modelo principal;
• red teaming: tentativas deliberadas de invasão antes e depois do lançamento;
• limitação dos privilégios do agente no nível da infraestrutura, e não do prompt.

O último item é o mais subestimado. Permissões de acesso, limites e confirmação humana para ações críticas funcionam independentemente do que o modelo «decidiu».

O que fazer nas equipes que implantam modelos

Primeiro: não trate a recusa como um controle de segurança. Ela é um ajuste de comportamento e precisa ser verificada como qualquer outro, com regularidade e a cada nova versão do modelo.

Segundo: teste os seus próprios cenários, não apenas benchmarks genéricos. Pedidos perigosos na sua área podem ter aparência bem diferente da que aparece em conjuntos públicos.

Terceiro: para agentes, projete privilégios mínimos e registro de ações. Se o modelo errar ou for enganado, o dano deve esbarrar em um limite técnico.

Quarto: meça os dois lados do erro. A proporção de pedidos perigosos que passaram e a de recusas indevidas em tarefas legítimas dizem mais sobre a qualidade do sistema do que qualquer indicador isolado.