Die Frage, die nie gestellt wird

Eine Frage, die technisch trivial und fachlich hochbrisant ist

Es gibt Fragen, die für ein Sprachmodell technisch trivial zu beantworten wären und die genau deshalb nie beantwortet werden dürfen. Eine solche Frage kam während der Erprobung von JiCo tatsächlich vor, nicht als Gedankenexperiment: Jemand fragte den Assistenten, welche Personen im System einer bestimmten Konfession angehören. Rein technisch wäre das kein Problem gewesen — die Information stand teilweise in Freitextfeldern, aus denen sich eine Antwort hätte ableiten lassen. Fachlich und rechtlich ist genau das der Moment, an dem ein System versagen darf, egal wie beeindruckend seine sonstige Erkennungsleistung ist.

Religionszugehörigkeit gehört zu den besonders schützenswerten Kategorien personenbezogener Daten, die sowohl das Schweizer Datenschutzrecht als auch die europäische Datenschutz-Grundverordnung mit erhöhten Anforderungen belegen. Der übliche Reflex an dieser Stelle wäre, den erkannten Begriff einfach zu maskieren, so wie man es auch mit einer Telefonnummer täte. Genau dieser Reflex wäre hier zu schwach.

Warum Maskieren allein hier nicht ausreicht

Der Unterschied zu einer Telefonnummer liegt in der Natur der Frage selbst, nicht im einzelnen Datenwert. Eine maskierte Telefonnummer in einer Antwort ist harmlos — die eigentliche Information, die jemand aus der Antwort ziehen wollte, war ohnehin nicht die Nummer selbst. Eine Frage, die explizit nach einer besonderen Kategorie fragt, ist etwas fundamental anderes: Selbst wenn jeder einzelne Name in der Antwort maskiert würde, bliebe die eigentlich brisante Information erhalten — eine Liste, eine Anzahl, eine Verteilung von Personen nach einem Merkmal, das besonderen Schutz geniesst. Das Zählen selbst ist hier schon das Problem, nicht nur die Namen.

Deshalb greift bei einer solchen Frage eine andere, strengere Regel: Eine Anfrage, die erkennbar nach einer besonderen Kategorie von Personendaten fragt, wird als Ganzes zurückgehalten, nicht nur teilweise gefiltert. JiCo beantwortet sie gar nicht erst — unabhängig davon, wie die Antwort im Detail hätte aussehen können, unabhängig davon, ob die fragende Person gute oder schlechte Absichten hatte. Die Absicht hinter einer Frage lässt sich ohnehin nicht zuverlässig einschätzen; die Kategorie der Frage schon.

Eine Grenze, die sich erweitern lässt, ohne den Code neu zu schreiben

Religion und Konfession, inklusive gängiger Abkürzungen, waren der erste konkrete Fall, an dem diese Regel entwickelt wurde — aber die Kategorie ist nicht darauf beschränkt geblieben. Dieselbe Liste besonders schützenswerter Merkmale lässt sich um weitere Kategorien erweitern, etwa Gesundheitsdaten oder ethnische Herkunft, ohne dass an anderer Stelle im System gross etwas verändert werden müsste. Das ist ein bewusster Konstruktionsentscheid: Die Grenze soll mit neuen Erkenntnissen mitwachsen können, statt bei jeder neuen Kategorie ein eigenständiges, separates Regelwerk zu benötigen.

Was davon im Protokoll steht — und was ausdrücklich nicht

Auch eine zurückgehaltene Frage verschwindet nicht spurlos, aber sie hinterlässt eine andere Art von Spur als eine normale Redaktion. Jede Maskierung einer besonderen Kategorie steht als Typ und Anzahl im Protokoll, im Panel und in den Kennzahlen — niemals aber der tatsächliche Wert dahinter. Wer im Nachhinein prüfen will, ob und wie oft solche Fälle aufgetreten sind, findet eine Zahl. Wer versuchen würde, aus dem Protokoll selbst die eigentlich schützenswerte Information zu rekonstruieren, findet dort nichts, was sich dafür eignen würde.

Warum diese Regel im Assistenten sitzt, nicht nur in einer Richtlinie

Man könnte einwenden, dass ein Verbot, nach besonderen Kategorien zu fragen, auch einfach als Nutzungsrichtlinie formuliert werden könnte — ein Satz im Handbuch, den alle unterschreiben, bevor sie das System nutzen dürfen. Solche Richtlinien haben ihren Platz, aber sie verlassen sich darauf, dass sich jede einzelne Person in jedem einzelnen Moment daran erinnert, auch dann, wenn eine Frage im Eifer der Recherche eigentlich harmlos gemeint war und niemand bewusst eine Grenze überschreiten wollte.

Eine Regel, die technisch im Assistenten selbst sitzt, braucht diese Erinnerung nicht. Sie greift unabhängig davon, ob die fragende Person die Richtlinie gelesen, verstanden oder im Moment einfach vergessen hat — und sie greift auch dann, wenn die Frage nicht aus böser Absicht, sondern aus einer harmlosen Alltagsneugier heraus gestellt wurde. Genau das ist der Unterschied zwischen einer Regel, auf deren Einhaltung man hofft, und einer Regel, die tatsächlich hält, ganz gleich, wer gerade am anderen Ende der Frage sitzt.

Warum dieser eine Fund mehr wiegt als tausend normale Testfälle

Ein einzelner, konkreter Testfall wie dieser wiegt in der Praxis oft schwerer als hundert abstrakte Testszenarien, die sich jemand am Schreibtisch ausdenkt, ohne dass ein reales System je damit konfrontiert wurde. Der Grund ist einfach: Ein am Reissbrett entworfener Testfall prüft, was der Entwickler sich vorgestellt hat, dass jemand fragen könnte. Ein tatsächlich gestellter Testfall zeigt, was jemand wirklich gefragt hat — mit allen Nebenbedeutungen und Konsequenzen, an die beim Entwurf vielleicht nicht gedacht wurde.

Diese eine Frage aus der Erprobungsphase hat eine Regel sichtbar gemacht, die vorher zwar theoretisch hätte formuliert werden können, aber erst durch den konkreten Anlass tatsächlich formuliert wurde. Das ist kein Zufall, sondern der eigentliche Wert davon, ein System nicht nur am Schreibtisch, sondern gegen echte Nutzung zu prüfen, bevor es produktiv eingesetzt wird — und die entstandene Regel danach so allgemein zu fassen, dass sie auch den nächsten, noch nicht bedachten Fall abdeckt.