APEX KI-Agenten: lassen Sie Anwender mit Ihrer App sprechen — sicher

Der schnellste Weg, das Vertrauen Ihres Security-Teams zu verlieren, ist ein KI-Agent, der "Zugriff auf die Datenbank hat". Der zweitschnellste Weg ist ein Agent mit breitem Function Calling auf eine ungeprüfte interne API. APEX 26.1 umgeht beide Muster mit KI-Agenten und KI-Tools — einem klar definierten, deklarativen Modell, in dem der Agent nur die Fähigkeiten aufrufen darf, die Sie explizit registriert haben. Wer in einem APEX-Haus für KI verantwortlich ist, sollte dieses Muster als erstes lernen.

Das mentale Modell

Ein APEX-KI-Agent ist eine konfigurierte Reasoning-Schleife. Er empfängt eine Nutzeranfrage, entscheidet, was zu tun ist, und handelt. Was er tatsächlich tun kann, wird durch die Menge der an die Anwendung angehängten KI-Tools begrenzt. Jedes Tool exponiert eine spezifische Anwendungsfähigkeit — zum Beispiel "Kundensaldo abfragen", "Bestätigungsdialog anzeigen", "Buchungssatz erfassen" — und der Agent hat keinen anderen Pfad zur Anwendung oder ihren Daten.

Drei Tool-Geschmacksrichtungen decken die meisten Use Cases ab:

• Server-seitiges PL/SQL: zum Lesen oder Schreiben von Daten in der Datenbank. Die Prozedur läuft als normaler Datenbank-User der Anwendung, mit denselben Berechtigungen wie jede APEX-Seite.
• Client-seitiges JavaScript: für Aktionen im Browser — einen Dialog öffnen, zu einem Abschnitt scrollen, ein Formular vorausfüllen. Diese können keine Daten lesen, die der Anwender nicht ohnehin sehen könnte.
• REST-Aufrufe: für die Kommunikation mit Systemen außerhalb der Datenbank. Dieselbe Authentifizierung, dieselbe Netzwerkpolitik wie bei jeder anderen APEX-REST-Integration.

Entscheidend: Es gibt kein generisches "SQL ausführen"-Tool, kein generisches "beliebige Prozedur aufrufen"-Tool, kein generisches "beliebigen HTTP-Request senden"-Tool. Die Fähigkeitsfläche des Agenten ist genau die Vereinigung der vom Entwickler registrierten Tools. Das ist es, was das Modell auditierbar macht.

Was Sie damit tatsächlich bauen können

Konkrete Beispiele, die gut in das Muster passen:

• Service-Desk-Assistent. Der Agent kann Ticketstatus nachschlagen, ein Ticket aus einem strukturierten Prompt erstellen und an eine menschliche Queue eskalieren — drei Tools, nichts weiter. Die Berechtigungen des Ticketsystems gelten weiterhin.
• Procurement-Helper. Der Agent kann genehmigte Lieferanten suchen, eine Bestellanforderung entwerfen und an den richtigen Approver routen. Er kann selbst nichts genehmigen.
• Field-Service-Co-Pilot. Der Agent kann Anlagenhistorie abrufen, ein Wartungsverfahren aus einer Wissensdatenbank empfehlen und den nächsten Servicetermin buchen.
• HR-Onboarding-Guide. Der Agent kann persönliche Checklisten abrufen, das richtige Formular für den nächsten Schritt öffnen und eine ausgefüllte Bestätigung einreichen.

Das Muster ist konsistent: eine kleine, benannte Menge von Verben, jedes ein Verb, das die Anwendung schon über ihre eigene UI unterstützt. Der Agent ist ein anderer Weg, diese Verben zu erreichen, nicht eine neue Menge von Verben.

Tools entwerfen, die ein Security-Review überstehen

Einige praktische Regeln zahlen sich vielfach aus.

Machen Sie jedes Tool single-purpose. "Kundendaten abrufen" schlägt "Kundenkram erledigen". Ein single-purpose Tool ist leicht zu benennen, leicht zu auditieren, leicht zu begrenzen.

