Read-only per Architektur
Die KI arbeitet über ein eigenes Datenbankkonto mit reinen Leserechten. INSERT, UPDATE und DELETE sind technisch ausgeschlossen – nicht nur per Anweisung.
Reporting & BI
Fachbereiche sollen Daten fragen können, ohne jede Auswertung als IT-Ticket zu formulieren. Unsere Datenbank-KI übersetzt Fragen in kontrollierte read-only Abfragen und liefert Listen, Diagramme und fertige Berichte.

Kurzantwort
Text-to-SQL übersetzt Fragen in natürlicher Sprache – etwa „Welche Kunden haben offene Posten über 10.000 €?" – in geprüfte SQL-Abfragen, führt sie read-only auf der Datenbank aus und erklärt das Ergebnis verständlich.
D'Este Solutions setzt Datenbank-KI mit Schema-Katalog, Query-Validierung und Rollen um, damit Fachbereiche schneller Antworten bekommen, ohne Vollzugriff auf die Datenbank zu benötigen.
Das Problem
Zwischen einer fachlichen Frage und ihrer Antwort liegt in vielen Unternehmen ein Umweg: Die Frage wird zum IT-Ticket, das Ticket zur SQL-Abfrage, die Abfrage zum Excel-Export – und bis das Ergebnis zurückkommt, hat sich die Frage oft schon geändert. Statische Reports helfen nur bedingt, denn sie beantworten, was gestern gefragt wurde, nicht was heute wichtig ist.
Die Folge kennen Controlling, Disposition und Geschäftsführung gleichermaßen: Fachbereiche behelfen sich mit veralteten Exporten, pflegen Schattenlisten in Excel oder verzichten ganz auf die Auswertung. Die IT wiederum arbeitet Anfragen ab, die eigentlich Self-Service sein könnten – Zeit, die für echte Entwicklungsarbeit fehlt.
Eine natürlichsprachliche Datenbankabfrage dreht diesen Ablauf um: Die Frage geht direkt an die Datenbank – auf Deutsch, nicht in SQL. Text-to-SQLübersetzt sie, führt sie kontrolliert aus und liefert das Ergebnis in Sekunden, wie im abgebildeten Dialog. Aus einer Warteschlange wird ein Gespräch.
Welche 10 Kunden hatten im März die höchsten offenen Posten?
Die zehn höchsten offenen Posten im März summieren sich auf 284.500 €. An der Spitze: Muster Logistik GmbH (48.200 €), Weber & Sohn KG (39.800 €) und Brandt Metallbau (31.400 €). Die vollständige Liste mit Fälligkeiten steht darunter.
Quelle: read-only SQL · 0,4 sAls Excel bitte.
Der Export liegt bereit: offene-posten-maerz.xlsx mit allen zehn Kunden, Beträgen, Fälligkeitsdaten und der verwendeten Abfrage als Dokumentation.
Schutzplanken
Eine KI auf der Produktivdatenbank braucht klare Grenzen. Diese sechs Schutzplanken stecken in jeder Datenbank-KI, die wir ausliefern.
Die KI arbeitet über ein eigenes Datenbankkonto mit reinen Leserechten. INSERT, UPDATE und DELETE sind technisch ausgeschlossen – nicht nur per Anweisung.
Nur beschriebene und freigegebene Tabellen sind für die KI sichtbar – inklusive Beziehungen, Fachbegriffen und Synonymen aus Ihrem Arbeitsalltag.
Jede generierte Abfrage wird geparst und gegen Regeln geprüft, bevor sie läuft. Auf Wunsch wird das SQL vor der Ausführung angezeigt.
Wer fragt, sieht nur seine Daten: Mandanten, Abteilungen und sensible Spalten folgen Ihrem bestehenden Rechtekonzept.
Zeilenlimits, Timeouts und Lastgrenzen schützen die Produktivdatenbank – auch bei unglücklich formulierten Fragen zur Stoßzeit.
Jede Frage, jedes generierte SQL und jedes Ergebnis wird protokolliert. Auswertungen bleiben nachvollziehbar – auch Monate später.

