Beim Zertifikatsanbieter eMudhra wurde die Kompromittierung privater Schlüssel mehrerer Zwischenzertifikate nachgewiesen. Software, die diesen Zertifikatsketten weiterhin vertraut, kann dadurch gefälschte HTTPS-Gegenstellen akzeptieren. Das ist auch für Unternehmen relevant, deren WordPress-Website oder Magento-Shop selbst ein Zertifikat eines anderen Anbieters verwendet.

Für Betreiber steht insbesondere die Kommunikation mit externen Diensten im Mittelpunkt. Zahlungsabwicklung, Backups oder Schnittstellen können auf unterschiedliche Zertifikatslisten zurückgreifen. Wir empfehlen deshalb eine gezielte Prüfung durch Hosting und technische Betreuung.

Quelle: Mozilla-Vorfallsbericht, abgerufen am 12.11.2026.

Das Wichtigste für Entscheider und Entscheiderinnen

Quellen: Mozilla-Vorfallsbericht und Disclosure-Seite, jeweils abgerufen am 12.11.2026. Die vorgeschlagenen Prüfaufträge sind unsere Handlungsempfehlung.

Was bei eMudhra passiert ist

Bei HTTPS prüft die verbindungsaufbauende Software das Zertifikat der Gegenstelle. Dafür verwendet sie vertrauenswürdige Zertifizierungsstellen als Grundlage. Ein Server kann diese Prüfung beispielsweise durchführen, bevor er Daten an eine externe API übermittelt.

Am 17. Oktober 2026 wurde die Kontrolle über private Schlüssel von acht eMudhra-Zwischenzertifikaten nachgewiesen. Sechs betreffen TLS, zwei die Signierung von Software. Laut dem später veröffentlichten Vorfallsbericht führte ein Fehler bei der Verarbeitung des Schlüsselmaterials zu rekonstruierbaren privaten Schlüsseln der betroffenen ECDSA-Zwischenzertifikate.

Der Bericht nennt außerdem acht zusätzliche RSA-Zwischenzertifikate, die am 7. November wegen Betriebseinstellung widerrufen wurden. Bei diesen beschreibt eMudhra Probleme beim Umgang mit dem Schlüsselmaterial. Das ist von der nachgewiesenen Rekonstruierbarkeit der ursprünglichen acht ECDSA-Schlüssel zu unterscheiden.

Quellen: Microsoft zur Einordnung der acht Schlüssel und vollständiger Vorfallsbericht in Kommentar 82, jeweils abgerufen am 12.11.2026.

Die betroffenen Zwischenzertifikate wurden widerrufen. Browserhersteller haben zusätzliche Sperren verteilt. Bei Software mit eigener Zertifikatsliste oder fehlender Verarbeitung von Widerrufsinformationen kann jedoch eine gesonderte Aktualisierung erforderlich sein.

Quelle: Disclosure-Seite zum eMudhra-Vorfall, abgerufen am 12.11.2026.

Welche Geschäftsprozesse betroffen sein können

Ein Angreifer könnte mit dem betroffenen Schlüsselmaterial einen fremden Dienst nachahmen. Um eine bestehende Verbindung abzufangen, muss er zusätzlich den Datenverkehr umleiten oder sich in dessen Übertragungsweg befinden. Ob der Angriff gelingt, hängt auch von weiteren Prüfungen des jeweiligen Clients ab.

Quelle: Disclosure-Seite mit technischen Erläuterungen, abgerufen am 12.11.2026.

Für WordPress und Magento ergeben sich daraus beispielsweise folgende zu prüfende Bereiche:

Diese Beispiele sind eine Übertragung des Angriffswegs auf typische Integrationen. Sie sind keine Meldungen über nachgewiesene Angriffe auf die genannten Systeme.

Was bei WordPress geprüft werden sollte

WordPress verwendet für seine HTTP-API standardmäßig eine mitgelieferte Zertifikatsdatei. Die offizielle Dokumentation nennt dafür wp-includes/certificates/ca-bundle.crt. Ein Update des Servers aktualisiert diese mitgelieferte Datei nicht automatisch.

Quelle: WordPress-Dokumentation zur HTTP-API, abgerufen am 12.11.2026.

WordPress 7.1.4 vom 28. Oktober 2026 enthält laut Hersteller bereits eine Aktualisierung der Stammzertifikate wegen des eMudhra-Widerrufs. Die Korrekturen wurden auch für ältere betroffene Versionszweige bereitgestellt. Betreiber sollten den installierten Sicherheitsstand konkret prüfen lassen.

Quelle: Offizielle Versionsinformationen zu WordPress 7.1.4, abgerufen am 12.11.2026.

Der Sansec-Leitfaden nennt beim Abruf noch keinen behobenen WordPress-Release. Diese Angabe ist durch die neuere Herstellerinformation überholt. Für WordPress selbst sollte ein passendes Herstellerupdate gegenüber einem vorübergehenden manuellen Dateiaustausch bevorzugt werden.

Zusätzlich sind Plugins und mitgelieferte Bibliotheken mit eigenen Zertifikatslisten zu prüfen. Deren Zustand lässt sich aus der WordPress-Version allein nicht ableiten.

Technische Anleitung: WordPress aktualisieren. Hinweise zu separat mitgelieferten Listen: Sansec-Leitfaden. Beide abgerufen am 12.11.2026.

Was bei Magento und Adobe Commerce geprüft werden sollte

Bei Magento sollte die technische Betreuung insbesondere die installierten Composer-Abhängigkeiten und die von Erweiterungen mitgelieferten Bibliotheken untersuchen. Dazu können auch Bibliotheken für Zahlungsdienste gehören. Sansec beschreibt die Maßnahmen nach der jeweils gefundenen Zertifikatsdatei.

Technische Anleitung: Sansec mit Maßnahmen nach Datei und Bibliothek, abgerufen am 12.11.2026.

Ein dokumentiertes Beispiel ist composer/ca-bundle. Die Releases 1.4.16 und 1.6.0 enthalten Korrekturen zum eMudhra-Vorfall. Ob das Paket installiert ist und welche Version eingesetzt wird, muss am konkreten Projekt geprüft werden.

Quelle: Offizielle Releases von composer/ca-bundle, abgerufen am 12.11.2026.

