Em abril de 2026, o Center for Democracy & Technology (CDT) e o MIT publicaram um estudo que testa uma suposição comum na indústria de IA: a de que as propriedades de segurança de um modelo-base permanecem estáveis após sua customização. O estudo analisou 31 modelos disponíveis no Hugging Face, 16 ajustados para medicina e 15 para direito, e comparou o comportamento de segurança antes e depois do fine-tuning. As propriedades de segurança estabelecidas durante o treinamento original não sobrevivem ao processo de customização de forma confiável, mesmo quando o ajuste é feito com dados benignos e para finalidades legítimas.
As mudanças não seguem um padrão simples. Em muitos casos, o mesmo modelo melhorou em alguns testes de segurança e piorou em outros. Em modelos jurídicos, isso ocorreu em 93% dos casos analisados. A direção do efeito depende mais de como a segurança é medida do que do tipo ou da intensidade do ajuste.
Na prática, isso significa que um modelo considerado seguro no momento da aquisição pode se comportar de forma diferente após ser adaptado internamente.
Por que isso importa
Modelos de IA raramente são usados em sua forma original. Empresas os adaptam para contextos específicos como atendimento ao cliente, análise jurídica e suporte clínico, usando técnicas como fine-tuning, RAG (retrieval-augmented generation) e engenharia de prompts. Esse processo é parte central da adoção de IA. O problema é que o risco varia conforme a técnica utilizada.
RAG e system prompts dominam as implantações enterprise. Segundo levantamento da Menlo Ventures de novembro de 2024, 51% dos modelos em produção usavam RAG como abordagem primária, ante 31% no ano anterior. A preferência tem razão econômica: RAG não altera os parâmetros do modelo, o que preserva a flexibilidade para trocar o modelo-base quando uma versão mais capaz for lançada. O risco introduzido pelo RAG existe, mas é de natureza diferente, ligado ao que o sistema acessa e recupera, não ao que o modelo aprendeu a fazer, o que também pode alterar o comportamento do sistema, ainda que por mecanismos diferentes do fine-tuning.
Fine-tuning opera de outra forma. Ele modifica os parâmetros internos do modelo para incorporar conhecimento de domínio, terminologia especializada ou padrões de comportamento específicos. É menos prevalente em grandes corporações, mas permanece a técnica dominante em ecossistemas open-source e em aplicações de alto risco como saúde e direito, justamente os contextos em que o estudo se concentrou. O que o relatório documenta é que esse processo não é aditivo: ao ajustar um modelo para responder com fluência clínica, o desenvolvedor pode alterar ou enfraquecer restrições de segurança estabelecidas no treinamento original, sem perceber que isso ocorreu.
O estudo mostra que não há relação consistente entre o tamanho da mudança nos parâmetros, o método de ajuste utilizado e o impacto final em segurança. Isso torna esses proxies insuficientes como indicadores de risco.
O que muda na prática
Grande parte da pesquisa sobre segurança de modelos foca em adulteração intencional; atores maliciosos que removem salvaguardas deliberadamente. O que o estudo documenta é diferente: o desalinhamento pode ocorrer em ajustes rotineiros, feitos sem nenhuma intenção de comprometer a segurança do sistema.
O efeito mais concreto não é a geração de respostas incorretas, mas a mudança de comportamento em contextos sensíveis. Nos experimentos do estudo, um modelo-base recusou orientar sobre automutilação e indicou ajuda profissional; após ajuste médico, passou a fornecer explicações detalhadas sobre métodos. Um modelo-base recusou criar conteúdo difamatório; após ajuste jurídico, passou a gerar textos insinuando corrupção sem evidência. Em ambos os casos, o modelo ajustado demonstrava maior fluência técnica, mas menor capacidade de impor limites.
Miranda Bogen, diretora do Laboratório de Governança de IA do CDT e coautora do estudo, descreve um cenário ilustrativo: um modelo ajustado para atendimento bancário pode se tornar mais preciso em consultas financeiras e, ao mesmo tempo, perder a capacidade de identificar sinais de sofrimento emocional. Se um cliente expressa angústia ao descobrir que está sem dinheiro, o modelo original poderia reconhecer o sinal e encaminhar para suporte adequado. O modelo ajustado pode não mais reconhecer esse padrão. Para Bogen, o problema não está na habilidade técnica de quem faz o ajuste: “mesmo pessoas com habilidades técnicas extremamente avançadas não conseguirão prever” o impacto do fine-tuning em segurança.
Medir segurança em IA após modificação é um problema técnico aberto, e o estudo o demonstra com precisão. Os pesquisadores aplicaram quatro benchmarks distintos: HEx-PHI e MLCommons AILuminate para segurança geral, MedSafetyBench e CARES para segurança médica específica. Os resultados divergem de forma sistemática. Um modelo pode registrar melhora em um benchmark e queda em outro simultaneamente, e a discordância não indica falha na medição, mas o fato de que cada avaliação captura uma dimensão diferente de risco.
O dado mais concreto dessa divergência aparece nos experimentos controlados com dados médicos: a mudança mediana foi de melhora de 12% nas métricas de segurança clínica combinada com queda de 26% nas métricas gerais de segurança, no mesmo conjunto de modelos. Um desenvolvedor que avalia seu modelo ajustado apenas com benchmarks de domínio pode concluir que o sistema ficou mais seguro. Ficou, em um sentido restrito. Em outro, ficou menos.
Isso ocorre porque a maioria das avaliações foi desenhada para modelos genéricos, não para sistemas adaptados. Benchmarks que usam prompts de turno único, por exemplo, podem não capturar um modelo que fornece instruções problemáticas de forma incremental ao longo de uma conversa, que é exatamente o tipo de comportamento que emerge após fine-tuning de domínio. Decisões de implantação baseadas em uma única avaliação tendem a não refletir o comportamento real do sistema em produção.
Nos experimentos controlados, Bogen observa que não foram encontrados “sinais claros” de que determinadas escolhas de configuração pudessem predizer se a segurança melhoraria ou pioraria após o ajuste. Isso também levanta uma questão mais funda sobre o que está sendo medido: é preciso verificar se o conceito de segurança que se quer avaliar está de fato sendo testado pelo benchmark utilizado.
O problema de governança
A forma como a segurança de IA é tratada hoje não cobre esse tipo de risco. Avaliações de segurança são feitas no modelo-base, antes da customização, e a maior parte do risco emerge depois, na adaptação ao contexto de uso. A isso se soma uma assimetria estrutural: desenvolvedores de modelos têm acesso a dados de treinamento, arquitetura e avaliações internas; empresas que adaptam esses modelos operam com menos informação e menos recursos. O resultado é um cenário em que a responsabilidade pelo risco tende a se deslocar para quem tem menor capacidade de avaliá-lo.
Isso é especialmente crítico nos domínios que o estudo analisa. Medicina e direito são contextos em que segurança e confiabilidade não são requisitos opcionais. Ajustar um modelo sem saber como isso afetará seu alinhamento de segurança representa um risco concreto quando o sistema está sendo usado em decisões clínicas ou documentos jurídicos. A pressão por adoção em setores de alto impacto aumenta a probabilidade de que modelos ajustados sejam implantados em funções críticas antes que seus limites sejam compreendidos.
A estrutura regulatória existente mede a variável errada. O guia de implementação do AI Act europeu, publicado em julho de 2025, usa um limiar baseado em compute para definir o que conta como modificação substancial: se os recursos computacionais usados no ajuste superam um terço dos utilizados no treinamento original, o modificador pode ser tratado como novo provedor, com obrigações correspondentes. O estudo demonstra que essa métrica não tem correlação com risco de segurança.
Técnicas como LoRA (Low-Rank Adaptation), entre as mais usadas por desenvolvedores independentes, modificam apenas uma fração dos parâmetros e consomem pouco compute, ficando abaixo do limiar europeu. Os experimentos do estudo mostram que causam desvios de segurança comparáveis aos de métodos que alteram todos os parâmetros. Legislação californiana em discussão no mesmo período adota abordagem similar: deixa que os próprios desenvolvedores definam o que constitui modificação substancial, o que tende a ancorar a definição nos mesmos marcadores computacionais.
O Colorado SB 24-205 adota abordagem diferente: define modificação substancial pelo impacto observável no comportamento, especificamente qualquer mudança deliberada que resulte em novo risco razoavelmente previsível de discriminação algorítmica. O estudo aponta esse enquadramento como mais adequado para capturar o risco real, ainda que sua operacionalização dependa de avaliações que as estruturas de medição atuais ainda não conseguem realizar de forma confiável.
O que organizações deveriam fazer
O estudo não sugere interromper o uso de fine-tuning. Indica que o processo precisa ser tratado como parte crítica do ciclo de risco. Testes de segurança precisam ser feitos no sistema final, não apenas no modelo-base. Uma única avaliação não é suficiente para capturar risco em contextos reais. Limitar onde e como o modelo pode ser aplicado reduz a exposição a comportamentos inesperados fora do domínio de ajuste.
Segurança em IA não é uma propriedade fixa do modelo: é resultado de como ele é modificado e utilizado. Isso desloca o foco de governança da validação no lançamento para o monitoramento contínuo ao longo do ciclo de uso.
A próxima variável observável é a resposta dos desenvolvedores de base. Uma análise de dezembro de 2025, citada no relatório, encontrou 947 nomes de seções diferentes em model cards de apenas cinco modelos de fronteira e 100 cards do Hugging Face. Sem padronização mínima de documentação sobre o que o treinamento de alinhamento cobriu, quais comportamentos foram alvejados e quais técnicas foram aplicadas, desenvolvedores downstream não têm base para antecipar o que um ajuste vai desfazer.