Erfahrungsbericht 1 · KI-Governance
Wer darf was wissen: Need-to-Know im Code statt in der Disziplin
Wie eine KI-Funktion nur die Daten sieht, die Rolle und Mandant erlauben, auch wenn jemand eine Prüfung vergisst.
- Status
- Erprobung Entwurf in Erprobung, noch nicht in Betrieb.
- Veröffentlicht
- Herausgeber
- SIMO GmbH, Aschaffenburg
AusgangsfrageWie stellen wir sicher, dass eine KI-Funktion nur die Daten sieht, die Rolle und Mandant erlauben, auch dann, wenn ein Entwickler eine Prüfung vergisst?
Was wir erprobt haben
Bisher hing die Berechtigung an einer Middleware-Zeile je Route. Fehlt diese Zeile, ist der Endpunkt offen.
Wir haben ein Modell entworfen, in dem jeder Aufruf eines KI-Bausteins ein signiertes Berechtigungsobjekt mitführen muss. Fehlt es, lässt sich der Code gar nicht erst übersetzen. Ausstellen darf diese Objekte nur eine zentrale Policy-Instanz. Der Entwurf ist in Erprobung und noch nicht in Betrieb.
Was es für die Business-Architektur bedeutet
Need-to-Know wird damit eine Eigenschaft der Architektur und keine Aufgabe für das Code-Review. Für regulierte Häuser zählt genau das: Man kann zeigen, dass ein Datenzugriff ohne Freigabe technisch nicht vorkommt. Dass er heute nur selten vorkommt, reicht nicht.
Learnings
- Eine vergessene Zeile ist das typische Datenleck. Strukturelle Garantien sind besser als Checklisten.
- Wenn Bausteine einander aufrufen, vervielfacht sich das Risiko. Die Prüfung gehört an jeden Übergang.
- Berechtigungen brauchen eine Ablaufzeit und einen engen Geltungsbereich, sonst werden sie zum Generalschlüssel.
- Need-to-Know
- Berechtigungen
- KI-Governance
- Mandantentrennung