Für die dauerhafte Behebung muss auch die Paketverwaltung berücksichtigt werden. Composer installiert bei vorhandener Lockdatei die dort festgelegten Versionen. Eine erneute Installation führt deshalb nicht automatisch zu korrigierten Abhängigkeiten. Wir empfehlen, erforderliche Änderungen im regulären Entwicklungs- und Bereitstellungsprozess umzusetzen und die betroffenen Shopfunktionen zu testen.

Technischer Hintergrund: Composer-Dokumentation zu Installation und Aktualisierung, abgerufen am 12.11.2026.

Wann das eigene Website-Zertifikat geprüft werden muss

Die Vertrauenslisten für ausgehende Verbindungen und das Zertifikat der eigenen Website erfüllen unterschiedliche Aufgaben. Beide Bereiche können im Zusammenhang mit dem Vorfall Prüfbedarf haben.

Microsoft kündigte am 11. November an, ab dem 16. November 2026 auch die verbleibenden eMudhra-Stammzertifikate aus seinen Vertrauenslisten zu entfernen. Der Zeitpunkt der Umsetzung hängt vom jeweiligen Produkt und dessen Aktualisierung ab.

Unternehmen sollten daher klären, ob ihre Website oder angebundene Dienste eine betroffene Zertifikatskette verwenden. Gegebenenfalls wird ein Ersatz oder eine alternative vertrauenswürdige Kette benötigt, um Verbindungsabbrüche zu vermeiden. Ein pauschaler Austausch aller Website-Zertifikate lässt sich daraus nicht ableiten.

Quelle und weiterführende Hinweise: Microsoft-Mitteilung einschließlich Update vom 11. November, abgerufen am 12.11.2026.

Was Unternehmen jetzt beauftragen sollten

Wir empfehlen eine gemeinsame Prüfung durch Hosting und technische Betreuung. Die genaue Zuständigkeit richtet sich nach dem jeweiligen Vertrag.

Die PHP-Konfiguration verdient dabei besondere Aufmerksamkeit. Sie kann festlegen, welche CA-Datei beziehungsweise welches Zertifikatsverzeichnis für bestimmte Verbindungen verwendet wird. Wir empfehlen, die tatsächlich genutzten Einstellungen zu dokumentieren.

Technischer Hintergrund: PHP-Dokumentation zur OpenSSL-Konfiguration, abgerufen am 12.11.2026.

Wie sich die Behebung nachweisen lässt

Die Prüfung sollte an den tatsächlich verwendeten Clients und Zertifikatslisten erfolgen. Ein erfolgreicher Browsercheck ist kein Nachweis für einen serverseitigen PHP-Aufruf. Ein fehlgeschlagener Verbindungsversuch muss ebenfalls fachlich eingeordnet werden, weil beispielsweise ein Netzwerkfehler dieselbe äußerlich sichtbare Folge haben kann.

Testmöglichkeiten und Erläuterungen: Disclosure-Seite, abgerufen am 12.11.2026.

Sansec beschreibt Prüfungen einzelner Zertifikatsdateien und weist auf das mögliche Überschreiben manueller Korrekturen hin.

Technische Anleitung: Sansec unter „Testing a fix“ und „Replacing a bundle file“, abgerufen am 12.11.2026.

Was über tatsächliche Angriffe bekannt ist

Zu tatsächlich über diesen Angriffsweg kompromittierten WordPress- oder Magento-Installationen liegen bisher wohl keine gesicherten Informationen vor. Die Disclosure-Seite erklärt, dass unklar ist, ob Angreifer die Schwäche gegen Clients außerhalb des Browserumfelds ausgenutzt haben.

Quelle: Disclosure-Seite zum Kenntnisstand, abgerufen am 12.11.2026.

Häufige Fragen von Website- und Shopbetreibern

Kann mein Shop trotz eines Zertifikats eines anderen Anbieters betroffen sein?

Ja. Für ausgehende Verbindungen ist entscheidend, welchen Zertifikatsketten die verbindungsaufbauende Software vertraut. Der Aussteller des eigenen Website-Zertifikats beantwortet diese Frage nicht.

Reicht ein Update von WordPress oder Magento?

Das lässt sich nur am konkreten Projekt beurteilen. Zusätzlich müssen gegebenenfalls separat mitgelieferte Zertifikatslisten von Erweiterungen und die Systemumgebung berücksichtigt werden.

Welche Bestätigung sollte die technische Betreuung liefern?

Wir empfehlen eine kurze Abschlussmeldung mit den geprüften Systemen und Komponenten, vorgenommenen Änderungen, Testergebnissen sowie verbleibenden offenen Punkten.

Weitere Informationen zu Magento Betreuung durch KonVis

Weitere Informationen zu WordPress Betreuung durch KonVis

Weiterführende Quellen und technische Anleitungen

Alle folgenden Quellen wurden am 12.11.2026 abgerufen.

• Sansec-Leitfaden zu kompromittierten Zertifizierungsstellen
• Disclosure-Seite zum eMudhra-Vorfall
• Mozilla-Vorfallsbericht
• Vollständiger Vorfallsbericht in Kommentar 82
• Microsoft-Mitteilung mit aktuellem Umstellungsplan
• WordPress 7.1.4 mit Angaben zur Zertifikatsaktualisierung
• WordPress aktualisieren
• WordPress-HTTP-API und Zertifikatsdatei
• Offizielle Releases von composer/ca-bundle
• Composer-Dokumentation zu Installation und Aktualisierung
• PHP-Konfiguration für OpenSSL
• curl-Dokumentation zur Zertifikatsprüfung

The post Kompromittierte Zertifizierungsstelle eMudhra und die Folgen für WordPress und Magento appeared first on KonVis - mehr Erfolg Online.

Dieser Beitrag beschäftigt sich mit der Frage, wie Unternehmen KI für die Produktsuche, Beratung, Konfiguration und Bestellvorbereitung einsetzen können. Der Schwerpunkt liegt auf bestehenden Magento-Shops und einer möglichen technischen Architektur, die ich als „AI-Zone“ bezeichnen möchte.

Der Artikel hat ausdrücklich keinen Anspruch, in fünf Jahren noch aktuell zu sein. Es handelt sich um meine Überlegungen zu den technischen Möglichkeiten im Jahr 2026 und zu denkbaren Entwicklungen in den kommenden Jahren.

