Regulierte KI ist eine Betriebsaufgabe

Die Server würden nie eine Verbindung zum Internet haben. Das sagte der Sicherheitschef einer nationalen Digitalisierungsbehörde in der ersten Architekturbesprechung, und es bestimmte den Rest des Projekts. Die Behörde wollte, dass KI die Tickets sortiert, die bei ihrem Servicedesk eingehen: 100% in den eigenen Räumen, abgeschottet von externen Netzen, ohne Abhängigkeit von einem Modellanbieter.

Wir haben es so gebaut, und es ist täglich im Einsatz. Die Lehre reicht weit über Offline-Systeme hinaus. In einem regulierten Betrieb ist es der einfache Teil, das KI-Modell auszuwählen und zu betreiben. Schwer ist alles, was entscheidet, ob das Modell überhaupt laufen darf: wohin die Daten gehen, was jeder Schritt sehen darf, wie Änderungen freigegeben werden und welche Nachweise es danach gibt.

Wo es läuft, ist eine Vorgabe für das Design

Teams planen oft um das Modell eines Anbieters herum und fragen erst am Ende nach dem Hosting. In einem regulierten Betrieb streicht „Wo dürfen diese Daten verarbeitet werden?" Optionen, bevor das Design beginnt. Es entscheidet, ob das Modell eines Anbieters zulässig ist, in welcher Region, unter welchem Vertrag, oder ob Modelle auf der eigenen Hardware des Kunden laufen müssen.

Für Finanzunternehmen in der EU gilt seit Januar 2025 der Digital Operational Resilience Act (DORA). Er behandelt die Abhängigkeit von externen Technologieanbietern als Risiko, das gesteuert, dokumentiert und bei Bedarf beendet werden muss, und das Modell eines Anbieters ist genau so eine Abhängigkeit. Hosting, zugelassene Modelle und Anbieter und der Ausstiegsweg werden deshalb vor dem Design schriftlich vereinbart und gehen in den Vertrag. Die Architektur folgt daraus.

Eine Folge davon: Bauen Sie dort, wo Sie betreiben. Ein System, das auf dem Modell eines Anbieters gebaut und auf einem lokalen betrieben wird, verhält sich anders, auf eine Weise, die Tests nicht ganz erfassen. Das System der Behörde wurde in derselben Art von Umgebung gebaut wie das laufende.

Jeder Schritt sieht nur die Daten, die er braucht

Möglichst wenig personenbezogene Daten zu verarbeiten, steht meist als Richtlinie auf Papier. Wir machen es zu einer Eigenschaft jedes Schritts. Ein Schritt, der entscheidet, welches Team ein Ticket bearbeitet, braucht den Tickettext und die Liste der Teams. Er braucht weder die Identitätsnummer des Antragstellers noch seine Vorgeschichte noch die Anhänge. Einfacher Code stellt eine Ansicht mit genau diesen Feldern zusammen, bevor das Modell etwas sieht.

Das verringert, was abfließen könnte, und es bringt den Datenfluss in eine Tabelle: Schritt, Daten hinein, Daten hinaus, wo er läuft. Ein Datenschutzbeauftragter fragt meist zuerst danach, und sie aus dem Design zu erzeugen ist weit leichter, als sie aus Protokollen zu rekonstruieren.

Wir verlassen uns nicht darauf, personenbezogene Daten aus Freitext herauszufiltern, bevor er anderswohin geht. Namen, Adressen und Kennnummern verlässlich aus Freitext zu entfernen ist schwerer, als es aussieht, und ein Filter, der bei den meisten Tickets funktioniert, hat trotzdem einige nach draußen geschickt. Freitext wird dort verarbeitet, wo die Daten sein dürfen.

Anweisungen, Schwellenwerte und Modelle sind Software

Änderungen an laufenden Systemen gehen durch eine Änderungskontrolle: Antrag, Test, Freigabe, Protokoll. Die schriftlichen Anweisungen an das Modell (seine Prompts), die Schwellenwerte und die Modellversion gehören zum laufenden System, sehen aber aus wie Einstellungen, die jeder mit Zugang in einer Minute ändern kann.

In einem regulierten Umfeld werden sie wie Software behandelt. Eine Änderung der Anweisungen wird gegen einen festen Satz echter Fälle mit bekannten richtigen Antworten getestet und wie jedes Release freigegeben. Die Modellversion ist festgelegt und ändert sich nur über ein Release. Bei der Behörde erzwang die Umgebung das von selbst: Code und Modelle kamen nur über den freigegebenen Übertragungsprozess hinein, also konnte sich nichts unbemerkt ändern. Anderswo machen wir die Einstellungen zum Teil des Release.

Jede Änderung als Release zu behandeln, hat eigene Nachteile. Braucht die Korrektur eines Wortes dasselbe Gremium wie ein neues Modell, hört das Team auf, Kleinigkeiten zu korrigieren, und das System entfernt sich von der Arbeit. Vor dem Go-live vereinbaren wir deshalb Änderungsklassen mit dem Risikoteam des Kunden, schriftlich, damit niemand am Tag einer nötigen Korrektur darüber streitet.

