IT- / Datenschutzrecht
Escrow-Vereinbarung Source-Code
anymize entfernt Mandanten-, Vendor- und Treuhänder-Klarnamen, interne Produkt- und Modul-Bezeichnungen sowie Repository-Pfade automatisch aus der Escrow-Vereinbarung, bevor sie an GPT, Claude oder Gemini geht — und setzt sie nach der KI-Antwort wieder ein. So prüfen oder entwerfen Sie eine Source-Code-Escrow mit Release-Triggern, Verifikations-Prozess und Insolvenz-Tauglichkeit in Minuten, ohne § 43a BRAO oder § 203 StGB zu berühren.
Schwierigkeit: Fortgeschritten · Datenklasse: Mandantendaten · Letztes Review:
Zur Orientierung gedacht. Die anwaltliche Würdigung im Einzelfall bleibt selbstverständlich bei Ihnen — KI-Outputs sind vor jeder Verwendung zu prüfen. Mehr dazu am Ende.
Anwendungsbereich
Worum geht es hier?
Source-Code-Escrow ist die klassische Antwort auf das Vendor-Abhängigkeits-Risiko bei geschäftskritischer Software: Wenn der Vendor ausfällt — durch Insolvenz, durch Geschäftsaufgabe, durch nachhaltige Pflichtverletzung — soll die Mandantschaft trotzdem an den Source-Code kommen, um die Software wartbar zu halten. Wer eine Escrow-Vereinbarung manuell entwirft oder prüft, sitzt 90–180 Minuten am Vertragstext zu Release-Triggern, Treuhänder-Rolle, Verifikations-Prozess, Update-Pflichten und Lizenz-Erstreckung. Die Insolvenz-Tauglichkeit der Escrow ist nach §§ 103 ff. InsO ein eigenes Streitfeld — und der wirtschaftliche Wert der Escrow steht und fällt mit dieser Bewertung. Mit anymize geht der Vertragstext anonymisiert an ein Frontier-Modell — Mandantenname, Vendor-Identität, Treuhänder-Identität und interne Produkt-Bezeichnungen verlassen das Haus nicht. Die anwaltliche Würdigung — Trigger-Reichweite, Insolvenz-Tauglichkeit, Verifikations-Strenge, Lizenz-Erstreckung — bleibt anwaltliche Eigenleistung.
Für wen passt das?
Zielgruppe und Kontext
- Rolle
- Fachanwält:in für IT-Recht; Fachanwält:in für Insolvenzrecht mit IT-Schwerpunkt; Inhouse-Counsel bei Mandantschaft mit geschäftskritischen Software-Verträgen; Wirtschaftsanwält:in mit M&A-/Joint-Venture-Mandaten, in denen Code-Zugang relevant ist.
- Seniorität
- Berufserfahrung mittel bis Spezialist:in — Escrow-Vereinbarungen sind technisch und rechtlich kombiniert, brauchen das Verständnis für Trigger-Reichweite (mit insolvenzrechtlicher Belastbarkeit) und für die operative Verifikations-Tiefe (Build-Test, Vollständigkeits-Test, Lauffähigkeits-Test).
- Kanzleigröße
- Einzelkanzlei mit IT-Fokus bis Großkanzlei mit IT-/Insolvenz-Praxis. Der Effizienz-Hebel rechnet sich besonders bei Mandantschaft mit mehreren geschäftskritischen Software-Verträgen, bei Konzern-Sourcing mit Standard-Escrow-Klausel-Set und bei Reviews im Rahmen von M&A-Due-Diligence.
- Spezifische Kontexte
- Mandantschaft schließt neuen Software-Vertrag mit geschäftskritischer Komponente und braucht Escrow-Begleitung; bestehender Escrow-Vertrag wird turnusmäßig auf Release-Reife geprüft (war der letzte Verifikations-Test erfolgreich?); Vendor zeigt Insolvenz-Anzeichen und Mandantschaft prüft Release-Trigger und nächste Schritte; M&A-Due-Diligence mit Escrow-Inventur; Konzern-Sourcing mit Vereinheitlichung der Escrow-Klauseln.
Die Situation in der Kanzlei
So bringen Sie Tempo und Sorgfalt zusammen
Escrow-Vereinbarungen sind in der Praxis oft ein Stück Papier ohne wirtschaftlichen Wert: Die Release-Trigger sind so eng formuliert, dass sie nie greifen; der hinterlegte Code ist bei Release tatsächlich nicht lauffähig, weil Build-Anleitung, Build-Umgebung oder dritter Code fehlen; der Treuhänder hat nie eine Verifikation durchgeführt; die Lizenz-Erstreckung im Release-Fall ist nicht geregelt; die insolvenzrechtliche Belastbarkeit ist offen, weil der Insolvenzverwalter nach § 103 InsO das Wahlrecht hat. Wer eine Escrow-Vereinbarung manuell prüft oder entwirft, sitzt 90–180 Minuten an diesen Detail-Fragen. Wer ChatGPT oder Claude direkt nutzen würde, käme in Minuten zur Klausel-Matrix — verletzt aber § 43a BRAO und § 203 StGB, sobald Mandantenname, Vendor-Identität, Treuhänder-Identität und interne Produkt-Bezeichnungen das Haus verlassen. anymize löst genau diesen Konflikt: Klarnamen werden vor dem KI-Aufruf zu Platzhaltern; die KI-Antwort kommt strukturiert zurück, anymize re-identifiziert. Die Vertraulichkeit ist strukturell gewahrt.
Was Sie davon haben
Zeit, Wert, Vertraulichkeit
Zeit pro Escrow-Review
~90 Min
Frontier-KI strukturiert Klausel-Matrix mit Trigger-Analyse, Verifikations-Tiefe und Insolvenz-Hinweisen in unter 15 Minuten. Anwaltliche Würdigung der Trigger-Reichweite, Insolvenz-Tauglichkeit und Verifikations-Strenge kommen wie gewohnt obendrauf.
Mehrwert pro Vertrag
€ 375–675
Stundensatz IT-/Insolvenzrecht (€ 250–450/h) angewandt auf 90 Minuten freigespielte Strukturierungs-Zeit.
Vertraulichkeit
strukturell
anymize entfernt 40+ Kategorien personenbezogener und geschäftsgeheimnis-relevanter Daten — Mandantenname, Vendor-Identität, Treuhänder-Identität, Produkt- und Modul-Bezeichnungen, Repository-Pfade — bevor der Vertrag das Haus verlässt.
Erkennungsrate
>95 %
Dreifach geprüft (Algorithmus + zwei spezialisierte KI-Prüfungen). Restmenge kontrollieren Sie im Vorschau-Modus vor dem KI-Aufruf.
So gehen Sie vor
In 5 Schritten zum Antrag
Escrow-Vereinbarung und Mandatskontext bereitstellen. Sie übernehmen den Escrow-Vertrag (PDF, Word, Markdown) und ggf. den zugehörigen Hauptvertrag (Software-Lizenz oder SaaS-Vertrag) in den anymize-Arbeitsplatz. Klären Sie: Welche Geschäfts-Kritikalität der Software (Tier 1–3)? Welcher Vendor-Risiko-Status (etabliert, jung, Insolvenz-Anzeichen)? Welche Verifikations-Erwartung (Existenz-Bestätigung vs. Lauffähigkeit)? Welche Treuhänder-Klasse (spezialisierter Software-Escrow-Treuhänder, Notar, Bank)?
Sie
Mandatsgrundlage · Kritikalität-Klassifikation
anymize anonymisiert automatisch. Über 40 Kategorien personenbezogener und geschäftsgeheimnis-relevanter Daten — Mandantenname, Vendor-Identität, Treuhänder-Identität, Produkt- und Modul-Bezeichnungen, Repository-Pfade, Vertretungsberechtigte, IBANs — werden durch semantische Platzhalter ersetzt. Sie sehen die Vorschau vor dem KI-Aufruf.
anymize
§ 43a BRAO Verschwiegenheit · § 203 StGB · Geschäftsgeheimnis
Frontier-KI strukturiert. Die pseudonymisierte Escrow-Vereinbarung geht an Ihr gewähltes Modell — GPT, Claude oder Gemini, alle in anymize verfügbar. Mit dem unten stehenden Prompt fragen Sie eine Klausel-Matrix mit den sechs Kern-Dimensionen ab: Release-Trigger, Hinterlegungs-Inhalt und -Form, Verifikations-Prozess, Update-Pflichten, Lizenz-Erstreckung im Release-Fall und Insolvenz-Hinweise. Die KI sieht keine Klarnamen — sie arbeitet ausschließlich mit den Platzhaltern.
GPT / Claude / Gemini in anymize
Klausel-Matrix in Minuten
anymize re-identifiziert. Die KI-Antwort kommt mit Platzhaltern zurück; anymize setzt automatisch die Originaldaten wieder ein. Sie erhalten eine Klausel-Matrix, die Sie anwaltlich würdigen: Trigger-Reichweite im konkreten Vendor-Setup, Verifikations-Tiefe (genügt der vereinbarte Test?), Insolvenz-Tauglichkeit (§ 103 InsO Wahlrecht, BGH-Linie zu Software-Hinterlegungen), Lizenz-Erstreckung (steht im Release-Fall ausreichendes Nutzungsrecht zur Verfügung?).
anymize + Sie
Bidirektionale Anonymisierung · anwaltliche Würdigung
Mandanten-Empfehlung und Verhandlung. Sie schicken die Klausel-Matrix mit Mandanten-Empfehlung an die Mandantschaft. Bei Lücken: Empfehlung zur Trigger-Erweiterung, zur Verifikations-Verschärfung (z. B. jährlicher Build-Test), zur Insolvenz-Klausel-Anpassung (Vorab-Hinterlegung mit unbedingter Treuhand statt aufschiebend bedingter Vereinbarung) oder zur Lizenz-Klausel-Klarstellung. Bei akuter Insolvenz-Lage: Eskalations-Plan und Release-Antrag vorbereiten.
Sie
Anwaltliche Beratung im Mandatsverhältnis
Womit Sie arbeiten
So setzen Sie anymize konkret ein
Was anymize tut
- Erkennt 40+ Kategorien personenbezogener und geschäftsgeheimnis-relevanter Daten — Mandantenname, Vendor-Identität, Treuhänder-Identität, Produkt- und Modul-Bezeichnungen, Repository-Pfade, Vertretungsberechtigte — mit über 95 % Erkennungsrate.
- Dreistufige Prüfung: Algorithmische Analyse, dann zwei spezialisierte KI-Prüfungen, die auch Kontext berücksichtigen (z. B. Vendor-Name vs. Treuhänder-Name).
- Bidirektionale Anonymisierung: Platzhalter werden eingesetzt, das Frontier-Modell antwortet mit Kontext, anymize re-identifiziert beim Empfang.
- Daten in deutschen Rechenzentren (Hetzner). Originaldokumente werden nicht gespeichert — nur die Zuordnung Platzhalter ↔ Klarname, mit Aufbewahrungsfrist nach Ihrer Wahl von 24 Stunden bis unbegrenzt.
Was Sie als Anwält:in tun
- Geschäfts-Kritikalität klären und passende Verifikations-Tiefe wählen — Existenz-Bestätigung genügt selten, Lauffähigkeits-Test ist die belastbare Variante.
- Vorschau der Anonymisierung sichten — bei Komponenten-Listen mit Modul-Bezeichnungen Stichproben prüfen.
- Klausel-Matrix anwaltlich würdigen — insbesondere die Trigger-Reichweite und die Insolvenz-Tauglichkeit nach § 103 InsO.
- Verifikations-Strenge bewerten — wie oft wird tatsächlich getestet, wer trägt die Kosten, wer dokumentiert das Ergebnis?
- Mandanten-Empfehlung formulieren, Verhandlungs-Strategie für Klausel-Anpassungen abstimmen, bei akuter Vendor-Krise Eskalations-Plan vorbereiten.
Daten-Input
Escrow-Vereinbarung (PDF, Word, Markdown), zugehöriger Hauptvertrag (Software-Lizenz / SaaS), ggf. Verifikations-Berichte vorheriger Tests, Mandanten-Briefing zur Geschäfts-Kritikalität.
Output-Kontrolle
Pseudonymisierter Text geht an die KI. Re-identifizierte Klausel-Matrix kommt zurück. anymize selbst trifft keine inhaltlichen Aussagen — die Strukturierung leistet das Frontier-Modell, die Würdigung machen Sie.
Freigabeprozess
Sie behalten jederzeit die Hoheit: Sichtung der Anonymisierung, anwaltliche Bewertung der Trigger-Reichweite und Insolvenz-Tauglichkeit, Mandanten-Beratung, Verhandlungs-Strategie — alles im üblichen Kanzlei-Workflow. anymize ist der Anonymisierungs-Layer, keine Workflow-Software.
Die KI-Anweisung
Prompt zum Kopieren
So nutzen Sie diesen Prompt:
1. Escrow-Vereinbarung in anymize einfügen — die Anonymisierung läuft automatisch (Mandantenname, Vendor-Identität, Treuhänder-Identität, Produkt- und Modul-Bezeichnungen werden zu Platzhaltern).
2. Diesen Prompt kopieren und an die Escrow-Vereinbarung anhängen; ggf. den Hauptvertrag als zweiten Block daruntersetzen.
3. In anymize unter „Tools → Reasoning“ auf „Thinking-Modus“ stellen, dann KI-Aufruf starten — der Output kommt re-identifiziert zurück.
# Rolle
Du bist Vertragsanalyse-Assistenz fuer eine IT-/Insolvenzrechts-
Kanzlei.
Rechtsstand: <heutiges Datum — bitte aktuell ermitteln und hier einsetzen>.
# Aufgabe
Pruefe die vorgelegte Source-Code-Escrow-Vereinbarung systematisch
gegen
(1) den Katalog der Release-Trigger und ihre praktische Reichweite,
(2) den Hinterlegungs-Inhalt (vollstaendiger Source-Code, Build-
Anleitung, Build-Umgebung, dritter Code, Lizenz-Bedingungen),
(3) den Verifikations-Prozess (Existenz, Vollstaendigkeit,
Lauffaehigkeits-Test),
(4) die Update-Pflichten waehrend der Vertragslaufzeit,
(5) die Lizenz-Erstreckung im Release-Fall (Nutzungsrecht-
Reichweite),
(6) die insolvenzrechtliche Belastbarkeit nach §§ 103 ff. InsO.
Liefere eine Klausel-Matrix mit Soll-Ist-Vergleich und einem
Verhandelbarkeits-Hinweis je Befund. Die anwaltliche Wertung —
Trigger-Reichweite im konkreten Vendor-Setup, Insolvenz-
Tauglichkeit, Verhandlungs-Strategie — ist NICHT deine Aufgabe.
# Inhalt
## Abschnitt 1 — Release-Trigger
Tabelle mit Spalten: Trigger | Klausel | Soll | Ist | Reichweite
Trigger-Klassen zu pruefen:
- Insolvenz-Eroeffnung gegen Vendor
- Insolvenz-Antrag mit Eroeffnungs-Reife
- Geschaeftsaufgabe ohne Rechtsnachfolge
- Wesentliche Pflichtverletzung (Wartungs-Ausfall ueber
X Monate; ausstehende Sicherheits-Updates)
- Konkursverwandte Schutz-Verfahren in auslaendischer
Jurisdiktion (Chapter 11 etc.)
- Verkauf des Vendors an Wettbewerber des Lizenznehmers
(Change-of-Control)
- Einstellung der Produkt-Pflege
## Abschnitt 2 — Hinterlegungs-Inhalt
Tabelle mit Spalten: Inhalts-Element | Soll | Ist | Luecke?
Inhalts-Elemente:
- Vollstaendiger Source-Code aller Komponenten
- Build-Anleitung (Step-by-Step)
- Build-Umgebung (Versionen, Tools)
- Dritter Code und OSS-Komponenten mit Lizenz-Texten
- Datenbank-Schemata
- Konfigurations-Dateien (ohne Geheimnisse)
- Test-Code und Test-Daten
- Dokumentation (Architektur, Schnittstellen)
- Patch-Stand und Versionsverlauf
- Hinweise auf externe Abhaengigkeiten (APIs, Lizenzen Dritter)
## Abschnitt 3 — Verifikations-Prozess
Tabelle mit Spalten: Verifikations-Tiefe | Frequenz | Kosten | Folge
Verifikations-Tiefen:
- Existenz-Bestaetigung (Treuhaender bestaetigt Datentraeger erhalten)
- Vollstaendigkeits-Test (gegen Inhalts-Liste)
- Lauffaehigkeits-Test (Build der Software aus dem hinterlegten Code)
- Funktional-Test (Software laeuft mit Test-Daten)
## Abschnitt 4 — Update-Pflichten waehrend der Vertragslaufzeit
Tabelle mit Spalten: Pflicht | Soll | Ist | Luecke?
Pflichten:
- Hinterlegungs-Frequenz (z. B. quartalsweise, bei Major-Release)
- Trigger fuer ausserplanmaessige Hinterlegung
- Nachweis ueber Aktualitaet der Hinterlegung
- Sanktion bei Verstoss gegen Update-Pflicht
## Abschnitt 5 — Lizenz-Erstreckung im Release-Fall
Tabelle mit Spalten: Frage | Soll | Ist | Luecke?
Fragen:
- Nutzungsrecht-Umfang nach Release (Vervielfaeltigung, Aenderung,
Weitergabe)
- Reichweite gegenueber Tochtergesellschaften
- OSS-Komponenten-Lizenz-Erstreckung (Lizenz-Anerkennung)
- Zeitliche Befristung der erweiterten Lizenz
- Verguetungs-Pflicht im Release-Fall
## Abschnitt 6 — Insolvenz-Hinweise (§§ 103 ff. InsO)
Tabelle mit Spalten: Aspekt | Hinweis | Reichweite
Aspekte:
- § 103 InsO Wahlrecht des Insolvenzverwalters
- Aufschiebend bedingte Vereinbarung vs. unbedingt erfuellte
Treuhand-Konstruktion
- Vorab-Hinterlegung als Schutz vor Wahlrecht
- BGH-Linie zur Software-Hinterlegung
- Hinweis auf separate Insolvenz-Klausel-Verhandlung
## Abschnitt 7 — Verhandelbarkeits-Uebersicht
Tabelle mit Spalten: Luecke | Stufe | Verhandlungs-Hinweis
Stufen:
- [STANDARD] — typische Luecke, regelmaessig verhandelbar
- [KRITISCH] — Trigger-Luecke, Verifikations-Luecke oder Lizenz-
Luecke, die Escrow wirtschaftlich entwertet
- [ANWALT-PRUEFUNG] — insolvenzrechtliche Bewertung im
konkreten Vendor-Setup erforderlich
# Format
Markdown. Tabellen fuer alle Abschnitte.
# Verbote
KEINE abschliessende Insolvenz-Tauglichkeits-Bewertung — die
Bewertung nach §§ 103 ff. InsO ist anwaltlich.
KEINE Empfehlung zur Annahme / Verhandlung / Ablehnung.
KEINE Spekulation zur Solvenz des Vendors.
KEINE Aussage zur Marktueblichkeit von Verifikations-Tiefen ohne
Quellen-Beleg.
KEINE Bezugnahme auf KI-Modell-Versionen oder Hersteller-Marketing.So sieht der Sachverhalt aus
Pseudonymisierter Eingabetext
Vertragsparteien:
Hinterlegender (Vendor): [[Unternehmensname-5e2a]],
[[Adresse-5e2a]], vertreten durch [[Vorname-5e2a]] [[Nachname-5e2a]].
Beguenstigter (Mandant): [[Unternehmensname-1c8d]],
[[Adresse-1c8d]], vertreten durch [[Vorname-1c8d]] [[Nachname-1c8d]].
Treuhaender: [[Unternehmensname-9f4b]],
[[Adresse-9f4b]], vertreten durch [[Vorname-9f4b]] [[Nachname-9f4b]].
Vertragsgegenstand:
Hinterlegung des Source-Codes der Standard-Software [[Produktname-5e2a]]
in der jeweils aktuellen Version. Die Hinterlegung dient der
Absicherung des Beguenstigten gegen den Ausfall des Hinterlegenden.
Auszug § 3 (Hinterlegungs-Inhalt):
Der Hinterlegende hinterlegt beim Treuhaender den Source-Code
der Standard-Software in einer Form, die eine spaetere Verwendung
durch den Beguenstigten ermoeglicht. Beigefuegt sind eine
Inhalts-Liste und eine kurze Build-Anleitung.
Auszug § 5 (Release-Trigger):
Der Treuhaender gibt den hinterlegten Code an den Beguenstigten
heraus, wenn
(a) ueber das Vermoegen des Hinterlegenden das Insolvenzverfahren
eroeffnet wurde, oder
(b) der Hinterlegende seine geschaeftliche Taetigkeit dauerhaft
eingestellt hat.
Auszug § 7 (Verifikation):
Der Treuhaender bestaetigt jaehrlich gegenueber dem Beguenstigten
den Eingang neuer Hinterlegungen. Eine inhaltliche Pruefung des
hinterlegten Codes obliegt dem Treuhaender nicht.
Auszug § 9 (Update-Pflichten):
Der Hinterlegende aktualisiert die Hinterlegung bei jedem
Major-Release. Major-Releases werden vom Hinterlegenden definiert.
Auszug § 11 (Nutzungsrecht im Release-Fall):
Im Release-Fall erhaelt der Beguenstigte ein nicht-uebertragbares,
nicht-unterlizenzierbares Nutzungsrecht zur internen Verwendung
des hinterlegten Codes fuer die Dauer der Restlaufzeit des
Lizenzvertrags.
Auszug § 13 (Verguetung Treuhaender):
Der Treuhaender erhaelt eine jaehrliche Verguetung in Hoehe von
[[Betrag-9f4b]] zuzueglich Aufwandsersatz fuer Verifikationen.So liefert anymize zurück
Der Antrags-Entwurf
# Source-Code-Escrow — Klausel-Matrix
## Abschnitt 1 — Release-Trigger
| Trigger | Klausel | Soll | Ist | Reichweite |
|---|---|---|---|---|
| Insolvenz-Eroeffnung | § 5 (a) | Pflicht | ja | erfuellt |
| Insolvenz-Antrag mit Eroeffnungs-Reife | n. v. | empfohlen | nein | [STANDARD] — Trigger greift erst spaet |
| Geschaeftsaufgabe | § 5 (b) | Pflicht | ja | erfuellt — aber "dauerhaft" auslegungsbeduerftig |
| Wesentliche Pflichtverletzung (Wartungs-Ausfall) | n. v. | empfohlen | nein | [KRITISCH] — Vendor-Schwaeche ohne Insolvenz nicht erfasst |
| Konkursverwandte auslaendische Verfahren | n. v. | empfohlen bei grenzueb. Vendor | nein | [PRUEFUNG] |
| Change-of-Control an Wettbewerber | n. v. | empfehlenswert | nein | [STANDARD] |
| Einstellung der Produkt-Pflege | n. v. | empfehlenswert | nein | [STANDARD] |
## Abschnitt 2 — Hinterlegungs-Inhalt
| Inhalts-Element | Soll | Ist | Luecke? |
|---|---|---|---|
| Vollstaendiger Source-Code | Pflicht | "in einer Form, die spaetere Verwendung ermoeglicht" — vage | [KRITISCH] — Inhalts-Liste konkretisieren |
| Build-Anleitung Step-by-Step | Pflicht | "kurze Build-Anleitung" | [STANDARD] |
| Build-Umgebung (Versionen, Tools) | Pflicht | nicht geregelt | [KRITISCH] |
| Dritter Code und OSS-Lizenz-Texte | Pflicht | nicht geregelt | [KRITISCH] |
| Datenbank-Schemata | empfohlen | nicht geregelt | [STANDARD] |
| Konfigurations-Dateien | empfohlen | nicht geregelt | [STANDARD] |
| Test-Code und Test-Daten | empfohlen | nicht geregelt | [STANDARD] |
| Dokumentation | empfohlen | nicht geregelt | [STANDARD] |
| Patch-Stand und Versionsverlauf | empfohlen | nicht geregelt | [STANDARD] |
| Externe Abhaengigkeiten (APIs Dritter) | empfohlen | nicht geregelt | [STANDARD] |
## Abschnitt 3 — Verifikations-Prozess
| Verifikations-Tiefe | Frequenz | Kosten | Folge |
|---|---|---|---|
| Existenz-Bestaetigung (Datentraeger erhalten) | jaehrlich (§ 7) | Aufwandsersatz | erfuellt |
| Vollstaendigkeits-Test gegen Inhalts-Liste | nicht geregelt | — | [KRITISCH] — Treuhaender lehnt inhaltliche Pruefung ab |
| Lauffaehigkeits-Test (Build der Software) | nicht geregelt | — | [KRITISCH] — wirtschaftlich entscheidend, fehlt |
| Funktional-Test | nicht geregelt | — | [STANDARD] |
## Abschnitt 4 — Update-Pflichten waehrend Vertragslaufzeit
| Pflicht | Soll | Ist | Luecke? |
|---|---|---|---|
| Hinterlegungs-Frequenz | quartalsweise oder Major-Release | "jedes Major-Release" | erfuellt; aber Major-Release-Definition durch Vendor [STANDARD] |
| Trigger fuer ausserplanmaessige Hinterlegung | empfohlen | nicht geregelt | [STANDARD] |
| Nachweis ueber Aktualitaet | Pflicht | Existenz-Bestaetigung jaehrlich | [STANDARD] |
| Sanktion bei Verstoss | empfohlen | nicht geregelt | [STANDARD] |
## Abschnitt 5 — Lizenz-Erstreckung im Release-Fall
| Frage | Soll | Ist | Luecke? |
|---|---|---|---|
| Nutzungsrecht-Umfang (Vervielfaeltigung, Aenderung, Weitergabe) | volle Wartungs-Tauglichkeit | "interne Verwendung" — Aenderungsrecht nicht erwaehnt | [KRITISCH] |
| Reichweite gegenueber Tochtergesellschaften | empfohlen | nicht geregelt | [STANDARD] |
| OSS-Komponenten-Lizenz-Erstreckung | Pflicht | nicht geregelt | [STANDARD] |
| Zeitliche Befristung | unbefristet (Wartungs-Tauglichkeit) | "Restlaufzeit des Lizenzvertrags" | [KRITISCH] — nach Vertragsende keine Nutzung |
| Verguetungs-Pflicht im Release-Fall | klaren | nicht geregelt | [STANDARD] |
## Abschnitt 6 — Insolvenz-Hinweise (§§ 103 ff. InsO)
| Aspekt | Hinweis | Reichweite |
|---|---|---|
| § 103 InsO Wahlrecht | Insolvenzverwalter kann Escrow-Vertrag ablehnen | [ANWALT-PRUEFUNG] |
| Aufschiebend bedingte Konstruktion | beguenstigend fuer Mandantschaft, wenn Treuhand unbedingt | [ANWALT-PRUEFUNG] |
| Vorab-Hinterlegung mit unbedingter Treuhand | Schutz vor § 103-Wahlrecht | empfohlen bei kritischer Mandantschaft [ANWALT-PRUEFUNG] |
| BGH-Linie Software-Hinterlegung | Hinweis: Insolvenz-Festigkeit ist Trefferfrage der Vertragsgestaltung | [ANWALT-PRUEFUNG] |
| Separate Insolvenz-Klausel | empfohlen | nicht vorhanden [STANDARD] |
## Abschnitt 7 — Verhandelbarkeits-Uebersicht
| Luecke | Stufe | Verhandlungs-Hinweis |
|---|---|---|
| Trigger "wesentliche Pflichtverletzung" | [KRITISCH] | ohne diesen Trigger greift Escrow erst bei Insolvenz |
| Hinterlegungs-Inhalt unklar | [KRITISCH] | konkrete Inhalts-Liste mit Build-Umgebung und OSS-Lizenzen ergaenzen |
| Lauffaehigkeits-Test fehlt | [KRITISCH] | empfohlen jaehrlich, Kosten geteilt |
| Nutzungsrecht "nur intern, ohne Aenderung" | [KRITISCH] | ohne Aenderungsrecht keine Wartung moeglich |
| Befristung Lizenz auf Restlaufzeit | [KRITISCH] | unbefristete Wartungs-Lizenz im Release-Fall verhandeln |
| Trigger fehlt bei Geschaeftsaufgabe ohne Insolvenz | [STANDARD] | "Einstellung der Produkt-Pflege" als Trigger ergaenzen |
| Insolvenz-Tauglichkeit nach § 103 InsO | [ANWALT-PRUEFUNG] | Vorab-Hinterlegung als Schutz pruefen |
[ANWALT-PRUEFUNG: Insolvenz-Tauglichkeit nach §§ 103 ff. InsO,
Trigger-Reichweite im Vendor-Setup [[Unternehmensname-5e2a]],
Verhandlungs-Strategie und Eskalations-Plan im Insolvenz-Fall
erfolgen anwaltlich.]Was das Berufsrecht verlangt
Pflichten — und wie anymize sie abdeckt
§ 43a BRAO Verschwiegenheit
Escrow-Vereinbarungen enthalten Mandanten- und Vendor-Identität sowie typischerweise interne Produkt- und Modul-Bezeichnungen. anymize ersetzt 40+ Kategorien personenbezogener Daten durch Platzhalter, bevor irgendein KI-Anbieter den Vertragstext sieht. Erkennungsrate über 95 %.
§ 43e BRAO Auftragsverarbeitung
Sie schließen einen AVV mit anymize ab. Datenverarbeitung ausschließlich in deutschen Rechenzentren (Hetzner). Originaldokumente speichern wir nicht — nur die Zuordnung Platzhalter ↔ Originaldaten, mit Aufbewahrungsfrist nach Ihrer Wahl. Eine Selbstreferenz für IT-Kanzleien: Sie prüfen die Escrow-Vereinbarung mit einem Werkzeug, das selbst nach § 43e BRAO ausgelegt ist.
§ 203 StGB Geheimnisschutz
Indem Mandantenname, Vendor-Identität, Treuhänder-Identität und interne Produkt-Bezeichnungen das Haus nicht verlassen, vermeiden Sie das Offenbarungsproblem grundsätzlich. Die anymize-Mitarbeitenden sind nach § 203 belehrt und sehen ohnehin nur die Zuordnungstabelle, nicht den Vertragstext.
§ 103 InsO Wahlrecht des Insolvenzverwalters
Bei beiderseits noch nicht vollständig erfüllten Verträgen hat der Insolvenzverwalter nach § 103 InsO ein Wahlrecht. Die Escrow-Vereinbarung ist aus dieser Perspektive ein zweiseitiger Vertrag, dessen Schicksal in der Insolvenz des Vendors offen ist. Praxis-Lösungen: Vorab-Hinterlegung mit echter Treuhand, bei der die Treuhand-Beziehung gegenüber dem Begünstigten in der Vendor-Insolvenz fortbesteht. Die KI markiert die Frage; die abschließende Bewertung der Insolvenz-Tauglichkeit ist anwaltlich.
Verifikations-Schwäche als ökonomischer Risiko-Treiber
Eine Escrow-Vereinbarung ohne Lauffähigkeits-Test ist ökonomisch oft wertlos: Der hinterlegte Code kann bei Release-Fall fehlen, unvollständig sein oder ohne Build-Umgebung nicht baubar. Marktstandard für geschäftskritische Software: jährlicher Build-Test mit dokumentierter Reproduzierbarkeit. Bei Tier-1-Software empfohlen: Funktional-Test mit Test-Daten.
Lizenz-Erstreckung im Release-Fall
Die häufigste Achillesferse ist die Lizenz-Klausel im Release-Fall: Ein Nutzungsrecht „nur intern, ohne Änderung, befristet auf Restlaufzeit des Lizenzvertrags“ erlaubt keine Wartung. Die Mandantschaft braucht im Release-Fall ein unbefristetes Bearbeitungs- und Vervielfältigungs-Recht für den Zweck der Wartungs-Fortführung, regelmäßig mit Erstreckung auf Konzern-Tochter.
Grenzüberschreitender Vendor und Insolvenz-Statut
Bei Vendoren mit Sitz außerhalb Deutschlands ist das Insolvenz-Statut zu berücksichtigen — Chapter 11 in den USA und Restructuring-Schemes in UK haben andere Wirkungen als ein deutsches Insolvenzverfahren. Die KI strukturiert die Frage; die Bewertung des konkreten Insolvenz-Statuts ist anwaltlich.
Datenschutz und Vertraulichkeit
So funktioniert das mit anymize
Die juristisch entscheidende Frage beim Escrow-Review: Sieht der KI-Anbieter den Mandantennamen, die Vendor-Identität, die Treuhänder-Identität und die internen Produkt-Bezeichnungen? Antwort mit anymize: nein. Vendor-, Mandanten- und Treuhänder-Klarnamen, Adressen, Produkt- und Modul-Bezeichnungen, Repository-Pfade, Vertretungsberechtigte und IBANs werden vor dem KI-Aufruf durch Platzhalter ersetzt; nach der KI-Antwort identifiziert anymize zurück. Verarbeitung in deutschen Rechenzentren (Hetzner), AVV nach Art. 28 DSGVO und § 43e BRAO ist Teil des Standardvertrags, Originaldokumente werden nicht gespeichert. Rechtsgrundlage Art. 6 Abs. 1 lit. b DSGVO (Mandatsvertrag). Mandanten- und Vendor-Klarnamen werden aus dem KI-Kontext gehalten, was § 203 StGB strukturell entlastet. Die EDPB Opinion 28/2024 erkennt funktionale Anonymität gegenüber Cloud-Diensten an — anymize setzt diese funktionale Anonymität operativ um. Bei Escrow-Inhalten kommt zusätzlich der Geschäftsgeheimnis-Schutz nach GeschGehG hinzu; auch diese Daten werden von anymize erkannt und ersetzt.
Was anymize konkret leistet
- Erkennt Mandanten-, Vendor- und Treuhänder-Klarnamen, Adressen, Produkt- und Modul-Bezeichnungen, Repository-Pfade und Vertretungsberechtigte mit über 95 % Genauigkeit.
- Ersetzt sie durch semantische Platzhalter, bevor der Vertragstext an GPT, Claude oder Gemini geht.
- Re-identifiziert die KI-Antwort automatisch — Sie sehen die Klausel-Matrix mit den richtigen Klarnamen zurück.
- Verarbeitung in deutschen Rechenzentren (Hetzner). AVV nach Art. 28 DSGVO mit § 43e BRAO-Erklärung im Standardvertrag.
- Originaldokumente werden nicht gespeichert — nur die Zuordnung Platzhalter ↔ Klarname, mit Aufbewahrungsfrist nach Ihrer Wahl von 24 Stunden bis unbegrenzt.
Sicherheitscheck vor der Einreichung
Was anymize liefert — was Sie souverän entscheiden
Vor dem KI-Aufruf
- Geschäfts-Kritikalität der Software klassifiziert (Tier 1–3)?
- Vendor-Risiko-Status bewertet (etabliert, jung, Insolvenz-Anzeichen)?
- Treuhänder-Klasse benannt (spezialisierter Escrow-Treuhänder, Notar, Bank)?
- Verifikations-Erwartung formuliert (Existenz, Vollständigkeit, Lauffähigkeit, Funktional)?
- Anonymisierungs-Vorschau gesichtet?
Nach der KI-Antwort
- Re-Identifikation korrekt — alle Platzhalter zurückgesetzt?
- Klausel-Matrix vollständig — alle sieben Abschnitte abgedeckt?
- [KRITISCH]-Markierungen anwaltlich nachgeprüft (insbesondere Trigger und Lizenz-Erstreckung)?
- [ANWALT-PRUEFUNG] Insolvenz-Tauglichkeit nach § 103 InsO abgearbeitet?
- Bei grenzüberschreitendem Vendor: Insolvenz-Statut geprüft?
Vor der Mandanten-Empfehlung
- Trigger-Reichweite anwaltlich verantwortet?
- Verifikations-Tiefe gegen Geschäfts-Kritikalität abgeglichen?
- Lizenz-Erstreckung im Release-Fall gewürdigt (Wartungs-Tauglichkeit)?
- Bei Tier-1-Software: Vorab-Hinterlegung mit unbedingter Treuhand empfohlen?
- Bei akuter Vendor-Krise: Eskalations-Plan und Release-Antrag vorbereitet?
Typische Fehlermuster — und wie anymize gegensteuert
- →KI gibt abschließende Insolvenz-Tauglichkeits-Bewertung ab — der Prompt verbietet das, prüfen Sie die Markierung.
- →KI bewertet eine Verifikations-Tiefe als „marktüblich“ ohne Quellen-Beleg.
- →KI verwechselt Existenz-Bestätigung und Lauffähigkeits-Test — beide haben unterschiedliche ökonomische Wirkung.
- →KI behandelt grenzüberschreitende Vendoren wie deutsche — das Insolvenz-Statut ist eigenständig zu prüfen.
- →KI behauptet, dass Standard-Trigger „Insolvenz-Eröffnung“ ausreicht — bei Vendor-Schwäche ohne Insolvenz greift dieser Trigger gerade nicht.
Rechtsgrundlagen
Normen, Urteile, Belege
Primärnormen
- Wirkungen der Insolvenzeröffnung auf Schuldverhältnisse
- Verwahrungsvertrag (Treuhand-Konstruktion)
- Nutzungsrechte an Software
- Zulässige Handlungen des berechtigten Software-Nutzers
Berufsrechtliche Grundlagen
- Anwaltliche Verschwiegenheit
- Auftragsverarbeitung und IT-Auslagerung
- Verletzung von Privatgeheimnissen
- Geschäftsgeheimnis-Schutz
Sekundärquellen
- Insolvenz-Festigkeit Software-Hinterlegung
- Verifikations-Anforderungen
- Praxis-Empfehlungen
- Mandantentransparenz und KI-Einsatz
- AI-/Modell-Verarbeitung und funktionale Anonymität
Stand: · Nächste Überprüfung:
Hinweis zur Nutzung
Zur Orientierung — nicht als Mandatsersatz
Diese Anleitung beschreibt einen Arbeitsablauf, den Sie mit anymize umsetzen können. Sie ist zur Orientierung gedacht und ersetzt weder die anwaltliche Würdigung im Einzelfall noch eine fachanwaltliche Prüfung. Welche Rechtsprechung einschlägig ist, wie der Sachverhalt rechtlich zu bewerten ist, welche Anträge in Ihrem konkreten Mandat richtig sind — das bleibt selbstverständlich bei Ihnen.
KI-Outputs müssen vor jeder Verwendung anwaltlich geprüft werden. Insbesondere Urteils-Aktenzeichen, Norm-Verweise und Fristen sind gegen Primärquellen zu verifizieren. anymize gewährleistet die Vertraulichkeit der Mandantendaten gegenüber dem KI-Anbieter; die fachliche Richtigkeit des Outputs liegt in Ihrer Verantwortung.
Jetzt starten.
14 Tage kostenlos testen.
Alle Modelle. Alle Features. Keine Kreditkarte.
Wir sind überzeugt von anymize. Und wir wissen: Bei einem KI-Werkzeug, das Mandanten-, Patienten- oder Mitarbeiter-Daten berührt, reicht ein Demo-Video nicht. Deshalb 14 Tage voller Zugang – alle Modelle, alle Features, keine Kreditkarte. Genug Zeit, um sicher zu sein, bevor du uns vertraust.
Dein KI-Arbeitsplatz wartet.