Trust-Boundary in BTP CAP-Apps mit AI – Anthropic als externe Zone
Wenn Ihre CAP-App Claude über die Anthropic-API ruft, verlässt jede Anfrage Ihre BTP-Vertrauenszone. Was das für Architektur, Audit-Log und Datenschutz-Folgenabschätzung bedeutet – und wo die DLP-Linie wirklich zieht.
Die Frage, die im Architektur-Review immer kommt
Sobald ein BTP-Architekt sieht, dass eine CAP-App Anthropic Claude ruft, kommt sie: „Wo ist die Trust-Boundary, und was passiert über sie hinweg?“ Diese Einordnung beantwortet die Frage in der Sprache, die SAP-Architekten sprechen – Subaccount, Space, Destination, Audit Log.
mermaid
flowchart LR
subgraph BTP["BTP Subaccount (Trust-Zone)"]
AR[Approuter]
CAP[CAP Backend<br/>@sap/cds]
DEST[Destination Service<br/>Claude-API-URL + Key]
AUDIT[Audit Log Service<br/>7-Jahre-Retention]
end
subgraph EXT["Externe Zone"]
CL[Anthropic Claude API]
end
USER[User] -->|JWT| AR
AR --> CAP
CAP -->|Destination-Lookup| DEST
DEST -.->|TLS 1.3 + API-Key| CL
CAP -->|Request + Response Hash| AUDIT
style BTP fill:#dbeafe,stroke:#1e40af
style EXT fill:#fef3c7,stroke:#d97706
Zwei Architekturen, zwei Trust-Geometrien
Architektur A – Direct-Call: CAP-Service ruft Claude direkt aus dem App-Code mit dem @anthropic-ai/sdk. API-Key liegt in einer User-provided Service-Instanz oder im BTP Credential Store.
Vorteil: einfach, schnell. Nachteil: jeder Entwickler, der den Code liest, sieht den Aufruf-Pfad. Audit-Log-Pflicht wird schnell vergessen.
Architektur B – Destination-Service-Wrapper: Claude-API ist als Destination konfiguriert. Der API-Key liegt in der Destination-Konfiguration, der CAP-Service ruft via @sap-cloud-sdk/connectivity und executeHttpRequest.
Vorteil: Audit-Spur durch BTP-Telemetrie, Key-Rotation zentralisiert, Mandantentrennung sauber. Nachteil: ein Layer mehr Code.
SFOUR-Empfehlung: Architektur B. Der eine Layer mehr zahlt sich beim ersten DPO-Review zurück.
Was über die Trust-Boundary geht
Pro Anthropic-Call verlassen folgende Daten Ihre BTP-Zone: - System-Prompt (sofern verwendet) – meistens fix, kein PII - User-Message – hier liegt das Risiko, wenn der CAP-Service unkontrolliert PRD-Daten reinpackt - Tool-Results (bei Tool-Calls) – Output von CAP-Actions, kann PII enthalten - Anthropic Response – kommt mit Token-Usage und Stop-Reason zurück
Was muss vorher anonymisiert sein? Per Default alles was an User-Message-Position rutscht. Architektur-Pattern: ein cleanForAI()-Aspekt im CAP-Service der vor jedem Call durchgegangen wird, mit @sap/cds-Aspekten als technische Durchsetzung.
Was bei Anthropic verbleibt
Anthropic's Datenrichtlinie (Stand 2026) sagt: API-Calls werden 30 Tage zur Abuse-Erkennung gespeichert, danach gelöscht. Modell-Training nur opt-in. Aber: das ist Anthropic's Aussage, nicht Ihre Garantie. Für die DSFA müssen Sie: 1. Den Auftragsverarbeitungsvertrag (AVV) mit Anthropic abschliessen lassen 2. Im Datenfluss-Diagramm Anthropic als externen Empfänger ausweisen 3. Die Rechtsgrundlage (Art. 6 GDPR) für jede Daten-Kategorie dokumentieren
Audit-Log-Pflicht
Jeder Call zur externen Zone braucht einen Audit-Log-Eintrag mit: - Zeitstempel - Aufrufender User (JWT-Subject) - Hash des System-Prompts (nicht der Inhalt!) - Hash + Länge der User-Message - Token-Usage Response - Status (success / error / blocked-by-DLP)
Der BTP Audit Log Service speichert das mit 7-Jahre-Retention. Wer das überspringt, hat im DPO-Review keine Antwort auf „wer hat wann welche Daten an Claude geschickt?“.
Die DLP-Schicht, die niemand mag
Empfohlen: ein DLP-Hook im CAP-Service, der vor dem Anthropic-Call den User-Message-String scannt. Bei Match auf Regex-Pattern für GLN, VAT, oder Free-Text-PII: Block + Alert. Implementierung 200 Zeilen TypeScript, Wartung gering.
Der Hook fängt was Anonymisierung übersehen hat – ein Sicherheitsnetz, kein Ersatz.
Wer Klarheit will
Ein Architektur-Review (30 Min) prüft Ihren konkreten Trust-Boundary-Schnitt: Destination-Pattern, Audit-Coverage, DLP-Hook. Wir liefern eine Zwei-Seiten-Auswertung mit präzisen Action-Items, keine Folien-Schau.
Stand: 2026-06-25
