KI in bestehende Workflows integrieren, ohne alles kaputtzumachen

Warum die meisten KI Projekte stecken bleiben, und warum es selten an der KI liegt

Ich erspare dir sechs Monate und eine Menge Frust. Die meisten KI Projekte, die stecken bleiben, scheitern nicht daran, dass das Modell nicht gut genug war. Sie scheitern daran, dass die Daten Murks waren.

Die Forschung zeigt in dieselbe Richtung. Gartner sagte im Februar 2025 voraus, dass Organisationen bis einschließlich 2026 60 % der KI Projekte aufgeben werden, die nicht auf KI taugliche Daten gestützt sind.¹ Eine Umfrage von Precisely und dem LeBow College of Business der Drexel University unter mehr als 550 Fachleuten für Daten und Analytics ergab, dass 77 % die Datenqualität ihrer Organisation bestenfalls als durchschnittlich einschätzten, nach 66 % im Jahr davor, ein Rückgang um elf Punkte.² Und der Data, BI and Analytics Trend Monitor 2026 von BARC mit 1.579 Teilnehmenden setzte das Datenqualitätsmanagement wieder auf Platz eins, gleichauf mit Datensicherheit und Datenschutz, vor den neueren KI Themen.³

Das Muster ist immer gleich. Ein Unternehmen ist begeistert von KI. Es kauft oder baut ein Modell und füttert es mit seinen Daten. Die Daten sind widersprüchlich, doppelt, veraltet oder lückenhaft. Das Modell liefert unzuverlässige Ergebnisse, das Projekt stockt, und sechs Monate und ein Budget später sind sich alle einig: "KI funktioniert bei uns nicht." Die KI war nicht das Problem. Die Daten in Ordnung zu bringen, wäre der erste Schritt gewesen.

Ich weiß das, weil ich es selbst erlebt habe. Als ich angefangen habe, GrowCentric.ai zu bauen, mein SaaS zur Optimierung von Marketing, waren die Modelle für maschinelles Lernen nicht der schwierige Teil. Schwierig war es, aus der unordentlichen Wirklichkeit echter eCommerce Unternehmen saubere, einheitliche Daten herauszubekommen. Und als ich für einen Automarktplatz auf Rails und Solidus eine KI gestützte Suche und Empfehlungen gebaut habe, lag die Herausforderung nicht in den Algorithmen. Sie lag darin, dass dasselbe Modell auf mehrere verschiedene Arten eingetragen war, Laufleistung und Motorleistung in gemischten Einheiten, Farbnamen wild durcheinander, doppelte Kundendatensätze und alte Lieferantenfeeds.

Rechenbeispiel: ein Auto, fünf Schreibweisen

Isarmobil ist ein erfundener Marktplatz für Gebrauchtwagen in München unter isarmobil.example, spezialisiert auf Fahrzeuge, die Händler aus Großbritannien einführen. Deshalb rechnet die Plattform intern in Meilen, wie die meisten ihrer Quellen. Die 1.800 Inserate stammen von Dutzenden Händlern. Dasselbe Auto taucht so auf:

1. "BMW 320i", 45.000 Meilen, 184 bhp, "schwarz"
2. "BMW 3er 320i", "45000", 135 kW, "Schwarz"
3. "3er 320 i", "72420 km", 184PS, "tiefschwarz"
4. "bmw 320I", "45k", keine Leistung angegeben, "Black Sapphire metallic"
5. "BMW 320i M Sport", 45.000 Meilen, 184 bhp, "SCHWARZ"

Ein Empfehlungsmodell sieht fünf verschiedene Autos. Eine Suche nach "schwarzer BMW 3er unter 50.000 Meilen" findet eines davon, vielleicht zwei. Kein Modell der Welt wird daraus schlau, ohne dass vorher aufgeräumt wird. Genau dort fängst du also an: nicht mit KI, mit Daten.

Die richtige Reihenfolge

Das ist die Reihenfolge, die funktioniert, aus Projekten, die ich gebaut, und aus Projekten, die ich gerettet habe.

Lies es von oben. Die einzige Schleife ist die Prüfung der Daten: Wenn die Prüfung sagt, dass die Daten das Problem nicht tragen, ist der nächste Job das Aufräumen, nicht das Modellieren.

