Was wo verarbeitet wird — und was nicht.

Diese Seite beschreibt, wogegen Kasimir gebaut ist, wohin Ihre Daten tatsächlich fließen und wo die Grenzen des Systems liegen. Sie enthält bewusst auch die Punkte, die noch offen sind. Eine Kanzlei, die ein solches System prüft, braucht keine Werbebroschüre, sondern eine Grundlage für die eigene Risikoentscheidung.

Stand aller Angaben: 25.07.2026.

1. Bedrohungsmodell

Kasimir ist gegen drei konkrete Szenarien konstruiert. Für jedes benennen wir die Gegenmaßnahme und das verbleibende Risiko.

1.1 Datenabfluss an Modellanbieter

Das Szenario. Mandantendaten gelangen in den Trainingsdatensatz eines Modellanbieters oder verbleiben in dessen Protokollen. Die Kanzlei erfährt davon nichts und kann es nicht überprüfen.

Dieses Risiko ist strukturell und betrifft jedes Cloud-Produkt in diesem Markt. Der compliance-stärkste österreichische Cloud-Wettbewerber räumt in seiner eigenen Anlage zur ÖRAK-Checkliste ein, dass hochgeladene Dateiinhalte technisch bedingt unverschlüsselt an das Sprachmodell übermittelt werden müssen. Verschlüsselung im Ruhezustand hilft in dem Moment nicht mehr, in dem das Modell die Datei lesen muss. [Quelle: https://aissociate.at/oerak_ki_checkliste_2026_01.pdf, Stand: 25.07.2026]

Was Kasimir dagegen tut. Der gesamte Modellverkehr verlässt das System durch genau ein Modul. Direkte Aufrufe von Anbieter-SDKs sind durch eine Lint-Regel gesperrt, die durch einen Test erzwungen wird — ein Entwickler kann diesen Pfad nicht versehentlich umgehen. An dieser einen Stelle greift die PII-Redaktion (Abschnitt 3). Ein Wechsel des Generierungsanbieters ist deshalb eine Konfigurationsänderung an dieser einen Stelle. Die Verlagerung auf eigene Hardware setzt zusätzlich eine Serving-Schicht voraus, die wir heute nicht ausliefern; beim Einbettungsmodell kommt eine vollständige Neuindexierung des Bestands hinzu.

Was offen bleibt. Die Redaktion deckt den Modellpfad ab, nicht den Embedding-Pfad. Der Rohtext jedes indexierten Dokuments wird derzeit unredigiert an den Embedding-Dienst übertragen. Details in Abschnitt 2 und 3. Das ist die größte Lücke zwischen Architekturanspruch und heutigem Betrieb, und wir stellen sie deshalb an den Anfang.

1.2 Zugriff durch Dritte

Das Szenario. Nicht die Kanzlei wird durchsucht, sondern ein Dienstleister. Oder ein ausländisches Gericht ordnet an, was der Anbieter eigentlich gelöscht hätte.

Das ist kein theoretischer Fall. In NYT v. OpenAI ordnete ein US-Magistrate-Judge am 13.05.2025 an, sämtliche Ausgabeprotokolle aufzubewahren und zu separieren, die andernfalls gelöscht worden wären — ausdrücklich einschließlich von Nutzern gelöschter und temporärer Chats. Betroffen waren auch API-Kunden ohne Zero-Data-Retention-Vereinbarung. Der Anbieter kam der Anordnung ab Mitte Mai nach und informierte die Nutzer erst am 05.06.2025. Die Anordnung wurde im Oktober 2025 aufgehoben; bereits aufbewahrte Daten blieben aufbewahrt. Weder ein Vertrag noch eine EU-Region noch eine Löscheinstellung hat diese Kunden geschützt, weil der Anbieter der Gerichtsbarkeit unterlag. [Quelle: https://venturebeat.com/ai/sam-altman-calls-for-ai-privilege-as-openai-clarifies-court-order-to-retain-temporary-and-deleted-chatgpt-sessions, Stand: 25.07.2026]

Für österreichische Kanzleien kommt § 40 Abs 3 Z 3 RL-BA 2015 hinzu: Der externe Dienstleister muss vertraglich und nachweislich verpflichtet sein, die Anwältin oder den Anwalt im Fall einer Hausdurchsuchung unverzüglich zu informieren. [Quelle: https://www.oerak.at/fileadmin/user_upload/Gesetzestexte/RL-BA/RL-BA_2015_29092023.pdf, Stand: 25.07.2026]

Was Kasimir dagegen tut. Die Antwort hängt am Betriebsmodell und wir geben sie deshalb dort (Abschnitt 2). Im heutigen, von uns betriebenen Modell gibt es Dritte — Hetzner und Scaleway — und es gilt die volle Begründungslast nach § 43e BRAO beziehungsweise § 40 Abs 3 RL-BA. Im On-Premises-Modell gibt es keinen Dritten, der durchsucht werden könnte.

Cloud ist erlaubt, aber begründungspflichtig. On-Premises ist begründungsfrei. Wer Ihnen sagt, Cloud sei für Kanzleien rechtswidrig, irrt.

1.3 Unbelegte Aussagen im Schriftsatz

Das Szenario. Ein Modell erfindet eine Entscheidung, eine Fundstelle oder eine Randnummer. Der Schriftsatz geht hinaus. Die Sanktion trifft die Berufsträgerin, nicht das Werkzeug.

Auch das ist entschieden: OGH 07.10.2025, 14 Os 95/25i (Zurückweisung einer mit Fehlzitaten durchsetzten Nichtigkeitsbeschwerde); KG Berlin 20.11.2025, 17 WF 144/25; AG Köln, 312 F 130/25 (erfundene Urteile, fiktive Monografien und Kommentar-Randnummern). [Quelle: https://www.anwaltsblatt.at/artikel/zurueckweisung-einer-nichtigkeitsbeschwerde-wegen-ki-generierter-fehlzitate, Stand: 25.07.2026] [Quelle: https://www.datenschutzticker.de/2025/10/ag-koeln-anwalt-zitiert-ki-halluzinationen-vor-gericht/, Stand: 25.07.2026]

Was Kasimir dagegen tut. Das Ziel ist Überprüfbarkeit, nicht Fehlerfreiheit. Vier Mechanismen greifen ineinander:

1. Verweigerung vor der Generierung. Liefert die Suche nichts oder liegt die beste Bewertung unter dem Schwellenwert, gibt das System eine feste Absage aus und ruft das Modell gar nicht erst auf.
2. Bindung an die gefundenen Stellen. Die acht abgerufenen Passagen werden als [S1]…[S8] übergeben; der Systemprompt untersagt das Erfinden von Paragrafen, Aktenzahlen, Daten, Parteinamen und Beträgen und verlangt einen Beleganker an jeder Tatsachen- oder Rechtsaussage.
3. Zitatprüfung nach der Generierung. Jeder Anker, der auf keine reale Quelle zeigt, wird zu [?]; Aussagen, deren Anker sämtlich unbekannt sind, werden entfernt. Enthält die Antwort am Ende keinen einzigen gültigen Anker, wird sie vollständig verworfen und durch die Absage ersetzt.
4. Zweiter Modelldurchlauf. Ein Prüflauf bewertet jede Aussage gegen die zitierte Passage und kann Aussagen streichen oder die Antwort insgesamt zurückweisen.

Jede angezeigte Quelle ist ein realer indexierter Abschnitt eines realen Dokuments, mit Dokument, Seite und Abschnittsbezeichnung und aufklappbarem Kontext. Die Erkennung von Zitaten (§/Abs/Z/lit, OGH-, VwGH-, VfGH- und EuGH-Aktenzahlen, BGBl, ECLI, RIS-ELI-Adressen) erfolgt regelbasiert, niemals durch ein Modell.

Das verwandelt die von der BRAK geforderte eigenverantwortliche Endkontrolle aus einer unbegrenzten Nachrecherche in eine Prüfung entlang belegter Fundstellen. Es ersetzt sie nicht.

Was offen bleibt. Der Prüflauf ist ein Modell, das ein Modell bewertet. Er gleicht Antworttext gegen abgerufenen Quelltext ab — es gibt keine Abfrage einer Rechtsdatenbank, keine Prüfung des Inkrafttretens und keine Kenntnis von Aufhebungen. Im laufenden Chat werden die Tokens zuerst angezeigt und das Prüfergebnis danach als Hinweis nachgereicht. Die Grenzen im Detail stehen in Abschnitt 8.

2. 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

3. PII-Behandlung vor Modellaufrufen

Vor jedem Aufruf des Sprachmodells werden personenbezogene Angaben durch undurchsichtige Platzhalter ersetzt und nach der Antwort wieder eingesetzt. Die Funktion ist standardmäßig aktiv.

3.1 Wie es arbeitet

Ebene 1 — regelbasiert, deterministisch. Erkannt werden österreichische Sozialversicherungsnummern (mit Plausibilitätsprüfung des Geburtsdatumsteils), IBAN, E-Mail-Adressen und österreichische Telefonnummern mit ausdrücklicher Vorwahl +43 oder 0043. Jeder Treffer wird zu einem Platzhalter der Form <<TYP_NNN>>. Derselbe Wert erhält innerhalb einer Anfrage denselben Platzhalter, damit der Bezug im Text erhalten bleibt.

Ebene 2 — Eigennamenerkennung. Ein deutschsprachiges spaCy-Modell markiert Personen (PER) als <<NAME_nnn>> und Orte (LOC) als <<ADDR_nnn>>. Organisationen (ORG) werden bewusst nicht ersetzt: Gerichts- und Kanzleibezeichnungen sind öffentlich und ihre Entfernung würde die juristische Verwertbarkeit der Antwort zerstören. Fehlt das Modell, fällt das System auf Ebene 1 zurück und protokolliert eine Warnung.

Rückübersetzung. Die Zuordnungstabelle existiert nur für die Dauer der einzelnen Anfrage. Vor der Anzeige werden die Originalwerte wieder eingesetzt. Im laufenden Stream werden angefangene Platzhalter über Paketgrenzen hinweg zurückgehalten, damit nie ein halb ersetzter Wert sichtbar wird.

Ergänzend. In der Produktionskonfiguration werden Dokument- und Antwortauszüge in den Protokollen durch einen SHA-256-Wert samt Länge ersetzt, statt im Klartext zu erscheinen.

3.2 Die Grenzen, ausdrücklich

1. Die Redaktion deckt nur den Modellpfad ab. Die Embedding-Aufrufe sind nicht redigiert — weder beim Abfragen noch beim Indexieren. Siehe Abschnitt 2.1. Das ist die wichtigste Einschränkung auf dieser Seite.
2. Das eingesetzte Sprachmodell zur Eigennamenerkennung ist die kleine Variante. Die Trefferquote auf deutscher Rechtsprosa ist bestmöglich, nicht vollständig. Ein nicht erkannter Name geht im Klartext an das Modell.
3. Nur Personen und Orte werden ersetzt. Nicht ersetzt werden: Aktenzahlen, Firmenbuchnummern, UID-Nummern, Geburtsdaten, Kontobezüge und Vertragsbeträge. Diese Angaben sind für die juristische Antwort meist erforderlich; ihre Ersetzung würde das Ergebnis unbrauchbar machen. Sie sollten wissen, dass sie übertragen werden.
4. Redaktion ist eine Minderung, keine Garantie. Sie verringert die Menge identifizierender Daten im Prompt. Sie macht den Prompt nicht anonym im Sinne der DSGVO.

Wer diese vier Punkte nicht akzeptieren möchte, für den ist Betriebsmodell C die richtige Antwort — nicht eine stärkere Redaktion.

4. Zugriffskontrolle

4.1 Mandatsbezogene Trennung

Der Zugriffsfilter wird in die Suchmaschinen hineingegeben, nicht nachträglich auf das Ergebnis angewendet. Die Kennung des Mandats wird als Filter an die dichte Suche, die spärliche Suche und die Volltextsuche übergeben. Passagen aus Mandaten außerhalb des angefragten Bereichs werden daher gar nicht erst abgerufen, nicht bloß ausgeblendet.

Das ist ein wesentlicher Unterschied. Ein Nachfilter kann durch einen Fehler in der Anzeigeschicht umgangen werden. Ein Vorfilter nicht.

4.2 Rollen

Die Anwendung kennt Nutzerstufen. Die Verwaltungsbereiche — Gesetzesbibliothek, Modell- und Kostenverwaltung, Nutzerverwaltung — sind der Administratorstufe vorbehalten. Der Zugriff auf ein Mandat ergibt sich aus Eigentümerschaft oder ausdrücklicher Freigabe.

4.3 Wo die Entscheidung tatsächlich fällt — und wo nicht

Hier ist Genauigkeit wichtiger als ein gutes Schlagwort.

Die Zugriffsentscheidung fällt heute auf Anwendungsebene: Die Sitzung wird geprüft, die Berechtigung am Mandat wird geprüft, und das Ergebnis wird als Mandatsfilter an die Suchschicht weitergereicht. Der Abfragedienst selbst ist nur im internen Netzverbund erreichbar und nicht öffentlich exponiert.

Auf Datenbankebene sind Row-Level-Security-Regeln angelegt und aktiviert. Sie greifen jedoch nur, wenn pro Anfrage eine Sitzungsvariable mit der Nutzerkennung gesetzt wird — und das geschieht derzeit an keiner Stelle. Die Datenbankregeln sind daher heute nicht die durchsetzende Schicht. Wir führen sie hier auf, weil sie im Schema sichtbar sind und ein prüfender IT-Dienstleister sie finden wird. Sie als wirksame Absicherung zu verkaufen, wäre unrichtig.

Ebenfalls offen: Single Sign-on über OIDC ist nicht implementiert. Die Anmeldung erfolgt über eine selbst gehostete Authentifizierung.

5. Audit und Nachvollziehbarkeit

5.1 Was protokolliert wird

Ereignisse werden in eine eigene Audit-Tabelle geschrieben. Jeder Eintrag enthält:

• Zeitstempel
• Nutzerkennung
• Aktion (etwa Dokument-Upload, Abfrage, Modellwechsel)
• betroffener Objekttyp und dessen Kennung
• Mandatsbezug
• strukturierte Detailangaben
• Trace-Kennung zur Verknüpfung mit den Betriebsprotokollen

Erfasst sind heute insbesondere Dokumenten-Uploads und deren Verarbeitungsstatus, Abfrageereignisse, der Wechsel des aktiven Chat- oder Embedding-Modells sowie Lebenszyklusereignisse der Infrastruktur.

5.2 Anfügend, nicht änderbar

Ein Datenbank-Trigger bricht jeden UPDATE- und DELETE-Versuch auf der Audit-Tabelle mit einem Fehler ab. Die Anwendung kann die Historie also auch dann nicht verändern, wenn sie es versuchte.

5.3 Die Grenzen, ausdrücklich

• Der Trigger ist keine Manipulationssicherheit. Er schützt gegen die Anwendung und gegen versehentliches SQL. Er schützt nicht gegen einen Datenbank-Superuser oder den Eigentümer des Schemas. Ein Entzug der Schreibrechte samt gesondertem Archivierungskonto ist vorgesehen und noch nicht umgesetzt.
• Audit-Schreibvorgänge sind bewusst nicht blockierend. Scheitert das Schreiben, wird die Anfrage trotzdem beantwortet und der Fehler protokolliert; das System zählt aufeinanderfolgende und gesamte Fehlversuche und stellt diesen Zähler zur Überwachung bereit. Der Vorteil ist, dass ein Datenbankproblem den Kanzleibetrieb nicht anhält. Der Preis ist, dass der Audit-Pfad theoretisch Lücken haben kann. Diesen Zähler sollte Ihre Überwachung auswerten.
• Nicht jede Aktion erzeugt heute einen Eintrag. Der Umfang wächst; wir behaupten keine lückenlose Protokollierung.

6. Verschlüsselung

6.1 Im Transport

Der Zugang erfolgt ausschließlich über HTTPS. Die TLS-Terminierung übernimmt der vorgelagerte Reverse Proxy; Zertifikate werden über ACME automatisch bezogen und erneuert, alternativ über eine interne PKI der Kanzlei. Die Referenzkonfiguration für den Produktionsbetrieb setzt HSTS mit einem Jahr Gültigkeit sowie X-Content-Type-Options, X-Frame-Options und eine restriktive Referrer-Policy. Die Verwaltungsendpunkte sind zusätzlich am Netzrand durch eine zweite Authentifizierung abzusichern, getrennt vom Anwendungstoken.

Ausgehende Aufrufe an den Inferenzdienst laufen über TLS.

Der Verkehr zwischen den Diensten innerhalb einer Installation läuft über ein privates, nicht öffentlich erreichbares Netz und ist zwischen den Containern nicht zusätzlich TLS-verschlüsselt. Für eine Installation auf einem Host ist das üblich; für verteilte Aufbauten ist es gesondert zu regeln.

6.2 Im Ruhezustand

Hier ist Klarheit wichtiger als ein Werbesatz: Die Anwendung führt keine eigene Verschlüsselung der abgelegten Dokumente durch. Der Schutz im Ruhezustand ergibt sich aus der Verschlüsselung des Datenträgers auf dem Betriebssystem des Hosts.

Das ist deshalb kein Widerspruch zum Sicherheitsanspruch, weil eine anwendungsseitige Verschlüsselung in dem Moment endet, in dem das System den Text lesen muss, um ihn zu indexieren oder zu beantworten — genau das ist die strukturelle Grenze, die der Wettbewerb in Abschnitt 1.1 einräumt. Sie ist aber Teil der Installationsvereinbarung und nicht eine Eigenschaft, die die Software von selbst mitbringt.

Wir nennen deshalb keine Verschlüsselungsstärke als Produktmerkmal. Was Ihre Installation im Ruhezustand schützt, wird bei der Einrichtung festgelegt und schriftlich dokumentiert.

7. Betriebssicherheit

7.1 Aktualisierungen

Kasimir wird als Container-Verbund ausgeliefert. Eine Aktualisierung ist ein Austausch der Abbilder mit anschließender Datenbankmigration; ein Rückfall auf den vorherigen Stand ist dadurch möglich. Der Modellwechsel ist davon getrennt und über die Verwaltungsoberfläche protokolliert steuerbar.

Ein Wartungsfenster, eine Patch-Kadenz und die Zuständigkeit für das Betriebssystem des Hosts sind nicht im Produkt festgelegt, sondern Gegenstand des Wartungsvertrags. Wir geben hier keine Kadenz an, die wir nicht vertraglich zugesagt haben.

7.2 Sicherung und Wiederherstellung

Ehrlich und ohne Beschönigung: Das Produkt enthält heute keinen automatisierten Sicherungslauf und keine erprobte Wiederherstellungsprozedur. Vorgesehen ist ein eigener Ablagebereich für Sicherungen mit Aufbewahrungssperre; die Sicherungsroutine selbst wird je Installation eingerichtet.

Was das für Sie bedeutet: Sicherung, Aufbewahrungsdauer, Auslagerungsort und — entscheidend — der erprobte Wiederherstellungstest gehören in die Leistungsbeschreibung Ihrer Installation und sind vor der Aufnahme des Echtbetriebs zu vereinbaren. Eine Sicherung, die nie zurückgespielt wurde, ist keine Sicherung. Fragen Sie uns danach; wir werden Ihnen nicht antworten, das sei bereits enthalten.

7.3 Zur Umkehrfrage, die Ihr IT-Dienstleister stellen wird

Der Einwand lautet: Ein Server in der Kanzlei sei unsicherer als ein zertifiziertes Rechenzentrum. Der Vergleich trifft nicht den richtigen Gegenstand. Der Maßstab ist nicht Rechenzentrum gegen Serverraum, sondern Ihr bestehender Aktenserver, auf dem heute bereits jedes Mandat liegt und den Sie bereits absichern. Kasimir fügt dieser Fläche keine neue Kategorie von Daten hinzu — es fügt einen weiteren Dienst auf derselben Fläche hinzu. Betrieben wird er, nicht sich selbst überlassen.

CTA: Technisches Gespräch mit Ihrem IT-Dienstleister vereinbaren

8. Was wir nicht behaupten

Diese Liste ist der eigentliche Zweck dieser Seite. Sie ist vollständig, soweit uns die Punkte bekannt sind.

8.1 Zertifizierungen

ChangeMy.AI FlexCo hält derzeit keine Sicherheitszertifizierung. Konkret:

• keine ISO/IEC 27001
• keine ISO/IEC 42001
• kein SOC 2
• kein BSI C5
• kein TISAX
• keine „DSGVO-Zertifizierung" (eine solche allgemeine Zertifizierung existiert im Übrigen nicht)

Es ist derzeit keine dieser Zertifizierungen beauftragt. Die Architektur orientiert sich an den Maßnahmenfeldern der ISO/IEC 27001 und an Art 32 DSGVO — Zugriffskontrolle, Protokollierung, Verschlüsselung im Transport, Trennung der Umgebungen, Least Privilege. Eine Orientierung ist kein Zertifikat und wir stellen sie nicht als solches dar.

Die interne Prüfung vom Mai 2026, auf die wir intern verweisen, war ein Code-Review durch das eigene Team. Sie war kein externes Audit und wird auf dieser Seite nicht als solches geführt.

8.2 Datenschutz

• Kein „DSGVO-konform" als erreichter Zustand. Eine Datenschutz-Folgenabschätzung für den Produkteinsatz liegt nicht vor. Zutreffend ist: Kasimir ist entlang der Anforderungen aus Art 28, 30 und 32 DSGVO gebaut — mandatsbezogene Zugriffskontrolle, anfügendes Audit-Log, PII-Redaktion an der Modellgrenze, Verarbeitung im EWR. Die Folgenabschätzung für Ihren Einsatz bleibt Ihre Aufgabe als Verantwortliche; wir liefern die Angaben dafür zu.
• Kein „Ihre Daten verlassen nie die EU" ohne Zusatz. Sie verlassen im heutigen Betriebsmodell den Server der Kanzlei — sie bleiben im EWR. Das ist nicht dasselbe.
• Kein „Ihre Daten verlassen nie Ihr Haus", solange Betriebsmodell A oder B läuft.

8.3 Genauigkeit und Prüfung

• Keine Halluzinationsfreiheit. Garantiert ist, dass jeder Beleganker auf eine real abgerufene Passage zeigt — nicht, dass der Text darum herum richtig ist.
• Keine Genauigkeitsprozente. Der interne Testdatensatz umfasst zwölf Fragen gegen einen Testkorpus aus fünf Dokumenten. Alle in unserer Dokumentation genannten Schwellenwerte sind Zielwerte, keine Messergebnisse. Es gibt keinen veröffentlichten Messlauf.
• Keine „unabhängige Prüfung durch ein zweites Modell". In der Voreinstellung prüft dasselbe Modell, das die Antwort erzeugt hat. Eine Prüfung durch ein Modell einer anderen Familie ist möglich und muss gesondert konfiguriert werden.
• Keine Prüfung gegen eine Rechtsdatenbank. Der Prüflauf vergleicht Antworttext mit Quelltext. Ob eine zitierte Norm noch in Kraft ist, prüft er nicht.
• Kein „jede Aussage ist geprüft, bevor Sie sie sehen". Im Stream erscheint der Text zuerst, das Prüfergebnis danach.

8.4 Funktionsumfang

• Keine Texterkennung für eingescannte Dokumente. Reine Bild-PDFs liefern derzeit keinen Text. Verarbeitet werden PDF mit Textebene, DOCX, DOC, TXT, MD und einfaches HTML.
• Keine automatische Übernahme aus dem RIS. Gesetzestexte werden von einer administrierenden Person hochgeladen.
• Kein Outlook- oder Word-Add-in, kein Mandantenportal.
• Keine Fristenberechnung, keine Term-Sheet- und keine AVV-Prüfstrecke.
• Kein Single Sign-on.
• Keine Verfügbarkeitszusage. Es existiert kein SLA und keine belastbare Verfügbarkeitshistorie.
• Roadmap-Punkte werden als solche gekennzeichnet. Was hier nicht als vorhanden beschrieben ist, ist nicht vorhanden.

9. EU AI Act — Status und Fristen

Die Verordnung (EU) 2024/1689 ist seit 01.08.2024 in Kraft. Für Kasimir und für Ihre Kanzlei sind drei Punkte relevant.

9.1 Rollen

ChangeMy.AI FlexCo ist Anbieter im Sinne des Art 3 Nr 3, weil Kasimir unter eigener Marke bereitgestellt wird. Ihre Kanzlei ist Betreiberin im Sinne des Art 3 Nr 4, weil sie das System unter eigener Verantwortung einsetzt. Beide Pflichtenkreise bestehen nebeneinander; der Umstand, dass das zugrunde liegende Modell zugekauft ist, ändert daran nichts.

9.2 Was seit wann gilt

Regelungsbereich	Anwendbar ab	Betrifft
Art 4 — KI-Kompetenz des Personals	Februar 2025, in Kraft	Ihre Kanzlei als Betreiberin
Art 50 — Transparenz gegenüber Nutzern	02.08.2026	uns als Anbieter, Sie als Betreiberin
Art 50 Abs 2 — maschinenlesbare Kennzeichnung synthetischer Inhalte	Übergangsfrist für vor dem 02.08.2026 bereitgestellte Systeme	uns als Anbieter
Hochrisiko-Pflichten, eigenständige Systeme (Anhang III)	Dezember 2027	je nach Einstufung
Hochrisiko-Pflichten, eingebettete Systeme (Anhang I)	August 2028	je nach Einstufung

Der Digital Omnibus zur KI wurde vom Europäischen Parlament am 16.06.2026 und vom Rat am 29.06.2026 angenommen und verschiebt die Hochrisiko-Fristen wie angegeben. Art 50 ist davon nicht erfasst und bleibt beim 02.08.2026. [Quelle: https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/, Stand: 25.07.2026]

Für die Übergangsfrist bei Art 50 Abs 2 nennen die Quellen unterschiedliche Endtermine (Dezember 2026 beziehungsweise Februar 2027). Maßgeblich ist die Fassung im Amtsblatt; wir gleichen sie ab und halten das Ergebnis nach.

Die finalen Leitlinien der Europäischen Kommission zu Art 50 wurden am 20.07.2026 veröffentlicht und definieren den Auslegungsmaßstab. [Quelle: https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act, Stand: 25.07.2026]

Der Sanktionsrahmen für Verstöße gegen Art 50 liegt nach Art 99 Abs 4 lit g bei bis zu 15 Mio. EUR oder 3 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.

9.3 Was wir umsetzen

Art 50 Abs 1 verlangt, dass Personen, die mit einem KI-System interagieren, darüber informiert werden. Die Ausnahme für offensichtliche Fälle legen die Kommissionsleitlinien eng aus; ein sprachlich flüssiger Assistent fällt nicht darunter. Umgesetzt wird das durch eine dauerhafte Kennzeichnung der Oberfläche, einen Hinweis vor der ersten Eingabe und eine bleibende Zeile am Eingabefeld. Nach Art 50 Abs 5 sind diese Hinweise barrierefrei bereitzustellen; sie stehen deshalb auch für Screenreader vor dem Eingabefeld und werden nicht allein über Symbol oder Farbe transportiert.

Der KI-Hinweis ersetzt die Information nach Art 13 DSGVO nicht und umgekehrt. Beide sind erforderlich.

9.4 Was wir noch nicht behaupten

Wir behaupten keine Konformität mit der KI-Verordnung. Eine dokumentierte Einstufung von Kasimir nach der Verordnung liegt bislang nicht vor. Ein Konformitätsversprechen ohne diese Grundlage wäre eine Behauptung ins Blaue.

Was wir zusagen: Die Einstufung wird dokumentiert und Ihnen als Betreiberin zur Verfügung gestellt, damit Sie Ihre eigene Bewertung darauf aufsetzen können. Die Einstufung Ihres konkreten Einsatzes obliegt Ihnen; die kanzleiinterne Nutzung eines Rechercheassistenten fällt nach derzeitiger Einschätzung typischerweise nicht unter Anhang III, ersetzt aber Ihre eigene Prüfung nicht.

Ein Siegel „AI-Act-konform" werden Sie auf dieser Website nicht finden, solange kein Zertifikat dahintersteht. Ein Gütezeichen ohne Grundlage ist nach dem Anhang zum UWG per se unzulässig — und für eine Kanzlei als Käuferin wäre es das erste Warnsignal.

10. Was Sie von uns anfordern können

Für Ihre eigene Prüfung stellen wir bereit:

• ein Datenflussdiagramm für das von Ihnen gewählte Betriebsmodell
• die Liste der eingesetzten Dienstleister mit Sitz und Verarbeitungsort
• den Auftragsverarbeitungsvertrag nach Art 28 DSGVO
• die gesonderte Verschwiegenheitsverpflichtung nach § 43e BRAO beziehungsweise § 40 Abs 3 RL-BA 2015, als eigenes Dokument und nicht als Klausel in den AGB
• die Beschreibung der technischen und organisatorischen Maßnahmen nach Art 32 DSGVO
• diese Seite als datierte, archivierte Fassung

CTA: Sicherheitsunterlagen anfordern

CTA: Demo vereinbaren

---

Kasimir ersetzt keine anwaltliche Prüfung.