Ich beschäftige mich seit einigen Monaten mit dem Gedanken, dass Magento-Shops eigentlich eine ziemlich gute Ausgangsbasis für AI Commerce und die weitere Entwicklung von KI-gestützten Einkaufsprozessen sein müssten. Dabei denke ich ausdrücklich an andere Formen des Onlinehandels als die Shops, die wir heute kennen.

Vielleicht werden in fünf bis zehn Jahren tatsächlich überwiegend KI-Agenten über Schnittstellen wie MCP mit Shopsystemen kommunizieren. Ob und wann sich das durchsetzt, lässt sich heute kaum seriös prognostizieren. Die für mich interessantere Frage ist daher, welche Möglichkeiten sich bereits jetzt umsetzen lassen und welche Vorteile Unternehmen sowie deren Kunden davon haben könnten.

Warum Magento eine interessante Grundlage für AI Commerce sein könnte

Magento bietet aus meiner Sicht mehrere Eigenschaften, die für den Einsatz von KI besonders interessant sind.

Kontrolle über Daten und Kernsysteme

Magento Open Source kann auf einer selbst betriebenen oder individuell verwalteten Hosting-Infrastruktur eingesetzt werden. Unternehmen haben damit weitreichende Möglichkeiten, den Betrieb, die Datenhaltung, die Erweiterungen und die verfügbaren Schnittstellen selbst zu kontrollieren.

Das halte ich gerade bei KI für wichtig. Man kann selbst entscheiden, welche Daten eine KI erhalten darf, welche Systeme angesprochen werden und wo die Verarbeitung stattfindet. Die tatsächliche Datenkontrolle hängt allerdings auch davon ab, welche externen KI-Dienste und weiteren Systeme eingesetzt werden.

Headless Commerce und individuell entwickelbare Frontends

Magento bietet mit REST und GraphQL bereits umfangreiche Möglichkeiten, externe Anwendungen anzubinden und eigene Frontends zu entwickeln. Das Frontend muss damit nicht zwangsläufig eng mit dem eigentlichen Shopsystem verbunden sein.

Genau diese Trennung halte ich für ausgesprochen interessant, weil sich dadurch vollkommen neue Anwendungen entwickeln lassen, ohne dass dafür zwangsläufig der komplette bestehende Onlineshop (nachgelagerte Logistik, Rechnungslegung usw.) umgebaut werden muss.

Open Source und individuelle Erweiterbarkeit

Magento ist ein international genutztes Open-Source-Shopsystem. Unternehmen können eigene Erweiterungen entwickeln und bestehende Prozesse über zusätzliche Schnittstellen zugänglich machen.

Gerade diese Möglichkeiten halte ich für interessant, wenn KI-Anwendungen neue Formen der Produktauswahl oder Bestellvorbereitung ermöglichen sollen. Durch die Programmierung individueller Magento-Erweiterungen lassen sich beispielsweise zusätzliche Funktionen bereitstellen, die genau auf die benötigten Daten und Prozesse zugeschnitten sind.

Das gilt natürlich nicht ausschließlich für Magento. Auch andere Shopsysteme können für vergleichbare Architekturen geeignet sein. Für mich ist Magento besonders interessant, weil sich dort individuelle B2B-Prozesse mit entsprechenden Erweiterungen umsetzen lassen und diese anschließend gezielt über APIs bereitgestellt werden können.

Was sollte eine KI auf keinen Fall dürfen?

Bevor man über die Möglichkeiten von AI Commerce nachdenkt, sollte man sich meiner Meinung nach zunächst überlegen, was eine KI auf keinen Fall machen können sollte.

Ich betrachte eine KI aktuell ungefähr wie einen extrem fähigen neuen Mitarbeiter, von dem man allerdings weiß, dass er gelegentlich vollkommen falsche Entscheidungen trifft und diese womöglich auch noch sehr überzeugend begründet. Diesem Mitarbeiter würde vermutlich niemand am ersten Arbeitstag vollständigen Administratorzugriff auf das Shopsystem, die Warenwirtschaft und sämtliche Kundenkonten geben.

Genau das passiert technisch aber unter Umständen, wenn KI-Systeme mit umfangreichen API-Berechtigungen ausgestattet werden.

Aus meiner Sicht sollte eine KI, die Kunden bei der Produktauswahl unterstützt, insbesondere keine Berechtigung erhalten, eigenständig Bestellungen verbindlich auszulösen, Produkte anzulegen, Preise zu verändern, Bestellungen zu stornieren oder andere kritische Shopprozesse zu manipulieren.

Das betrifft insbesondere KI-Agenten, die eigenständig Werkzeuge und Schnittstellen aufrufen können. Auch bei internen KI-Anwendungen würde ich mit möglichst wenigen Berechtigungen beginnen. Welche zusätzlichen Funktionen später sinnvoll sein können, hängt vom konkreten Anwendungsfall und den vorhandenen Kontrollmechanismen ab.

Für die Kundenberatung sehe ich jedenfalls keinen vernünftigen Grund, einer KI vollständigen Zugriff auf den Magento-Administrationsbereich zu geben. Dies endet sonst in den aus den Medien bekanntem Chaos...

Die AI-Zone als vorgelagerter Bereich des Onlineshops

Mein Ansatz wäre, eine Art AI-Zone vor den eigentlichen geschäftskritischen Shopprozessen einzurichten.

In diesem Bereich kann die KI den Kunden bei seiner Arbeit unterstützen. Sie kann Anforderungen verstehen, Informationen verarbeiten, Produkte suchen, mögliche Lösungen ermitteln und Vorschläge machen. Im Grunde übernimmt sie damit zahlreiche Aufgaben, die der Kunde bisher selbst erledigen musste.

Das Ergebnis dieser Arbeit könnte beispielsweise ein vollständig vorbereiteter Warenkorb sein. Die KI hat die passenden Produkte ermittelt, die benötigten Mengen vorgeschlagen und gegebenenfalls weitere Informationen vorbereitet.

Auch die Übernahme von Liefer- und Rechnungsdaten oder die Vorauswahl einer verfügbaren Zahlungsart wäre denkbar, sofern dies technisch ausdrücklich vorgesehen und datenschutzrechtlich zulässig ist.