Schritt 1: das geschäftliche Problem festlegen. Nicht "wir wollen KI einsetzen", sondern "wir wollen mehr abgebrochene Warenkörbe zurückholen", "wir wollen wissen, welche Autos sich innerhalb von sieben Tagen verkaufen" oder "wir wollen, dass Supporttickets bei der richtigen Person landen". Wenn du das Problem nicht beschreiben kannst, ohne KI zu erwähnen, bist du noch nicht so weit.

Schritt 2: die Daten prüfen. Bevor du eine Zeile KI Code schreibst, schau dir die Daten an. Wie vollständig, wie einheitlich, wie richtig, wie aktuell sind sie? Wo sind die Dubletten und die Lücken? Die Prüfung sagt dir, ob du Wochen oder Monate entfernt bist. Für einen Shop auf Rails und Solidus kann das eine kurze Klasse sein:

class DataQualityAudit
  def run
    { products: audit_products, customers: audit_customers, inventory: audit_inventory }
  end

  private

  def audit_products
    {
      total: Spree::Product.count,
      missing_descriptions: Spree::Product.where(description: [nil, ""]).count,
      without_images: Spree::Product.where.missing(:variant_images).count,
      variants_without_price: Spree::Variant.where.missing(:prices).count,
      duplicate_skus: Spree::Variant.where.not(sku: [nil, ""]).group(:sku).having("count(*) > 1").count.size
    }
  end

  def audit_customers
    users = Spree.user_class
    {
      total: users.count,
      duplicate_emails: users.group("LOWER(email)").having("count(*) > 1").count.size,
      without_address: users.where.missing(:addresses).count,
      untouched_two_years: users.where(updated_at: ...2.years.ago).count
    }
  end

  def audit_inventory
    {
      negative_stock: Spree::StockItem.where("count_on_hand < 0").count,
      listed_but_unsellable: Spree::StockItem.where(count_on_hand: 0, backorderable: false)
                               .joins(variant: :product).merge(Spree::Product.available).count
    }
  end
end

Spree.user_class ist das konfigurierte Nutzermodell, und Produkte und Varianten werden in Solidus nur weich gelöscht, die Standardscopes lassen gelöschte Datensätze also schon weg.

Eine einzige Zahl pro Bereich hilft dir, den Fortschritt zu verfolgen. Ein einfacher Vollständigkeitswert ist der Anteil der Pflichtfelder, die ausgefüllt sind:

$$C = \frac{f}{r \times n}$$

Dabei ist $C$ der Vollständigkeitswert von 0 bis 1, $f$ die Zahl der Pflichtfelder, die tatsächlich ausgefüllt sind, $r$ die Zahl der Pflichtfelder pro Datensatz und $n$ die Zahl der Datensätze. Es ist eine gewöhnliche Quote, Ereignisse durch Gelegenheiten. Grundlagen: Verhältnisse und Quoten

Rechenbeispiel: die Vollständigkeit der Inserate bei Isarmobil

Isarmobil verlangt pro Inserat fünf Felder: Marke und Modell, Laufleistung, Leistung, Farbe und mindestens ein Foto. Bei 1.800 Inseraten sind das $5 \times 1{.}800 = 9{.}000$ Pflichtfelder. Die Prüfung findet 540 Inserate ohne Leistung, 210 ohne Foto und 90 ohne Laufleistung, also sind $540 + 210 + 90 = 840$ Felder leer und $9{.}000 - 840 = 8{.}160$ ausgefüllt.

$$C = \frac{8{.}160}{9{.}000} = 0{,}907$$

$C$ liegt also bei 90,7 %. Das klingt gut, bis du merkst, dass die leeren Felder genau die sind, nach denen Käufer filtern. Der Wert sagt dir, wie viel fehlt. Welche Felder fehlen, sagt dir, ob es wichtig ist.

Schritt 3: bereinigen und vereinheitlichen. Die unspektakuläre Arbeit, die alles andere erst möglich macht. Dubletten zusammenführen, Formate vereinheitlichen, Lücken füllen, wo es geht, und Prüfregeln ergänzen, damit keine neuen schmutzigen Daten mehr hereinkommen. Für Isarmobil heißt das ein Normalisierer für Inserate:

