Welche KI-Modelle Ihre Finanzzahlen sehen – und zu welchen Bedingungen

„Welches Modell sieht unsere Abschlüsse, und was verhindert, dass es damit trainiert wird?” ist eine Frage, die früher oder später jeder ernsthafte Interessent stellt, und die ehrliche Antwort ist interessanter als „wir setzen auf einen vertrauenswürdigen Anbieter”. Rexfin nutzt bewusst mehrere Modelle für mehrere unterschiedliche Aufgaben, und der Grund, warum das sicher statt riskant ist, läuft auf zwei Designentscheidungen hinaus: Keinem einzelnen Modell wird je zugetraut, bei einer Zahl von sich aus richtigzuliegen, und kein Modell bekommt irgendetwas zu sehen, bevor seine Datenbedingungen geprüft wurden.

Die Zahl hängt nicht davon ab, welches Modell sie geschrieben hat

Rexfins Vertrauenskette beruht auf der Übereinstimmung unabhängiger Extraktionsdurchläufe, dem Abgleich mit der gedruckten Summe und einer deterministischen Identitätsprüfung – nie auf der Konfidenz irgendeines einzelnen Modells. Genau darum geht es im Artikel warum Berechnung deterministisch ist, nicht generativ, und deshalb kann sich Rexfin erlauben, unsentimental damit umzugehen, welches Modell welche Aufgabe übernimmt.

Hochvolumige Aufgaben mit geringem Risiko – Zahlen von einer Seite abgreifen, eine Position klassifizieren, eine Retrieval-Abfrage umformulieren – laufen auf günstigeren Modellen, weil die Extraktions-Abgleichsprüfung eine falsche Vermutung erkennt, egal welches Modell sie geliefert hat. Die beiden Rollen, die für das, was ein Kunde tatsächlich liest, wirklich zählen – der Verifier, der über einen Identitätsfehler urteilt, und der Writer, der die finale zitierte Antwort formuliert – sind stärkeren Modellen vorbehalten. Ist die starke Modellstufe nicht verfügbar, schlägt Rexfin geschlossen fehl und liefert einen klaren Fehler, statt eine vertrauenskritische Antwort stillschweigend auf ein günstigeres Modell herunterzustufen. Eine falsche Antwort von einem günstigen Modell, die wie eine wohlüberlegte daherkommt, ist schlimmer als gar keine Antwort.

Kein Anbieter kommt ohne geprüfte Bedingungen hinein

Jeder Anbieter durchläuft ein Zulassungs-Gate, bevor er überhaupt routingfähig ist. Die Datenbedingungen eines Anbieters werden als strukturierter Fakt erfasst: Speichert er Prompts, trainiert er damit, in welcher Region verarbeitet er, welche DPA-Referenz gilt. Zugelassen wird ausschließlich ein Anbieter, der als Zero-Retention und ohne Training erfasst ist; alles andere wird markiert oder abgelehnt und lässt sich schlicht nicht auswählen, egal wie gut das Modell sonst ist. Laufen die Bedingungen eines Anbieters aus oder ändern sich, wird er automatisch herabgestuft und erhält keinen Traffic mehr – ohne Code-Änderung, ohne dass jemand daran denken müsste, einen Schalter umzulegen.

Das ist bewusst keine Richtlinie nach dem Muster „wir nutzen keine Anbieter aus Land X”. Ein Anbieter wird ausschließlich anhand der Bedingungen zugelassen oder abgelehnt, die er belegen kann – das hält die Governance-Erzählung ehrlich statt bloß demonstrativ, und es bedeutet, dass kein einzelner Anbieter je zu etwas wird, um das Rexfin nicht herumrouten könnte, sobald sich dessen Bedingungen ändern.

Nichts ruht außerhalb der vorgesehenen Region

Daten im Ruhezustand – die extrahierten Kennzahlen, die Audit-Einträge, die zwischengespeicherten Antworten – bleiben an eine einzige festgelegte Region gebunden. Ein externer Modellanbieter sieht einen Prompt allenfalls während der Übertragung, und auch das nur unter einer Zero-Retention-Bedingung, und die Offenlegung, welcher Anbieter was sieht, wird aus der aktiven Routing-Konfiguration erzeugt statt als handgepflegtes Dokument, das still veraltet. Für Kunden mit strengeren Anforderungen lassen sich vertrauenskritische Rollen stattdessen auf ein selbst gehostetes Modell in der Region legen – einer der Wege, die unter Optionen zur Datenresidenz im GCC-Raum beschrieben sind.

Der Datenfluss mit dem größten Volumen im System – die Berechnung von Embeddings fürs Retrieval – läuft lokal statt über eine externe API, was bedeutet, dass der mit Abstand größte Datenstrom die Region nie verlässt und offline nie mit einem Anbieter in Berührung kommt.

Was die Grenze tatsächlich überquert

Bevor ein Prompt an einen Anbieter außerhalb der Region geht, durchläuft er ein zweites Gate: einen Vorgang, der sensible Abschnitte identifiziert – Namen, Kontonummern, Identifikatoren – und sie durch stabile Platzhalter maskiert, bevor die Anfrage überhaupt versendet wird. Das Modell arbeitet mit der maskierten Version; die Platzhalter werden lokal wieder gegen die echten Werte getauscht, nachdem die Antwort zurückkommt, und diese Zuordnung verlässt den Prozess nie und wird nie protokolliert. Kann der Maskierungsschritt aus irgendeinem Grund nicht ausgeführt werden, wird der Aufruf blockiert, statt unmaskiert versendet zu werden – der Fehlermodus lautet immer „Versand verweigern”, nie „trotzdem senden und hoffen”.

Was hier nicht versprochen wird

Nichts davon ist eine Zertifizierungsaussage – Rexfin behauptet an dieser Stelle keinen SOC- oder ISO-Status. Was behauptet wird, ist enger gefasst und überprüfbar: Routing-Entscheidungen sind Konfiguration, die Zulassung von Anbietern wird im Code durchgesetzt statt in einer DPA nur versprochen, und die Offenlegung, wer was sieht, wird aus dem tatsächlich verdrahteten System erzeugt, nicht separat davon verfasst. Genau diese Kombination macht aus „wir prüfen unsere KI-Anbieter” mehr als einen Satz in einem Sicherheitsfragebogen – nämlich etwas, das ein Käufer tatsächlich nachprüfen kann. Wie das mit der umfassenderen Sicherheitsarchitektur der Plattform zusammenhängt und wie Rexfin sich gegen manipulative Eingaben in Prompts wehrt, steht unter Schutz vor Prompt Injection. Für die vollständige Übersicht, wie die Plattform aufgebaut ist, besuchen Sie den Inside-the-Rexfin-Platform-Hub.