Aufbau eines privaten KI-Datenanalysesystems für Unternehmensteams

Viele Unternehmen verfolgen das gleiche Ziel: einen KI-Analysten für Firmendaten, der so einfach zu bedienen ist wie ChatGPT.

Sie möchten Fragen in natürlicher Sprache stellen und Antworten direkt aus Tabellenkalkulationen, Datenbanken, Dashboards und internen Berichten erhalten. Dabei soll die Geschwindigkeit der KI genutzt werden, ohne die Kontrolle über sensible Daten aufzugeben.

Das klingt einfach – bis man mit der praktischen Umsetzung beginnt.

Ein privates KI-System zur Datenanalyse ist weit mehr als ein Chatbot mit Dateizugriff. Es erfordert eine geregelte Zugriffskontrolle, verlässliche Berechnungen, Audit-Logs, Model-Serving und eine User Experience, die sich nahtlos in die tatsächlichen Arbeitsabläufe der Teams integriert.

Was Unternehmen unter privater KI-Datenanalyse verstehen

Wenn ein Unternehmen nach privater KI-Analytik verlangt, sind damit meist mehrere Anforderungen gleichzeitig gemeint:

• Daten dürfen nicht an nicht autorisierte öffentliche KI-Tools gesendet werden.
• Nutzer dürfen nur die Daten sehen, für die sie eine Zugriffsberechtigung haben.
• Sensible Dateien müssen in genehmigten Speichersystemen verbleiben.
• Berechnungen müssen lückenlos nachvollziehbar sein.
• Prompts und Ergebnisse müssen revisionssicher protokolliert werden.
• Modelle müssen in einer kontrollierten Umgebung ausgeführt werden.
• Administratoren müssen die Kontrolle über Datenspeicherung und Protokollierung behalten.

Aus diesem Grund enttäuschen generische KI-Demos oft professionelle Entscheider. Eine Demo beantwortet zwar eine Frage, aber ein echtes System muss diese Antwort unter Berücksichtigung von Identitätsmanagement, Berechtigungen, Datenherkunft (Data Lineage) und Compliance-Vorgaben liefern.

Warum ein Chatbot allein nicht ausreicht

Ein Chatbot kann Texte zusammenfassen, Berichte erklären oder Entwürfe formulieren.

Analytik funktioniert jedoch anders. Viele geschäftliche Fragestellungen erfordern präzise Berechnungen.

Nehmen wir diese Frage als Beispiel:

Warum ist die Bruttomarge im dritten Quartal gesunken und welche Region hatte den größten Anteil daran?

Eine hilfreiche Antwort erfordert mehrere Schritte:

1. Identifikation der korrekten Umsatz- und Kostenfelder.
2. Anwendung der Margenformel.
3. Filterung auf das 3. Quartal.
4. Vergleich mit dem Vorjahreszeitraum.
5. Gruppierung nach Regionen.
6. Berechnung des Beitrags zur Veränderung.
7. Erläuterung des Ergebnisses anhand von Belegen.

Ein reines Retrieval-System (RAG) findet vielleicht ein Dokument, in dem die Marge erwähnt wird, kann das Ergebnis aber nicht zuverlässig berechnen.

Für die Analyse im Unternehmen ist RAG zwar hilfreich, aber allein nicht ausreichend.

Die vier Ebenen eines privaten KI-Analysten

Ein praxistaugliches System besteht aus vier Schichten.

1. Interface-Ebene (Schnittstelle)

Hier stellen Nutzer ihre Fragen und prüfen die Ergebnisse.

Mögliche Formen sind:

• Eine Tabellenkalkulations-Oberfläche
• Eine Chat-Sidebar
• Ein Dashboard-Assistent
• Eine interne Web-App
• Eine API für bestehende Tools

Für Business-Teams ist die Tabellenkalkulation oft die natürlichste Umgebung, da hier bereits der Großteil der Ad-hoc-Analysen stattfindet.

