Warum dieser Beitrag
Der KI-Markt 2026 ist laut. Jeder Vendor hat eine Demo, jede Branche eine „AI-First-Strategie", jeder Berater einen 30-Folien-Pitch. Wir auch — aber wir haben uns vorgenommen, im Erstgespräch ehrlich zu sagen, wenn KI nicht der richtige Hebel ist. Das ist nicht edel — es ist betriebswirtschaftlich. Schlecht passende KI-Projekte sterben in der Beta, brennen Budget und vergiften das Verhältnis zur eigenen IT.
Vier Pattern, die wir regelmässig sehen und bei denen wir „kauf das nicht" sagen.
Pattern 1 — Inbound unter ~20 pro Tag bei Klassifikation oder Triage
Beispiel: Ein KMU will einen Sales-/Support-Triage-Agent. Inbound-Volumen: 15 Mails pro Tag, davon 70 % von drei bekannten Lieferanten-Domänen.
Unsere Empfehlung: klassisches Rule-Routing reicht. Ein Regex auf den Absender, eine Whitelist für die Stamm-Kunden, ein paar Subject-Pattern, fertig. Aufwand: ein bis zwei Tage. Pflege: gelegentlich eine neue Regel.
Ein LLM einzusetzen, um 15 Mails pro Tag zu klassifizieren, ist Über-Engineering: Sie zahlen Token-Kosten und tragen Modell-Risiko für ein Problem, das eine Wenn-Dann-Liste löst. Erst wenn Volumen UND Variabilität gleichzeitig wachsen — also wenn 80+ Inbound pro Tag aus einer unvorhersehbaren Mischung von Quellen kommen — lohnt sich der Agent. Vorher nicht.
Mehr dazu in Use Case 09, wo wir die Schwellen explizit benennen.
Pattern 2 — Einmalige Aufgabe oder einmalige Migration
Beispiel: Ein Unternehmen plant eine einmalige Daten-Migration von einem alten CRM in ein neues. 4'000 Records, fünf Felder, klare Mapping-Logik. „Können Sie das mit einem Agent machen?"
Können wir. Sollten Sie aber nicht. Bei einer einmaligen Aufgabe ohne wiederkehrenden Wert verteuert KI das Projekt unnötig: Setup, Eval, Guardrails, Audit-Trail — alles Aufwand, der einmalig genutzt wird und dann verfällt. Ein erfahrener Migrations-Berater macht das mit Excel, einem ETL-Skript und drei Stunden Review schneller und günstiger.
Anders sieht es aus, wenn die Migration strukturell wiederkehrt (z.B. quartalsweise Bestandstransfers, oder ein Unternehmen, das regelmässig Akquisitionen integriert). Dann lohnt sich der Aufbau eines agentengestützten Workflows — siehe Use Case 01 Agentische SAP-Migration, wo genau das das Bild ist.
Faustregel: Würden Sie das Skript ein zweites Mal brauchen? Wenn nein, manuell. Wenn ja, fünf Mal? Dann lohnt sich der Agentenwert.
Pattern 3 — Sehr stabile, schema-konforme Datenquellen
Beispiel: Eine Treuhandfirma bekommt monatlich Standard-Lohnabrechnungen von zehn Kunden — alle als strukturierte XML-Dateien nach gleichem Schema. „Können wir das per KI ins System bringen?"
Können wir, aber klassisches ETL ist hier besser. Wenn die Daten:
- ein stabiles Schema haben (Felder ändern sich nicht jeden Monat),
- in einem maschinenlesbaren Format vorliegen (XML, JSON, strukturiertes CSV),
- und ohne interpretative Mehrdeutigkeit ankommen (kein „mal so, mal so" pro Lieferant),
dann ist eine deterministische ETL-Pipeline einfacher, schneller, billiger — und Sie müssen sie nicht evaluieren. Ein LLM bringt hier nur eine zusätzliche Quelle für stille Fehler.
KI wird interessant, wenn das Format kreativ wird: Eingangsrechnungen in zehn unterschiedlichen Layouts, Verträge mit handschriftlichen Anpassungen, Formulare ohne festes Schema. Dort ist die Dokument-Extraktions-Pipeline (Use Case 07) genau richtig. Bei reinen Strukturdaten dagegen: ETL.
Pattern 4 — Wissensbasis unter ~50 Dokumenten
Beispiel: Ein Startup mit 25 Mitarbeitenden möchte ein RAG-System für die interne Wissensbasis. Vorhanden: ein HR-Handbuch (12 Seiten), drei IT-Policies, eine Sammlung von Onboarding-Notizen.
Unsere Empfehlung: schreiben Sie ein gutes Wiki. Bei weniger als ~50 sinnvoll abgegrenzten Dokumenten zahlt sich der Aufbau einer Such-Pipeline nicht aus. Notion, Confluence oder ein gut gepflegtes README im SharePoint mit klarer Struktur lösen das Problem besser. Die Volltextsuche reicht für so kleine Bestände.
RAG wird sinnvoll, wenn:
- die Wissensbasis substanziell ist (Erfahrungswert: 200+ Dokumente),
- die Suchfrequenz spürbar ist (mehrere Anfragen pro Woche, nicht pro Quartal),
- die Antwortqualität messbar wichtig ist (z.B. weil HR sonst dieselben fünf Fragen pro Woche beantwortet).
Bei kleinen Wissensbasen produziert RAG einen netten Demo-Effekt, kostet aber Pflegezeit, die durch die geringe Nutzung nie zurückkommt. Konkretes zum Setup in Use Case 06 RAG über interne Wissensbasis, und Schwellen in der FAQ.
Warum wir das so machen
Drei Gründe, weshalb wir lieber Discovery-Sessions führen, in denen wir manchmal abraten, als jeden Lead in ein PoC zu drücken:
Discovery ist günstiger als Sunk-Cost
Ein zwei-stündiges Erstgespräch, in dem wir den Use Case ehrlich beurteilen, spart Ihnen unter Umständen 6 Wochen PoC und mittlere fünf-stellige Beträge.
Ein gescheitertes PoC ist teurer als kein PoC
Wenn Sie Ihrem Vorstand erklären müssen, warum die KI-Initiative nichts liefert, ist das schwieriger als zu sagen „wir haben es geprüft und entschieden, es nicht zu tun".
Reputation ist zyklisch
Kundinnen und Kunden, denen wir abgeraten haben, kommen für die nächsten Projekte zurück — weil sie wissen, dass wir nicht jeden Auftrag annehmen. Das funktioniert besser als jede Marketing-Kampagne.
Wann KI doch der richtige Hebel ist
Damit dieser Beitrag kein „nie KI"-Manifest wird: Es gibt viele Use Cases, bei denen KI deutlich überlegen ist. Drei Pattern, bei denen wir mit Überzeugung empfehlen:
- Variabler Inbound mit echtem Volumen — 100+ Mails pro Tag aus wechselnden Quellen → Triage-Agent, eindeutig.
- Kreativ strukturierte Dokumente — Eingangsrechnungen, Verträge mit handschriftlichen Anpassungen, Formulare ohne festes Schema → Dokument-Extraktion mit Review-Queue.
- Wissensbasen 200+ Dokumente mit hoher Suchfrequenz — HR, IT, Vertragsmuster, Q&A → RAG mit Zitaten und Eskalation für sensible Themen.
In diesen Pattern liefert KI Tag-statt-Wochen-Verbesserungen mit auditfertigem Trail. Die Use-Case-Bibliothek zeigt zwölf solche Pattern in voller Tiefe.
Fazit
KI ist mächtig — und mächtige Werkzeuge sind nicht in jeder Situation angemessen. Vier Pattern, bei denen wir Ihnen abraten würden:
- Pattern 1 — Inbound unter 20/Tag → Rule-Routing reicht.
- Pattern 2 — Einmalige Aufgaben → manuelle Bearbeitung ist günstiger.
- Pattern 3 — Strukturierte, schema-konforme Daten → klassisches ETL ist besser.
- Pattern 4 — Wissensbasis unter 50 Dokumenten → Wiki und Glossar pflegen.
Wenn Sie unsicher sind, ob Ihr Use Case in eines dieser Pattern fällt, oder ob KI doch der richtige Hebel ist: ein Discovery-Call klärt das in einer Stunde — und kostet Sie nichts. Auch wenn das Ergebnis ist, dass wir kein gemeinsames Projekt starten sollten.
Mehr zur strategischen Beratung: KI-Beratung — Architektur-Reviews und Strategie.
Unsicher, ob Ihr Use Case in eines dieser Pattern fällt?
Ein Discovery-Call dauert eine Stunde und ist kostenlos. Sie bekommen eine ehrliche Einschätzung — auch wenn die Antwort „klassische Lösung reicht" lautet.
Discovery-Call anfragen