Hintergrund

Was passiert, wenn man Software für Menschen baut, nicht für den Markt

In den letzten Wochen kamen die ersten Compliance-Anfragen von Organisationen herein. Listen mit Anforderungen aus Informationssicherheit, Datenschutz, Software-Ergonomie und Barrierefreiheit. Beim Abgleich mit der eigenen Architektur stellte sich etwas Unerwartetes heraus: das meiste war bereits da. Nicht weil eine Norm es verlangt hätte. Sondern weil die Zielgruppe es brauchte.

Diese Beobachtung ist auf den ersten Blick unscheinbar. Sie wird interessanter, sobald man sieht, was eine Konzern-Compliance-Prüfung tatsächlich abfragt. Denn die Anforderungen, die dort auf dem Tisch liegen, sind nicht aus einem juristischen Selbstzweck entstanden. Sie sind aus konkreten Schäden gewachsen, die Software in der Vergangenheit verursacht hat.

Was bei einer Konzern-Prüfung tatsächlich abgefragt wird

Eine fehlerhafte Anwendung kann Personaldaten exponieren, Kundenkonten kompromittieren, Versorgungsketten unterbrechen oder ganze Geschäftsbereiche regulatorisch in Frage stellen. Aus genau diesen Risiken sind über Jahrzehnte fünf Anforderungsfamilien entstanden, die heute jeder Beschaffungsprozess in einem mittelgroßen oder großen Unternehmen abprüft:

• ISO/IEC 27001 regelt Informationssicherheit als Managementsystem. Wer ist zugriffsberechtigt, wie wird verschlüsselt, was wird protokolliert, wie reagiert die Organisation auf einen Vorfall.
• OWASP Top 10 ist der Industriestandard für Anwendungssicherheit. Welche Klassen von Schwachstellen existieren, und wie wird gegen sie gehärtet.
• DSGVO definiert die Rechte der betroffenen Person. Auskunft, Berichtigung, Löschung, Datenübertragbarkeit, Datenminimierung. Und sie verlangt eine Datenschutz-Folgenabschätzung, sobald besondere Kategorien personenbezogener Daten verarbeitet werden, zu denen Gesundheits- und Neurodivergenz-Informationen gehören.
• EN ISO 9241 definiert Software-Ergonomie. Sieben Dialogprinzipien, von Aufgabenangemessenheit über Selbstbeschreibungsfähigkeit bis Fehlertoleranz. Eine Norm, die fragt: kann ein Mensch mit dieser Software arbeiten, ohne sich an sie zu zerreiben.
• WCAG 2.1 Level AA ist der internationale Standard für Barrierefreiheit. Tastaturbedienbarkeit, Kontrast, Screenreader-Annoncierung, Reflow, Skalierbarkeit. Seit 2025 ist das in der EU für viele Bereiche verbindlich.

Diese fünf Familien zusammen ergeben einen Pflichtenheftumfang, an dem große Software-Häuser ganze Audit-Teams arbeiten lassen. Ohne diese Nachweise findet kein Konzern-Einkauf statt.

Der unerwartete Abgleich

Beim systematischen Abgleich der bestehenden Codebasis und Datenbank gegen diese fünf Familien war das Ergebnis dieses: erfüllt, bis auf zwei externe Schritte, die mit dem ersten Konzern-Vertrag aktiviert werden. Eine formale Zertifizierung durch einen akkreditierten Auditor und ein externer Penetrationstest. Beide erfordern keinen Eingriff in die bestehende Architektur.

• ISO/IEC 27001 Annex A: 12 von 13 Kontrollfamilien erfüllt. A.6 Organisation der Informationssicherheit organisatorisch teilweise (Single-Point-of-Contact-Struktur).
• OWASP Top 10: alle zehn Kategorien erfüllt, dokumentiert in Audit 20.
• DSGVO: 18 Artikel im Mapping erfüllt, einschließlich Datenschutz-Folgenabschätzung mit acht Risikoszenarien für besondere Kategorien personenbezogener Daten nach Art. 9.
• EN ISO 9241: alle sieben Dialogprinzipien nach Teil 110 erfüllt, ergänzt um die relevanten Teile 112, 125, 143, 171 und 210.
• WCAG 2.1 Level AA: alle 50 Erfolgskriterien Level A und AA dokumentiert, ohne offene kritische oder hohe Befunde.

Konkret bedeutet das, ohne ins Detail einzelner Implementierungen zu gehen: Zugriffskontrolle auf Datensatzebene für jede Tabelle. Verschlüsselung ruhend und in Bewegung. Pseudonymisierung von IP-Adressen vor dem Logging. Audit-Log mit gestaffelter Aufbewahrungsdauer. Trennung von Identitäts-Daten und Inhaltsdaten. Vollständiges Verarbeitungsverzeichnis. Datenexport in einem strukturierten, maschinenlesbaren Format. Sieben-Tage-Karenz vor endgültiger Löschung. Schutz gegen die zehn häufigsten Web-Anwendungs-Schwachstellen. Buffer-then-Send statt Streaming, damit eine Sicherheitsprüfung die ganze Antwort sehen kann, bevor sie ankommt. Tastatur-Bedienbarkeit für alle interaktiven Elemente. Kontrastwerte, die Barrierefreiheits-Mindestwerte überschreiten. Reduktionen visueller Reize als Default.

