Vom KI-Piloten in den Produktivbetrieb: Fünf belastbare Entscheidungswege für österreichische Unternehmen

Illustratives Szenario, Wien, August 2026. Im Besprechungsraum eines Wiener Mittelstandsunternehmens endet die Vorführung eines KI-Piloten mit Applaus. Das System hat eingehende technische Anfragen vorsortiert, passende Unterlagen gefunden und einen Antwortentwurf vorbereitet. Im Pilotteam waren die Ergebnisse schneller und meist besser als erwartet. Der Geschäftsführer stellt deshalb die scheinbar einfache Frage: „Können wir freigeben?“

Plötzlich wird aus der Demo eine Betriebsentscheidung. Die Bereichsleiterin will wissen, wer fehlerhafte Entwürfe abfängt. Der Datenschutz fragt nach den tatsächlich verwendeten Daten. Die Informationssicherheit hat noch keine belastbare Antwort auf Berechtigungen und Protokollierung. Der Einkauf wartet auf Vertragsanlagen und Ausstiegskonditionen. Der Betriebsrat war über den Test informiert, aber nicht über die geplante Veränderung von Aufgaben und Kontrolle. Alle haben den gleichen Piloten gesehen und dennoch fünf verschiedene Entscheidungen im Kopf.

Das Szenario ist eine illustrative, realitätsnahe Verdichtung typischer Situationen in Österreich und im DACH-Raum. Es ist kein Kundenfall und behauptet kein Ergebnis.

Vom KI-Piloten in den Produktivbetrieb: die kurze Antwort

Ein KI-Pilot ist bereit für den Produktivbetrieb, wenn die Geschäftsführung nicht nur die Qualität einer Vorführung, sondern einen begrenzten, verantworteten und kontrollierbaren Betriebsfall freigeben kann. Dafür braucht sie belastbare Evidenz in sechs Domänen: Geschäftswert, Prozessleistung, Daten und Datenschutz, Architektur und Informationssicherheit, Betrieb und menschliche Aufsicht sowie Einkauf und Lieferkette.

Die Entscheidung ist nicht binär. Für einen priorisierten Workflow gibt es fünf belastbare Zustände: freigeben, unter Auflagen freigeben, neu gestalten, zurückstellen oder stoppen. Der richtige Zustand hängt nicht von der Begeisterung im Demo-Termin ab, sondern davon, welche Behauptungen durch Nachweise gedeckt sind und welche Verantwortung jemand tatsächlich übernimmt.

Operative Analyse: Dieses Fünf-Zustände-Modell, die Scorecard und der nachfolgende Entscheidungspfad sind eine Managementmethode. Sie sind weder gesetzliche Vorgaben noch Zertifizierungskriterien und ersetzen keine rechtliche, datenschutzrechtliche oder arbeitsrechtliche Prüfung im Einzelfall.

Ein guter Pilot ist noch kein guter Betrieb

Im Piloten arbeitet ein kleines, motiviertes Team mit ausgesuchten Fällen. Es kennt die Schwächen des Systems, korrigiert still im Hintergrund und kann bei Problemen auf den bisherigen Ablauf zurückfallen. Kosten für manuelle Nacharbeit, Sonderfälle und Betreuung verschwinden leicht im Projektbudget. Genau das macht einen Pilotversuch nützlich: Er soll schnell Erkenntnisse erzeugen.

Der Produktivbetrieb stellt eine andere Frage. Was passiert an einem Montagmorgen mit realem Volumen, neuen Mitarbeitenden, abwesenden Expertinnen, einem Modellupdate des Anbieters und einem Fall, der in keinem Testsatz vorkam? Wer erkennt eine Verschlechterung? Wer darf den Workflow anhalten? Wie wird weitergearbeitet, wenn ein Dienst ausfällt? Was kostet der Fall dann tatsächlich?

Ein Pilot beweist daher im besten Fall, dass ein Lösungsansatz Potenzial hat. Produktionsreife verlangt zusätzlich, dass Nutzen, Grenzen, Zuständigkeiten und Rückwege im normalen Betrieb funktionieren. Wer diese Ebenen vermischt, finanziert nicht die Skalierung eines Beweises, sondern die Skalierung offener Fragen.

Warum die Produktionsentscheidung 2026 anspruchsvoller geworden ist