Leicht übersehen wird der Testsatz selbst. Jede Änderung wird freigegeben, weil sie den Satz besteht, also kann still die Latte senken, wer den Satz bearbeiten darf. Fälle kommen über denselben Änderungsprozess hinzu, und einen zu entfernen braucht die Zustimmung des Prozessverantwortlichen und eine schriftliche Begründung.

Jedes Release trägt eine Nachweismappe

Fragt eine Aufsichtsbehörde, ein Prüfer oder ein Risikoausschuss, wie das System funktioniert, sollte die Antwort schon existieren. Jedes Release trägt eine Nachweismappe: die Datenflusstabelle, die eingesetzten Modelle und Versionen und wo sie laufen, die Testergebnisse im Vergleich zum vorigen Release, den Freigabenachweis und die Liste der Änderungen. Der Release-Prozess erzeugt sie; niemand schreibt sie für die Prüfung. Sie macht Änderungen auch für das eigene Team des Kunden nach der Übergabe sicher, weil sie festhält, wie Funktionieren am Tag des Release aussah.

Protokollierung und Datensparsamkeit ziehen in entgegengesetzte Richtungen

Prüfbarkeit drängt dazu, alles zu protokollieren. Datenschutz drängt dazu, so wenig personenbezogene Daten wie möglich so kurz wie möglich aufzubewahren. Ein System, das vollständige Tickettexte für immer protokolliert, ist sehr gut prüfbar und sehr schwer zu verteidigen.

Wir trennen, was eine Entscheidung braucht, um erklärt zu werden, und was sie braucht, um wiederholt zu werden. Der Fallnachweis enthält die Entscheidung, Verweise auf die Belege, die Modell- und Regelversionen und einen Fingerabdruck der Eingabe, der belegt, was sie war, ohne sie zu speichern. Die vollständige Eingabe bleibt im Quellsystem unter dessen bestehenden Aufbewahrungsregeln. Wird sie planmäßig gelöscht, lässt sich die Entscheidung weiter erklären, aber nicht mehr mit dem Originaltext neu durchlaufen. Der Kunde stimmt diesem Kompromiss pro Ablauf im Design zu.

Es gibt einen zweiten Grund, Erklärung statt Wiederholung zuzusagen. Selbst mit demselben Modell, denselben Anweisungen und Einstellungen gibt ein Sprachmodell nicht immer zweimal dieselbe Antwort. Horace He und Kollegen bei Thinking Machines Lab haben die Hauptursache auf die Serverlast zurückgeführt, die verändert, wie Anfragen gebündelt werden, und damit die Rechnung hinter jeder Antwort („Defeating Nondeterminism in LLM Inference", September 2025). Ein geändertes Wort kann eine Einordnung ändern. Wer einer Aufsichtsbehörde zusagt, jede Entscheidung auf Abruf reproduzieren zu können, verspricht etwas, das die Technik nicht verlässlich leistet. Wir speichern Modellversion, Einstellungen, den Fingerabdruck der Eingabe und die Ausgabe und sagen zu, dass sich jede Entscheidung aus diesem Nachweis erklären lässt. Dieses Versprechen können wir halten.

Der Rückfallweg ist eine Kontrolle

Die Frage, mit der die meisten Designprüfungen im regulierten Umfeld enden, lautet: Was passiert, wenn Sie das heute abschalten müssen? Eine Aufsichtsbehörde fragt nach einem Vorfall anderswo, ein Anbieter zieht ein Modell zurück, oder eine neue Regel gilt ab einem Stichtag. DORA verlangt dasselbe von jedem Technologiedienst hinter einer kritischen Funktion, als Ausstiegsstrategie.

Deshalb hat jeder Schritt, der ein Modell nutzt, einen Weg ohne Modell. Beim Sortieren von Tickets geht ein Ticket, das das Modell nicht einordnen kann, oder jedes Ticket, solange das Modell aus ist, in eine allgemeine Warteschlange, die Menschen wie früher abarbeiten, mit allen Feldern vorausgefüllt, die einfache Regeln füllen können. Jedes Release misst diesen Rückfallweg ebenso wie das Modell, also ist der Vorsprung des Modells dokumentiert, und das beantwortet die Frage, die Risikoausschüsse früher oder später stellen: Warum hier überhaupt ein Modell? Das Abschalten ist eine getestete Routine mit einem benannten Verantwortlichen, kein Notfall.

Die Kontrollen überdauern das Modell

Die Trennung vom Internet machte das System der Behörde leichter zu besitzen: feste Versionen, keine Aufrufe nach außen, kein Abonnement, dessen Preis sich ändern kann, nichts verlässt das Haus. Das Modell darin ließe sich morgen ersetzen. Die Entscheidung über den Betriebsort, der Datenfluss, die Änderungskontrolle und die Nachweise blieben, denn in einem regulierten Betrieb sind sie das System.