class ListingNormaliser
  MAKE_ALIASES = { "bmw" => "BMW", "vw" => "Volkswagen", "merc" => "Mercedes-Benz", "mercedes" => "Mercedes-Benz" }.freeze
  KM_PER_MILE = 1.609344
  KW_PER_BHP = 0.7457
  KW_PER_PS = 0.7355

  def normalise(listing)
    {
      make: MAKE_ALIASES.fetch(listing[:make].to_s.strip.downcase, listing[:make].to_s.strip),
      mileage_miles: mileage_in_miles(listing[:mileage]),
      power_kw: power_in_kw(listing[:power]),
      colour: listing[:colour].to_s.strip.downcase.presence
    }
  end

  private

  def mileage_in_miles(value)
    text = value.to_s.downcase.strip
    return nil if text.empty?

    number = text.delete(",").to_f
    number *= 1_000 if text.match?(/\d\s*k\b/)
    number /= KM_PER_MILE if text.include?("km")
    number.positive? ? number.round : nil
  end

  def power_in_kw(value)
    text = value.to_s.downcase
    number = text[/\d+(\.\d+)?/].to_f
    return nil unless number.positive?

    if text.include?("kw") then number.round
    elsif text.include?("ps") then (number * KW_PER_PS).round
    else (number * KW_PER_BHP).round # bhp oder hp
    end
  end
end

Achte auf die beiden Umrechnungsfaktoren. Die britische Brake Horsepower (bhp) und die metrische Pferdestärke (PS) sind nicht dieselbe Einheit, und ein Normalisierer, der für beide denselben Faktor nimmt, liegt still und leise um rund 1,4 % daneben.

Rechenbeispiel: die fünf BMWs, vereinheitlicht

Inserat 3 sagt "72420 km" und 184PS. Laufleistung: $72{.}420 \div 1{,}609344 = 45{.}000$ Meilen. Leistung: $184 \times 0{,}7355 = 135$ kW. Inserat 1 sagt 184 bhp: $184 \times 0{,}7457 = 137$ kW. Inserat 2 sagt schon 135 kW. Aus "45k" in Inserat 4 werden 45.000 Meilen.

Nach dem Normalisierer stimmen vier der fünf bei der Laufleistung überein, und die Leistungswerte liegen bei 135 bis 137 kW, nah genug, um sie als wahrscheinlich dasselbe Auto zu markieren, das ein Mensch prüft. Die Farbe braucht noch eine Zuordnungstabelle (schwarz, tiefschwarz und Black Sapphire metallic werden für die Suche alle zu "schwarz"), das ist die Arbeit eines Vormittags. Erst dann sind die Daten es wert, einem Modell gezeigt zu werden.

Schritt 4: das Muster der Anbindung wählen. Jetzt, und erst jetzt, denkst du darüber nach, wie die KI an deine Systeme angebunden wird.

Schritt 5: klein anfangen, alles messen, nachbessern.

Drei Muster, um KI zu ergänzen, ohne etwas zu ersetzen

Die meisten Unternehmen können ihre Systeme nicht herausreißen und neu anfangen. Du hast eine Rails Anwendung, die seit Jahren läuft, einen Solidus Shop mit Tausenden Produkten und Kunden, Mitarbeitende, die sich auf die Abläufe verlassen, und Anbindungen an Lieferanten, Zahlungsdienstleister und Paketdienste. Nichts davon musst du ersetzen. Du legst die KI obendrauf.

Muster 1: der Service Wrapper. Leg die KI hinter einen Service, den deine Anwendung aufruft. Die Anwendung muss nicht wissen, dass maschinelles Lernen im Spiel ist. Sie fragt, bekommt eine Antwort und nutzt sie, und wenn die KI langsam ist oder ausfällt, greift ein Rückfall.

class ProductRecommendationService
  def recommendations_for(user, limit: 6)
    fetch_ai_recommendations(user, limit).presence || fallback_recommendations(user, limit)
  end

  private

  def fetch_ai_recommendations(user, limit)
    response = AiClient.post("/recommendations", user_id: user.id, limit: limit)
    in_stock(Spree::Product.where(id: response.fetch("product_ids", []))).limit(limit)
  rescue AiClient::Error, Timeout::Error => e
    Rails.logger.warn("Recommendations unavailable: #{e.message}")
    nil
  end

  def fallback_recommendations(user, limit)
    in_stock(Spree::Product.available).order(available_on: :desc).limit(limit)
  end

  def in_stock(products)
    products.joins(:variants_including_master).merge(Spree::Variant.in_stock).distinct
  end
end

