Lokales LLM vs. öffentliche API für sensible Excel-Daten: Die richtige Wahl

Die Debatte über lokale LLMs versus öffentliche KI-APIs wird oft zu vereinfacht geführt.

Die eine Seite fordert, dass jedes Unternehmen Modelle lokal betreiben sollte. Die andere Seite behauptet, dass Enterprise-KI-APIs sicher genug und wesentlich einfacher zu handhaben seien.

Für sensible Excel-Daten ist die Antwort praxisorientierter: Die Architektur muss zur Sensibilität der Tabelle, zur Reife Ihrer Sicherheitsprozesse und zum tatsächlichen Workflow der Endnutzer passen.

Eine öffentliche API, ein Enterprise-KI-Dienst, ein lokales Modell, ein privates VPC-Deployment oder ein hybrider Redaktions-Workflow – jede dieser Optionen kann je nach Situation die richtige sein.

Warum Excel-Daten besondere Sorgfalt erfordern

Tabellenkalkulationen werden oft unterschätzt.

Sie enthalten häufig genau die Daten, die es nie in ein kontrolliertes BI-System geschafft haben:

• Umsätze auf Kundenebene
• Gehälter und Provisionen
• Prognosen
• Budgets
• Zahlen für das Board-Reporting
• Konditionen von Lieferanten
• Support-Exporte
• Steuerunterlagen
• Operative Ausnahmefälle
• Personenbezogene Daten (PII)

Wenn ein Mitarbeiter eine solche Datei in einen Chatbot hochlädt, verliert das Unternehmen unter Umständen die Kontrolle darüber, wohin die Daten fließen, wie lange sie gespeichert werden, wer darauf zugreifen kann und ob die Aktion den internen Richtlinien entspricht.

Das Risiko ist nicht nur technischer Natur, sondern auch prozessual. Die meisten Excel-Uploads finden außerhalb der normalen Data-Governance-Pfade statt.

Die fünf wichtigsten Optionen

1. Öffentlicher Chatbot

Dies ist der einfachste Weg. Ein Nutzer öffnet einen Chatbot, lädt eine Datei hoch und bittet um eine Analyse.

Für öffentliche oder synthetische Daten ist das völlig in Ordnung. Bei vertraulichen Dateien ist es riskant, sofern das Unternehmen das Tool und den Anwendungsfall nicht explizit genehmigt hat.

Der Hauptvorteil ist die Geschwindigkeit. Das Hauptrisiko ist die unkontrollierte Offenlegung von Daten.

2. Öffentliche API

Eine öffentliche API bietet Entwicklern mehr Kontrolle als ein Consumer-Chatbot. Sie können eine interne App bauen, die Datenmenge begrenzen und Prompts präziser steuern.

Dennoch verlassen die Daten die Umgebung des Unternehmens. Die Bedingungen des Anbieters bezüglich Datennutzung, Aufbewahrung, Protokollierung und Compliance sind hier entscheidend.

Für viele Unternehmen ist dies nach einer Prüfung des Anbieters und mit dem richtigen Vertrag eine gangbare Lösung. Es sollte jedoch nicht automatisch als sicher eingestuft werden.

3. Enterprise-KI-Dienst

Enterprise-KI-Plattformen bieten oft strengere Datenschutzzusagen, Administrationskontrollen, Verschlüsselung, Verzicht auf Training mit Kundendaten, Aufbewahrungsoptionen und Compliance-Dokumentationen.

Beispiele sind die Enterprise-Angebote von OpenAI, Microsoft Azure OpenAI, AWS Bedrock, Google Vertex AI, Anthropic und anderen.

Dies ist oft der goldene Mittelweg für Unternehmen, die eine hohe Modellqualität wünschen, ohne eine eigene GPU-Infrastruktur betreiben zu müssen.

Der Kompromiss besteht darin, dass die Verarbeitung weiterhin außerhalb der eigenen Server stattfindet, wenn auch unter strengeren Enterprise-Kontrollen.

4. Lokales LLM

Ein lokales LLM läuft auf einem Laptop, einer Workstation, einem Server oder einem internen GPU-Cluster.

Der Hauptvorteil ist die volle Kontrolle. Die Daten verlassen weder das Gerät noch das Netzwerk. Dies ist nützlich für Prototypen, datenschutzrelevante Experimente oder Offline-Szenarien.

Die Nachteile sind jedoch real:

• Die Modellqualität kann unter der von Frontier-APIs liegen.
• Das Setup kann instabil sein.
• GPUs sind teuer in der Anschaffung und im Betrieb.
• Monitoring ist begrenzt, sofern man es nicht selbst baut.
• Zugriffskontrolle und Audit-Logs liegen in der eigenen Verantwortung.
• "Lokal" bedeutet nicht automatisch "compliant".

5. Privates VPC oder On-Prem-Deployment

Dies ist die Enterprise-Variante der lokalen KI.

Das Modell läuft in einer kontrollierten Umgebung, meist eingebettet in Identitätsmanagement, Netzwerkrichtlinien, Logging, Storage und Sicherheitsvorgaben. Das Team kann eine interne API bereitstellen und diese mit genehmigten Anwendungen verbinden.

Dies ist der sicherste Weg für hochsensible Excel-Workflows, erfordert jedoch eine hohe operative Reife.

Ein praktisches Entscheidungs-Framework

Nutzen Sie die Datensensibilität als ersten Filter.

Stellen Sie sich anschließend die operative Frage: Wer wartet das System?

