Contexto
Qué sucede cuando construyes software para las personas y no para el mercado
En las últimas semanas llegaron las primeras solicitudes de cumplimiento por parte de organizaciones. Listas con requisitos de seguridad de la información, protección de datos, ergonomía de software y accesibilidad. Al contrastarlos con la propia arquitectura, resultó algo inesperado: la mayor parte ya estaba allí. No porque una norma lo exigiera, sino porque el grupo de usuarios lo necesitaba.
Esta observación es discreta a primera vista. Se vuelve más interesante en cuanto se observa lo que realmente evalúa una auditoría de cumplimiento corporativa. Porque los requisitos que están sobre la mesa no han nacido de un fin jurídico en sí mismo. Han crecido a partir de daños concretos que el software ha causado en el pasado.
Lo que realmente se evalúa en una auditoría corporativa
Una aplicación defectuosa puede exponer datos del personal, comprometer cuentas de clientes, interrumpir cadenas de suministro o poner en duda áreas de negocio completas ante el regulador. Precisamente de estos riesgos han surgido durante décadas cinco familias de requisitos que hoy comprueba cualquier proceso de adquisición en una mediana o grande empresa:
- ISO/IEC 27001 regula la seguridad de la información como sistema de gestión. Quién tiene autorización de acceso, cómo se encripta, qué se registra, cómo reacciona la organización ante un incidente.
- OWASP Top 10 es el estándar industrial para la seguridad de aplicaciones. Qué clases de vulnerabilidades existen y cómo se refuerzan contra ellas.
- GDPR define los derechos de las personas interesadas. Acceso, rectificación, supresión, portabilidad de datos, minimización de datos. Y exige una Evaluación de Impacto relativa a la Protección de Datos en cuanto se procesan categorías especiales de datos personales, entre los que se incluye la información sobre salud y neurodivergencia.
- EN ISO 9241 define la ergonomía del software. Siete principios del diálogo, desde la adecuación a la tarea hasta la capacidad de autodescripción y la tolerancia a errores. Una norma que pregunta: ¿puede un ser humano trabajar con este software sin desgastarse con él?
- WCAG 2.1 Nivel AA es el estándar internacional para la accesibilidad. Manejo por teclado, contraste, anuncio mediante lectores de pantalla, reflow, escalabilidad. Desde 2025, esto es vinculante en la UE para muchos sectores.
Estas cinco familias juntas dan lugar a un pliego de condiciones en el que las grandes casas de software ponen a trabajar a equipos completos de auditoría. Sin estas evidencias, no se produce ninguna compra corporativa.
El contraste inesperado
Al contrastar sistemáticamente la base de código existente y la base de datos con estas cinco familias, el resultado fue este: cumplido, a excepción de dos pasos externos que se activan con el primer contrato corporativo. Una certificación formal por un auditor acreditado y una prueba de penetración externa. Ambos procesos no requieren ninguna intervención en la arquitectura existente.
- ISO/IEC 27001 Anexo A: 12 de las 13 familias de controles cumplidas. A.6 Organización de la seguridad de la información cumplida parcialmente a nivel organizativo (estructura de punto único de contacto).
- OWASP Top 10: las diez categorías cumplidas, documentadas en la auditoría 20.
- GDPR: 18 artículos cumplidos en el mapeo, incluyendo la Evaluación de Impacto relativa a la Protección de Datos con ocho escenarios de riesgo para categorías especiales de datos personales según el Art. 9.
- EN ISO 9241: los siete principios de diálogo según la parte 110 cumplidos, complementados con las partes relevantes 112, 125, 143, 171 y 210.
- WCAG 2.1 Nivel AA: los 50 criterios de éxito Nivel A y AA documentados, sin hallazgos críticos o altos pendientes.
De forma concreta, esto significa, sin entrar en detalles de implementaciones individuales: control de acceso a nivel de registro para cada tabla. Encriptación en reposo y en movimiento. Seudonimización de direcciones IP antes del registro de logs. Registro de auditoría con tiempo de conservación escalonado. Separación de datos de identidad y datos de contenido. Registro completo de actividades de tratamiento. Exportación de datos en un formato estructurado y legible por máquina. Periodo de carencia de siete días antes de la eliminación definitiva. Protección contra las diez vulnerabilidades de aplicaciones web más comunes. Buffer-then-Send en lugar de streaming, para que una comprobación de seguridad pueda ver toda la respuesta antes de que llegue. Manejo con teclado para todos los elementos interactivos. Valores de contraste que superan los valores mínimos de accesibilidad. Reducción de estímulos visuales por defecto.
El desglose completo con indicación de estado por área y referencia a los documentos fuente correspondientes se encuentra en el informe de cumplimiento v1.0.
Por qué estaba todo ya ahí
Quien construye una aplicación para personas autistas no puede construir de forma "rápida y algo insegura". Una respuesta errónea de la IA puede llevar a alguien a una crisis. Una información transmitida sobre un diagnóstico puede costar un empleo o influir en un proceso de custodia. Una interfaz con demasiados estímulos excluye a parte del grupo objetivo desde la primera pantalla.
De esta situación de amenaza surgieron decisiones de arquitectura que, en retrospectiva, son idénticas a los requisitos corporativos. El filtro anti-ABA (protección contra respuestas que intentan normalizar o condicionar a las personas autistas) es de hecho una forma de seguridad de salida (output security) según la lógica de OWASP. La detección de crisis redundante en frontend y backend es defensa en profundidad (defense-in-depth) según ISO 27001. La seudonimización de IPs es minimización de datos según el artículo 5 del GDPR. El borrado suave (soft-delete) con periodo de carencia es una implementación previsora del derecho a la limitación según el artículo 18.
Ninguna de estas decisiones se tomó para cumplir una norma. Se tomó porque un grupo de personas vulnerables lo necesita. Que además cumpla la norma es la consecuencia involuntaria.
Qué tiene esto que ver con la revisión por pares
La revista científica Autism in Adulthood (Mary Ann Liebert, factor de impacto 9.5, Q1 en Psicología del Desarrollo) está evaluando actualmente un artículo que clasifica el concepto detrás de Autistic Mirror. Una revisión científica no solo observa la idea y la pretensión. Observa la implementación real. Un software sin una arquitectura de seguridad y ética sólida es difícil de defender en una revisión. El rigor metodológico a nivel científico y el rigor arquitectónico a nivel técnico echan raíces en el mismo punto.
Por tanto, el cumplimiento no es una capa separada que se coloca encima posteriormente. Es el requisito previo para que la evaluación científica sea posible de forma significativa. Lo que un grupo de personas vulnerables necesita en materia de seguridad y dignidad coincide con lo que una evaluación científica seria exige en rigor metodológico. Ambos estándares echan raíces en el mismo punto: un producto no debe causar daños adicionales a las personas a las que pretende ayudar.
Una observación sobre las estructuras pequeñas
El cumplimiento de esta profundidad surge en las corporaciones a lo largo de los años. Equipos de seguridad, departamentos jurídicos, investigación UX, auditorías externas, control de calidad. El hecho de que una estructura muy pequeña pueda llegar a un punto similar en una primera versión de producto tiene una razón específica.
En la investigación sobre autismo se describe un patrón de procesamiento que se puede llamar observación simultánea interna y externa: la observación de uno mismo y la del sistema funcionan en paralelo en lugar de secuencialmente. Combinado con una biografía que conoce desde dentro las consecuencias de los sistemas mal construidos, surge una lista de requisitos que ninguna especificación de diseño convencional ofrece jamás. Donde un equipo de producto clásico pregunta "qué exige el mercado", este modo de procesamiento pregunta "qué le ocurre a la persona que usa esto si algo sale mal en este punto".
Los mercados a menudo exigen exactamente lo que las personas necesitan. Solo lo formulan en otro lenguaje: como cumplimiento, riesgo, reputación, auditoría. Cuando se construye desde la otra dirección, desde la necesidad concreta de la persona, a veces se llega al mismo punto en el que se encuentra la norma. No porque uno haya leído la norma, sino porque la norma se asienta en el mismo suelo: que un sistema no debe dañar a las personas.
Un rayo de esperanza
Quien construye un producto partiendo de la esencia puede consolidar las evidencias de cumplimiento en pocos días porque la sustancia ya está ahí. Quien construye un producto a partir del cumplimiento, a menudo no puede incorporar posteriormente las necesidades de las personas porque falta la sustancia. Es una cuestión de orden. Y decide si un producto es, al final, ambas cosas: sostenible para las personas para las que fue hecho y sostenible para las organizaciones que lo adquieren.
Autistic Mirror es un chat de IA que explica qué sucede en el sistema nervioso autista. Para personas adultas autistas y para su entorno. Mecanismo en lugar de consejo. Explicación en lugar de corrección. La aplicación no es un producto médico y no sustituye el tratamiento médico o terapéutico. Es una capa de traducción neurológica, construida con respeto hacia el grupo objetivo y, como se ha comprobado, casualmente en un estado que ya cumple la mayoría de los requisitos corporativos.
