KI-Architektur für Unternehmen: 12-Punkte-Checkliste

Production Readiness ist kein Komponenten-Check

Ein Architekturdiagramm zeigt Komponenten und Verbindungen. Es beweist nicht, dass eine AI-Lösung unter realen Daten, Last und Fehlern sicher betrieben werden kann. Ein erfolgreicher Demo-Run beweist dasselbe wenig. Auch vorhandene Guardrails sind nur eine Behauptung, solange nicht geprüft ist, ob sie an den kritischen Systemgrenzen tatsächlich greifen.

Produktionsreife entsteht nicht dadurch, dass alle Architekturbausteine vorhanden sind. Entscheidend ist, ob die kritischen Entscheidungen zu Daten, Zugriff, Sicherheit, Qualität, Betrieb, Fehlerfällen, Kosten und Exit mit belastbarer Evidenz bewertet werden können.

Dieses Memo prüft deshalb keine Tool-Liste. Es fragt: Ist diese konkrete Lösung für ihren vorgesehenen Einsatz ausreichend begrenzt, messbar, betreibbar und wiederherstellbar?

Vor den Gates: Scope und Failure Budget

Ohne klaren Scope kann kein Production-Readiness-Review belastbar sein. Vor den technischen Gates muss feststehen:

• Welchen konkreten Prozess oder Outcome unterstützt die Lösung produktiv?
• Welche Nutzer oder Systeme verwenden sie?
• Welche Aktionen darf sie ausführen, welche nie?
• Was liegt ausdrücklich außerhalb des Scopes?
• Welcher Fehler wäre geschäftlich nicht tolerierbar?

Ein Support-Assistent, der eine belegte Antwort vorschlägt, hat ein anderes Failure Budget als ein Agent, der Tickets schließt oder Kundendaten ändert. Der Scope legt fest, welche Fehler akzeptabel eskalieren dürfen und wo die Architektur technisch stoppen muss. Ohne diese Grenze kann ein Team eine technisch saubere Lösung für einen unklaren Use Case freigeben.

So wird jedes Architecture Gate bewertet

Jedes Gate erhält einen expliziten Status:

• GO: Die relevante Entscheidung ist getroffen, Evidenz liegt vor und die verbleibenden Risiken liegen innerhalb akzeptierter Grenzen.
• MITIGATION NEEDED: Kein unmittelbarer Blocker; das verbleibende Risiko ist explizit bewertet und akzeptiert. Maßnahme, Owner, Frist und Verifikationskriterium sind dokumentiert. Ob die Mitigation vor oder nach dem Go-live erfolgen darf, hängt vom konkreten Risiko ab.
• BLOCKED: Eine zentrale Voraussetzung fehlt oder ein Risiko kann derzeit nicht ausreichend begrenzt beziehungsweise bewertet werden. Produktion nicht freigeben.

Production-Readiness-Review

1. 01

   Scope festlegen

   Welcher Prozess, welche Nutzer, Aktionen und nicht tolerierbaren Fehler liegen im Review?

   Prüfgrenze dokumentiert

2. 02

   Gate-Evidenz prüfen

   Welche Entscheidung ist belegt, welche beruht noch auf Annahmen?

   GO, Mitigation oder Blocker

3. 03

   Blocker isolieren

   Welche Systemgrenze oder Failure Class verhindert eine verantwortbare Freigabe?

   Risiko konkret benannt

4. 04

   Mitigation definieren

   Welche Maßnahme reduziert das Risiko, wer verantwortet sie und woran wird sie geprüft?

   Owner und Verifikation

5. 05

   Freigabe dokumentieren

   Welche Trade-offs werden bewusst akzeptiert und wann wird die Entscheidung erneut geprüft?

   GO, MITIGATION NEEDED oder BLOCKED dokumentiert

Kein numerischer Gesamtscore und kein Ampel-Durchschnitt ersetzt diese Entscheidung. Ein einzelner echter Blocker bei Zugriff, Sicherheitsgrenzen, Evaluation oder Recovery darf nicht durch acht grüne Gates kompensiert werden.

Gate 1: Data – Herkunft, Aktualität und Reproduzierbarkeit

