KI in Produktionssystemen — Engineering statt Demo

Es gibt kaum ein Feld, in dem der Abstand zwischen dem ersten Eindruck und dem verlässlichen Betrieb so groß ist wie bei KI. Eine Demo entsteht in Stunden und beeindruckt sofort; ein System, das dieselbe Fähigkeit zuverlässig, bezahlbar und ohne stille Fehler in Produktion erbringt, ist eine der anspruchsvolleren Ingenieuraufgaben. Der Markt zeigt Demos; über das, was danach kommt, wird selten ehrlich gesprochen.

Dieses Dokument handelt von dem, was danach kommt. Es behandelt KI nicht als Zauber und nicht als Bedrohung, sondern als eine besondere Art von Komponente — eine, die wahrscheinliche statt sicherer Antworten gibt — und fragt, wie man ein System um sie herum baut, das man verantworten kann. Es ist bewusst modell-, anbieter- und hype-neutral gehalten; es nennt kein Produkt, weil die Prinzipien von keinem abhängen.

1. Die Kluft zwischen Demo und Produktion

Eine Demo hat eine einzige Aufgabe: zu zeigen, dass etwas im besten Fall geht. Sie wird an ausgewählten Beispielen vorgeführt, unter freundlichen Bedingungen, ohne Last, ohne Grenzfälle, ohne die Frage, was passiert, wenn die Antwort falsch ist. Ein Produktivsystem hat die entgegengesetzte Aufgabe: zuverlässig zu sein, gerade im schlechten Fall, unter echter Last, mit echten Nutzern, deren Eingaben niemand vorhergesehen hat.

Schema: Die Demo ist die Spitze über der Wasserlinie. Alles, was ein KI-System verlässlich macht, liegt darunter — unsichtbar im ersten Eindruck.

Die Kluft zwischen beiden ist bei KI besonders tief, weil die Demo so leicht gelingt und so wenig über das Produktivsystem aussagt. Ein Modell, das in zehn vorgeführten Fällen überzeugt, kann im elften still etwas Falsches behaupten — und dieser elfte Fall ist der, der in Produktion zählt. Wer den Erfolg der Demo für den Beweis der Produktionsreife hält, verwechselt den besten Fall mit dem Normalfall. Die eigentliche Arbeit beginnt genau dort, wo die Demo endet.

Trade-off. Die Demo ernst zu nehmen als das, was sie ist — ein Anfang, kein Beweis —, dämpft die Begeisterung, die sie auslöst, und verlangt, den weiten Weg dahinter zu benennen.

Kosten. Der Abstand zwischen Demo und Produktion ist Arbeit, die im ersten Eindruck unsichtbar ist und deshalb im Budget gern vergessen wird.

Wann wir anders entscheiden. Wo eine KI-Fähigkeit wirklich nur vorgeführt werden soll — ein Experiment, ein Lernversuch —, genügt die Demo, und der Aufwand der Produktionsreife wäre fehl am Platz.

2. Warum KI-Systeme anders sind

Herkömmliche Software ist deterministisch: Dieselbe Eingabe führt zur selben Ausgabe, und wenn nicht, ist das ein Fehler, den man findet und behebt. Ein KI-Modell ist wahrscheinlich: Es gibt die plausibelste Antwort, nicht die sichere, und dieselbe Frage kann verschiedene Antworten hervorbringen. Das ist kein Fehler, sondern die Natur der Sache — und es verändert alles, was man über den Umgang mit der Komponente weiß.

Aus dieser einen Eigenschaft folgt der Rest. Man kann ein wahrscheinliches System nicht testen wie ein deterministisches, weil es keine feste richtige Ausgabe gibt, gegen die man prüft. Man kann sich nicht darauf verlassen, dass es zweimal dasselbe tut. Man muss damit rechnen, dass es überzeugend falsch liegt — nicht mit einer Fehlermeldung, sondern mit einer flüssigen, plausiblen, falschen Antwort. Wer ein KI-System wie gewöhnliche Software behandelt, wendet Werkzeuge an, die für Sicherheit gebaut sind, auf etwas, das Wahrscheinlichkeit liefert — und wundert sich, dass sie nicht greifen.

