Der KI-Pilot, der nie in Produktion ging: Was bei Daten und Betrieb fehlte

Der Pilot hat funktioniert. Auf einer Auswahl handverlesener Dokumente hat das Modell die Felder extrahiert, die Tickets sortiert und die Leute überzeugt, die ihn in Auftrag gegeben hatten. Monate später läuft er immer noch in einer Sandbox auf Beispieldaten, und niemand kann sagen, was nötig wäre, um ihn für die echte Queue einzuschalten.

Diese Lücke schließt man nicht, indem man das Modell austauscht. Eine Demo beantwortet, ob ein Modell ein Dokument lesen kann. Die Produktion fragt, was mit jedem Dokument passiert, auch mit dem gescannten, dem weitergeleiteten Thread und dem, bei dem das Modell falschliegt, und zwar auf Daten, die den vom Piloten genutzten Dienst möglicherweise nie erreichen durften.

Eine Demo beweist, dass das Modell lesen kann; die Produktion fragt nach jedem Dokument

2015 schrieben Sculley und Kollegen bei Google, dass nur ein kleiner Bruchteil realer Machine-Learning-Systeme aus Machine-Learning-Code besteht und dass die erforderliche umgebende Infrastruktur umfangreich und komplex ist. Eine Pipeline auf Basis eines Sprachmodells hat dieselbe Form, und ein Pilot, der nur aus dem kleinen Teil gebaut ist, hat nichts um sich herum, womit er in Produktion laufen könnte.

Legen Sie das, was der Pilot hatte, neben das, was die Produktions-Queue braucht, und die fehlende Arbeit ergibt eine Liste:

• Evaluierung: ein paar Beispiele, die jemandem gefallen haben, gegenüber einem gelabelten Set mit einer vereinbarten Abnahmeschwelle pro Feld
• Daten: Exporte, Beispieldaten oder eine gehostete API, gegenüber Live-Quellen, die Ihre Infrastruktur nicht verlassen dürfen
• Eingabe: saubere PDFs, gegenüber Scans, E-Mail-Threads, Anhängen und Templates, die sich ohne Vorankündigung ändern
• Ausgabe: Text, den ein Mensch gelesen hat, gegenüber Datensätzen, die ein anderes System verarbeitet und denen es vertrauen muss
• Betrieb: jeweils ein Nutzer, gegenüber Spitzenlast, einem Ausfall des Modellservers und einem Verantwortlichen nach dem Launch

Erst das Abnahmeset schreiben, dann das Modell anfassen

Das erste fehlende Artefakt ist ein gelabeltes Set echter Dokumente mit der Antwort, die jedes einzelne liefern soll. Ohne dieses Set wird jede Änderung an Prompt oder Modell von dem beurteilt, der an diesem Tag die Ausgabe liest, und der Pilot kann kein Gate bestehen, das nie aufgeschrieben wurde.

Die Rules of Machine Learning von Google stellen die Messung vor das Modell: Rule #2 lautet, zuerst Metriken zu entwerfen und zu implementieren. Für Extraktion und Ticket-Routing ist die Metrik nicht ein einziger Score für das ganze Dokument:

• Ziehen Sie die Dokumente aus echtem Traffic über einen Zeitraum, der lang genug ist, um Monatsende, Feiertage und die Absender mit ungewöhnlichen Formaten einzuschließen
• Lassen Sie sie von den Menschen labeln, die die Arbeit heute machen, auf einem Teil des Sets von zwei Personen unabhängig voneinander, und behandeln Sie deren Abweichungen als Lücken in der Spezifikation statt als Rauschen
• Bewerten Sie jedes Feld getrennt, denn ein falsches Datum wird durch einen richtigen Namen nicht ausgeglichen
• Legen Sie die Abnahmeschwelle pro Feld und pro Dokumenttyp schriftlich fest und benennen Sie, welche Felder automatisiert werden dürfen und welche immer an einen Menschen gehen
• Messen Sie den heutigen manuellen Prozess auf demselben Set, damit das Modell mit der realen Baseline verglichen wird und nicht mit Perfektion
• Halten Sie einen Teil des Sets von allen fern, die Prompts tunen, damit der abschließende Score nicht an den Beispielen gemessen wird, an die der Prompt angepasst wurde