Fällt der KI Service aus, zeigt der Shop stattdessen die neuesten vorrätigen Produkte. Die Kundschaft sieht nie einen Fehler. KI soll einen Ablauf verbessern, nie zu seiner einzigen Schwachstelle werden.

Achte darauf, was geschickt wird: eine Nutzer ID und eine Zahl. Nicht der Name der Kundin, ihre Mailadresse oder ihre Anschrift. Dazu gleich mehr.

Muster 2: der Event Listener. Dein Shop verkündet schon, was passiert. Solidus veröffentlicht Events wie order_finalized auf seinem eigenen Bus, Spree::Bus, gebaut auf der Bibliothek Omnes, und du kannst eigene registrieren.⁴ Eine KI Schicht abonniert diese Events und handelt, ohne den Checkout anzufassen:

# config/initializers/omnes.rb
Rails.application.config.to_prepare do
  Spree::Bus.register(:cart_abandoned) unless Spree::Bus.registry.registered?(:cart_abandoned)
  Isarmobil::AiSubscriber.new.subscribe_to(Spree::Bus)
end

# app/subscribers/isarmobil/ai_subscriber.rb
module Isarmobil
  class AiSubscriber
    include Omnes::Subscriber

    handle :order_finalized, with: :after_order
    handle :cart_abandoned, with: :after_abandonment

    def after_order(event)
      order = event.payload[:order]
      CrossSellAnalysisJob.perform_later(order.id)
      DemandForecastUpdateJob.perform_later(order.id)
    end

    def after_abandonment(event)
      CartRecoveryJob.perform_later(event.payload[:order].id)
    end
  end
end

# Ein wiederkehrender Job veröffentlicht das eigene Event für Warenkörbe, die seit einer Stunde liegen
Spree::Bus.publish(:cart_abandoned, order: order)

Der Subscriber stellt nur Jobs in die Warteschlange, der Checkout wartet also nie darauf, dass ein Modell nachdenkt. Checkout, Zahlungen und Auftragsverwaltung in Solidus ändern sich nicht. Die KI Schicht hört zu und ergänzt.

Muster 3: die Middleware Schicht. Wenn KI zwischen zwei Systemen sitzen und die Daten verbessern soll, die durchlaufen, erledigt das eine Middleware Schicht. Dieses Muster nutze ich bei GrowCentric.ai, das zwischen eCommerce Shops und Werbeplattformen wie Google Ads und Meta sitzt. Es liest Leistungsdaten, reichert sie mit eigener Analyse an und gibt angepasste Kampagneneinstellungen zurück. Der Shop ändert sich überhaupt nicht. GrowCentric braucht nur Zugriff über die API, um Leistungsdaten zu lesen und Änderungen an Kampagnen zu schreiben.

Rechenbeispiel: das passende Muster bei Isarmobil

Drei Aufgaben bei Isarmobil. "Ähnliche Autos auf einer Inseratsseite zeigen" ist eine Frage, die die Seite stellt und in weniger als einer Sekunde beantwortet haben will, also ein Service Wrapper mit Rückfall. "Wenn ein Auto verkauft ist, die Nachfrageprognose für dieses Modell aktualisieren" reagiert auf etwas, das passiert ist, also ein Event Listener. "Die Gebote in Google Ads danach anpassen, wie schnell sich jedes Modell verkauft" sitzt zwischen zwei Systemen, also Middleware. Das Muster folgt aus der Frage: gefragt, passiert oder dazwischen.

Altsysteme, und was MCP daran ändert

An Altsystemen bleiben die meisten Unternehmen hängen. Ein Lieferant schickt Produktdaten als CSV Anhang. Die Buchhaltung spricht nur SOAP XML. Das Lagersystem von 2015 hat eine kaum dokumentierte REST API. Die Kundendaten verteilen sich auf drei Systeme, die nie verbunden wurden. Das ist die Wirklichkeit in jedem eCommerce Unternehmen aus dem Mittelstand, mit dem ich gearbeitet habe.

Die klassische Antwort sind eigene Integrationen zwischen jedem Paar von Systemen. Bei $n$ Systemen können das bis zu $n(n-1)/2$ Integrationen sein, zehn Systeme heißen also bis zu $10 \times 9 \div 2 = 45$, und jede Änderung bricht mehrere davon.