Architekturentscheidung

Welche Daten dürfen den Output beeinflussen, welche Quelle bleibt führend und wie lässt sich der damalige Datenstand nachvollziehen? Ein Retrieval-Index, Cache oder abgeleiteter Datensatz ist keine zweite Fachwahrheit.

Required Evidence

• Source of Truth, fachliche Identität und Provenance je relevanter Datenklasse,
• Versionen, Gültigkeitsstatus und Freshness-Anforderung,
• Regeln für Update, Delete, Archive und Restore,
• bekannte Datenqualitätsgrenzen,
• ein nachvollziehbarer Pfad, um einen Output aus dem damaligen Datenstand zu erklären oder zu reproduzieren.

Typische Blocker

Unbekannte Datenherkunft, veraltete Inhalte ohne sichtbare Freshness, nicht propagierte Deletes oder eine Datenpipeline, deren Ergebnis nicht reproduzierbar ist.

Mögliche Mitigation und GO

Ein Pilot kann mit weniger Quellen starten. Er braucht aber eine klar führende Quelle, dokumentierte Freshness-Grenzen und überprüfbare Lifecycle-Ereignisse. GO ist vertretbar, wenn ein kritischer Output zu Quelle, Version und Zeitstand zurückgeführt werden kann. Die Details für Lifecycle und Ingestion behandeln RAG-Datenquellen anbinden; für dokumentenzentrierte Systeme sind DMS an RAG anbinden und SharePoint an RAG anbinden die passenden Deep Dives.

Gate 2: Identity & Access – effektive Rechte an jeder Systemgrenze

Architekturentscheidung

Welche Identität gilt entlang des gesamten Execution Paths: am Login, beim Retrieval, bei API-Calls und bei Tool-Aktionen? Maßgeblich ist die effektive Berechtigung am Ende dieses Pfads, nicht nur ein korrektes Login im Frontend.

Required Evidence

• Identity-Mapping zwischen Anwendung, Datenquelle und externen APIs,
• Rollen, ACLs, Mandantengrenzen und Service Identities,
• erlaubte Lese- und Schreibaktionen pro Tool,
• Least-Privilege-Grenzen und nachvollziehbare Delegation,
• Tests für Rechtewechsel und verweigerte Zugriffe.

Typische Blocker

Post-Filtering sensibler Inhalte, fehlendes Identity-Mapping oder Tool Calls über einen überprivilegierten Service Account sind keine akzeptablen Restarbeiten.

Mögliche Mitigation und GO

Eine Read-only-Assistenz kann mit weniger Delegation starten als ein aktiver Agent. GO ist erst vertretbar, wenn nicht autorisierte Evidenz den Modellkontext nicht erreichen kann und jede Aktion mit der richtigen Identität und minimalem Scope ausgeführt wird. Die Retrieval-Perspektive vertieft RAG-Berechtigungen & Security Trimming.

Gate 3: Security – Containment statt nachträglicher Kontrolle

Architekturentscheidung

Wo liegen Trust Boundaries, und welche Eingaben, Tools und Ausgaben dürfen diese Grenzen überschreiten? Bei AI-Systemen reicht Erkennung allein nicht: Kritische Aktionen müssen technisch begrenzt sein.

Required Evidence

• dokumentierte Trust Boundaries für User Input, Kontext, Modelle, Tools und Egress,
• Begrenzungen gegen Prompt- und Context-Injection,
• Secret-Handling ohne Secrets in Prompt, Client oder ungeschützten Logs,
• Tool Isolation, Sandboxing sowie Rate- und Action-Limits,
• sichere Defaults für unbekannte, ungültige oder unerwartete Modellresultate.

Typische Blocker

Ein frei formulierter Modelloutput kann privilegierte Tools steuern, ein Connector kann Daten unkontrolliert nach außen geben oder ein Secret ist über Prompt, Log oder Tool-Output erreichbar.

Mögliche Mitigation und GO