Trade-off. Die Wahrscheinlichkeit anzunehmen bedeutet, auf die Bequemlichkeit des Deterministischen zu verzichten — man tauscht Fähigkeit gegen Sicherheit und muss die Sicherheit anderswo herstellen.

Kosten. Der Umgang mit einem wahrscheinlichen System verlangt Methoden, die viele Teams erst lernen müssen — Evaluation, Absicherung, Beobachtung des Unerwarteten.

Wann wir anders entscheiden. Wo eine Aufgabe sicher und regelbasiert lösbar ist, nimmt man kein wahrscheinliches System — deterministische Software ist dort einfacher, billiger und verlässlicher (siehe auch die Frage, wann KI die falsche Lösung ist).

3. Evaluation statt Eindruck

Weil ein KI-System keine feste richtige Ausgabe hat, kann man seine Güte nicht am Einzelfall beurteilen — schon gar nicht am vorgeführten. Man braucht Evaluation: eine Menge von Fällen mit bekannten, gewünschten Ergebnissen, gegen die man das System systematisch misst, und ein Maß dafür, wie oft und wie stark es abweicht. Ohne diese Messung ist jede Aussage über die Qualität eines KI-Systems ein Gefühl, kein Wissen.

Evaluation ist bei KI, was das Testen bei gewöhnlicher Software ist — nur schwerer, weil die richtige Antwort selten eindeutig ist. Sie ist deshalb keine einmalige Abnahme, sondern eine dauerhafte Einrichtung: Man misst vor jeder Änderung am System, ob es besser oder schlechter geworden ist, denn bei einem wahrscheinlichen System kann eine gut gemeinte Anpassung an einer Stelle etwas an einer anderen verschlechtern, ohne dass es auffällt. Wer ohne Evaluation an einem KI-System schraubt, arbeitet blind — er ändert und hofft, statt zu ändern und zu wissen.

Trade-off. Evaluation aufzubauen kostet Zeit und Sorgfalt, bevor das System überhaupt Wert liefert — sie fühlt sich wie Umweg an, ist aber die Grundlage jeder verlässlichen Aussage.

Kosten. Eine Evaluationsmenge muss gepflegt werden, mit den Fällen wachsen und die Grenzfälle abdecken, an denen das System scheitert — das ist dauerhafte Arbeit, kein einmaliger Aufwand.

Wann wir anders entscheiden. Für einen Wegwerf-Versuch, dessen Fehler folgenlos sind, spart man sich die volle Evaluation; sobald das System aber Entscheidungen beeinflusst, die zählen, ist sie unverzichtbar.

4. Fehlermodi von KI-Systemen

Ein KI-System scheitert anders als gewöhnliche Software, und seine Fehlermodi sind gerade deshalb gefährlich, weil sie nicht wie Fehler aussehen. Der bekannteste ist die überzeugende Falschaussage: Das Modell behauptet etwas Plausibles, das nicht stimmt, in flüssiger, selbstsicherer Form — ohne jede Warnung, dass es rät. Ein solcher Fehler bricht nichts ab; er fließt in die Antwort ein und wird geglaubt, weil er sich nicht von einer richtigen Antwort unterscheidet.

Dazu kommen stillere Formen. Das Verhalten kann mit der Zeit abdriften, wenn sich die Eingaben oder das Modell verschieben, sodass ein System, das gestern gut war, heute schlechter ist, ohne dass jemand etwas geändert hat. Es kann bei seltenen, aber wichtigen Eingaben versagen, die in keiner Demo vorkamen. Und es kann durch geschickt geformte Eingaben aus seiner vorgesehenen Rolle gebracht werden. Diese Fehlermodi haben eines gemeinsam: Sie melden sich nicht selbst. Man findet sie nur, wenn man aktiv nach ihnen sucht — durch Evaluation, durch Beobachtung, durch das bewusste Design für den Fall, dass die Antwort falsch ist.

