Datenflüsse je Betriebsmodell

Kasimir wird je Kanzlei eingerichtet. Drei Betriebsmodelle sind vorgesehen. Wir unterscheiden hier ausdrücklich zwischen dem, was heute läuft, und dem, was die Architektur vorbereitet.

2.1 Betriebsmodell A — Betrieb durch ChangeMy.AI (heutiger Stand)

So läuft Kasimir heute. Die Anwendung liegt auf einem Server bei Hetzner in Deutschland. Die Inferenz läuft über Scaleway Generative APIs in Paris. Beides liegt im EWR; im Produktpfad ist kein US-Anbieter beteiligt.

Verarbeitungsschritt	Ort	Was das System überträgt	Redigiert
Anwendung, Datenbank, Vektorindex, Volltextindex, Objektspeicher, Authentifizierung	Hetzner, Deutschland	— (verlässt den Server nicht)	entfällt
Sparse-Suchschlüssel und Cross-Encoder-Neubewertung	selbst gehostet, im Prozess auf CPU	— (kein externer Aufruf)	entfällt
PII-Erkennung (Namen, Orte)	selbst gehostet, im Prozess	— (kein externer Aufruf)	entfällt
Chat-Generierung	Scaleway, Paris (fr-par)	Frage und die acht abgerufenen Passagen	ja
Dense-Embedding der Abfrage	Scaleway, Paris	der rohe Fragetext	nein
Dense-Embedding bei der Indexierung	Scaleway, Paris	der Rohtext jedes indexierten Dokuments, abschnittsweise	nein

Die letzten beiden Zeilen sind der wunde Punkt und wir schreiben sie deshalb aus: Wenn Sie ein Dokument hochladen, wird dessen Text zur Vektorisierung an Scaleway übertragen, ohne durch die PII-Redaktion zu laufen. Die Redaktion sitzt heute nur vor dem Sprachmodell, nicht vor dem Embedding-Dienst. Wer Mandatsakten in Betriebsmodell A indexiert, muss diesen Umstand in seine Beurteilung nach § 43e BRAO beziehungsweise § 40 Abs 3 RL-BA einbeziehen.

Die architektonische Abhilfe ist ein selbst gehostetes Embedding-Modell. Sie ist vorbereitet und noch nicht ausgeliefert.

2.2 Betriebsmodell B — Private Cloud der Kanzlei

Dieselbe Architektur, betrieben auf Infrastruktur, die vertraglich der Kanzlei oder ihrem IT-Dienstleister zugeordnet ist. Die Kanzlei bestimmt Standort, Zugriff und Aufbewahrung selbst.

Wichtig und ehrlich: Solange die Inferenz über einen externen Endpunkt läuft, bleibt für Generierung und Embedding derselbe Fluss bestehen wie in Betriebsmodell A. Betriebsmodell B verlagert die Anwendung, nicht automatisch das Modell.

2.3 Betriebsmodell C — On-Premises

Das Ziel und der eigentliche Zweck der Architektur: Anwendung und Modelle laufen auf Hardware der Kanzlei, ohne ausgehenden Modellverkehr.

Was dafür bereits gilt. Jede Komponente des Stapels ist selbst hostbar und entsprechend lizenziert. Der gesamte Modellverkehr läuft durch ein einziges, prüfbares Modul. Der Anbieterwechsel ist eine Konfigurationsänderung. Die Sparse-Suche, die Neubewertung und die PII-Erkennung laufen bereits heute ohne externen Aufruf.

Was nicht gilt. Betriebsmodell C ist derzeit bei keiner Kanzlei in Betrieb. Die Serving-Schicht für lokale Modelle ist im Repository noch ein Platzhalter, und die dafür vorgesehene Hardware ist nicht beschafft. Wir nennen keine Durchsatzwerte für Hardware, auf der wir Kasimir nicht gemessen haben.

Bis dahin gilt: Kasimir ist auf Air-Gap-Betrieb hin gebaut, aber nicht air-gapped. Ohne Verbindung zum Inferenzdienst kann das System heute weder antworten noch ein Dokument indexieren.

CTA: Datenflussdiagramm für Ihr Betriebsmodell anfordern