Read-only-Tools, enge Schemas, Allow-Lists, explizite Freigaben und technische Egress-Grenzen reduzieren das Risiko. GO ist vertretbar, wenn ein manipuliertes Modellresultat keine Aktion außerhalb seiner begrenzten Berechtigung auslösen kann. Datenschutz, Datenresidenz und das passende Betriebsmodell sind ein angrenzendes Review: DSGVO-konforme KI für Unternehmen.

Gate 4: Evaluation – messbare Qualität vor und nach Änderungen

Architekturentscheidung

Was bedeutet für diesen Use Case „funktioniert“ – und welche Fehlerklasse ist nicht akzeptabel? Modell, Prompt, Retrieval, Daten und Tool-Verhalten müssen gegen dieselbe kontrollierte Basis prüfbar bleiben.

Required Evidence

• Qualitätskriterien und Go-live-Akzeptanzkriterien,
• ein versioniertes Golden Dataset oder Regression Set mit realistischen Fällen,
• erwartete Fehlerklassen, Negativfälle und zulässige Eskalationen,
• Task- und gegebenenfalls Tool-Erfolg statt bloß plausibler Antworten,
• ein Verfahren, das Änderungen vor dem Rollout auf Regressionen prüft.

Typische Blocker

„Funktioniert bei meinen Tests“, keine reproduzierbare Baseline, keine Akzeptanzkriterien oder Änderungen ohne Regressionstest reichen nicht für eine Freigabe.

Mögliche Mitigation und GO

Ein kleines, kuratiertes Set kritischer Fälle ist besser als eine große, unklare Benchmark-Sammlung. GO ist vertretbar, wenn bekannte kritische Fehler messbar sind und eine Änderung nicht unbemerkt bereits gelöste Fälle verschlechtert. Metriken und Fehlerdiagnose vertieft RAG Evaluation: Golden Dataset & Regression Tests. Bei agentischen Workflows mit Tool Calls oder State Changes reicht diese systemweite Freigabe allein nicht: Der konkrete Execution Path muss zusätzlich geprüft werden. Das behandelt AI Agent Evaluation.

Gate 5: Observability – Fehler, Drift und Kosten diagnostizierbar machen

Architekturentscheidung

Welche Signale machen einen schlechten Output, Drift oder eine teure Anfrage bis zu ihrer Ursache nachvollziehbar? Infrastruktur-Monitoring allein reicht nicht, wenn Modell, Retrieval und Tool-Aufruf gemeinsam ein Ergebnis erzeugen.

Required Evidence

• Request- und Trace-Korrelation über Modell-, Retrieval- und Tool-Schritte,
• getrennte Signale für Latenz, Token- und Tool-Kosten, Fehler und Eskalationen,
• Retrieval- und Qualitätsindikatoren, die zu den definierten Failure Classes passen,
• datensparsame Logging-Regeln, Zugriff auf Diagnoseinformationen und Retention,
• eine praktikable Incident-Diagnose.

Typische Blocker

Fehler werden nur über Nutzerbeschwerden sichtbar, eine falsche Antwort lässt sich keiner Komponente zuordnen oder Kosten und Latenz sind nicht pro Request beziehungsweise Task sichtbar.

Mögliche Mitigation und GO

Nicht „alles loggen“, sondern die minimale Evidenz erfassen, die eine Ursache unterscheiden kann. GO ist vertretbar, wenn das Team einen repräsentativen Fehler zu Request, betroffenen Schritten, Datenstand und Version zurückverfolgen kann, ohne unnötig sensible Inhalte zu protokollieren.

Gate 6: Failure Modes – Timeouts, Tool-Fehler, Fallbacks und Recovery

Architekturentscheidung

Wie verhält sich das System außerhalb des Happy Paths? Der Happy Path zeigt Funktionalität; die Failure Paths zeigen Produktionsreife.

Required Evidence

• erwartete Reaktion auf Modell-Ausfall, Rate Limit, Timeout und nicht verfügbares Retrieval,
• Regeln für fehlgeschlagene Tools, Partial Execution und doppelte Ausführung,
• Retry-Strategie, Backoff sowie Idempotency Key oder Deduplication bei geeigneten mutierenden Aktionen,
• Status-Reconciliation bei unbekanntem Ausführungszustand,
• Fail-closed- oder Fail-open-Entscheidungen, Fallback und Human Handoff,
• Recovery- und Rückgängigkeitsstrategie für kritische Aktionen.

