KI im Monatstakt, Plattform im Jahrestakt: Warum die DXP-Architektur jetzt entscheidet

Seit dem 2. August gelten die Transparenzpflichten der europäischen KI-Verordnung. Wer KI-Systeme im Kundenkontakt einsetzt oder synthetische Inhalte veröffentlicht, muss das seither erkennbar machen, maschinenlesbar und nachweisbar. Fast zeitgleich haben mehrere Anbieter neue Modellgenerationen ausgerollt, kaum sechs Monate nach den vorherigen. Diese beiden Meldungen aus demselben Sommer beschreiben zusammen das eigentliche Problem vieler Digitalabteilungen: Die Regulierung verlangt Kontrolle über KI-generierte Inhalte, während sich die technische Grundlage dieser Inhalte schneller dreht, als klassische Plattformzyklen es vorsehen.

Neue LLM-Modelle oder KI-Tools erscheinen im Abstand von Monaten, Unternehmen tauschen ihre Digitalplattform im Abstand von Jahren. Wer ein neues Modell, einen neuen Kanal oder einen neuen Agenten nur über ein mehrmonatiges Plattformprojekt anbinden kann, ist strukturell zu langsam, unabhängig davon, wie gut die Plattform sonst funktioniert. Genau deshalb hat sich die Diskussion um die Digital Experience Platform (DXP) in den letzten Monaten spürbar verschoben: weg vom Funktionsumfang, hin zur Frage, wie schnell sich einzelne Bausteine tauschen lassen, ohne dass der Rest des Stacks stillsteht.

Dabei lohnt es sich, den Sammelbegriff KI auseinanderzunehmen. In Ausschreibungen und Datenblättern steht „KI-fähig” inzwischen für drei sehr unterschiedliche Dinge: für das Sprachmodell im Hintergrund, für Assistenten in der Redaktionsoberfläche und für den KI-gestützten Kundendialog. Jede dieser Ebenen stellt eigene Anforderungen an die Architektur. Wer sie vermischt, kauft Funktionen ein und wird trotzdem nicht schneller.

Ebene 1: Das Modell muss austauschbar bleiben

Große Replatforming-Projekte definieren einmal einen Zielzustand und arbeiten ihn über zwölf bis vierundzwanzig Monate ab. Diese Logik setzt voraus, dass die Anforderungen während der Projektlaufzeit stabil bleiben. Bei Sprachmodellen ist das vorbei. Ein Modell, das zum Zeitpunkt der Ausschreibung führend war, ist zum Go-live oft zwei Generationen alt. Die Preisstruktur hat sich mit hoher Wahrscheinlichkeit ebenfalls verändert, in einigen Fällen um Größenordnungen, weil neue Modellklassen ältere Preispunkte unterbieten oder neue Fähigkeiten neue Kostenmodelle mitbringen.

Daraus folgt eine klare Anforderung an jede Plattform, die KI-Funktionen anbietet: Das zugrunde liegende Modell muss sich wechseln lassen, ohne dass Redaktions- und Freigabeprozesse angefasst werden. Eine Plattform sollte mit jedem beliebigen Modell arbeiten können, etwa OpenAI, Azure OpenAI, Anthropic oder einem eigenen Modell im eigenen Rechenzentrum, und der Wechsel sollte eine Konfigurationsentscheidung sein, keine Beschaffung. Modellunabhängigkeit ist damit die günstigste Absicherung im gesamten Stack. Modelle ändern sich in Monaten, Plattformverträge laufen über Jahre. Wer das Modell fest verdrahtet, erzeugt Vendor-Lock-in ausgerechnet auf der volatilsten Ebene der Architektur, und zwar zu einem Zeitpunkt, an dem niemand seriös vorhersagen kann, welcher Anbieter in achtzehn Monaten das beste Verhältnis aus Qualität, Kosten und Datenschutz bietet.

Ebene 2: Assistenten sind nur so gut wie ihre Quelle