Das Model Context Protocol (MCP), über das ich in KI Agenten und Chatbots geschrieben habe, ändert die Form. Anthropic hat es im November 2024 als offenen Standard veröffentlicht, um KI Assistenten mit den Systemen zu verbinden, in denen die Daten liegen,⁵ und im Dezember 2025 an die Agentic AI Foundation unter dem Dach der Linux Foundation übergeben, damit kein einzelner Anbieter es kontrolliert.⁶ Statt Punkt zu Punkt Integrationen stellst du vor jedes System einen MCP Server. Jeder Server beschreibt auf standardisierte Weise, was sein System kann, und jeder Agent, der MCP spricht, kann ihn nutzen. Zehn Systeme, zehn Server.

Das offizielle Ruby SDK, das Gem mcp, definiert jede Fähigkeit als Werkzeugklasse:⁷

class CheckSupplierStock < MCP::Tool
  description "Check stock at the supplier for one SKU"
  input_schema(properties: { sku: { type: "string" } }, required: ["sku"])

  class << self
    def call(sku:, server_context:)
      stock = LegacySupplierSoapClient.check_stock(sku) # kapselt die alte SOAP API
      MCP::Tool::Response.new([{ type: "text", text: { sku: sku, available: stock }.to_json }])
    end
  end
end

class LatestSupplierCatalogue < MCP::Tool
  description "The supplier's latest catalogue, parsed and normalised"
  input_schema(properties: { since: { type: "string", format: "date" } })

  class << self
    def call(server_context:, since: nil)
      rows = SupplierCsvImporter.new.fetch_and_normalise(since: since) # liest die CSV Anhänge
      MCP::Tool::Response.new([{ type: "text", text: rows.to_json }])
    end
  end
end

server = MCP::Server.new(name: "isarmobil_supplier", tools: [CheckSupplierStock, LatestSupplierCatalogue])

Der Agent muss nie wissen, dass ein Lieferant CSV Anhänge schickt, während ein anderer eine SOAP API hat. Der Server versteckt das. Und achte darauf, was fehlt: ein Werkzeug, das Bestellungen beim Lieferanten auslöst. Lesen kommt zuerst. Alles, was Geld bindet, wartet, bis sich die lesenden Werkzeuge Vertrauen verdient haben, und läuft dann über einen Menschen.

Datenschutz vor dem ersten API Aufruf

Jede Anfrage, die du an einen KI Dienst in der Cloud schickst, verlässt deine Systeme. Enthält sie irgendetwas, das einen Menschen erkennbar macht, ist das eine Verarbeitung personenbezogener Daten nach der Datenschutz Grundverordnung (DSGVO), und es gelten die üblichen Regeln: Die Daten müssen auf das für den Zweck notwendige Maß beschränkt sein, so verlangt es der Grundsatz der Datenminimierung in Art. 5 Abs. 1 lit. c DSGVO,⁸ und ein Anbieter, der sie in deinem Auftrag verarbeitet, braucht einen Vertrag zur Auftragsverarbeitung mit den Inhalten, die Art. 28 DSGVO vorschreibt.⁹ Zuständig für Unternehmen ist in Deutschland die Datenschutzaufsicht des Bundeslands, in dem das Unternehmen sitzt,¹⁰ und die Orientierungshilfe der Aufsichtsbehörden von Bund und Ländern zu KI und Datenschutz ist der beste Ausgangspunkt.¹¹

Das Risiko ist nicht theoretisch. Im Mai 2023 schränkte Samsung die Nutzung generativer KI wie ChatGPT auf Firmenrechnern ein, nach Fällen von Missbrauch, Berichten zufolge auch vertraulichem Code, der in ChatGPT eingegeben worden war.¹² Niemand wollte Schaden anrichten. Jemand wollte Hilfe bei einem Bug. Mein Artikel zu KI im Unternehmen geht weitere solche Vorfälle durch und zeigt, wie du sensible Arbeit so vermittelst, dass sie das Haus nie verlässt, und DSGVO konforme KI Features bauen behandelt die Produktseite.

Im Integrationscode decken drei Gewohnheiten das meiste ab. Schick Kennungen, keine Identitäten: eine Nutzer ID, nie Name und Mailadresse, es sei denn, die Aufgabe braucht sie wirklich. Nutz Geschäfts oder API Bedingungen mit einem Vertrag zur Auftragsverarbeitung, nie einen privaten Account. Und protokollier, was du geschickt hast, damit du die Frage "Was haben wir der KI gegeben?" beantworten kannst, wenn jemand fragt.

Rechenbeispiel: was Isarmobil an den Empfehlungsdienst schickt

