AVV

1. Parteien, Gegenstand und Dauer

Auftraggeber ist die im Konto bezeichnete Werkstatt; Auftragsverarbeiter ist [FIRMA], [ANSCHRIFT], vertreten durch [VERTRETUNGSBERECHTIGT]. Dieser Mustervertrag ergänzt die Nutzungsvereinbarung nach Art. 28 DSGVO. Gegenstand ist die Speicherung und Verarbeitung personenbezogener Daten zur Erstellung und Bereitstellung von Erklärvideos während des Nutzungsverhältnisses.

[OFFEN: Vollständige Parteienbezeichnung, Vertragsbezug, Weisungskontakte und Beginn bestätigen.]

2. Art, Zweck, Daten und betroffene Personen

Verarbeitung umfasst Upload, Speicherung, Strukturierung, Videoerstellung, synthetische Vertonung, Bereitstellung und Löschung. Datenarten sind Kontaktdaten von Beratenden und Endkunden, Gebäudedaten, iSFP-Inhalte, Fotos sowie Stimm- und Einwilligungsaufnahmen beim Klonen. Betroffene sind Werkstattmitarbeitende, Beratungskunden und auf Aufnahmen erkennbare Personen. Biometrische Daten zur eindeutigen Identifizierung können Art. 9 DSGVO unterliegen; sie dürfen nur mit tragfähiger Rechtsgrundlage, gegebenenfalls ausdrücklicher Einwilligung, verarbeitet werden. Eine Stimmaufnahme ist nicht automatisch eine solche Identifizierungsverarbeitung. [PRÜFEN: Einordnung des konkreten Klonverfahrens, Rechtsgrundlage und gegebenenfalls Datenschutz-Folgenabschätzung.]

3. Weisungen und Pflichten

Wir verarbeiten Daten ausschließlich auf dokumentierte Weisung des Auftraggebers, auch hinsichtlich Übermittlungen in Drittländer, soweit keine gesetzliche Pflicht etwas anderes verlangt. In diesem Fall informieren wir vorab, sofern zulässig. Wir weisen auf aus unserer Sicht rechtswidrige Weisungen hin. Befugte Personen müssen zur Vertraulichkeit verpflichtet sein. Wir unterstützen den Auftraggeber bei Betroffenenrechten, Datenschutzverletzungen, Sicherheitsmaßnahmen und gegebenenfalls Datenschutz-Folgenabschätzungen. Datenschutzverletzungen werden unverzüglich an [E-MAIL] gemeldet. [OFFEN: Meldekanal, verantwortliche Personen und operativen Ablauf verbindlich festlegen.]

4. TOM-Anlage: aus dem Repository überprüfter Stand

• Mandantentrennung: Ressourcen verwenden org_id, explizit scoped Repositories und zusammengesetzte Fremdschlüssel (src/stimmweb/tenancy.py, models.py). RLS-Policies sind in 0002_rls_policies.py und 0003_billing_legal.py vorbereitet. RLS ist im aktuellen Deploymentmodell noch nicht aktiviert und wird daher nicht als aktive Schutzmaßnahme zugesichert.
• Zugriff: Eingeladene Mitgliedschaft, gehashte Einmaltokens und serverseitige Cookie-Sitzungen; mutierende API-Aufrufe benötigen Origin und sitzungsgebundenes CSRF (auth.py). Rollen trennen Bearbeitung und Leserechte.
• Transport: HTTPS ist im produktiven Caddy-Setup vorgesehen; der Demo-Zugang verwendet Tailscale Funnel. Interne lokale Serviceverbindungen sind teilweise HTTP. [PRÜFEN: Tatsächliche TLS-Terminierung, interne Netze und Zertifikatsbetrieb vor Veröffentlichung nachweisen.]
• Schlüssel: Provider- und Sitzungsschlüssel kommen aus Serverumgebung/ADC; Browser erhält sie nicht (providers/secrets.py, auth.py). [OFFEN: Betreiberzugriffe, Rotation, Secret-Store und Schutz ruhender Datenträger dokumentieren.]
• Backups: infra/macmini/backup.py sieht lokale Datenbank- und Dateisicherungen vor; das allein schützt nicht vor Geräteverlust. infra/backup.sh und restore-test.sh bereiten den S3-Betrieb vor. [PRÜFEN: Eingeschalteten Sicherungsplan, externe verschlüsselte Kopie, Aufbewahrung und Wiederherstellungstest bestätigen.]
• Löschung: src/stimmweb/purge.py bereinigt gelöschte Assets nach 30 Tagen und abgelaufene iSFP-Vorschauen; Referenzen auf Einwilligungen/Marken werden berücksichtigt. [OFFEN: Vollständige Kontolöschung, Datenrückgabe, Backup-Löschung und täglichen Wartungslauf verbindlich umsetzen/bestätigen.]
• KI-Grenze für iSFP: Die privaten Felder werden nicht in die explizit zusammengestellten Narrationsnachrichten aufgenommen (backend/src/voiceapp/eb_isfp.py:narration_messages). Die Webgrenze prüft bekannte und neue private Feldwerte vor Provider-Aufrufen (src/stimmweb/providers/policy.py:provider_request, guard_messages). Kundendatenfälle deaktivieren Grounding und Bildsuche; Kundenfotos werden an dieser Grenze abgelehnt. tests/test_isfp_privacy.py prüft diese Grenzen. Pseudonymisierte Gebäudewerte können an das Modell gehen; Freitexte benötigen weiterhin Ihre Prüfung.

[PRÜFEN: Die TOM beschreiben geprüften Code und geplante Betriebsabläufe; technische und organisatorische Wirksamkeit muss der Betreiber vor Einsatz bestätigen.]

5. Unterauftragsverarbeitung

Die Liste der Subunternehmer ist Bestandteil dieses Musters. Der Auftraggeber erteilt eine allgemeine Genehmigung für die nach Prüfung benannten Anbieter. Wir informieren über neue oder ersetzte Unterauftragsverarbeiter und ermöglichen Widerspruch aus sachlichen Datenschutzgründen. Jeder Unterauftrag muss entsprechende Datenschutzpflichten enthalten. [OFFEN: Benachrichtigungskanal, Widerspruchsfrist und Verfahren bei nicht lösbarem Widerspruch festlegen.]

6. Nachweise und Kontrolle

Wir stellen die zum Nachweis von Art. 28 DSGVO erforderlichen Informationen zur Verfügung und ermöglichen angemessene Kontrollen nach Abstimmung, einschließlich erforderlicher Audits. Schutz anderer Mandanten, Vertraulichkeit und Verhältnismäßigkeit werden berücksichtigt. [OFFEN: Ansprechpartner und Prüfverfahren vereinbaren.]

7. Vertragsende

Nach Vertragsende werden personenbezogene Auftragsdaten nach Wahl des Auftraggebers zurückgegeben oder innerhalb von 30 Tagen gelöscht, sofern keine gesetzliche Aufbewahrungspflicht entgegensteht. Bestehende Kopien sind einzubeziehen. [OFFEN: Exportformat, vollständige Löschung einschließlich Sicherungskopien und Nachweisverfahren vor bindender Vereinbarung implementieren.]

Die Annahme erfolgt durch owner oder admin der jeweiligen Werkstatt und wird mit Version und Zeitstempel protokolliert. Diese Annahme ersetzt die notwendige rechtliche und betriebliche Prüfung dieses Entwurfs nicht.