Die leidigen Use-Case-Schubladen

Wenn ich noch eine Tabelle vorgesetzt bekomme, in der binär (oder auf einer 3er-Skala) Generative KI vs. Non-Generative KI für 10 Use-Case-Schubladen eingeordnet wird, esse ich einen Stehtisch.

Schubladen liefern Unternehmen perfekte Vorwände, sich für zahllose Use Cases nicht mit Generativer KI zu beschäftigen. Wenn man dann auch kein ML/Data-Science-Team hat, lässt man’s halt.

„Ja, Herr Glaser, aber 95 % aller GenAI-Proof-of-Concepts scheitern doch laut Studie!“

Und das sollen sie! Unternehmen müssen Erfahrungen sammeln und Intuition aufbauen. Sie müssen lernen, rapide zu iterieren und zu erkunden. Das ist spätestens im Produktionsbetrieb unabdingbar – unabhängig von Studienlagen. Die erwähnte Studie war übrigens methodisch schwach. Wer die eigene Organisation nicht so aufstellt, dass schnelles Erproben, Lernen, Verwerfen (oder sofortiges In-Produktion-Bringen) möglich ist, wird es schwer haben.

Es ist, wie es ist: Transformer kannibalisieren klassische ML-Domänen.

Nehmen wir Use Cases, die jahrelang in der „Non-GenAI“-Schublade lagen:

Anomalieerkennung in Zeitreihen? Jahrelang die Domäne von XGBoost, Isolation Forests, LSTM-Netzen. Heute können wir LLM-gestützte Systeme auf Produktionsmetriken, Prozess- oder Knowledge-Graphen ansetzen und nach Mustern fragen, Hypothesen generieren und Befunde erklären. Ja, das braucht Context Engineering. Ja, die Latenz ist höher. Ja, die Inferenzkosten pro Anfrage sind anders zu bewerten. Aber: deutlich weniger klassisches Feature Engineering, weniger gelabelte Trainingsdaten, keine separate MLOps-Pipeline für jedes Teilproblem. Der Trade-off verschiebt sich – auch wenn für harte SLAs weiterhin spezialisierte Modelle führen.

Sentiment-Analyse? Vor drei Jahren: fein-getunte BERT-Varianten mit tausenden manuell gelabelten Samples, aufwendige Labeling-Plattformen, kontinuierliches Retraining. Heute: Zero-Shot oder Few-Shot mit Foundation Models – die auch Ironie (manchmal), Code-Switching und domänenspezifische Nuancen besser erfassen. Ob das wirtschaftlicher ist? Kommt drauf an: Datenverfügbarkeit, Inferenzlast, Anforderungen an Erklärbarkeit, Reproduzierbarkeit und Datenschutz.

Dokumentenklassifikation? Die klassische Spielwiese für Random Forests und SVMs. Heute geben wir Vision-Language-Modelle PDFs, Scans, Tabellen – sie verstehen Layout, semantische Zusammenhänge und visuelle Strukturen gleichzeitig. Das ist nicht „per se besser“. Es ist ein anderes Set an Constraints: Latenz, Kosten, Determinismus, Datenschutz. Aber es ist verfügbar – oft out-of-the-box auf Datensätzen, für die ich vorher Wochen in Feature-Extraktion investiert hätte.

Predictive Maintenance? Für die Vorhersagekomponente mit harten Latenz- und Zuverlässigkeitsanforderungen bleibt klassisches ML oft die bessere Wahl. Aber: Datenaufbereitung, Identifikation relevanter Korrelationen, automatische Generierung von Wartungsberichten, Interpretation von Anomalien für nicht-technisches Personal – das übernehmen zunehmend LLMs. Der Use Case hybridisiert sich.

Die Frage ist nicht mehr „GenAI oder Non-GenAI“.

Die Frage ist: Haben wir die technische Reife und organisatorische Beweglichkeit, um in Wochen herauszufinden, wo Transformermodelle unsere Lösungen ergänzen, ersetzen oder obsolet machen – oder völlig neue schaffen können? Können wir das Kosten-Nutzen-Verhältnis für unser spezifisches Integrationsszenario evaluieren? Haben wir die Kapazität, beide Ansätze parallel zu testen? Wenn nicht: Machen wir dann einfach nichts?

Wer 2025 noch in statischen Use-Case-Taxonomien denkt, ignoriert die Kannibalisierungsdynamik. Technologie entwickelt sich in Monaten, nicht in Planungszyklen. Das erfordert eine Kultur des permanenten, methodischen Experimentierens – nicht die administrative Kategorisierung im Q3-Strategieworkshop.