Die zweite Ebene sind die Assistenten, mit denen Redaktionen inzwischen täglich arbeiten. Ein Assistent im CMS erzeugt Entwürfe, Zusammenfassungen, Metadaten und Sprachvarianten. Seine Qualität hängt dabei weniger am Modell als an dem, worauf er zugreift. Markenregeln, Tonalität, zulässige und unzulässige Aussagen sowie Freigabelogik müssen maschinenlesbar vorliegen, damit ein Assistent gegen sie generieren kann, und zwar für alle gleich: In großen Teams mit vielen Redakteuren in mehreren Märkten darf das Ergebnis nicht davon abhängen, wer gerade den Auftrag erteilt. Was früher informell im Kopf erfahrener Redakteure lag, wird zur Konfiguration. Ein System, das in derselben Zeit statt sechs Entwürfen dreißig produziert, produziert ohne definierte Leitplanken eben dreißig markenfremde Entwürfe, und es produziert sie genauso schnell.

Hier liegt auch die Antwort auf eine Frage, die in Auswahlprozessen regelmäßig gestellt wird: ob ein KI-Copilot im CMS das Governance-Problem löst. Er löst es nicht, er beschleunigt die Erzeugung. Der Engpass ist durch KI also nicht verschwunden, er hat sich geteilt. Vorgelagert muss jemand die Leitplanken explizit machen, gegen die generiert wird, eine Arbeit, die in den meisten Organisationen bisher niemandem formal gehörte. Nachgelagert steht die menschliche Prüfung in einem Volumen, für das kein manueller Reviewprozess gebaut wurde. Ein Team, das früher einige Dutzend Stücke pro Quartal geprüft hat, bekommt dieselbe Menge nun an einem Tag. Die Entscheidung bleibt beim Menschen. Damit Governance und Freigaben dieses Tempo aushalten, müssen sie in der Plattform abgebildet sein, denn mit Disziplin allein lässt sich das Volumen nicht bewältigen.

Dazu kommt ein Punkt, der in Anforderungskatalogen bisher meist fehlt: KI-Suche und Answer Engines. Ein wachsender Teil der Recherche endet heute in einer generierten Antwort statt auf der Website des Anbieters. Zitiert wird, was konsistent und aktuell ist. Widersprechen sich Produktangaben zwischen Landingpage, PDF und Regionalseite, entscheidet der Zufall, welche Version in die Antwort gerät und unter welchem Namen. Der Single Source of Truth war vorher ein Effizienzthema, jetzt ist er zusätzlich ein Sichtbarkeitsthema. Und er trägt nur, wenn Inhalte modular über APIs strukturiert ansprechbar sind, statt nur als gerenderte Seite vorzuliegen. Ein Modell, das eine Website scrapen muss, um an Produktdaten zu kommen, arbeitet mit dem Stand von gestern und ohne jede Information darüber, welche Fassung freigegeben war.

Für Teams mit mehreren Marken, Märkten und Sprachen verschärft sich das alles noch einmal. Wer Inhalte für zehn Märkte pflegt, verwaltet zehn Sätze lokalisierter Richtlinien und zehn Freigabeketten, die jeweils an unterschiedliche regionale Anforderungen berichten. Eine Aussage, die in einem Land rechtlich zulässig ist, kann im Nachbarmarkt anders bewertet werden. Ändert sich eine Produktaussage oder eine Pflichtangabe, entscheidet die Architektur darüber, ob die Änderung an einer Stelle erfolgt und überall greift, oder ob jemand jede Regionalseite und jede Sprachversion einzeln nachzieht und dabei hoffen muss, keine zu übersehen.

Ebene 3: Der Kundendialog läuft auf denselben Daten

