23.06.26
Ich habe einen KI-Assistenten für Shopware 6 gebaut – hier ist die Architektur
Die meisten Shop-Betreiber haben die Daten. Sie kommen nur nicht ohne Entwickler oder BI-Analysten daran. Standard-Shopware-Dashboards zeigen Ihnen das Wesentliche — aber sobald Sie etwas Spezifisches fragen möchten, zum Beispiel welche Kunden seit sechs Wochen nicht mehr bestellt haben oder wie sich der durchschnittliche Bestellwert in diesem Monat entwickelt, öffnen Sie entweder eine Tabellenkalkulation, schreiben einen individuellen Bericht oder rufen jemanden an. Ich habe etwas gebaut, das das ändert.
Was der KI-Assistent tatsächlich macht
Ich habe einen KI-Assistenten gebaut, der auf einem Shopware-6-Shop aufsetzt und Analyse-Fragen in natürlicher Sprache direkt aus den Shop-Daten beantwortet. Keine Dashboard-Navigation. Kein SQL. Keine individuellen Berichte. Sie stellen eine Frage, Sie bekommen eine Antwort.
Die Art von Fragen, die er beantwortet:
- Welche Produkte verkaufen sich diese Woche am besten?
- Wie entwickelt sich der durchschnittliche Bestellwert in den letzten 30 Tagen?
- Welche Kunden haben seit längerer Zeit keine Bestellung aufgegeben?
Der Assistent ist für das Shopware-Administrationspanel konzipiert — das Werkzeug, das ein Shop-Manager oder Inhaber täglich nutzen würde, ohne bei jeder geschäftlichen Frage einen Entwickler einbeziehen zu müssen. Eine Live-Demo läuft in meinem Portfolio auf bojanvidaic.de — Chat-Widget, unten rechts.
Die Architektur: Drei Technologien, eine Sprache
Der Stack ist bewusst pragmatisch gewählt:
- Shopware 6 (PHP) — die Quelle aller Shop-Daten: Bestellungen, Produkte, Kunden.
- .NET-10-Service (C#) — eine eigenständige REST-API, die zwischen der KI und der Datenbank sitzt. Sie übernimmt die Abfragelogik, den Datenabruf und die Antwortformatierung.
- Groq AI mit Llama 3.3 — die natürlichsprachliche Schicht. Das Modell interpretiert die Frage, entscheidet, welche Daten benötigt werden, und formuliert die Antwort.
- Read-only-Analysedatenbank — die KI greift nie auf die produktive Transaktionsdatenbank zu. Sie fragt eine separate, schreibgeschützte Schicht ab, die die Produktionsleistung stabil und sicher hält.
- Hetzner CX22, on-premise — der gesamte Stack läuft auf einem einzigen VPS. Keine Cloud-KI-API verarbeitet Kundendaten.
Shopware, .NET und Groq teilen weder ein Framework noch eine Runtime — kommunizieren aber über einen sauberen API-Vertrag. Der .NET-Service übersetzt strukturierte Shop-Daten in etwas, über das die KI schlussfolgern kann, und die KI übersetzt Benutzerfragen in strukturierte Abfragen, die der .NET-Service ausführen kann. Drei Technologien, eine Sprache.
Das Schwierige war nicht die KI
Ich hatte erwartet, dass die KI-Integration selbst der schwierige Teil sein würde. War sie nicht. Groqs Inferenzgeschwindigkeit ist schnell genug für ein reaktionsschnelles Chat-Erlebnis, und Llama 3.3 beantwortet Analyse-Fragen mit der richtigen Prompt-Struktur gut.
Die eigentliche Arbeit war das bewusste Einschränken der KI. Ein uneingeschränktes Sprachmodell versucht alles zu beantworten — und in einem Shop-Kontext ist das ein Problem. Es muss innerhalb des Analyse-Bereichs bleiben, Fragen ablehnen, für die keine Daten vorhanden sind, und niemals Zahlen halluzinieren, die es nicht aus der Datenbank abgerufen hat.
Dieses Verhalten zuverlässig und konsistent zu machen — über verschiedene Formulierungen, Grenzfälle und unvollständige Fragen hinweg — ist der Bereich, in dem die eigentliche Entwicklungszeit steckt. Guardrails. Prompt-Design. Output-Validierung. Nicht das Modell selbst.
DSGVO, On-Premise und warum diese Entscheidung bewusst war
Jede Frage, die durch diesen Assistenten fließt, berührt echte Shop-Daten — Bestellhistorie, Kaufmuster der Kunden, Produktperformance. Diese Daten an eine Cloud-KI-API eines Drittanbieters zu senden war für mich keine Option — und für die meisten EU-basierten Unternehmen sollte es das auch nicht sein.
Der Betrieb on-premise auf Hetzner bedeutet, dass Kundendaten innerhalb einer definierten Infrastruktur bleiben, die der Shop-Betreiber kontrolliert. Groqs API wird ausschließlich für die Inferenz verwendet — das Modell erhält strukturierte, anonymisierte Abfrageergebnisse, keine rohen Kundendatensätze. Die Read-only-Datenbankschicht setzt eine weitere Grenze: Selbst wenn sich etwas in der KI-Schicht unerwartet verhält, kann sie keine Shop-Daten verändern.
Diese Architektur ist kein Zufall. Sie ist das Mindestmaß an verantwortungsvollem Design für ein System, das geschäftssensible Daten liest und Benutzern präsentiert.
Wie das für Ihren Shop aussehen könnte
Das ist eine funktionierende Implementierung, kein Proof of Concept. Die Architektur skaliert: Der .NET-Service kann um neue Abfragetypen erweitert werden, die KI-Schicht kann auf das Datenmodell eines bestimmten Shops abgestimmt werden, und dasselbe Muster funktioniert ebenso gut für B2B-Analyse-Use-Cases — kundenspezifische Preisanalysen, Erkennung von Nachbestellmustern oder segmentbasiertes Reporting.
Wenn Sie einen Shopware-6-Shop betreiben und möchten, dass Ihr Team Geschäftsfragen stellen kann, ohne eine Tabellenkalkulation zu öffnen oder darauf zu warten, dass ein Entwickler eine Abfrage ausführt — das ist ein baubares, deploybares System.
Ich baue diese Art von Integration, weil ich wissen möchte, ob sie in der Praxis funktioniert, nicht nur in der Theorie. Sie tut es. Und ich baue sie gerne für Ihren Shop.