Faktenlage 2026: Die Europäische Kommission veröffentlichte am 7. Juli 2026 einen EU-Aktionsplan zu Cybersicherheit und künstlicher Intelligenz. Er verbindet den sicheren und verantwortungsvollen KI-Einsatz mit Cyberresilienz und sieht unter anderem sichere Testunterstützung für kritische Sektoren vor. Das ist keine individuelle Freigaberegel für österreichische Unternehmen. Es zeigt aber, dass KI-Einführung und Informationssicherheit 2026 nicht mehr als getrennte Programme behandelt werden sollten.

Für agentische Systeme betont die 2026 gestartete AI Agent Standards Initiative des NIST sichere Funktionsweise, interoperable Protokolle sowie Identität und Autorisierung von Agenten. Das freiwillige NIST AI RMF Playbook ordnet Risikomanagement in die Funktionen Govern, Map, Measure und Manage ein. Beide Quellen sind keine österreichischen Rechtsnormen. Als technische Orientierung unterstreichen sie jedoch, warum ein überzeugender Output-Test allein für autonome oder teilautonome Abläufe zu kurz greift.

Auch ISO/IEC 42001:2023 beschreibt Anforderungen an Aufbau, Umsetzung, Erhaltung und laufende Verbesserung eines KI-Managementsystems. Die hier vorgestellte Scorecard bescheinigt weder Konformität mit dieser Norm noch begründet sie eine Zertifizierung. Sie nutzt lediglich denselben vernünftigen Managementgedanken: Eine Produktionsentscheidung braucht einen wiederholbaren Prozess und benannte Verantwortliche.

Rechtlicher Anwendungsbereich und betriebliche Vernunft sind zwei verschiedene Linien

Fakt: Für Hochrisiko-KI verlangt Artikel 14 des EU AI Act eine dem Risiko, dem Autonomiegrad und dem Einsatzkontext angemessene menschliche Aufsicht. Menschen müssen das System je nach Fall überwachen, Ausgaben einordnen, übersteuern oder den Betrieb unterbrechen können. Artikel 26 nennt für Betreiber von Hochrisiko-Systemen Pflichten rund um bestimmungsgemäße Nutzung, Aufsicht, Monitoring und Vorfälle.

Abgrenzung: Ob ein konkreter Workflow in diesen Anwendungsbereich fällt und welche Pflichten tatsächlich gelten, ist einzelfallabhängig. Dieser Artikel verallgemeinert Hochrisiko-Pflichten nicht auf jeden KI-Piloten. Umgekehrt ist „nicht hochriskant“ keine Managementfreigabe. Datenschutz, Informationssicherheit, Arbeitsorganisation, Vertragsrisiken und die Verantwortung für Kundenergebnisse können eine belastbare Prüfung verlangen, auch wenn eine bestimmte AI-Act-Pflicht nicht greift.

Analyse: Für die Geschäftsführung ist die nützliche Frage deshalb nicht nur „Müssen wir?“, sondern auch „Können wir diesen Workflow mit vertretbarem Aufwand zuverlässig verantworten?“ Die rechtliche Einordnung setzt Mindestanforderungen, wo sie anwendbar ist. Die Produktionsentscheidung bestimmt darüber hinaus, ob das Unternehmen den Betrieb organisatorisch und wirtschaftlich tragen kann.

Vor der Freigabe wird der Workflow eng gezogen

„Unsere KI-Lösung geht in Produktion“ ist kein entscheidbarer Satz. Ein Vorstand oder eine Geschäftsführung kann nur einen konkreten Einsatz freigeben: mit definiertem Eingang, Ergebnis, Nutzerkreis, Datenraum, Systemgrenzen und Ausschlüssen. Je unschärfer der Gegenstand, desto leichter werden Freigaben erteilt, die später niemand verantworten kann.

Eine brauchbare Entscheidungsgrenze beantwortet sieben Fragen auf einer Seite:

1. Welcher konkrete betriebliche Vorgang beginnt und endet wo?
2. Welche Entscheidung oder Handlung darf die KI vorbereiten, und welche ausdrücklich nicht?
3. Welche Personen nutzen oder beaufsichtigen das Ergebnis?
4. Welche Daten dürfen hinein, welche müssen draußen bleiben?
5. Welche Systeme, Anbieter und Schnittstellen sind beteiligt?
6. Bei welchem Signal wird auf den bisherigen Ablauf zurückgeschaltet?
7. Wer besitzt Budget, Betriebsverantwortung und finale Freigabe?

