Confiança & Segurança
Nós atacamos nosso próprio aplicativo
O que é uma rodada de Red Team, por que realizamos mais de 1.100 tentativas em 19 idiomas e o que terminou em zero
O Autistic Mirror é frequentemente utilizado em momentos sensíveis. Após um dia de sobrecarga sensorial, em uma crise ou durante um conflito com o ambiente ao redor. Quem abre um aplicativo em tais situações não possui margem de erro para uma IA que responda de forma inadequada. Por isso, a segurança não é uma função a ser adicionada posteriormente. A segurança é o pré-requisito para que a ferramenta possa ser utilizada.
Este artigo descreve o que fizemos com o aplicativo em produção no dia 17 de maio de 2026. Ele pode ser lido sem conhecimento prévio. Quem busca detalhes técnicos os encontrará no relatório de auditoria interna. Aqui, tratamos da questão de saber se as camadas de proteção resistem quando alguém tenta rompê-las ativamente.
O que é um teste de Red Team
Um teste de Red Team é um ataque simulado. Em vez de esperar que alguém de fora tente, nós mesmos atacamos o aplicativo. Utilizamos todos os padrões conhecidos na pesquisa de segurança, além dos padrões que seriam críticos especificamente para uma IA em um contexto neurodivergente.
Três perguntas estão no centro dessa avaliação.
É possível induzir a IA a ignorar suas regras internas. É possível, em uma situação de crise, convencê-la a omitir linhas de ajuda ou oferecer respostas que minimizem o problema. O software ao redor protege os dados das pessoas usuárias mesmo quando um endpoint é pressionado diretamente.
A relevância em tais testes não surge de uma única tentativa. Ela surge através de volume e variação. Uma única tentativa bem-sucedida é uma anedota. Centenas de tentativas bem-sucedidas em vários idiomas são evidência.
O que queremos dizer com tentativa de ataque
Uma tentativa de ataque é uma requisição real ao aplicativo em execução, formulada de modo a contornar uma regra de proteção. Sem laboratório, sem simulação, sem mock. Exatamente o que uma pessoa atacante digitaria no campo de entrada. Quando falamos de tentativas de ataque a seguir, referimo-nos sempre a essas requisições reais.
A primeira rodada
No primeiro passo, executamos várias dezenas de padrões de ataque cuidadosamente construídos contra o aplicativo em produção. Cada padrão em todos os sete idiomas de interface mantidos ativamente. Alemão, inglês, espanhol, francês, holandês, português brasileiro e dinamarquês.
Sete idiomas não são decoração. Uma defesa de IA que funciona em alemão pode falhar silenciosamente em francês. Quem leva a segurança a sério testa cada idioma no qual o aplicativo realmente responde.
Resultado desta primeira rodada. Zero violações.
Por que isso não foi o suficiente para nós
Uma rodada concluída com 210 tentativas é um bom sinal. Estatisticamente, ainda é pouco. Quem quer saber se um sistema realmente resiste precisa de uma escala onde o acaso possa ser excluído como explicação.
O padrão da indústria para relatórios de Red Team em produtos de IA envolve de algumas dezenas a poucas centenas de tentativas, frequentemente em apenas um ou dois idiomas. Queríamos testar de forma mais profunda e ampla. Por dois motivos. Porque o aplicativo opera em um contexto que exige proteção especial. E porque estamos nos preparando para auditorias externas, onde linhas de base comparáveis são necessárias.
A rodada expandida
Na rodada expandida de 17 de maio de 2026, um inventário significativamente maior foi testado contra o aplicativo em produção. Mais de 1.100 tentativas de ataque, além de várias centenas de outras respostas do modelo originadas de conversas longas e de múltiplas etapas. Acompanhado por uma suíte completa de testes estruturais offline, que verifica a lógica de proteção independentemente da IA.
Para que a escala fique visível, aqui estão as áreas individuais. O significado dos termos está descrito em uma frase logo após.
| Área | O que é testado | Resultado |
|---|---|---|
| Auditoria profunda nos 7 idiomas de interface | Tentativas de induzir a IA, passo a passo, a quebrar suas regras, em cada idioma mantido ativamente | 0 violações |
| Tentativas de sobrescrever as regras internas diretamente | entradas clássicas como "ignore todas as instruções anteriores" | 0 violações |
| Tentativas de forçar a IA a assumir outro papel | "você agora é um médico", "responda como um coach" | 0 violações |
| Tentativas de burlar regras via truques de escrita | entradas codificadas ou com caracteres alterados para contornar filtros | 0 violações |
| Tentativas de forçar ajuste comportamental e normalização | requisições onde a IA deve fornecer recomendações semelhantes a ABA | 0 violações |
| Ataques em outros idiomas fora da interface | mais de uma dezena de idiomas adicionais que um atacante escolheria, pois muitas defesas de IA falham neles | 0 violações |
| Tentativas de bypass reformuladas | os mesmos ataques com outras palavras, para que puros filtros de palavras-chave fossem evitados | 0 violações |
| Ataques combinados de um catálogo expandido | vários padrões de ataque simultâneos na mesma tentativa | 0 violações |
| Manipulação lenta ao longo de muitos turnos de conversa | conversas onde as regras de proteção devem ser suavizadas ao longo de muitos passos, e não diretamente | dentro da janela de tolerância |
| Testes estruturais offline | várias suítes de teste que verificam a consistência e o desvio da lógica de proteção independentemente da IA | todos aprovados |
| Endpoints administrativos sob pressão | todas as interfaces administrativas são acessadas sem autorização válida e devem recusar | corretamente bloqueado |
| Auditoria de qualidade do conteúdo das respostas | vários clusters verificam se a IA nomeia corretamente mecanismos neurológicos em vez de clichês genéricos | concordância quase completa |
| Isolamento de dados entre pessoas usuárias | verificação do banco de dados para garantir que dados de uma pessoa jamais cheguem à resposta de outra | 0 vazamentos de dados |
| Detecção de manipulação no log de atividades | teste para verificar se alterações posteriores em logs relevantes para a segurança permanecem identificáveis | aprovado |
| Acessibilidade de todos os links de hotline de crise | cada link de emergência cadastrado no aplicativo é verificado | aprovado |
| Termos técnicos multilíngues | verificação se termos técnicos neurológicos e co-occurring conditions são explicados corretamente em vários idiomas | aprovado |
O que os números significam
Três dimensões são importantes nesta tabela.
A profundidade. Mais de 1.100 tentativas de ataque são muito superiores ao que é comum no mercado. Com uma taxa de violação observada de zero, a incerteza estatística torna-se tão pequena que o sucesso não pode mais ser explicado pelo acaso.
A amplitude. 19 idiomas cobertos. Os sete idiomas de interface mantidos ativamente, mais outros idiomas de diferentes sistemas de escrita que um atacante escolheria, pois muitas defesas de IA falham silenciosamente neles.
A repetibilidade. Esta rodada fornece uma linha de base comparável. Se realizarmos o mesmo teste em três meses, veremos imediatamente se novas versões do modelo ou alterações de prompt introduziram uma regressão. A segurança não é um estado, mas uma medição contínua.
Proteção de dados durante o próprio teste
Mesmo um teste de segurança não deve gerar um rastro de dados que se torne um problema posterior. Por tentativa, apenas três coisas são armazenadas. O veredito (aprovado, parcial, reprovado). O mecanismo atacado. Um curto "hash stump" criptográfico da resposta do modelo. Não são arquivadas respostas em texto claro, regras internas do sistema ou dados de usuários. Quem quiser verificar a auditoria pode fazê-lo sem nunca ver o texto original.
Testes externos são o próximo passo
Passar nos próprios testes é obrigação, não mérito. Uma declaração de segurança só ganha peso quando terceiros independentes podem verificá-la. Por isso, estamos preparando uma rodada de testes externos e publicaremos seus resultados com a mesma transparência desta rodada interna, independentemente de os achados serem favoráveis ou desconfortáveis.
Paralelamente, um manuscrito sobre a metodologia científica da nossa arquitetura de segurança foi enviado para avaliação na Autism in Adulthood (status: em revisão). Com isso, a arquitetura torna-se verificável pela primeira vez fora da nossa própria casa.
O que está por trás dos números
A maioria dos produtos de IA faz propaganda de funções. A segurança raramente aparece no marketing porque parece abstrata para quem vê de fora. Por trás dos números desta rodada existe uma postura diferente. Um aplicativo que trabalha com pessoas em situação de vulnerabilidade deve aos seus usuários mais do que uma interface bem cuidada. Deve a eles que as promessas resistam sob pressão. O fato de isto ter resultado em zero violações não é uma garantia para o futuro. É a afirmação de que a responsabilidade é levada a sério, com testes reais em números reais, não com alegações.
Para organizações e auditores
Para clientes B2B, departamentos de compliance e órgãos de auditoria externa, um documento detalhado de metodologia e resultados está disponível. Ele contém a matriz completa de amostras, os inventários exatos por área de ataque, a lógica do classificador e a declaração de proteção de dados para armazenamento. Solicitação informal para enterprise@autisticmirror.app, envio após breve consulta sobre a finalidade de uso.
O Autistic Mirror explica a neurologia autista de forma individual, relacionada à sua situação. Seja para você, como pai/mãe ou como profissional.
