Vertragsunterlagen

1. Freigegebener Informationspilot

Verantwortlicher, Kunden-/Angebotsreferenz, freigegebene Websites, Agenten und Wissensquellen sind im individuellen Vertrag zu benennen. Zweck ist die Beantwortung von Unternehmensfragen aus freigegebenem Wissen und die vereinbarte Verwaltung der Gespräche.

Betroffene Personen können Websitebesucher, Interessenten sowie Personen sein, deren Angaben rechtmäßig in den freigegebenen Quellen stehen. Daten umfassen Fragen und Antworten, erkannte Kontakt-/Adressmuster, bereitgestellte Quellenauszüge, Sitzungskennungen, tokenisierte Ablaufdaten und notwendige technische Metadaten. Nicht erkannte Namen oder andere Angaben können in Freitext enthalten bleiben.

Gesundheitsdaten, strafrechtliche Daten, aktive Termin-/Lead-Prozesse und weitere besondere Verarbeitung sind im Informationspilot nicht freigegeben. Eine Erweiterung benötigt einen ausdrücklich geprüften Auftragsumfang.

2. Kundenspezifische Fristen festlegen

Die wirksamen Kundenfristen müssen vor Produktionsbeginn in Vertrag und Retention-Policy übereinstimmen. Entwicklungswerte sind keine Kundenvereinbarung. Im aktuellen Schema beträgt die Gesprächsvorgabe 90 Tage; der Kunde kann im vorgesehenen Bereich von 30 bis 365 Tagen eine tatsächlich vereinbarte Frist festlegen.

PII-Mappings werden spätestens mit den zugehörigen Gesprächsinhalten bereinigt. Die Feldmatrix umfasst auch Zustände, Zusammenfassungen, Nachrichtenteile, Zitate, Trace-Freitexte und Feedbackkommentare. Verbleibende Kennungen und Kennzahlen sind nicht automatisch anonyme Daten.

Für Wissensquellen und Originaldateien, Kundendokumente, verbleibende Kennzahlen, Vorgangs-/Auditdaten und nutzungsbezogene Nachweise sind Zweck, Löschereignis und erforderliche Frist gesondert festzulegen. Das Schema enthält Audit-Vorgaben von 12 Monaten und Usage-Vorgaben von 36 Monaten; ihre Anwendung benötigt den überprüften Vertrags- und Betriebsstand.

Wissensquellenlöschung umfasst ihre Textabschnitte, Embeddings, Suchprojektionen und zugehörigen Caches. Die Gesprächsbereinigung ist ein gesonderter Vorgang. Nicht zugeordnete weitere Besuche und CRM-/Terminbestände dürfen bei einer Betroffenenanfrage nicht still übergangen werden.

3. Rückgabe und Sicherungsfristen

Vor Freigabe auszufüllen: Exportformat und Kontaktweg, Rückgabe-/Löschfrist bei Vertragsende, Backup- und WAL-Aufbewahrung, Objektversionen, Zugriffsschutz, Standorte sowie Ablauf der letzten betroffenen Sicherung. Der tatsächliche Betriebsablauf muss diese Angaben erfüllen.

Unabhängige Löschvermerke werden solange geschützt aufbewahrt, wie ein älteres einschlägiges Backup noch wiederhergestellt werden könnte. Aufbewahrung und spätere Löschung dieser Vermerke sind ebenfalls festzulegen. Eine mit dem Mapping gesicherte Schlüsselhülle erlaubt weiterhin die Entschlüsselung; ein Live-DELETE allein beweist keine Krypto-Löschung.

1. Zugang und Mandantentrennung

Lokaler Prüfstand: Dashboard-Anmeldung über Auth0, serverseitige Sitzungsprüfung, Owner-/Staff-Berechtigungen, Origin-Prüfung bei Änderungen und Entzug widerrufener Sitzungen. Tenant-Zuordnung stammt aus geprüfter Sitzung oder Widget-Token; Geschäftsdatenzugriffe verwenden Transaktionen mit FORCE Row Level Security.

Vor Produktionsbeginn nachzuweisen: tatsächliche produktive Auth0-Anwendung, MFA-/Betreiberverfahren, Benutzerzuordnungen, getrennte Laufzeit-/Migrationsrollen, Netzwerk-/Storage-Isolation, Secret-Verwaltung und Notfallzugang. Die lokale Superuser-Migrationsrolle ist kein produktives Rollenmodell.

2. Verschlüsselung und Datenminimierung

Lokaler Prüfstand: erkannte E-Mail-, Telefon-, IBAN- und bestimmte Adressmuster werden vor Modellaufrufen tokenisiert; Mappings liegen im AES-256-GCM-Umschlagverfahren. Schlüssel gelangen nicht in Agent-Konfiguration, Export oder Protokoll. Originalfragen und Antworten werden serverseitig gespeichert; die Mustererkennung erfasst nicht jeden Personenbezug.

Vor Produktionsbeginn nachzuweisen: TLS, Daten-/Backup-Verschlüsselung im eingesetzten Hosting, Schlüsselzugriff und Rotation, Modell-/Logging-Einstellungen und tatsächliche Datenwege. Ein EU-Endpunkt oder lokale Tokenisierung beweist für sich keine vollständige Datenschutzkonformität.

3. Aufbewahrung, Rechtebearbeitung und Wiederherstellung

Lokaler Prüfstand: Quellenvollständigkeits-Gegenproben, Gesprächsfristen mit Schutz gegen verspätete Schreibvorgänge sowie Owner-Verfahren für Auskunft, gezielte Berichtigung und bestätigte Besucherlöschungen. Unabhängiges lokales Löschjournal und echte Dump-/Restore-Gegenproben sind vorhanden.