Typische Blocker

Ein fehlgeschlagener Tool Call kann unklaren Teilzustand hinterlassen. Ein Timeout oder Verbindungsabbruch bei einer mutierenden Aktion bedeutet nicht automatisch, dass sie nicht ausgeführt wurde; ein einfacher Retry kann sie doppelt ausführen.

Mögliche Mitigation und GO

Bei nicht rückgängig zu machenden Aktionen sind Human Gates oder explizite Bestätigung oft sinnvoller als Autonomie. Lässt sich ein unbekannter Ausführungszustand nicht automatisch klären, braucht es einen Human Handoff oder eine sichere Eskalation. GO ist vertretbar, wenn die kritischen Failure Paths bewusst getestet wurden und das System bei Unsicherheit in einen sicheren, erklärbaren Zustand fällt.

Gate 7: Cost & Capacity – Last, Limits und wirtschaftliche Grenzen

Architekturentscheidung

Welche reale Last muss die Lösung tragen, und wie begrenzt sie Kosten und Degradation, wenn Modelle, Retrieval oder APIs knapp werden?

Required Evidence

• Annahmen zu Nutzern, Concurrency, Lastspitzen und erwarteter Context Size,
• Provider Rate Limits und Verhalten bei deren Überschreitung,
• Kosten pro Task einschließlich Modell-, Retrieval- und Tool-Aufrufen,
• Budgetgrenzen, Alerting sowie Backpressure oder Queueing,
• Degradation Strategy, etwa kleinere Antwort, spätere Verarbeitung oder sichere Eskalation.

Typische Blocker

Unbekannte Unit Economics, kein definiertes Verhalten bei Rate Limits, ungebremst eskalierende Kosten oder keine belastbare Annahme zur realen Last.

Mögliche Mitigation und GO

Eine frühe Version darf konservative Limits setzen und komplexe Aufgaben bewusst in eine Queue verschieben. GO ist vertretbar, wenn die Kosten pro relevanter Aufgabe bekannt sind und die Lösung bei Spitzen kontrolliert degradiert statt unkontrolliert teuer oder unzuverlässig zu werden.

Gate 8: Vendor Lock-in & Exit – Austauschbarkeit, Export und Rebuild

Architekturentscheidung

Ist die Abhängigkeit bewusst akzeptiert – und ist ein realistischer Exit möglich, wenn Preis, Qualität, Verfügbarkeit oder Strategie sich ändern? Lock-in ist nicht pauschal schlecht; unbewusster Lock-in ist ein Betriebsrisiko.

Required Evidence

• provider-spezifische APIs, Vektoren, Stores und Agent Runtimes klar benannt,
• exportierbare Datenformate und Eigentum an Daten, Konfigurationen und Evaluationsfällen,
• versionierte Prompts, Workflows und entscheidende Infrastrukturkonfiguration,
• Rebuild-Fähigkeit für abgeleitete Daten und kritische Systemzustände,
• dokumentierte Wechsel- und Revisit-Trigger.

Typische Blocker

Ein Anbieterwechsel ist nur theoretisch möglich, Daten oder Evaluationswissen lassen sich nicht exportieren oder die Architekturentscheidung existiert nur als Erinnerung einzelner Projektmitglieder.

Mögliche Mitigation und GO

Definieren Sie für bewusst akzeptierte Trade-offs einen ADR: Kontext, Optionen, Entscheidung, Risiken, Konsequenzen sowie Exit- und Revisit-Trigger. GO ist vertretbar, wenn der Preis der Abhängigkeit bekannt ist und ein Wechsel oder Rebuild als konkreter Ablauf beschrieben werden kann. Die Wahl des Betriebsmodells behandelt Private AI vs. Public Cloud ausführlicher.

Gate 9: Operations – Ownership, Runbooks, Change und Rollback

Architekturentscheidung

Wer reagiert Montagmorgen, wenn es nicht funktioniert? Produktion braucht einen benannten Owner, einen Incident Path und eine sichere Änderungskette – auch für Modell-, Provider- und Datenänderungen.

