Achtergrond

Wat er gebeurt als je software bouwt voor mensen, niet voor de markt

In de afgelopen weken kwamen de eerste compliance-aanvragen van organisaties binnen. Lijsten met eisen op het gebied van informatiebeveiliging, gegevensbescherming, software-ergonomie en toegankelijkheid. Bij het vergelijken met de eigen architectuur kwam er iets onverwachts naar voren: het meeste was er al. Niet omdat een norm dat vereiste. Maar omdat de doelgroep het nodig had.

Deze observatie lijkt op het eerste gezicht onbeduidend. Ze wordt interessanter zodra je ziet wat een compliance-toetsing van een groot concern daadwerkelijk uitvraagt. Want de eisen die daar op tafel liggen, zijn niet ontstaan uit een juridisch doel op zich. Ze zijn gegroeid uit concrete schade die software in het verleden heeft veroorzaakt.

Wat er bij een concern-audit daadwerkelijk wordt getoetst

Een foutieve applicatie kan personeelsgegevens blootleggen, klantaccounts compromitteren, toeleveringsketens onderbreken of hele divisies regulatorisch in twijfel trekken. Juist uit deze risico's zijn in de loop der decennia vijf groepen eisen ontstaan die tegenwoordig elk inkoop-proces in een middelgroot of groot bedrijf toetst:

• ISO/IEC 27001 regelt informatiebeveiliging als een managementsysteem. Wie heeft toegangsrechten, hoe wordt er versleuteld, wat wordt er gelogd, hoe reageert de organisatie op een incident.
• OWASP Top 10 is de industriestandaard voor applicatiebeveiliging. Welke klassen van kwetsbaarheden bestaan er en hoe wordt de software daartegen gehard.
• GDPR (AVG) definieert de rechten van de betrokkene. Inzage, rectificatie, verwijdering, dataportabiliteit, dataminimalisatie. En het vereist een gegevensbeschermingseffectbeoordeling zodra bijzondere categorieën persoonsgegevens worden verwerkt, waartoe gezondheids- en neurodivergentie-informatie behoren.
• EN ISO 9241 definieert software-ergonomie. Zeven dialoogprincipes, van geschiktheid voor de taak tot zelfbeschrijvend vermogen en foutentolerantie. Een norm die vraagt: kan een mens met deze software werken zonder erdoor opgebrand te raken.
• WCAG 2.1 Level AA is de internationale standaard voor toegankelijkheid. Toetsenbordbedienbaarheid, contrast, aankondiging via screenreaders, reflow, schaalbaarheid. Sinds 2025 is dit in de EU voor veel sectoren verplicht.

Deze vijf groepen samen vormen een pakket aan eisen waar grote softwarehuizen hele auditteams aan laten werken. Zonder deze bewijsstukken vindt er geen inkoop door een concern plaats.

De onverwachte vergelijking

Bij de systematische vergelijking van de bestaande codebase en database met deze vijf groepen was het resultaat: voldaan, op twee externe stappen na die met het eerste concerncontract geactiveerd worden. Een formele certificering door een geaccrediteerde auditor en een externe penetratietest. Beide vereisen geen ingreep in de bestaande architectuur.

• ISO/IEC 27001 Annex A: 12 van de 13 beheersingsmaatregelen behaald. A.6 Organisatie van informatiebeveiliging organisatorisch gedeeltelijk (Single-Point-of-Contact structuur).
• OWASP Top 10: alle tien de categorieën behaald, gedocumenteerd in Audit 20.
• GDPR: 18 artikelen in de mapping behaald, inclusief gegevensbeschermingseffectbeoordeling met acht risicoscenario's voor bijzondere categorieën persoonsgegevens volgens Art. 9.
• EN ISO 9241: alle zeven dialoogprincipes volgens deel 110 behaald, aangevuld met de relevante delen 112, 125, 143, 171 en 210.
• WCAG 2.1 Level AA: alle 50 succescriteria van Niveau A en AA gedocumenteerd, zonder openstaande kritieke of hoge bevindingen.

Concreet betekent dit, zonder in detail te treden over individuele implementaties: toegangscontrole op recordniveau voor elke tabel. Versleuteling in rust en in beweging. Pseudonimisering van IP-adressen voor het loggen. Auditlog met gestaffelde bewaartermijn. Scheiding van identiteitsgegevens en inhoudelijke gegevens. Volledig verwerkingsregister. Gegevensexport in een gestructureerd, machineleesbaar formaat. Zeven dagen bedenktijd voor definitieve verwijdering. Bescherming tegen de tien meest voorkomende kwetsbaarheden in webapplicaties. Buffer-dan-verzend in plaats van streaming, zodat een beveiligingscontrole het hele antwoord kan zien voordat het aankomt. Toetsenbordbediening voor alle interactieve elementen. Contrastwaarden die de minimale toegankelijkheidswaarden overschrijden. Reductie van visuele prikkels als standaard.