Die verbindliche Bestellung soll jedoch weiterhin durch den Kunden beziehungsweise den berechtigten Einkäufer ausgelöst werden.

Gerade im B2B-Bereich kann es zusätzlich Freigabeprozesse, Budgetgrenzen und unterschiedliche Einkaufsberechtigungen geben. Diese müssen weiterhin durch das eigentliche Shopsystem beziehungsweise die dafür vorgesehenen Geschäftsprozesse kontrolliert werden.

Wie die Trennung konkret aussehen könnte

Eine mögliche Architektur wäre:

1. Der Kunde übermittelt seine Anforderungen an die KI-Anwendung, beispielsweise als Text, Datei oder Foto.
2. Die KI analysiert die Informationen und ermittelt passende Produkte anhand der freigegebenen Produktdaten.
3. Der Kunde prüft das Ergebnis und kann Angaben ergänzen oder korrigieren.
4. Die KI-Anwendung übergibt die ausgewählten Artikel über eine begrenzte Schnittstelle an den Warenkorb.
5. Magento prüft unter anderem Produktgültigkeit, Mengen, Preise, Verfügbarkeit und kundenspezifische Berechtigungen.
6. Der Kunde gelangt zum regulären Checkout und gibt die Bestellung nach Prüfung selbst frei.

Das ist natürlich nur ein mögliches Szenario. Es verdeutlicht aber, wo ich die Trennung zwischen KI und Shopprozessen ansetzen würde. Die KI darf bei der Vorbereitung sehr flexibel arbeiten, während die eigentlichen Transaktionsregeln weiterhin durch klar definierte Prozesse kontrolliert werden.

Der klassische KI-Chat ist für mich wenig interessant

Wenn über KI im E-Commerce gesprochen wird, landet man häufig sehr schnell beim KI-Chatbot. Diesen Ansatz finde ich persönlich eher langweilig.

Ein Chatbot, der Kundenfragen beantwortet, kann sicherlich sinnvoll sein. Gerade wenn Mitarbeiter im Innendienst regelmäßig die gleichen Fragen beantworten müssen, lassen sich damit womöglich Kosten und Arbeitszeit sparen.

Aber welchen echten Vorteil hat der Kunde davon? Wenn sich ein Kunde vorher mit einem Mitarbeiter unterhalten musste und jetzt mit einem Chatbot, dann benötigt er für die Unterhaltung möglicherweise immer noch genauso viel Zeit. Im ungünstigen Fall ist der Kunde anschließend sogar genervt, weil die KI sein Anliegen falsch verstanden hat oder er mehrere Rückfragen beantworten musste.

Mich interessieren daher besonders KI-Anwendungen, bei denen der Kunde selbst deutlich weniger Arbeit hat.

Ein guter Shopping-Assistent sollte idealerweise bereits wissen, welche Informationen für den nächsten Schritt benötigt werden. Warum sollte er immer erst fragen „Wie kann ich Ihnen helfen?“, wenn er auch direkt einen passenden Prozess anbieten könnte?

Der richtige Input ist entscheidend

Ich glaube, einer der größten Hebel liegt darin, sich zu überlegen, wie ein Kunde seine Anforderungen möglichst einfach an einen Onlineshop übergeben kann.

Ein klassischer Onlineshop erwartet vom Kunden häufig, dass er selbst nach Produkten sucht, Artikelnummern kennt, Kategorien durchsucht oder technische Filter bedient. Gerade bei komplexen B2B-Produkten kann das aufwendig sein.

Ein KI-gestützter Einkaufsprozess könnte deutlich anders aussehen. Anstatt den Kunden durch eine Vielzahl von Suchmasken und Eingabefeldern zu führen, könnte man überlegen, welche Informationen er bereits hat und wie diese möglichst einfach verarbeitet werden können.

Anforderungslisten und Dokumente hochladen

Stellen wir uns einen B2B-Shop für Industriebedarf vor.

Ein Einkäufer benötigt zwanzig unterschiedliche Artikel. Bisher müsste er möglicherweise jeden Artikel einzeln suchen und anschließend in den Warenkorb legen. Warum sollte er das weiterhin tun müssen, wenn er seine Anforderungsliste bereits als Datei vorliegen hat?

Er könnte diese Liste einfach hochladen. Das Dokument könnte eine Excel-Datei, eine PDF-Datei, eine Stückliste oder auch eine E-Mail mit den benötigten Artikeln sein.

Die KI verarbeitet die Informationen und ermittelt anhand der Produktdaten mögliche passende Artikel. Bei eindeutigen Treffern könnte die Zuordnung automatisch vorbereitet werden. Bei unklaren Produkten fragt die Anwendung gezielt nach oder zeigt mehrere mögliche Alternativen.

Das Ergebnis ist ein vorbereiteter Warenkorb, den der Einkäufer nur noch prüfen muss. Der Vorteil liegt dann nicht primär darin, dass der Händler weniger Aufwand hat. Der Einkäufer kann sich im Idealfall einen erheblichen Teil der bisherigen Such- und Eingabearbeit sparen.

Frühere Bestellungen und Wiederbestellungen nutzen

Bei bestehenden B2B-Kunden sind häufig bereits Informationen vorhanden, die für eine neue Bestellung relevant sein können. Dazu gehören beispielsweise frühere Bestellungen, regelmäßig gekaufte Artikel, bekannte Maschinen oder kundenspezifische Sortimente.

Warum sollte ein Assistent diese Informationen ignorieren?

Wenn ein Kunde regelmäßig Ersatzteile für bestimmte Maschinen bestellt, könnte die Anwendung direkt entsprechende Vorschläge anbieten. Beispielsweise könnte der Kunde gefragt werden, ob er erneut Ersatzteile für eine bestimmte Maschine benötigt oder seine aktuelle Bedarfsliste hochladen möchte, damit diese mit dem bisher bestellten Sortiment abgeglichen werden kann.

Voraussetzung ist natürlich, dass der Kunde authentifiziert wurde und die KI ausschließlich auf Daten zugreifen kann, für die er berechtigt ist. Gerade kundenspezifische Preise, Bestellungen und andere Unternehmensdaten dürfen nicht versehentlich zwischen unterschiedlichen Kunden zugänglich werden.

Bilder als Eingabe für die Ersatzteilsuche

Noch interessanter finde ich die Möglichkeiten, die sich durch Bilder ergeben.