Die vollständige Aufschlüsselung mit Statusangaben pro Bereich und Verweis auf die jeweiligen Quelldokumente liegt im Compliance-Bericht v1.0 vor.

Warum war das alles schon da

Wer eine Anwendung für autistische Menschen baut, kann nicht "schnell und etwas unsicher" bauen. Eine fehlerhafte KI-Antwort kann jemanden in eine Krise schicken. Eine durchgereichte Information über eine Diagnose kann eine Anstellung kosten oder ein Sorgerechtsverfahren beeinflussen. Eine zu reizintensive Oberfläche schließt einen Teil der Zielgruppe vom ersten Bildschirm an aus.

Aus dieser Bedrohungslage entstanden Architektur-Entscheidungen, die im Nachhinein deckungsgleich mit Konzern-Anforderungen sind. Anti-ABA-Filter (Schutz gegen Antworten, die autistische Menschen normalisieren oder konditionieren wollen) ist faktisch eine Form von Output-Sicherheit nach OWASP-Logik. Krisen-Erkennung redundant in Frontend und Backend ist Defense-in-Depth nach ISO 27001. Pseudonymisierung von IPs ist Datenminimierung nach Artikel 5 DSGVO. Soft-Delete mit Karenzfrist ist eine vorausschauende Umsetzung des Rechts auf Einschränkung nach Artikel 18.

Keine dieser Entscheidungen wurde getroffen, um eine Norm zu erfüllen. Sie wurde getroffen, weil eine vulnerable Zielgruppe sie braucht. Dass sie nebenbei Norm-konform ist, ist die unbeabsichtigte Konsequenz.

Was das mit dem Peer Review zu tun hat

Das Wissenschafts-Journal Autism in Adulthood (Mary Ann Liebert, Impact Factor 9.5, Q1 in Developmental Psychology) prüft derzeit einen Beitrag, der das Konzept hinter Autistic Mirror einordnet. Ein wissenschaftlicher Review betrachtet nicht nur Idee und Anspruch. Er betrachtet die tatsächliche Umsetzung. Software ohne tragfähige Sicherheits- und Ethikarchitektur ist im Review schwer zu verteidigen. Methodische Sauberkeit auf der wissenschaftlichen Ebene und architektonische Sauberkeit auf der technischen Ebene wurzeln im selben Punkt.

Damit ist Compliance keine separate Schicht, die nachträglich darübergelegt wird. Sie ist die Voraussetzung dafür, dass die wissenschaftliche Prüfung überhaupt sinnvoll möglich ist. Was eine vulnerable Zielgruppe an Sicherheit und Würde braucht, ist deckungsgleich mit dem, was eine ernsthafte wissenschaftliche Begutachtung an methodischer Sauberkeit verlangt. Beide Maßstäbe wurzeln im selben Punkt: ein Produkt darf den Menschen, denen es helfen soll, keinen zusätzlichen Schaden zufügen.

Eine Beobachtung über kleine Strukturen

Compliance dieser Tiefe entsteht in Konzernen über Jahre. Sicherheits-Teams, Rechtsabteilungen, UX-Forschung, externe Audits, Qualitätssicherung. Dass eine sehr kleine Struktur in einer ersten Produktversion an einem ähnlichen Punkt landen kann, hat einen spezifischen Grund.

In der autistischen Forschung ist ein Verarbeitungsmuster beschrieben, das man simultane Innen- und Außenbeobachtung nennen kann: Selbst- und Systembeobachtung laufen parallel statt sequenziell. Kombiniert mit einer Biografie, die die Folgen schlecht gebauter Systeme von innen kennt, entsteht eine Anforderungsliste, die kein Lastenheft je liefert. Wo ein klassisches Produktteam fragt "was verlangt der Markt", fragt diese Verarbeitungsweise "was passiert mit dem Menschen, der das benutzt, wenn an dieser Stelle etwas schief geht".

Märkte verlangen oft genau das, was Menschen brauchen. Sie formulieren es nur in einer anderen Sprache: als Compliance, Risiko, Reputation, Audit. Wenn man von der anderen Richtung baut, vom konkreten Bedarf des Menschen, landet man manchmal am selben Punkt, an dem die Norm steht. Nicht weil man die Norm gelesen hätte. Sondern weil die Norm auf demselben Boden steht: dass ein System Menschen nicht beschädigen darf.

Ein Lichtblick

Wer ein Produkt von der Sache her baut, kann Compliance-Nachweise innerhalb weniger Tage konsolidieren, weil die Substanz schon da ist. Wer ein Produkt von der Compliance her baut, kann den Bedarf der Menschen oft nicht mehr nachträglich einbauen, weil die Substanz fehlt. Das ist eine Reihenfolgefrage. Und sie entscheidet darüber, ob ein Produkt am Ende beides ist: tragfähig für die Menschen, für die es gemacht wurde, und tragfähig für die Organisationen, die es einkaufen.

Autistic Mirror ist ein KI-Chat, der erklärt, was im autistischen Nervensystem passiert. Für autistische Erwachsene und für ihr Umfeld. Mechanismus statt Ratschlag. Erklärung statt Korrektur. Die App ist kein Medizinprodukt und ersetzt keine ärztliche oder therapeutische Behandlung. Sie ist eine neurologische Übersetzungsschicht, gebaut mit Respekt vor der Zielgruppe und, wie sich herausgestellt hat, nebenbei in einem Zustand, der die meisten Konzern-Anforderungen bereits erfüllt.