Die dritte Ebene ist der Kundendialog, und sie wird in Architekturdiskussionen am häufigsten übergangen. Chatbots, Live-Chat und Personalisierung werden oft getrennt beschafft und mit einer eigenen Wissensbasis betrieben. Das Ergebnis kennt jeder aus eigener Erfahrung: Der Bot nennt andere Konditionen als die Produktseite, und der Interessent weiß nicht, welcher Angabe er trauen soll. Für die Architektur heißt das, dass Customer Engagement auf denselben freigegebenen Inhalten laufen muss wie die Website. Sonst wird jede Verbesserung im CMS an genau der Stelle wieder eingerissen, an der sie sich auszahlen sollte.

Diese Stelle ist meist eng. Bei erklärungsbedürftigen Käufen, etwa einer Baufinanzierung, einem Versicherungsabschluss oder Unternehmenssoftware mit mehrjähriger Bindung, springen Interessenten oft ab, weil sie ein Formular nicht zu Ende ausfüllen oder auf einer Vergleichsseite keine Antwort finden. Passt sich die Seite an dieser Stelle nicht auf das Verhalten des Besuchers und bietet keine Hilfe an, etwa per Chat oder Rückruf, suchen sie woanders weiter. Wie groß der Bedarf an qualifizierter Ansprache in diesem Moment ist, zeigt eine internationale Innofact-Befragung von 2.535 Verbrauchern in fünf Ländern: 76 Prozent bestätigen den Mehrwert der Beratung durch einen echten Menschen, gerade bei teuren Produkten oder komplexen Dienstleistungen, und 75 Prozent wünschen sich persönliche Unterstützung, sobald automatisierte Werkzeuge an ihre Grenzen kommen. KI kann diesen Moment in Echtzeit erkennen und passende Inhalte oder einen menschlichen Ansprechpartner einspielen. Sie kann es aber nur auf Basis derselben Datenlage, aus der auch die Website gespeist wird.

Der gemeinsame Nenner heißt Composability

Alle drei Ebenen stellen dieselbe strukturelle Anforderung: Neue Tools müssen sich per API anbinden lassen, ohne dass daraus ein Plattformprojekt wird. Das ist die Kernidee hinter Composable, einer Plattform als Menge austauschbarer Packaged Business Capabilities, also fachlich abgeschlossener Bausteine wie Suche, Personalisierung, Asset-Verwaltung oder Checkout, die jeweils über APIs eingebunden werden. Entscheidend ist dabei die zweite Hälfte: Governance muss über alle Komponenten hinweg greifen und darf nicht pro Tool neu definiert werden. Ein Baustein, der sich anbinden lässt, aber eigene Freigabelogik mitbringt, verlagert das Problem nur.

Zwei Einordnungen gehören zur Ehrlichkeit dieser Debatte. Erstens ist ein Monolith damit keineswegs grundsätzlich die falsche Wahl. Für ein Unternehmen mit einer Marke, einem Markt und stabilen Anforderungen bleibt eine integrierte Plattform meist die einfachere Option. Composable zahlt sich dort aus, wo Marken, Märkte und Kanäle sich unterschiedlich entwickeln: im Tempo, etwa wenn eine Marke wöchentlich Kampagnen startet und eine andere nur einmal im Monat aktualisiert, aber auch in den Anforderungen, etwa wenn ein Markt eigene Pflichtangaben, Sprachen oder Freigaben braucht. Zweitens verlangt Composable kein radikales Headless-Setup. Es braucht API-Zugriff auf Inhalte, mehr zunächst nicht. Hybride Modelle wie CoreMedia, bei denen Redaktionen weiter im visuellen Kontext arbeiten und Inhalte gleichzeitig in der Redaktionsoberfläche personalisiert werden können, sind meist der pragmatischere Weg, weil sie die Arbeitsweise der Redaktion nicht opfern, um die der Maschinen zu ermöglichen.

Was die KI-Verordnung für die Architektur bedeutet