Vor Produktionsbeginn nachzuweisen: aktivierte vollständige Fristenjobs, Alarmierung, übrige Datenkategorien, externer unabhängiger Journal-Speicher, tatsächliche Backup-/WAL-/Objektfristen, getrennte Sollstand-/Schlüssel-Aufbewahrung und kontrollierte Restore-Freigabe. Die lokale Implementierung ist keine Abnahme dieses Betriebs.

4. Kontrolle und Verfügbarkeit

Lokaler Prüfstand: automatisierte Rollen-/RLS-/Origin-/Widerrufsprüfungen, eingeschränkte Protokollierung, Eval-/Veröffentlichungsriegel und geprüfte Artefakte. Produktive Provisorien und ungeprüfte Modellbindungen bleiben gesperrt.

Vor Produktionsbeginn nachzuweisen: tatsächliche Wartungs-/Updateverfahren, Zuständigkeiten, Erreichbarkeit bei Vorfällen, Schwachstellenbearbeitung, regelmäßige Restore-Übung mit RPO/RTO, Kosten- und Sicherheitsalarme sowie belastbare Budgetreservierung und Anbieterabbruch.

1. Verbindliches Register vor Einsatz

Für jeden tatsächlich eingesetzten weiteren Auftragsverarbeiter festzuhalten: vollständige juristische Person und Anschrift, Aufgabe, Datenkategorien, Verarbeitungs-/Zugriffsländer, beauftragte Region, Vertrags-/Genehmigungsstand, Logging-/Aufbewahrungsregeln und gegebenenfalls Übermittlungsgrundlage. Erst die ausgefüllte und genehmigte Liste benennt beauftragte Dienstleister.

Hosting, PostgreSQL, Redis, Upload-/Objektstorage und Backup-/Journal-Speicher: Betreiber, Standorte und Verträge sind vor dem Produktivstart einzutragen. Technische Komponenten sind keine eigenständigen Vertragspartner.

2. Chat und Embeddings

Der Code unterstützt Azure- und Bedrock-Modellanbindungen. Für die tatsächlich ausgewählten Bindungen sind Anbieter-Rechtsträger, Modell-/Deployment-/Profilreferenzen, Verarbeitungsländer, providerseitiges Logging, Speicherfristen und Vertragsgrundlagen einzutragen. Eine unterstützte Anbindung ist noch keine genehmigte Beauftragung.

MSA DataX verwendet Auftragsdaten ausschließlich für die vereinbarte Kundenleistung und nicht für eigene Trainingszwecke. Vor Einsatz sind Anbieterbedingungen und Einstellungen nachzuweisen, die eine Verwendung der Auftragsdaten für eigene Trainingszwecke des Anbieters ausschließen.

3. Anmeldung und übrige Dienstleister

Auth0 ist für die Dashboard-Identitätsprüfung eingerichtet; die lokale Konfiguration nutzt einen EU-Tenant. Vor Produktionsbeginn sind der konkrete Okta-/Auth0-Vertragspartner, Vertrag, Unterauftragnehmer, Datenresidenz und mögliche Zugriffsländer nachzuweisen.

Dashboard-Konto-/Sicherheitsverarbeitung und die Verarbeitung von Websitebesucherdaten sind anhand ihrer tatsächlichen Zwecke abzugrenzen. Auth0 wird nicht allein wegen einer bestehenden Anmeldung als Empfänger von Besuchergesprächen ausgewiesen. Weitere Support-, Kommunikations- oder Signaturdienste werden bei tatsächlichem Einsatz ergänzt.

1. Individuelles Angebot ergänzen

Angebots-/Vertragsreferenz: ____________________. Vollständiger Kunden-Vertragspartner und Anschrift: ____________________. Vertretungsberechtigte Person und Funktion: ____________________. Status als Unternehmer: ____________________.

Vereinbarter Leistungsumfang, Websites und Datenquellen: ____________________. Beginn, Laufzeit und Kündigungsfrist: ____________________. Vergütung, Umsatzsteuer, Abrechnung und Fälligkeit: ____________________. Nutzungslimits, Mehrverbrauch und dessen Preise: ____________________. Support-/Kontaktweg und vereinbarte Verfügbarkeit: ____________________.

2. Dokumente und Betriebsanlagen

Die tatsächlich vereinbarten Dokumente mit Kennung, Version und SHA-256 aus dem beiliegenden Manifest aufführen. Vollständige Textfassungen gemeinsam mit dem Angebot archivieren; eine aktuelle URL allein ist kein unveränderlicher Nachweis.

Die kundenspezifische Verarbeitung-/Fristenanlage, genehmigte Dienstleister/Orte, TOM-Betriebsnachweise und Weisungskontakte ausfüllen. Das vorliegende Entwurfspaket darf nicht als bereits freigegebener Vertragsbestand übernommen werden.

3. Bewusste Vereinbarung dokumentieren

Art und Datum der Annahme, Identität/Funktion des vertretungsberechtigten Kundenvertreters und dessen ausdrückliche Erklärung dokumentieren: ____________________. Betreiber-Bestätigung und Referenz auf den gespeicherten Nachweis: ____________________. Gegebenenfalls dokumentierte abweichende Individualvereinbarungen: ____________________.

Angebot, vereinbarte Dokumentfassungen, ausgefüllte Anlagen und tatsächlichen Annahmenachweis zusammen geschützt aufbewahren. Auftrag und Kundenfreigabe werden vom Betreiber getrennt abgeglichen. Download oder Dashboard-Login füllen diese Nachweise nicht automatisch aus.