Mit Oracle APEX 26.1 wird die Auswahl des AI-Modells deutlich flexibler. Neben OCI Generative AI, OpenAI und Cohere unterstützt APEX nun unter anderem Google Gemini, Anthropic Claude, Mistral AI, Ollama und OpenAI-kompatible Endpunkte. Für Teams ist das interessant, weil nicht jede Aufgabe dasselbe Modell, dieselbe Datenresidenz oder dieselbe Kostenstruktur benötigt.
1. Den Provider nach dem Anwendungsfall auswählen
Für kurze Klassifikationen oder Textentwürfe kann ein schnelles Modell genügen. Komplexe Begründungen, mehrsprachige Ausgaben oder Tool-Aufrufe stellen andere Anforderungen. APEX kapselt die Verbindung in einem Generative AI Service: Provider, Endpoint, Modell und Credential werden konfiguriert, während die Anwendung über AI-Funktionen und Komponenten darauf zugreift.
Die Anwendung sollte nicht überall einen konkreten Modellnamen fest verdrahten. Legen Sie stattdessen einen stabilen Static ID für den Service fest und wählen Sie den konkreten Provider über die Konfiguration. So kann ein Team später von einem Cloud-Modell auf einen anderen Dienst oder einen internen Endpoint wechseln, ohne alle Seitenprozesse zu ändern.
2. Generative AI Service sauber konfigurieren
Die Einrichtung erfolgt im App Builder unter den Workspace Utilities für Generative AI. Dort werden Provider, Endpoint, Modell und Web Credential hinterlegt. APEX führt einen Verbindungstest aus, bevor der Service gespeichert wird. Secrets gehören ausschließlich in das Credential-Repository und nicht in JavaScript, SQL-Text oder statische Ressourcen.
Trennen Sie Services nach Zweck und Umgebung: Ein Entwicklungsservice darf ein anderes Modell verwenden als Produktion. Schalten Sie die Nutzung durch den APEX Assistant nur dann frei, wenn der Service dafür vorgesehen ist. Für Laufzeitfunktionen kann ein separater Service mit restriktiverem Netzwerkpfad und eigenem Kostenlimit sinnvoll sein.
3. Ollama und OpenAI-kompatible Endpoints
Ollama eröffnet einen lokalen Weg für Chat und Embeddings. Das kann für sensible Inhalte, Offline-Szenarien oder interne Prototypen attraktiv sein, setzt aber eine erreichbare Modellinstanz und ausreichende Hardware voraus. APEX ruft den Dienst serverseitig auf; deshalb muss der Endpoint aus der Datenbank- beziehungsweise ORDS-Infrastruktur erreichbar sein, nicht nur vom Entwickler-Laptop.
OpenAI-kompatible APIs erlauben außerdem eigene Gateways, Proxy-Schichten oder andere selbst betriebene Modelle. Prüfen Sie vor dem Einsatz, welche Chat-, Embedding- und JSON-Schema-Funktionen der Endpoint tatsächlich unterstützt. „Kompatibel“ bedeutet nicht automatisch identisches Verhalten bei Tool-Parametern, Streaming, Fehlercodes oder Tokenzählung.
4. Governance vor dem ersten produktiven Prompt
- Datenklassen festlegen und sensible Inhalte einem freigegebenen Provider oder einem lokalen Modell zuordnen.
- Für jeden Service einen eigenen Credential-, Netzwerk- und Berechtigungsumfang definieren.
- Maximale AI-Tokens und Timeouts passend zu Funktion, Budget und Benutzererwartung setzen.
- Prompts, Modell, Provider, Nutzer, Laufzeit und Fehler so protokollieren, dass keine geheimen Inhalte unnötig im Log landen.
- Antworten bei fachlich kritischen Prozessen als Entwurf behandeln und eine menschliche Prüfung einbauen.
Fazit
APEX 26.1 macht AI-Integration weniger abhängig von einem einzelnen Anbieter. Cloud-Modelle, OpenAI-kompatible Gateways und lokale Ollama-Instanzen können über dasselbe deklarative Muster angebunden werden. Der nachhaltige Vorteil entsteht aber erst durch die Kombination aus austauschbarer Konfiguration, serverseitig geschützten Credentials, begrenzten Tokens und klarer Daten-Governance.
Weiterführend: Oracle: AI-Provider in APEX 26.1, die Dokumentation zu Generative AI Services und die Release-Voraussetzungen.