Diese Grenze schützt auch vor dem häufigsten Scope-Fehler: Ein Pilot für einen schmalen Hilfsschritt wird unbemerkt zur Automatisierung einer ganzen Entscheidungskette erklärt. Bewertet wird immer nur jener Workflow, für den Evidenz vorliegt.

Die fünf belastbaren Entscheidungswege

Ein klares Vokabular verhindert, dass „Go“ fünf verschiedene Bedeutungen bekommt. Jeder Zustand beschreibt eine andere Managementhandlung und braucht einen eigenen Beschluss.

1. Freigeben

Der abgegrenzte Workflow zeigt belastbaren Nutzen, die kritischen Kontrollen funktionieren und der Betrieb hat einen Owner. Restrisiken sind bekannt und innerhalb der vereinbarten Toleranz. Die Freigabe nennt Volumen, Nutzerkreis, Monitoring, Rückfallverfahren und das Datum der nächsten Überprüfung. Sie ist keine Generalvollmacht für weitere Anwendungsfälle.

2. Unter Auflagen freigeben

Der Workflow darf kontrolliert starten, aber nur mit konkret messbaren Bedingungen. Eine Auflage hat einen Owner, eine Frist, ein Abnahmekriterium und eine Konsequenz bei Nichterfüllung. „Datenschutz noch einbinden“ ist keine Auflage. „Vor Öffnung für Standort B muss die Löschroutine mit dokumentiertem Test bestanden sein“ ist eine.

3. Neu gestalten

Der Nutzen ist plausibel, doch die derzeitige Architektur oder Aufgabenverteilung trägt ihn nicht. Vielleicht erhält das System zu breite Berechtigungen, vielleicht findet menschliche Kontrolle erst statt, nachdem bereits gehandelt wurde, oder die Fehlerkosten sind im gewählten Prozessschritt zu hoch. Dann wird nicht länger am Piloten poliert. Der Workflow, die Kontrollpunkte oder die technische Lösung werden neu entworfen.

4. Zurückstellen

Eine zeitlich oder sachlich benennbare Voraussetzung fehlt: notwendige Datenqualität, eine Vertragszusage, interne Kapazität, eine noch ausstehende Mitwirkung oder eine abhängige Plattformentscheidung. Zurückstellen bedeutet nicht, das Projekt ohne Termin im Portfolio zu parken. Der Beschluss nennt das Wiedervorlage-Ereignis und beendet bis dahin vermeidbare Ausgaben.

5. Stoppen

Der wirtschaftliche Wert trägt die Betriebs- und Kontrollkosten nicht, ein wesentliches Risiko lässt sich nicht vertretbar reduzieren oder der Workflow löst das falsche Problem. Stoppen ist dann keine Niederlage, sondern eine Investitionsentscheidung. Der Abschluss hält fest, was gelernt wurde, welche Daten oder Komponenten weiterverwendet werden dürfen und was geordnet stillgelegt wird.

Die Beweiskette statt der Foliensammlung

Ein Entscheidungsgremium braucht keine längere Präsentation, sondern eine nachvollziehbare Kette: Geschäftsbehauptung, technischer und betrieblicher Nachweis, verbleibende Unsicherheit, verantwortliche Person und daraus abgeleitete Entscheidung. Fehlt ein Glied, entsteht im Termin eine Grundsatzdiskussion, obwohl eigentlich nur ein Nachweis offen ist.

Der Unterschied ist kaufmännisch relevant. Eine fehlende Information wird gezielt beschafft. Eine unklare Verantwortung wird als Governance-Lücke behandelt. Ein negativer Test wird nicht in einer Durchschnittskennzahl versteckt. Dadurch sinkt die Gefahr, dass laut vertretene Meinungen mehr Gewicht erhalten als das tatsächliche Betriebsbild.

Die Sechs-Domänen-Evidenz-Scorecard

Die Scorecard bewertet jede Domäne von 0 bis 3: 0 bedeutet nicht geklärt oder nicht vertretbar, 1 bedeutet plausible Annahme ohne ausreichenden Nachweis, 2 bedeutet für den begrenzten Einsatz ausreichend belegt, 3 bedeutet unter realistischen Bedingungen belegt und im Betrieb verantwortet. Die Zahl schafft Vergleichbarkeit, ersetzt aber kein Urteil.