2. Reasoning-Ebene (Logik)

Dies ist die Ebene des LLM (Large Language Model) oder Agenten.

Sie interpretiert die Frage des Nutzers, stellt Rückfragen, wählt die passenden Werkzeuge aus, schreibt SQL-Abfragen oder Formeln und erklärt die Ergebnisse.

Wichtig: Diese Ebene sollte nicht als „Source of Truth“ für die eigentlichen Berechnungen dienen.

3. Execution-Ebene (Ausführung)

Hier findet die eigentliche Datenverarbeitung statt.

Die Ausführungsebene nutzt Tools wie:

• SQL-Warehouses
• DuckDB
• pandas oder Polars
• Formel-Engines von Tabellenkalkulationen
• BI Semantic Layer
• Interne APIs

Diese Schicht berechnet Zahlen, verknüpft Tabellen, filtert Zeilen und liefert strukturierte Belege zurück.

4. Governance-Ebene (Verwaltung)

Diese Schicht kontrolliert Zugriffe, Protokollierung, Aufbewahrungsfristen und die Überprüfung der Ergebnisse.

Sie umfasst:

• SSO und RBAC (rollenbasierte Zugriffskontrolle)
• Richtlinien auf Zeilen- und Spaltenebene
• Audit-Logs
• Kontrolle über die Speicherung von Prompts und Antworten
• Data Lineage (Datenherkunft)
• Maskierung sensibler Daten
• Berechtigungen für Modelle und Tools

Ohne diese Ebene ist ein privater KI-Analyst nicht reif für den Unternehmenseinsatz.

RAG vs. direkte Analyse

RAG (Retrieval-Augmented Generation) ist nützlich, wenn es um textbasierte Fragen geht.

Beispiele:

• Was steht in dieser Richtlinie?
• Wie ist der Nettoumsatz definiert?
• Welcher Bericht erklärt die Churn-Methodik?

Direkte Berechnungen sind erforderlich, wenn die Frage auf harten Daten basiert.

Beispiele:

• Welche Region war für den Rückgang verantwortlich?
• Wer sind die fünf wichtigsten Kunden nach Marge?
• Welche Ausgaben waren diesen Monat ungewöhnlich?
• Was hat sich zwischen diesen beiden Exporten geändert?

Die beste Architektur für Unternehmen kombiniert beides: RAG liefert Definitionen und Kontext, während SQL, Tabellenformeln oder Python die Ergebnisse berechnen. Das Modell erklärt das Ergebnis anschließend in natürlicher Sprache.

Governance-Anforderungen, die von Anfang an feststehen müssen

Governance kann nicht nachträglich „drangebastelt“ werden.

Ein privates KI-System muss folgende Fragen beantworten können:

• Wer hat die Frage gestellt?
• Auf welche Daten hat das System zugegriffen?
• Welches Modell hat geantwortet?
• Welche Tools wurden ausgeführt?
• Welche Abfrage oder Formel wurde generiert?
• Welches Ergebnis wurde zurückgegeben?
• Wurden sensible Daten maskiert?
• Könnte ein anderer Nutzer die Antwort reproduzieren oder überprüfen?

Diese Fragen sind für regulierte Branchen essenziell, aber auch für den normalen Geschäftsbetrieb wichtig. Wenn eine KI-Antwort eine Prognose oder einen Vorstandsbericht beeinflusst, muss die Herkunft nachvollziehbar sein.

Observability und Evaluierung

KI-Analytik im Unternehmen benötigt mehr als nur eine Überwachung der Uptime.

Zu den operativen Kennzahlen gehören:

• Latenz
• Token-Verbrauch
• Modellfehler
• Fehler bei Tool-Aufrufen
• Ausführungszeit von Abfragen
• GPU-Auslastung
• Kosten pro Frage

Qualitätsmetriken umfassen:

