In regulierten Umgebungen ist das Modell der einfache Teil

Die Server bekommen keine Internetverbindung, und daran wird sich nichts ändern. Das sagte der Sicherheitsverantwortliche einer nationalen Digitalisierungsbehörde im ersten Architekturtermin, und dieser Satz bestimmte das ganze weitere Projekt. Die Behörde wollte eine KI-gestützte Ticket-Triage für ihren Service Desk: zu 100 % im eigenen Haus, physisch vom Netz getrennt, ohne Abhängigkeit von einem Modellanbieter.

Genau so haben wir sie gebaut, und sie läuft im Produktivbetrieb. Die Lehre daraus reicht weit über abgeschottete Netze hinaus. In einem regulierten Umfeld sind Auswahl und Betrieb des Modells der einfache Teil. Schwierig ist alles, was darüber entscheidet, ob das Modell überhaupt laufen darf: wohin Daten fließen, was jeder Schritt sehen darf, wie Änderungen freigegeben werden und welche Nachweise es danach gibt.

Hosting ist eine Vorgabe für das Design

Viele Teams planen rund um ein gehostetes Modell und fragen erst ganz am Ende nach dem Hosting. In einem regulierten Umfeld fallen durch die Antwort auf die Frage, wo diese Daten verarbeitet werden dürfen, Optionen weg, bevor das Design überhaupt beginnt. Sie entscheidet, ob eine gehostete Modell-API zulässig ist, in welcher Region und unter welchem Vertrag, oder ob die Modelle auf der eigenen Hardware des Kunden laufen müssen.

Für Finanzunternehmen in der EU gilt der Digital Operational Resilience Act seit Januar 2025. Er behandelt die Abhängigkeit von externen IKT-Dienstleistern als Risiko, das gesteuert, dokumentiert und bei Bedarf beendet werden muss, und eine gehostete Modell-API ist genau diese Art von Abhängigkeit. Deshalb werden Hosting, die freigegebene Liste von Modellen und Anbietern und der Ausstiegsweg vor dem Design schriftlich geklärt, und sie kommen in den Vertrag. Die Architektur folgt daraus.

Eine oft unterschätzte Folge: Entwickeln Sie dort, wo das System später läuft. Wer mit einem gehosteten Modell entwickelt und dann ein lokales ausrollt, hat es mit zwei Modellen zu tun, die sich unterschiedlich verhalten, und zwar auf eine Weise, die Tests nicht vollständig erfassen. Das System der Behörde wurde auf derselben Art von Modell in derselben Art von Umgebung gebaut wie die Produktion.

Jeder Schritt sieht nur die Felder, die er braucht

Datenminimierung wird meist als Richtlinie formuliert. Wir behandeln sie als Eigenschaft jedes einzelnen Schritts. Ein Triage-Schritt, der entscheidet, welches Team ein Ticket bearbeiten soll, braucht den Tickettext und die Liste der Teams. Er braucht nicht die Ausweisnummer der anfragenden Person, ihre bisherigen Tickets oder die Anhänge. Deterministischer Code stellt eine Sicht nur mit diesen Feldern zusammen, bevor das Modell aufgerufen wird.

Das verringert, was nach außen gelangen könnte, und es macht den Datenfluss in einer einzigen Tabelle nachvollziehbar: Schritt, eingehende Felder, ausgehende Felder, Ort der Verarbeitung. Nach genau dieser Tabelle fragen Datenschutzbeauftragte meist zuerst, und sie direkt aus dem Design abzuleiten ist viel einfacher, als sie im Nachhinein aus Logs zu rekonstruieren.

Wir verlassen uns nicht darauf, personenbezogene Daten aus Freitext zu entfernen, bevor er weitergegeben wird. Namen, Adressen und Kennungen in unstrukturiertem Text zuverlässig zu schwärzen ist schwieriger, als es aussieht. Eine Schwärzung, die bei den meisten Tickets funktioniert, hat trotzdem einige personenbezogene Daten nach außen gegeben. Freitext wird deshalb dort verarbeitet, wo die Daten liegen dürfen.