Ein hoher Gesamtwert kann eine Null in Datenschutz oder Informationssicherheit nicht ausgleichen. Ebenso wenig sollte eine starke technische Bewertung fehlende Betriebsverantwortung verdecken. Kritische Nullwerte sind Stoppsignale für den aktuellen Entwurf, nicht automatisch für den gesamten Geschäftsnutzen.

Wie aus sechs Bewertungen eine Managemententscheidung wird

Die Scorecard ist ein Gesprächsgerüst, kein Automat. Es gibt keinen universellen Gesamtwert, ab dem eine Freigabe automatisch belastbar wäre. Entscheidend ist das Evidenzmuster: Scope, Owner, Monitoring und Rückfallweg müssen tatsächlich stehen; eine kritische Null in Datenschutz, Informationssicherheit oder Betriebsverantwortung darf nicht durch starke Werte in anderen Domänen verrechnet oder als bloße Auflage kleingeredet werden.

Die anderen drei Zustände ergeben sich nicht aus einem simplen Schwellenwert. Neu gestalten ist richtig, wenn die Wertthese hält, aber die Lösungsarchitektur oder der Kontrollpunkt falsch gewählt wurde. Zurückstellen passt bei einer klaren, später eintretenden Voraussetzung. Stoppen passt, wenn die Wertthese nicht trägt oder ein wesentliches Risiko nicht vertretbar reduziert werden kann.

Das Decision Evidence Pack für die Freigaberunde

Das Decision Evidence Pack ist die kleinste vollständige Unterlage, mit der ein Entscheidungsgremium den Workflow beurteilen und den Beschluss später nachvollziehen kann. Es ist kein Aktenfriedhof. Für einen einzelnen Workflow genügen meist acht präzise Bausteine:

1. Entscheidungsblatt: gewünschter Zustand, beantragter Scope, Investition, Owner und Entscheidungsdatum.
2. Workflow- und Systemgrenze: Start, Ende, Nutzer, Daten, Systeme, Anbieter, erlaubte Handlungen und Ausschlüsse.
3. Wertnachweis: Baseline, Volumen, Nutzenhypothese, Vollkosten und Bandbreite bei schlechteren Annahmen.
4. Evaluationsakte: Testsatz, Qualitätsgrenzen, Fehlerklassen, Gegenproben, manuelle Nacharbeit und bekannte Blindstellen.
5. Kontroll- und Risikoregister: Datenschutz, Informationssicherheit, Missbrauch, Ausfall, Monitoring, Eskalation und Rückfallweg.
6. Betriebsmodell: fachlicher und technischer Owner, menschliche Aufsicht, Support, Schulung, Änderungsfreigabe und Vorfallweg.
7. Beschaffungsnachweis: Vertragsstatus, Leistungszusagen, Datenverwendung, Unterauftragnehmer, Kostenänderungen und Exit-Möglichkeit.
8. Entscheidungsprotokoll: Fakten, Annahmen, abweichende Einschätzungen, Auflagen, Fristen und nächste Überprüfung.

Jeder Baustein nennt Stand, Quelle und Verantwortlichen. „In Prüfung“ darf vorkommen, aber nicht ohne Termin und Entscheidungsauswirkung. So bleibt offen, was wirklich offen ist.

Wer in Österreich an den Tisch gehört

Die Zusammensetzung richtet sich nach dem Workflow, nicht nach einem Standardorganigramm. Die Geschäftsführung oder der Budgetverantwortliche besitzt die Investitionsentscheidung. Der Fachbereich verantwortet Ergebnis und Prozess. IT beziehungsweise Architektur verantwortet Systemgrenzen und Betriebsfähigkeit. Datenschutz beurteilt die konkrete Datenverarbeitung. Informationssicherheit prüft Zugriffe, Missbrauch, Protokollierung, Ausfall und Lieferkette. Der Einkauf macht aus Herstellerpräsentationen belastbare Vertragspositionen.

Der Betriebsrat gehört frühzeitig eingebunden, wenn Aufgaben, Leistungskontrolle, Arbeitsmittel oder Beschäftigtendaten berührt sein können. Der genaue Beteiligungsbedarf hängt vom Einzelfall und den geltenden Regelungen ab. Operativ ist die frühe Einbindung auch unabhängig von der juristischen Einordnung sinnvoll: Mitarbeitende kennen jene Ausnahmen, Umgehungswege und Belastungsspitzen, die in einem Pilottest selten sichtbar werden.

