Definition der beiden Optionen
Der Vergleich bezieht sich auf zwei technische Ansätze zur Automatisierung der Ticket-Triage und des monatlichen Reportings in einer Schweizer Kanzlei mit 800 Mitarbeitenden. Option A nutzt kommerzielle Cloud-APIs von OpenAI oder Anthropic, die über HTTPS abgerufen werden. Option B setzt auf Open-Weight-Modelle wie Llama-3 oder Mistral, die auf eigener Hardware im Rechenzentrum der Kanzlei laufen. Beide Ansätze integrieren sich über REST-APIs in Notion und Confluence und folgen dem Prinzip der menschlichen Freigabe. Der entscheidende Unterschied liegt in der Datenhoheit und der Latenz: Bei Option A verlassen die Daten das Gebäude, bei Option B bleiben sie lokal. Für eine Kanzlei, die mit sensiblen Mandatsdaten arbeitet und dem EU AI Act unterliegt, ist diese Unterscheidung nicht nur technisch, sondern regulatorisch relevant.
Kriterien für die Bewertung
- Latenz: Zeit von der Anfrage bis zur Antwort, gemessen in Millisekunden.
- Kostenstruktur: Fixkosten (Hardware, Lizenzen) versus variable Kosten (Token-Abrechnung).
- Datenhoheit: Ort der Datenverarbeitung und Zugriffsmöglichkeiten Dritter.
- Compliance: Erfüllung der Pflichten nach EU AI Act und DSGVO.
- Skalierbarkeit: Verhalten bei Spitzenlasten (z. B. Monatsende-Reporting).
- Wartungsaufwand: Aufwand für Updates, Monitoring und Fehlerbehebung.
- Integrationstiefe: Qualität der Anbindung an Notion und Confluence.
- Qualität der Ausgabe: Genauigkeit der Klassifikation und Vollständigkeit der Report-Entwürfe.
Vergleichstabelle
| Kriterium | Option A: Cloud-APIs | Option B: On-Premise |
|---|---|---|
| Latenz | 300–800 ms (inkl. Netzwerk) | 100–200 ms (lokal) |
| Kosten | 0,002–0,03 CHF/Token, variabel | 15.000–30.000 CHF einmalig, 500–1.000 CHF/Monat |
| Datenhoheit | Daten verlassen das Gebäude | Daten bleiben im Rechenzentrum |
| Compliance | Erfordert Datenverarbeitungsvertrag (DPA) | Kein DPA nötig, volle Kontrolle |
| Skalierbarkeit | Automatisch durch Cloud-Anbieter | Begrenzt durch lokale GPU-Ressourcen |
| Wartung | Keine eigene Hardware-Wartung | Eigenes Monitoring, Updates manuell |
| Integration | Standard-REST-APIs | Standard-REST-APIs, lokale Endpunkte |
| Qualität | Sehr hoch bei komplexen Aufgaben | Hoch bei Klassifikation, mittelmäßig bei kreativen Texten |
Szenario-spezifisches Verdikt
Option A gewinnt, wenn die Kanzlei keine eigene IT-Infrastruktur für KI betreiben möchte und die Ticketmengen gering sind (unter 50 pro Tag). In diesem Fall sind die variablen Kosten überschaubar, und die Wartung entfällt. Option B gewinnt, wenn die Datenhoheit eine harte Anforderung ist, wie es bei Mandatsdaten in der Schweiz üblich ist. Zudem ist Option B bei hoher Auslastung (über 100 Tickets pro Tag) kostengünstiger, da die Token-Kosten der Cloud-Lösung exponentiell steigen. Für das monatliche Reporting, das große Datenmengen verarbeitet, ist Option B stabiler, da es keine Drosselung durch den Cloud-Anbieter gibt. In der Praxis wird Option B für die Kernprozesse (Triage, Reporting) und Option A für sporadische, komplexe Anfragen empfohlen.
Empfehlung
Für die Schweizer Kanzlei mit 800 Mitarbeitenden, die Ticket-Triage und monatliches Reporting automatisieren möchte, ist Option B (On-Premise) die empfohlene Lösung. Die Gründe: Erstens bleibt die Datenhoheit vollständig beim Unternehmen, was die Compliance mit dem EU AI Act und der DSGVO vereinfacht. Zweitens ist die Latenz niedriger, was die Benutzererfahrung verbessert. Drittens sind die Kosten bei der erwarteten Auslastung (ca. 200 Tickets pro Tag) nach 18 Monaten niedriger als bei Cloud-APIs. Der vierwöchige Pilot sollte mit Option B starten, um die Infrastruktur zu validieren. Ein Audit vor dem Piloten ist essenziell, um die genaue Ticketmengen und die Integration in Notion/Confluence zu planen. Die menschliche Freigabe bleibt in beiden Optionen bestehen, da sie eine regulatorische Anforderung ist.
Leave a Reply