Hvad sker der, når man bygger software til mennesker, ikke til markedet

I løbet af de seneste uger kom de første compliance-anmodninger fra organisationer. Lister med krav inden for informationssikkerhed, databeskyttelse, softwareergonomi og tilgængelighed. At kortlægge dem mod den eksisterende arkitektur gav et uventet resultat: det meste var allerede på plads. Ikke fordi en standard krævede det. Men fordi målgruppen havde brug for det.

Observationen ser umiddelbart ubemærkelsesværdig ud. Den bliver interessant, først når man ser, hvad en enterprise compliance-gennemgang faktisk spørger om. De krav, der ender på bordet, opstod ikke som et juridisk mål i sig selv. De voksede ud af konkret skade, som software har forårsaget tidligere.

Hvad en enterprise-gennemgang faktisk spørger om

En fejlbehæftet applikation kan eksponere personaledata, kompromittere kundekonti, forstyrre forsyningskæder eller bringe hele forretningsenheder i regulatorisk fare. Ud fra præcis disse risici har der i årtier udviklet sig fem familier af krav, som enhver indkøbsproces i en mellemstor eller stor organisation i dag vil kontrollere:

Tilsammen producerer disse fem familier et kravomfang, som store softwareleverandører bemander hele auditteams til at håndtere. Uden denne dokumentation sker ingen enterprise-indkøb.

Det uventede match

At kortlægge den eksisterende kodebase og database systematisk mod disse fem familier gav dette resultat: opfyldt, bortset fra to eksterne skridt, der aktiveres med den første enterprise-kontrakt. En formel certificering af en akkrediteret revisor og en ekstern penetrationstest. Ingen af dem kræver nogen ændring af den eksisterende arkitektur.

Konkret, uden at gå ind i individuelle implementeringer: rækkevis adgangskontrol på hver tabel. Kryptering i hvile og under transport. Pseudonymisering af IP-adresser inden logning. Auditlog med lagdelt retention. Adskillelse af identitetsdata og indholdsdata. En komplet fortegnelse over behandlingsaktiviteter. Dataeksport i et struktureret, maskinlæsbart format. Syv dages respitperiode inden endelig sletning. Beskyttelse mod de ti mest almindelige webapplikations-sårbarheder. Buffer-then-send i stedet for streaming, så et sikkerhedstjek kan se hele svaret, inden det ankommer. Tastaturbetjening af alle interaktive elementer. Kontrastværdier, der overstiger minimumsværdierne for tilgængelighed. Reduceret sensorisk belastning som standard.

Den fulde opdeling med status pr. område og referencer til de underliggende kildedokumenter er tilgængelig i Compliance Report v1.0.

Hvorfor alt dette allerede var på plads

Hvis man bygger en applikation til autistiske personer, kan man ikke bygge den "hurtigt og lidt usikkert". Et fejlagtigt AI-svar kan skubbe nogen ud i en krise. Et stykke diagnostisk information videregivet til det forkerte sted kan koste et job eller forme en forældreretssag. En grænseflade, der er for sensorisk intens, ekskluderer en del af målgruppen fra den allerførste skærm.

Fra dette trusselsbillede opstod arkitektoniske beslutninger, der retrospektivt falder på linje med enterprise-krav. Et anti-ABA-filter (beskyttelse mod svar, der forsøger at normalisere eller konditionere autistiske personer) er teknisk set en form for output-sikkerhed i OWASP-forstand. Krisedetektering redundant i frontend og backend er forsvar i dybden i ISO 27001-forstand. IP-pseudonymisering er dataminimering i henhold til GDPR-artikel 5. Blød sletning med en respitperiode er en fremadrettet implementering af retten til begrænsning i henhold til Artikel 18.

Ingen af disse beslutninger blev truffet for at opfylde en standard. De blev truffet, fordi en sårbar målgruppe havde brug for dem. Det faktum, at de tilfældigvis er standardkonorme, er den utilsigtede konsekvens.

Hvordan dette forbinder sig til peer review

Det videnskabelige tidsskrift Autism in Adulthood (Mary Ann Liebert, Impact Factor 9,5, Q1 inden for udviklingspsykologi) gennemgår i øjeblikket en indsendelse, der rammesætter konceptet bag Autistic Mirror. En videnskabelig gennemgang ser ikke kun på ide og ambition. Den ser på den faktiske implementering. Software uden en solid sikkerheds- og etikerarkitektur er svær at forsvare i review. Metodologisk soliditet på det videnskabelige niveau og arkitektonisk soliditet på det tekniske niveau er rodfæstet i det samme punkt.

Compliance er derfor ikke et separat lag, der efterfølgende lægges oven på. Det er forudsætningen for, at den videnskabelige gennemgang overhovedet kan give mening. Hvad en sårbar gruppe behøver med hensyn til sikkerhed og værdighed overlapper med, hvad en seriøs videnskabelig gennemgang kræver med hensyn til metodologisk soliditet. Begge hviler på det samme punkt: et produkt må ikke forårsage yderligere skade på de mennesker, det er ment til at hjælpe.

En observation om små strukturer

Compliance på denne dybde er noget, virksomheder bygger op over år. Sikkerhedsteams, juridiske afdelinger, UX-forskning, eksterne audits, kvalitetssikring. At en meget lille struktur kan lande tæt på et lignende punkt i en første produktversion har en specifik årsag.

Autismeforskning beskriver et behandlingsmønster, der kan kaldes simultan selv- og systemobservation: selvobservation og systemobservation kører parallelt frem for sekventielt. Kombineret med en biografi, der kender konsekvenserne af dårligt byggede systemer indefra, producerer dette en kravliste, som intet specifikationsdokument nogensinde leverer. Hvor et klassisk produktteam spørger "hvad kræver markedet", spørger denne behandlingstilstand "hvad sker der med det menneske, der bruger dette, hvis noget går galt her".

Markeder kræver ofte præcis, hvad mennesker har brug for. De formulerer det blot på et andet sprog: som compliance, risiko, omdømme, audit. At bygge fra den anden retning, fra hvad et menneske konkret har brug for, lander sommetider ved det samme punkt, som standarden befinder sig ved. Ikke fordi nogen læste standarden. Men fordi standarden hviler på det samme fundament: at et system ikke må skade mennesker.

Et lyspunkt

At bygge et produkt fra substans giver mulighed for at konsolidere compliance-dokumentation på dage, fordi substansen allerede er der. At bygge et produkt fra compliance giver ofte ikke mulighed for at eftermontere menneskelige behov, fordi substansen mangler. Det er et spørgsmål om rækkefølge. Og det afgør, om et produkt ender med at være begge dele: levedygtigt for de mennesker, det blev lavet til, og levedygtigt for de organisationer, der køber det.

Autistic Mirror er en AI-chat, der forklarer, hvad der sker i det autistiske nervesystem. For autistiske voksne og deres omgivelser. Mekanisme frem for råd. Forklaring frem for korrektion. Appen er ikke et medicinsk udstyr og erstatter ikke medicinsk eller terapeutisk behandling. Det er et neurologisk oversættelseslag, bygget med respekt for de mennesker, det tjener, og, som det viser sig, i en tilstand, der allerede opfylder de fleste enterprise-krav.

Aaron Wahl
Aaron Wahl

Autistisk, grundlægger af Autistic Mirror

Appen, denne artikel handler om.

Opret gratis konto