Warum oberflächliche KI-Beratung
mehr kostet als sie bringt –
und wann klassische Systeme gewinnen.
Als Softwareentwickler mit 20 Jahren Projekterfahrung sage ich es direkt: Nicht alles, was KI technisch kann, sollte man auch bauen. Die Token-Rechnung entscheidet – nicht das Pitch-Deck.
Wir bekommen regelmäßig Anfragen, die so beginnen: „Wir haben mit einem KI-Berater gesprochen – der meint, wir können das mit einem LLM lösen." In vielen Fällen stimmt das technisch. Aber die eigentliche Frage – ob es auch wirtschaftlich sinnvoll ist – bleibt dabei zu oft unbeantwortet.
Ich schreibe diesen Artikel, weil wir als Softwareentwickler täglich an der Grenze zwischen dem arbeiten, was möglich ist, und dem, was sinnvoll ist. Und weil ich in den letzten zwei Jahren beobachte, wie ein wachsender Markt an KI-Coaches und „Transformation Consultants" diese Grenze systematisch verwischt – nicht aus böser Absicht, sondern aus fehlendem technischem Tiefgang.
Das ist kein Anti-KI-Artikel. Wir setzen KI-Komponenten bei genPsoft aktiv in Projekten ein – Voice AI, Chatbot-Integrationen, Klassifizierungssysteme. Aber eben dort, wo die Rechnung aufgeht. Und das ist längst nicht überall der Fall.
Das Problem: Was im Workshop fehlt
KI-Workshops haben eine typische Dramaturgie. Man sieht beeindruckende Demos. Es wird gezeigt, was ChatGPT, GPT-4, Claude oder ähnliche Modelle können. Das Publikum ist begeistert. Dann folgen Use-Cases, Post-its, Priorisierungsmatrizen.
Was strukturell fehlt – fast immer – ist die Betriebskostenrechnung. Sprich: Was kostet dieses System nicht einmalig zu entwickeln, sondern laufend zu betreiben? Und steht dieser Betrag in einem vernünftigen Verhältnis zum erzielten Nutzen?
„Nach vier Monaten Entwicklung und rund 35.000 Euro Investment mussten wir feststellen, dass uns die monatlichen API-Kosten mehr kosten als der konkrete Nutzen, den wir aus dem System ziehen."
— Sinngemäß aus einem unserer Erstgespräche, anonymisiert · Mittelständisches Unternehmen, Süddeutschland
Dieses Muster habe ich in mehreren Varianten erlebt. Das zugrundeliegende Problem ist immer dasselbe: Der Total Cost of Ownership (TCO) wurde nicht sauber berechnet, weil die Beratung nur den Aufbau, nicht den Betrieb im Blick hatte.
Fallstudie: KI durchsucht Gemeindewebseiten nach Ausschreibungen
Ich zeige das anhand eines konkreten, realen Use-Cases – anonymisiert, aber technisch präzise. Ein Softwaredienstleister möchte öffentliche Vergabe- und Ausschreibungshinweise automatisiert erfassen. Die Idee: Ein KI-Agent soll alle relevanten Gemeindewebseiten in der DACH-Region crawlen, den Inhalt analysieren, Ausschreibungen identifizieren und strukturiert aufbereiten.
Technisch: machbar. Der KI-Berater: begeistert. Die Zustimmung des Managements: erteilt.
Was wirklich gerechnet werden muss
Jeder Schritt dieses Systems kostet Tokens. Tokens kosten Geld. Bei großen, heterogenen Datenmengen addiert sich das sehr schnell.
Kritische Folgefrage: Ein interner Mitarbeiter findet in 30 Minuten manueller Recherche 2–3 relevante Ausschreibungen. Bei einem internen Stundensatz von 50 € kostet das 25 €. Die KI-Lösung ist in diesem Szenario teurer – bei höherem Aufwand für Entwicklung, Wartung und Fehlerkorrektur.
Das unterschätzte technische Problem: heterogene Quellen
Was KI-Berater ohne tiefgehende Entwicklungserfahrung systematisch unterschätzen: Gemeindewebseiten sind technologisch extrem heterogen.
Es gibt keine Norm, kein einheitliches Format, keinen Standard. Manche Gemeinden nutzen IRIS oder ein Ratsinformationssystem, andere pflegen eine handgemachte HTML-Seite aus dem Jahr 2011, wieder andere verlinken auf Drittplattformen oder publizieren gescannte PDFs ohne Metadaten. Für die KI bedeutet das: Sie kann nicht auf Strukturen schlussfolgern – sie muss bei jeder Seite von Null interpretieren. Das erhöht den Tokenverbrauch pro Seite signifikant und senkt gleichzeitig die Verlässlichkeit der Ausgabe.
Nicht alles, was technisch funktioniert, ergibt kommerziell Sinn. Die entscheidende Frage lautet nicht „Ist es möglich?" – sondern „Rechtfertigt der Nutzen die laufenden Kosten?"
Wann klassische API-Systeme die überlegene Wahl sind
Im beschriebenen Szenario ist die optimale Lösung keine generative KI als primäre Datenbeschaffungsschicht. Sie ist eine strukturierte Integration vorhandener Fachplattformen – und KI dann gezielt als Nachverarbeitungsschicht.
Für öffentliche Ausschreibungen existieren etablierte, maschinenlesbare Datenquellen: TED (Tenders Electronic Daily) auf EU-Ebene, DTVP, Vergabe24, evergabe.de und andere Plattformen mit REST-APIs, strukturierten XML-Feeds und klar definierten Datenmodellen. Diese sind günstig, zuverlässig und bereits gefiltert.
| Architektur-Ansatz | Datenqualität | Monatliche Kosten | Trefferrelevanz | Empfehlung |
|---|---|---|---|---|
| KI crawlt alle Gemeindeseiten direkt | Variabel, hohe Fehlerrate | 576–1.152 € | Sehr niedrig | Nicht empfohlen |
| Vergabeplattform-API (TED, DTVP, etc.) | Strukturiert, standardisiert | 50–200 € | Hoch | ✓ Empfohlen |
| KI-Nachklassifizierung auf API-Treffer | Präzise (vorselektierter Input) | 5–30 € | Sehr hoch | ✓ Empfohlen |
| Hybrides System: API + KI-Filter | Optimal | 55–230 € | Sehr hoch | ✓ Best Practice |
Best-Practice-Architektur: Strukturierte Datenquellen via API erschließen → KI nur für Nachklassifizierung und Relevanzbewertung einsetzen. Ergebnis: 95 % geringere Token-Kosten bei höherer Ergebnisqualität. Das ist softwaretechnisch sauberes Denken – nicht KI-Euphorie.
KI oder klassisches System? Die technische Abwägung
Als Leitfaden – nicht als Dogma, aber als strukturierter Denkrahmen für Projekte, die wir evaluieren:
- Keine strukturierte Datenquelle existiert
- Inhalte interpretiert, nicht nur abgerufen werden müssen
- Datenmenge pro Vorgang gering, Variantenbreite hoch
- Token-Kosten deutlich unter Nutzen-Wert pro Ergebnis
- Menschliche Arbeitszeit ersetzt wird, die teurer ist
- Fehlerquote tolerierbar und kontrollierbar ist
- ROI klar messbar definiert werden kann
- Eine API oder Datenbank dieselbe Info strukturiert liefert
- Datenvolumen pro Lauf im Millionen-Token-Bereich liegt
- Trefferquote unter ~2 % liegt (Nadel im Heuhaufen)
- Kosten / relevantem Ergebnis den manuellen Aufwand übersteigen
- Fehler geschäftskritisch und schwer erkennbar sind
- Das Problem auch mit Regel-/Filterlogik lösbar wäre
- Kein klar messbarer ROI definierbar ist
Was seriöse KI-Beratung leisten muss
Ich sage nicht, dass alle KI-Berater schlecht sind. Aber ich sage, dass ein Berater, der keine saubere Betriebskostenrechnung macht, kein vollständiges Bild liefert. Vor jeder Entscheidung für eine KI-Lösung sollten folgende fünf Fragen verbindlich beantwortet sein:
-
Was ist der messbare Nutzen pro Ergebnis-Einheit, in Euro?
Nicht in „Stunden gespart" oder „mehr Effizienz" – sondern als konkreter Betrag, der gegen die laufenden Kosten gestellt werden kann.
-
Wie hoch sind die monatlichen Token- und Infrastrukturkosten realistisch?
Nicht geschätzt, sondern anhand eines echten Piloten mit echten Produktionsdaten ermittelt. Demo-Bedingungen lügen.
-
Gibt es eine strukturiertere, günstigere Alternative?
APIs, Datenbankabfragen, regelbasierte Systeme, bestehende Fachplattformen. Diese Frage muss gestellt und beantwortet sein, bevor KI evaluiert wird.
-
Wie wird die Ausgabequalität der KI gemessen und kontrolliert?
Eine KI, deren Fehler nicht erkannt werden, ist gefährlicher als gar kein System. Qualitätssicherung muss von Anfang an eingebaut, nicht nachträglich ergänzt werden.
-
Wo liegt der Break-even, und was passiert, wenn er nicht erreicht wird?
Jedes KI-Projekt braucht definierte Erfolgskennzahlen und einen Ausstiegspunkt. Ohne Messung ist kein Lernen möglich.
Wer diese fünf Fragen einem KI-Berater stellt und keine klaren, zahlenbasierten Antworten bekommt, hat seinen wichtigsten Hinweis bereits erhalten. Gute Technologieberatung beginnt mit Ehrlichkeit über Grenzen – auch über die der eigenen Empfehlung.
KI-Projekt in Planung?
Wir analysieren mit Ihnen, ob und wo KI in Ihrem konkreten Vorhaben wirtschaftlich sinnvoll ist – mit echter Architektur- und Kostenbetrachtung.
Kostenloses Analysegespräch buchen →// 30 min · kostenlos · kein Pitch · konkretes Ergebnis