Nehmen wir einen Maschinenbauer oder einen Händler für technische Ersatzteile. Ein Kunde benötigt ein Ersatzteil, kennt aber weder die Artikelnummer noch die genaue Bezeichnung.

Bisher müsste er womöglich herausfinden, um welches Bauteil es sich handelt, technische Dokumentationen durchsuchen oder den Innendienst kontaktieren.

Eine mögliche KI-Anwendung könnte hier ganz anders arbeiten. Der Kunde öffnet eine Web-App auf seinem Smartphone und fotografiert das defekte Bauteil. Dafür muss er keine zusätzliche Anwendung installieren, da eine entsprechend entwickelte Web-App direkt im Browser auf die Smartphone-Kamera zugreifen kann, sofern der Nutzer dies erlaubt.

Die KI versucht anschließend, das Bauteil zu identifizieren. Möglicherweise erkennt sie bereits den Hersteller oder die Bauart. Sie könnte zudem sichtbare Beschriftungen, Maße oder andere Merkmale auswerten.

Falls keine eindeutige Zuordnung möglich ist, kann die Anwendung gezielt nachfragen. Beispielsweise nach der Maschinenbezeichnung, einer Seriennummer oder einem weiteren Foto aus einer bestimmten Perspektive.

In einer entsprechend aufgebauten Anwendung könnten diese Informationen anschließend mit Ersatzteilkatalogen, Maschinenlisten oder Herstellerdaten abgeglichen werden.

Wichtig ist dabei, dass eine KI-Erkennung nicht automatisch als zweifelsfreie Produktidentifikation behandelt wird. Ein Foto kann wichtige Informationen liefern. Ob damit ein Ersatzteil zuverlässig identifiziert werden kann, hängt von der Produktart, den verfügbaren Referenzdaten und dem jeweiligen Anwendungsfall ab. Gerade bei sicherheitskritischen Bauteilen wären zusätzliche Prüfungen erforderlich.

Trotzdem halte ich diesen Ansatz für wesentlich interessanter als einen allgemeinen Chatbot. Der Kunde muss im Idealfall nur noch fotografieren, einige Angaben bestätigen und kann anschließend das passende Ersatzteil auswählen.

Wie sollte man KI-Projekte für B2B-Shops planen?

Zunächst die eigenen Prozesse verstehen

Meiner Meinung nach ist das einer der wichtigsten Punkte überhaupt. Ein Unternehmen muss seine eigenen Prozesse verstehen, bevor es versucht, diese mit KI zu verbessern.

Dabei reicht es nicht aus, lediglich die bisherigen Arbeitsschritte aufzuschreiben und anschließend zu überlegen, welche davon eine KI übernehmen könnte. Man sollte sich vielmehr anschauen, welche Informationen an welcher Stelle benötigt werden, warum der Kunde eine bestimmte Angabe machen muss und welche Entscheidungen anhand dieser Informationen getroffen werden.

Gerade in komplexen B2B-Prozessen gibt es häufig eine Vielzahl von Einzelschritten, die historisch entstanden sind. Vielleicht existiert ein bestimmter Schritt heute nur deshalb, weil ein Mitarbeiter bislang keine andere Möglichkeit hatte, die benötigte Information zu bekommen.

Wenn eine KI diese Information direkt aus einem Dokument, Foto oder anderen Daten ableiten kann, könnte der bisherige Schritt vollständig entfallen.

Daher halte ich das Verständnis der Daten, Informationen und Entscheidungsprozesse für eine der wichtigsten Voraussetzungen erfolgreicher KI-Projekte.

Genau an dieser Stelle kann eine unabhängige Betrachtung der bestehenden Prozesse sinnvoll sein. Bei unserer Magento-Beratung und Konzeption beschäftigen wir uns unter anderem mit der Frage, welche Abläufe in einem bestehenden Shop verbessert werden können und welche technische Umsetzung dafür geeignet ist.

Überlegen, wie der perfekte Prozess aussehen würde

Ich würde bei der Konzeption bewusst versuchen, mich von den bisherigen technischen Abläufen zu lösen.

Stellen wir uns erneut die Ersatzteilsuche vor. Eine klassische Verbesserung wäre beispielsweise, die Eingabe einer Seriennummer einfacher zu gestalten. Man könnte Hilfetexte ergänzen oder erklären, wo der Kunde die Seriennummer findet.

Das ist sicherlich sinnvoll. Aber warum nicht zunächst überlegen, wie der perfekte Ablauf aus Sicht des Kunden aussehen würde?

Vielleicht möchte der Kunde überhaupt keine Seriennummer eingeben. Er möchte lediglich ein defektes Bauteil fotografieren und sofort erfahren, welches Ersatzteil er benötigt.

Wenn man diesen Wunsch als Ausgangspunkt nimmt, ergeben sich ganz andere Möglichkeiten für die technische Umsetzung. Ob sich diese anschließend wirtschaftlich, zuverlässig und mit vertretbarem Aufwand umsetzen lassen, muss natürlich geprüft werden.

Ich halte es aber für sinnvoll, zunächst den gewünschten Ablauf zu definieren und erst anschließend die technischen Möglichkeiten und Grenzen zu betrachten.

Headless AI Commerce als technische Architektur

Hier kommt für mich das Thema Headless Commerce ins Spiel.

Unter Headless Commerce versteht man vereinfacht die technische Trennung zwischen dem Frontend, mit dem der Kunde interagiert, und den eigentlichen Commerce-Funktionen im Backend. Diese Funktionen werden über Schnittstellen bereitgestellt.

Magento unterstützt solche Architekturen bereits über REST und GraphQL. Für KI-Anwendungen ergibt sich dadurch eine interessante Möglichkeit, da man neue Anwendungen entwickeln kann, die unabhängig vom eigentlichen Magento-Frontend betrieben werden und nur gezielt auf benötigte Shopfunktionen zugreifen.

Das könnten beispielsweise ein KI-gestützter Produktkonfigurator, eine Ersatzteilsuche oder ein Assistent für die Verarbeitung von Anforderungslisten sein.

Dabei muss man meiner Meinung nach keineswegs den gesamten bestehenden Magento-Shop auf Headless umstellen. Die KI-Anwendung könnte zunächst als eigenständige, vorgelagerte Anwendung entwickelt werden, während der bisherige Shop weitgehend unverändert bleibt.

