MITRE ATLAS
O ATLAS descreve o que um adversário faz para envenenar o dado de treino, copiar o modelo, contornar as travas e fazer o sistema entregar o que não deveria. É o vocabulário que falta na maior parte das avaliações de segurança de IA vendidas hoje, que terminam num relatório sobre a aplicação web que serve o modelo.
O MITRE ATLAS é a base de conhecimento que descreve os ataques dirigidos a sistemas de inteligência artificial, mantida pela MITRE. A DM11 avalia seus sistemas de IA contra as técnicas do catálogo, testa o modelo e a esteira de dados junto com a aplicação que os expõe, e entrega o resultado com a prova do que foi possível fazer. Quando o objetivo também inclui um documento para enviar a um cliente ou a um regulador, o caminho é a certificação ISO/IEC 42001, e a evidência produzida aqui entra inteira nesse projeto.
Quem conduz a avaliação
CEH, Certified Ethical Hacker pela EC-Council
SYCP e SYES, certificações ofensivas da Solyd
CISA, auditoria de sistemas de informação
17 anos de governança, riscos e conformidades
O QUE É
ATLAS é a sigla de Adversarial Threat Landscape for AI Systems, o panorama de ameaças adversárias a sistemas de inteligência artificial que a MITRE mantém em aberto. Ele reaproveita a estrutura do MITRE ATT&CK, o catálogo de táticas e técnicas de adversário que a mesma organização mantém para sistemas corporativos, e a aplica ao que o ATT&CK deixa de fora: o modelo, o dado que o treinou e a esteira que leva um ao outro. Na distribuição de junho de 2026 são 16 táticas, 103 técnicas de primeiro nível com mais 70 subtécnicas, 35 mitigações e 63 estudos de caso.
Envenenar o dado de treino para que o modelo aprenda errado de propósito. Publicar conjunto de dados ou modelo já contaminado para que alguém o baixe. Extrair o modelo por consultas repetidas até reconstruir uma cópia utilizável. Inferir se um registro específico estava no conjunto de treino, o que em base de saúde ou de crédito é vazamento de dado pessoal sem nenhum vazamento de arquivo. Manipular a entrada até o modelo classificar errado, que é como se contorna um detector. Nenhuma dessas técnicas aparece num teste de infraestrutura, porque nenhuma delas depende de uma falha de infraestrutura.
Além das táticas herdadas do ATT&CK, o ATLAS tem duas próprias: acesso ao modelo e preparação do ataque de IA. A primeira reconhece que o grau de acesso muda tudo, e vai de conhecer só a aplicação até ter o arquivo do modelo na mão, passando pelo acesso por consulta, que é o caso da maioria. A segunda descreve o trabalho que o adversário faz antes de atacar, como treinar um modelo aproximado para ensaiar contra ele e chegar ao alvo com o ataque já calibrado. Esse ensaio é invisível para quem monitora só o tráfego da aplicação.
São 63, e é o que separa o ATLAS de uma lista de ameaças imaginadas. Estão documentados ali, com o alvo e quem executou, casos de evasão de detector de malware baseado em aprendizado de máquina, envenenamento de chatbot público, réplica de modelo de linguagem por consultas, injeção indireta de instrução em assistente corporativo com acesso a e-mail e a documento, contorno de verificação de identidade por vídeo sintético e extração de modelo embarcado em aplicativo de celular. O catálogo é atualizado em cadência quase mensal, o que o torna mais parecido com um boletim de ameaça do que com uma norma.
Vale alinhar a expectativa cedo, porque isso muda o planejamento. O que a avaliação produz é um mapa de cobertura, técnica a técnica, dizendo o que foi tentado, o que funcionou e com qual evidência. A MITRE publica o catálogo e não credencia avaliador, então não existe selo ATLAS para emitir nem organismo que confira o seu. Quando o seu cliente ou o seu regulador precisa de um documento assinado por terceiro, quem responde é a certificação ISO/IEC 42001, e o resultado desta avaliação entra lá como a evidência técnica que o auditor vai pedir.
QUEM COSTUMA PRECISAR
As três chegam pelo mesmo caminho: existe IA em produção, existe alguma verificação de segurança feita, e ninguém consegue dizer se o modelo em si já foi testado alguma vez.
A empresa contratou um teste de intrusão na aplicação de IA e recebeu um relatório competente sobre autenticação, sessão, permissão e configuração de servidor. Nada disso responde se é possível extrair o modelo por consulta, envenenar o próximo ciclo de treino ou fazer o sistema revelar a instrução que o governa. São perguntas diferentes, com método diferente, e quase nenhum escopo de pentest padrão as inclui.
O assistente deixou de só responder e passou a consultar a base interna, abrir chamado, ler caixa de entrada e executar ação em sistema. A partir daí, uma instrução escondida num documento que um terceiro enviou vira caminho de execução, e o conteúdo que entra no contexto do modelo passa a ter o mesmo peso de segurança que uma entrada de usuário. É a categoria de incidente que mais cresce nos estudos de caso do próprio ATLAS.
O projeto de ISO/IEC 42001 avançou, ou o NIST AI RMF, o framework de gestão de risco de IA do instituto americano de padrões, foi adotado como método, e chegou a hora de responder quais ameaças concretas cada sistema enfrenta. Sem um catálogo de técnicas por trás, essa parte vira uma planilha de riscos genéricos que ninguém consegue testar nem fechar. O ATLAS é a lista que transforma risco declarado em ameaça verificável.
HISTÓRIAS
Trocamos os nomes dos clientes com o mesmo sigilo que vai proteger a sua empresa depois. Os nomes mudam, o padrão dos problemas se repete. Quando o cliente autoriza, mostramos referências com nome numa conversa.
Saúde suplementar
Um assistente interno respondia dúvidas da equipe de atendimento consultando a base de documentos da operadora, e essa base recebia arquivos enviados por prestadores externos. O teste de segurança feito seis meses antes tinha coberto o portal, a autenticação e a infraestrutura, e passou limpo. Ninguém tinha olhado o que acontece quando o texto de um documento chega ao modelo.
Reproduzimos a técnica de injeção indireta de instrução do ATLAS: colocamos, dentro de um documento comum, um trecho endereçado ao modelo e não ao leitor humano. Depois seguimos o caminho até o fim, testando o que o assistente conseguia buscar e devolver a partir dali, e onde a resposta saía da empresa.
O assistente cumpria a instrução escondida e trazia trechos de documentos de outros prestadores para dentro da mesma conversa. A correção coube toda fora do servidor: separar o conteúdo de terceiro do conteúdo confiável, restringir o que o assistente pode buscar por sessão e registrar cada recuperação, para que a próxima tentativa deixe rastro.
Tecnologia e software
Uma empresa de software expunha, dentro do produto, um modelo de classificação treinado com anos de dado próprio. Era o principal ativo do negócio. O acesso era autenticado e cobrado por uso, e a percepção era de que isso bastava, porque cada consulta tinha dono e havia limite de requisições por minuto.
Aplicamos a técnica de extração de modelo do ATLAS a partir de uma conta legítima de cliente: consultas construídas para maximizar informação por chamada, dentro do limite contratado, ao longo de dias. Treinamos um modelo aproximado com as respostas e medimos quanto ele concordava com o original.
O modelo aproximado reproduzia a decisão do original na maior parte dos casos, com um volume de consultas que cabia folgado no plano contratado. O limite por minuto nunca foi tocado, porque esse ataque trabalha por paciência, sem precisar de volume. A defesa passou a olhar padrão de consulta ao longo do tempo, e a diretoria passou a tratar o modelo como propriedade intelectual com controle de acesso, e não como funcionalidade.
Telecomunicações
Um modelo de priorização de atendimento era retreinado periodicamente com o histórico de chamados, incluindo texto livre escrito por quem abria o chamado e a classificação que o próprio cliente marcava. O ciclo era automático e ninguém revisava o que entrava. A conversa sobre segurança de IA na empresa estava toda concentrada na aplicação que servia o modelo.
Mapeamos a esteira de dado do ponto de entrada até o treino e testamos o envenenamento na origem, com um volume pequeno de registros construídos para deslocar a decisão do modelo numa faixa específica. Depois medimos o efeito em ambiente de teste, com o mesmo procedimento de retreino que roda em produção.
Uma fração pequena dos registros do ciclo já era suficiente para mudar a prioridade de uma categoria inteira de chamado, e nada nesse processo disparava alerta. Entraram validação e limite de influência por origem, revisão amostral do que entra no treino e comparação do modelo novo com o anterior antes da publicação, que virou a etapa que segura o ciclo quando algo se desloca.
COMO CONDUZIMOS
A avaliação vale pelo que ela consegue demonstrar. Técnica do ATLAS aqui é marcada como tentada, bem-sucedida ou não aplicável, com a prova anexada e o caminho reproduzível, porque parecer inseguro e ser demonstravelmente inseguro levam a decisões de investimento diferentes.
Levantamos quais sistemas de IA existem, oficiais e não oficiais, o que cada um decide ou automatiza, de onde vem o dado que o treina ou alimenta a resposta, e a que ele tem acesso depois de responder. Sem esse desenho, qualquer teste vira exercício sobre a tela.
Inventário de sistemas e casos de uso de IA, com dono por item
Origem do dado de treino e do conteúdo consultado em produção
Ferramentas, integrações e permissões que o modelo aciona
Grau de acesso disponível para o teste, definido com a diretoria
Marco de entregaEsteira desenhada do dado de origem até a ação que o sistema executa.
Nem toda técnica do catálogo faz sentido para todo desenho, e testar tudo é a forma mais cara de descobrir isso. Selecionamos as técnicas pertinentes ao seu tipo de modelo, ao seu grau de exposição e ao acesso que um adversário realista teria, e submetemos a lista à sua aprovação antes de executar qualquer coisa.
Modelagem de ameaça por sistema, mapeada às táticas do ATLAS
Lista de técnicas selecionadas, com justificativa de inclusão e de exclusão
Regras de engajamento, janela de execução e critério de parada
Autorização formal, incluindo o que o contrato do provedor de modelo permite
Marco de entregaEscopo aprovado, com cada técnica selecionada rastreada ao identificador do catálogo.
Testamos o modelo, o conteúdo que chega até ele, o ponto onde o dado de treino entra e as ferramentas que ele aciona, junto com a aplicação e a infraestrutura em volta. É a etapa em que a diferença entre este trabalho e um teste de aplicação aparece por inteiro.
Tentativas de evasão, extração, inferência sobre o treino e contorno de trava
Injeção de instrução por conteúdo de terceiro, até a ação que o modelo executa
Teste de envenenamento no ponto de entrada do dado, em ambiente controlado
Prova reproduzível para cada técnica bem-sucedida
Marco de entregaCada técnica executada com resultado registrado e caminho reproduzível.
O mapa técnico sozinho não sustenta decisão de investimento. Ligamos cada achado à mitigação correspondente do catálogo e ao controle de governança que a sua empresa já usa, para o assunto chegar à diretoria no vocabulário que ela acompanha. Depois das correções, repetimos as mesmas técnicas com o mesmo método.
Achados ligados às mitigações do ATLAS e aos controles da ISO/IEC 42001
Relatório executivo em linguagem de negócio, com risco e esforço separados
Plano de correção com responsável e data por achado
Reteste das técnicas bem-sucedidas, comparável à execução inicial
Marco de entregaCorreções demonstradas com a repetição das técnicas que haviam funcionado.
QUANTO TEMPO LEVA
Não publicamos prazo padrão, porque prazo publicado vira promessa. O inventário costuma ser a parte curta quando alguém já sabe o que existe, e longa quando ninguém sabe. Estes são os três fatores que mais mexem no relógio, e a primeira conversa já mostra em qual deles a sua empresa está.
Empresa com inventário de usos de IA começa a modelar ameaça na primeira semana. Empresa sem inventário passa o início descobrindo o que já está em produção, e essa descoberta quase sempre inclui uso que a área de tecnologia não tinha aprovado.
Testar só pela aplicação, como faria alguém de fora, é mais rápido e enxerga menos. Ter acesso ao modelo, ao conjunto de treino e à esteira de publicação permite cobrir as técnicas de envenenamento e de cadeia de suprimento, que são as mais caras de descobrir depois. A escolha é de escopo e de orçamento, e ela é feita com você antes de começar.
Com modelo próprio, quase todo o catálogo se aplica. Com modelo de terceiro consumido por interface de programação, boa parte do teste se concentra no contexto, nas ferramentas e nas travas que você controla, e o que pode ser testado no modelo em si depende do que o contrato do provedor autoriza. Essa leitura do contrato entra cedo, porque ela costuma ser a que mais atrasa.
PERGUNTAS FREQUENTES
As dúvidas que aparecem em quase toda primeira reunião, respondidas sem rodeio.
Não. A MITRE publica e mantém o catálogo em aberto, e não credencia avaliador nem emite selo, para empresa nenhuma. Quem oferece um certificado ATLAS está vendendo outra coisa. O que existe é o relatório de avaliação, com o mapa de cobertura por técnica e a prova por trás, e ele é aceito como evidência técnica dentro de um projeto de ISO/IEC 42001, que é a norma de IA que rende certificado emitido por terceiro.
Começamos pelo inventário do que já está em produção e pela seleção das técnicas do ATLAS que fazem sentido para o seu desenho. O resultado é um mapa do que foi tentado, do que funcionou e do que fazer primeiro, na linguagem que a diretoria acompanha.