# KI-Schulden: Was kaputtgeht, nachdem die Demo funktioniert Source: https://normanholz.de/articles/ai-tech-debt-hidden-cost-llms/ Language: de Last updated: 2025-08-26 Reading time: 5 Minuten Lesezeit LLM-Funktionen sind schnell gebaut und schwer zu betreiben. Fünf Arten von KI-Schulden, die entstehen, wenn Teams KI als Funktion behandeln und nicht als System. Gerade baut jedes Startup KI-Funktionen. Viele bauen dabei eine zweite Art technischer Schulden auf. Das wirkt am Anfang nicht gefährlich, weil die Demo funktioniert. Der Prompt liefert etwas Brauchbares. Die RAG-Pipeline findet das richtige Dokument. Der Kunde sagt: schön, das fühlt sich wie Magie an. Sechs Monate später will niemand mehr anfassen, was da entstanden ist. Klassische technische Schulden sind sichtbar: unordentlicher Code, fehlende Tests, Dienste, die man schon vor Jahren hätte trennen sollen. KI-Schulden sind anders. Sie stecken in Prompts, Modellen, Daten, Auswertung, Produktverhalten und Vertrauen im Team. Das räumt man nicht mit einem motivierten Wochenende und viel Kaffee aus der Welt. So sieht das in der Praxis aus. ## 1. Prompt-Schulden Das Verhalten deines Produkts steckt in einem Prompt mit 2.000 Tokens. Niemand hat ihn sauber versioniert. Niemand hat ihn getestet. Niemand versteht ihn komplett. Ein Entwickler hat letzten Oktober einen Satz ergänzt, weil er einen Sonderfall gelöst hat. Jetzt trägt dieser Satz das System, und niemand weiß warum. So werden Prompts zu Folklore. Änderungen fühlen sich harmlos an, weil es ja nur Text ist. Also ergänzen Leute Anweisungen, Ausnahmen, Beispiele, Gegenbeispiele und einen seltsamen Satz, der dem vorherigen widerspricht, weil er im Staging geholfen hat. Das System funktioniert weiter. Bis es das nicht mehr tut. **Lösung:** Behandle Prompts wie Code. Versioniere sie. Lass sie überprüfen. Teste sie. Führe ein Changelog. Schreib auf, warum sich ein Prompt geändert hat, nicht nur was sich geändert hat. Und bitte lass kein Produktionsverhalten von einem Prompt abhängen, den nur eine Person versteht. ## 2. Modell-Schulden Die erste Version lief auf GPT-4. Dann war Claude günstiger. Dann hatte Gemini das bessere Kontextfenster. Dann hat ein Team aus Datenschutzgründen ein lokales Modell ergänzt. Jetzt laufen Wiederholungen über drei Anbieter, Kosten lassen sich schwer zuordnen, und niemand weiß genau, was passiert, wenn ein Modell sein Verhalten ändert. Das ist keine Anbieterflexibilität. Das ist Abhängigkeitswildwuchs. Die Modellwahl beeinflusst Latenz, Kosten, Ausgabestil, Fehlerarten, Messergebnisse und Produktverhalten. Ein Modellwechsel ist nicht wie der Wechsel eines Datenbanktreibers. Derselbe Prompt kann sich anders verhalten. Dieselbe Nutzereingabe kann anders scheitern. Sicherheitslogik kann zu streng oder zu locker werden. **Lösung:** Lege eine dünne Abstraktion zwischen dein Produkt und den Modellanbieter. Keine Fantasie-Abstraktion nach dem Motto "wir können jederzeit jedes Modell tauschen". Eine langweilige, praktische. Erfasse Modellnutzung, Kosten, Latenz, Prompts und Anbieterwahl pro Funktion. Wenn du nicht beantworten kannst, was diese KI-Funktion letzte Woche gekostet hat, hast du einen Generator für Überraschungsrechnungen gebaut. ## 3. Evaluations-Schulden Du hast eine RAG-Funktion ausgeliefert. Nutzer stellen Fragen. Das System antwortet. Manchmal beschweren sich Nutzer. Jemand passt den Prompt an. Die Beschwerden hören auf. Alle machen weiter. Aber was wurde besser? Wurde die Suche besser? Wurde das Modell vorsichtiger? Hat der Prompt Unsicherheit nur besser versteckt? Hast du ein Kundenproblem gelöst und fünf stille Probleme neu erzeugt? Ohne Evaluation weißt du das nicht. Du steuerst nach Bauchgefühl. Teams liefern LLM-Funktionen aus, ohne wiederholbar messen zu können, ob das System besser oder schlechter wird. Das ist keine belastbare Entwicklungsarbeit. Das ist Aberglaube mit schönerem Werkzeug. **Lösung:** Baue einen Golden Dataset. Fang klein an. 50 bis 200 echte Beispiele reichen am Anfang. Nimm echte Nutzerfragen, echte Dokumente, langweilige Fälle, Sonderfälle und Fälle, in denen die richtige Antwort "Ich weiß es nicht" lautet. Lass diesen Datensatz bei jeder relevanten Prompt-, Modell- oder Retrieval-Änderung laufen. Du brauchst keinen perfekten Benchmark. Du brauchst eine Basislinie, die dir sagt, wann du das System schlechter gemacht hast. ## 4. Daten-Schulden Deine KI-Funktion hängt von Daten ab, die nie für KI gedacht waren. Vertriebsnotizen in Salesforce. Freitext-Tags in Airtable. Alte Wiki-Seiten. Nutzereingaben mit Tippfehlern. Produktkategorien, die Marketing jedes Quartal umbenennt. Dann verbindet jemand ein LLM damit, und chaotische Betriebsdaten werden Teil des Produkts. Ein Mensch versteht, dass "enterprise", "Enterprise Plan", "ENT" und "large customer" vielleicht dasselbe meinen. Deine Pipeline vielleicht nicht. Deine Embeddings vielleicht nicht. Deine Retrieval-Filter ganz sicher nicht immer. Jede undokumentierte Schemaänderung wird zu einer möglichen Regression. Jedes uneinheitliche Label wird Modellkontext. Jedes veraltete Dokument wird zu einer selbstbewussten falschen Antwort, die nur auf ihren Auftritt wartet. **Lösung:** Dokumentiere den Vertrag zwischen deinen KI-Funktionen und deinen Datenquellen. Welche Felder sind wichtig? Welche Labels sind stabil? Welche Dokumente dürfen in die Suche? Welche Systeme sind die Quelle der Wahrheit? Was passiert, wenn sich ein Feld ändert? Behandle Datenänderungen als Produktänderungen, wenn KI davon abhängt. Denn genau das sind sie. ## 5. Vertrauens-Schulden Das unterschätzen viele. Jedes Mal, wenn dein LLM vor einem Kunden halluziniert, sinkt Vertrauen. Nicht nur beim Kunden. Auch im Team. Entwickler beginnen, dem System zu misstrauen. Product meidet ambitionierte Anwendungsfälle. Support schreibt manuelle Umwege. Die Geschäftsführung fordert mehr "Guardrails", ohne genau zu wissen, was das heißt. Dann bekommt das System Validierungsschichten, Fallback-Logik, manuelle Freigaben und hart codierte Ausnahmen. Einiges davon ist nötig. Zu viel davon tötet genau das, was die Funktion nützlich gemacht hat. Das Team verbessert das KI-System nicht mehr. Es verteidigt sich dagegen. **Lösung:** Entscheide früh, was die KI verantwortet und wobei sie nur hilft. Es gibt einen großen Unterschied zwischen: - KI schlägt eine Antwort vor - KI sendet die Antwort - KI klassifiziert ein Support-Ticket - KI schließt das Support-Ticket - KI fasst einen Vertrag zusammen - KI entscheidet, ob der Vertrag akzeptabel ist Das sind unterschiedliche Risikoprofile. Sie brauchen unterschiedliches Produktdesign, andere Evaluation und andere Fallbacks. Liefere nie eine KI-Funktion ohne Fallback ohne KI aus. Produktionssysteme fallen aus, und dieses System fällt auf Arten aus, die korrekt aussehen können. ## Warum diese Schulden schlimmer sind als normale technische Schulden Normale technische Schulden wachsen in deinem System. Technische KI-Schulden wachsen in deinem System und außerhalb davon. Das Modell ändert sich. Der Anbieter ändert Preise. Die API hat einen Ausfall. Derselbe Prompt verhält sich nach einem Modellupdate anders. Deine Daten ändern ihre Form. Deine Nutzer finden Eingaben, die du nie getestet hast. Dein Evaluationsdatensatz veraltet. Du kannst die Version nicht einfrieren und dich sicher fühlen. Der Boden bewegt sich unter dir. "Wir haben KI eingebaut" ist keine Strategie. Es ist kaum eine Funktionsbeschreibung. Die Startups, die damit gut umgehen, haben nicht die cleversten Prompts. Sie haben technische Führung, die KI als System behandelt. Prompts, Modelle, Daten, Evaluation und Vertrauen gehören alle zu diesem System. Ignoriere einen Teil lange genug, und er taucht später auf deiner Roadmap wieder auf. Meist zum schlechtesten Zeitpunkt. Wenn dein Team KI-Funktionen ohne diese Leitplanken ausliefert, ist [ein Fractional-CTO-Mandat](/) meist günstiger, als später aufzuräumen. Frag mich, woher ich das weiß.