Das halte ich insbesondere für Unternehmen interessant, die einen etablierten und funktionierenden B2B-Shop betreiben. Die eigentliche Magento-Programmierung kann sich dadurch auf die Funktionen konzentrieren, die für die Anbindung und kontrollierte Verarbeitung der Daten tatsächlich benötigt werden.

AI-Zone und Shop-Backend technisch trennen

Die AI-Zone wäre in meiner Vorstellung ein technisch eigenständiger Bereich, in dem sich neue KI-basierte Funktionen entwickeln und betreiben lassen.

Dort können Anwendungen deutlich flexibler verändert und neue Ideen ausprobiert werden. Der entscheidende Punkt ist, dass die AI-Zone nur ausdrücklich freigegebene Funktionen des eigentlichen Shops nutzen darf.

Ein KI-Konfigurator benötigt beispielsweise Produktinformationen, technische Eigenschaften und möglicherweise Verfügbarkeiten. Er braucht aber keinen Zugriff auf die Magento-Administrationsfunktionen zur Änderung von Produktpreisen oder zur Stornierung von Bestellungen.

Wichtig ist hier, dass es nicht nur um KI Anwendungen geht, sondern auch um Funktionen/Tools/Anwendungen die VON bzw. MIT KI "eben schnell" entwickelt wurden. Sprich das sind womöglich enorm komplexe Anwendungen, die aber eben schlicht von Innendienst/Marketing/Verkauf primär "entwickelt" wurden.

Für die Übergabe des Ergebnisses wäre womöglich eine einzige klar definierte Funktion ausreichend, welche die geprüften Artikel und Mengen in den Warenkorb übernimmt. Die eigentliche Verarbeitung übernimmt anschließend das Shopsystem.

Natürlich muss auch eine solche Funktion sorgfältig abgesichert werden. Schon Veränderungen an einem Warenkorb können Auswirkungen haben, wenn beispielsweise fremde Warenkörbe manipuliert werden können. Deshalb muss technisch gewährleistet sein, dass nur der berechtigte Kunde und dessen Warenkorb betroffen sind.

Wo MCP eingesetzt werden könnte

Für die Kommunikation zwischen KI-Anwendungen und bestehenden Systemen könnte unter anderem das Model Context Protocol (MCP) genutzt werden.

MCP ermöglicht es, KI-Anwendungen definierte Werkzeuge bereitzustellen. Ein solches Werkzeug könnte beispielsweise Produktinformationen abfragen, eine Ersatzteilzuordnung durchführen oder einen vorbereiteten Warenkorb erzeugen.

Das bedeutet allerdings nicht, dass jede Verbindung zwischen KI und Magento zwangsläufig über MCP erfolgen muss. Je nach Anwendungsfall können direkte REST- oder GraphQL-Schnittstellen sinnvoller sein.

Entscheidend sind aus meiner Sicht die konkret freigegebenen Funktionen und deren Berechtigungen. Eine KI sollte nur die Funktionen aufrufen können, die für ihre jeweilige Aufgabe tatsächlich benötigt werden.

Die sichere Übergabe zwischen AI-Zone und Shop-Backend

An dieser Stelle wird es technisch besonders interessant.

Die AI-Zone und das eigentliche Shopsystem müssen miteinander kommunizieren. Dabei entsteht zwangsläufig eine Grenze zwischen einem Bereich, in dem KI-generierte Informationen verarbeitet werden, und den geschäftskritischen Prozessen des Shops.

Diese Grenze muss sauber geplant werden. Hier geht es neben der generellen Architektur insbesondere um die Programmierung und Absicherung von Magento-Schnittstellen, über die externe Anwendungen mit dem Shop kommunizieren.

KI-Ausgaben grundsätzlich als externe Daten behandeln

Aus meiner Sicht sollte man niemals darauf vertrauen, dass eine KI ihre Ergebnisse schon korrekt liefern wird.

Eine KI kann sich irren, Informationen falsch interpretieren oder unerwartete Daten erzeugen. Außerdem können KI-Anwendungen durch manipulierte Dokumente, Webseiten oder andere Eingaben beeinflusst werden.

Daher müssen die Ergebnisse der KI bei der Übergabe in den Shop genauso kritisch behandelt werden wie andere externe Eingaben.

Ein Beispiel wäre eine KI, die Artikelnummern und Mengen an Magento übermittelt. Die Schnittstelle muss prüfen, ob die übergebenen Daten dem erwarteten Format entsprechen, ob die Artikel existieren und ob der Kunde diese bestellen darf.

Die KI darf dabei nicht beliebige zusätzliche Anweisungen oder Datenfelder an interne Shopfunktionen übermitteln können. Eine solche Übergabe sollte über klar definierte Datenstrukturen und eine entsprechend abgesicherte Schnittstelle erfolgen.

Auch klassische Sicherheitsmaßnahmen bleiben notwendig. Dazu gehören unter anderem eine korrekte Eingabevalidierung, sichere Datenbankzugriffe, Berechtigungsprüfungen und die Begrenzung möglicher Aktionen.

Es wäre beispielsweise falsch, Adressdaten pauschal von Sonderzeichen zu befreien. Gültige Namen und Adressen können selbstverständlich Sonderzeichen enthalten. Entscheidend ist, dass Daten entsprechend ihrer Bedeutung geprüft und anschließend sicher verarbeitet werden.

Die Geschäftsregeln bleiben im Shop

Stellen wir uns vor, die KI hat anhand einer Anforderungsliste zwanzig Artikel ermittelt. Diese werden über eine Schnittstelle an den Warenkorb übergeben.

Magento muss anschließend weiterhin die für den jeweiligen Kunden gültigen Preise, Mengenbeschränkungen, Produktoptionen und weiteren Geschäftsregeln prüfen.

Gerade im B2B-Commerce sind häufig individuelle Preislisten, Kundengruppen, Lieferbedingungen und Freigabeprozesse vorhanden. Die KI kann einen Vorschlag machen, während die verbindlichen Regeln durch die dafür vorgesehenen Shopfunktionen umgesetzt werden.

Dabei halte ich es für besonders wichtig, dass die KI keine Möglichkeit besitzt, diese Regeln über alternative API-Aufrufe zu umgehen.

