KI-Interactive Reports in APEX 26.1: natürliche Sprache, ohne Halluzinationen

Fast jedes BI-Tool im Jahr 2026 verspricht dasselbe: stelle eine Frage in normalem Deutsch, bekomme eine Antwort. Fast alle funktionieren gleich: ein LLM übersetzt die Frage in SQL, das SQL läuft, die Antwort kommt zurück. Und fast alle scheitern gleich: irgendwann ist das SQL leicht falsch, die Antwort wirkt überzeugend, und jemand trifft eine Entscheidung, die er nicht hätte treffen dürfen. Oracles KI-Interactive Reports in APEX 26.1 wählen eine andere Architektur — und es lohnt sich, diese Wahl zu verstehen, bevor man darauf aufbaut.

Das Muster, das Oracle bewusst nicht gebaut hat

Das dominierende Muster in der Branche ist das, was man NL-zu-SQL mit Hoffnung nennen könnte. Der Anwender stellt eine Frage. Das Modell liest das Datenbankschema, erzeugt eine SQL-Query, führt sie aus und rendert das Ergebnis. Das Modell hat breiten Spielraum: jede Tabelle, jeder Join, jede Aggregation. Der Anwender kann nicht sehen, was tatsächlich lief, es sei denn, er schaut sich das SQL an — was er nicht tut.

Dieses Muster produziert drei mittlerweile gut dokumentierte Fehlermodi:

• Falsche Joins. Das Modell wählt einen plausiblen, aber falschen Join-Pfad und liefert Zahlen, die richtig aussehen, es aber nicht sind.
• Vergessene Filter. Das Modell "vergisst" einen Mandanten-Filter, einen Datumsbereich oder ein Soft-Delete-Flag und gibt Daten außerhalb des normalen Kontextes des Anwenders preis.
• Unnachvollziehbare Änderungen. Morgen erzeugt dieselbe Frage anderes SQL, und niemand kann erklären, warum.

Nichts davon ist theoretisch. Es ist der Grund, warum die meisten Enterprise-Datenteams das "KI fragen"-Feature nach dem ersten Vorfall still abschalten.

Was Oracle stattdessen gebaut hat

KI-Interactive Reports übersetzen eine natürliche Sprachfrage in deklarative Interactive-Report-Einstellungen auf eine vorhandene Report-Definition. Der Anwender fragt: "Zeige nur deutsche Kunden dieses Quartals mit offenen Rechnungen über 10.000 Euro, gruppiert nach Vertriebsregion." APEX übersetzt das in:

• Ein Filter-Chip auf invoice_date.
• Ein Filter-Chip auf customer_country.
• Ein Filter-Chip auf invoice_status.
• Ein Filter-Chip auf invoice_amount mit Operator und Wert.
• Eine Group-By-Einstellung auf sales_region.

Entscheidend: Diese Chips erscheinen auf dem Report. Sie sind sichtbar. Sie sind editierbar. Der Anwender kann den Länderfilter entfernen, ein Highlighting hinzufügen, die Aggregation ändern. Nichts passiert hinter einem Vorhang.

Warum "deklarative Einstellungen" "generiertes SQL" schlägt

Die architektonische Verschiebung zählt aus vier konkreten Gründen.

Berechtigungen gelten weiterhin. Die Report-Definition setzt bereits Row-Level Security, Spaltensichtbarkeit und Anwendungsfilter um. Die KI kann keine Daten erreichen, die der Anwender nicht auch durch manuelles Klicken erreichen könnte.

Audit bleibt unverändert. Was Sie heute an Logging und Audit auf Interactive Reports haben, gilt auch für KI-getriebene Änderungen. Es gibt keinen parallelen "KI-Query"-Log zu pflegen.

Die Angriffsfläche ist endlich. Ein LLM, das beliebiges SQL ausgeben kann, hat praktisch unbegrenztes Verhalten. Ein LLM, das nur bekannte IR-Einstellungen emittieren kann, hat einen klar definierten Ausgaberaum — denselben, den Ihre QA bereits testet.

Anwender lernen das Werkzeug. Wenn die KI einen Filter sichtbar anwendet, sieht der Anwender, wie es funktioniert, und kann es beim nächsten Mal selbst tun. Die KI wird zur Lehrerin, nicht zur Blackbox.

Generiertes SQL verbirgt die Entscheidungen des Modells. Generierte Chips zeigen sie. Sie zu zeigen ist das eigentliche Feature.

Wo es passt und wo nicht

KI-Interactive Reports sind das richtige Muster, wenn der zugrundeliegende Report gut definiert ist: ein kuratiertes Dataset mit sinnvollen Joins, abgestimmten Spalten und bedeutungsvollen Aggregationen. Sie glänzen für die lange Reihe von "Ich möchte diesen Report nur anders schneiden"-Anfragen, die heute jeden Wunsch zum BI-Ticket machen.

Sie sind nicht das richtige Muster für offene explorative Analyse über viele Fakttabellen — das bleibt die Aufgabe eines vollständigen BI-Tools mit semantischer Schicht und ausgebildetem Analysten. Die Linie verläuft ungefähr so: Wenn die Frage durch Ändern der Einstellungen eines Reports, den Sie ohnehin gebaut hätten, beantwortet werden kann, sind KI-Interactive Reports die Antwort; wenn die Frage das Erfinden des Reports erfordert, nicht.

Wie Sie das Feature ausrollen, ohne Vertrauen zu verspielen

Eine praktische Einführungsreihenfolge:

1. Starten Sie mit einem gut kuratierten Report. Idealerweise einer mit klaren Spaltennamen, dokumentiertem Dataset und bekannter Nutzergemeinschaft.
2. Briefen Sie die Anwender. Erklären Sie, dass die KI dieselben Filter ändert, die sie manuell ändern könnten. Zeigen Sie, wie ein Chip hinzugefügt und entfernt wird.
3. Beobachten Sie die ersten hundert Queries. Achten Sie auf Fälle, in denen Anwender etwas wollten, das die Chips nicht ausdrücken können. Das sind Ihre nächsten Backlog-Items, keine Bugs.
4. Aktualisieren Sie die Report-Definition, wenn Sie wiederkehrende Wünsche sehen, die neue Spalten oder Joins erfordern. Die KI ist eine Zwangsfunktion für besseres Report-Design.
5. Widerstehen Sie der Versuchung, es für jeden Report im Workspace einzuschalten. Kuratierter Rollout schlägt flächendeckenden Rollout für das Vertrauen.

Warum das ein strategischer Schritt ist, kein Feature

Zwei Jahre lang wurde die KI-und-Daten-Konversation von Demos dominiert, in denen ein Chatbot auf der Bühne SQL schreibt. Echte Unternehmen tun sich schwer, diese Demos auszurollen, weil die Fehlermodi in regulierten Kontexten inakzeptabel sind. Indem Oracle die kontrollierte, deklarative Variante zum Default in APEX macht, bietet es einen Pfad, den Compliance-Teams tatsächlich zeichnen können.

Das ist eine nüchterne Antwort auf ein gehyptes Problem. Und genau die Art pragmatischer Entscheidung, die eine Plattform tragfähig macht.