Contexto
O que acontece quando se constrói software para pessoas, não para o mercado
Nas últimas semanas, chegaram as primeiras solicitações de conformidade de organizações. Listas com requisitos de segurança da informação, proteção de dados, ergonomia de software e acessibilidade. Ao comparar com a própria arquitetura, algo inesperado se revelou: a maior parte já estava lá. Não porque uma norma exigia, mas porque o público-alvo precisava.
Essa observação parece insignificante à primeira vista. Torna-se mais interessante quando se vê o que uma auditoria de conformidade corporativa realmente solicita. Pois os requisitos que estão sobre a mesa não surgiram de uma finalidade jurídica em si. Eles cresceram a partir de danos concretos que softwares causaram no passado.
O que é realmente solicitado em uma auditoria corporativa
Uma aplicação defeituosa pode expor dados de pessoal, comprometer contas de clientes, interromper cadeias de suprimentos ou questionar regulatoriamente divisões inteiras de negócios. Exatamente desses riscos surgiram, ao longo de décadas, cinco famílias de requisitos que hoje todo processo de aquisição em uma média ou grande empresa verifica:
- ISO/IEC 27001 regula a segurança da informação como um sistema de gestão. Quem tem autorização de acesso, como é feita a criptografia, o que é registrado em log, como a organização reage a um incidente.
- OWASP Top 10 é o padrão da indústria para segurança de aplicações. Quais classes de vulnerabilidades existem e como o sistema é endurecido contra elas.
- GDPR define os direitos dos titulares dos dados. Informação, retificação, exclusão, portabilidade de dados, minimização de dados. E exige uma avaliação de impacto sobre a proteção de dados sempre que categorias especiais de dados pessoais são processadas, o que inclui informações de saúde e neurodivergência.
- EN ISO 9241 define a ergonomia do software. Sete princípios de diálogo, desde a adequação à tarefa e capacidade de autodescrição até a tolerância a erros. Uma norma que pergunta: um ser humano pode trabalhar com este software sem se desgastar com ele?
- WCAG 2.1 Level AA é o padrão internacional para acessibilidade. Operabilidade por teclado, contraste, anúncio de leitores de tela, refluxo, escalabilidade. Desde 2025, isso é obrigatório na UE para muitas áreas.
Essas cinco famílias juntas resultam em um escopo de especificações no qual grandes empresas de software mantêm equipes inteiras de auditoria trabalhando. Sem essas evidências, nenhuma compra corporativa acontece.
A comparação inesperada
Na comparação sistemática da base de código e do banco de dados existentes com essas cinco famílias, o resultado foi este: cumprido, exceto por dois passos externos que serão ativados com o primeiro contrato corporativo. Uma certificação formal por um auditor credenciado e um teste de intrusão externo. Ambos não exigem intervenção na arquitetura existente.
- ISO/IEC 27001 Annex A: 12 de 13 famílias de controle cumpridas. A.6 Organização da segurança da informação cumprida parcialmente no nível organizacional (estrutura de ponto único de contato).
- OWASP Top 10: todas as dez categorias cumpridas, documentadas na Auditoria 20.
- GDPR: 18 artigos cumpridos no mapeamento, incluindo avaliação de impacto sobre a proteção de dados com oito cenários de risco para categorias especiais de dados pessoais conforme Art. 9.
- EN ISO 9241: todos os sete princípios de diálogo conforme parte 110 cumpridos, complementados pelas partes relevantes 112, 125, 143, 171 e 210.
- WCAG 2.1 Level AA: todos os 50 critérios de sucesso Nível A e AA documentados, sem descobertas críticas ou altas pendentes.
Na prática, isso significa, sem entrar em detalhes de implementações individuais: controle de acesso em nível de registro para cada tabela. Criptografia em repouso e em movimento. Pseudonimização de endereços IP antes do registro em log. Log de auditoria com tempo de retenção escalonado. Separação de dados de identidade e dados de conteúdo. Registro completo de atividades de processamento. Exportação de dados em formato estruturado e legível por máquina. Período de carência de sete dias antes da exclusão definitiva. Proteção contra as dez vulnerabilidades mais comuns de aplicações web. Buffer-then-Send em vez de streaming, para que uma verificação de segurança possa ver a resposta inteira antes que ela chegue. Operabilidade por teclado para todos os elementos interativos. Valores de contraste que excedem os mínimos de acessibilidade. Redução de estímulos visuais como padrão.
O detalhamento completo com indicação de status por área e referência aos respectivos documentos de origem está disponível no Relatório de Conformidade v1.0.
Por que tudo isso já estava lá
Quem constrói uma aplicação para pessoas autistas não pode construir de forma rápida e um pouco insegura. Uma resposta de IA errônea pode levar alguém a uma crise. Uma informação repassada sobre um diagnóstico pode custar um emprego ou influenciar um processo de custódia. Uma interface excessivamente estimulante exclui parte do público-alvo já na primeira tela.
Dessa situação de ameaça surgiram decisões de arquitetura que, em retrospectiva, são congruentes com os requisitos corporativos. Filtros Anti-ABA (proteção contra respostas que visam normalizar ou condicionar pessoas autistas) são, de fato, uma forma de segurança de saída conforme a lógica da OWASP. A detecção de crises redundante no frontend e backend é Defense-in-Depth conforme a ISO 27001. A pseudonimização de IPs é minimização de dados conforme o Artigo 5 da GDPR. O Soft-delete com período de carência é uma implementação antecipada do direito à limitação conforme o Artigo 18.
Nenhuma dessas decisões foi tomada para cumprir uma norma. Foi tomada porque um público-alvo vulnerável precisa dela. O fato de ser, incidentalmente, conforme a norma, é a consequência não intencional.
O que isso tem a ver com o Peer Review
O periódico científico Autism in Adulthood (Mary Ann Liebert, Fator de Impacto 9.5, Q1 em Psicologia do Desenvolvimento) está revisando atualmente um artigo que contextualiza o conceito por trás do Autistic Mirror. Uma revisão científica não considera apenas a ideia e a pretensão. Ela considera a implementação real. Software sem uma arquitetura de segurança e ética viável é difícil de defender em uma revisão. O rigor metodológico no nível científico e o rigor arquitetônico no nível técnico têm raízes no mesmo ponto.
Assim, a conformidade não é uma camada separada aplicada posteriormente. Ela é o pré-requisito para que a revisão científica seja sequer significativamente possível. O que um público-alvo vulnerável precisa em termos de segurança e dignidade é congruente com o que uma avaliação científica séria exige em termos de rigor metodológico. Ambos os critérios se baseiam no mesmo princípio: um produto não deve causar danos adicionais às pessoas que ele se propõe a ajudar.
Uma observação sobre estruturas pequenas
Conformidade nessa profundidade surge em corporações ao longo de anos. Equipes de segurança, departamentos jurídicos, pesquisa de UX, auditorias externas, garantia de qualidade. O fato de uma estrutura muito pequena poder chegar a um ponto semelhante em uma primeira versão de produto tem uma razão específica.
Na pesquisa sobre o autismo, é descrito um padrão de processamento que se pode chamar de observação simultânea interna e externa: a observação de si mesmo e do sistema ocorrem em paralelo em vez de sequencialmente. Isso, combinado com uma biografia que conhece por dentro as consequências de sistemas mal construídos, gera uma lista de requisitos que nenhum caderno de especificações jamais entrega. Enquanto uma equipe de produto clássica pergunta o que o mercado exige, esse modo de processamento pergunta o que acontece com a pessoa que utiliza isso se algo der errado neste ponto.
Os mercados muitas vezes exigem exatamente o que as pessoas precisam. Eles apenas o formulam em outra linguagem: como conformidade, risco, reputação, auditoria. Quando se constrói a partir da outra direção, da necessidade concreta do ser humano, às vezes se chega ao mesmo ponto onde a norma está. Não porque se tenha lido a norma, mas porque a norma está sobre o mesmo solo: que um sistema não deve prejudicar as pessoas.
Um sinal de esperança
Quem constrói um produto a partir da essência pode consolidar evidências de conformidade em poucos dias, porque a substância já está lá. Quem constrói um produto a partir da conformidade muitas vezes não consegue mais integrar a necessidade das pessoas posteriormente, porque falta a substância. É uma questão de ordem. E ela decide se um produto é, ao final, ambas as coisas: sustentável para as pessoas para quem foi feito e sustentável para as organizações que o adquirem.
Autistic Mirror é um chat de IA que explica o que acontece no sistema nervoso autista. Para adultos autistas e para as pessoas ao seu redor. Mecanismo em vez de conselho. Explicação em vez de correção. O aplicativo não é um produto médico e não substitui o tratamento médico ou terapêutico. É uma camada de tradução neurológica, construída com respeito pelo público-alvo e, como se revelou, incidentalmente em um estado que já cumpre a maioria dos requisitos corporativos.