Eine technische Trennung ist erst dann wirklich sinnvoll, wenn sie auch durch Berechtigungen und kontrollierte Schnittstellen abgesichert ist. Ein eigenständiges Frontend allein reicht dafür nicht aus.

Warum Magento hier interessant ist

Magento bietet für solche Vorhaben bereits zahlreiche Schnittstellen. Zusätzlich können eigene Magento-Erweiterungen entwickelt werden, die genau die benötigten Funktionen bereitstellen.

Es ist somit möglich, für einen KI-Konfigurator beispielsweise eine eigene API zu entwickeln, die ausschließlich definierte Artikeldaten übernimmt und kontrolliert an die Warenkorblogik weitergibt.

Das kann über bestehende Magento-APIs, individuelle REST- oder GraphQL-Endpunkte oder andere geeignete Integrationsverfahren erfolgen. Welcher technische Ansatz sinnvoll ist, hängt von den Anforderungen des konkreten Projekts ab.

Ich würde möglichst einfache, klar begrenzte Übergabepunkte bevorzugen. Je weniger Möglichkeiten die KI-Anwendung hat, direkt in interne Shopabläufe einzugreifen, desto überschaubarer werden die möglichen Auswirkungen von Fehlern.

KI-gestützte Entwicklung (in) der AI-Zone in hoher Geschwindigkeit

Neben dem Einsatz von KI für Kunden interessiert mich ein weiterer Punkt besonders. Die Entwicklung solcher Anwendungen könnte durch KI selbst erheblich beschleunigt werden.

Nehmen wir einen Produktkonfigurator. Bisher musste eine neue Funktion häufig erst konzipiert, durch einen Entwickler umgesetzt, getestet und anschließend veröffentlicht werden.

Mit KI-gestützter Softwareentwicklung können zumindest bestimmte Entwicklungsarbeiten deutlich schneller erfolgen. Ein Mitarbeiter aus dem Vertrieb könnte beispielsweise beschreiben, welche zusätzliche Eingabemöglichkeit für den Konfigurator benötigt wird. Eine Entwicklungs-KI könnte daraufhin einen ersten Umsetzungsvorschlag oder direkt entsprechenden Programmcode erstellen.

Das bedeutet natürlich nicht, dass jede beliebige Anforderung innerhalb weniger Stunden fehlerfrei umgesetzt werden kann. Die Möglichkeiten hängen stark von der Komplexität der Anwendung, den verfügbaren Daten und den technischen Rahmenbedingungen ab.

Trotzdem halte ich die Entwicklungsgeschwindigkeit, die heute bereits bei bestimmten Aufgaben möglich ist, für bemerkenswert.

Fachabteilungen können stärker an der Weiterentwicklung beteiligt werden

Besonders interessant wäre für mich eine Struktur, in der Vertrieb, Innendienst oder Außendienst Änderungen an einer vorgelagerten Anwendung wesentlich direkter anstoßen können.

Die Mitarbeiter wissen häufig sehr genau, wo Kunden Probleme haben und welche Funktionen tatsächlich benötigt werden. Eine KI könnte helfen, diese Anforderungen schneller in konkrete Anwendungsvorschläge umzusetzen.

Vielleicht wird es damit möglich, dass Fachabteilungen einfache Verbesserungen selbst vorbereiten und auf einem Testsystem ausprobieren. Der eigentliche Shop bleibt dabei technisch getrennt und die Kommunikation erfolgt weiterhin über die dafür vorgesehenen Schnittstellen.

Auch KI-generierter Code muss geprüft werden

An dieser Stelle muss man allerdings zwischen zwei unterschiedlichen Dingen unterscheiden.

Eine KI, die Kunden bei der Produktauswahl berät, benötigt bestimmte Berechtigungen zur Laufzeit. Eine KI, die neuen Programmcode erzeugt, kann dagegen Fehler oder Sicherheitsprobleme in eine Anwendung einbauen.

Deshalb sollte auch der Code der AI-Zone nicht ungeprüft in einem produktiven System ausgeführt werden. Eine mögliche Vorgehensweise wäre, Änderungen zunächst in einer getrennten Entwicklungsumgebung zu erzeugen und anschließend auf einem Testsystem zu prüfen.

Dort könnten automatisierte oder händische Tests kontrollieren, ob die Anwendung weiterhin korrekt funktioniert, die freigegebenen Schnittstellen einhält und keine unerlaubten Aktionen ausführt. Zusätzlich müssen sicherheitsrelevante Änderungen entsprechend geprüft werden.

Erst nach erfolgreicher Prüfung wird die neue Version veröffentlicht. Gerade diese Kombination aus schneller Entwicklung und klar definierten technischen Grenzen halte ich für interessant. Damit die Abgrenzung tatsächlich funktioniert, muss auch der Entwicklungs- und Veröffentlichungsprozess entsprechend abgesichert sein.

Welche Risiken bleiben trotz der Trennung bestehen?

Die vorgestellte Architektur könnte bestimmte Risiken reduzieren. Vollständig vermeiden lassen sie sich dadurch nicht.

Bereits die Übermittlung falscher Artikelnummern oder Mengen kann erhebliche Auswirkungen haben, wenn diese Daten ungeprüft weiterverarbeitet werden. Auch falsche Produktempfehlungen können problematisch sein, beispielsweise wenn ein Kunde ein technisch ungeeignetes Ersatzteil bestellt, weil die KI ein Foto falsch interpretiert hat.

Hinzu kommen Fragen zur Datenverarbeitung. Wenn Dokumente mit Kundeninformationen, vertraulichen technischen Zeichnungen oder Einkaufslisten an externe KI-Dienste übertragen werden, muss geklärt sein, wie diese Daten verarbeitet und geschützt werden.

Eine weitere Frage betrifft die Verfügbarkeit und die Kosten. Was passiert, wenn der KI-Dienst ausfällt? Kann der Kunde weiterhin regulär im Shop bestellen? Wie werden die Kosten der KI-Verarbeitung begrenzt, wenn sehr viele Dokumente oder Bilder verarbeitet werden?

Auch solche Fragen sollten bereits bei der Konzeption berücksichtigt werden. Für bestehende B2B-Shops würde ich deshalb Anwendungen bevorzugen, bei denen der reguläre Einkaufsprozess unabhängig von der KI weiterhin funktioniert.