Prompts, Schwellenwerte und Modelle sind Code

Änderungen an Produktivsystemen durchlaufen die Change-Kontrolle: Antrag, Test, Freigabe, Dokumentation. Prompts, Schwellenwerte und Modellversionen gehören zum Produktivsystem, sehen aber aus wie Konfiguration, und jeder mit Zugriff kann sie in einer Minute ändern.

In einem regulierten Umfeld sind sie Code. Eine Prompt-Änderung wird gegen den Abnahmedatensatz getestet und wie jedes Release freigegeben. Modellversionen sind fest vorgegeben und ändern sich nur über ein Release. Bei der Behörde hat die Umgebung das von selbst sichergestellt: Code, Bibliotheken und Modellgewichte kamen nur über den freigegebenen Übertragungsprozess ins Netz, sodass sich nichts unbemerkt ändern konnte. Anderswo stellen wir es sicher, indem der Konfigurationsspeicher Teil des Releases ist.

Leicht übersehen wird der Abnahmedatensatz selbst. Jede Änderung wird freigegeben, weil sie diesen Datensatz besteht. Wer den Datensatz bearbeiten kann, kann also unbemerkt die Hürde senken. Neue Fälle kommen deshalb über denselben Change-Prozess hinzu wie Code, und um einen Fall zu entfernen, braucht es die Freigabe des Prozessverantwortlichen und eine schriftliche Begründung.

Zu jedem Release gehört ein Nachweispaket

Wenn eine Aufsichtsbehörde, die interne Revision oder ein Risikoausschuss fragt, wie das System funktioniert, sollte die Antwort schon vorliegen. Zu jedem Release gehört ein Nachweispaket: die Datenflusstabelle, die eingesetzten Modelle mit Versionen und Ort der Verarbeitung, die Ergebnisse auf dem Abnahmedatensatz im Vergleich zum vorigen Release, der Freigabenachweis und die Liste der Änderungen. Die Release-Pipeline erzeugt das Paket automatisch. Niemand schreibt es eigens für die Prüfung.

Das Paket macht Änderungen auch für das Team des Kunden nach der Übergabe sicherer, weil es festhält, was am Tag des Releases als „funktioniert“ galt.

Protokollierung und Datenminimierung ziehen in entgegengesetzte Richtungen

Dieser Zielkonflikt ist real und wird selten offen angesprochen. Prüfbarkeit spricht dafür, alles zu protokollieren: jede Eingabe, jede Ausgabe, jeden Zwischenschritt. Minimierungs- und Aufbewahrungsregeln verlangen, so wenige personenbezogene Daten wie möglich so kurz wie möglich zu speichern. Ein System, das den vollständigen Tickettext dauerhaft protokolliert, ist sehr gut prüfbar und datenschutzrechtlich kaum zu verteidigen.

Wir lösen das, indem wir trennen, was nötig ist, um eine Entscheidung zu erklären, und was nötig ist, um sie zu wiederholen. Die Vorgangsakte enthält die Entscheidung, Verweise auf die Belege, die Versionen von Modell und Regelwerk und einen Fingerabdruck der Eingabe. Die vollständige Eingabe bleibt im Quellsystem und unterliegt dessen Aufbewahrungsregeln, die Vorgangsakte verweist nur darauf. Wird der Quelldatensatz planmäßig gelöscht, lässt sich die Entscheidung weiterhin erklären, aber nicht mehr mit dem Originaltext wiederholen. Diesem Kompromiss stimmt der Kunde je Workflow ausdrücklich zu, und er ist im Design festgehalten.

Die Kontrollen überdauern das Modell

Das abgeschottete Netz hat das System der Behörde am Ende sogar leichter beherrschbar gemacht: fest vorgegebene Versionen, keine externen Aufrufe, kein Abonnement mit wechselnden Preisen, nichts, was das Gebäude verlässt. Das Modell darin ließe sich morgen austauschen. Hosting-Entscheidung, Datenfluss, Change-Kontrolle und Nachweise würden bleiben, denn in einem regulierten Umfeld sind sie das eigentliche System.