Zwei Architekturen für E-Commerce-Support: On-Premise vs. Cloud-API
Für ein E-Commerce-Unternehmen mit 51–200 Mitarbeitern in Deutschland, das PCI-DSS-konformen Support und interne Wissenssuche automatisieren will, stehen zwei Architekturen zur Verfügung: Open-Weight-Modelle auf eigener Hardware (z. B. Llama 3 70B, Mistral Large 123B) und Cloud-APIs (OpenAI GPT-4o, Anthropic Claude 3.5 Sonnet). Die Entscheidung ist nicht nur technisch, sondern auch compliance-getrieben. Bei PCI-DSS v4.0 (Abschnitt 3.3.1) dürfen sensible Kartendaten nicht an Dritte übertragen werden, was die Cloud-API für bestimmte Workflows ausschließt. Gleichzeitig muss der Support mehrsprachig funktionieren und innerhalb von 14 Tagen als Fixed-Scope-Pilot geliefert werden. Die folgende Analyse vergleicht beide Optionen anhand konkreter Kriterien, um eine fundierte Empfehlung für den Rollout zu geben.
Kriterien für den Vergleich
Die Bewertung stützt sich auf acht Kriterien, die für den beschriebenen Use Case relevant sind:
- PCI-DSS-Compliance: Kann das Modell sensible Kartendaten verarbeiten, ohne sie an Dritte zu übermitteln?
- Latenz: Time-to-First-Token (TTFT) und Gesamtdurchlaufzeit für den Conversational Agent.
- Kostenstruktur: Fixkosten (Hardware) vs. variable Kosten (API-Tokens) bei 50 Anfragen pro Minute.
- Mehrsprachigkeit: Qualität der Antworten in Deutsch, Englisch, Französisch und Spanisch.
- Integration: Aufwand für REST-API und Webhooks in bestehende CRM- und Helpdesk-Systeme.
- Vendor Lock-in: Abhängigkeit von einem einzelnen Anbieter und Migrationsspielraum.
- Skalierbarkeit: Verhalten bei Lastspitzen (z. B. Black Friday) ohne zusätzliche Hardware.
- Wartungsaufwand: Update-Zyklen, Monitoring und Fehlerbehebung im Betrieb.
Vergleichstabelle: Konkrete Werte
| Kriterium | On-Premise (Open-Weight) | Cloud-API (OpenAI/Anthropic) |
|---|---|---|
| PCI-DSS-Compliance | Vollständig: Daten bleiben im eigenen Netzwerk, keine externe Übertragung. Audit-Trails lokal. | Eingeschränkt: Daten verlassen das Netzwerk. Anbieter muss im PCI-DSS-ROC aufgeführt sein. |
| Latenz (TTFT) | 150–400 ms (A100), 50–100 ms/Token. Gesamtdurchlauf: 800–1.200 ms. | 200–500 ms, 30–80 ms/Token. Gesamtdurchlauf: 1.000–1.500 ms. |
| Kosten (50 Anfr./Min.) | Hardware: 40.000–80.000 EUR (A100). Strom: ca. 0,30 EUR/kWh. Amortisation: 14 Monate. | 0,002–0,005 EUR/1.000 Tokens. Bei 50 Anfr./Min.: ca. 1.500–3.000 EUR/Monat. |
| Mehrsprachigkeit | Gut für DE, EN. Mittel für FR, ES. Fallback auf Cloud-API möglich. | Sehr gut für alle großen Sprachen. Konsistente Qualität. |
| Integration | REST-API via vLLM/TGI. Webhooks über eigenen Gateway. Aufwand: 4 Tage. | REST-API direkt. Webhooks über Anbieter. Aufwand: 2 Tage. |
| Vendor Lock-in | Gering: Modell- und Hardware-Wechsel möglich. | Hoch: API-Änderungen, Preisanpassungen, Deprecation. |
| Skalierbarkeit | Begrenzt durch Hardware. Black-Friday-Spitzen erfordern zusätzliche GPUs. | Elastisch: Automatische Skalierung, keine Hardware-Investition. |
| Wartungsaufwand | Hoch: GPU-Monitoring, Modell-Updates, vLLM-Patches. | Gering: API-Updates transparent, kein Hardware-Wartung. |
Szenario 1: Interne Wissenssuche und Dokumenten-Extraktion
Für die interne Wissenssuche (RAG über Firmen-Doku und CRM-Records) gewinnt das On-Premise-Modell. Die Daten sind sensibel (Kundendaten, interne Prozesse), und die PCI-DSS-Anforderungen erlauben keine externe Übertragung. Die Latenz von 800–1.200 ms ist für interne Nutzer akzeptabel. Die Kosten amortisieren sich nach 14 Monaten, was für einen Pilot mit 14 Tagen und anschließendem Rollout wirtschaftlich sinnvoll ist. Die Integration über REST-API und Webhooks in das bestehende CRM (z. B. Salesforce, HubSpot) ist in 4 Tagen umsetzbar.
Für den Conversational Agent im Customer Support ist die Entscheidung differenzierter. Bei rein deutschen Anfragen und begrenztem Volumen (unter 100 Anfragen/Minute) reicht das On-Premise-Modell. Bei mehrsprachigem Support (DE, EN, FR, ES) und Lastspitzen (Black Friday, Cyber Monday) ist die Cloud-API überlegen. Die Qualität der Antworten in Französisch und Spanisch ist bei GPT-4o und Claude 3.5 Sonnet konsistenter. Die elastische Skalierung verhindert, dass bei 500 Anfragen/Minute die Antwortzeiten auf über 3 Sekunden steigen.
Szenario 2: Mehrsprachiger Support und Lastspitzen
Für die Dokumenten-Extraktion (Rechnungen, Lieferscheine, Retourenformulare) ist die Cloud-API präziser. Modelle wie GPT-4o sind auf großen, kuratierten Datensätzen trainiert und erkennen unstrukturierte Formate (Handschrift, gescannte PDFs) zuverlässiger. Die Fehlerquote liegt bei 2–5 % gegenüber 8–12 % bei Open-Weight-Modellen. Da die extrahierten Daten (Kundenname, Adresse, Artikelnummer) nicht sensibel im PCI-DSS-Sinn sind, ist die Cloud-API hier die bessere Wahl. Die Integration über REST-API und Webhooks in das ERP (z. B. SAP, Shopify) ist in 2 Tagen umsetzbar.
Für den mehrspachigen Support mit 51–200 Mitarbeitern und internationalen Kunden ist die Cloud-API die robustere Lösung. Die Qualität der Antworten in Französisch und Spanisch ist bei OpenAI und Anthropic konsistenter. Die elastische Skalierung verhindert, dass bei Lastspitzen die Antwortzeiten auf über 3 Sekunden steigen. Die Kosten von 1.500–3.000 EUR/Monat sind für ein Unternehmen dieser Größe akzeptabel. Der Vendor Lock-in ist ein Risiko, aber durch die Architektur mit Fallback auf On-Premise-Modelle abfederbar.
Empfehlung: Hybride Architektur für den 14-Tage-Pilot
Die Empfehlung ist eine hybride Architektur mit klarem Routing: On-Premise-Modelle für interne Wissenssuche und PCI-DSS-sensible Daten, Cloud-APIs für Dokumenten-Extraktion und mehrsprachigen Support. Der Fixed-Scope-Pilot für 14 Tage umfasst: 1) Prozess-Audit der Support- und Dokumenten-Workflows (3 Tage), 2) Setup der On-Premise-Infrastruktur mit vLLM (2 Tage), 3) Integration der REST-APIs und Webhooks (4 Tage), 4) Training und Validierung des RAG-Systems (5 Tage), 5) Messung der Baseline und des After-States (2 Tage). Die Lieferung erfolgt mit einem Report zu Zykluszeit, Fehlerquote und ROI-Projektion. Die Human-in-the-Loop-Komponente bleibt erhalten: Alles, was Geld, Gesundheitsdaten oder Verträge betrifft, wird von einer Person freigegeben. Die Architektur ist model-agnostic, sodass bei Bedarf auf andere Modelle umgestellt werden kann, ohne die Integration zu ändern.
Leave a Reply