Der Proof of Concept ist sauber aufgesetzt, die Demo läuft, die Fachseite nickt, und im Testsystem sieht alles nach Fortschritt aus. Dann soll der Assistent ins ERP greifen, echte Freigaben anstoßen oder mit CRM- und Finance-Daten arbeiten, und genau dort beginnt der Stillstand. Nicht weil das Modell schlecht ist, sondern weil System und Organisation noch nicht produktionsreif sind.
Production Readiness heißt: Ein KI-System ist nicht nur technisch funktional, sondern im realen Betrieb kontrollierbar, überprüfbar, abgesichert und integriert. Die Lücke ist gut sichtbar. Laut Statistik Austria nutzten 2025 bereits 30 % der österreichischen Unternehmen mit mindestens zehn Beschäftigten KI-Technologien, im EU-Schnitt 20 %. Gleichzeitig hatten 77 % der Unternehmen ohne KI den Einsatz noch gar nicht erwogen. Viele Piloten bleiben dazwischen hängen: Der Engpass ist selten die Demo, sondern die Brücke in den Betrieb, besonders dort, wo ERP, CRM, Buchhaltung, Freigaben und Altsysteme zusammenkommen.
Warum Proofs of Concept in der Praxis scheitern
Ein PoC kann beeindruckend aussehen und trotzdem im Alltag scheitern. Das passiert, wenn der Assistent in einer isolierten Oberfläche glänzt, aber keine echten Systemgrenzen kennt. Sobald er Daten aus einem ERP lesen, einen Vorgang im CRM anstoßen oder eine Freigabe im Finance-Prozess auslösen soll, tauchen die Fragen auf, die im Test nie hart genug gestellt wurden: Wer darf was? Was passiert bei Fehlern? Wer sieht den Entscheidungsweg?
Gutes Modell ist nicht gleich brauchbarer Betrieb
Ein Modell kann bei Texterkennung, Klassifikation oder Antwortgenerierung stark sein und trotzdem nicht produktionsreif. Production Readiness fragt nicht nur nach Präzision, sondern nach dem gesamten Betriebsbild: Zugriffsrechte, Wiederanlauf, Protokollierung, Ausfallsicherheit und die Frage, ob ein Prozess sauber weiterläuft, wenn ein Mensch eingreifen muss.
Ein PoC beantwortet meist nur die Frage, ob etwas grundsätzlich funktioniert. Produktion beantwortet die Frage, ob es unter Last, unter Kontrolle und unter echten Regeln funktioniert.
Warum der Sprung vom Labor in die Realität klemmt
Viele Teams unterschätzen, wie stark Produktion von Governance abhängt. Ein Assistent, der nur Vorschläge macht, ist leicht zu pilotieren. Ein Assistent, der Arbeitsaufträge erstellt, Belege prüft oder Stammdaten verändert, braucht Freigabepfade, Verantwortlichkeiten und technische Leitplanken. Genau dort endet der PoC oft, weil die Frage nach dem Betrieb erst ganz spät gestellt wird.
Die fünf Säulen der Production Readiness
Eine einzelne Liste mit „Test bestanden“ reicht nicht. Sinnvoller sind fünf Säulen, die gemeinsam entscheiden, ob ein System tragfähig ist: Modellqualität, Integrationsreife, Governance und Compliance, Monitoring sowie Betriebssicherheit und Wiederanlauf.
Modellqualität ist die Eintrittskarte, nicht das Ziel. In der Produktion zählt, ob Antworten stabil bleiben, ob Entscheidungen nachvollziehbar sind und ob das System auch bei schlechten Eingaben oder unvollständigen Daten kontrolliert reagiert.
Integrationsreife ist in vielen Unternehmen der eigentliche Flaschenhals. Ein KI-System wird erst nützlich, wenn es sauber mit ERP, CRM, Buchhaltung oder einem Legacy-Backoffice spricht. Ohne belastbare Schnittstellen bleibt der Assistent ein Chatfenster neben der Arbeit.
Governance und Compliance werden sichtbar, sobald ein System Entscheidungen mit Auswirkungen auf Geld, Kunden oder Buchungen vorbereitet. Dann braucht es Nachvollziehbarkeit, Freigaberegeln und dokumentierte Zuständigkeiten.
Monitoring sorgt dafür, dass Fehler früh auffallen. Einmal erfolgreich live zu gehen genügt nicht. Das System muss im Alltag beobachtbar bleiben.
Betriebssicherheit und Wiederanlauf bedeuten, dass es bei Problemen einen definierten Rückweg gibt, der geübt ist und nicht nur auf dem Papier steht.
Praktische Regel: Wenn ein Assistent einen Prozess verändern darf, muss dieselbe Organisation auch belegen können, wie sie den Prozess wieder in einen sicheren Zustand bringt.
Checkliste für KI-Agenten und Enterprise-Systeme
Sobald ein KI-Agent mit ERP, CRM oder einem Legacy-Backoffice spricht, zählt nicht mehr nur die Antwortqualität. Dann geht es um kontrollierte Übergaben, prüfbare Entscheidungen und einen Rückweg, wenn etwas schiefgeht. Trennen Sie vor dem Go-live klar zwischen Pflicht und Kür.
Kritisch vor dem Go-live
- Service-Level: Verfügbarkeit, Antwortzeit und Reaktionszeit bei Störungen sind schriftlich festgelegt, auch gegenüber Modell- und Cloud-Anbietern.
- Wiederanlaufziele: Für jeden kritischen Prozess sind maximale Ausfallzeit (RTO) und maximaler Datenverlust (RPO) aus dem geschäftlichen Schaden abgeleitet und getestet, nicht nur notiert.
- Auditierbarkeit: Jede Entscheidung hat einen nachvollziehbaren Pfad, besonders wenn das System Daten verändert oder Freigaben auslöst.
- Integrationstests: ERP, CRM, Finance und alle betroffenen Altsysteme sind im echten Zusammenspiel geprüft.
Wichtig für den kontrollierten Betrieb
- Datenschutz durch Technikgestaltung: Datenzugriffe sind an Rolle und Zweck gebunden.
- Freigabeprozesse: Schreibende Aktionen haben definierte menschliche oder technische Gates.
- Rollback-Plan: Ein dokumentierter Rückweg existiert und wurde geübt.
- Incident-Prozess: Es ist festgelegt, wer reagiert, wer eskaliert und wer entscheidet.
Empfehlenswert für kritische Umgebungen
- Shadow-Mode-Tests: Der Agent arbeitet parallel, ohne selbst operative Entscheidungen auszulösen.
- Wiederanlaufübungen: Teams testen regelmäßig, ob der Prozess nach Störungen tatsächlich zurückkommt.
- Betriebsdokumentation: Runbooks und Verantwortlichkeiten sind so klar, dass auch neue Teammitglieder arbeiten können.
- Regeln für Ausnahmen: Bleibt vor dem Go-live etwas offen, hat es ein Ablaufdatum und einen klaren Plan.
Für Finanzunternehmen kommen regulatorische Pflichten dazu. Seit 17. Jänner 2025 gilt der Digital Operational Resilience Act (DORA) mit Anforderungen an IKT-Risikomanagement, Vorfallsmeldungen, Resilienztests und das Management von IKT-Drittanbietern. Ein KI-System, das in solche Prozesse eingreift, fällt in diesen Rahmen.
Governance und Sicherheit in regulierten Umgebungen
Die härtesten Probleme entstehen selten im Modell, sondern in der Verantwortungskette. Wer darf Daten sehen? Wer darf eine Entscheidung freigeben? Wer trägt die Verantwortung, wenn ein Assistent etwas Falsches schreibt oder falsche Informationen anzeigt? In regulierten Unternehmen muss diese Kette durchgängig dokumentiert sein. Datenschutz, Genauigkeit und die Gefahr von Falschinformationen sind dabei keine Randthemen, sondern die eigentliche Voraussetzung für den Betrieb. Wer diese Fragen nicht beantwortet, kann einen Rollout zwar starten, aber nicht verantworten.
Die Governance-Schicht gehört zwischen Modell und Fachsystem
Ein sauberer Aufbau trennt drei Ebenen. Das Modell erzeugt Vorschläge oder Aktionen. Dazwischen liegt die Governance-Schicht mit Freigaben, Prüfungen und Logging. Erst danach erreicht die Aktion ERP, CRM oder Finance. So bleibt nachvollziehbar, wer was warum veranlasst hat.
Technische und organisatorische Kontrollen greifen dabei ineinander. Audit-Logs allein reichen nicht, wenn niemand die Berechtigungen pflegt. Freigaben allein reichen nicht, wenn das System keine saubere Protokollierung liefert. Und Datenschutz allein reicht nicht, wenn Zugriffe in den Fachsystemen offen bleiben. Einen strukturierten Rahmen dafür beschreibt unser Security Governance Framework.
Rollout-Strategien
Nicht jeder Go-live braucht denselben Mut. Ein unkritischer Assistent für interne Wissensabfragen kann anders starten als ein Agent, der auf Buchungs- oder Freigabedaten zugreift. Die richtige Strategie hängt von Risiko, Integrationskomplexität und regulatorischem Druck ab.
- Direkter Launch: Passt, wenn das Risiko klein ist, der Prozess eng umrissen ist und ein Fehler keinen Kaskadeneffekt auslöst. Das Team lernt schnell, trägt aber ein höheres Betriebsrisiko.
- Stufenweiser Rollout: Einzelne Standorte, Teams oder Prozessschritte werden nacheinander freigeschaltet. Probleme lassen sich isolieren, bevor sie das ganze Unternehmen betreffen.
- Canary Release: Ein kleiner Anteil der Vorgänge läuft über die neue Version, der Rest über den bisherigen Weg. Steigen Fehlerrate oder Eskalationen, wird zurückgeschaltet, bevor viele Fälle betroffen sind.
- Shadow-Mode: Bei hochkritischen Prozessen beobachtet, empfiehlt oder simuliert der Agent zunächst nur. Erst wenn die Ergebnisse validiert sind und die Fachseite Vertrauen aufgebaut hat, wird der aktive Betrieb freigegeben.
Wenn ein Fehler Geld, Compliance oder Kundenbeziehungen trifft, ist Parallelbetrieb oft die billigere Form von Vorsicht.
Monitoring und Wiederanlauf im laufenden Betrieb
Ein System ist nicht produktionsreif, nur weil es live ist. Erst im Betrieb zeigt sich, ob es driftet, langsamer wird und ob ein Team im Ernstfall schnell genug reagieren kann. Monitoring muss drei Fragen beantworten:
- Modellleistung: Liefert das Modell noch brauchbare Ergebnisse, oder lässt die Qualität nach?
- Geschäftlicher Effekt: Verbessert der Assistent den Prozess wirklich, gemessen an Durchlaufzeit, Fehlerquote und Eskalationen?
- Systemzustand: Sind Latenz, Durchsatz und Fehlerquoten im erwarteten Bereich?
Diese drei Ebenen gehören zusammen, weil ein technisch stabiles System trotzdem fachlich nutzlos sein kann.
Ein Backup ist nur dann wertvoll, wenn der Wiederanlauf getestet ist. Hier planen viele Projekte zu optimistisch. Ein dokumentierter Ablauf für Ausfall, Rückfall und manuelle Übernahme ist wichtiger als ein theoretisch perfektes Architekturdiagramm. Die entscheidende Frage lautet immer: Wer merkt den Fehler zuerst, und wer bringt den Prozess sicher zurück?
Merksatz: Wenn niemand einen Alarm versteht oder einen Runbook-Schritt ausführen kann, ist das System nicht überwacht, sondern nur protokolliert.
Production Readiness in der Praxis
Ein typischer Weg beginnt mit einer Risikoanalyse. Das Team prüft, welcher Prozess automatisiert werden soll, welche Daten dafür nötig sind und wo die Grenzen liegen. Danach folgt die Integration in bestehende ERP- und CRM-Systeme, zunächst in eng begrenztem Umfang, damit Fehler nicht auf den ganzen Betrieb durchschlagen.
Der Agent übernimmt zuerst vorbereitende Aufgaben, etwa das Sammeln von Informationen oder das Vorstrukturieren von Vorgängen. Freigaben bleiben beim Menschen, damit Governance, Protokollierung und fachliche Kontrolle greifen. So entsteht Vertrauen im Betrieb, nicht durch große Versprechen, sondern durch kontrollierte Schritte. Dazu gehören definierte Rollen, Beobachtbarkeit, Ausnahmeprozesse und ein Rollout, der nicht alles auf einmal freischaltet.
Besonders gut funktioniert dieser Übergang, wenn Senior Engineers direkt mit den Fach- und Ops-Teams arbeiten, statt ein fertiges System über den Zaun zu reichen. Dieses Modell beschreibt unser Beitrag zum Forward-Deployed Engineering. Wie wir KI-Projekte in den Betrieb bringen, zeigt die Seite zur KI-Implementierung.
Sprechen Sie mit uns
Wenn Sie einen PoC in einen kontrollierten, auditierbaren Betrieb überführen wollen, sprechen Sie mit uns.