sprek
Entwurfsfassung (Version 0.6), vor erster Verwendung anwaltlich zu pruefen — siehe Versionshistorie am Ende des Dokuments.

Auftragsverarbeitungsvertrag (AVV) — Sprek

Version: 0.6 (Entwurf, anwaltlich nicht geprüft) Datum: 2026-09-08 Status: Anlage zum jeweils zugrundeliegenden Hauptvertrag — Pilotvertrag oder Allgemeine Geschäftsbedingungen (AGB, § 5a regelt den unentgeltlichen Testzugang), je nachdem, auf welchem Weg der Verantwortliche den Sprek-Dienst nutzt (siehe § 1 Abs. 1a). Entwurf, vor erster Verwendung anwaltliche Prüfung erforderlich

Herkunft dieses Dokuments: Basiert auf der öffentlichen „Mustervereinbarung zur Auftragsverarbeitung, Version 2.1" (Bundesmuster, /mnt/project/Muster_zur_Auftragsverarbeitung.pdf), angepasst für die B2B-SaaS-Konstellation Sprek ↔ Handwerksbetrieb. Das Bundesmuster ist ursprünglich für Behörden-Auftrags- verarbeitung geschrieben — Parteien-Fiktion und einzelne Klauseln (insbesondere die EU/EWR-Ausschließlichkeit in § 3) wurden entsprechend angepasst; die Grundstruktur (§§ 1–11, Anhänge) bleibt erhalten, weil sie GDD/LfDI-BW-Standard und damit anwaltlich vertraut ist.

Position in der Legal-Struktur: docs/legal/documents/avv.md — Anlage zum jeweiligen Hauptvertrag: im Pilotbetrieb Anlage 1 zum Pilotvertrag (siehe clauses/avv-verweis.md und documents/pilotvertrag.md § 5, § 10 Abs. 1), im unentgeltlichen Testzugang Anlage zu den AGB (siehe documents/agb.md § 5a Abs. 8 und § 9 Abs. 2).

Quellen: knowledge/03_avv-pflichtinhalte.md, knowledge/04_drittland-transfer.md, knowledge/08_datenpannen.md, knowledge/12_betroffenenrechte.md, knowledge/13_loeschkonzept.md, registers/vendor-risk-register.md

Vereinbarung zur Auftragsverarbeitung

Als Anlage zum zwischen den Vertragsparteien geschlossenen Hauptvertrag vom [Datum] — nachfolgend „Hauptvertrag" —, der je nach Zugangsweg der Pilotvertrag oder die Allgemeinen Geschäftsbedingungen (§ 5a für den unentgeltlichen Testzugang) sein kann (siehe § 1 Abs. 1a),

zwischen

[Vor- und Nachname / Firma des Kunden], [Anschrift] — nachfolgend „Verantwortlicher" —

und

Max Bleckmann, Inhaber des Einzelunternehmens „Sprek", Bergische Straße 13, 42549 Velbert — nachfolgend „Auftragsverarbeiter" —

— beide nachfolgend gemeinsam „Vertragsparteien" —

wird die folgende Vereinbarung zur Auftragsverarbeitung geschlossen:

Präambel

Die Vertragsparteien sind mit dem Hauptvertrag ein Auftrags- verarbeitungsverhältnis eingegangen. Um die sich hieraus ergebenden Rechte und Pflichten gemäß den Vorgaben der Datenschutz-Grundverordnung (DSGVO) und des Bundesdatenschutz- gesetzes (BDSG) zu konkretisieren, schließen die Vertragsparteien die nachfolgende Vereinbarung.

Der Auftragsverarbeiter verarbeitet im Rahmen des Hauptvertrags personenbezogene Daten von Endkunden des Verantwortlichen, um aus Sprachnachrichten automatisiert Angebotsentwürfe zu erstellen, die der Verantwortliche vor Versand prüft und freigibt.

§ 1 Anwendungsbereich

(1) Die Vereinbarung findet Anwendung auf die Verarbeitung (Art. 4 Nr. 2 DSGVO) aller personenbezogenen Daten (im Folgenden: Daten), die Gegenstand des Hauptvertrags sind oder im Rahmen von dessen Durchführung anfallen und auf Weisung des Verantwortlichen verarbeitet werden. Nicht unter den Anwendungsbereich fällt die Verarbeitung von Daten des Verantwortlichen selbst (Stammdaten, Kontaktdaten, Nutzungsdaten der Sprek-Anwendung), für die der Auftragsverarbeiter eigenständig Verantwortlicher im Sinne der DSGVO ist (siehe documents/pilotvertrag.md § 5 Abs. 3 bzw. im Testzugang documents/agb.md § 9 Abs. 3 und die Datenschutzerklärung des Auftragsverarbeiters).

(1a) Nutzt der Verantwortliche den Sprek-Dienst im Rahmen eines unentgeltlichen, befristeten Testzugangs ohne gesondert unterzeichneten Pilotvertrag, gelten die Allgemeinen Geschäftsbedingungen (§ 5a — unentgeltlicher Testzugang) als Hauptvertrag im Sinne dieser Vereinbarung; diese Vereinbarung gilt mit deren Annahme. Die Dauer des Testzugangs richtet sich nach dem Zugangsweg:

a) Testzugang ohne Zugangscode (Selbst-Service-Anmeldung ohne vorherige Code-Vergabe): Der Testzugang ist befristet auf 30 Tage ab Einrichtung des Zugangs, unabhängig davon, ob das mengenmäßige Nutzungskontingent (aktuell 3 Angebotsentwürfe) innerhalb dieser Frist ausgeschöpft wird.

b) Testzugang mit Zugangscode (Pilot-Trial-Einlösung): Der Testzugang ist befristet auf die im jeweiligen Zugangscode hinterlegte Anzahl von Tagen (derzeit 7 Tage für Call-Interessenten oder 30 Tage für Piloten), beginnend mit Einlösung des Codes.

In beiden Fällen endet der Testzugang automatisch mit Fristablauf, ohne dass es einer Kündigung bedarf. Ein Übergang in ein entgeltliches Abonnement erfolgt ausschließlich durch gesonderten Abschluss der Allgemeinen Geschäftsbedingungen; bis dahin gilt diese Vereinbarung in Verbindung mit den Testzugangsbedingungen fort.

Die Consent-Mechanik ist seit spätestens 2026-09-08 aktiv (SPREK_REQUIRE_AVV_CONSENT, verhaltensgeprüft). AGB- und AVV-Zustimmung werden im Testzugang per Checkbox erhoben, zusammen mit einer Kenntnisnahme der Datenschutzerklärung nach Art. 28 Abs. 9 DSGVO protokolliert (test_access_consents).

[OFFEN: Die Befristung nach lit. a ist technisch nicht durchgesetzt (kein Cron; Löschkonzept Zeile 16 trägt [TODO]). Bis zur Implementierung läuft der Zugang faktisch weiter, obwohl er nach dieser Vereinbarung beendet ist.]

(2) Diese Vereinbarung gilt vorrangig vor anderen Vereinbarungen zwischen den Vertragsparteien, soweit es die Verarbeitung personenbezogener Daten betrifft, es sei denn, zwischen den Parteien wird ausdrücklich etwas anderes vereinbart.