Trade-off. Für die Fehlermodi zu entwerfen bedeutet, dem System zu misstrauen, das man gerade einsetzt — diese Nüchternheit dämpft die Begeisterung, ist aber die Voraussetzung für Verlässlichkeit.

Kosten. Jedes Gegenmittel — Prüfung, Beobachtung, Kontrolle — ist zusätzliche Arbeit und zusätzliche Teile im System, die selbst gepflegt werden müssen.

Wann wir anders entscheiden. Wo eine falsche Antwort folgenlos ist — ein Vorschlag, den ohnehin ein Mensch prüft, ein unkritischer Zusatz —, darf man die aufwändigen Gegenmittel verschlanken; die volle Absicherung gilt dort, wo die Antwort etwas auslöst.

5. Guardrails und Grenzen

Ein wahrscheinliches System braucht Grenzen, innerhalb deren es wirken darf — und außerhalb deren es nicht wirken kann. Diese Grenzen sind selbst deterministisch: feste Regeln, die prüfen, was in das Modell hineingeht und was herauskommt, und die verhindern, dass eine falsche oder unerlaubte Antwort Wirkung entfaltet. Das Modell schlägt vor; die Grenze entscheidet, ob der Vorschlag ausgeführt werden darf. So bleibt die Verantwortung bei etwas Prüfbarem, nicht bei etwas Wahrscheinlichem.

Schema: Der wahrscheinliche Kern wird von deterministischen Grenzen eingefasst. Was hineingeht und herauskommt, wird geprüft — die Verantwortung bleibt bei etwas Sicherem.

Zu den Grenzen gehört auch der Mensch, wo die Wirkung es verlangt. Nicht jede KI-Ausgabe muss ein Mensch prüfen — das würde den Nutzen zunichtemachen —, aber überall dort, wo eine falsche Antwort ernsten Schaden anrichtet, gehört eine menschliche Kontrolle in den Weg zwischen Vorschlag und Wirkung. Die Kunst ist, diese Kontrolle dort einzusetzen, wo sie zählt, und dort wegzulassen, wo der Fehler folgenlos ist — nicht überall und nicht nirgends.

Trade-off. Grenzen und Kontrolle kaufen Verlässlichkeit mit einem Teil der Geschwindigkeit und Autonomie, die KI verspricht — ein vollständig freies System ist schneller, aber unverantwortlich.

Kosten. Jede Grenze ist zusätzliche deterministische Logik, die entworfen, geprüft und gepflegt werden muss, und jede menschliche Kontrolle kostet Zeit im Ablauf.

Wann wir anders entscheiden. Wo die Ausgabe des Modells ohnehin nur ein unverbindlicher Vorschlag an einen Menschen ist, kann man auf zusätzliche Grenzen verzichten — der Mensch ist dann bereits die Grenze.

6. Daten und Kontext sind das System

Die Qualität eines KI-Systems in Produktion hängt weniger am Modell als an dem, was man ihm gibt. Ein Modell ist ein allgemeines Werkzeug; nützlich wird es erst durch den Kontext, mit dem man es füttert — die richtigen, aktuellen, verlässlichen Informationen zur richtigen Frage. Ein hervorragendes Modell mit schlechtem Kontext gibt schlechte Antworten; ein bescheidenes Modell mit gutem Kontext gibt oft überraschend gute. Deshalb liegt die eigentliche Ingenieursarbeit häufig nicht beim Modell, sondern beim Kontext: ihn zu beschaffen, aktuell zu halten, sauber und relevant an das Modell zu bringen.

