Oracle will Geschäftsregeln vor eigenmächtigen KI-Agenten schützen

1. Oracle will Geschäftsregeln vor eigenmächtigen KI-Agenten schützen
   • Identität und Geschäftsregeln an der Datenquelle
   • Kontrollierter Zugriff auf Geschäftsobjekte
   • Gemeinsame Laufzeit für generierte Anwendungen

Oracle hat auf der Oracle AI World in Las Vegas die Deep Trust AI Architecture vorgestellt. Der Architekturansatz führt Funktionen aus Oracle AI Database, Autonomous AI Database und dem APEX AI Application Generator zusammen. Sicherheits- und Geschäftsregeln sollen unabhängig davon greifen, welche Anwendung oder welcher KI-Agent auf Unternehmensdaten zugreift.

Dahinter steht ein bekanntes Problem. Regeln, die ausschließlich in einer Anwendung implementiert sind, schützen nur Zugriffe über diese Anwendung. Ein Agent kann dagegen über einen Server für das Model Context Protocol (MCP) oder mithilfe einer Übersetzung natürlichsprachlicher Fragen in SQL direkt auf eine Datenbank zugreifen. Prüfungen, die nur in der umgangenen Anwendung hinterlegt sind, werden dann nicht ausgeführt. MCP ist dabei ein möglicher Zugriffsweg, entscheidend ist die Platzierung der Kontrollen.

Die zentrale Durchsetzung von Zugriffs- und Integritätsregeln in Datenbanken ist als Prinzip etabliert. Oracle bündelt entsprechende Mechanismen nun mit Funktionen für KI-gestützte Datenzugriffe und Anwendungserzeugung zu einem gemeinsamen Architekturleitbild.

Identität und Geschäftsregeln an der Datenquelle

Mit Deep Data Security sollen Administratoren Zugriffsregeln für Anwender direkt in Oracle AI Database festlegen. Die Datenbank prüft laut Oracle die Benutzeridentität anhand eines kryptografisch signierten Tokens aus dem Unternehmensverzeichnis. Auf dieser Grundlage bestimmt sie, auf welche Daten der jeweilige Benutzer zugreifen darf.

SQL Assertions ergänzen die Zugriffskontrolle um fachliche Bedingungen. Oracle nennt als Beispiel Ausgaben, die das festgelegte Limit eines Mitarbeiters überschreiten. Eine entsprechend definierte Bedingung soll verhindern, dass die Datenbank eine solche Änderung akzeptiert, unabhängig davon, ob eine klassische Anwendung oder ein KI-Agent sie anfordert.

Damit hängt die Einhaltung der hinterlegten Regel nicht davon ab, ob jede zugreifende Anwendung dieselbe Prüfung korrekt implementiert. Voraussetzung bleibt, dass die notwendigen Regeln in der Datenbank definiert und für den jeweiligen Zugriff wirksam sind. Eine zulässige Aktion ist dadurch allerdings noch nicht automatisch fachlich sinnvoll.

Kontrollierter Zugriff auf Geschäftsobjekte

Für Anwendungen und Agenten sieht Oracle außerdem die Deep Trust Data APIs vor. Statt beliebige SQL-Anweisungen auf Tabellen auszuführen, sollen sie kontrollierte Lese- und Schreibzugriffe auf logische Geschäftsobjekte ermöglichen, beispielsweise eine vollständige Bestellung. Regeln für Änderungen und die Konsistenz der Daten werden dabei in der Datenbank durchgesetzt.

Deep NL2SQL soll die Übersetzung natürlichsprachlicher Fragen in SQL verbessern. Dazu werden Unternehmensbegriffe und Informationen zum Datenmodell einbezogen. Korrekturen durch Nutzer sollen vor ihrer Übernahme in die Wissensbasis validiert werden.

Eine Zugriffskontrolle allein gewährleistet allerdings noch keine korrekten Antworten.

Gemeinsame Laufzeit für generierte Anwendungen

Zur Architektur gehört auch die deklarative Anwendungserzeugung mit APEXlang. Ein KI-Werkzeug erstellt dabei eine Anwendungsbeschreibung, die eine zentrale APEX-Laufzeit ausführt. Gemeinsame Funktionen und Schutzmechanismen müssen dadurch nicht für jede generierte Anwendung erneut als eigener Programmcode entstehen.

Eine weitere Ebene bildet der Betrieb der Softwareplattform. Oracle verweist dafür auf Autonomous AI Database. Der Dienst soll Sicherheitsupdates für den zugrunde liegenden Software- und Infrastrukturstack automatisiert einspielen. Der Architekturansatz umfasst somit vier Ebenen: Plattform, Daten, Datenzugriff und Anwendungsentwicklung.

Deep Trust ist kein einzelner neuer Dienst, sondern ein Leitbild für das Zusammenspiel mehrerer Funktionen. Einen gemeinsamen Einführungstermin oder Gesamtpreis nennt Oracle nicht. Welche Bestandteile in einer konkreten Umgebung verfügbar sind und welche Voraussetzungen sie haben, muss deshalb je Komponente geprüft werden.

(fo)