- Datenbasis: Für Bedarfsprognosen nennen Fachquellen als Faustregel mindestens zwei bis drei Jahre Absatzhistorie, Fehlbestände müssen in den Daten markiert sein
- API-Kosten: Claude Haiku 4.5 kostet laut Herstellerseite 1 US-Dollar je Million Eingabetoken und 5 US-Dollar je Million Ausgabetoken (Stand: Oktober 2026)
- Recht: Art. 50 der KI-Verordnung gilt seit 2. August 2026, die Hochrisiko-Pflichten nach Anhang III erst ab 2. Dezember 2027. Der Bußgeldrahmen (Art. 99) reicht bis 35 Mio. EUR oder 7 % des weltweiten Jahresumsatzes bei verbotenen Praktiken und bis 15 Mio. EUR oder 3 % bei vielen anderen Verstößen. Für KMU gilt jeweils der niedrigere Betrag.
Eine Bedarfsprognose mit maschinellem Lernen lohnt sich, wenn Sie mindestens zwei Jahre bereinigte Absatzdaten haben, Fehlbestände in diesen Daten markiert sind und das Modell im Test eine einfache Vorwochen-Prognose schlägt. Fehlt eine dieser drei Bedingungen, bringt ein komplexeres Modell meist nichts. Für Texte und Dokumente (Tickets sortieren, Rechnungen auslesen) brauchen Sie dagegen kein eigenes Modell: Dort ist ein Hersteller-API in der Regel der kürzere und billigere Weg.
Dieser Artikel ordnet die realistischen Einsatzfelder von maschinellem Lernen im Mittelstand ein: Prognose, Klassifikation, Texterkennung und Empfehlungen. Er zeigt, welche Daten Sie dafür brauchen, wann sich die Entscheidung zwischen API und eigenem Modell stellt, welche Preise die Hersteller veröffentlichen, was DSGVO, Art. 22 und die KI-Verordnung für Sie bedeuten und wie ein Projekt in fünf Schritten aufgebaut wird. Ich schreibe als Webentwickler (seit 2018, eCommerce und Automatisierung) und bewerte Technik und Preise nach den veröffentlichten Quellen, nicht nach Herstellerversprechen.
Hinweis: Preise stammen von den verlinkten Herstellerseiten (Stand: Oktober 2026) und sind Listenpreise in US-Dollar. Alle Zahlen ohne Quellenlink sind Beispielrechnungen mit angenommenen Werten oder eigene Einschätzungen und ohne Gewähr. Rechtliche Hinweise ersetzen keine Prüfung im Einzelfall.
- Warum maschinelles Lernen für Unternehmen mehr als generative KI ist
- Welche Machine-Learning-Anwendungen im Mittelstand heute den größten Nutzen bringen
- Bedarfsprognose mit maschinellem Lernen: Daten, Baseline, Backtest
- Wie neuronale Netze, supervised learning und predictive analytics in der Praxis zusammenspielen
- In welchen 5 Schritten eine KI-Implementierung in Deutschland sauber startet
- API oder eigenes Modell: Make-or-Buy und belegte Preise
- Datenschutz und KI-Verordnung: DSGVO, Art. 22 und Fristen
- Häufige Fehler und Risiken bei Datenqualität, Black-Box-Modellen und Cyberangriffen
- Warum KI 2026 vor allem Produktivität sichert statt sofort Wachstumssprünge zu liefern
- Was Sie jetzt mitnehmen
Warum maschinelles Lernen für Unternehmen mehr als generative KI ist
Maschinelles Lernen und generative KI sind zwei verschiedene Werkzeuge, und für Ihr Unternehmen macht die Unterscheidung einen großen Unterschied. ChatGPT schreibt Texte, Midjourney erzeugt Bilder. Klassisches Machine Learning löst operative Probleme auf Tabellendaten: Bedarfsprognosen, Preisoptimierung, Anomalieerkennung in der Produktion, Qualitätskontrolle. Generative KI ist ein Teilbereich des Deep Learning. Deep Learning ist wiederum eine Methode des maschinellen Lernens. Wer diese Hierarchie nicht kennt, kauft schnell die falsche Technologie oder übersieht regulatorische Anforderungen wie den EU AI Act Compliance 2026.
Was bedeutet ML für Ihr Geschäft? Algorithmen lernen aus Ihren historischen Daten, erkennen Muster und treffen Vorhersagen, ohne dass jemand jede Regel einzeln programmiert. Beispiel mit angenommenen Werten: Ein JTL-Shop mit 12.000 Artikeln lässt ein Modell aus zwei Jahren Bestellhistorie berechnen, welche Artikel in welcher Woche nachbestellt werden sollten. Eine feste Regel wie „immer 20 Stück nachbestellen“ kann Saisonschwankungen nicht abbilden, ein Modell mit Wochen- und Aktionsdaten kann es zumindest versuchen.
Deep Learning arbeitet anders. Es nutzt neuronale Netze, also Architekturen mit mehreren Schichten, die nichtlineare Zusammenhänge modellieren. Klassisches ML verarbeitet strukturierte Tabellendaten (Umsatz, Klickrate, Lagerbestand). Deep Learning wird vor allem bei unstrukturierten Daten eingesetzt: Bilder, Sprache, Sensorsignale. Generative KI wie GPT oder Stable Diffusion basiert auf Deep Learning, aber nicht jedes Deep-Learning-Modell erzeugt etwas. Ein Convolutional Neural Network (CNN), das fehlerhafte Bauteile am Fließband erkennt, klassifiziert nur. Die Konsequenz: Wer ausschließlich auf generative KI setzt, übersieht die operativen Einsatzfelder, die klassisches ML und spezialisiertes Deep Learning abdecken.
Welche Machine-Learning-Anwendungen im Mittelstand heute den größten Nutzen bringen
Im Mittelstand sind personelle Ressourcen begrenzt, deshalb entscheidet die Auswahl des Einsatzfelds über den Erfolg. Die folgende Tabelle ordnet die vier typischen Felder (Prognose, Klassifikation, Texterkennung, Empfehlungen) nach Datenbasis, Umsetzungsweg und Risiko. Die Einordnung ist meine fachliche Einschätzung, keine Studie.
| Anwendungsbereich | Datenbasis | Nutzen & Hebel | Umsetzungsaufwand und Weg | Risiko |
|---|---|---|---|---|
| Absatzprognose (Demand Sensing) | Historische ERP-Daten, Preise, Aktionen, Lagerstatus | Bessere Bestellmengen, weniger Fehlbestände und Überbestände möglich | Mittel. Meist eigenes Modell auf Tabellendaten (n8n plus Python), kein LLM nötig | Gering bei Absatzdaten ohne Personenbezug. Schlechte Datenlage ist das Hauptrisiko |
| Klassifikation von Kunden oder Bestellungen (Churn, Retouren, Betrug) | Shop-Transaktionen, Kundenhistorie | Priorisierung von Reaktivierung oder Prüfung | Gering bis mittel. Standardverfahren wie logistische Regression oder Gradient Boosting | Personenbezug: DSGVO prüfen, bei automatischen Entscheidungen Art. 22 |
| Texterkennung und Dokumentenverarbeitung (OCR) | Rechnungen, Lieferscheine als PDF oder Bild | Weniger Abtippen, schnellere Weiterleitung an die Buchhaltung | Gering. Fertiger Hersteller-API (zum Beispiel Cloud Vision, Preise unten) statt eigenem Modell | Fehlerhafte Felder, Datenschutz bei Auftragsverarbeitung |
| Textklassifikation im Support (Ticket-Routing) | Support-Historie, Kategorienliste | Zeitersparnis im First-Level-Support möglich | Gering. LLM-API mit klarer Kategorienliste und Stichproben-Kontrolle | Falsche Zuordnung bei Fachfragen, Personenbezug in Tickets |
| Empfehlungen im Shop | Klick- und Kaufdaten | Cross-Selling-Vorschläge | Mittel. Erst Shop-Bordmittel oder Regeln testen, eigenes Modell erst bei ausreichend Daten | Tracking-Einwilligung, Profiling |
| Predictive Maintenance | Sensordaten, Wartungshistorie | Weniger ungeplante Stillstände möglich | Hoch. Hardware-Anbindung und Ausfall-Historie nötig | Technisch komplex, wenige Ausfälle als Trainingsbeispiele |
Während einfache Automatisierungen oft über klassische Workflows abgebildet werden, erfordern komplexe Entscheidungsmuster Machine Learning. Für die Einordnung der Ansätze hilft der Vergleich RPA vs BPM vs KI. Als Faustregel gilt: Lässt sich ein Prozess mit drei klaren Wenn-dann-Regeln beschreiben, brauchen Sie kein ML. Erst wenn die Regeln zu zahlreich oder zu unscharf werden, lohnt sich ein gelerntes Modell.
Bedarfsprognose mit maschinellem Lernen: Daten, Baseline, Backtest
Die Bedarfsprognose ist das Einsatzfeld mit den meisten Fehlerquellen, weil sie auf den eigenen Daten aufbaut. Die folgenden Punkte entscheiden, ob ein Modell brauchbar wird.
Welche Daten für eine Bedarfsprognose nötig sind
Das AWS-Whitepaper zur Zeitreihenprognose nennt für den Handel als Mindestbestandteile Transaktionsdaten (Artikelnummer, Standort, Zeitstempel, verkaufte Einheiten), Artikelstammdaten, Preiszeitreihen, Aktionsdaten und eine Information, ob ein Artikel in jeder Zeiteinheit lieferbar war. Ein Anbieter-Leitfaden von aiSuperior beschreibt als allgemeine Faustregel mindestens zwei Jahre Verkaufsdaten in wöchentlicher Auflösung und betont, dass Datenqualität wichtiger ist als Datenmenge. Zwei Jahre brauchen Sie, damit das Modell jede Saison mindestens zweimal gesehen hat.
| Datenfeld | Wofür es gebraucht wird | Typischer Fallstrick |
|---|---|---|
| Artikelnummer, Standort, Datum, verkaufte Menge | Grundlage jeder Prognose | Uneinheitliche Zeitstempel, doppelte Buchungen, Retouren als negative Mengen |
| Lieferbarkeit je Tag oder Woche | Unterscheidung zwischen echter Nachfrage und Nachfrage, die nicht bedient werden konnte | Ohne diese Spalte wirken Fehlbestände wie Nachfrage null |
| Preise und Aktionen mit Datum | Erklären Ausschläge nach oben | Aktionen nur im Kopf des Einkäufers, nicht im System |
| Artikelstamm (Kategorie, Variante) | Ähnliche Artikel können voneinander lernen | Varianten ohne saubere Zuordnung zum Hauptartikel |
| Externe Signale (Saison, Feiertage, Wetter) | Zusätzliche Erklärung für Schwankungen | Mehr Spalten bedeuten nicht automatisch bessere Prognosen |
Quellen: AWS-Whitepaper, Schritt 1: Daten sammeln und aggregieren (Datenfelder, Lieferbarkeit) und aiSuperior, Machine Learning in der Bedarfsprognose (Zeitraum, externe Faktoren). Beide sind Herstellerseiten, keine unabhängigen Studien; die Spalte „Fallstrick“ ist meine Einschätzung.
Fehlbestände: Nachfrage null ist nicht Verkauf null
Der häufigste Datenfehler bei Shop-Prognosen: Ein Artikel war drei Wochen ausverkauft, die Verkaufszahl steht auf null, und das Modell lernt „kaum Nachfrage“. Das AWS-Whitepaper beschreibt genau diesen Unterschied: Gespeichert werden meist nur Verkäufe, nicht die potenzielle Nachfrage, und bei nicht vorrätigen Artikeln liegen die Verkäufe unter der Nachfrage. Praktisch heißt das: Markieren Sie Zeiträume ohne Lagerbestand als „nicht lieferbar“ und nehmen Sie sie aus dem Training heraus oder geben Sie dem Modell die Spalte mit.
Baseline zuerst: Schlägt das Modell die Vorwoche?
Bevor Sie ein Modell bewerten, brauchen Sie eine einfache Vergleichsprognose, zum Beispiel „nächste Woche so viel wie diese Woche“ oder „so viel wie im gleichen Zeitraum des Vorjahres“. Ein Modell, das diese Baseline im Test nicht schlägt, ist den Betrieb nicht wert, egal wie modern das Verfahren klingt.
Backtest statt Zufalls-Split
Bei Zeitreihen müssen Sie die Daten nach Zeit teilen, nicht zufällig. Das AWS-Whitepaper erklärt: Wer Datenpunkte zufällig auf Trainings- und Testdaten verteilt, lässt Informationen aus der Zukunft in das Training fließen (Datenleck). Außerdem sind mehrere Testfenster über verschiedene Zeiträume robuster als ein einziger Test, vor allem bei saisonalen Mustern wie dem Weihnachtsgeschäft. Dieses Vorgehen heißt Backtesting.
Welche Fehlermaße zu Ihrem Fall passen
Der prozentuale Fehler MAPE teilt durch den tatsächlichen Wert und versagt deshalb bei Tagen oder Wochen mit null Verkäufen (Division durch null). Das AWS-Whitepaper nennt den gewichteten Fehler WAPE als gängige Alternative, die dieses Problem vermeidet, weist aber auf Grenzen hin: Er ist nicht symmetrisch und liefert bei kleinen Zahlen aufgeblähte Werte. Wenn Über- und Unterbestand unterschiedlich teuer sind (Ladenhüter binden Kapital, Fehlbestände kosten Umsatz), eignen sich Quantil-Prognosen, die eine Spanne statt eines Einzelwerts liefern. Dafür nennt das Whitepaper den Weighted Quantile Loss.
Beispielrechnung mit angenommenen Werten: Ein Artikel hatte in fünf Wochen die Ist-Absätze 10, 0, 4, 20 und 6 (Summe 40). Ein Modell prognostizierte 8, 2, 5, 15 und 7. Die absoluten Abweichungen sind 2, 2, 1, 5 und 1, also 11 in Summe. Der WAPE beträgt 11 geteilt durch 40, also 27,5 Prozent. Die Baseline „Vorwoche“ hätte 12, 1, 4, 18 und 9 vorhergesagt, mit Abweichungen 2, 1, 0, 2 und 3 (Summe 8) und damit 20 Prozent WAPE. In diesem erfundenen Beispiel verliert das Modell gegen die Baseline. Ein echter Backtest braucht natürlich deutlich mehr als fünf Wochen und mehr als einen Artikel, die Logik bleibt aber gleich.
Welche Modellfamilie bei welcher Datenlage
Der oben genannte aiSuperior-Leitfaden nennt als gängige Verfahren Auto-ARIMA, ETS, Prophet und XGBoost. Für Shops mit überschaubarem Sortiment starten Sie mit der Baseline und einem statistischen Verfahren, dann einem Gradient-Boosting-Modell auf Tabellenmerkmalen (Wochentag, Aktion, Preis, Vorjahreswert). Tiefe neuronale Netze lohnen sich erst bei sehr vielen Artikeln und Signalen. Die Reihenfolge ist meine fachliche Empfehlung.
Wie neuronale Netze, supervised learning und predictive analytics in der Praxis zusammenspielen
Neuronale Netze sind kein Muss für zuverlässige Vorhersagen: In vielen Shop-Szenarien arbeiten klassische supervised-learning-Verfahren wie Entscheidungsbäume oder lineare Regression schneller und wartbarer. Die Wahl zwischen einfachem Modell und tiefem neuronalem Netz hängt von drei Faktoren ab: der Datenmenge für das Training, der geforderten Nachvollziehbarkeit (etwa gegenüber Kunden oder Aufsichtsbehörden) und den verfügbaren Rechenressourcen samt Budget. Reichen wenige tausend Datenpunkte und muss die Entscheidung erklärbar bleiben, ist ein einfaches Modell meist die bessere Wahl.
Entscheidend ist die Datenqualität. Ein komplexes Netz auf schlechten Daten schneidet in der Regel schlechter ab als ein einfaches Modell auf sauberen Daten.
Supervised learning funktioniert so: Sie trainieren ein Modell mit gelabelten Beispielen (Eingabe und bekanntes Ergebnis), damit es bei neuen Eingaben eine Vorhersage trifft. Beispiel aus dem eCommerce: zwölf Monate Bestelldaten mit Produktkategorie, Wochentag, Werbebudget und tatsächlichem Absatz. Das Modell lernt die Muster und prognostiziert die nächste Woche. Neuronale Netze sind eine Untergruppe dieser Verfahren: mehrere Schichten künstlicher Neuronen, die nichtlineare Muster erkennen. Predictive Analytics ist der Dachbegriff für alle Verfahren, die aus historischen Daten Vorhersagen ableiten, egal ob mit neuronalen Netzen, Entscheidungsbäumen oder statistischen Modellen.
So ist ein neuronales Netz aufgebaut: Eingabeschicht (Ihre Rohdaten), verdeckte Schichten (hier passiert die Mustererkennung) und Ausgabeschicht (die Vorhersage). Jedes Neuron gewichtet seine Eingaben, summiert sie auf und wendet eine Aktivierungsfunktion an. Beim Training werden die Gewichte so angepasst, dass die Vorhersage möglichst nah an den echten Werten liegt. Der Haken: Ein tiefes Netz braucht in der Regel sehr viele Trainingsbeispiele, um stabil zu lernen. Bei einem Shop mit kleinem Sortiment und wenigen Bestellungen pro Monat liefert ein lineares Modell oder ein Gradient Boosting Tree meist die besseren Ergebnisse bei einem Bruchteil des Aufwands.
Supervised learning im eCommerce ohne neuronale Netze:
- Churn-Prognose mit logistischer Regression: Kauft der Kunde in den nächsten 90 Tagen noch einmal?
- Bestandsoptimierung mit Random Forest oder Gradient Boosting: Welche Artikelnummer braucht Nachschub?
- Preisanpassung mit XGBoost: Welcher Preis passt zu Wettbewerb und Lagerbestand?
- Retourenvorhersage mit Entscheidungsbäumen: Welche Bestellung wird wahrscheinlich zurückgeschickt?
Diese Modelle trainieren auf Standard-Hardware, und Sie sehen, welche Merkmale die Vorhersage beeinflussen. Bei einem neuronalen Netz ist diese Nachvollziehbarkeit deutlich schwieriger (Black Box).
Neuronale Netze machen Sinn bei unstrukturierten Daten (Produktbilder, Kundenbewertungen, Chat-Verläufe) oder stark nichtlinearen Zusammenhängen mit vielen Variablen. Ein Convolutional Neural Network (CNN) erkennt defekte Produkte auf Fotos besser als jede Regel-Engine, und ein Transformer-Modell analysiert die Stimmung in Bewertungen genauer als reines Keyword-Matching.
Predictive Analytics in der Praxis heißt: Eine klare Frage stellen („Welche Kunden kaufen in Q2 nicht mehr?“). Historische Daten sammeln (Bestellfrequenz, durchschnittlicher Warenkorb, letzte Interaktion). Das Ergebnis labeln (abgewandert ja oder nein). Die Daten nach Zeit in Trainings- und Testteil trennen. Mehrere Modelle trainieren (logistische Regression, Random Forest, XGBoost), auf dem Testteil vergleichen und das einfachste ausreichende Modell wählen. Dann als API oder n8n-Workflow betreiben: Jeden Montag läuft das Modell über die aktuelle Kundenliste und markiert Risikokunden für eine Reaktivierungskampagne.
Der häufigste Fehler: Unternehmen kaufen eine „KI-Lösung“ mit neuronalem Netz, obwohl ihre Daten für ein einfaches Modell reichen würden. Neuronale Netze sind Werkzeuge für spezifische Probleme, keine Universallösung. Beginnen Sie mit dem einfachsten Modell, das funktioniert, und erhöhen Sie die Komplexität nur, wenn die Vorhersagegenauigkeit im Backtest messbar steigt.
Sie kennen die technischen Möglichkeiten, aber es fehlt die klare Priorisierung für Ihr Unternehmen. Was fehlt, ist eine objektive Bewertung der Einsatzfelder, damit Sie nicht in teure Fehlentwicklungen investieren, sondern dort ansetzen, wo die Hebelwirkung für Ihren Mittelstand am größten ist.
In welchen 5 Schritten eine KI-Implementierung in Deutschland sauber startet
Die Einführung künstlicher Intelligenz im deutschen Mittelstand scheitert oft nicht an der Technik, sondern an einer unklaren Prozessstruktur. Der folgende Plan führt in fünf Schritten von der Idee bis zum stabilen Betrieb. Jeder Schritt hat ein konkretes Ergebnis, an dem Sie erkennen, ob Sie weitergehen oder abbrechen sollten.
- Identifizieren Sie konkrete Schmerzpunkte im Tagesgeschäft. Legen Sie fest, welches Problem gelöst werden soll und woran Sie den Erfolg messen. Im eCommerce sind das oft zeitintensive Routineaufgaben wie die manuelle Kategorisierung von Artikeln oder das Sortieren von Support-Tickets. Ergebnis: ein Satz mit Zielgröße („Fehlbestände bei Top-Artikeln senken“) und der heutigen Messung als Ausgangswert. Eine klare Zieldefinition verhindert, dass Sie Budget in Experimente ohne ROI-Bezug stecken.
- Prüfen Sie die Datenqualität und die rechtlichen Rahmenbedingungen. KI braucht saubere Daten. Sind die Bestandsdaten in der Wawi lückenhaft, bleibt auch das Ergebnis unbrauchbar. Prüfen Sie: Wie viele Jahre Historie liegen vor, sind Fehlbestände markiert, enthalten die Daten Personenbezug? Parallel klären Sie, ob DSGVO, Art. 22 und die KI-Verordnung betroffen sind (siehe unten). Eine Orientierung bietet die Plattform Lernende Systeme. Ergebnis: eine Datenliste mit Lücken und eine Entscheidung „Personenbezug ja oder nein“.
- Wählen Sie die passende technische Architektur. Entscheiden Sie zwischen fertigen SaaS-Lösungen, einem Hersteller-API und einem eigenen Modell, angebunden zum Beispiel über n8n. Standard-Plugins stoßen bei Sonderlogiken schnell an Grenzen, Individualentwicklung ermöglicht eine präzise Integration. Bedenken Sie dabei die KI-Projekte Kosten Deutschland, bei denen Wartung und API-Gebühren eine größere Rolle spielen als die erste Entwicklung. Ergebnis: eine Make-or-Buy-Entscheidung mit Kostenrechnung (Vorlage im Abschnitt zu den Preisen).
- Starten Sie einen isolierten Pilotbetrieb (MVP). Rollen Sie die KI nicht sofort für das gesamte Sortiment aus. Wählen Sie eine Kategorie oder einen Prozess, etwa die Vorsortierung von Retouren-Anfragen, und testen Sie unter realen Bedingungen, bei Prognosen zusätzlich im Backtest gegen die Baseline. Ergebnis: eine Gegenüberstellung von Modell und Baseline auf Daten, die das Modell nie gesehen hat.
- Messen Sie die Ergebnisse und skalieren Sie schrittweise. Vergleichen Sie Bearbeitungszeit oder Prognosefehler vor und nach der Einführung. Erst wenn der Pilot den vorher festgelegten Wert erreicht, weiten Sie die Lösung aus. Planen Sie Monitoring und Neu-Training ein, denn Kundenverhalten und Sortiment ändern sich. Ergebnis: ein Betriebsplan mit Verantwortlichem und Prüfintervall.
| Schritt | Ergebnis | Abbruch oder Umplanung, wenn |
|---|---|---|
| 1. Problem und Messgröße | Zielgröße mit Ausgangswert | Niemand kann sagen, woran Erfolg gemessen wird |
| 2. Daten und Recht | Datenliste, Personenbezug geklärt | Weniger Historie als erforderlich oder rechtliche Grundlage fehlt |
| 3. Architektur | API oder eigenes Modell, Kostenrechnung | Laufende Kosten übersteigen den erwarteten Nutzen |
| 4. Pilot | Modell gegen Baseline getestet | Modell schlägt die Baseline nicht |
| 5. Betrieb | Monitoring, Neu-Training, Verantwortlicher | Kein Verantwortlicher für Modellpflege benannt |

