KI im Dauerbetrieb
Fünf Lehren aus Projekten, in denen Sprachmodelle nicht vorgeführt, sondern täglich benutzt werden — und in denen wir die Ergebnisse hinterher selbst verantworten müssen.
Eine Vorführung mit einem Sprachmodell gelingt fast immer. Ein Dauerbetrieb gelingt selten von allein. Eine viel zitierte Untersuchung des MIT kam 2025 zu dem Ergebnis, dass rund 95 Prozent der KI-Pilotprojekte in Unternehmen keinen messbaren Ertrag liefern; Gartner erwartet, dass mehr als 40 Prozent der Projekte mit KI-Agenten bis Ende 2027 wieder eingestellt werden. Beide Zahlen werden gern als Zweifel am Modell gelesen. Nach unserer Erfahrung sind sie eher ein Befund über das Drumherum.
Wir setzen Sprachmodelle in eigenen Portalen ein: zum Anreichern von Datensätzen, zum Übersetzen, zum Prüfen von Bildern, zum Entwerfen von Texten. Diese Systeme laufen nicht in einer Demo, sondern seit Monaten im Takt. Was dabei trägt und was nicht, folgt weniger aus der Wahl des Modells als aus fünf sehr unspektakulären Entscheidungen.
Der Chat ist nicht der Betrieb
Solange ein Mensch danebensitzt, ist ein Sprachmodell ein Gesprächspartner. Sobald es tausende Datensätze bearbeiten soll, ist es ein Auftragnehmer in einer Warteschlange — und braucht dieselbe Mechanik wie jeder andere Hintergrundprozess: Aufgaben werden einzeln zugeteilt, während der Bearbeitung gesperrt und mit Ergebnis oder Fehler zurückgemeldet.
Das klingt selbstverständlich, ist es im Alltag aber nicht. Wir haben es zweimal falsch gebaut, bevor es hielt. Der lehrreichste Fall: Ein Lauf brach mitten in der Bearbeitung ab. Die Aufgabe blieb auf „in Arbeit“ stehen — und weil eine Parallelsperre verhindert, dass zwei Läufe dasselbe tun, stand danach die gesamte Schlange still. Nicht eine Aufgabe war blockiert, sondern alle.
Was daraus folgt: Jede Zuteilung braucht ein Verfallsdatum. Bei uns fallen Aufgaben, die länger als vier Stunden in Bearbeitung sind, automatisch zurück in die Warteschlange. Ein abgebrochener Lauf kostet dann Zeit, aber nicht den Betrieb.
Praktischer Hinweis: Wer KI-Arbeit automatisiert, baut kein KI-System, sondern ein Auftragssystem, in dem zufällig ein Modell arbeitet. Die schwierigen Fragen sind entsprechend die alten: Wiederholbarkeit, Sperren, Zeitüberschreitung, Nachvollziehbarkeit.
Belegpflicht schlägt Formulierungskunst
Der verbreitetste Versuch, erfundene Angaben zu verhindern, ist die Anweisung, nichts zu erfinden. Sie wirkt — ungefähr so zuverlässig wie ein Schild an einer offenen Tür. In einem Portal mit mehreren tausend Anbietereinträgen haben wir deshalb umgestellt: Eine Angabe wird nur übernommen, wenn zwei voneinander unabhängige Quellen sie tragen, und beide Quellen werden zum Datensatz gespeichert.
Der Unterschied ist strukturell, nicht sprachlich. Vorher war die Frage: Wie formuliere ich die Anweisung so, dass das Modell vorsichtig wird? Nachher: Was passiert mit einer Angabe, die keinen Beleg hat? Antwort: Sie fällt raus. Das Modell darf weiter irren — der Irrtum erreicht nur die Datenbank nicht mehr.
Der Preis dafür ist Ausbeute. Ein spürbarer Teil der Datensätze bleibt unvollständig, weil sich nichts belegen ließ. Das ist unbequem und richtig so: Eine Lücke ist reparierbar, eine plausible Falschangabe im Bestand nicht, weil niemand mehr weiß, welche der Angaben man nachprüfen müsste.
Was wir geändert haben: Belege werden mitgespeichert, nicht nur geprüft. Sonst lässt sich Monate später nicht mehr feststellen, worauf eine Angabe beruhte — und man prüft am Ende alles noch einmal von Hand.
Eine zweite Instanz, mit anderer Aufgabe
In einem Rezeptportal waren rund 800 Bilder automatisch zugeordnet worden — jedes formal korrekt, jedes mit passender Lizenz. Eine anschließende Prüfung, bei der ein bildverstehendes Modell nur eine einzige Frage beantworten sollte („zeigt dieses Bild das genannte Gericht?“), fand 58 Fehlzuordnungen, von denen wir 53 ersetzen konnten. Das sind gut sieben Prozent — unsichtbar für jede technische Prüfung, sofort sichtbar für jeden Besucher.
Entscheidend war nicht, dass ein zweites Modell mitlief, sondern dass es eine andere Aufgabe hatte. Dasselbe Modell noch einmal zu fragen, ob sein Ergebnis gut sei, liefert vor allem Zustimmung. Die prüfende Instanz muss eine engere, prüfbare Frage bekommen als die erzeugende — mit einer Antwort, die falsch sein kann.
Wirtschaftlich betrachtet ist das der günstigste Teil der Kette. Eine Prüffrage kostet einen Bruchteil einer Erzeugung, läuft parallel und braucht keine Aufsicht. Teuer wird nur, was sie findet — und genau das ist der Zweck.
Grenze der Methode: Die Prüfung findet grobe Fehlzuordnungen, keine feinen. Ob ein Bild das Gericht gut zeigt, bleibt eine menschliche Frage. Wir behandeln sie als Stichprobe, nicht als Vollprüfung.
Der teuerste Fehler ist der plausible
Ein mehrsprachiges Portal führt jedes Feld in vier Sprachen. Eine Prüfung des Bestands ergab 253 Einträge, deren englisches Feld deutschen Text enthielt. Formal war alles in Ordnung: Feld gefüllt, Länge plausibel, keine Fehlermeldung. Inhaltlich war die Übersetzung schlicht nicht passiert — das Modell hatte den Ausgangstext durchgereicht.
Dieselbe Klasse von Fehler in anderer Gestalt: In einem Portal mit Veranstaltungsdaten sollten Modelle einschätzen, wer bei einer künftigen Ausgabe auftreten könnte. Die Ergebnisse lasen sich überzeugend — und wiederholten auffällig oft die Besetzung des Vorjahres. Nicht falsch im Einzelfall, aber als Muster wertlos, weil es genau die Information nicht enthält, für die es gebaut wurde.
Beide Fälle haben gemeinsam, dass keine Prüfung anschlägt, die auf Vorhandensein achtet. Wer nur zählt, wie viele Felder gefüllt sind, misst die Arbeit — nicht das Ergebnis. Brauchbare Prüfungen fragen nach Eigenschaften: Unterscheidet sich das Übersetzungsfeld vom Ausgangsfeld? Unterscheidet sich die Prognose vom Vorjahr?
Was wir geändert haben: Zu jeder automatisch erzeugten Angabe gehört eine Prüfung, die ihren typischen Ausfall beschreibt — nicht ihre Existenz. Diese Prüfungen entstehen erfahrungsgemäß erst nach dem ersten Schaden. Man kann sie aber aus fremdem Schaden vorwegnehmen, und dazu ist dieser Text da.
Menge ist kein Ergebnis
Die verlockendste Eigenschaft dieser Werkzeuge ist ihr Durchsatz. Genau daraus entsteht der teuerste Fehler, den wir uns selbst geleistet haben: tausende automatisch erzeugte Seiten, jede für sich vertretbar, in der Summe eine Belastung für die gesamte Domain. Die Folgen und die Korrektur haben wir an anderer Stelle ausführlich beschrieben.
Die Lehre daraus lässt sich auf jede Anwendung übertragen, nicht nur auf Texte für Suchmaschinen: Ein Sprachmodell senkt die Kosten des Erzeugens, nicht die Kosten des Bestands. Alles, was erzeugt wird, muss danach gepflegt, geprüft, aktualisiert und irgendwann abgeräumt werden — und diese Kosten fallen weiterhin bei Menschen an.
Deshalb ist die nützlichste Frage vor jedem Einsatz nicht „wie viel schaffen wir damit?“, sondern: Was davon wollen wir in zwei Jahren noch verantworten? Bei Anreicherungen mit klarem Zweck — fehlende Nährwerte, fehlende Übersetzungen, fehlende Belege — lautet die Antwort meist ja. Bei Massentexten, die nur existieren, weil Daten dafür vorliegen, fast nie.
Der Gegenbeweis in eigener Sache: Im selben Rezeptportal hat eine eng umrissene Anreicherung die Nährwertabdeckung von 28 auf über 97 Prozent gebracht. Gleiche Technik, gleicher Durchsatz — nur mit einer Frage dahinter, die Besucher tatsächlich stellen.
Was daraus für Projekte folgt
Auffällig ist, wie wenig dieser Lehren mit dem Modell zu tun hat. Keiner der beschriebenen Fehler wäre durch ein besseres Modell verhindert worden, und keiner durch eine geschicktere Anweisung. Verhindert hätten sie: eine Zeitüberschreitung, eine Belegpflicht, eine zweite prüfende Frage, eine Kennzahl, die den typischen Ausfall misst, und eine Entscheidung darüber, was gar nicht erst erzeugt werden soll.
Das deckt sich mit dem, was die eingangs genannten Studien als Ursache benennen: Nicht die Modellgüte ist der Engpass, sondern die Einbettung in einen Ablauf, der Fehler bemerkt und überlebt. Wer KI einführt, führt in erster Linie einen Prozess ein — und in zweiter Linie ein Modell hinein.
Wir arbeiten deshalb umgekehrt zur üblichen Reihenfolge: erst die Frage, welcher Arbeitsschritt sich wiederholt und wie man sein Ergebnis prüft — dann die Frage, ob ein Modell diesen Schritt übernehmen kann. Projekte, bei denen die zweite Frage zuerst kommt, enden erfahrungsgemäß in der Gruppe der 95 Prozent.
KI-Einsatz, der auch nach einem Jahr noch trägt?
Wir integrieren Sprachmodelle in Webanwendungen mit Django, Nuxt und Qwik — und betreiben die Ergebnisse danach selbst weiter. Beides zusammen, weil man das eine ohne das andere schlecht beurteilen kann.
Gespräch anfragen