"Wie viel haben wir im zweiten Quartal mit Kunde Müller umgesetzt?" – eine einfache Frage für jeden Vertriebsleiter, aber oft eine stundenlange Angelegenheit, wenn die Antwort im ERP-System steckt und die Person mit SQL-Kenntnissen gerade im Urlaub ist. Praktiker berichten zunehmend auf X, dass lokale LLMs diese Lücke schließen können: als natürlichsprachige Schnittstelle zwischen Geschäftsanwender und Datenbank, ohne dass eine einzige Zeile Firmendaten das interne Netzwerk verlässt.
Wie Text-to-SQL mit lokalem LLM funktioniert
Das Prinzip ist denkbar einfach. Der Benutzer tippt eine Frage auf Deutsch. Das lokal laufende Modell übersetzt sie in eine SQL-Abfrage, die direkt gegen die ERP-Datenbank ausgeführt wird. Das Ergebnis kommt zurück, formatiert als Zusammenfassung oder Tabelle.
Vier Schritte, die vollständig lokal ablaufen:
- Natürlichsprachige Eingabe: "Zeig mir alle offenen Rechnungen über 5.000 € aus dem zweiten Quartal."
- SQL-Generierung: Das LLM erzeugt eine passende
SELECT-Abfrage, angepasst an das spezifische Datenbankschema. - Datenbankausführung: Die Abfrage läuft gegen die lokale ERP-Datenbank (SAP Business One, Odoo oder einen DATEV-Export).
- Antwort-Aufbereitung: Das Modell fasst das Ergebnis in verständlicher Sprache zusammen oder stellt es als strukturierte Tabelle dar.
Kein API-Key, kein Cloud-Abonnement, kein Datentransfer – der gesamte Prozess läuft auf unternehmenseigener Hardware.
Welche Modelle eignen sich?
Nicht jedes lokale Modell ist für strukturierte Datenbankabfragen gleich gut geeignet. Die lokale KI-Community hat sich auf einige besonders leistungsstarke Optionen konvergiert:
SQLCoder von Defog.ai ist ein Open-Source-Modell, das speziell auf Text-to-SQL-Aufgaben feinabgestimmt wurde. Es läuft via Ollama und übertrifft laut Community-Berichten allgemeine Modelle vergleichbarer Größe bei typischen ERP-Abfragemustern deutlich – Multi-Table-Joins, Aggregationen, Datumsfilter. Auf Apple-Silicon-Hardware mit 192 GB Unified Memory berichten Community-Benchmarks von 20–40 Tokens pro Sekunde für die 15B-Variante.
Qwen 2.5 32B und größere Varianten bieten starkes SQL-Reasoning auch bei komplexen Abfragen mit vielen Tabellen oder verschachtelten Bedingungen. Laut gemeldeten Community-Messungen bewältigen 14B-Modelle grundlegende Reporting-Aufgaben (Umsatz nach Zeitraum, Top-Kunden, offene Forderungen) zuverlässig; für komplexe analytische Workloads werden 32B+ empfohlen.
Llama 3.3 70B eignet sich besonders, wenn das Team Abfragen in mehreren Sprachen stellt – praktisch für internationale KMU-Teams, die auf Deutsch, Spanisch und Englisch im selben ERP-System arbeiten.
ERP-Systeme im KMU-Alltag: Was technisch möglich ist
Die drei am häufigsten eingesetzten ERP-Systeme in mitteleuropäischen und südeuropäischen KMU haben unterschiedliche technische Zugangspunkte:
SAP Business One
SAP B1 nutzt entweder HANA oder Microsoft SQL Server als Datenbank-Backend. Beide sind via Standard-ODBC-Konnektoren oder direkte SQL-Clients erreichbar. Die wichtigste Einrichtungsaufgabe besteht darin, eine Schemabeschreibung zu verfassen: Die relevanten Tabellen und Spalten so zu dokumentieren, dass das LLM versteht, was es abfragt. In der Praxis ist das eine einmalige Investition von ein bis zwei Tagen.
Odoo
Odoo setzt auf PostgreSQL – eine der am besten dokumentierten relationalen Datenbanken überhaupt. Da das Datenmodell von Odoo öffentlich dokumentiert ist, lässt sich der Schema-Kontext für ein lokales LLM schneller aufbauen als bei proprietären Systemen. SQLCoder-basierte Setups laufen hier von Anfang an gut.
DATEV-Exporte
Wer mit DATEV arbeitet, hat in der Regel keinen direkten Datenbankzugang. Ein praktischer Ansatz: DATEV-Auswertungen als CSV oder XLSX auf planmäßiger Basis exportieren, in eine lokale SQLite-Datenbank laden und das LLM darauf loslassen. Null Cloud-Kontakt – die Finanzdaten bleiben im eigenen, DATEV-gesicherten Umfeld und auf dem eigenen Server.
Der DSGVO-Vorteil ist strukturell, nicht nur rhetorisch
ERP-Systeme enthalten Daten, die aus Datenschutzsicht besonders sensibel sind: Kundenzahlungshistorien, Mitarbeitergehälter (in HR-Modulen), strategische Einkaufspreise, vertrauliche Lagerbestände. Wer eine cloudbasierte KI-Lösung nutzt, um diese Daten zu durchsuchen, überträgt sie – zumindest als Teil eines Prompts – an Infrastruktur Dritter, die den Nutzungsbedingungen des jeweiligen Anbieters und dem Recht des Serverstandorts unterliegt.
Gemäß unserem Verständnis der DSGVO – insbesondere Art. 5 Abs. 1 lit. f zum Grundsatz der Integrität und Vertraulichkeit sowie Art. 32 zu angemessenen technischen Maßnahmen – ist genau diese Übertragung das zentrale rechtliche Risiko. Drittanbieter-AGBs, mögliche Nutzung für Trainingszwecke und extraterritoriale Zugriffsansprüche greifen nicht, wenn die Verarbeitung auf eigenen Systemen bleibt.
Ein lokales LLM eliminiert diese Risiken strukturell. Was das interne Netzwerk nicht verlässt, kann nicht abgefangen werden. Was auf eigener Hardware verarbeitet wird, unterliegt keiner fremden Jurisdiktion. Das ist keine Marketing-Formulierung – das ist die technische Realität lokaler KI-Infrastruktur.
Mehr zu Datensouveränität und deren technischer Umsetzung erläutern wir auf /data-sovereignty.html.
Praxis-Setup: Was man braucht
Eine produktionsfähige Text-to-SQL-Implementierung für KMU besteht typischerweise aus wenigen Komponenten:
- Ollama als lokaler Modell-Server (läuft auf Windows, macOS, Linux)
- SQLCoder oder Qwen 2.5 als LLM (über Ollama bereitgestellt)
- Open WebUI als Chat-Oberfläche – mit Datenbankkonnektor-Plugin
- Schemabeschreibung als Systemkontext (einmalig erstellt, bei Schemaänderungen aktualisiert)
- SQL-Konnektor zu SAP B1, Odoo oder einer lokalen SQLite-Datei für DATEV-Exporte
Der Standardansatz für die Einführung: mit einem Pilotprojekt beginnen, das zwei bis drei der am häufigsten abgefragten Tabellen und 10–15 repräsentative Testabfragen umfasst. Genauigkeit bewerten, bevor das vollständige Schema eingebunden wird. Dieser kontrollierte Rollout dauert in der Praxis typischerweise zwei bis vier Wochen.
Was ein solcher Pilotprozess konkret umfasst – einschließlich Evaluationskriterien und Qualitätsschwellen – beschreiben wir auf /local-ai.html.
Was Text-to-SQL leistet – und was es nicht ersetzt
Dieser Ansatz ersetzt keine vollständigen BI-Werkzeuge wie Power BI oder Tableau. Er ergänzt sie – und ersetzt in manchen Fällen die informellen "Kannst du mir mal die Zahl rausziehen?"-Anfragen, die täglich Entwicklern und Analysten Zeit kosten.
Die Geschäftsanwender mit dem größten Nutzen: Vertriebsleiter, die vor einem Meeting wissen wollen, welche Konten sich abkühlen; Operations-Verantwortliche, die schnell eine Lieferantenlieferzeit-Auswertung nach Warengruppe brauchen; Geschäftsführer, die vor einem Kundengespräch die letzten drei Auftragspositionen sehen wollen.
Für diese Anwendungsfälle ist lokales Text-to-SQL oft genau das richtige Werkzeug – weil es kein Dashboard-Aufbauprojekt erfordert, keine BI-Fachkraft voraussetzt und keinen IT-Freigabeprozess benötigt. Eine Frage, getippt in natürlicher Sprache, beantwortet in Sekunden.
Wenn Sie erkunden möchten, wie ein lokales KI-Setup mit ERP-Anbindung für Ihr Unternehmen aussehen könnte, sprechen Sie mit uns über ein Pilotprojekt.