Das verschiebt den Blick von der Frage „welches Modell?" zu der wichtigeren „welcher Kontext, und woher?". Ist die Informationsquelle verlässlich und aktuell? Wird der richtige Ausschnitt zur konkreten Frage ausgewählt, nicht zu viel und nicht zu wenig? Bleibt nachvollziehbar, worauf eine Antwort beruht? Diese Fragen entscheiden über die Güte in Produktion — und sie sind klassische Datentechnik, keine Magie. Wer sie ernst nimmt, hat den größten Hebel für Qualität in der Hand.

Trade-off. In den Kontext zu investieren statt in das Modell bedeutet, die weniger glänzende Arbeit zu tun — Datenpflege statt Modellwahl —, dafür aber am wirksamsten Hebel zu ziehen.

Kosten. Guten Kontext bereitzustellen und aktuell zu halten ist dauerhafte Arbeit an Datenquellen, Auswahl und Pflege — sie endet nie, weil sich die Welt ändert.

Wann wir anders entscheiden. Wo die Aufgabe kein externes Wissen braucht, sondern rein aus der Fähigkeit des Modells lebt, tritt der Kontext zurück, und die Wahl des Modells wiegt schwerer.

7. Kosten und Latenz als Architekturfrage

Anders als gewöhnliche Software, deren Betrieb pro Anfrage oft vernachlässigbar ist, hat jede KI-Anfrage einen spürbaren Preis — an Rechenzeit, an Geld, an Wartezeit für den Nutzer. Diese Kosten sind keine Nebensache, die man später optimiert, sondern eine Architekturfrage von Anfang an. Ein System, das für jede Kleinigkeit das teuerste Modell befragt, kann im Kleinen beeindrucken und im Großen unbezahlbar werden.

Der verantwortliche Umgang behandelt das Modell wie eine teure, langsame Ressource, die man sparsam einsetzt. Man fragt es nur, wo es wirklich gebraucht wird, statt überall; man hält Antworten zurück, wo dieselbe Frage wiederkehrt; man wählt für einfache Aufgaben das kleinere, billigere Mittel und für schwere das stärkere; man plant, was geschieht, wenn das Modell langsam ist oder ausfällt. Kosten und Latenz sind damit keine Betriebsdetails, sondern formen die Architektur so stark wie die Datenbank ein gewöhnliches System formt.

Trade-off. Kosten und Latenz ernst zu nehmen bedeutet, nicht überall das stärkste Modell einzusetzen — man tauscht ein wenig Fähigkeit gegen Bezahlbarkeit und Tempo.

Kosten. Die sparsame Architektur — gestufte Modelle, Zwischenspeicher, Ausweichwege — ist selbst zusätzliche Komplexität, die man baut und pflegt.

Wann wir anders entscheiden. Wo Anfragen selten und die Antwort besonders wertvoll ist, darf man das teuerste Mittel wählen; die Sparsamkeit gilt dort, wo Menge und Wiederholung die Kosten treiben.

8. Determinismus, wo es zählt

Die verbindende Idee all dieser Kapitel ist eine architektonische: Man fasst das Wahrscheinliche in Deterministisches ein. Der wahrscheinliche Teil — das Modell — wird auf den Bereich begrenzt, in dem seine Fähigkeit den einzigen Weg darstellt; alles um ihn herum, was sicher sein kann, wird sicher gebaut. Prüfungen, Grenzen, Auswahl des Kontexts, Behandlung der Ausgabe: Das alles ist gewöhnliche, deterministische Software, die man testen und verantworten kann. Das System als Ganzes wird dadurch beherrschbar, obwohl sein Kern es nicht ist.

So löst sich der scheinbare Widerspruch, ein unsicheres Werkzeug verantwortlich einzusetzen. Man macht nicht das Modell sicher — das kann man nicht —, sondern das System um es herum. Der wahrscheinliche Kern bleibt, was er ist, aber er ist eingefasst, beobachtet und begrenzt, sodass seine Unsicherheit lokal bleibt und nicht das Ganze durchdringt. Das ist dieselbe Haltung, die überall in guter Technik gilt: das Unsichere klein halten und hinter etwas Prüfbares stellen.