Daten, die den Perimeter nicht verlassen dürfen, ändern die Architektur, nicht nur den Anbieter

Wenn der Pilot auf einem gehosteten Modell mit Beispieldaten, synthetischen Daten oder Dokumenten gebaut wurde, die jemand von Hand freigegeben hat, und die echten Daten keinen externen Anbieter erreichen dürfen, lässt sich das Ergebnis des Piloten nicht übertragen: Das Modell in der eigenen Infrastruktur ist womöglich ein anderes Modell oder dasselbe Open-Weight-Modell mit anderer Quantisierung und anderen Serving-Einstellungen, und in beiden Fällen muss seine Qualität auf dem Abnahmeset neu gemessen werden.

Das Modell ist die offensichtliche Komponente, die man in die eigene Infrastruktur holt. Es ist nicht die einzige, denn eine Pipeline auf Basis eines Sprachmodells kopiert die Daten an mehr Orte als den Modellaufruf:

• Der Inferenzserver und die Modellgewichte, mit fixierten Versionen
• Embeddings und der Vektorindex, die aus den Dokumenten abgeleitet sind und wie die Dokumente geschützt werden müssen
• Prompts, Ausgaben und Traces in Logs, denn ein geloggter Prompt enthält das Dokument, aus dem er gebaut wurde
• Das Abnahmeset, das Annotationstool und die Review-Queue
• Monitoring und Error-Tracking, die zu einer externen Kopie der Daten werden, wenn sie als gehosteter Dienst laufen

Maskierung hilft dort, wo Logs einen abgeschotteten Bereich verlassen müssen. Presidio, ein Open-Source-Framework, das bei Microsoft entstanden ist, erkennt und anonymisiert personenbezogene Daten in Text, und seine Dokumentation hält fest, dass es keine Garantie gibt, alle sensiblen Informationen zu finden, weil die Erkennung automatisiert ist. Maskierung begrenzt die Offenlegung; sie ersetzt nicht, dass die Daten intern bleiben.

Die Eingabe ist die unspektakuläre Hälfte: Scans, Threads und Anhänge

Ein Pilot bekommt Dokumente; die Produktion bekommt, was auch immer Absender erzeugen. Vor jedem Modellaufruf muss die Pipeline daraus Text machen, den sie auf seine Quelle zurückführen kann:

• Scans und Fotos laufen durch OCR, deren Fehler bei Ziffern und Tabellenspalten beim Modell als Text ankommen, der sicher wirkt
• E-Mail- und Ticket-Threads enthalten zitierte Antworten, Signaturen und Disclaimer, deshalb muss die jüngste Nachricht vom Verlauf getrennt werden
• Der eigentliche Inhalt steckt oft in Anhängen, und jedes Format braucht einen eigenen Extraktionspfad
• Jeder Chunk behält seine Quelle, also Datei, Seite und Offset, damit sich jedes extrahierte Feld auf die Textstelle zurückverfolgen lässt, aus der es stammt
• Duplikate, etwa eine weitergeleitete Mitteilung oder ein per E-Mail wiedereröffnetes Ticket, werden erkannt, bevor daraus zwei Datensätze werden

Lange Eingaben brauchen eigene Sorgfalt. In „Lost in the Middle“, 2024 in TACL veröffentlicht, zeigten Liu und Kollegen, dass die Leistung der getesteten Modelle oft am höchsten ist, wenn die relevante Information am Anfang oder am Ende des Eingabekontexts steht, und deutlich abnimmt, wenn sie in der Mitte eines langen Kontexts steht. Ein langes Dokument nach Abschnitten zu teilen, mit der Quelle an jedem Chunk, ist ein sichereres Standardvorgehen als die Annahme, das Modell lese den gesamten Kontext gleichmäßig, und das Abnahmeset zeigt, was für Ihre Dokumente gilt.

Strukturierte Ausgabe braucht ein Schema, einen Validator und einen Platz für die falsche Antwort