Wenn das Unternehmen keine Kapazitäten hat, um GPUs zu betreiben, Modell-Server zu patchen, Logs zu überwachen und Outputs zu evaluieren, kann ein rein lokales Deployment neue Risiken schaffen. In diesem Fall ist ein Enterprise-KI-Dienst mit starken Kontrollen oft sicherer als ein unmanaged lokales Modell.

Lokal bedeutet nicht automatisch sicher

Ein lokales Modell kann dennoch Daten leaken oder falsch handhaben, wenn das umgebende System schwach ist.

Häufige Fehler sind:

• Speichern hochgeladener Dateien in unverschlüsselten Ordnern.
• Protokollieren von Prompts, die sensible Werte enthalten.
• Gewährung von Zugriff auf alle Dateien für jeden Nutzer.
• Erlaubnis für generierten Code, auf das Netzwerk zuzugreifen.
• Fehlende Patches für den Host-Rechner.
• Kopieren von Ergebnissen in ungesicherte Tools.
• Verwendung von Modellen oder Paketen aus nicht vertrauenswürdigen Quellen.

Datenschutz ist eine Eigenschaft der gesamten Architektur, nicht nur des Standorts des Modells.

Öffentliche APIs sind nicht automatisch unsicher

Das Gegenteil gilt ebenfalls.

Enterprise-KI-APIs können robuste Kontrollen bieten. Viele Anbieter garantieren, dass Business- oder API-Kundendaten standardmäßig nicht zum Training von Modellen verwendet werden. Cloud-Provider bieten zudem privates Networking, IAM, Verschlüsselung, Audit-Logs und Optionen zur Datenaufbewahrung.

Die entscheidenden Fragen sind spezifisch:

• Welcher Produktplan?
• Welcher Vertrag?
• Welche Aufbewahrungseinstellungen?
• Welche Region?
• Welche Logs?
• Welche Nutzer?
• Welche Excel-Daten?

Eine öffentliche API mit Enterprise-Kontrollen kann für viele Workflows akzeptabel sein. Ein willkürlicher Upload in einen Chatbot hingegen meist nicht.

Wie ein idealer Workflow für sensible Excel-Daten aussieht

Für die Analyse sensibler Tabellen sollte ein guter Workflow:

1. Daten vor der Analyse klassifizieren.
2. Dateien in genehmigten Speichern belassen.
3. Benutzerberechtigungen erzwingen.
4. Deterministische Tools für Berechnungen nutzen.
5. Nur den notwendigen Kontext an das Modell senden.
6. Datenabfluss aus den Tools verhindern.
7. Quellzeilen, Blätter, Formeln oder Abfragen zitieren.
8. Prompts, Tools, Datenzugriffe und Outputs protokollieren.
9. Admins die Kontrolle über die Aufbewahrung geben.
10. Private oder Enterprise-genehmigte Modell-Endpunkte unterstützen.

Dies bietet Teams eine praxisnahe Balance: Die Nützlichkeit der KI ohne unkontrolliertes Copy-Paste-Verhalten.

Wo RowSpeak ins Spiel kommt

RowSpeak fungiert als Workflow-Ebene für die Tabellenanalyse. Das bedeutet, es kann über verschiedenen Modell-Optionen liegen.

Für ein Team mit geringerem Risiko kann der Modell-Endpunkt eine genehmigte Enterprise-API sein. Für ein hochsensibles Deployment kann es ein privates LLM sein, das in der Infrastruktur des Kunden läuft. In beiden Fällen bleibt die Nutzererfahrung auf die Excel-Aufgabe fokussiert: Daten hochladen, Fragen stellen, Diagramme erstellen, Belege prüfen und Excel-Dateien mit einem Excel-to-Dashboard-Workflow in Dashboards verwandeln.

Das Modell ist austauschbar. Der kontrollierte Workflow ist der beständige Teil. Deshalb gehört diese Entscheidung oft in den Kontext einer umfassenderen KI-Business-Intelligence-Planung und nicht nur zur reinen Modellauswahl.

Abschließende Checkliste

Bevor Sie sich für ein lokales LLM oder eine öffentliche API zur Excel-Analyse entscheiden, beantworten Sie diese Fragen:

• Was ist das sensibelste Feld in der Arbeitsmappe?
• Ist das Tool für diese Datenklasse zugelassen?
• Trainiert der Anbieter mit Prompts, Dateien oder Ergebnissen?
• Wo werden die Daten verarbeitet und gespeichert?
• Können stattdessen anonymisierte Stichproben verwendet werden?
• Benötigen Nutzer Berechtigungen auf Zeilen- oder Dateiebene?
• Werden Berechnungen deterministisch durchgeführt?
• Sind die Antworten auditierbar?
• Wer wartet das Modell und die Infrastruktur?
• Was passiert, wenn das Modell falsch liegt?

Die beste Architektur ist selten die ideologischste. Es ist diejenige, die den Nutzern echte analytische Hilfe bietet und gleichzeitig dem Risikoniveau der Tabelle entspricht. Wenn die Frage der Anbieterwahl im Vordergrund steht, kann es auch helfen, bekannte Optionen wie Copilot in Excel mit privaten Workflow-Tools zu vergleichen.

Quellen und weiterführende Informationen

• OpenAI Enterprise Privacy: https://openai.com/enterprise-privacy/
• AWS Bedrock FAQs: https://aws.amazon.com/bedrock/faqs/
• Google Vertex AI Data Governance / Zero Data Retention: https://docs.cloud.google.com/vertex-ai/generative-ai/docs/vertex-ai-zero-data-retention
• vLLM OpenAI-kompatibler Server: https://docs.vllm.ai/en/latest/serving/openai_compatible_server/
• Ollama Library: https://ollama.com/library