Trade-off. Das Wahrscheinliche einzufassen kostet die zusätzliche deterministische Struktur ringsum — man baut mehr als nur den Aufruf des Modells, um ihn verantworten zu können.

Kosten. Die Einfassung ist echte Arbeit: Prüfungen, Grenzen und Beobachtung sind eigene Bestandteile mit eigener Pflege, die den Aufwand über den bloßen Modellaufruf hinaus vervielfachen.

Wann wir anders entscheiden. Wo die Unsicherheit des Modells folgenlos bleibt, spart man sich die volle Einfassung; die Sorgfalt wächst mit dem Schaden, den eine falsche Antwort anrichten kann.

9. Typische Fehler

Die wiederkehrenden Muster, an denen KI in Produktion scheitert — fast alle sind Varianten davon, die Demo für das System zu halten:

• Den Erfolg der Demo für den Beweis der Produktionsreife nehmen und den Weg dahinter unterschätzen.
• Ein wahrscheinliches System wie deterministische Software behandeln und sich auf feste, reproduzierbare Ausgaben verlassen.
• Ohne Evaluation an einem KI-System schrauben — ändern und hoffen statt ändern und messen.
• Die stillen Fehlermodi übersehen, weil sie nicht wie Fehler aussehen, sondern wie flüssige Antworten.
• Dem Modell blind vertrauen, statt seine Ein- und Ausgaben in deterministische Grenzen zu fassen.
• Am Modell optimieren, wo der Kontext das eigentliche Problem ist — gute Datenarbeit durch Modellwahl ersetzen wollen.
• Kosten und Latenz als spätere Optimierung behandeln, bis das System im Großen unbezahlbar oder zu langsam wird.
• Menschliche Kontrolle überall oder nirgends einsetzen, statt dort, wo eine falsche Antwort wirklich schadet.

10. Entscheidungs-Checkliste

Vor und während des Baus eines KI-Produktivsystems der Reihe nach zu klären:

• Demo oder System? Ist klar, dass die beeindruckende Demo erst der Anfang ist — und der Weg zur Verlässlichkeit eingeplant?
• Wahrscheinlich verstanden? Ist allen bewusst, dass die Ausgaben variabel und mitunter überzeugend falsch sind — und ist das System darauf ausgelegt?
• Evaluation vorhanden? Gibt es eine gepflegte Menge von Fällen, gegen die man die Güte misst — vor jeder Änderung?
• Fehlermodi bedacht? Sind überzeugende Falschaussage, Abdrift, Grenzfall und Manipulation der Eingabe adressiert?
• Eingefasst? Ist der wahrscheinliche Kern von deterministischen Grenzen umgeben, die Ein- und Ausgabe prüfen?
• Mensch, wo nötig? Steht eine menschliche Kontrolle dort im Weg, wo eine falsche Antwort ernsten Schaden anrichtet — und nur dort?
• Kontext im Griff? Ist die Informationsquelle verlässlich, aktuell und nachvollziehbar — und wird der richtige Ausschnitt gewählt?
• Kosten und Latenz geplant? Ist der Preis pro Anfrage bedacht, mit gestuften Modellen, Zwischenspeicher und Ausweichwegen?
• Beobachtbar? Sieht man in Produktion, wie das System sich verhält — inklusive der stillen Verschlechterung?

Wer diese Fragen beantworten kann, hat ein KI-System gebaut, das man verantworten kann — nicht bloß eine Demo, die beeindruckt.

FAQ

Warum reicht eine überzeugende Demo nicht? Weil eine Demo den besten Fall zeigt und ein Produktivsystem den schlechten überstehen muss. Ein Modell, das in zehn vorgeführten Fällen glänzt, kann im elften still etwas Falsches behaupten — und dieser elfte Fall ist der, der in Produktion zählt. Die eigentliche Arbeit beginnt, wo die Demo endet.