Constrained Decoding beschränkt das Modell auf JSON, das zu einem Schema passt: vLLM unterstützt das als Structured Outputs, llama.cpp über Grammatiken. Es legt die Form des Datensatzes fest, im Rahmen der Schema-Features, die das Backend unterstützt, und solange die Generierung nicht am Token-Limit abgeschnitten wird, aber nicht seine Richtigkeit: Ein wohlgeformter Datensatz kann trotzdem das falsche Datum enthalten.

Die Richtigkeit wird nach dem Modell geprüft, durch Code, dem das Unternehmen bereits vertraut:

• Typ- und Formatprüfungen: Datumsangaben, Währungen und Kennungen mit Prüfziffer, etwa die ISIN
• Feldübergreifende Regeln, etwa das Enddatum eines Zeitraums, das nicht vor dessen Startdatum liegen kann
• Lookups in Referenzdaten, die das Unternehmen bereits pflegt, etwa ein bekanntes Instrument oder ein bekannter Kunde
• Konsistenz mit der Quelle: Jeder extrahierte Wert muss vor der Normalisierung in der Textstelle vorkommen, auf die er verweist

Die eigene Konfidenz des Modells ist ein schwaches Gate. Der GPT-4 Technical Report von OpenAI, 2023 veröffentlicht, zeigt, dass das vortrainierte Modell auf einem Multiple-Choice-Benchmark gut kalibriert war und dass das Post-Training die Kalibrierung verringert hat. Eine selbst angegebene Sicherheit oder eine Token-Wahrscheinlichkeit ist ein Signal, das gegen das Abnahmeset zu testen ist, keine Schwelle, der man standardmäßig vertraut.

Ein Datensatz, der an irgendeiner Prüfung scheitert, geht in eine Review-Queue, nicht an das nachgelagerte System. Die Queue ist ein eigenständiges Produkt: Sie braucht einen Verantwortlichen, eine Kapazitätsplanung in Reviewer-Stunden, die neben jedem Feld angezeigte Quellstelle und Korrekturen, die zurück ins Abnahmeset fließen.

Tickets und Dokumente sind nicht vertrauenswürdige Eingaben für das Modell

Ein Support-Ticket ist Text, den jemand außerhalb des Unternehmens geschrieben hat, und ein Dokument kann Anweisungen enthalten, die sein Absender absichtlich platziert hat. Die OWASP Top 10 for LLM Applications 2025 führen Prompt Injection an erster Stelle, einschließlich indirekter Injection, bei der die Anweisungen in externen Inhalten ankommen, die das Modell verarbeitet, etwa einer Website oder einer Datei.

Drei Einträge derselben Liste lassen sich in Designregeln für eine Dokumenten-Pipeline übersetzen:

• Prompt Injection: Kennzeichnen Sie jedes Dokument und jedes Ticket als nicht vertrauenswürdigen Inhalt, getrennt von den Anweisungen in einem Template, das der Absender nicht bearbeiten kann
• Unsachgemäße Ausgabeverarbeitung (Improper Output Handling): Validieren Sie Modellausgaben, bevor irgendein System auf ihrer Grundlage handelt, so wie Sie Eingaben eines Nutzers validieren würden
• Übermäßige Handlungsbefugnis (Excessive Agency): Geben Sie der Pipeline nur das Minimum an Rechten, das ihre Aufgabe braucht, damit ein Modell, das Tickets liest, keine Konten schließen und keine Zahlungen auslösen kann

OWASP weist außerdem darauf hin, dass unklar ist, ob es einen narrensicheren Schutz vor Prompt Injection gibt. Das Gewicht tragen die Ausgabeprüfungen und die Begrenzung der Rechte, nicht die Formulierung des Prompts.

Modell, Prompt und Parser als eine Version fixieren

Das Verhalten einer Pipeline ist das Produkt mehrerer Artefakte, die sich unabhängig voneinander ändern. Behandeln Sie sie als ein Release und speichern Sie dessen Kennung an jedem Datensatz, den es erzeugt:

• Die Modellgewichte per Prüfsumme, mit der Quantisierung und der Version des Inferenzservers
• Das Prompt-Template, das Ausgabeschema und die Decoding-Parameter
• Die OCR-Engine, die Chunking-Regeln und die Validatoren
• Die Version des Abnahmesets, gegen die das Release bewertet wurde