Entscheidend ist eine saubere Rollenverteilung. Datenschutz und Informationssicherheit erteilen nicht stellvertretend die Geschäftsfreigabe. Der Einkauf entscheidet nicht über Prozessqualität. Der Fachbereich kann technische Risiken nicht allein akzeptieren. Jede Funktion liefert ihr Urteil zur eigenen Domäne; eine benannte Person führt diese Urteile zur KI-Produktionsentscheidung zusammen.

Der 15-20-Arbeitstage-Pfad zur Entscheidung

Der Pfad ist für einen bereits erprobten, priorisierten Workflow gedacht. Er baut kein unternehmensweites KI-Programm und repariert kein ungeklärtes Projektportfolio. Liegen wesentliche Unterlagen gar nicht vor, kann die richtige Entscheidung nach 20 Arbeitstagen durchaus „neu gestalten“ oder „zurückstellen“ lauten.

Arbeitstage 1-3: Entscheidung und Grenze festziehen

Geschäftsfrage, Zielkennzahl, Workflow-Grenze, beantragter Zustand und Entscheidungsträger werden schriftlich festgelegt. Gleichzeitig benennt das Team alle sechs Domänenverantwortlichen. Offene Grundsatzfragen werden sichtbar, bevor jemand weitere Tests bestellt.

Arbeitstage 4-7: Vorhandene Evidenz ordnen

Pilotresultate, Architektur, Datenflüsse, Datenschutzunterlagen, Sicherheitsprüfungen, Betriebsentwurf und Vertragsdokumente kommen in eine gemeinsame Evidenzkarte. Jede Behauptung erhält Quelle, Stand und Owner. Das Team trennt fehlende Dokumentation von tatsächlich fehlender Kontrolle.

Arbeitstage 8-11: Kritische Annahmen angreifen

Nun werden nicht noch mehr Durchschnittsfälle getestet, sondern die teuersten Irrtümer: schwierige Eingaben, Rechteüberschreitung, fehlerhafte Quellen, Ausfall, unklare Eskalation, Anbieteränderung und hohe Nacharbeitslast. Der Rückfall auf den bisherigen Ablauf wird praktisch geprobt. Ein Test, der eine Annahme widerlegt, ist ein wertvoller Entscheidungsnachweis.

Arbeitstage 12-15: Gemeinsame Bewertung und Vorentscheidung

Fachbereich, Datenschutz, Informationssicherheit, Einkauf und gegebenenfalls Betriebsrat prüfen dieselbe Version des Packs. Die sechs Domänen werden begründet bewertet. Strittige Punkte werden als konkrete Entscheidungsfragen formuliert, nicht als allgemeine Bedenken. Am Ende steht ein vorgeschlagener Zustand mit Begründung.

Arbeitstage 16-20: Beschluss und Mandat

Bei einem überschaubaren Workflow kann die Entscheidung bereits an Tag 15 fallen. Komplexere Fälle nutzen die verbleibenden Tage für gezielte Nachweise, Auflagenverhandlung und die finale Freigabe. Der Beschluss wird mit Scope, Budgetgrenze, Owner, Bedingungen, Stoppsignalen und Review-Datum protokolliert. Erst danach beginnt die nächste Investitionsphase.

Die Freigaberunde braucht eine Entscheidung, keinen Statusbericht

Das Meeting beginnt mit dem beantragten Zustand und den drei stärksten Nachweisen, nicht mit der Geschichte des Piloten. Danach kommen die kritischen Lücken und die Empfehlung. Jede Domänenverantwortliche beantwortet dieselbe Frage: „Welche Evidenz würde meine Einschätzung ändern?“ So lassen sich echte Blocker von allgemeinem Unbehagen unterscheiden.

Für eine Freigabe unter Auflagen werden Bedingungen einzeln beschlossen. Jede Bedingung braucht eine überprüfbare Erledigung. Für „neu gestalten“ wird der neue Entwurfsauftrag finanziert, nicht die bisherige Pilotverlängerung. Für „zurückstellen“ wird ein Wiedervorlage-Ereignis definiert. Für „stoppen“ wird die geordnete Beendigung beauftragt. Das Ergebnis ist damit in jedem Fall handlungsfähig.

