Produktive KI · Architektur · Engineering
Vom KI-Prototyp zum Produktivsystem: Die Architektur-Checkliste, die viele Teams überspringen
Ein Prototyp beweist, dass ein Modell eine beeindruckende Antwort erzeugen kann. Ein Produktivsystem muss etwas Schwierigeres beweisen: dass die Antwort über einen freigegebenen Pfad entstanden ist, validiert werden kann, sicher fehlschlägt und auch nach der Demo von einem Team betrieben werden kann.
An dieser Lücke scheitern viele KI-Projekte. Teams optimieren Prompts und Modellwahl, während das umgebende System implizit bleibt: kein Abnahme-Gate, kein stabiler Output-Vertrag, keine Evidenzgrenze, kein Incident Owner und kein definiertes Verhalten bei Unsicherheit.
Dieser Leitfaden beschreibt die Architektur-Checkliste, mit der ich eine KI-Fähigkeit in ein verantwortbares Softwaresystem überführe. Sie gilt für RAG, Dokumentenautomatisierung, Klassifikation, Extraktion, Copilots und agentische Workflows. Ziel ist nicht, probabilistisches Verhalten zu beseitigen, sondern es in deterministische Grenzen einzuschließen.
Architekturprinzip
Das Modell ist eine Komponente. Das Produkt ist das Kontrollsystem darum.
Produktionsreife entsteht aus dem Zusammenspiel von Datenverträgen, Retrieval- oder Tool-Grenzen, Policy Enforcement, Evaluation, Observability, menschlicher Freigabe und Recovery. Ein stärkeres Modell kann fehlende Kontrollen nicht kompensieren.
1. Mit einem Abnahmevertrag beginnen, nicht mit einem Modell
Bevor ein Provider gewählt oder ein Prompt optimiert wird, muss klar sein, was das System tun darf, was als Erfolg gilt und wann es ablehnen oder eskalieren muss. Ohne diesen Vertrag bleibt jeder Modellvergleich subjektiv.
Ein brauchbarer Abnahmevertrag benennt Nutzer, freigegebene Datenquellen, unterstützte Aufgaben, verbotene Aktionen, minimale Evidenz, Latenz- und Kostengrenzen sowie den menschlichen Owner der finalen Entscheidung. Dazu gehören auch Negativfälle: fehlende Belege, widersprüchliche Dokumente, bösartige Eingaben, nicht verfügbare Tools und fehlerhafte Outputs.
Ein versionierter Evaluationssatz bildet reale und adversarielle Fälle ab.
Erfolgsmetriken beziehen sich auf die Geschäftsaufgabe, nicht auf einen generischen Modell-Benchmark.
Ablehnung und Eskalation sind testbare Ergebnisse, keine unverbindlichen Prompt-Hinweise.
Ein Release wird blockiert, wenn ein kritischer Sicherheits- oder Berechtigungstest fehlschlägt.
2. Einen deterministischen Vertrag um probabilistische Outputs legen
Freitext ist bequem für Demos und fragil für Software. Nachgelagerter Code sollte ein versioniertes Schema mit explizitem Status, typisierten Feldern, Evidenzreferenzen, Konfidenzsignalen und Validierungsfehlern erhalten.
Schema-Validierung ist nur die erste Grenze. Der Server muss prüfen, ob Quellen aus dem freigegebenen Retrieval-Set stammen, Tool Calls einer Allowlist entsprechen, IDs existieren, Summen stimmen und Werte Domänenregeln einhalten. Schlägt die Validierung fehl, wird innerhalb eines engen Budgets erneut versucht oder kontrolliert abgebrochen.
article12Page.code3. Kontext, Retrieval und Tools als Sicherheitsgrenzen behandeln
Prompt Injection wird nicht dadurch gelöst, dass man dem Modell sagt, schlechte Anweisungen zu ignorieren. Abgerufene Dokumente, Webseiten, E-Mails und Tool-Antworten sind nicht vertrauenswürdige Eingaben. Sie dürfen keine Policies neu definieren, Rechte erweitern oder unbemerkt Aktionen auslösen.
Identität und Autorisierung gehören vor das Retrieval und vor jede Tool-Ausführung. Tools brauchen enge Scopes, validierte Parameter, Timeouts, Rate Limits, möglichst Idempotenz und eine klare Trennung zwischen Lese- und Schreibaktionen. Wirkungskritische Writes benötigen Bestätigung oder menschliche Freigabe.
4. Evaluation in die Auslieferung integrieren, nicht in die Abschlussdemo
Ein produktiver Evaluationssatz enthält Normalfälle, Edge Cases, absichtlich unbeantwortbare Anfragen, Berechtigungsgrenzen, Injection-Versuche, Tool-Ausfälle und Beispiele mit abweichendem Expertenurteil. Erwartetes Verhalten und Bewertungshinweise werden mit dem Testfall versioniert.
article12Page.section4P2
Aufgabenqualität
Exaktheit, Vollständigkeit, Klassifikationsqualität, Extraktionsgenauigkeit oder fachlich geprüfte Korrektheit für den konkreten Workflow.
Evidenzqualität
Ob die zitierte oder gefundene Quelle die konkrete Aussage wirklich trägt – nicht nur, ob irgendeine Citation vorhanden ist.
Grenzqualität
Ablehnung, Berechtigungsisolation, Injection-Resistenz, Schema-Validität und sicheres Verhalten bei Ausfällen.
Betriebsqualität
p50/p95-Latenz, Fehlerrate, Token- und Tool-Kosten, Retry-Rate, Queue-Tiefe und Volumen menschlicher Reviews.
5. Wichtige Runs nachträglich erklärbar machen
Bei einem Incident reicht ein Chatverlauf nicht aus. Das Team braucht einen Trace aus Policy-Version, Prompt- oder Workflow-Version, Modell, gefundenen Source-IDs, Tool-Entscheidungen, Validierungsergebnissen, Latenz, Kosten und finaler Reviewer-Aktion.
Das bedeutet nicht, jedes vertrauliche Dokument oder jeden vollständigen Prompt unbegrenzt zu speichern. Logs werden minimiert, zugriffsgeschützt und zweckgebunden aufbewahrt. Ziel sind Reproduzierbarkeit und Verantwortbarkeit, nicht wahllose Überwachung.
6. Den Fehlerpfad vor dem Happy Path entwerfen
Provider haben Timeouts. Suchen liefern keine Treffer. Dokumente widersprechen sich. Parser zerstören Tabellen. Ein Tool schreibt erfolgreich, aber der Callback geht verloren. Produktive Architektur benennt diese Zustände und entscheidet, was erneut versucht, gequeued, degradiert, eskaliert oder abgelehnt wird.
Retries brauchen Limits und Idempotenz. Queues brauchen Dead-Letter Handling. Externe Writes brauchen Reconciliation. Die Oberfläche muss zwischen „in Bearbeitung“, „Review erforderlich“, „unzureichende Evidenz“ und „fehlgeschlagen“ unterscheiden – denn ein schöner, aber unklarer Spinner ist keine Betriebsstrategie.
7. Menschliche Prüfung sinnvoll gestalten
Human-in-the-loop ist keine Sicherheitskontrolle, wenn Reviewer nur auf Freigeben klicken. Die Oberfläche muss Quellenbelege, Unsicherheit, geänderte Felder, Policy-Warnungen und die genaue Wirkung der Freigabe zeigen.
Feedback sollte strukturiert werden: akzeptiert, korrigiert, abgelehnt, Grundkategorie und Reviewer-Rolle. So entsteht Material für Evaluation und Verbesserung, ohne jede Korrektur automatisch als Trainingssignal zu behandeln.
8. Ownership für Kosten, Änderungen und Incidents festlegen
Ein System ist erst produktionsreif, wenn jemand Modell- und Prompt-Änderungen, Evaluationsschwellen, Datenquellenqualität, Security Review, Budgetalarme, Incident Response und Rollback verantwortet. Zuständigkeiten können geteilt werden, dürfen aber nicht unbenannt bleiben.
Modell-Upgrades sind Software-Releases. Sie brauchen Change Record, Regression Evaluation, Canary- oder Staged Rollout, überwachte Schwellen und Rollback-Pfad. Gleiches gilt für Embedding-Modelle, Reranker, Extraktions-Prompts, Tool-Schemas und Policy-Regeln.
Das Production Gate
Vor dem Go-live sollte das Team jede dieser Fragen mit Ja beantworten:
Gibt es einen versionierten Abnahmesatz mit positiven, negativen und adversariellen Fällen?
Werden Rechte außerhalb des Modells an Retrieval- und Tool-Grenzen erzwungen?
Werden Outputs vor der Weiterverarbeitung per Schema und Domänenregeln validiert?
Kann das System ablehnen, eskalieren und fehlschlagen, ohne ein Ergebnis zu erfinden?
Lässt sich eine wichtige Entscheidung aus einem minimierten Audit Trace rekonstruieren?
Sind Latenz, Kosten, Fehler, Retries und Review-Volumen beobachtbar?
Haben Schreibaktionen passende Bestätigungs- und Idempotenzkontrollen?
Gibt es für jede produktive Änderung einen benannten Owner und Rollback-Pfad?
Produktive KI ist diszipliniertes Software Engineering
Der Sprung vom Prototyp zum Produkt ist kein einzelnes Framework und kein besserer Prompt. Er verändert das Versprechen des Systems. Ein Prototyp verspricht eine überzeugende Fähigkeit. Ein Produktivsystem verspricht begrenztes Verhalten, messbare Qualität, recoverbare Fehler und verantwortbaren Betrieb.
Darum liegt die wertvollste AI-Engineering-Arbeit oft außerhalb des Modellaufrufs. Die Kontrollschicht um das Modell macht die Fähigkeit sicher genug für die Nutzung, klar genug für eine Freigabe und stabil genug für einen echten Geschäftsprozess.
Primärquellen
Sie haben einen KI-Prototyp, dem noch die Produktivarchitektur fehlt?
Ich unterstütze Teams dabei, Evidenzgrenzen, Evaluations-Gates, Sicherheitskontrollen und Betriebsmodell zu definieren, die aus einer KI-Demo ein belastbares System machen.
Gespräch beginnen