§ 2 Konkretisierung des Auftragsinhalts

(1) Gegenstand und Dauer der Auftragsverarbeitung sowie Umfang, Art und Zweck der vorgesehenen Verarbeitung von Daten bestimmen sich nach dem Hauptvertrag und der als Anlage 1 zu dieser Vereinbarung beigefügten Verarbeitungsbeschreibung.

(2) Folgende Arten personenbezogener Daten sind Gegenstand der Verarbeitung durch den Auftragsverarbeiter:

  • Sprachaufnahmen (Audio) mit Kundenname, Adresse, gewünschter Leistung, Mengen- und Preisangaben, ggf. Zusatzangaben
  • Transkripte derselben Inhalte (Freitext)
  • Strukturierte Angebotsdaten (Name, Adresse, Leistungspositionen, Preise)
  • E-Mail-Adressen der Endkunden (für den Angebotsversand)

Details siehe Anlage 1 (Verarbeitungsbeschreibung).

(3) Der Kreis der durch den Umgang mit ihren Daten betroffenen Personen sind: Endkunden des Verantwortlichen (Auftraggeber von Handwerksleistungen), sowie ggf. Dritte, die in Sprachnachrichten beiläufig erwähnt werden (siehe Anlage 1).

(4) Im Rahmen der Auftragsverarbeitung werden nach aktuellem Kenntnisstand keine besonderen Kategorien von Daten (Art. 9 DSGVO) im Sinne einer regelmäßigen oder gezielten Verarbeitung verarbeitet. Es ist jedoch nicht vollständig auszuschließen, dass Freitext-Sprachnachrichten im Einzelfall besondere Kategorien enthalten (z. B. Gesundheitsangaben bei Zugänglichkeitshinweisen).

Zur Sprachaufnahme selbst (geklärt, siehe knowledge/03_avv-pflichtinhalte.md Abschnitt 7.2): Die Sprachaufnahme stellt kein biometrisches Datum nach Art. 9 DSGVO dar, weil der Auftragsverarbeiter sie ausschließlich zur Transkription einsetzt — nicht zur Sprechererkennung, Voiceprint- Extraktion oder Authentifizierung. Nach Art. 4 Nr. 14 DSGVO kommt es auf den Identifizierungszweck an, nicht auf die bloße technische Möglichkeit einer biometrischen Auswertung. Der Auftragsverarbeiter sichert zu, dass die eingesetzten KI- Dienstleister ausschließlich zur Transkription bzw. inhaltlichen Strukturierung beauftragt werden und keine Sprechererkennungs- oder Voiceprint-Funktionen genutzt werden. Sollte sich dies durch eine Änderung der eingesetzten KI-Dienste ändern, ist diese Bewertung unverzüglich neu vorzunehmen.

[ANWALT: Diese Einschätzung stützt sich auf EDPB-Leitlinien 02/2021 zu virtuellen Sprachassistenten im Analogieschluss, nicht auf eine bindende Einzelfallentscheidung zu dieser genauen Konstellation. Restrisiko gering, aber zu bestätigen — siehe knowledge/03_avv-pflichtinhalte.md Abschnitt 7.2 für die vollständige Herleitung inklusive Eventualprüfung.]

(5) Die verarbeiteten personenbezogenen Daten haben einen normalen bis erhöhten Schutzbedarf (Sprachaufnahmen als höchstpersönliche Daten, siehe Abs. 4).

§ 3 Verpflichtungen und Weisungsbefugnis

(1) Die Vertragsparteien sind verpflichtet, die ihnen durch datenschutzrechtliche Vorschriften (insbesondere die DSGVO) auferlegten Pflichten einzuhalten. Der Verantwortliche kann jederzeit die Herausgabe, Berichtigung, Anpassung, Löschung und Einschränkung der Verarbeitung der Daten verlangen (siehe auch § 7 dieser Vereinbarung).

(2) Zur Gewährleistung des Schutzes der Rechte der betroffenen Personen unterstützt der Auftragsverarbeiter den Verantwortlichen angemessen, insbesondere durch Bereitstellung eines Export-Pakets pro Endkunde auf Anfrage. Das Verfahren im Detail ist im Betroffenenrechte-Runbook des Auftragsverarbeiters beschrieben (documents/betroffenenrechte-runbook.md, sobald verfügbar; bis dahin: formlose Anfrage per E-Mail, Bearbeitung binnen 10 Werktagen als internes Sprek-Ziel).

(3) Soweit sich eine betroffene Person zwecks Geltendmachung eines Betroffenenrechts unmittelbar an den Auftragsverarbeiter wendet, wird der Auftragsverarbeiter dieses Ersuchen unverzüglich an den Verantwortlichen weiterleiten und die betroffene Person darüber informieren, dass ihr Anliegen an den zuständigen Verantwortlichen weitergeleitet wurde.

