On-Prem KI-Tabellen-Architektur: Vom LLM-Endpunkt zur kontrollierten Analyse

Ein LLM On-Premises zu betreiben, ist erst der Anfang.

Wenn das Ziel eine KI-gestützte Tabellenanalyse ist, reicht ein Modell-Endpunkt allein nicht aus. Business-Anwender möchten kein rohes JSON an einen internen Inferenz-Server senden. Sie möchten eine Arbeitsmappe hochladen, eine Frage stellen, eine verlässliche Antwort erhalten, ein Diagramm erstellen und genau wissen, woher die Zahlen stammen.

Das erfordert eine Architektur rund um das Modell.

Dieser Leitfaden erläutert die Hauptkomponenten eines On-Prem-Systems für KI-Tabellenanalysen.

Referenzarchitektur

Eine praxistaugliche On-Prem-Architektur für KI-Tabellenanalysen sieht wie folgt aus:

Die Reihenfolge kann variieren, aber das Prinzip bleibt gleich: Das LLM soll logische Schlüsse ziehen und erklären, während kontrollierte Systeme den Datenzugriff, die Berechnungen, die Sicherheit und die Revisionssicherheit übernehmen.

Identitäts- und Zugriffskontrolle

Alles beginnt mit der Identität.

Jede KI-Antwort muss mit einem Benutzer, einem Workspace, einer Datei und einer Berechtigungsentscheidung verknüpft sein.

Enterprise-Bereitstellungen erfordern in der Regel:

• SSO via SAML oder OIDC
• Rollenbasierte Zugriffskontrolle (RBAC)
• Gruppen-Mapping vom Identity Provider
• Berechtigungen auf Workspace-Ebene
• Berechtigungen auf Dateiebene
• Dataset-Allowlists
• Admin-Kontrollen

Wenn das System eine Verbindung zu Datenbanken oder Object Storage herstellt, darf es bestehende Berechtigungen nicht umgehen. Die KI darf nicht zur Abkürzung für die Governance werden.

Verarbeitung von Arbeitsmappen (Ingestion)

Die Ingestion von Tabellenkalkulationen ist schwieriger, als es aussieht.

Eine echte Arbeitsmappe kann Folgendes enthalten:

• Mehrere Tabellenblätter
• Ausgeblendete Blätter
• Formeln
• Verbundene Zellen
• Inkonsistente Kopfzeilen
• Benannte Bereiche
• Kommentare
• Formatierungen mit inhaltlicher Bedeutung
• Geschützte Blätter
• Diagramme und Pivot-Tabellen
• Externe Links
• Makros

Ein produktives System sollte genug von dieser Struktur parsen, um zu verhindern, dass das Modell eine verzerrte Sicht auf die Daten erhält.

Aus Sicherheitsgründen sollten makrofähige Dateien vorsichtig behandelt werden. Wenn das System Code ausführt, sollte dies in einer Sandbox geschehen. In vielen Umgebungen sollten Makros gescannt, blockiert oder lediglich als Metadaten behandelt werden, anstatt sie auszuführen.

Verständnis der Tabellenstruktur

Nach der Ingestion sollte das System eine nützliche Repräsentation der Arbeitsmappe erstellen.

Dies kann Folgendes umfassen:

• Zusammenfassungen der Blätter
• Tabellengrenzen
• Spaltennamen und abgeleitete Datentypen
• Beispielzeilen
• Formel-Abhängigkeitskarten
• Erkannte Metriken
• Datumsbereiche
• Fehlende Werte
• Anomalien
• Beziehungen zwischen Blättern oder Dateien

Diese Repräsentation ist das, was das Modell zuerst sehen sollte. Eine gesamte Arbeitsmappe direkt in einen Prompt zu senden, ist meist verschwenderisch und riskant.

Das Ziel ist es, dem Modell genügend Kontext für die Planung des nächsten Schritts zu geben, anstatt es die gesamte Datei auswendig lernen zu lassen.

Deterministische Rechenebene

Für Tabellen-KI ist dies eine der wichtigsten Komponenten.

Das Modell sollte kritische Zahlen nicht intern berechnen, sondern Tools aufrufen.

Die Rechenebene kann Folgendes umfassen:

• Tabellenformeln
• SQL
• DuckDB
• pandas
• Polars
• Warehouse Pushdown
• Diagrammerstellung
• Validierungsprüfungen

Wenn ein Benutzer beispielsweise nach den Top-Kunden nach Umsatz fragt, identifiziert das Modell die richtigen Felder und erstellt eine Abfrage. Die Rechenebene führt die Abfrage aus. Das Modell erklärt anschließend das Ergebnis.

Diese Trennung verbessert die Genauigkeit, Geschwindigkeit und Revisionssicherheit.

Bereitstellung privater Modelle

Die Modellebene kann auf verschiedene Arten bereitgestellt werden.

vLLM wird häufig für selbstgehostete Inferenz mit hohem Durchsatz verwendet und bietet einen OpenAI-kompatiblen Server.

KServe ist nützlich, wenn das Unternehmen eine Kubernetes-native Modellbereitstellung und Standard-Inferenzdienste wünscht.

NVIDIA NIM bietet optimierte Inferenz-Microservices für NVIDIA-beschleunigte Infrastrukturen.

Ollama eignet sich für Pilotprojekte und lokale Tests, wobei Produktionsumgebungen oft eine stärkere Skalierung, Zugriffskontrolle und Observability erfordern.

Die Modellebene sollte als interne Infrastruktur behandelt werden:

• Authentifiziert
• Versioniert
• Überwacht
• Durch Netzwerkkontrollen isoliert
• Mit klaren Datenaufbewahrungsrichtlinien konfiguriert
• Vor Modell-Upgrades evaluiert

