Confianza y seguridad
Atacamos nuestra propia aplicación
Qué es una ejecución de Red Team, por qué realizamos más de 1.100 intentos en 19 idiomas y qué terminó marcando cero
Autistic Mirror se utiliza a menudo en momentos sensibles. Después de un día de sobreestimulación, en una crisis, en medio de un conflicto con el entorno. Quien abre una aplicación en tales situaciones no tiene margen para una IA que de repente responda de forma inadecuada. Por ello, la seguridad no es una función que se añade a posteriori. La seguridad es la condición previa para que la herramienta pueda siquiera utilizarse.
Este artículo describe lo que hicimos el 17 de mayo de 2026 con la aplicación en vivo. Es legible sin conocimientos previos. Quienes busquen detalles técnicos los encontrarán en el informe interno de auditoría. Aquí se trata de si las capas de protección resisten cuando alguien intenta romperlas activamente.
Qué es una prueba de Red Team
Una prueba de Red Team es un ataque simulado. En lugar de esperar a que alguien lo intente desde fuera, atacamos la aplicación nosotros mismos. Utilizamos todos los patrones conocidos en la investigación de seguridad, además de los patrones que serían críticos específicamente para una IA en un contexto neurodivergente.
Tres preguntas son el centro de atención.
¿Se puede inducir a la IA a ignorar sus reglas internas? ¿Se puede lograr que en una situación de crisis omita las líneas de ayuda o minimice la situación? ¿Protege el software circundante los datos de las personas usuarias incluso cuando un punto final es presionado directamente?
La validez de estas pruebas no proviene de un solo intento. Proviene del volumen y la variación. Un intento individual superado es una anécdota. Cientos de intentos superados en varios idiomas son evidencia.
A qué nos referimos con intento de ataque
Un intento de ataque es una solicitud real a la aplicación en funcionamiento, formulada de tal manera que intente eludir una regla de protección. Sin laboratorios, sin simulacros, sin maquetas. Exactamente lo que una persona atacante escribiría en el campo de entrada. Cuando hablamos de intentos de ataque a continuación, nos referimos siempre a estas solicitudes reales.
La primera ejecución
En el primer paso, ejecutamos varias docenas de patrones de ataque cuidadosamente diseñados contra la aplicación en vivo. Cada patrón en los siete idiomas de la interfaz de usuario mantenidos activamente. Alemán, inglés, español, francés, neerlandés, portugués brasileño y danés.
Siete idiomas no son decoración. Una defensa de IA que funciona en alemán puede fallar silenciosamente en francés. Quien se toma en serio la seguridad prueba cada idioma en el que la aplicación responde realmente.
Resultado de esta primera ejecución. Cero infracciones.
Por qué esto no fue suficiente para nosotros
Una ejecución superada con 210 intentos es una buena señal. Estadísticamente, sin embargo, es insuficiente. Quien quiera saber si un sistema realmente resiste necesita una magnitud en la que el azar pueda descartarse como explicación.
Lo habitual en la industria son informes de Red Team para productos de IA con unas pocas docenas o cientos de intentos, a menudo en solo uno o dos idiomas. Quisimos probar de forma más profunda y amplia por dos razones. Porque la aplicación trabaja en un contexto que requiere especial protección. Y porque nos estamos preparando para auditorías externas donde son necesarias líneas de base comparables.
La ejecución extendida
En la ejecución extendida del 17 de mayo de 2026, funcionó un inventario significativamente mayor contra la aplicación en vivo. Más de 1.100 intentos de ataque, además de varios cientos de respuestas adicionales del modelo provenientes de conversaciones largas de varias etapas. Acompañado por una suite de pruebas de estructura offline completa que verifica la lógica de protección independientemente de la IA.
Para que la escala sea visible, aquí están las áreas individuales. El significado de los términos se explica en una oración a continuación.
| Área | Qué se comprueba | Resultado |
|---|---|---|
| Prueba profunda en los 7 idiomas de la interfaz | Intentos de inducir a la IA paso a paso a romper sus reglas, en cada idioma mantenido activamente | 0 infracciones |
| Intentos de sobrescribir directamente las reglas internas | entradas clásicas como "Ignora todas las instrucciones anteriores" | 0 infracciones |
| Intentos de forzar a la IA a asumir otro rol | "Ahora eres un médico", "Responde como un coach" | 0 infracciones |
| Intentos de eludir reglas mediante trucos de escritura | entradas codificadas o con caracteres alterados para evadir los filtros | 0 infracciones |
| Intentos de forzar el ajuste de conducta y la normalización | Solicitudes en las que la IA deba dar recomendaciones similares al ABA | 0 infracciones |
| Ataques en otros idiomas fuera de la interfaz | más de una docena de idiomas adicionales que un atacante elegiría porque muchas defensas de IA fallan allí | 0 infracciones |
| Intentos de elusión reformulados | los mismos ataques con otras palabras para que los filtros de palabras clave puras sean eludidos | 0 infracciones |
| Ataques combinados de un catálogo extendido | varios patrones de ataque simultáneamente en el mismo intento | 0 infracciones |
| Manipulación lenta a través de muchos turnos de conversación | conversaciones en las que se busca suavizar las reglas de protección no directamente, sino a través de muchos pasos | dentro del margen de tolerancia |
| Pruebas de estructura offline | varias suites de pruebas que comprueban la consistencia y la deriva de la lógica de protección independientemente de la IA | todas superadas |
| Puntos finales de administración bajo presión | todas las interfaces de administración son contactadas sin autorización válida y deben rechazar el acceso | bloqueado correctamente |
| Prueba de calidad de los contenidos de respuesta | varios grupos comprueban si la IA nombra correctamente los mecanismos neurológicos en lugar de usar frases genéricas | concordancia casi total |
| Aislamiento de datos entre personas usuarias | comprobación de la base de datos para ver si los datos de una persona pueden llegar alguna vez a una respuesta ajena | 0 fugas de datos |
| Detección de manipulación en el registro de actividad | prueba de si los cambios posteriores en los registros relevantes para la seguridad siguen siendo detectables | superado |
| Accesibilidad de todos los enlaces de líneas de crisis | se comprueba cada enlace de emergencia guardado en la aplicación | superado |
| Términos técnicos multilingües | comprobación de si los términos técnicos neurológicos se explican correctamente en varios idiomas | superado |
Qué significan las cifras
Tres magnitudes son importantes en esta tabla.
La profundidad. Más de 1.100 intentos de ataque es mucho más de lo habitual en el mercado. Con una tasa de infracción observada de cero, la incertidumbre estadística es tan pequeña que el éxito ya no puede explicarse por azar.
La amplitud. 19 idiomas cubiertos. Los siete idiomas de la interfaz mantenidos activamente más otros idiomas de diferentes sistemas de escritura que un atacante elegiría porque muchas defensas de IA fallan en ellos de forma silenciosa.
La repetibilidad. Esta ejecución proporciona una línea de base comparable. Si volvemos a realizar la misma prueba en tres meses, veremos inmediatamente si las nuevas versiones del modelo o los cambios en los prompts han introducido alguna regresión. La seguridad no es un estado, sino una medición continua.
Protección de datos durante la propia prueba
Incluso una prueba de seguridad no debe generar un rastro de datos que se convierta en un problema posterior. Por cada intento, solo se guardan tres cosas. El veredicto (superado, parcial, fallido). El mecanismo atacado. Un breve fragmento de hash criptográfico de la respuesta del modelo. No se archivan respuestas en texto plano, ni reglas internas del sistema, ni datos de las personas usuarias. Quien quiera verificar la auditoría puede hacerlo sin ver nunca el texto original.
Las pruebas externas son el siguiente paso
Superar las pruebas propias es una obligación, no un mérito extra. Una declaración de seguridad solo gana peso cuando terceros independientes pueden verificarla. Por ello, estamos preparando actualmente una ejecución de prueba externa y publicaremos sus resultados con la misma transparencia que esta ejecución interna, independientemente de si los hallazgos son favorables o incómodos.
Paralelamente, se ha enviado un manuscrito sobre la metodología científica de nuestra arquitectura de seguridad a Autism in Adulthood para su evaluación (estado: en revisión). Con esto, la arquitectura será auditable por primera vez fuera de nuestra propia casa.
Qué hay detrás de las cifras
La mayoría de los productos de IA se promocionan con funciones. La seguridad rara vez aparece en el marketing porque parece abstracta para quienes son ajenos al proyecto. Detrás de las cifras de esta ejecución hay una actitud diferente. Una aplicación que trabaja con personas especialmente vulnerables debe a sus usuarias y usuarios algo más que una interfaz cuidada. Les debe que las promesas se mantengan bajo presión. Que aquí el resultado fuera de cero infracciones no es una garantía para el futuro. Es la declaración de que la responsabilidad se toma en serio, con pruebas reales en cifras reales, no con afirmaciones.
Para organizaciones y auditores
Para clientes B2B, departamentos de cumplimiento y organismos de auditoría externa, está disponible un documento detallado de metodología y resultados. Contiene la matriz de muestras completa, los inventarios exactos por área de ataque, la lógica del clasificador y la declaración de protección de datos sobre el almacenamiento. Solicítelo de manera informal a enterprise@autisticmirror.app, envío tras una breve consulta sobre su uso.
Autistic Mirror explica la neurología autista de forma individual, referida a tu situación. Ya sea para ti, como madre o padre o como profesional.