Fixierte Versionen machen die Ausgaben nicht identisch. Thinking Machines Lab hat im September 2025 gezeigt, dass ein Inferenzserver für denselben Prompt bei Temperatur null unterschiedliche Completions zurückgeben kann, weil das Ergebnis einer Request davon abhängt, wie viele andere Requests mit ihr im selben Batch liegen; derselbe Beitrag zeigt, dass batch-invariante Kernels das auf Kosten der Geschwindigkeit beseitigen. Sofern der Server keine solchen Kernels nutzt, heißt Reproduzierbarkeit, das Abnahmeset bei jedem Release erneut laufen zu lassen und die Scores zu vergleichen, nicht identischen Text zu erwarten.

Betrieb: Kapazität, Queues und die Stunde, in der der Modellserver ausfällt

Kapazität wird in Tokens geplant, nicht in Dokumenten. Messen Sie die Verteilung der Eingabe- und Ausgabelänge im echten Traffic, denn ein langer Anhang kann so viel kosten wie viele kurze Tickets, und die Generierungszeit wächst mit der Länge der Ausgabe.

Serving-Systeme fassen Requests zu Batches zusammen, um den Beschleuniger auszulasten. Im vLLM-Paper, vorgestellt auf der SOSP 2023, berichteten Kwon und Kollegen, dass Paging des Key-Value-Caches der Attention den Durchsatz bei gleichem Latenzniveau um das 2- bis 4-Fache verbesserte, verglichen mit den Systemen, die sie evaluiert haben. Größere Batches erhöhen den Durchsatz und zugleich die Latenz jeder einzelnen Request, was eine Back-Office-Queue verkraften kann und ein interaktiver Schritt nicht, deshalb werden beide getrennt:

• Interaktive Verarbeitung, etwa eine Ticket-Triage, auf die ein Support-Mitarbeiter wartet, mit eigener Kapazität und einem Latenzziel
• Batch-Verarbeitung, etwa die nächtliche Extraktion, über eine Queue, die Spitzen abfängt und angehalten werden kann
• Backpressure zwischen Eingang und Modellserver: eine begrenzte Queue und ein Concurrency-Limit, damit eine Lastspitze an Dokumenten wartet oder mit einem Retry-Signal abgewiesen wird, statt den Server zu überlasten
• Idempotente Verarbeitung mit dem Dokument als Schlüssel, damit ein Retry nach einem Absturz keinen zweiten Datensatz erzeugt
• Ein Fallback auf den manuellen Prozess, wenn der Modellserver nicht verfügbar ist, damit die Arbeit auf einen Menschen wartet, statt verloren zu gehen

Der Fallback ist das, was das Einschalten der Pipeline umkehrbar macht. Der manuelle Prozess, den es heute gibt, bleibt die Rückfallebene, und die Pipeline nimmt ihm Arbeit Feld für Feld ab, statt ihn an einem einzigen Stichtag zu ersetzen.

Die Antworten überwachen, nicht nur die Server

Server-Dashboards zeigen, ob die Pipeline geantwortet hat. Sie zeigen nicht, ob die Antworten richtig waren, und ein Modell, das bei einem neuen Template schlechter wird, behält seine Latenz. Das Monitoring einer Extraktions- oder Ticket-Pipeline deckt beides ab:

• Die Review-Quote und die Korrekturen der Reviewer pro Feld, pro Dokumenttyp und pro Release
• Eine regelmäßige Stichprobe automatisierter Datensätze, die Menschen erneut gegen die Abnahmekriterien prüfen
• Drift der Eingaben: neue Absender, neue Templates, der Sprachmix und die Länge der Dokumente
• Validierungsfehler pro Regel, die ein neues Format sichtbar machen können, bevor sich die Genauigkeitsmetriken bewegen
• Tokens, Beschleunigerstunden und Wartezeit in der Queue pro Dokumenttyp, neben der Latenz jeder Stufe