Ausgaben
Eine Trefferliste ist selten das Ende einer Auswertung. Deshalb formatiert die Datenbank-KI Ergebnisse direkt weiter: als Excel-Datei für die Weiterverarbeitung, als PDF-Bericht mit Diagrammen für Ablage und Verteiler oder als kurze Management-Zusammenfassung, die das Ergebnis in zwei Sätzen einordnet.
Wiederkehrende Auswertungen lassen sich terminieren: Der Wochenbericht entsteht dann automatisch und landet als PDF im Postfach. So fügt sich KI-Reporting in vorhandene Abläufe ein, statt ein weiteres Werkzeug zu erzwingen, das niemand öffnet.
Einsatzbeispiele
Im Controlling entstehen die meisten Ad-hoc-Fragen: offene Posten je Kunde, Umsätze je Kostenstelle, Materialbewegungen der letzten Wochen. Wo eineWarenwirtschaft Bestands- und Auftragsdaten sauber führt, macht die Datenbank-KI daraus Antworten – ohne dass für jede Monatsfrage ein neuer Report gebaut werden muss.
In der Logistik ändern sich Fragen mit jeder Tour: Welche Fahrzeuge stehen morgen zur Verfügung? Welche Lieferungen hängen, welche Kosten je Kilometer laufen aus dem Ruder? Flottenkennzahlen aus einer Fuhrparksoftware wieLOGAS lassen sich so per Frage auswerten – der Disponent bleibt in seinem Ablauf, statt zwischen Auswertungsmasken zu wechseln.
Im Personalbereich geht es um Fristen und Nachweise: Wessen G26-Untersuchung läuft in den nächsten sechzig Tagen ab, wer ist für das anstehende Projekt einsatzfähig? Daten aus der DESTE Qualifikationsmatrixwerden per Frage geprüft. Weil Personaldaten sensibel sind, kombinieren viele Kunden die Abfrage mit lokaler KI – dann verlassen weder Fragen noch Ergebnisse das Haus.
Vorgehen
Der Aufwand liegt nicht im Sprachmodell, sondern im sauberen Fundament: Datenmodell beschreiben, Zugriffe absichern, Ausgaben gestalten.
Tabellen, Beziehungen, Fachbegriffe und typische Fragen aus dem Fachbereich werden dokumentiert. Daraus entsteht der Schema-Katalog, mit dem die KI arbeitet – je präziser er ist, desto besser die Abfragen.
Read-only-Konto, freigegebene Tabellen, Zeilenlimits und Validierungsregeln werden eingerichtet. Echte Testfragen aus Controlling, Disposition oder HR zeigen, ob die Ergebnisse fachlich stimmen.
Ergebnisse werden als Liste, Diagramm, Excel-Datei, PDF-Bericht oder Management-Zusammenfassung aufbereitet – und auf Wunsch zeitgesteuert per E-Mail oder Ablage verteilt.
FAQ
Antworten auf die Fragen, die IT-Leiter und Fachbereiche in Erstgesprächen am häufigsten stellen.
Ein Sprachmodell erhält eine Beschreibung des Datenmodells – Tabellen, Beziehungen, Fachbegriffe – und übersetzt eine Frage wie „Umsatz je Kunde im letzten Quartal“ in eine SQL-Abfrage. Diese wird validiert, read-only ausgeführt und das Ergebnis als Liste, Diagramm oder Bericht aufbereitet. Die Qualität hängt vor allem davon ab, wie gut das Datenmodell für die KI beschrieben ist.
Ja, wenn die Architektur stimmt: Der Zugriff läuft über ein eigenes Datenbankkonto mit reinen Leserechten, nur freigegebene Tabellen sind sichtbar, jede generierte Abfrage wird vor der Ausführung validiert, und Zeilenlimits sowie Timeouts schützen die Performance. Schreiboperationen sind technisch ausgeschlossen, nicht nur organisatorisch verboten.
Nein, sie ergänzt sie. Standardberichte und Dashboards bleiben sinnvoll für wiederkehrende Kennzahlen; die Datenbank-KI beantwortet die spontanen Fragen dazwischen, für die sich kein eigener Report lohnt. Häufig gestellte Fragen lassen sich später in feste Berichte überführen.
Grundsätzlich alle gängigen relationalen Datenbanken, etwa Microsoft SQL Server, PostgreSQL, MySQL/MariaDB oder Oracle. Entscheidend ist weniger das Datenbanksystem als das Datenmodell: Tabellen, Beziehungen und Fachbegriffe müssen je Datenbank individuell beschrieben werden, die Architektur dahinter bleibt wiederverwendbar.
Da alle Abfragen read-only laufen, kann eine falsch verstandene Frage keine Daten verändern. Das generierte SQL lässt sich vor der Ausführung anzeigen, Ergebnisse enthalten eine Erklärung, welche Tabellen und Filter verwendet wurden, und jede Abfrage wird protokolliert. Unplausible Ergebnisse fallen so schnell auf, und die Frage kann präziser gestellt werden.
Ja, mit passenden Schutzmaßnahmen: Rollen und Berechtigungen steuern, wer welche Tabellen und Spalten abfragen darf; sensible Felder können ausgeblendet oder pseudonymisiert werden. Auf Wunsch läuft das Sprachmodell lokal auf eigener Infrastruktur, sodass weder Fragen noch Ergebnisse an externe Dienste gehen.
Weiterlesen
Kontakt
Schildern Sie kurz Datenbank, Systemlandschaft und typische Auswertungen – wir antworten in der Regel innerhalb eines Werktags mit einer ersten Einschätzung.