• Korrektheit der Antworten
• Genauigkeit der Quellenangaben
• Validität von SQL und Formeln
• Halluzinationsrate
• Korrekturrate durch Nutzer
• Rückfragerate

Erfolgreiche Teams erstellen Testsets aus realen Fragen und erwarteten Antworten. Diese lassen sie laufen, bevor sie Modelle, Prompts, Tools oder Retrieval-Einstellungen ändern.

Spezifische Anforderungen an Tabellenkalkulationen

Tabellenkalkulationen sind ein Sonderfall, da sie extrem flexibel, aber oft unstrukturiert sind.

Ein produktives System muss umgehen können mit:

• Mehreren Tabellenblättern
• Ausgeblendeten Blättern
• Formeln und Zellbezügen
• Verbundenen Zellen
• Benannten Bereichen
• Kommentaren
• Inkonsistenten Kopfzeilen
• Exportierten CSVs
• Pivot-ähnlichen Zusammenfassungen
• Lokalen Datums- und Währungsformaten

Deshalb unterscheidet sich Tabellen-KI von allgemeiner Dokumenten-Q&A. Das System muss Strukturen verstehen und Berechnungen durchführen können, statt nur Texte zusammenzufassen.

Eigenbau vs. Kauf

Der Eigenbau eines privaten KI-Analysten bietet maximale Kontrolle, erfordert aber massiven Engineering-Aufwand. Viele Teams definieren zunächst ihren Bedarf – von KI-Reporting bis zur Dashboard-Bereitstellung – bevor sie entscheiden, was sie selbst bauen:

• Model Serving
• Parsing von Arbeitsmappen
• Prompt-Orchestrierung
• Daten-Konnektoren
• Sandboxed Execution
• Zugriffskontrolle
• Audit-Logging
• Evaluierung
• Benutzeroberfläche

Der Kauf oder Einsatz einer spezialisierten Workflow-Ebene kann diesen Weg erheblich verkürzen. Wichtig ist dabei, sich nicht an ein einziges Modell zu binden. Modelle ändern sich schnell; beständig bleibt der kontrollierte Workflow rund um die Unternehmensdaten.

Wo RowSpeak ins Spiel kommt

RowSpeak wurde für die KI-Analyse direkt in Tabellenkalkulationen entwickelt – ideal für Teams, die KI-Datenanalyse benötigen, ohne Nutzer direkt mit rohen Modell-Endpunkten arbeiten zu lassen.

In einer privaten Architektur fungiert RowSpeak als Ebene über den genehmigten Modellen und Datensystemen. Das Modell liefert die Logik, während RowSpeak den Workflow für den Upload von Tabellen, das Stellen von Fragen, das Erstellen von Diagrammen und Zusammenfassungen bereitstellt – immer fest verknüpft mit den zugrunde liegenden Daten.

Das unterscheidet RowSpeak von einem reinen Modell-Server. Es ist die Schicht, die private KI-Fähigkeiten in eine nutzbare Analyse-Erfahrung für Business-Teams verwandelt, ähnlich wie in der KI-Business-Intelligence-Datenstrategie beschrieben.

Fazit

Ein privater KI-Analyst besteht nicht nur aus einem Modell und einem Prompt. Es ist ein kontrolliertes Gesamtsystem.

Das Erfolgsrezept lautet:

LLM-Logik + deterministische Berechnung + berechtigungsgesteuerter Datenzugriff + Revisionssicherheit + ein Workflow, den die Nutzer bereits kennen.

Für viele Unternehmen beginnt dieser Workflow nach wie vor mit der Tabellenkalkulation.

Quellen und weiterführende Informationen

• KServe: https://kserve.github.io/website/
• NVIDIA NIM: https://www.nvidia.com/en-us/ai-data-science/products/nim-microservices/
• dbt Semantic Layer: https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl
• Snowflake Cortex Analyst: https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst
• vLLM OpenAI-kompatibler Server: https://docs.vllm.ai/en/latest/serving/openai_compatible_server/