FACT COPY · DE
Faktenfassung: Reisedaten, Identität, Datenschutz und Payment
Schutzbedarf, Zweckbindung, Delegation und Zahlungsgrenzen in MCP-basierten Reisesystemen.
Originalseite: https://travel-mcp.com/de/reisebranche/daten-identitaet-payment/
Sachliche Zusammenfassung
Reiseprozesse verbinden Identitätsdaten, Bewegungsdaten, Präferenzen, Dokumente und Zahlung. Diese Kombination erlaubt weitreichende Rückschlüsse und verlangt eine Architektur, die Datenminimierung und Fachrechte technisch durchsetzt.
Datenklassen im Reiseprozess
Kontaktdaten, Geburtsdatum, Reisedokumente, Loyalitätsnummern, besondere Unterstützungsbedarfe und Reiseverlauf besitzen unterschiedlichen Schutzbedarf. Nicht jede Information darf automatisch in den Modellkontext gelangen, nur weil ein Backend sie liefert.
Der MCP-Server sollte Felder nach Capability und Zweck selektieren. Ressourcen mit Kundendaten benötigen dieselbe Objektberechtigung wie Tools; eine schwer erratbare URI ist kein Zugriffsschutz.
Zweckbindung und Datenminimierung
Die DSGVO verlangt unter anderem Zweckbindung und Datenminimierung. Für MCP bedeutet das: Ein Tool zur Dokumentensuche benötigt nicht automatisch das vollständige Kundenprofil; eine Hotelanfrage benötigt nicht zwingend Passdaten. Der Capability-Vertrag dokumentiert, welche Daten warum verarbeitet und wie lange sie in Logs oder Sitzungen gehalten werden.
Prompts, Toolbeschreibungen und Telemetrie können ebenfalls personenbezogene Daten enthalten. Redaction und Löschregeln müssen deshalb den gesamten Ablauf umfassen, nicht nur die Backendantwort.
Identität, Delegation und Objektzugriff
Authentifizierung beantwortet, wer zugreift; Autorisierung entscheidet, welche Buchung, welcher Mandant und welche Aktion zulässig sind. Reisebüromitarbeitende, Endkunden, Veranstalter und Dienstleister besitzen unterschiedliche Delegationsketten.
Der Server prüft Objektbeziehung und fachliche Rolle bei jedem Aufruf. Ein gültiger OAuth-Token mit allgemeinem Scope darf keine fremde Buchung öffnen. Für Supportzugriffe sind Begründung, zeitliche Begrenzung und Audit sinnvoll.
Payment aus dem Modellkontext heraushalten
PCI DSS richtet sich an Organisationen, die Zahlungsdaten speichern, verarbeiten, übertragen oder die Karteninhaberdatenumgebung beeinflussen können. Ein MCP-Design sollte den Scope minimieren: tokenisierte Zahlungsreferenzen und gehostete Zahlungsflüsse sind direkten Kartendaten im Modellkontext vorzuziehen.
Ein Payment-Tool erhält Betrag, Währung, Orderreferenz und zulässige Zahlungsreferenz. Es darf weder aus Modelltext Kartendaten extrahieren noch Beträge frei bestimmen. Zahlungsautorisierung, Capture, Refund und Statusabfrage sind getrennte Fähigkeiten mit eigenen Rechten.
Audit ohne Datenschatten
Audit muss beantworten, wer welche Capability für welches Objekt mit welchem Ergebnis genutzt hat. Dafür sind nicht zwangsläufig vollständige Prompts oder Dokumentinhalte nötig. Hashes, Referenzen, strukturierte Entscheidungen und Redaction reduzieren den zusätzlichen Datenschatten.
Aufbewahrung folgt rechtlichen und betrieblichen Zwecken. Security-Telemetrie, fachliche Buchungshistorie und Modellbeobachtung besitzen unterschiedliche Fristen und Zugriffsgruppen.
- Minimale Tool-Eingaben
- Feldbasierte Ausgabefilter
- Objektberechtigung
- Tokenisierte Zahlungsreferenzen
- Redigierte und zweckgebundene Logs
FAQ
Dürfen Passdaten an ein Sprachmodell gesendet werden?
Nur wenn dies für den konkreten Zweck erforderlich, rechtlich zulässig und durch den gewählten Betrieb sowie Vertrag abgesichert ist. Häufig kann der Fachserver die Daten verarbeiten, ohne sie dem Modell offenzulegen.
Reicht PCI-konformes Payment für das Gesamtsystem?
Nein. PCI DSS adressiert Zahlungsdaten; Datenschutz, Identität, Fachrechte und MCP-spezifische Risiken bleiben zusätzlich relevant.