(4) Der Auftragsverarbeiter darf Daten ausschließlich im Rahmen der Weisungen des Verantwortlichen verarbeiten, sofern er nicht zu einer anderen Verarbeitung durch Unionsrecht oder das Recht eines Mitgliedstaats verpflichtet ist. Eine Weisung ist die auf einen bestimmten Umgang des Auftragsverarbeiters mit Daten gerichtete Anordnung des Verantwortlichen. Die Weisungen werden zunächst durch den Pilotvertrag und diese Vereinbarung definiert; insbesondere gilt die technisch im Sprek-System vorgesehene Verarbeitung (Sprachnachricht → Transkription → Strukturierung → Angebotsentwurf → Freigabe → Versand) als generelle Standardweisung des Verantwortlichen zu Beginn der Nutzung. Der Verantwortliche kann diese Standardweisung jederzeit in dokumentierter Form ändern, ergänzen oder ersetzen. [ANWALT: Bestätigung der Konstruktion „Standardweisung durch Vertragsschluss" für automatisierte SaaS-Workflows — siehe knowledge/03_avv-pflichtinhalte.md Abschnitt 7.4]

(5) Der Auftragsverarbeiter hat den Verantwortlichen unverzüglich zu informieren, wenn er der Meinung ist, eine Weisung verstoße gegen datenschutzrechtliche Vorschriften. Der Auftragsverarbeiter ist berechtigt, die Durchführung der entsprechenden Weisung solange auszusetzen, bis sie vom Verantwortlichen bestätigt oder geändert wird. Die weisungsberechtigten und -empfangsberechtigten Personen sowie die Informationswege sind im Anhang „Weisungsbefugnis" festgelegt.

(6) Änderungen des Verarbeitungsgegenstandes mit Verfahrensänderungen sind gemeinsam abzustimmen und zu dokumentieren.

(7) Auskünfte an Dritte oder die betroffene Person darf der Auftragsverarbeiter nur nach vorheriger ausdrücklicher Zustimmung des Verantwortlichen erteilen, es sei denn, er ist gesetzlich zur Herausgabe verpflichtet.

(8) Der Auftragsverarbeiter verwendet die Daten für keine anderen Zwecke als die Erbringung der Sprek-Leistung und ist insbesondere nicht berechtigt, sie an Dritte weiterzugeben, es sei denn, er ist gesetzlich dazu verpflichtet. Kopien und Duplikate werden ohne Wissen des Verantwortlichen nicht erstellt, mit Ausnahme technisch notwendiger Backups im Rahmen der TOMs (Anlage 2).

(9) Der Verantwortliche führt — soweit ihn diese Pflicht trifft — das Verzeichnis von Verarbeitungstätigkeiten nach Art. 30 Abs. 1 DSGVO. Der Auftragsverarbeiter stellt dem Verantwortlichen auf dessen Wunsch Informationen zur Aufnahme in dieses Verzeichnis zur Verfügung und führt entsprechend Art. 30 Abs. 2 DSGVO sein eigenes Verzeichnis zu allen Kategorien der im Auftrag durchgeführten Verarbeitungstätigkeiten (siehe documents/vvt.md, Teil B, sobald verfügbar).

(10) Drittlandtransfer — abweichend vom EU/EWR-Grundsatz 🔑

Anders als im Bundesmuster vorgesehen, erfolgt die Verarbeitung der Daten im Auftrag des Verantwortlichen nicht ausschließlich auf dem Gebiet der EU/des EWR. Der Auftragsverarbeiter setzt zur Erbringung der Leistung namentlich benannte Subunternehmen mit Sitz in einem Drittland (insbesondere USA) ein — siehe Anlage 3 (Subprozessoren-Liste). Mit Abschluss dieser Vereinbarung erteilt der Verantwortliche seine allgemeine Genehmigung für die in Anlage 3 benannten Subprozessoren einschließlich der dort verzeichneten Drittlandübermittlungen.

Jede Übermittlung von Daten an ein Drittland erfolgt ausschließlich auf Grundlage der in Anlage 4 (Drittlandtransfer-Mechanismen) dokumentierten Garantien (EU-US Data Privacy Framework, Standard- vertragsklauseln der EU-Kommission, ergänzende Transfer Impact Assessments) und muss mit Kapitel V DSGVO im Einklang stehen. Die grundlegenden Voraussetzungen für die Rechtmäßigkeit der Verarbeitung bleiben unberührt.

[ANWALT: Dies ist die wichtigste inhaltliche Abweichung vom Bundesmuster und sollte vorrangig geprüft werden. Die Doppel-Strategie DPF+SCC+TIA ist in knowledge/04_drittland- transfer.md hergeleitet, aber nicht anwaltlich bestätigt.]

(11) Der Auftragsverarbeiter gewährleistet, dass ihm unterstellte natürliche Personen, die Zugang zu Daten haben, diese nur auf Anweisung des Verantwortlichen verarbeiten. Da der Auftragsverarbeiter als Einzelunternehmer ohne Mitarbeiter operiert, betrifft dies aktuell ausschließlich Max Bleckmann selbst; bei künftiger Einstellung von Mitarbeitern oder Einsatz von Home-Office-Arbeitsplätzen ist vorab eine angemessene technisch- organisatorische Absicherung sicherzustellen und zu dokumentieren.

§ 4 Beachtung zwingender gesetzlicher Pflichten durch den Auftragsverarbeiter

(1) Der Auftragsverarbeiter gewährleistet, dass die zur Verarbeitung der Daten befugten Personen zur Vertraulichkeit verpflichtet sind (siehe auch clauses/vertraulichkeit.md des Pilotvertrags bzw. documents/agb.md § 9 Abs. 1) und weist dies dem Verantwortlichen auf Wunsch nach.

(2) Die Vertragsparteien unterstützen sich gegenseitig beim Nachweis und der Dokumentation der ihnen obliegenden Rechenschaftspflicht (Art. 5 Abs. 2, Art. 24 Abs. 1 DSGVO). Der Auftragsverarbeiter stellt dem Verantwortlichen hierzu bei Bedarf entsprechende Informationen zur Verfügung, insbesondere die DSFA-Schwellwertanalyse (documents/dsfa-schwellwertanalyse.md) und die TOM-Dokumentation.

(3) Ob den Auftragsverarbeiter eine Pflicht zur Benennung eines Datenschutzbeauftragten trifft, ist derzeit nicht abschließend geklärt und Gegenstand der laufenden DSFA-Schwellwertanalyse (documents/dsfa-schwellwertanalyse.md). Diese Analyse kommt zu dem Ergebnis, dass die Indizienlage überwiegend für eine DSFA-Pflicht spricht und empfiehlt, diese Pflicht proaktiv anzunehmen (dort Abschnitt 6.2) — was nach § 38 Abs. 1 S. 2 BDSG automatisch eine DSB-Benennungspflicht des Auftragsverarbeiters zur Folge hätte (dort Abschnitt 6.3). Bis zur anwaltlichen Bestätigung dieser Einschätzung benennt der Auftragsverarbeiter als vorläufigen Ansprechpartner für den Datenschutz: Max Bleckmann, datenschutz@sprek.de. Sollte sich die DSB-Pflicht bestätigen, wird unverzüglich ein externer Datenschutzbeauftragter benannt und dessen Kontaktdaten mitgeteilt.

[ANWALT: Dieser Absatz und die DSFA-Schwellwertanalyse gehen gemeinsam zum Anwaltstermin. Die Formulierung ist bewusst mit der DSFA-Empfehlung synchronisiert (beide Dokumente gehen von wahrscheinlicher DSFA-/DSB-Pflicht aus, statt sie zu verneinen) — frühere Entwurfsfassung hatte hier optimistischer „keine bestätigte Pflicht" formuliert, was der eigenen DSFA-Tendenz widersprach.]

(4) Der Auftragsverarbeiter informiert den Verantwortlichen unverzüglich über Kontrollen und Maßnahmen durch Aufsichts- behörden, soweit sie die im Auftrag des Verantwortlichen verarbeiteten Daten betreffen. Zuständige Aufsichtsbehörde für den Auftragsverarbeiter ist die Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen (LDI NRW), Sitz Velbert (siehe knowledge/08_datenpannen.md Abschnitt 8).

§ 5 Technisch-organisatorische Maßnahmen und deren Kontrolle

(1) Die Vertragsparteien vereinbaren die in Anlage 2 („Technisch-organisatorische Maßnahmen") zu dieser Vereinbarung niedergelegten konkreten Sicherheitsmaßnahmen. Anlage 2 wird Gegenstand dieser Vereinbarung und verweist auf documents/toms.md.

(2) Ergibt eine Prüfung des Verantwortlichen einen Anpassungsbedarf der technisch-organisatorischen Maßnahmen gemäß Art. 32 DSGVO, sind die Anpassungen vom Auftragsverarbeiter im Rahmen wirtschaftlicher Zumutbarkeit für einen Solo-Founder- Betrieb umzusetzen.

(3) Technische und organisatorische Maßnahmen unterliegen dem technischen Fortschritt; dem Auftragsverarbeiter ist es gestattet, alternative, mindestens gleichwertige Maßnahmen umzusetzen. Wesentliche Änderungen sind zu dokumentieren.

(4) Der Auftragsverarbeiter stellt dem Verantwortlichen alle erforderlichen Informationen zum Nachweis der Einhaltung dieser Vereinbarung zur Verfügung und ermöglicht angemessene Überprüfungen.

(5)–(6) Die Überprüfung kann auf Grundlage vorgelegter Dokumentation oder — bei berechtigtem Interesse und mit angemessenem Vorlauf — durch eine Vor-Ort-Prüfung erfolgen, unter Berücksichtigung der besonderen Situation eines Ein-Personen-Betriebs (kein eigenes Rechenzentrum; die Kernverarbeitung findet bei den in Anlage 3 benannten Subprozessoren statt, deren eigene Zertifizierungen/Nachweise maßgeblich sind).

(7) Der Auftragsverarbeiter stellt dem Verantwortlichen die für eine etwaige Datenschutz-Folgenabschätzung (Art. 35 DSGVO) erforderlichen Informationen zur Verfügung — insbesondere die DSFA-Schwellwertanalyse als Ausgangspunkt.

(8) Der Auftragsverarbeiter ergreift im Benehmen mit dem Verantwortlichen die zur Sicherung der Daten erforderlichen Maßnahmen unter Berücksichtigung des Stands der Technik.

§ 6 Mitteilung bei Verstößen durch den Auftragsverarbeiter

(1) Der Auftragsverarbeiter unterrichtet den Verantwortlichen innerhalb von 24 Stunden nach Kenntniserlangung über jede Verletzung des Schutzes personenbezogener Daten im Sinne von Art. 4 Nr. 12 DSGVO, die die im Auftrag verarbeiteten Daten betrifft — unabhängig von einer eigenen Einschätzung des Risikos. Die Meldung erfolgt über die Kontaktstelle datenschutz@sprek.de und enthält mindestens: Art der Verletzung, betroffene Datenkategorien und ungefähre Anzahl, wahrscheinliche Folgen sowie bereits ergriffene Maßnahmen. Ist eine vollständige Aufklärung binnen 24 Stunden nicht möglich, erfolgt eine vorläufige Meldung mit Nachreichung der Details.

(2) Der Auftragsverarbeiter unterrichtet den Verantwortlichen zudem umgehend bei schwerwiegenden Störungen seines Betriebsablaufs sowie bei Verdacht auf Verstöße gegen diese Vereinbarung oder gesetzliche Datenschutzbestimmungen.

(3) Dies gilt insbesondere im Hinblick auf die Meldepflicht des Verantwortlichen nach Art. 33 Abs. 1 DSGVO (72-Stunden-Frist gegenüber der Aufsichtsbehörde) sowie die Benachrichtigungspflicht nach Art. 34 DSGVO. Der Auftragsverarbeiter sichert zu, den Verantwortlichen bei diesen Pflichten angemessen zu unterstützen — insbesondere durch Bereitstellung der zur Meldung erforderlichen Informationen. Meldungen nach Art. 33 oder 34 DSGVO für den Verantwortlichen darf der Auftragsverarbeiter nur nach vorheriger Weisung gemäß § 3 durchführen; der Auftragsverarbeiter trifft selbst keine eigene Risikobewertung anstelle des Verantwortlichen (siehe knowledge/08_datenpannen.md Abschnitt 4).

(4) Der Auftragsverarbeiter dokumentiert jede Verletzung des Schutzes personenbezogener Daten — auch Bagatellfälle und Verdachtsfälle ohne anschließende Meldung — in einem internen Datenpannen-Verzeichnis (docs/legal/internal/datenpannen- verzeichnis.md, sobald eingerichtet).

§ 7 Löschung und Rückgabe von Daten

(1) Überlassene Datenträger und Datensätze verbleiben im Eigentum des Verantwortlichen.

(2) Nach Abschluss der vertraglich vereinbarten Leistungen oder früher nach Aufforderung durch den Verantwortlichen, jedoch spätestens mit Beendigung des Hauptvertrags, hat der Auftragsverarbeiter sämtliche im Auftrag verarbeiteten personenbezogenen Daten dem Verantwortlichen nach dessen Wahl zurückzugeben oder datenschutzgerecht zu löschen. Die konkrete Ausgestaltung (30-Tage-Wahlfrist, Default „Löschen" bei ausbleibender Wahl, Format der Rückgabe) ist in clauses/datenloeschung-vertragsende.md und im Löschkonzept (documents/loeschkonzept.md, sobald verfügbar) geregelt und Bestandteil dieser Vereinbarung. Eine weitere Speicherung ist nur zulässig, soweit hierzu eine gesetzliche Verpflichtung besteht (z. B. § 257 HGB beim Verantwortlichen selbst, nicht beim Auftragsverarbeiter — siehe clauses/datenloeschung- vertragsende.md Abs. 5). Ein Löschungsprotokoll wird dem Verantwortlichen auf Anforderung vorgelegt.

Für Daten aus einem Testzugang nach § 1 Abs. 1a gilt abweichend: Die Löschfrist beginnt mit Ablauf der jeweils einschlägigen Testphase und nicht erst mit einer gesonderten Kündigung.

a) Bei einem Testzugang ohne Zugangscode (§ 1 Abs. 1a lit. a) beginnt die Frist mit Ablauf der dort genannten Frist ab Einrichtung des Zugangs, unabhängig von der tatsächlichen Nutzung.

b) Bei einem Testzugang mit Zugangscode (§ 1 Abs. 1a lit. b) beginnt die Frist mit Ablauf der dort genannten Anzahl von Tagen, sofern bis dahin keine Umstellung auf ein entgeltliches Abonnement erfolgt ist.

In beiden Fällen werden die im Auftrag verarbeiteten Daten, sofern kein Übergang in ein entgeltliches Abonnement erfolgt, spätestens 30 Tage nach Ablauf der jeweiligen Testphase gelöscht, sofern der Verantwortliche nicht zuvor ausdrücklich Rückgabe verlangt. Damit ergibt sich rechnerisch: lit. a spätestens 60 Tage nach Einrichtung des Zugangs (30 Tage Testphase + 30 Tage Löschfrist), lit. b spätestens die im Zugangscode hinterlegte Anzahl von Tagen plus 30 Tage nach Einlösung des Codes.

[OFFEN: Die Löschung nach dem vorstehenden Absatz ist derzeit für beide Zugangswege technisch nicht durchgesetzt (kein Cron; Löschkonzept Zeilen 16/17 tragen jeweils [TODO]). Bis zur Implementierung ist diese Regelung deklaratorisch.]

[ANWALT: Ob eine rein vertraglich zugesagte Löschfrist ohne technische Durchsetzung genügt oder die Implementierung Voraussetzung dafür ist, den Testzugang als Standardweg scharfzuschalten, ist vor dieser Umstellung zu klären.]

(3) Bei Subprozessoren, deren Löschverfahren der Auftragsverarbeiter nicht vollständig steuern kann (insbesondere KI-Dienstleister im API-Modus), gilt die in clauses/datenloeschung-vertragsende.md Abs. 4 beschriebene Realität: keine dauerhafte Speicherung zu Trainingszwecken, Löschung gemäß den Standardverfahren des jeweiligen Anbieters.

§ 8 Subunternehmen

(1) Der Auftragsverarbeiter erhält mit Abschluss dieser Vereinbarung die allgemeine Genehmigung des Verantwortlichen für die Beauftragung der in Anlage 3 aufgeführten Subunternehmen. Der Auftragsverarbeiter unterrichtet den Verantwortlichen mindestens 30 Tage im Voraus in Textform über beabsichtigte Änderungen dieser Liste (Hinzufügen oder Ersetzen von Subunternehmen) und räumt dem Verantwortlichen damit ausreichend Zeit ein, vor der Beauftragung Einwände zu erheben. Der Auftragsverarbeiter stellt hierfür die erforderlichen Informationen bereit.

Nicht als Subunternehmen im Sinne dieser Regelung gelten Dienstleistungen, die als bloße Nebenleistung in Anspruch genommen werden (z. B. Telekommunikationsdienstleistungen), sofern hierfür angemessene vertragliche Vereinbarungen bestehen.

(2) Der Auftragsverarbeiter stellt sicher, dass seine vertraglichen Vereinbarungen mit Subunternehmen ein Datenschutzniveau gewährleisten, das mindestens dieser Vereinbarung entspricht.

(3) Dem Verantwortlichen sind auf Anforderung Auskünfte über den Inhalt der mit Subunternehmen geschlossenen Verträge und deren datenschutzrelevante Umsetzung zu geben, soweit dies nach den jeweiligen Anbieterverträgen möglich ist.

(4) Kommt ein Subunternehmen seinen datenschutzrechtlichen Verpflichtungen nicht nach, haftet der Auftragsverarbeiter gegenüber dem Verantwortlichen für die Einhaltung dieser Pflichten.

§ 9 Datenschutzkontrolle

Soweit der Verantwortliche einen Datenschutzbeauftragten benannt hat oder eine vergleichbare Kontrollperson mit der Wahrnehmung seiner datenschutzrechtlichen Aufgaben betraut, gewährt der Auftragsverarbeiter dieser Person zu angemessenen Zeiten Zugang zu den zur Erfüllung ihrer Aufgaben erforderlichen Informationen und Auskünften. Die nach Gesetz bestehenden Verschwiegenheitspflichten bleiben unberührt.

§ 10 Haftung und Schadenersatz

Auf Art. 82 DSGVO wird bezüglich der Haftung und des Rechts auf Schadenersatz verwiesen. Diese Vereinbarung begrenzt oder erweitert die Haftung nach Art. 82 DSGVO nicht; die Haftungsregelungen des Pilotvertrags (documents/pilotvertrag.md § 4) betreffen ausschließlich die vertragliche Haftung außerhalb des Anwendungsbereichs der DSGVO.

§ 11 Schlussbestimmungen

(1) Änderungen und Ergänzungen dieser Vereinbarung und aller ihrer Bestandteile bedürfen der Textform und des ausdrücklichen Hinweises darauf, dass es sich um eine Änderung bzw. Ergänzung handelt. Dies gilt auch für den Verzicht auf dieses Formerfordernis.

(2) Sollten einzelne Regelungen dieser Vereinbarung unwirksam oder undurchführbar sein, wird davon die Wirksamkeit der übrigen Regelungen nicht berührt. An die Stelle der unwirksamen Regelung tritt diejenige wirksame Regelung, deren Wirkung der verfolgten Zielsetzung am nächsten kommt.

[Hinweis: Der Pilotvertrag selbst verzichtet bewusst auf eine salvatorische Klausel (siehe clauses/schlussbestimmungen.md Abschnitt 3, Begründung: § 306 BGB regelt den Effekt bereits gesetzlich). Diese AVV übernimmt die salvatorische Klausel aus dem Bundesmuster, weil sie dort GDD/LfDI-BW-Standard ist. Diese Inkonsistenz zwischen Pilotvertrag und AVV ist stilistisch, nicht juristisch relevant — ANWALT kann vereinheitlichen, falls gewünscht.]

Unterschriften

Verantwortlicher Auftragsverarbeiter
Ort, Datum Ort, Datum
Name, Funktion Max Bleckmann

Anhang „Weisungsbefugnis" zu § 3

zur Vereinbarung zur Auftragsverarbeitung vom [Datum] zwischen [Verantwortlicher] und Sprek (Max Bleckmann)

Weisungsberechtigte Person auf Seiten des Verantwortlichen:

  • [Name des Handwerkers/Inhabers]

Zum Empfang der Weisungen berechtigte Person auf Seiten des Auftragsverarbeiters:

  • Max Bleckmann (alleiniger Ansprechpartner, Ein-Personen-Betrieb)

Vorgesehene Informationswege, wenn eine Weisung nach Meinung des Auftragsverarbeiters gegen datenschutzrechtliche Vorschriften verstößt: ☐ schriftliche und/oder ☐ elektronische und/oder ☐ mündliche Information — Vorschlag: elektronische Information (E-Mail), da praxistauglich und dokumentierbar für einen Solo-Founder-Betrieb

Weisungen (auch mündliche) sind durch die Vertragsparteien zu dokumentieren. Änderungen sind unverzüglich anzuzeigen.

Anlage 1 — Verarbeitungsbeschreibung

Die vollständige Beschreibung des Verarbeitungsablaufs (Datenfluss von der WhatsApp-Sprachnachricht bis zum Angebotsversand, Datenspeicherorte, Subprozessoren-Touchpoints, Zwei-Loop- Freigabemodell) ist in documents/pipeline-uebersicht.md dokumentiert und Bestandteil dieser Vereinbarung.

Zusammengefasst: Verarbeitung von Sprachnachrichten der Handwerker zwecks automatisierter Erstellung von Angebots- dokumenten für deren Endkunden; Transkription (Whisper), Extraktion und Textgenerierung (Claude), PDF-Erstellung (Gotenberg), Freigabe durch den Handwerker, Versand an den Endkunden. Datenkategorien und Betroffene siehe § 2 dieser Vereinbarung.

Anlage 2 — Technisch-organisatorische Maßnahmen (TOM)

Die nach Art. 32 DSGVO geschuldeten technisch-organisatorischen Maßnahmen sind in documents/toms.md (Acht-Kategorien-Struktur: Zutritts-, Zugangs-, Zugriffs-, Weitergabe-, Eingabe-, Auftrags-, Verfügbarkeits- und Trennungskontrolle) dokumentiert und Bestandteil dieser Vereinbarung. Das Dokument weist den jeweiligen Umsetzungsstatus ehrlich aus (umgesetzt / teilweise / offen) und benennt die vor Pilot-Start noch zu schließenden Punkte (u. a. Restore-Test, RLS-Verifikation, n8n-Log-Retention).

Anlage 3 — Subprozessoren-Liste

Stand: 2026-07-27. Diese Liste ist Gegenstand der allgemeinen Genehmigung nach § 8 dieser Vereinbarung. Vollständige Details, DPF/SCC/TIA-Status und Verifikationsdaten: registers/vendor-risk-register.md.

# Subprozessor (Einheit) Leistung Sitz/Region Verarbeitete Daten
1 Twilio Inc. WhatsApp Business API (Ein-/Ausgang) — produktiv seit 2026-08-07, verifizierte Business-Nummer +49 151 68546473 USA Audio, Telefonnummer, Inhalt der Sprachnachricht
2 OpenAI [Entity USA/EU beim DPA klären] Whisper (Sprach-Transkription) USA [EU-Residenz prüfen] Audio mit Endkundendaten
3 Anthropic [Entity USA/EU beim DPA klären] Claude (Extraktion, Textgenerierung) USA [EU-Residenz prüfen] Transkripte mit Endkundendaten, Tenant-Vorlagen
4 Vercel Inc. Frontend-/App-Hosting USA Session, Cookies, IP-Adressen des Handwerkers
5 Supabase Inc. [EU-Vertragspartner verify] Datenbank + Storage EU (Frankfurt) Sämtliche persistierten Daten
6 Resend Inc. [EU-Entity verify] Transaktions-E-Mail EU (Irland) E-Mail-Adresse Endkunde, PDF, Mail-Inhalt
7 Amazon Web Services EMEA SARL (Luxemburg) SES-Mail-Backend (Sub-Sub via Resend) EU (Irland, eu-west-1) wie Resend
8 Hetzner Online GmbH VPS-Hosting (n8n, Gotenberg) Deutschland sämtliche Daten während der Verarbeitung
9 Haufe-Lexware [Entity ergänzen] Buchhaltungs-Integration (geplant) Deutschland Rechnungsbezogene Daten (ab Bezahl-Phase)
10 Meta Platforms Ireland Ltd. Betrieb der WhatsApp Business Plattform (Twilio als technischer Zustelldienst darüber) EU (Irland); US-Mutter Meta Platforms, Inc. Telefonnummer, Sprachnachricht, Transkript, Metadaten

Nicht als datenverarbeitender Subprozessor geführt: IONOS SE (Montabaur, DE) — reine Domain-/DNS-Registrierung für sprek.de, keine Berührung mit personenbezogenen Inhaltsdaten.

Hinweis zum DPA-Status: Mehrere Subprozessoren stehen noch auf offenem DPA-Status (siehe Vendor-Risk-Register). Der Abschluss der jeweiligen Auftragsverarbeitungsverträge mit den Subprozessoren ist Voraussetzung der Produktivnutzung und Gegenstand eines eigenen offenen Arbeitspakets. [TODO: DPAs abschließen — Asana]

Anlage 4 — Drittlandtransfer-Mechanismen

Grundlage: Doppel-Strategie DPF + SCC + TIA aus knowledge/04_drittland-transfer.md. Diese Tabelle dokumentiert je Subprozessor mit Drittlandbezug den Übermittlungsmechanismus.

Subprozessor Drittland? Mechanismus Status
Twilio Inc. Ja (USA) EU-US Data Privacy Framework (aktiv), SCC als Backup, TIA empfohlen 🟡 DPA offen
OpenAI Ja (USA, sofern US-Entity) [EU-Residenz prüfen] SCC + TIA (Pflicht), DPF nur falls im Register bestätigt 🟠 DPA + Entity offen
Anthropic Ja (USA, sofern US-Entity) [EU-Residenz prüfen] SCC + TIA (Pflicht), DPF nur falls bestätigt 🟠 DPA + Entity offen
Vercel Inc. Ja (USA) EU-US Data Privacy Framework (aktiv, Re-Zertifizierung bis 2027-04-29 in Prüfung), SCC als Backup 🟡 DPA offen
Supabase Inc. Verarbeitung in EU (Frankfurt), aber US-Muttergesellschaft Kein regulärer Drittlandtransfer; Rest-Risiko US-Support-Zugriff → über DPA + SCC abzusichern 🟠 DPA offen
Resend / AWS EMEA SARL Verarbeitung in EU (Irland), US-Muttergesellschaften Primär EU-intern; SCC sicherheitshalber, AWS-Subprocessing über Resend-DPA 🟠 DPA offen
Hetzner Online GmbH Nein (Deutschland) Kein Drittlandtransfer Standard-AVV verfügbar

Zusammenfassung: Die eigentlichen Drittland-Übermittlungen (Kapitel V DSGVO) betreffen Twilio, OpenAI, Anthropic und Vercel (USA). Für Supabase und Resend/AWS liegt die Verarbeitung in der EU; das Restrisiko ergibt sich aus den US-Muttergesellschaften (Cloud Act) und wird über DPA und ergänzende Garantien adressiert. Vollständige Begründung: knowledge/04_drittland-transfer.md.

Einheitliche Entity-Bezeichnung beim Ausfüllen beachten — z. B. AWS konsistent als „Amazon Web Services EMEA SARL (Luxemburg), Verarbeitung Region Irland" führen.

Anhang „Subunternehmen" zu § 8

[Formale Liste analog Bundesmuster Seite 13: Name/Anschrift, Datum AVV-Abschluss, Leistungsgegenstand — pro Subprozessor aus Anlage 3. Wird bei Fertigstellung von Anlage 3 automatisch mitbefüllt, um Redundanz zu vermeiden — ggf. Anhang und Anlage 3 zusammenlegen.]

Review-Anhang: Anpassungsentscheidungen und offene Punkte

Dieser Anhang ist nicht Vertragsbestandteil. Er dokumentiert die beim Adaptieren des Bundesmusters getroffenen Entscheidungen und ist vor Anwaltsprüfung zu entfernen.

A. Wesentliche Anpassungen gegenüber dem Bundesmuster

A1. Parteien-Fiktion ersetzt. Bundesmuster geht von „Bundesrepublik Deutschland, vertreten durch [öffentliche Stelle]" als Verantwortlichem aus (Behörden-Kontext). Ersetzt durch den jeweiligen Handwerksbetrieb als Verantwortlichen — Sprek bleibt Auftragsverarbeiter.

A2. § 3 Abs. 10 (Drittlandtransfer) — größte inhaltliche Änderung. Bundesmuster schreibt EU/EWR-Ausschließlichkeit vor. Sprek nutzt strukturell US-Subprozessoren (OpenAI, Anthropic, Twilio, Vercel). Ersetzt durch Verweis auf Anlage 3/4 mit DPF+SCC+TIA-Strategie. Dies ist der Punkt, den der Anwalt zuerst prüfen sollte — er trägt das größte Abweichungsrisiko vom Standard-Muster.

A3. § 3 Abs. 4 (Weisung) — Konstruktion „Standardweisung durch Vertragsschluss". Bundesmuster geht von einzelfallbezogenen Weisungen einer Behörde aus. Bei einem vollautomatisierten SaaS-Workflow ist das unpraktikabel — ergänzt um die Fiktion, dass der vereinbarte Funktionsumfang selbst die Standardweisung darstellt. [ANWALT: juristisch tragfähig?]

A4. § 4 Abs. 3 (DSB-Kontaktdaten) — an offene DSFA-Frage gekoppelt. Statt einer festen Aussage wird auf die laufende DSFA-Schwellwertanalyse verwiesen. Sobald diese final ist, muss dieser Absatz konkretisiert werden (entweder DSB-Kontaktdaten oder endgültige Bestätigung „keine Pflicht").

A5. § 6 (Meldepflicht) verschärft. Bundesmuster sagt nur „umgehend" ohne Frist. Ergänzt um die 24-Stunden-Frist-Empfehlung aus knowledge/08_datenpannen.md sowie die EDSA-Klarstellung „keine eigene Risikobewertung durch den AV".

A6. § 8 (Subunternehmen) — Variante „allgemeine Genehmigung" gewählt, nicht die Variante „Einzelgenehmigung je Subunternehmen". Konsistent mit der bereits in knowledge/03_avv-pflichtinhalte.md getroffenen Empfehlung. 30-Tage-Frist statt der im Muster vorgeschlagenen „vier Wochen" (praktisch identisch, aber einheitlich mit den übrigen Sprek-Dokumenten in Tagen statt Wochen formuliert).

A7. § 9 (Datenschutzkontrolle) abgeschwächt. Bundesmuster setzt einen Datenschutzbeauftragten des Verantwortlichen voraus (Behörden-Standard). Ein Zwei-Personen-Malerbetrieb hat typischerweise keinen DSB — Formulierung auf „soweit vorhanden" umgestellt.

A8. § 11 Abs. 2 (salvatorische Klausel) — Inkonsistenz zum Pilotvertrag bewusst in Kauf genommen, siehe Hinweis direkt im Vertragstext. Der Pilotvertrag verzichtet auf eine salvatorische Klausel, dieser AVV enthält sie (Bundesmuster-Standard). Beide Herangehensweisen sind für sich vertretbar; eine Vereinheitlichung wäre kosmetisch, kein inhaltliches Risiko.

A9. Anker vom Pilotvertrag auf „Hauptvertrag" generisiert (v0.5). Bis v0.4 hing der gesamte Text am Pilotvertrag. Der unentgeltliche Testzugang kennt keinen Pilotvertrag — dort tragen die AGB (§ 1 Abs. 1a, § 5a, § 9 Abs. 2). Die Legaldefinition im Vertragskopf lautet daher „Hauptvertrag"; der Begriff ist an allen Folgestellen mitgezogen (Präambel, § 1 Abs. 1, § 2 Abs. 1, § 7 Abs. 2), damit kein undefinierter Verweis stehenbleibt. Zwei Quellenverweise bleiben beim Pilotvertrag, weil die zitierte Klausel tatsächlich dessen Klausel ist, und sind nur um das AGB-Pendant ergänzt: § 1 Abs. 1 (Abgrenzung eigene Daten → agb.md § 9 Abs. 3) und § 4 Abs. 1 (Vertraulichkeit → agb.md § 9 Abs. 1). Die Testphasen-Fristen selbst stehen in § 1 Abs. 1a lit. a/b, die Löschauslöser in § 7 Abs. 2.

Technische Verankerung (Symbolnamen statt Zeilenverweisen, damit Refactorings sie nicht brechen — die Fristen selbst stehen bewusst ohne Codebezug im Vertragstext, weil der AVV kundensichtbar gerendert wird):

Vertragsaussage Technisches Pendant
§ 1 Abs. 1a lit. a — Fristbeginn „Einrichtung des Zugangs" tenant_configs.config.demo.started_at (api/demo/route.ts)
§ 1 Abs. 1a lit. a — Kontingent „3 Angebotsentwürfe" config.demo.offer_limit / demoLimit() (lib/demo-tenant.ts), durchgesetzt im Demo-Gate
§ 1 Abs. 1a lit. b — „im Zugangscode hinterlegte Anzahl von Tagen" pilot_codes.trial_days (Migration 0044, lib/pilot-codes.ts; 7 oder 30)
§ 7 Abs. 2 lit. b — „keine Umstellung auf ein entgeltliches Abonnement" subscriptionBlocked() (lib/billing.ts)
§ 1 Abs. 1a — Zustimmungsnachweis test_access_consents (Migration 0051), Hash aus lib/legal-documents.ts

Bewusst NICHT mitgezogen — an beiden Stellen hängt [ANWALT]-Substanz, die in eigenem Zug zu klären ist, nicht im Windschatten dieser Ergänzung:

  • § 3 Abs. 4 (Standardweisung) verweist weiter auf den Pilotvertrag. Folge: Die Konstruktion „der vereinbarte Funktionsumfang ist die Standardweisung" ist im Testzugang unverankert — dort gibt es keinen Pilotvertrag, der die Weisung definieren könnte. Die Frage aus A3/C3 wird dadurch dringlicher, weil sie von Individualverhandlung auf Checkbox-Massenakzeptanz skaliert.
  • § 10 (Haftung) verweist weiter auf pilotvertrag.md § 4. Folge: Im Testzugang gilt stattdessen agb.md § 8, dessen Tragfähigkeit im unentgeltlichen Verhältnis selbst [ANWALT]-offen ist (siehe Marker am Ende von agb.md § 5a). Die Haftungsverweisung bleibt im Testzugang also unverankert.

B. Was noch fehlt, bevor dieser AVV unterschriftsreif ist

Anlagen 1–4 sind jetzt inhaltlich gefüllt (v0.4):

  • Anlage 1 verweist auf documents/pipeline-uebersicht.md ✓
  • Anlage 2 verweist auf documents/toms.md ✓
  • Anlage 3 enthält die Subprozessoren-Tabelle (9 Einträge + IONOS-Ausschluss) ✓
  • Anlage 4 enthält die Drittland-Mechanismus-Tabelle ✓

Verbleibende offene Punkte:

  1. DPA-Status mehrerer Subprozessoren noch offen (Anlage 3/4) — Abschluss der einzelnen DPAs ist Voraussetzung der Produktivnutzung, eigenes Arbeitspaket (Asana)
  2. Entity-Klärung OpenAI/Anthropic/Supabase/Resend (USA- vs. EU-Vertragspartner) beim jeweiligen DPA-Abschluss
  3. Haufe-Lexware-Entity in Anlage 3 ergänzen (erst ab Buchhaltungs-Integration relevant)
  4. Anhang Subunternehmen — formale Liste, ggf. mit Anlage 3 zusammengelegt statt dupliziert (kosmetisch)
  5. Konkrete Kontaktadresse für § 4 Abs. 3 und § 6 Abs. 1: datenschutz@sprek.de — eingerichtet (Google Workspace)
  6. Ergebnis der DSFA-Schwellwertanalyse ist in § 4 Abs. 3 eingearbeitet (v0.3); finale Formulierung nach Anwaltsbestätigung
  7. AGB-Zustimmung im Testzugang-Flow fehlt — behoben (v0.6): test_access_consents erhebt seit Commit 70a5370 (17.08.) auch agb als dritten Pflicht-Consent neben datenschutz und avv.
  8. Lösch-Cron für beide Testzugangs-Pfade fehlt (v0.5) — § 7 Abs. 2 sagt eine 30-Tage-Löschung zu, die technisch nicht durchgesetzt ist (loeschkonzept.md Zeilen 16/17 tragen jeweils [TODO]); siehe [OFFEN]- und [ANWALT]-Marker in § 7 Abs. 2

C. Anwaltsfragen aus diesem Dokument — Priorisiert

  1. A2 (Drittlandtransfer-Klausel) — höchste Priorität
  2. § 2 Abs. 4 (Art. 9/Stimm-Biometrie) — durch Recherche 6 geklärt (2026-07-21): keine Art.-9-Verarbeitung, solange Whisper nur zur Transkription eingesetzt wird. Restrisiko gering, Anwalt bestätigt idealerweise die Bewertung, ist aber nicht mehr die offene Kernfrage.
  3. A3 (Standardweisungs-Konstruktion)
  4. Verhältnis der salvatorischen Klausel zum Pilotvertrag (A8, niedrige Priorität, kosmetisch)

D. Konsistenzprüfung (Claude Code, 2. Runde) — behobene Befunde

  • § 4 Abs. 3 (DSB-Framing): Ursprüngliche Formulierung „keine bestätigte Pflicht" klang optimistischer als die eigene DSFA-Schwellwertanalyse (die eine DSFA-/DSB-Pflicht proaktiv annimmt, siehe DSFA Abschnitt 6.2/6.3). Beide Dokumente gehen gemeinsam zum Anwalt und sollten nicht gegenläufig klingen — Formulierung entsprechend synchronisiert.
  • § 6 Abs. 3 (Zitat): Verwies fälschlich auf knowledge/08_datenpannen.md Abschnitt 3 statt Abschnitt 4 — korrigiert.
  • Anlage 4 (AWS-Entity-Bezeichnung): Hinweis ergänzt, bei Ausfüllen die Vertragspartner-Bezeichnung aus dem Vendor-Risk- Register (AWS EMEA SARL, Luxemburg) konsistent zu verwenden, statt verkürzt „AWS SES (EU-Irland)".

E. Versionshistorie

Datum Version Änderung
2026-07-21 0.1 Initial-Adaption aus Bundesmuster Version 2.1; Drittlandtransfer-Klausel (§ 3 Abs. 10) als wichtigste Anpassung; vier Anlagen als Platzhalter angelegt, warten auf zugehörige Einzeldokumente
2026-07-21 0.2 Konsistenzprüfung (Claude Code, read-only, 2. Runde) eingearbeitet: DSB-Framing in § 4 Abs. 3 mit DSFA-Empfehlung synchronisiert; Zitat-Verrutscher in § 6 Abs. 3 korrigiert (Abschnitt 4 statt 3); Hinweis zur einheitlichen AWS-Entity-Bezeichnung in Anlage 4 ergänzt
2026-07-21 0.3 § 2 Abs. 4 (Stimm-Biometrie/Art. 9) mit Ergebnis aus Perplexity-Recherche 6 aktualisiert: keine Art.-9-Verarbeitung, solange Whisper nur zur Transkription eingesetzt wird; Review-Anhang C2 als geklärt markiert; Kopf-Version-Nachtrag (0.1→0.2 war beim letzten Durchgang übersehen worden)
2026-07-27 0.4 Anlagen 1–4 mit echten Inhalten gefüllt (vorher Platzhalter): Anlage 1 → Verweis Pipeline-Übersicht, Anlage 2 → Verweis TOMs, Anlage 3 → Subprozessoren-Tabelle (9 Einträge + IONOS-Ausschluss), Anlage 4 → Drittland-Mechanismus-Tabelle; § 5 Abs. 1 Platzhalter-Hinweis entfernt; Review-Anhang B auf verbleibende Restpunkte reduziert
2026-08-17 0.5 Testzugang im AVV verankert (Anlass: K62 aus der Konsistenzprüfung — agb.md v0.2 § 5a Abs. 8 erklärt den AVV auch bei unentgeltlicher Nutzung zum Vertragsbestandteil und setzt diese Verankerung voraus, während der AVV den Testzugang bis v0.4 nicht kannte). Textvorschlag aus avv-testzugang-analyse.md Abschnitt 5.1–5.3 eingepflegt: Pilotvertrag-Anker durch Legaldefinition „Hauptvertrag" ersetzt (Kopf, Herkunftsblock, Vertragskopf) und an allen Folgestellen mitgezogen (Präambel, § 1 Abs. 1, § 2 Abs. 1, § 7 Abs. 2; § 1 Abs. 1 und § 4 Abs. 1 behalten ihren Pilotvertrag-Quellenverweis und sind nur um das AGB-Pendant ergänzt) — sonst blieben acht Verweise auf ein Dokument stehen, das im Testzugang nicht existiert; neuer § 1 Abs. 1a mit zwei Fristenlogiken (30 Tage ohne Zugangscode, trial_days mit Zugangscode); § 7 Abs. 2 um zwei testzugangsspezifische Löschauslöser plus einheitliche 30-Tage-Löschfrist ergänzt, deckungsgleich mit loeschkonzept.md v0.5 Zeilen 16/17. Abweichungen vom Vorschlag: Bedeutungsumkehr in § 1 Abs. 1a Satz 1 behoben (Vorschlag machte den AVV zu seinem eigenen Hauptvertrag), Datei-/Zeilenverweise aus dem Vertragstext entfernt und als Symbolnamen-Tabelle in Review-Anhang A9 verschoben (vier von fünf waren stale, und der AVV wird kundensichtbar gerendert), Markerform auf [OFFEN:] vereinheitlicht (statt der Mischform [ANWALT/OFFEN:]), Cron-Vorbehalt in § 7 Abs. 2 als ein gemeinsamer Marker für beide Pfade statt asymmetrisch nur für lit. a. § 3 Abs. 4 und § 10 bewusst unverändert ([ANWALT]-Blocker), Folgen in A9 dokumentiert. Offen bleibt: fehlende AGB-Zustimmung im Testzugang-Flow und fehlender Lösch-Cron (Abschnitt B Punkte 7/8)
2026-09-08 0.6 Anlass: Statuscheck vom 08.09. stellte fest, dass SPREK_REQUIRE_AVV_CONSENT aktiv ist (verhaltensgeprüft: 422/400 statt 404 bei fehlenden Consent-Feldern), während dieses Dokument an zwei Stellen weiterhin „nicht scharfgeschaltet" bzw. eine fehlende AGB-Zustimmung im Testzugang behauptete (§ 1 Abs. 1a Folgemarker, Review-Anhang B Punkt 7) — beides überholt, seit demo/consent-checkout (Commit 70a5370, 17.08.) AGB als dritten Pflicht-Consent erhebt. Beide Stellen korrigiert. Aktivierung erfolgte bewusst, trotz weiterhin offener [ANWALT]-Blocker (§ 3 Abs. 4, § 3 Abs. 10, § 4 Abs. 3) — siehe Maßnahmenplan P5-4. Exaktes Umschaltdatum aus dem Repo nicht rekonstruierbar (Env-Var-Änderungen erzeugen keinen Git-Diff); Dokumentationsstand 2026-09-08. Zum Zeitpunkt dieser Änderung 0 Zeilen in test_access_consents — kein bestehender Nachweis betroffen.

Dokument-Hash (SHA-256) dieser Fassung: 9df88cdccb576ea8bc4b848a25638cd1dc57679bc182e87b0743c41f717f6e5a