Das Generative AI Profile des NIST, NIST AI 600-1, im Juli 2024 veröffentlicht, ordnet diese Arbeit den vier Funktionen seines AI Risk Management Framework zu: Govern, Map, Measure und Manage. Die Namen sind weniger wichtig als die Konsequenz: Messen nach dem Launch ist eine benannte und personell besetzte Aufgabe, nicht etwas, das das Pilotteam erledigt, wenn es Zeit hat.

Nach Feld und Dokumenttyp ausrollen: Shadow, assistiert, dann automatisiert

Die Pipeline an einem Stichtag für alles einzuschalten, bündelt jedes Risiko in einem einzigen Ereignis. Ein gestufter Rollout hält sie auseinander:

• Shadow: Die Pipeline verarbeitet Live-Traffic, schreibt nirgendwohin, und ihre Datensätze werden mit dem verglichen, was Menschen erstellt haben
• Assistiert: Die Pipeline füllt vor, ein Mensch bestätigt jeden Datensatz, und Korrekturen werden pro Feld gezählt
• Automatisiert pro Feld und pro Dokumenttyp, nur dort, wo die Abnahmeschwelle im Live-Traffic hält, während alles Übrige weiterhin geprüft wird
• Eine Rückschaltung in den assistierten Modus pro Dokumenttyp, die der Betriebsverantwortliche ohne gesonderte Freigabe auslöst, wenn eine überwachte Rate ihren Grenzwert überschreitet

Ein Pilot, der Dokumente gut liest und trotzdem nie in Produktion kommt, ist nicht am Lesen gescheitert. Er hat nie ein Abnahmeset bekommen, das er bestehen sollte, einen Datenpfad, den er nutzen durfte, einen Platz für seine falschen Antworten oder einen Verantwortlichen für den Tag nach dem Launch.

Die Firma, die das in Produktion bringt, fragt erst nach Ihren Dokumenten, dann nach Ihrem Wunschmodell

Die Frage hinter diesem Artikel, wer eine LLM-Pipeline in Ihrer eigenen Infrastruktur aufsetzen und tatsächlich in Produktion bringen kann, lässt sich mit einem Test beantworten, der keine Anbieterliste braucht. Eine Firma, die diese Arbeit macht, fragt nach Abnahme und Betrieb, bevor sie ein Modell empfiehlt:

• Bittet darum, eine Stichprobe echter Dokumente und Tickets zu sichten, auch die schlechten, innerhalb Ihrer Umgebung oder im Rahmen Ihrer Datenvereinbarung, und fragt, wie der manuelle Prozess sie heute behandelt
• Schlägt vor, zuerst mit Ihren Leuten das Abnahmeset aufzubauen, mit Abnahmeschwellen pro Feld, noch vor jedem Tuning
• Listet jeden Ort auf, an den die Daten kopiert werden, von Gewichten und Indizes bis zu Logs, Traces, Evaluierungsdaten, Review-Tool und Monitoring, und zeigt, dass jeder davon intern bleibt
• Nimmt die Validatoren, die Review-Queue und den Fallback auf manuelle Bearbeitung in dasselbe Designdokument auf wie das Modell
• Bringt ein Release mit, das Modell, Prompt, Schema und Parser gemeinsam fixiert, und einen Rollout pro Feld vom Shadow-Modus bis zur Automatisierung
• Benennt, wer die Pipeline nach dem Launch betreibt, wer die Stichprobe prüft und wer alarmiert wird, wenn der Modellserver stehen bleibt

Nach jedem Punkt können Sie im ersten Gespräch fragen, und eine vage Antwort bedeutet, dass der Umfang der fehlenden Arbeit des Piloten noch nicht bestimmt ist.

Die erste Frage ist also nicht, welches Modell innerhalb Ihres Perimeters laufen soll. Sie lautet, welche Felder in welchen Dokumenten Sie automatisiert akzeptieren würden, gemessen woran, und wer die Datensätze übernimmt, die an der Validierung scheitern.

Was amBrain über die oben in der Zusammenfassung beschriebene Produktionsintegration hinaus öffentlich belegen kann: amBrain baut seit 2019 Software. Wir arbeiten in drei Formaten: vollständige Umsetzung, dediziertes Team oder Engineers, die in Ihrem Team mitarbeiten.