Jedes zweite Startup-Deck, das ich lese, hat „KI-gestützt" in der Überschrift. Die meisten meinen damit: Die Nutzereingabe wird an die OpenAI API geschickt und die Antwort angezeigt. Das ist keine Produktstrategie. Das ist ein API-Call.
Das ist keine Kritik am Einsatz von LLMs. Ich nutze sie in Produktionssystemen. Das Problem ist der reflexartige Griff danach — KI einbauen, weil es im Pitch gut klingt, nicht weil es ein echtes Problem besser löst als die Alternative.
Wo LLMs tatsächlich Mehrwert schaffen
Es gibt einige Kategorien, in denen Sprachmodelle ihren Platz verdienen.
Aufgaben, bei denen Outputvarianz akzeptabel ist. Entwürfe erstellen, zusammenfassen, klassifizieren, umformatieren — alles, wo „meistens gut genug" die echte Anforderung ist. Wer einen ersten Entwurf einer Demand-Strategie generiert oder ein Meeting-Protokoll zusammenfasst, erleidet durch ein ungenaues Wort oder eine leicht verschobene Aussage keinen Produktionsvorfall. Varianz ist hier tolerierbar.
Aufgaben, die vorher unmöglich oder unverhältnismäßig teuer waren. Vor LLMs bedeutete strukturierte Absichtsextraktion aus einem Freitext entweder eine aufwändige NLP-Pipeline oder einen Menschen, der es liest. Heute ist es ein API-Call an gpt-5.4-nano für $0,20 pro Million Input-Tokens — oder Claude Haiku, wenn man lieber auf Anthropics Stack setzt. Das ist ein echter Fortschritt.
Bestehende Workflows augmentieren — nicht ersetzen. Ein Entwickler, der Copilot für Boilerplate-Autovervollständigung nutzt, wird schneller. Derselbe Entwickler, der ein LLM autonom Produktionscode pushen lässt, ohne Review — der bekommt einen 2-Uhr-nachts-Vorfall.
Wo sie nicht funktionieren
Kerngeschäftslogik. Wenn der Output eines KI-Schritts bestimmt, ob Geld fließt, wer Zugang erhält oder welche Daten geschrieben werden — braucht man Determinismus. LLMs sind nicht deterministisch. „Meistens korrekt" ist nicht korrekt, wenn der Fehlerfall eine Finanztransaktion ist.
Überall, wo der Output zu 100 % richtig sein muss. Medikamentendosierungen. Rechtstexte. Steuerberechnungen. LLMs können Menschen in diesen Bereichen unterstützen. Sie können den Menschen in der Entscheidungskette nicht ersetzen.
Alles mit Latenzanforderungen unter 100 ms. Selbst gpt-5.4-nano mit Streaming braucht an guten Tagen 300–800 ms bis zur ersten Antwort. Wer Echtzeit-Autovervollständigung, ein Such-Ranking-Layer oder einen Validierungsschritt in einer engen Schleife baut — LLMs passen da nicht. Regelengine oder ein kleines, aufgabenspezifisch trainiertes Modell.
Ein echtes Beispiel: FirstDemand
FirstDemand nimmt eine Landing-Page-URL und generiert eine Demand-Strategie — Zielgruppe, Positionierungswinkel, Akquisitionskanäle, Messaging-Lücken. Eine strukturierte LLM-Pipeline erledigt das in etwa 20 Sekunden.
Was würde das ohne KI kosten? Ein Strategieberater mit €150/h würde für dieselbe Recherche und Ausarbeitung drei Stunden benötigen. Das sind €450 pro Output — bei wochenlanger Vorlaufzeit.
Warum funktioniert KI hier? Zwei Gründe. Erstens ist der Output strategische Orientierung, kein Rechtsgutachten. Wenn das Modell eine Kanalempfehlung leicht falsch einschätzt, denkt der Gründer mit und passt an. Die Varianz ist kein Problem. Zweitens war die Aufgabe vorher hinter teurem menschlichem Arbeitsaufwand vergraben — genau die Kategorie, in der LLMs echten Wert freischalten.
Ein Gegenbeispiel: InferCheck
InferCheck ist ein Verzeichnis von über 350 KI-Modellen bei 111+ Anbietern, jeweils mit DSGVO-Compliance-Daten. Genutzt wird es, um zu bewerten, ob ein bestimmter KI-Anbieter in der EU legal eingesetzt werden kann.
Der naheliegende Ansatz: Ein LLM beantwortet Compliance-Fragen im Gesprächsstil. „Ist gpt-5.4 DSGVO-konform für Gesundheitsdaten?"
Das haben wir nicht gebaut. Die KI macht hier nicht die Arbeit. Die strukturierten, kuratierten, manuell verifizierten Daten machen sie. Ein LLM, das DSGVO-Fragen zu KI-Anbietern beantwortet, ist exakt der Fall „Output muss zu 100 % korrekt sein". Jemand könnte eine falsche Compliance-Entscheidung treffen, basierend auf einer halluzinierten Antwort. InferCheck ist deshalb eine Datenbank mit Suche, Filtern und quellenbasierten Einträgen — kein Chatbot.
Nicht überdrehen. Manchmal ist ein gut strukturierter Postgres-Table das richtige Werkzeug.
Das „LLM als Regex"-Muster
Vieles, was Entwickler als „KI-Feature" bezeichnen, sind im Grunde Textextraktionsaufgaben. Ein Nutzer schickt ein Support-Ticket. Gesucht werden: Kategorie, Dringlichkeit, betroffenes Produkt, ob eine Abrechnungsfrage enthalten ist.
Dafür braucht man kein 70-Milliarden-Parameter-Modell. Man braucht einen Prompt mit JSON-Schema und gpt-5.4-nano für $0,20 pro Million Input-Tokens — oder claude-haiku-4-5, wenn man ohnehin auf Anthropics API setzt. Das ist das „LLM als Regex"-Muster — ein Sprachmodell dort einsetzen, wo man früher ein sprödes Regelwerk oder einen eigenen NLP-Classifier gebraucht hätte. Günstig, schnell und gut genug.
Wer erkennt, wann man in diesem Bereich arbeitet — und nicht nach einem leistungsfähigeren Modell greift als nötig — hält die Inferenzkosten nahe null.
Eine Checkliste vor dem KI-Einbau
Bevor ein LLM-Call in den Code kommt, drei Fragen beantworten:
- Würde ein Regex, eine Lookup-Tabelle oder eine Regel funktionieren? Wenn ja, das nutzen. Simpler ist schneller, günstiger und debuggbar.
- Ist Outputqualitätsvarianz hier ein Problem? Wenn eine falsche Antwort echte Konsequenzen hat — finanziell, rechtlich, medizinisch, sicherheitsrelevant — LLM weglassen oder eine verpflichtende menschliche Prüfung einbauen.
- Werden Echtzeitergebnisse benötigt (unter 100 ms)? Wenn ja, kein LLM.
Wenn alle drei Fragen mit Nein beantwortet wurden, passt ein LLM wahrscheinlich. Weitermachen.
Die echten Kosten sind nicht die API-Rechnung
Die API-Rechnung ist kalkulierbar. gpt-5.4-nano für $0,20 pro Million Tokens bei Extraktionsaufgaben kostet im Startup-Maßstab fast nichts.
Die echten Kosten sind Debugging-Zeit. Um 2 Uhr nachts, wenn die LLM-Pipeline einen missgeformten JSON-Blob zurückgibt, weil das Modell entschieden hat, vor der schließenden Klammer noch eine „hilfreiche" Anmerkung einzufügen. JSON.parse() wirft einen Fehler. Der Stack Trace zeigt auf einen dynamisch zusammengesetzten String, sechs Abstraktionsschichten tief — da zahlt man den Preis.
LLMs scheitern auf Weisen, die schwer vorherzusehen und nervig zu reproduzieren sind. Sie sind inkonsistent über Modellversionen hinweg. Ein Prompt, der auf gpt-5.4 einwandfrei funktioniert, kann sich nach einem Modell-Update anders verhalten — OpenAI und Anthropic nehmen beide stille Capability-Änderungen vor. Output-Validierung, Fallback-Handling und strukturierte Outputs (JSON-Modus oder Function Calling) gehören von Anfang an dazu — nicht als Nachgedanke, wenn es kracht.
KI einsetzen, wo sie echte neue Möglichkeiten schafft. Weglassen, wo ein einfacheres Werkzeug denselben Job erledigt. Das Ziel ist ein funktionierendes Produkt, kein Pitch-Deck mit höherer KI-Erwähnungsquote.