De volledige specificatie met statusinformatie per gebied en verwijzingen naar de respectieve brondocumenten is beschikbaar in het compliance-rapport v1.0.

Waarom was dit er allemaal al

Wie een applicatie bouwt voor autistische mensen, kan niet "snel en een beetje onveilig" bouwen. Een foutief AI-antwoord kan iemand in een crisis storten. Een doorgegeven informatie over een diagnose kan een baan kosten of een proces over ouderlijk gezag beïnvloeden. Een interface met te veel prikkels sluit een deel van de doelgroep vanaf het eerste scherm uit.

Uit deze dreigingssituatie ontstonden architectuurkeuzes die achteraf gezien identiek zijn aan concernvereisten. De Anti-ABA-filter (bescherming tegen antwoorden die autistische mensen willen normaliseren of conditioneren) is feitelijk een vorm van output-beveiliging volgens de OWASP-logica. Crisisdetectie redundant in frontend en backend is Defense-in-Depth volgens ISO 27001. Pseudonimisering van IP's is dataminimalisatie volgens Artikel 5 GDPR. Soft-delete met een wachtperiode is een vooruitziende implementatie van het recht op beperking volgens Artikel 18.

Geen van deze beslissingen werd genomen om aan een norm te voldoen. Er werd voor gekozen omdat een kwetsbare doelgroep ze nodig heeft. Dat ze terloops aan de norm voldoen, is de onbedoelde consequentie.

Wat dit met de Peer Review te maken heeft

Het wetenschappelijke tijdschrift Autism in Adulthood (Mary Ann Liebert, Impact Factor 9.5, Q1 in Developmental Psychology) beoordeelt momenteel een bijdrage die het concept achter Autistic Mirror duidt. Een wetenschappelijke review kijkt niet alleen naar het idee en de ambitie. Het kijkt naar de daadwerkelijke uitvoering. Software zonder een solide beveiligings- en ethische architectuur is in een review moeilijk te verdedigen. Methodische zuiverheid op wetenschappelijk niveau en architecturale zuiverheid op technisch niveau wortelen in hetzelfde punt.

Daarmee is compliance geen aparte laag die er achteraf overheen wordt gelegd. Het is de voorwaarde om de wetenschappelijke toetsing überhaupt zinvol mogelijk te maken. Wat een kwetsbare doelgroep aan veiligheid en waardigheid nodig heeft, komt overeen met wat een serieuze wetenschappelijke beoordeling aan methodische zuiverheid verlangt. Beide maatstaven wortelen in hetzelfde punt: een product mag de mensen die het moet helpen geen extra schade toebrengen.

Een observatie over kleine structuren

Compliance van deze diepgang ontstaat in concerns gedurende jaren. Beveiligingsteams, juridische afdelingen, UX-onderzoek, externe audits, kwaliteitsborging. Dat een zeer kleine structuur in een eerste productversie op een vergelijkbaar punt kan uitkomen, heeft een specifieke reden.

In het autisme-onderzoek wordt een verwerkingspatroon beschreven dat men simultane binnen- en buitenobservatie kan noemen: zelfobservatie en systeemobservatie lopen parallel in plaats van sequentieel. Gecombineerd met een biografie die de gevolgen van slecht gebouwde systemen van binnenuit kent, ontstaat er een lijst met eisen die geen enkel bestek ooit levert. Waar een klassiek productteam vraagt "wat verlangt de markt", vraagt deze manier van verwerken "wat gebeurt er met de mens die dit gebruikt als er op dit punt iets misgaat".

Markten verlangen vaak precies wat mensen nodig hebben. Ze formuleren het alleen in een andere taal: als compliance, risico, reputatie, audit. Als je vanuit de andere richting bouwt, vanuit de concrete behoefte van de mens, kom je soms op hetzelfde punt uit als waar de norm staat. Niet omdat je de norm hebt gelezen. Maar omdat de norm op dezelfde grond staat: dat een systeem mensen niet mag beschadigen.

Een lichtpuntje

Wie een product vanuit de essentie bouwt, kan compliance-bewijzen binnen enkele dagen consolideren omdat de substantie er al is. Wie een product vanuit compliance bouwt, kan de behoeften van mensen vaak niet meer achteraf inbouwen omdat de substantie ontbreekt. Dat is een kwestie van volgorde. En die bepaalt of een product uiteindelijk beide is: levensvatbaar voor de mensen voor wie het is gemaakt, en levensvatbaar voor de organisaties die het inkopen.

Autistic Mirror is een AI-chat die uitlegt wat er in het autistische zenuwstelsel gebeurt. Voor autistische volwassenen en voor hun omgeving. Mechanisme in plaats van advies. Uitleg in plaats van correctie. De app is geen medisch hulpmiddel en vervangt geen medische of therapeutische behandeling. Het is een neurologische vertaallaag, gebouwd met respect voor de doelgroep en, naar nu blijkt, terloops in een staat die al aan de meeste concernvereisten voldoet.