Wie testet man ein System, das nicht immer dasselbe antwortet? Nicht mit einem erwarteten Ergebnis, sondern mit Evaluation über viele Fälle: eine Menge von Beispielen mit gewünschten Ergebnissen und ein Maß dafür, wie oft und wie stark das System abweicht. Man misst die Güte statistisch, nicht am Einzelfall, und misst vor jeder Änderung erneut, weil eine Verbesserung an einer Stelle anderswo schaden kann.

Was ist der gefährlichste Fehlermodus? Die überzeugende Falschaussage. Das Modell liefert eine flüssige, plausible, selbstsichere Antwort, die nicht stimmt — ohne Warnung, ohne Abbruch. Sie ist gefährlich, weil sie sich nicht von einer richtigen Antwort unterscheidet und deshalb geglaubt wird. Gegenmittel sind Evaluation, Prüfung gegen verlässliche Quellen und menschliche Kontrolle, wo es zählt.

Kommt es mehr auf das Modell oder auf die Daten an? Meist auf den Kontext, den man dem Modell gibt. Ein starkes Modell mit schlechtem Kontext antwortet schlecht; ein bescheidenes mit gutem Kontext oft erstaunlich gut. Die wirksamste Arbeit liegt deshalb selten in der Modellwahl, sondern darin, verlässliche, aktuelle Informationen sauber und relevant an das Modell zu bringen.

Muss ein Mensch jede KI-Ausgabe prüfen? Nein — das würde den Nutzen zunichtemachen. Menschliche Kontrolle gehört dorthin, wo eine falsche Antwort ernsten Schaden anrichtet, und darf dort entfallen, wo der Fehler folgenlos ist. Die Kunst ist, sie gezielt einzusetzen, nicht überall und nicht nirgends.

Wie hält man die Kosten im Griff? Indem man das Modell wie eine teure, langsame Ressource behandelt: nur fragen, wo es gebraucht wird; wiederkehrende Antworten zurückhalten; für einfache Aufgaben das kleinere Mittel wählen; einen Ausweg planen, wenn es langsam ist oder ausfällt. Kosten und Latenz sind eine Architekturfrage von Anfang an, keine spätere Optimierung.

Weiterführend

• Gute Werkzeuge verstärken — die Engineering Story dazu: KI amplifiziert Können, ersetzt aber nicht das Urteil.
• Observability ist Architektur — warum ein System, das man nicht beobachtet, seine stille Verschlechterung nicht zeigt.
• API Design für langlebige Systeme — das Modell hinter einer stabilen Grenze anbinden, austauschbar halten.
• Warum Softwareprojekte wirklich scheitern — warum der beeindruckende Anfang und das tragfähige System zweierlei sind.

Grundlage ist die Batunet Engineering Method: das Unsichere einfassen, für den Fehlerfall entwerfen, Beobachtbarkeit ab Tag eins, das Urteil beim Menschen halten.

Abschließendes Engineering-Prinzip

KI ändert nicht, was gute Technik ausmacht — sie stellt sie nur auf die Probe. Ein wahrscheinliches Modell ist kein Grund, die Disziplin aufzugeben, sondern der schärfste Anlass, sie anzuwenden: messen statt glauben, für den Fehlerfall entwerfen, das Unsichere hinter etwas Sicheres stellen, das Urteil beim Menschen lassen. Der Unterschied zwischen einer KI-Demo und einem KI-System ist genau der Unterschied zwischen Eindruck und Engineering. Das Modell liefert die Fähigkeit; die Verlässlichkeit liefert das System, das man darum herum baut. Wer das versteht, sieht in KI keine Abkürzung um die Ingenieurskunst herum, sondern eine neue, anspruchsvolle Anwendung für sie.

Eine Demo zeigt, dass etwas gehen kann. Ein System sorgt dafür, dass es verlässlich geht — auch im schlechten Fall. Zwischen beiden liegt die ganze Arbeit, und sie ist Engineering, kein Zauber.