Validieren Sie Inputs innerhalb des Tools. Behandeln Sie den Agenten wie nicht vertrauenswürdigen externen Input. Der Agent hat vielleicht Ihre Prompt-Instruktionen gelesen, aber vielleicht auch etwas, das in die Nachricht des Anwenders eingeschleust wurde.

Geben Sie strukturierten Output zurück, keinen Text. Ein Tool, das einen Datensatz zurückgibt, ist leichter zu überlegen als eines, das Fließtext zurückgibt. Der Agent kann immer noch erzählen, aber der Datenpfad bleibt sauber.

Loggen Sie jeden Tool-Aufruf. Tool-Aufrufe sind Ihr Audit Trail. Erfassen Sie Aufrufer, Tool-Name, Inputs, Outputs und Zeitstempel. Das ist das Artefakt, das Ihr Compliance-Team braucht.

Fordern Sie Bestätigung für zustandsändernde Tools. Wenn ein Tool Daten schreibt, leiten Sie es über einen Bestätigungsschritt, den der Anwender explizit annimmt. Die client-seitige JavaScript-Variante ist genau für dieses Muster gebaut.

Ein sicherer Agent ist nicht einer mit schlauen Guardrails auf einem mächtigen Tool. Es ist einer, dessen Tools von vornherein zu schmal sind, um gefährlich zu sein.

Die Rolle des Pseudo-Code-Reviews

Ein Detail der breiteren APEX-26.1-KI-Fläche, das auch hier gilt: Wenn Sie den AI Application Generator von Oracle bitten, eine Anwendung zu erstellen oder zu ändern, erzeugt er zunächst menschenlesbaren Pseudo-Code. Sie reviewen und editieren diesen Pseudo-Code, bevor die endgültige Generierung läuft. Dieselbe Review-vor-Ausführung-Philosophie überträgt sich in das Agentendesign — Sie können vorab sehen, was ein Agent für eine Klasse von Prompts tun würde, und seinen Toolset einengen, bevor Sie ihn loslassen.

Was APEX KI-Agenten nicht lösen

Zwei ehrliche Grenzen. Erstens ist die Qualität des agentischen Reasonings weiterhin durch das zugrundeliegende Modell begrenzt. Ein eng zugeschnittener Toolset verhindert katastrophale Handlungen, aber keine bloß unhilfreichen. Planen Sie "der Agent schlägt das falsche Tool vor" als normalen Fehlermodus und sehen Sie Fallbacks an einen Menschen vor.

Zweitens funktioniert dieses Muster für anwendungsförmige Probleme: begrenzte Domänen, benannte Verben, strukturierte Daten. Es ist nicht der richtige Ansatz für offenen Dokumentenchat, tiefe Multi-Source-Recherche oder alles, was über viele Systeme gleichzeitig streifen muss. Diese Use Cases gehören zu OCI Generative AI Agents oder ähnlichen breiteren agentischen Plattformen — die sich selbst als REST-Tool von einem APEX-Agenten aus aufrufen lassen, wenn Sie beides wollen.

Ein Start-Workflow für Ihr Team

1. Wählen Sie einen anwenderseitigen Prozess mit zehn oder mehr Anfragen pro Woche und offensichtlichen benannten Verben.
2. Listen Sie die Verben. Wenn Sie sie nicht jeweils in einem Satz beschreiben können, ist der Prozess noch nicht agentenreif.
3. Implementieren Sie jedes Verb als Tool mit strikter Eingabevalidierung und strukturiertem Output.
4. Pilotieren Sie mit einer wohlgesonnenen Nutzergruppe. Loggen Sie jeden Tool-Aufruf und jede Konversation.
5. Reviewen Sie die Logs wöchentlich. Die Logs des ersten Monats sind das beste Designmaterial, das Ihre Designer je bekommen werden.

APEX 26.1 macht agentische Interaktion realistisch für Enterprise-Teams, die sie bisher nicht rechtfertigen konnten. Das Modell ist bewusst konservativ, und diese Konservativität ist das Feature. Bauen Sie innerhalb der Linien, und Sie bekommen einen Agenten, den Ihr Auditor tatsächlich live gehen lässt.