Der erste Entwurf der Integration bei Isarmobil schickte den vollständigen Nutzerdatensatz: Name, Mailadresse, Telefonnummer, Postleitzahl und die angesehenen Autos. Die Frage an jedes Feld lautet, ob die Empfehlung es braucht.

1. Name: nein.
2. Mailadresse und Telefon: nein.
3. Postleitzahl: nur die ersten beiden Ziffern, wenn die Entfernung zählt (80, nicht 80331).
4. Angesehene Autos: ja, als IDs der Inserate.
5. Eine stabile Nutzer ID, damit der Dienst lernen kann: ja, eine zufällige Kennung, nicht die ID aus der Datenbank.

Aus fünf personenbezogenen Feldern werden eine zufällige ID, eine Region und eine Liste von Inserats IDs. Die Empfehlungen sind genauso gut, und ein Datenleck beim Anbieter würde fast nichts offenlegen.

Fünf realistische Einstiegspunkte

Genug Theorie. Hier sind fünf Einstiegspunkte, sortiert nach Wirkung und Schwierigkeit. Such dir einen aus. Bring ihn zum Laufen. Dann nimm dir den nächsten vor.

1. Klügere Rückgewinnung abgebrochener Warenkörbe (geringe Schwierigkeit, hohe Wirkung). Abgebrochene Warenkörbe gehören zu den größten Umsatzlecks im eCommerce. Der Durchschnitt des Baymard Institute über 50 Studien setzt die Abbruchrate bei rund 70 % an.¹³ Die KI Fassung geht über "Du hast noch etwas im Warenkorb" hinaus. Sie schätzt, warum die Kundin gegangen ist (Schreck über die Versandkosten, Preisvergleich, nur gestöbert), wählt Kanal und Anreiz und timt die Nachricht. Auf dem Automarktplatz, den ich erwähnt habe, war das die nützlichste KI Integration, die ich gebaut habe.

class CartRecoveryAgent
  def recover(order)
    user = order.user
    return unless user&.marketing_consent? # eigener Einwilligungsnachweis des Shops: ohne Einwilligung keine Mail und keine Anzeige

    reason = AbandonmentClassifier.predict(signals_for(order))
    strategy = RecoveryStrategy.for(reason)

    CartRecoveryMailer.recovery(order, template: strategy.template, incentive: strategy.incentive)
                      .deliver_later(wait: strategy.delay)

    AgentAuditLog.create!(agent_name: "CartRecovery", action_type: "recovery_email",
                          decision_payload: { order_id: order.id, reason: reason, strategy: strategy.to_h })
  end

  private

  def signals_for(order)
    {
      reached_delivery_step: order.state.in?(%w[delivery payment confirm]),
      first_time_buyer: order.user.orders.complete.none?,
      items: order.line_items.count,
      basket_value: order.item_total.to_f
    }
  end
end

Zwei Details zählen. Die Prüfung der Einwilligung kommt zuerst: Eine Mail zum abgebrochenen Warenkorb ist Werbung, eine Retargeting Anzeige auch. Und der Mailer wird über seine eigene Methode aufgerufen, recovery, nie über send aus Ruby, das eine Methode der Klasse aufrufen würde, statt eine Mail zu verschicken.

Rechenbeispiel: lohnt sich der Bau?

Die Annahmen des Beispiels: Der Teileshop von Isarmobil sieht 600 abgebrochene Warenkörbe im Monat mit durchschnittlich 85 €, 60 % dieser Kunden haben in Werbung eingewilligt, und die klügeren Mails holen 6 % der Warenkörbe zurück, an die sie gehen, gegen 3 % bei der alten festen Erinnerung.

Warenkörbe, die angeschrieben werden dürfen: $600 \times 0{,}6 = 360$. Alte Erinnerung: $360 \times 0{,}03 = 10{,}8$ Bestellungen. Neuer Agent: $360 \times 0{,}06 = 21{,}6$ Bestellungen. Der Unterschied ist $10{,}8 \times 85 = 918$ € Umsatz im Monat. Kostet der Bau weniger als die Marge darauf über ein Jahr, lohnt er sich. Die 6 % sind eine Annahme des Beispiels, und der erste Monat Messung ersetzt sie durch eine echte Zahl. Grundlagen: Erwartungswert