Ein gutes Protokoll hält auch Gegenstimmen fest. Nicht um Verantwortung zu verteilen, sondern um später zu erkennen, welche Annahmen sich verändert haben. Wenn ein Anbieter, ein Datenfluss oder die Arbeitsorganisation angepasst wird, lässt sich die Entscheidung gezielt wieder öffnen, statt das gesamte Projekt neu zu erzählen.

Die bedingte 30/60/90-Tage-Roadmap

Eine Roadmap beginnt erst nach der Entscheidung und richtet sich nach deren Zustand. Ein pauschaler Rollout-Plan für alle fünf Wege würde die gerade gewonnene Klarheit wieder zerstören.

Bis Tag 30: Bedingungen erfüllen und Betriebsbasis setzen

Bei freigeben werden Monitoring-Baseline, Support, Rückfallweg und Änderungsprozess produktiv gesetzt. Bei unter Auflagen freigeben startet nur der genehmigte Umfang; jede Auflage wird abgenommen. Bei neu gestalten entsteht ein neuer Workflow- und Kontrollentwurf. Bei zurückstellen werden Ausgaben eingefroren und nur das Wiedervorlage-Signal beobachtet. Bei stoppen werden Zugänge, Datenkopien und laufende Verträge geordnet geschlossen.

Bis Tag 60: Reale Betriebsdaten gegen die Entscheidung prüfen

Freigegebene Workflows werden anhand von Qualität, Nacharbeit, Vorfällen, Nutzung und Vollkosten geprüft. Auflagen, die nicht fristgerecht erfüllt sind, lösen die vereinbarte Begrenzung oder Rücknahme aus. Ein neu gestalteter Workflow darf eine begrenzte Validierung durchlaufen, aber noch keinen stillen Rollout. Zurückgestellte und gestoppte Vorhaben erzeugen keine Schattenprojekte.

Bis Tag 90: Erweitern, korrigieren oder erneut entscheiden

Nur wenn die reale Evidenz die ursprüngliche Annahme trägt, wird über mehr Volumen, weitere Nutzer oder zusätzliche Fähigkeiten entschieden. Andernfalls wird begrenzt, neu gestaltet oder gestoppt. Die 90-Tage-Prüfung ist kein Ritual: Sie ist die erste Produktionsentscheidung auf Basis echten Betriebs statt Pilotbedingungen.

Typische Fehlentscheidungen nach einer starken Demo

Der Pilotchampion wird automatisch zum Betriebs-Owner. Fachliche Begeisterung ist wertvoll, ersetzt aber weder Budgetverantwortung noch Bereitschaftsdienst, Eskalation und Änderungsfreigabe.

Der Durchschnittswert verdeckt den teuren Fehler. Ein System kann in 95 Prozent der Fälle gut arbeiten und trotzdem ungeeignet sein, wenn die restlichen fünf Prozent hohe Schäden oder unvertretbare Nacharbeit verursachen.

Eine offene Kontrolle wird zur Auflage umbenannt. Nicht jede Lücke darf nach dem Start geschlossen werden. Fehlender Zugriffsschutz, ungeklärte Datenverwendung oder kein funktionsfähiger Rückfallweg können den aktuellen Entwurf blockieren.

Der Einkauf kommt nach der technischen Festlegung. Dann werden Datenrechte, Preisanpassungen, Unterauftragnehmer und Exit-Kosten zu Tatsachen, obwohl noch keine bewusste Abhängigkeit beschlossen wurde.

Der Betriebsrat erfährt von der Einführung statt von der Gestaltung. Das kostet Vertrauen und verschenkt Prozesswissen. Frühe Einbindung bedeutet nicht automatische Zustimmung; sie macht Auswirkungen und Alternativen rechtzeitig prüfbar.

Zurückstellen wird mit Weiterarbeiten verwechselt. Ein vertagtes Vorhaben, das weiter Budget verbraucht, ist faktisch ohne Freigabe in Produktion gegangen.

Was offizielle Quellen belegen und was dieses Modell hinzufügt

Belegt durch offizielle Quellen: Der EU-Aktionsplan vom Juli 2026 verknüpft sicheren KI-Einsatz mit Cyberresilienz. NIST beschreibt freiwillige Risikomanagementfunktionen und arbeitet 2026 an Standards und Protokollen für sichere, interoperable KI-Agenten einschließlich Identität und Autorisierung. Der AI Act enthält für Hochrisiko-Systeme Anforderungen an menschliche Aufsicht und Pflichten für Betreiber. ISO/IEC 42001 spezifiziert Anforderungen an ein KI-Managementsystem.

