KI-Modelle wechseln im Jahresrhythmus. Datenmodelle, Integrationen und Berechtigungen bleiben. Wer 2026 KI-Plattformen baut, entscheidet vor allem über die zweite Hälfte des Stacks. Über das, was die KI-Modell-Demos nicht zeigen.
Die Schwelle, KI auszuprobieren, ist niedrig. Eine Person, ein Editor, ein API-Schlüssel. Was als Demo überzeugt, fällt im Betrieb auseinander, sobald Daten, Lasten, Berechtigungen und Audit-Pflichten dazukommen. Genau da beginnt Architektur. Genau da hört das Ausprobieren auf.
Bauen ist nicht Bauen
Ein Prototyp steht in zwei Tagen. Eine Plattform steht nicht in zwei Tagen. Beide zeigen, dass etwas möglich ist. Nur eines hält dem Betrieb stand. Wer aus einem Pilot eine Plattform machen will, muss früher als gedacht Entscheidungen treffen, die mit dem KI-Modell wenig zu tun haben. Wer Datenstrukturen, Identitäten und Schnittstellen erst nach dem Pilot baut, baut zweimal.
Wir sehen das nicht aus Folien, sondern aus vierzehn Jahren Projektarbeit mit Hersteller:innen und Großhändler:innen. Die meisten KI-Anwendungen scheitern nicht am KI-Modell. Sie scheitern an Datenqualität, fehlenden Eigentümer:innen für Pipelines und an Skalierungspfaden, die nie gezeichnet wurden. Wer KI im Betrieb hält, kennt diese drei Probleme. Sie stehen in den KI-Modell-Vergleichen nicht.
KI ist eine Schicht, kein Fundament
KI-Modelle sind die volatilste Schicht im Stack. Sie wechseln, wenn ein neues KI-Modell schneller, günstiger oder belastbarer ist. Trivial ist die Wahl des KI-Modells deshalb nicht: Tool Calling, Kontextfenster, Kosten, Latenz, Structured Outputs, Hosting-Optionen und Sicherheitsmechanismen unterscheiden sich teils erheblich. Austauschbarkeit ist kein Naturzustand, sie entsteht erst, wenn Datenzugriff, Tooling und Prozesslogik sauber von der KI-Modellschicht entkoppelt sind. Bis dahin ist jede Entscheidung über das KI-Modell eine Architekturentscheidung mit Folgen. Wer ohne diese Entkopplung mit der Wahl des KI-Modells beginnt, hat über die unsichtbaren neunzig Prozent darunter noch nicht entschieden: Datenmodell, RAG-Pipeline, Authentifizierung, Audit-Logs, Tool-Use-Verträge zwischen Agent und System.
KI-Modelle werden austauschbar, sobald die Architektur darunter sauber entkoppelt ist. Was eine KI-Plattform im Betrieb trägt, sind Daten, Integrationen und Governance.
Patrick Lorenz, Head of Frontend Development, Smart Commerce
Für Hersteller und Großhandel ist das eine gute Nachricht. Was Sie an Stammdaten, ERP-Anbindungen, Berechtigungs-Logik und Service-Prozessen mitbringen, ist die Substanz, auf der KI später aufsetzt. Was Start-ups mit dem neuesten KI-Modell schneller demonstrieren, fehlt ihnen oft genau dort. Bei fischer haben wir über mehrere Jahre eine Plattform gebaut, die heute mehrere KI-Bausteine trägt. Die Plattform wurde nicht für KI erfunden. Sie wurde so gebaut, dass KI ohne Operation am offenen Herzen integriert werden konnte. Das ist der Unterschied, den Architektur macht.
Architektur für KI sieht anders aus als Architektur ohne KI
Wer 2026 Plattformen baut, baut sie für KI mit. Nicht weil KI heute schon alles tragen muss, sondern weil sie morgen als nächstes Bauteil eingehängt wird. Architektur erkennt, wenn das nächste Bauteil KI heißt. Sieben Eigenschaften gehören dann zum Fundament:
- RAG-fähige Datenmodelle. Strukturierte Inhalte, sauber attribuiert, mit Quellenführung. Damit Antworten belegbar bleiben.
- Tool-Use-Layer mit expliziten Verträgen. Definierte APIs, an die Agenten anschließen. Standards wie MCP zeichnen sich ab, sind aber noch nicht etabliert. Entscheidend ist heute, dass die Verträge zwischen Agent und System überhaupt explizit sind, unabhängig vom Protokoll, das sich am Ende durchsetzt.
- Knowledge Graphs und Produktdaten als Maschinen-Inputs. Damit Maschinen lesen, was Menschen geschrieben haben.
- Observability für Agenten. Logs, Traces, Eval-Pipelines. Damit klar bleibt, was ein Agent getan hat und warum.
- Identitäts- und Berechtigungslogik, die auch für Agenten gilt. Damit niemand mit fremden Rechten handelt.
- Governance-by-Design. EU AI Act und DSGVO als Bauteile, nicht als Anhang. Damit Compliance nicht nachträglich eingezogen werden muss.
- Modulare Schnitte zwischen den Bausteinen. Damit der nächste KI-Modell- oder Tool-Wechsel kein Replatforming auslöst. Composable erleichtert diese Schnitte, ist aber nicht die einzige Form. Auch monolithischere Plattformen können sie sauber ziehen, sofern Teams sie diszipliniert führen.
Jedes dieser Bauteile lässt sich einzeln einbauen. Was sie zur Architektur macht, ist die Art, wie sie zusammenpassen. Wer einzelne Bauteile gut baut und die Verbindungen ignoriert, hat eine Sammlung. Keine Plattform.
Was eine KI-Plattform im Betrieb trägt
Die meisten Bauteile, die eine KI-Plattform im Betrieb tragen, stehen nicht im Architektur-Diagramm. Sie entstehen in den Wochen nach Go-Live, wenn Kostenkurven, Fehler des KI-Modells und Datenverschiebungen sichtbar werden. Wer sie nicht einplant, baut sie unter Druck nach.
- Ownership für Datenpipelines, Prompts und Retrieval-Strategien. Inklusive Versionierung, damit nachvollziehbar bleibt, welche Version eines Prompts welches Verhalten erzeugt hat.
- Kostenkontrolle pro Workflow. Token-Verbräuche, Drittanbieter-Limits, Eskalationspfade bei Anomalien. KI-Kosten sind variabel und können in zwei Wochen aus dem Ruder laufen.
- Fallbacks bei Fehlern des KI-Modells. Was passiert, wenn die API zwanzig Minuten nicht antwortet oder eine Antwort offensichtlich falsch ist. Wer die Antwort nicht in der Architektur hat, hat sie im Support.
- Human-in-the-loop-Pfade für kritische Entscheidungen. Klar definierte Schwellen, ab denen ein Mensch entscheidet. Welche Aktion ein Agent autonom ausführen darf und welche freigegeben werden muss.
- Observability für Agentenaktionen. Wer hat was getan, mit welchen Daten, in wessen Auftrag. Für Audit, für Debugging, für die Frage „warum hat der Agent das gemacht“.
- Security-Grenzen zwischen Agent und Backend. Ein Agent erbt nicht die Rechte der Person, die ihn anstößt. Service-Identitäten, gescopte Token, klare Trennung zwischen Lese- und Schreibrechten.
- Datenlebenszyklen. Was darf in den Retrieval-Index, was wird gelöscht, wie lange werden Inputs gespeichert. Datenschutz und Modellqualität laufen hier zusammen.
Diese Bauteile sind weniger glamourös als KI-Modell-Demos. Sie entscheiden, ob eine KI-Anwendung im zweiten Halbjahr noch finanzierbar, prüfbar und steuerbar ist. Architektur ist die eine Hälfte. Organisation ist die andere. KI im Betrieb braucht Rollen, die in klassischen IT-Org-Charts selten stehen: Eigentümer:innen für Datenprodukte, Review-Boards für KI-Modellwechsel, Prompt-Engineering im Produktteam, Enablement, das nicht nur Entwickler:innen erreicht. Wer KI in einem klassischen Projektsetup führt, läuft in dieselben Schnittstellenprobleme wie vor zehn Jahren bei Commerce-Plattformen, nur schneller.
Vier Aggregatzustände von KI in der Plattform
Wer über KI-Architektur redet, sollte vorher klären, über welche Form von KI gesprochen wird. Vier Aggregatzustände werden im Alltag häufig verwechselt, obwohl sie unterschiedliche Architektur-Ansprüche stellen:
- KI-Feature. Eine punktuelle KI-Funktion in einem bestehenden Produkt. Beispiel: semantische Produktsuche. Architektur-Anspruch: gering, isoliert einbaubar, wenig Folgewirkung im Stack.
- KI-Workflow. Mehrere KI-Schritte unterstützen einen menschlichen Prozess. Beispiel: assistierte Angebotserstellung mit Daten aus ERP, PIM und CRM. Architektur-Anspruch: Daten- und Berechtigungsfluss über mehrere Systeme, Versionierung der Schritte.
- KI-Agent. Eigenständig handelnde Komponente mit Tool Use und Entscheidungslogik. Beispiel: Service-Agent, der Tickets klassifiziert, Daten zieht, Antworten erzeugt, eskaliert. Architektur-Anspruch: Observability, Security-Grenzen, Fallbacks, Audit, klare Verträge nach außen.
- AI-native Plattform. Architektur, die KI als integralen Bestandteil mehrerer Bausteine voraussetzt. Beispiel: Commerce-Plattform mit RAG, Agenten und Recommendern im selben Stack. Architektur-Anspruch: alle Punkte zuvor plus modulare Schnitte und Governance über mehrere Teams. (Der Begriff „AI-native“ hat sich in dieser Form etabliert und wird bewusst beibehalten.)
Die Diskussion über KI-Architektur kippt je nach Aggregatzustand. Ein KI-Feature lässt sich tragen, ohne die Plattform anzufassen. Eine AI-native Plattform funktioniert nicht ohne Architektur, die KI als Bauteil mitgedacht hat. Dazwischen verläuft die wichtigste Entscheidung, die in den meisten KI-Vorhaben zu spät getroffen wird: Welcher Aggregatzustand ist das Ziel, und in welcher Reihenfolge wird darauf zugesteuert.
Der Engpass verschiebt sich
KI beschleunigt Implementierung massiv. Generatoren schreiben Code, refaktorisieren Strukturen, erzeugen Tests, übersetzen Anforderungen in Module. Was lange als Engpass galt, ist seltener der Engpass: die reine Code-Produktion. Engpass werden andere Stellen. Welche Architektur trägt diese Bausteine im Betrieb. Welche Verträge bestehen zwischen Agent, System und Mensch. Wer hat Ownership für Daten, Prompts, Retrieval-Strategien. Wer prüft, wenn ein KI-Modellwechsel das Verhalten in der Produktion verändert. Wer beantwortet die Frage, was eine Aktion gekostet hat und ob sie korrekt war.
In unserem Maschinenraum nutzen wir KI an vielen Stellen: für Codereviews, für Refactorings, für Pair-Coding, für Testautomation. Sie beschleunigt uns. Sie ersetzt die Architekt:innen nicht. Architektur kommt von Menschen, die zwölf Migrationen und drei Replattformings hinter sich haben und wissen, an welcher Stelle KI-Modelle wechseln werden, welche Schnitte modular bleiben müssen, welche Kostenmodelle ein Workflow im Betrieb verträgt und welche Eskalationspfade die Organisation hält. Wer diese Arbeit überspringt, bekommt eine plausible Folie. Nicht das Bauwerk, das sich im dritten Quartal noch erweitern lässt.
Was wir auf der K5 in Berlin zeigen
Am 24. und 25. Juni 2026 sind wir mit einem Stand auf der K5 in Berlin. Wer Composable, Agentic Commerce, RAG-basierte Knowledge Bots, Scan-to-Order, GEO oder KI-Produktberatung in der eigenen Plattform plant, kann am Stand vorbeikommen und sich zwanzig Minuten Zeit nehmen. Wir zeigen, wie die einzelnen Bauteile in einem realen Stack zusammenpassen. Termin am Stand vorab buchen.