KI-Orchestrierung

Die Orchestrierungsebene entscheidet, wie das System das Modell und die Tools nutzt.

Sie verwaltet:

• Prompt-Templates
• Modellauswahl
• Tool-Auswahl
• Kontext-Konstruktion
• Rückfragen zur Klärung
• Abfragevalidierung
• Code-Sandboxing
• Retry-Logik
• Antwortformatierung

In dieser Ebene sind viele Sicherheitskontrollen angesiedelt.

Wenn das Modell beispielsweise SQL generiert, sollte das System validieren, dass das SQL nur lesend ist, auf erlaubte Tabellen beschränkt bleibt und nicht zu ressourcenintensiv ist. Wenn das Modell Python generiert, sollte das System dies in einer Sandbox ohne Netzwerkzugriff ausführen (sofern nicht explizit erlaubt).

Revisionssicherheit (Auditability)

Audit-Logs sind in professionellen Umgebungen unverzichtbar.

Ein nützliches Log sollte Folgendes enthalten:

• Benutzer
• Zeitstempel
• Zugegriffene Arbeitsmappe oder Datensatz
• Prompt
• Modellname und -version
• Generierte Abfrage, Formel oder Code
• Tool-Outputs
• Finale Antwort
• Berechtigungsentscheidungen
• Fehler und Fallbacks

Das bedeutet nicht, dass jeder sensible Wert ewig gespeichert werden muss. Die Aufbewahrung sollte konfigurierbar sein. Aber das System benötigt genügend Rückverfolgbarkeit für Überprüfungen, Debugging und Compliance.

Observability

Technische Teams müssen sowohl die Infrastruktur als auch die Antwortqualität überwachen.

Infrastruktur-Metriken:

• Latenz
• GPU-Auslastung
• Warteschlangentiefe
• Token-Verbrauch
• Modellfehler
• Tool-Ausführungszeit
• Speicherauslastung

Qualitäts-Metriken:

• Korrektheit der Antworten
• Qualität der Quellenangaben (Citations)
• Validität von Formeln
• Erfolgsrate von Abfragen
• Benutzerkorrekturen
• Halluzinationsberichte
• Fehlgeschlagene Klärungsversuche

Ohne Observability können Teams nicht wissen, ob der KI-Analyst besser wird oder stillschweigend unzuverlässige Ergebnisse liefert.

Häufige Fallstricke

Das Modell als Tabellen-Engine nutzen

Dies führt zu halluzinierten Summen und fragilen Antworten. Nutzen Sie Tools für Berechnungen.

Erst abrufen, dann filtern

Berechtigungen müssen erzwungen werden, bevor der Kontext das Modell erreicht.

Die Komplexität von Arbeitsmappen ignorieren

CSV-Demos beweisen nicht, dass das System mit echten Excel-Dateien umgehen kann.

Zu viele sensible Daten loggen

Revisionssicherheit ist wichtig, aber Logs müssen auch Aufbewahrungs- und Datenschutzregeln folgen.

Um ein einziges Modell herum bauen

Modelle ändern sich schnell. Bauen Sie den Workflow so, dass das Modell austauschbar bleibt.

Ein schrittweiser Einführungsplan

Ein realistischer Rollout kann in Phasen erfolgen:

1. Prototyp mit Beispiel- oder anonymisierten Tabellen erstellen.
2. Validierung gängiger Analyseaufgaben und Fehlerszenarien.
3. Deterministische Rechenebene für alle numerischen Aufgaben hinzufügen.
4. Identität und Berechtigungen verknüpfen, bevor echte Dateien genutzt werden.
5. Privaten Modell-Endpunkt via vLLM, KServe, NIM oder einem anderen Stack bereitstellen.
6. Audit-Logs und Monitoring hinzufügen.
7. Pilotprojekt mit einem Team (meist Finanzen, Operations oder Vertrieb).
8. Ergebnisse evaluieren und gegen bekannte Antworten prüfen, bevor skaliert wird.

Dies verhindert den häufigen Fehler, eine Modell-Demo in ein Produktionssystem zu verwandeln, bevor die Governance-Ebene steht.

Die Rolle von RowSpeak

RowSpeak fungiert als Workflow-Ebene über privaten Modell-Endpunkten und kontrollierter Datenausführung.

Der Modell-Server liefert die Logik. RowSpeak liefert die Tabellen-Erfahrung: Upload von Arbeitsmappen, Fragen in natürlicher Sprache, Diagramme, Zusammenfassungen, Berichte und Analyse-Workflows wie das wöchentliche Sales-Reporting.

Für On-Prem-Bereitstellungen ist diese Trennung wertvoll. Die IT behält die Kontrolle über das Modell und die Infrastruktur. Business-Anwender arbeiten über ein Interface, das für Tabellenanalysen optimiert ist – egal ob das Ergebnis ein KI-Dashboard oder ein Finanzbericht ist.

Fazit

Ein On-Prem LLM-Endpunkt ist Infrastruktur. Ein On-Prem KI-Tabellenanalyst ist ein Produkterlebnis plus Governance.

Das Modell ist wichtig, aber die Architektur drumherum entscheidet darüber, ob dem System vertraut wird. Ein modellspezifisches Beispiel finden Sie im Leitfaden zum Self-Hosting von DeepSeek für RowSpeak.

Quellen und weiterführende Links

• vLLM OpenAI-kompatibler Server: https://docs.vllm.ai/en/latest/serving/openai_compatible_server/
• KServe: https://kserve.github.io/website/
• NVIDIA NIM: https://www.nvidia.com/en-us/ai-data-science/products/nim-microservices/
• Ollama Library: https://ollama.com/library
• llama.cpp: https://github.com/ggml-org/llama.cpp