Ob ein KI-Assistent auf Portalinhalte zugreifen soll, ist in Kundengesprächen selten die entscheidende Frage. Wichtiger ist: Wer legt fest, welche Daten das Unternehmen verlassen dürfen – und wie lässt sich das später nachvollziehen?
Davon hängt in der Praxis häufig ab, ob eine KI-Anbindung produktiv eingesetzt werden kann oder in der Freigabeschleife stecken bleibt. Genau an dieser Stelle setzt Liferay DXP 2026.Q3 an.
Vom Beta-Projekt zur regulären Anbindung
Der MCP Server war bislang als Beta verfügbar. Mit der vollständigen Unterstützung von OAuth 2.0 erreicht er nun die nächste Entwicklungsstufe.
Der Zugriff eines KI-Assistenten läuft damit über dieselben Authentifizierungsmechanismen, die im Portal bereits für Anwendungen und Schnittstellen eingesetzt werden. Für Betreiber ist das ein wichtiger Schritt: Die Anbindung basiert auf bestehenden Identitäten und lässt sich mit vorhandenen Werkzeugen betreiben und überwachen.
Profile für unterschiedliche Anwendungsfälle
Mit den MCP Server Profiles legen Administratoren fest, welche Aktionen ein KI-Assistent in einem konkreten Anwendungsfall ausführen darf.
Die Aktionen sind nach Anwendungsbereichen gruppiert. Hinzu kommen Schutzmechanismen auf Feldebene und konfigurierbare Maskierungen. Mehrere getrennte Profile können parallel betrieben werden – beispielsweise eines für einen Assistenten in der Redaktion und ein weiteres für die Auskunft im Servicebereich.
Die Voreinstellungen sind bewusst zurückhaltend. Zugleich wird protokolliert, welche Zugriffe ein Profil erlaubt.
Damit lässt sich eine Diskussion direkt im System abbilden, die sonst in jedem Projekt neu geführt werden muss: Statt einen technischen Zugang zunächst breit zu öffnen und anschließend organisatorisch einzuschränken, wird die Begrenzung technisch hinterlegt und nachweisbar gemacht.
Maskierung, bevor Daten das Unternehmen verlassen
Das MCP Server Data Masking prüft Antworten und maskiert konfigurierte Inhalte, bevor sie den KI-Anbieter erreichen. Dazu gehören unter anderem E-Mail-Adressen, Telefonnummern und Kreditkartennummern.
Der Mechanismus wirkt über alle angebundenen Werkzeuge hinweg und erzeugt einen vollständigen Audit-Trail.
Der Vorteil gegenüber einer individuell entwickelten Filterung liegt vor allem in der Reichweite: Eine Eigenentwicklung muss an jeder relevanten Stelle eingebaut, gepflegt und bei neuen Schnittstellen erneut geprüft werden. Der integrierte Schutzmechanismus greift dagegen zentral für alle Daten, die über den Server laufen.
Regeln für KI-Crawler
Mit llms.txt können Betreiber im Site-Root festlegen, wie große Sprachmodelle und KI-Crawler ihre Inhalte verwenden dürfen.
Das Prinzip orientiert sich an robots.txt: Sensible Pfade lassen sich ausschließen, ohne dafür eine eigene technische Lösung entwickeln zu müssen. Die Funktion ist derzeit als Beta gekennzeichnet.
Schnittstellen, die ihre Fähigkeiten selbst beschreiben
Die Headless-Search-API stellt umfangreichere, selbstbeschreibende OpenAPI-Metadaten bereit. KI-Werkzeuge, die das Schema auslesen, sollen dadurch besser verstehen, welche Funktionen die API bietet und wie sie korrekt aufgerufen wird.
Davon profitieren nicht nur KI-Anwendungen. Auch in klassischen Integrationsprojekten reduzieren verständliche Metadaten Rückfragen, Fehlversuche und zusätzlichen Abstimmungsaufwand.
Modulare Developer Skills für die Entwicklung
Im Liferay Workspace stehen die bisherigen KI-Regeldateien nun als modulare Developer Skills zur Verfügung. Sie sind nach häufig verwendeten DXP-Bereichen gegliedert, darunter Site Initializer, Fragmente, Frontend Client Extensions und Objects.
KI-Agenten laden nur die Informationen, die für die jeweilige Aufgabe benötigt werden. Das hält den Kontext überschaubar und kann die Qualität generierter Anpassungen verbessern.
Für Entwicklungsteams, die bereits mit KI-Unterstützung arbeiten, bedeutet das im Alltag vor allem: präzisere Ergebnisse und weniger Nacharbeit.
Was sich für die Freigabe verändert
Eine technische Verbindung zu einem Sprachmodell ist vergleichsweise schnell hergestellt. Verzögerungen entstehen häufig erst in der Freigabe – weil nicht ausreichend belegt werden kann, welche Daten unter welchen Bedingungen übertragen werden und wer die Regeln dafür festgelegt hat.
Profile, Schutz auf Feldebene, Maskierung und Protokollierung liefern dafür zentrale Bausteine. Datenschutz, Revision und Betriebsrat erhalten Antworten, die sich nicht nur organisatorisch zusichern, sondern am System nachvollziehen lassen.
Zur Einordnung gehört allerdings auch: Einige Funktionen sind optional, andere befinden sich noch im Beta-Status. Die Richtung ist klar erkennbar. Für eine konkrete Produktionsentscheidung müssen Reifegrad und Eignung jedoch im jeweiligen Einsatzszenario geprüft werden.