Zurück zum regulatorischen Rahmen, der diese Architekturfragen seit diesem Sommer mit Fristen versieht. Seit dem 2. August 2026 gelten die Transparenzpflichten der KI-Verordnung. Nutzer müssen erkennen können, dass sie mit einem KI-System interagieren, und synthetisch erzeugte Inhalte müssen maschinenlesbar gekennzeichnet sein. Für generative Systeme, die vor diesem Stichtag auf dem Markt waren, läuft eine Übergangsfrist für die Kennzeichnungspflicht bis Dezember 2026. Die Anforderungen für Hochrisiko-Systeme wurden durch den Digital Omnibus auf Dezember 2027 beziehungsweise August 2028 verschoben. Den jeweils aktuellen Stand dokumentiert die Europäische Kommission.

Für die Plattformarchitektur folgt daraus eine einfache, aber weitreichende Konsequenz: Kennzeichnung, Versionierung und Nachweis müssen dort entstehen, wo Inhalte entstehen. Ein Unternehmen, das erst am Ende der Kette manuell ergänzt, welche Inhalte KI-generiert sind, kann diese Angabe weder für alle Kanäle garantieren noch im Zweifel belegen. Die Nachweiskette reißt an genau der Stelle, an der sie belastbar sein müsste. Wer dagegen im Content-Management festhält, welches Modell mit welchen Leitplanken welchen Entwurf erzeugt hat und wer ihn freigegeben hat, beantwortet die Frage der Aufsicht mit einem Export statt mit einer Rekonstruktion.

Souveränität gehört in dieselbe Entscheidung

Zur Compliance-Betrachtung gehört inzwischen auch, wo die Plattform selbst betrieben wird und welchem Recht der Betreiber unterliegt. Eine Lösung kann jede europäische Anforderung auf dem Papier erfüllen und ein Unternehmen trotzdem einem ausländischen Offenlegungsregime aussetzen, wenn der Anbieter keinem europäischen Recht untersteht. Digitale Souveränität meint in diesem Zusammenhang die Kontrolle darüber, wo Daten liegen, wer Zugriff erzwingen kann und welche Rechtsordnung für die Plattform gilt. Praktisch übersetzt sich das in Deploymentoptionen: EU-Region, Private Cloud oder On-Premise, kombiniert mit einem Anbieter im europäischen Rechtsraum.

Anbieter positionieren sich hier unterschiedlich. CoreMedia etwa, ein Hamburger Anbieter, der Content-Management und Customer Engagement in einer Plattform bündelt, bietet Cloud-, Hybrid- und On-Premise-Betrieb an und koppelt seinen KIO AI Co-Pilot an kein festes Modell, während andere Anbieter im DXP-Umfeld ausschließlich SaaS bereitstellen und den Modellpartner vorgeben. Für die Bewertung ist weniger die Anbieterliste relevant als die Frage, welche dieser Optionen ein Unternehmen in drei Jahren noch braucht und ob die gewählte Architektur den Wechsel dann zulässt.

Drei Prüfungen statt einer Feature-Matrix

Wer in den kommenden Monaten eine Plattformentscheidung vorbereitet, kommt mit drei Prüfungen weiter als mit jeder Feature-Matrix:

1. Lässt sich das zugrunde liegende Modell wechseln, ohne dass Redaktions- und Freigabeprozesse angefasst werden?
2. Greifen Assistenten, Agenten und Chatbots auf dieselben freigegebenen Inhalte zu wie die Website, oder wird ihnen nur die gerenderte Seite angeboten?
3. Lässt sich ein einzelner Baustein, etwa Suche oder Personalisierung, innerhalb eines Quartals tauschen, ohne dass ein Plattformprojekt daraus wird?

Wer diese drei Fragen beantworten kann, braucht keine Architekturdiskussion mehr zu führen. Die Antworten sind die Architekturdiskussion. Und wer sie nicht beantworten kann, weiß seit dem 2. August, dass die Zeit dafür nicht mehr unbegrenzt ist.