Required Evidence

• Owner für Produkt, Daten, technische Plattform, Security und Freigabe kritischer Änderungen,
• Incident Path, Runbooks und erreichbare Eskalation,
• Versionsmanagement für Modell, Prompt, Daten- und Tool-Konfiguration,
• Deployment-, Rollback- sowie Backup-/Restore-Verfahren,
• regelmäßige Re-Evaluation bei Provider-, Modell-, Daten- oder Nutzungsänderungen.

Typische Blocker

Das Pilotteam löst sich auf, niemand besitzt das Runbook, ein Modellwechsel kann nicht zurückgerollt werden oder ein Incident hat keinen klaren ersten Verantwortlichen.

Mögliche Mitigation und GO

Ein schlankes Runbook genügt, wenn es die realen Failure Paths abdeckt. GO ist vertretbar, wenn Zuständigkeit, erste Reaktion und Wiederherstellung für einen kritischen Incident praktisch nachvollziehbar sind.

Was ein Pilot vereinfachen darf – und was nicht

Ein Pilot darf kleiner sein: Skalierung, Komfort, UI, Automatisierungsgrad und bestimmte Integrationen können bewusst begrenzt bleiben.

Er darf aber nicht auf Annahmen beruhen, die für Produktion komplett verworfen werden müssen. Identity-Modell, grundlegende Daten- und ACL-Logik, Evaluierbarkeit, Failure Boundaries, Ownership und irreversible Exit-Entscheidungen gehören deshalb früh in den Pilot.

Ein Pilot darf kleiner sein. Er sollte aber nicht die Risiken ausblenden, die Produktion später bestimmen.

Die Review-Ausgabe: Entscheidungen, Mitigations und Blocker

Ein Architecture Review endet nicht mit einem abstrakten Score-Dashboard. Sein Ergebnis ist ein Entscheidungsartefakt:

• GO-Entscheidungen mit der zugehörigen Evidenz,
• MITIGATION NEEDED mit Maßnahme, Owner, Frist und Verifikationskriterium,
• BLOCKED mit konkretem Risiko, fehlender Voraussetzung und Entblockierungsbedingung,
• ADRs für bewusst akzeptierte Trade-offs,
• Revisit Trigger für Änderungen bei Daten, Modellen, Providern, Last oder Risikoprofil.

So bleibt Production Readiness keine Momentaufnahme. Sie wird bei relevanten Änderungen erneut prüfbar, statt dass Entscheidungen in Slides oder in der Erinnerung des Projektteams verschwinden.

Vier Anti-Patterns vor dem Go-live

Tool-first Architecture

„Wir haben eine Plattform gekauft – jetzt suchen wir den Use Case.“ Ohne Scope und Failure Budget gibt es keine belastbare Freigabegrenze.

Prompt as Business Logic

Deterministische Regeln wandern in unversionierte Prompts. Dann sind Verhalten, Testbarkeit und Rollback unnötig fragil.

Agent Everything

Autonomie wird eingesetzt, obwohl ein begrenzter Workflow mit klaren Übergaben sicherer und leichter recoverbar wäre.

Pilot ohne Production Path

Die Demo funktioniert mit Testdaten, Admin-Rechten und manueller Nacharbeit. Die kritischen Produktionsrisiken wurden damit nicht getestet, sondern verborgen.

Wann ein Architecture Review vor Produktion nötig ist

Eine Review ist besonders sinnvoll, wenn ein PoC produktiv werden soll, RAG oder Agenten auf reale Unternehmenssysteme zugreifen, kritische Tool-Aktionen geplant sind oder Modell-, Provider- und Plattformentscheidungen später teuer rückbaubar wären.

Für eine neue Initiative mit offenen Systemgrenzen, Zielbild oder Build-Plan ist KI-Beratung & AI Solution Architecture der passende Einstieg. Besteht bereits ein System, Pilot, RAG- oder Agent-Setup vor Rollout oder Go-live, ist KI Production Readiness die passende Alternative, um diese Gates gegen den realen Stand zu prüfen.