API oder eigenes Modell: Make-or-Buy und belegte Preise
Die Kalkulation von KI-Vorhaben folgt anderen Gesetzmäßigkeiten als klassische Web-Projekte. Bei Hersteller-APIs zahlen Sie nach Verbrauch, bei eigenen Modellen entstehen Entwicklungs-, Betriebs- und Wartungskosten. Welcher Weg passt, hängt vor allem von der Art der Daten ab.
| Einsatzfeld | Meist sinnvoll | Begründung (eigene Einschätzung) |
|---|---|---|
| Absatzprognose auf Tabellendaten | Eigenes Modell | Die Prognose braucht Ihre Zeitreihen, nicht Sprachverständnis. Standardbibliotheken wie scikit-learn verursachen keine Gebühr je Anfrage |
| Text sortieren (Tickets, E-Mails) | LLM-API | Sprachmodelle verstehen Text ohne eigenes Training, die Kosten wachsen mit dem Volumen |
| Rechnungen und Belege auslesen | OCR-API | Fertige Texterkennung ist günstig und braucht kein Training |
| Empfehlungen im Shop | Shop-Bordmittel, später eigenes Modell | Erst bei ausreichend Klickdaten lohnt sich ein eigenes Modell |
| Sensible Daten ohne Drittland-Übermittlung | Eigenes oder in der EU betriebenes Modell | Wenn ein Vertrag mit dem API-Anbieter nicht infrage kommt, bleibt nur Eigenbetrieb |
Was die Hersteller für API-Nutzung veröffentlichen
| Dienst und Modell | Preis laut Herstellerseite | Quelle |
|---|---|---|
| Anthropic, Claude Haiku 4.5 | 1 US-Dollar je Mio. Eingabetoken, 5 US-Dollar je Mio. Ausgabetoken | Anthropic Pricing |
| Anthropic, Claude Sonnet 5.5 | 2 US-Dollar je Mio. Eingabetoken, 10 US-Dollar je Mio. Ausgabetoken | Anthropic Pricing |
| Anthropic, Claude Opus 5.5 | 4 US-Dollar je Mio. Eingabetoken, 20 US-Dollar je Mio. Ausgabetoken | Anthropic Pricing |
| Anthropic, Batch-Verarbeitung | 50 Prozent Rabatt auf Eingabe- und Ausgabetoken bei asynchroner Verarbeitung | Anthropic Pricing |
| Google Cloud Vision, Texterkennung (OCR) | Erste 1.000 Einheiten je Monat kostenlos, danach 1,50 US-Dollar je 1.000 Einheiten (eine Seite entspricht einer Einheit) | Cloud Vision Pricing |
Die Seiten weisen keine Umsatzsteuer aus. Für eine Kalkulation in Euro kommen Wechselkurs und gegebenenfalls Umsatzsteuer hinzu. Nach der Anthropic-Preisseite erzeugen Modelle ab Claude 4.7 (dazu gehört Sonnet 5.5) für denselben Text rund 30 Prozent mehr Token als ältere Modelle, Haiku 4.5 gehört zu den älteren. Rechnen Sie bei Vergleichen deshalb mit Ihrem echten Text und nicht nur mit dem Listenpreis. Eine Beispielrechnung des Herstellers zeigt die Größenordnung: Bei rund 3.700 Token je Konversation und Haiku 4.5 kosten 10.000 Support-Tickets etwa 37 US-Dollar.
Beispielrechnung: Ticket-Klassifikation mit angenommenen Werten
Angenommen, Ihr Shop bekommt 10.000 Tickets im Monat. Je Ticket gehen 800 Eingabetoken (Ticket plus Kategorienliste) an das Modell, zurück kommen 30 Ausgabetoken (der Kategoriename). Das sind 8 Mio. Eingabe- und 0,3 Mio. Ausgabetoken im Monat.
- Haiku 4.5: 8 mal 1 plus 0,3 mal 5 gleich 9,50 US-Dollar im Monat. Mit Batch-Rabatt (nur bei nicht eiligen Aufträgen) 4,75 US-Dollar.
- Sonnet 5.5: 8 mal 2 plus 0,3 mal 10 gleich 19,00 US-Dollar, bei rund 30 Prozent mehr Token durch den neueren Tokenizer bis etwa 24,70 US-Dollar.
- Opus 5.5: 8 mal 4 plus 0,3 mal 20 gleich 38,00 US-Dollar vor einem möglichen Token-Aufschlag.
Die Formel für Ihre eigene Rechnung: Anfragen je Monat mal (Eingabetoken mal Eingabepreis plus Ausgabetoken mal Ausgabepreis), geteilt durch eine Million. Die Zahlen sind angenommen, die Preise sind belegt. Entscheidend ist deshalb meist nicht die API-Gebühr, sondern die Zeit für Einrichtung, Prüfung der Ergebnisse und Betrieb. Dieser Aufwand ist projektabhängig und lässt sich nicht seriös pauschal beziffern.
Für die Texterkennung: Bei 800 gescannten Rechnungsseiten im Monat bleibt der Cloud-Vision-Verbrauch im kostenlosen Kontingent von 1.000 Einheiten. Bei 2.000 Seiten fallen für 1.000 Einheiten 1,50 US-Dollar an. Ob die erkannten Felder (Rechnungsnummer, Betrag) zuverlässig genug sind, zeigt nur eine Stichprobe mit Ihren Belegen.
Was beim eigenen Modell zusätzlich zu rechnen ist
Ein eigenes Modell hat keine Gebühr je Anfrage, aber laufende Kosten an anderer Stelle: Entwicklung, Hosting, Überwachung, Neu-Training und eine Person, die das Modell pflegt. Pauschale Euro-Spannen für „Proof of Concept“ oder „Plattform“ gibt es in diesem Artikel bewusst nicht, weil mir dafür keine belastbare Quelle vorliegt. Holen Sie stattdessen für Ihren Fall Angebote ein und lassen Sie die laufenden Kosten pro Jahr getrennt ausweisen. Weitere Kostenfaktoren finden Sie im Artikel KI-Projekte Kosten Deutschland.
Datenschutz und KI-Verordnung: DSGVO, Art. 22 und Fristen
Für die meisten ML-Projekte im Mittelstand sind drei Fragen entscheidend: Verarbeiten Sie personenbezogene Daten? Entscheidet das System allein über Menschen? Fällt der Einsatz in eine Hochrisiko-Kategorie der KI-Verordnung? Dies ist keine Rechtsberatung, die Einordnung im Einzelfall übernimmt eine Rechtsberatung oder Ihr Datenschutzbeauftragter.
DSGVO: Personenbezug klären
Absatzprognosen auf Artikel- und Datumsebene enthalten in der Regel keine personenbezogenen Daten. Churn-Prognosen, Kundensegmentierung und Ticket-Auswertung dagegen schon. Dann gelten die allgemeinen Pflichten: Rechtsgrundlage, Datenminimierung (Art. 5 Abs. 1 Buchst. c DSGVO), Auftragsverarbeitungsvertrag mit dem API-Anbieter (Art. 28 DSGVO) und bei hohem Risiko eine Datenschutz-Folgenabschätzung (Art. 35 DSGVO). Die Konferenz der unabhängigen Datenschutzaufsichtsbehörden (DSK) hat am 6. Mai 2024 eine Orientierungshilfe „Künstliche Intelligenz und Datenschutz“ veröffentlicht, die als Checkliste für Auswahl, Einführung und Nutzung von KI-Anwendungen dient.
Praktisch bedeutsam ist der Verarbeitungsort. Auf der Preisseite von Anthropic sind für die API die Optionen „global“ und „us“ für die Inferenz genannt, bei Amazon Bedrock und Google Cloud gibt es regionale Endpunkte mit einem Preisaufschlag von 10 Prozent gegenüber globalen Endpunkten. Welche Region für Ihren Fall zulässig ist, klären Sie vor dem Einsatz mit dem Anbieter und Ihrem Datenschutzbeauftragten.
Art. 22 DSGVO: Wann eine Maschine nicht allein entscheiden darf
Art. 22 Abs. 1 DSGVO gibt Betroffenen das Recht, nicht einer ausschließlich auf automatisierter Verarbeitung (einschließlich Profiling) beruhenden Entscheidung unterworfen zu werden, die ihnen gegenüber rechtliche Wirkung entfaltet oder sie in ähnlicher Weise erheblich beeinträchtigt. Ausnahmen nennt Abs. 2: erforderlich für einen Vertrag, erlaubt durch Rechtsvorschrift oder ausdrückliche Einwilligung. In den Vertrags- und Einwilligungsfällen muss der Verantwortliche nach Abs. 3 angemessene Schutzmaßnahmen treffen, mindestens das Recht auf Eingreifen einer Person, auf Darlegung des eigenen Standpunkts und auf Anfechtung der Entscheidung.
Wie weit der Begriff reicht, zeigt das Urteil des EuGH vom 7. Dezember 2023 (Rechtssache C-634/21, SCHUFA Holding). Der Gerichtshof sah schon die automatische Erstellung eines Wahrscheinlichkeitswerts über die Zahlungsfähigkeit als Entscheidung im Sinne des Art. 22 an, wenn dieser Wert maßgeblich darüber bestimmt, ob ein Dritter einen Vertrag mit der Person schließt. Für Sie bedeutet das nach meiner Einschätzung: Eine reine Bestandsprognose berührt Art. 22 nicht. Ein Modell, das Kunden automatisch Zahlarten sperrt oder Bewerber aussortiert, sollte dagegen rechtlich geprüft werden, bevor es produktiv geht. Ein Mensch, der Modellvorschläge tatsächlich prüft und ändern kann, ist die einfachste Absicherung.
KI-Verordnung: Fristen und Hochrisiko
Die Verordnung (EU) 2026/1744 (Digital-Omnibus zur KI) vom 8. Juli 2026 wurde am 24. Juli 2026 im Amtsblatt veröffentlicht und ist am 27. Juli 2026 in Kraft getreten. Sie verschiebt die Pflichten für Hochrisiko-Systeme nach Anhang III auf den 2. Dezember 2027 und für in Produkte eingebettete Systeme (Art. 6 Abs. 1) auf den 2. August 2028. Die Transparenzpflicht nach Art. 50 Abs. 1 (Nutzer müssen erkennen, dass sie mit einer KI interagieren, etwa bei Chatbots) gilt seit 2. August 2026. Auch Art. 4 (KI-Kompetenz) wurde neu gefasst: Betreiber müssen Maßnahmen zur Förderung der KI-Kompetenz ihres Personals ergreifen, ein bestimmtes Kompetenzniveau je Person müssen sie nicht mehr garantieren.
Anhang III der Verordnung nennt als Hochrisiko-Bereiche unter anderem Beschäftigung, Bildung und die Bewertung der Kreditwürdigkeit natürlicher Personen. Typische Mittelstands-Anwendungen wie Bestandsprognose, Ticket-Sortierung oder Produktempfehlungen stehen dort nicht, nach meiner Einschätzung gehören sie in der Regel nicht dazu. Prüfen müssen Sie es trotzdem, wenn ein System Bewerber vorsortiert oder Bonität einschätzt. Hochrisiko-Pflichten sind unter anderem Risikomanagement, technische Dokumentation, Protokollierung und menschliche Aufsicht.
Der Bußgeldrahmen in Art. 99 liegt bei bis zu 35 Mio. EUR oder 7 % des weltweiten Jahresumsatzes bei verbotenen Praktiken und bei bis zu 15 Mio. EUR oder 3 % bei vielen anderen Verstößen, darunter die Transparenzpflichten. Für KMU gilt jeweils der niedrigere der beiden Beträge. Wenn Sie ein Verzeichnis von Verarbeitungstätigkeiten nach Art. 30 DSGVO führen, ergänzen Sie es um Modelltyp, Herkunft der Trainingsdaten, Bewertungsmaße und Verantwortlichen. Das spart später Doppelarbeit.
Häufige Fehler und Risiken bei Datenqualität, Black-Box-Modellen und Cyberangriffen
Die meisten gescheiterten ML-Projekte scheitern an denselben acht Fehlern, nicht an der Rechenleistung. Die Liste ist eine Zusammenstellung aus den oben genannten Quellen und meiner fachlichen Einschätzung, keine Studie:
- Kein messbares Ziel. Ohne Ausgangswert lässt sich nach dem Projekt nicht sagen, ob es etwas gebracht hat.
- Fehlbestände nicht markiert. Das Modell lernt aus Nullverkäufen falsche Nachfrage.
- Zufälliger statt zeitlicher Split. Das Modell sieht beim Training die Zukunft und wirkt im Test besser, als es im Betrieb ist.
- Keine Baseline. Ohne Vergleichsprognose lässt sich nicht beurteilen, ob das Modell überhaupt etwas leistet.
- Falsche Fehlermaße. MAPE bei Nullverkäufen liefert unbrauchbare Werte, WAPE ist hier die gängige Alternative.
- Sprachmodell für Tabellenprognosen. Für Zeitreihen sind klassische Verfahren auf Ihren Daten in der Regel passender und günstiger als ein LLM.
- Personenbezogene Daten ungeprüft an einen API-Anbieter senden. Auftragsverarbeitung und Verarbeitungsort vorher klären.
- Kein Betrieb nach dem Pilot. Modelle veralten, wenn sich Sortiment und Kundenverhalten ändern. Ohne Verantwortlichen und Prüfintervall wird die Prognose unbemerkt schlechter.
Datenqualität und Bias: Fehlerhafte oder verzerrte Trainingsdaten führen zu systematischen Modellfehlern. Überbestände binden Kapital, Fehlbestände kosten Umsatz. Stammen die Trainingsdaten nur aus bestimmten Kundengruppen, kann das Modell andere Segmente schlechter bedienen. Die Plattform Lernende Systeme empfiehlt, Datenherkunft, Qualitätsprüfungen und regelmäßige Audits zu dokumentieren. Wer Datenqualität vernachlässigt, bekommt fehlerhafte Prognosen, die direkt in Preisgestaltung oder Bestandsplanung einfließen.
Black-Box-Modelle und Compliance: Deep-Learning-Systeme liefern oft präzise Ergebnisse ohne erkennbare Logik. Das wird zum Problem, wenn eine Entscheidung begründet werden muss, etwa gegenüber Betroffenen nach Art. 22 DSGVO oder bei Gleichbehandlungsfragen. Klären Sie vorab: Wer prüft Modellentscheidungen, wer dokumentiert die Logik, wer trägt die Verantwortung?
Cyberangriffe auf KI-Systeme: Deepfakes ermöglichen Social Engineering, etwa gefälschte Video-Calls mit vermeintlichen Geschäftsführern, die Zahlungsfreigaben verlangen. Gegen manipulierte Eingabedaten helfen Plausibilitätsprüfungen auf Modell-Ausgaben und der Zugriffsschutz auf Trainingsdaten. Wie häufig solche Angriffe im Mittelstand sind, kann ich nicht belegen, deshalb hier keine Zahl.
Warum KI 2026 vor allem Produktivität sichert statt sofort Wachstumssprünge zu liefern
KI-Projekte im Mittelstand bringen realistisch zuerst saubere Prozesse, weniger Fehler und Zeitersparnis, selten sofortige Umsatzsprünge. KI sichert zunächst die Produktivität, die durch manuelle Workarounds, fehleranfällige Excel-Prozesse und schlechte Datenqualität verloren geht. Erst danach entstehen Wachstumschancen, und auch diese lassen sich nicht zusichern.
Im Mittelstand fehlt oft die Grundlage: Liefert die Warenwirtschaft keine sauberen Bewegungsdaten, kann kein Algorithmus eine präzise Bedarfsprognose erstellen. Deshalb beginnt echte Automatisierung mit den Basics, also repetitive Aufgaben auslagern, nicht mit der Vision eines vollautonomen Systems.
Beispielrechnung mit angenommenen Werten: Eine Mitarbeiterin prüft wöchentlich zwölf Stunden Rechnungen von Hand. Verkürzt eine automatische Vorprüfung diese Zeit auf zwei Stunden, entstehen im Monat rund 40 Stunden Kapazität (zehn Stunden mal vier Wochen). Ob sich das lohnt, hängt von Einrichtung, laufenden Kosten und davon ab, wofür die frei gewordene Zeit eingesetzt wird. Zeitgewinn ist nicht automatisch Umsatz.
Predictive Analytics im deutschen Mittelstand bedeutet nicht, dass ein System Ihre Entscheidungen trifft. Es hilft, Muster zu erkennen, die manuell unsichtbar bleiben, basierend auf historischen Daten und Saisonalität. Die Prognose funktioniert aber nur, wenn die Warenwirtschaft saubere Daten liefert. Wer KI auf fehlerhafte Excel-Exporte aufsetzt, automatisiert nur das Chaos.
Was Sie jetzt mitnehmen
Sie haben jetzt einen nüchternen Überblick über Einsatzfelder, Datenvoraussetzungen, Preise und rechtliche Fragen von maschinellem Lernen im Mittelstand. ML ist kein Allheilmittel, aber ein Werkzeug für Routineaufgaben, Datenanalyse und Prozessoptimierung. Die Frage ist nicht „ob“, sondern „wo“ und „wie“ sich der Einsatz in Ihrem Betrieb rechnet.
Die wichtigsten Punkte in Kürze: Prüfen Sie zuerst Ihre Daten (zwei bis drei Jahre Historie, Fehlbestände markiert). Vergleichen Sie jedes Modell mit einer einfachen Baseline im zeitlichen Backtest. Für Texte und Dokumente reicht meist ein Hersteller-API, dessen Kosten Sie mit der oben gezeigten Formel selbst nachrechnen können. Klären Sie Personenbezug, Auftragsverarbeitung und Art. 22, bevor etwas produktiv geht. Weitere Details zu Kostenfaktoren finden Sie im Artikel KI-Projekte Kosten Deutschland.
Drei sinnvolle Startpunkte für Mittelständler: Erstens, automatisierte Dokumentenverarbeitung (Rechnungen, Lieferscheine), weil Dokumente ein klar abgegrenztes Problem sind und Fertig-APIs verfügbar sind. Zweitens, Bedarfsprognose oder Predictive Maintenance, wenn Sie ausreichend historische Daten haben. Drittens, Kundenservice-Chatbots mit Übergabe an Menschen, wenn Ihr Support viele wiederkehrende Anfragen bearbeitet. Achten Sie bei Chatbots auf die Kennzeichnung als KI nach Art. 50.
Häufig gestellte Fragen
Wie viele Daten braucht eine Bedarfsprognose mit maschinellem Lernen?
Als Faustregel nennen Fachquellen mindestens zwei bis drei Jahre Absatzdaten, bei Händlern in wöchentlicher Auflösung. Wichtiger als die Menge ist die Qualität: Fehlbestände müssen markiert sein, sonst lernt das Modell aus Nullverkäufen eine zu niedrige Nachfrage.
Brauche ich neuronale Netze für Absatzprognosen?
Nein. Für Tabellendaten mit überschaubarem Sortiment sind eine Baseline, statistische Verfahren und Gradient Boosting meist die bessere Wahl: schneller, wartbarer und leichter zu erklären. Neuronale Netze lohnen sich bei unstrukturierten Daten wie Bildern oder sehr großen Datenmengen.
Woran erkenne ich, ob mein Prognosemodell gut genug ist?
Vergleichen Sie es in einem zeitlichen Backtest mit einer einfachen Baseline, zum Beispiel dem Wert der Vorwoche. Ein Modell, das diese Baseline nicht schlägt, ist den Betrieb nicht wert. Bei Nullverkäufen ist der WAPE aussagekräftiger als der MAPE.
Was kostet die Nutzung einer KI-API?
Anthropic nennt für Claude Haiku 4.5 1 US-Dollar je Million Eingabetoken und 5 US-Dollar je Million Ausgabetoken, für Sonnet 5.5 2 und 10 US-Dollar (Stand: Oktober 2026). Google Cloud Vision berechnet für Texterkennung nach 1.000 kostenlosen Einheiten pro Monat 1,50 US-Dollar je 1.000 Einheiten. Mit der Formel im Abschnitt zu den Preisen rechnen Sie Ihre Menge selbst aus.
Fällt mein ML-Einsatz unter Art. 22 DSGVO oder die Hochrisiko-Regeln der KI-Verordnung?
Bestandsprognosen ohne Personenbezug berühren Art. 22 in der Regel nicht. Entscheidet ein System allein über Menschen, etwa bei Bonität oder Bewerberauswahl, sollten Sie das rechtlich prüfen lassen. Die Hochrisiko-Pflichten nach Anhang III gelten laut Verordnung (EU) 2026/1744 erst ab 2. Dezember 2027, Art. 50 gilt seit 2. August 2026. Mehr dazu im Artikel UI Was ist das: Benutzeroberflächen für den Shop-Erfolg.