Wie könnte ein sinnvoller Einstieg in AI Commerce aussehen?

Ich würde bei einem bestehenden B2B-Shop zunächst einen überschaubaren Prozess auswählen, der für die Kunden tatsächlich mit Aufwand verbunden ist.

Ein gutes Beispiel könnte die Verarbeitung von Anforderungslisten sein. Die KI erhält Zugriff auf die benötigten Produktinformationen und darf anhand einer hochgeladenen Liste passende Artikel ermitteln. Der Kunde muss diese Listen schlicht nicht mehr in ein bestimmtes Format überführen sondern die KI übernimmt die Umwandlung.

Im ersten Schritt könnte sie lediglich einen Vorschlag anzeigen. Wenn die Ergebnisse ausreichend zuverlässig sind, lässt sich die Anwendung um die kontrollierte Übergabe an den Warenkorb erweitern.

Auf diese Weise kann man den Nutzen überprüfen und Erfahrungen mit dem eingesetzten KI-Modell, den Produktdaten und der Schnittstelle sammeln. Erst danach würde ich überlegen, welche weiteren Funktionen sinnvoll sind.

Für andere Unternehmen könnte die bildgestützte Ersatzteilsuche oder die vereinfachte Wiederbestellung der bessere Einstieg sein. Das hängt letztlich davon ab, wo die eigenen Kunden heute besonders viel Zeit verlieren.

Für andere Unternehmen mag es schlicht interessant sein über KI generierten Code sehr mächtige und laufend flexibel angepasste Konfiguratoren zu erstellen. Diese können für bestimmte Produkte die korrekten Produkte ermittelnd und einen Warenkorb befüllen. Oder evtl. dienen diese als Einkaufshilfe und erlauben das schnelle navigieren in die korrekten Kategorien. Hier sind der Grenzen kaum Grenzen gesetzt

Kosten und Aufwand bei der Umsetzung

Bei solchen Projekten würde ich bewusst klein anfangen. Ein umfangreiches KI-System mit zahlreichen Funktionen zu entwickeln, ohne zuvor den tatsächlichen Nutzen überprüft zu haben, halte ich für wenig sinnvoll.

Die Kosten hängen insbesondere davon ab, welche Produktdaten bereits vorhanden sind, wie diese bereitgestellt werden können und welche zusätzlichen Schnittstellen beziehungsweise Funktionen benötigt werden.

Wenn ein bestehender Magento-Shop bereits gut gepflegte Produktdaten und geeignete APIs besitzt, kann eine vorgelagerte KI-Anwendung womöglich mit vergleichsweise überschaubarem Aufwand getestet werden. Müssen dagegen zunächst Produktinformationen aufbereitet oder umfangreiche individuelle Funktionen entwickelt werden, kann der Aufwand deutlich steigen.

Eine pauschale Aussage, was die Umsetzung einer solchen AI-Zone kostet, halte ich ohne Kenntnis der konkreten Anforderungen für wenig seriös.

Fazit und Ausblick auf Headless AI Commerce

Ich glaube, dass wir gerade im B2B-Commerce noch sehr am Anfang stehen, was den sinnvollen Einsatz von KI betrifft.

Der klassische KI-Chatbot erscheint mir dabei vergleichsweise wenig spannend. Viel interessanter finde ich die Frage, wie Kunden ihre Anforderungen zukünftig an einen Onlineshop übergeben können und wie viel Arbeit sich dadurch einsparen lässt.

Vielleicht reicht es irgendwann tatsächlich aus, ein defektes Ersatzteil zu fotografieren oder eine unstrukturierte Anforderungsliste hochzuladen, um wenige Augenblicke später einen weitgehend vorbereiteten Warenkorb zu erhalten.

Die dafür benötigten Technologien existieren zumindest in wesentlichen Teilen bereits im Jahr 2026. Wie zuverlässig sie sich in einem konkreten B2B-Szenario einsetzen lassen, muss individuell geprüft werden.

Technisch würde ich eine solche Entwicklung möglichst klar vom eigentlichen Shopsystem trennen. Eine eigenständige AI-Zone könnte neue Formen der Produktsuche, Beratung und Konfiguration ermöglichen, während Magento weiterhin die geschäftskritischen Prozesse kontrolliert.

Besonders interessant finde ich dabei die Verbindung aus Headless Commerce, individuell entwickelten Schnittstellen und KI-gestützter Softwareentwicklung. Wenn die Architektur entsprechend aufgebaut ist, könnten neue Ideen aus Vertrieb, Innendienst und Außendienst wesentlich schneller in Anwendungen umgesetzt werden.

Die eigentliche Herausforderung sehe ich darin, die eigenen Geschäftsprozesse so gut zu verstehen, dass man erkennt, wo KI dem Kunden wirklich Arbeit abnehmen kann.

Genau dort würde ich bei der Planung ansetzen. Ob sich daraus langfristig eine vollkommen neue Form des B2B-Commerce entwickelt, wird sich zeigen.

Weiterführende Informationen und technische Grundlagen

Adobe Commerce – Headless Commerce

Beschreibung der technischen Trennung zwischen Frontend und Commerce-Backend.

https://experienceleague.adobe.com/en/docs/commerce-operations/implementation-playbook/architecture/headless/benefits

Adobe Commerce – GraphQL Queries und Mutations

Dokumentation zur Nutzung der Magento- und Adobe-Commerce-Schnittstellen.

https://developer.adobe.com/commerce/webapi/graphql/usage

OWASP – Excessive Agency

Sicherheitsrisiken, die entstehen, wenn KI-Agenten zu umfangreiche Funktionen, Berechtigungen oder Handlungsspielräume erhalten.

https://genai.owasp.org/llmrisk/llm062025-excessive-agency

Konvis – Magento-Daten mit KI über MCP und REST API abfragen

Informationen zur kontrollierten Anbindung von KI-Anwendungen an Magento.

Konvis – Risiken von MCP-Servern im Onlineshop

Weitere Überlegungen zu API-Berechtigungen, KI-Agenten und Sicherheitsgrenzen.

The post Headless AI Commerce im B2B – KI in bestehende Onlineshops integrieren und Gedanken zur Systemarchitektur appeared first on KonVis - mehr Erfolg Online.