2. Produktdaten anreichern (geringe Schwierigkeit, mittlere Wirkung). Dünne oder widersprüchliche Produktbeschreibungen lassen sich mit KI verbessern, aber erst, wenn die strukturierten Daten sauber sind. Beschreibungen erzeugen oder verbessern, Eigenschaften aus Freitext herausziehen und Kategorien einheitlich halten. Übernimm das Ergebnis nicht blind:

class ProductEnrichmentService
  def enrich(product)
    return unless product.description.to_s.length < 100 || product.meta_description.blank?

    properties = product.product_properties.joins(:property).pluck("spree_properties.name", :value).to_h
    result = AiClient.post("/enrich-product", name: product.name, description: product.description.to_s,
                                              properties: properties, taxons: product.taxons.pluck(:name))

    if result["confidence"].to_f >= 0.8
      product.update!(description: result["description"], meta_description: result["meta_description"])
    else
      EnrichmentReview.create!(product: product, proposal: result) # ein Mensch entscheidet
    end
  end
end

Unter der Schwelle für die Sicherheit prüft ein Mensch den Vorschlag. Und achte darauf, dass nur Produktdaten an den Dienst gehen, nie Kundendaten.

3. Nachfrageprognose (mittlere Schwierigkeit, hohe Wirkung). Wie ich in Agentic AI im eCommerce beschrieben habe, gehört die Lagersteuerung zu den wertvollsten Einsätzen von KI. Sie braucht zuerst eine saubere Historie. Waren die Bestandszahlen falsch, haben die Verkaufsdaten Lücken oder sind die Kategorien uneinheitlich, wird die Prognose unzuverlässig. Fang mit mindestens 12 Monaten sauberer Bestellungen, richtigem Bestand und einheitlichen Kategorien an und bau dann ein einfaches Prognosemodell, das mit der Zeit besser wird.

4. Supporttickets einordnen (geringe Schwierigkeit, mittlere Wirkung). KI kann eingehende Tickets nach Art (Rücksendung, Frage zur Lieferung, Frage zum Produkt, Beschwerde), Dringlichkeit und Ton markieren und an die richtige Person weiterleiten. Dafür brauchst du kein neues Supportsystem, nur einen Event Listener, der jedes neue Ticket liest und Labels ergänzt.

5. Marketingkampagnen optimieren (mittlere Schwierigkeit, hohe Wirkung). Das macht GrowCentric.ai. Statt Budgets, Gebote und Ausrichtung von Hand anzupassen, beobachten KI Agenten die Leistung ständig und treffen die Routineentscheidungen der Optimierung. Voraussetzung ist sauberes Tracking. Ist die Attribution kaputt oder das Conversion Tracking lückenhaft, optimiert die KI auf das Falsche.

Was ich für Kunden mache

Damit es konkret wird, wie das zu meiner Arbeit passt:

Datenprüfung und Aufräumen. Ich prüfe die Daten eines Solidus Shops (Vollständigkeit der Produkte, doppelte Kunden, Richtigkeit des Bestands, Stimmigkeit der Bestellungen) und baue dann die Vereinheitlichung und die Prüfregeln, die neue schmutzige Daten draußen halten. Das ist das Fundament für alles andere.

Eine Architektur auf Rails, die für KI bereit ist. Events, Hintergrundjobs und Rückfälle, damit die Anwendung für KI bereit ist und ein Ausfall der KI nie den Shop lahmlegt.

MCP Server. Server, die bestehende Systeme (Solidus, Lieferantenfeeds, Lager, Buchhaltung) auf standardisierte Weise für KI Agenten öffnen, damit Altsysteme mitmachen, ohne ersetzt zu werden.

Die Agenten selbst. Rückgewinnung von Warenkörben, Prognosen, Einordnung von Tickets, Auftragssteuerung, jeweils mit abgestufter Autonomie, Protokollen und den Leitplanken aus meinen Artikeln zu Agentic AI und zu Agenten und Chatbots.

Compliance von Anfang an. Die DSGVO ab der ersten Zeile Code, und für Unternehmen, die in der EU verkaufen, der Cyber Resilience Act und die NIS2 Richtlinie. KI einzusetzen, die gegen Datenschutzrecht verstößt, ist kein Vorteil, sondern eine Haftungsfalle.

Der ehrliche Realitätscheck

Zum Schluss ein paar unbequeme Wahrheiten.