Eigene operative Analyse: Die fünf Entscheidungszustände, die sechs Domänen, die Punktelogik, das Decision Evidence Pack, der 15-20-Arbeitstage-Pfad und die bedingte 30/60/90-Roadmap sind ein vorgeschlagenes Vorgehen für eine konkrete Investitions- und Betriebsentscheidung. Sie sind keine behördliche Methodik, keine Rechtsberatung, keine Konformitätsbewertung und kein Zertifizierungsnachweis.

Die Trennung ist wichtig: Offizielle Quellen begründen, warum Aufsicht, Risikomanagement, Sicherheit und verantworteter Betrieb relevant sind. Das Modell beantwortet die Managementfrage, wie ein österreichisches Unternehmen diese Themen für einen einzelnen Workflow in eine klare Freigabe bringt.

FAQ zur KI-Produktionsentscheidung

Wann ist ein KI-Pilot bereit für den Produktivbetrieb?

Wenn für einen klar begrenzten Workflow Nutzen und Prozessleistung belegt sind, Daten und Datenschutz geklärt wurden, Architektur und Informationssicherheit tragfähig sind, ein Betriebs-Owner samt menschlicher Aufsicht feststeht und der Einkauf die Liefer- und Ausstiegsbedingungen geklärt hat. Eine gute Demo allein reicht nicht.

Ist „unter Auflagen freigeben“ nur ein freundlicheres Ja?

Nein. Es ist ein begrenzter Beschluss mit überprüfbaren Bedingungen. Jede Auflage braucht Owner, Termin, Abnahmekriterium und eine vorab vereinbarte Konsequenz. Fehlen diese vier Elemente, wurde keine Auflage beschlossen, sondern Unsicherheit verschoben.

Wann soll ein Unternehmen neu gestalten statt zurückstellen?

Neu gestalten passt, wenn die Wertthese plausibel bleibt, aber Workflow, Architektur oder Kontrollpunkt ungeeignet sind. Zurückstellen passt, wenn eine konkrete Voraussetzung außerhalb dieses Entwurfs fehlt und ihr Eintritt absehbar überprüft werden kann. Ohne solches Ereignis ist „zurückstellen“ meist nur ein unklarer Projektstatus.

Welche Rolle haben Datenschutz, Informationssicherheit und Betriebsrat bei der Freigabe?

Sie liefern die belastbare Bewertung für ihre jeweilige Domäne und machen notwendige Kontrollen oder Beteiligung sichtbar. Die finale Investitions- und Betriebsfreigabe bleibt bei der dafür verantwortlichen Geschäftsleitung. Welche rechtlichen Anforderungen im konkreten Fall gelten, muss gesondert geprüft werden.

Kann die Sechs-Domänen-Scorecard eine Rechtsprüfung oder Zertifizierung ersetzen?

Nein. Sie strukturiert eine Managemententscheidung für einen Workflow. Sie bestätigt weder AI-Act-Konformität noch Datenschutzkonformität und ist kein Nachweis einer Zertifizierung nach ISO/IEC 42001 oder einer anderen Norm.

Was soll nach einem Stopp mit den Pilotresultaten passieren?

Der Beschluss sollte Lernergebnisse, wiederverwendbare Komponenten, zulässige Datenbestände, Vertragsfolgen und die technische Stilllegung festhalten. So wird aus dem Stopp verwertbares Organisationswissen und kein still weiterlaufender Schattenbetrieb.

Aus Pilotbelegen wird ein Architekturmandat

Wenn Ihr KI-Pilot überzeugt, aber die Freigabe zwischen Fachbereich, Datenschutz, Informationssicherheit, Einkauf und Betriebsrat festhängt, braucht es keine weitere Demo. Ein Architekturmandat verdichtet für einen priorisierten Workflow die Systemgrenze, sechs Evidenzdomänen, Betriebsverantwortung und Entscheidungsoptionen zu einem belastbaren Mandat für die Geschäftsführung. Das Ergebnis ist keine Zertifizierung und keine Rechtsmeinung, sondern eine klar dokumentierte KI-Produktionsentscheidung mit nächsten Schritten.

Architekturmandat für Ihre KI-Produktionsentscheidung besprechen