Es dauert länger, als du denkst. Plan für eine Integration, die etwas bewirkt, drei bis sechs Monate ein, nicht drei bis sechs Wochen. Allein das Aufräumen der Daten kann Wochen dauern, das Testen der Integration dauert länger als die Entwicklung, und dein Team braucht Zeit, den Entscheidungen der KI zu vertrauen, bevor sie mehr Autonomie bekommt.

Du brauchst weniger KI, als du denkst. Die meisten Unternehmen hätten von sauberen Daten und besserer einfacher Auswertung mehr als von einem ausgefeilten Modell. Wenn du einfache Fragen zum Verhalten deiner Kundschaft, zu deinem Conversion Funnel und zum Lagerumschlag mit den vorhandenen Daten nicht beantworten kannst, hilft dir KI noch nicht. Bring zuerst die Grundlagen in Ordnung.

Die erste Fassung wird ernüchternd sein. Rechne bei einer ersten Integration mit 5 % bis 10 % Verbesserung, nicht mit einer Verwandlung. Das ist normal. Der Wert wächst, je mehr Daten die Modelle sehen und je mehr Einsätze du ergänzt.

Verstehen kannst du nicht auslagern. Auch wenn du jemanden (wie mich) beauftragst, es zu bauen, muss dein Team verstehen, was es tut und warum. Wenn niemand erklären kann, wie der Agent für abgebrochene Warenkörbe entscheidet, kann ihn niemand verbessern, Fehler darin finden oder ihm vertrauen. Das Wissen zu übergeben ist so wichtig wie der Code.

Die Unternehmen, die mit KI gut fahren, sind nicht die mit den eindrucksvollsten Modellen. Es sind die mit den saubersten Daten, der sorgfältigsten Anbindung und der Disziplin, klein anzufangen und zu messen. Glamourös ist das nicht. Es funktioniert.

Footnotes

1. Freevacy, Gartner reveals 60% of AI projects with data issues will fail, 26. Februar 2025, über die Pressemitteilung von Gartner Lack of AI-Ready Data Puts AI Projects at Risk vom selben Tag, https://www.freevacy.com/news/gartner/gartner-reveals-60-of-ai-projects-with-data-issues-will-fail/6155

2. Rachel Galvez, 2025 planning insights: data quality remains the top data integrity challenge, Precisely, 5. November 2024, zum Bericht 2025 Outlook: Data Integrity Trends and Insights mit dem Drexel University LeBow College of Business, https://www.precisely.com/blog/data-integrity/2025-planning-insights-data-quality-remains-the-top-data-integrity-challenges

3. BARC, Data quality beats AI hype: BARC publishes the Data, BI and Analytics Trend Monitor 2026, 12. November 2025, https://barc.com/news/barc-publishes-the-data-bi-and-analytics-trend-monitor-2026/

4. Solidus Guides, Subscribing to events, abgerufen im November 2026, https://guides.solidus.io/customization/subscribing-to-events

5. Anthropic, Introducing the Model Context Protocol, 25. November 2024, https://www.anthropic.com/news/model-context-protocol

6. MCP Core Maintainers, MCP joins the Agentic AI Foundation, Model Context Protocol blog, 9. Dezember 2025, https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/

7. Model Context Protocol, Ruby SDK (the mcp gem), GitHub, abgerufen im November 2026, https://github.com/modelcontextprotocol/ruby-sdk

8. Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 5 Absatz 1 Buchstabe c, Datenminimierung, EUR-Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

9. Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 28, Auftragsverarbeiter, EUR-Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

10. Bundesdatenschutzgesetz (BDSG), § 40 Aufsichtsbehörden der Länder, gesetze-im-internet.de, https://www.gesetze-im-internet.de/bdsg_2018/__40.html

11. Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder (DSK), Orientierungshilfe Künstliche Intelligenz und Datenschutz, Version 1.0, 6. Mai 2024, https://www.datenschutzkonferenz-online.de/media/oh/20240506_DSK_Orientierungshilfe_KI_und_Datenschutz.pdf

12. Arjun Kharpal, Samsung bans use of generative AI tools like ChatGPT after April internal data leak, CNBC, 2. Mai 2023, https://www.cnbc.com/2023/05/02/samsung-bans-use-of-ai-like-chatgpt-for-staff-after-misuse-of-chatbot.html

13. Baymard Institute, Cart abandonment rate statistics, aktualisiert am 28. Oktober 2026, https://baymard.com/lists/cart-abandonment-rate