

Als über den EU AI Act gesprochen wird, landen die Gespräche oft sehr schnell bei Governance-Strukturen, Risikoklassen, Registern und internen Prüfprozessen. Das ist wichtig – aber es blendet eine Realität aus, die in vielen Unternehmen darüber entscheidet, ob AI-Compliance überhaupt kontrollierbar wird: Der größte Teil der KI, die heute genutzt wird, wird nicht „gebaut“, sondern eingekauft. Und genau deshalb ist Einkauf und Vendor Management die unterschätzte Frontlinie.
Das klingt zunächst nach Zuständigkeitsdebatte, ist aber in Wahrheit eine Steuerungsfrage. Denn wenn KI-Funktionen in Standardsoftware, Cloud-Services, Plattformen oder Dienstleisterleistungen stecken, dann entstehen Pflichten und Risiken dort, wo Sie als Kunde Einfluss nehmen können: in Beschaffung, Vertragsgestaltung, laufender Steuerung und Exit-/Fallback-Logik. Wenn diese Hebel nicht sauber gesetzt sind, kann die beste interne Governance im Alltag kaum greifen. Dann haben Sie vielleicht ein KI-Register – aber die wesentlichen Informationen fehlen. Oder Sie haben eine Klassifizierung – aber kein vertragliches Fundament, um Nachweise einzufordern. Oder Sie haben Regeln – aber keine Routine, um Änderungen des Anbieters rechtzeitig zu erkennen.
In der Praxis zeigt sich das oft sehr unauffällig. Ein Fachbereich braucht schnell eine Funktion, die „intelligent“ wirkt: Dokumente zusammenfassen, Tickets vorsortieren, Anfragen klassifizieren, Texte formulieren, Bilder prüfen, Entscheidungen vorbereiten. Der Anbieter hat das Feature „out of the box“. Der Bedarf ist real, der Nutzen ist schnell sichtbar – also wird gekauft oder aktiviert. Monate später stellt jemand die Frage: „Ist das eigentlich KI im Sinne unseres Registers? Welche Daten gehen da rein? Wer ist verantwortlich? Wie haben wir das Risiko eingeordnet? Was passiert, wenn der Anbieter das Modell ändert? Können wir das nachvollziehen?“ Wenn diese Fragen erst nachträglich gestellt werden, entsteht die typische Kombination aus Stress und Reibung: Compliance will Ordnung, der Fachbereich will weiterarbeiten, IT will keine Schattenverträge, Vendor Management hat nur Standardklauseln, und am Ende wird das Thema politisch, obwohl es eigentlich operativ lösbar wäre.
Der EU AI Act verschärft das nicht, weil er „mehr Papier“ verlangt, sondern weil er Erwartungen an Transparenz, Kontrolle und Nachweisfähigkeit erhöht – je nach Einsatzkontext und Risikoklasse. Und diese Nachweisfähigkeit ist bei eingekauften Lösungen kein Automatismus. Viele Unternehmen verlassen sich hier zu stark auf zwei Annahmen: „Der Anbieter wird das schon compliant liefern“ und „Wenn es Standardsoftware ist, ist es weniger kritisch“. Beide Annahmen können stimmen – sie können aber genauso gut in die falsche Richtung führen, weil der entscheidende Faktor nicht der Produktname ist, sondern der Einsatzkontext: Was beeinflusst die KI? Welche Entscheidungen werden dadurch geprägt? Welche Nutzergruppen sind betroffen? Wie stark verlassen sich Menschen faktisch auf die Ergebnisse? Und wie gut können Sie als Kunde Qualität, Änderungen und Störungen steuern?
Wenn man das Thema auf den Punkt bringt, ist Einkauf bei KI nicht nur „Preis und Vertrag“, sondern der Ort, an dem Sie vier zentrale Dinge absichern: Erstens, dass Sie überhaupt wissen, was Sie einkaufen (und welche KI-Funktionalität enthalten ist). Zweitens, dass Sie eine belastbare Informationsbasis bekommen, um intern korrekt zu klassifizieren und zu steuern. Drittens, dass Sie im Betrieb eine Handhabe haben, wenn der Anbieter ändert, liefert oder ausfällt. Und viertens, dass Sie im Prüf- oder Incident-Fall Nachweise liefern können, ohne alles aus E-Mails und Produktbroschüren zusammenzukratzen.
Die größte Herausforderung ist dabei nicht, dass Einkauf „keine Ahnung von KI“ hätte. Die Herausforderung ist, dass klassische Beschaffungsprozesse auf Funktionen, SLA und Datenschutz ausgerichtet sind – nicht auf Modelländerungen, Drift, Trainingsdatenherkunft, Transparenzanforderungen, oder die Frage, wie man eine KI-Funktion im Betrieb zuverlässig überwacht. Wenn Sie diese Punkte nicht in Ihren Beschaffungs- und Vendor-Standard integrieren, entsteht ein strukturelles Risiko: KI wächst im Portfolio schneller, als Governance hinterherkommt.
Was hilft, ist ein pragmatischer Rahmen, der KI-Beschaffung nicht kompliziert macht, sondern klarer. In vielen Unternehmen funktioniert das am besten, wenn man nicht versucht, jede Bestellung zu „KI-Spezialfall“ zu machen, sondern wenn man einen kurzen KI-Screening-Schritt voranstellt. Screening heißt: ein paar Fragen, die schnell klären, ob ein Produkt oder Service KI-Funktionen enthält, die für Governance relevant sind. Dabei reicht oft schon: Nutzt das Tool ein Modell, das Inhalte erzeugt, klassifiziert oder priorisiert? Werden Entscheidungen oder Prozesse beeinflusst? Werden personenbezogene oder sensitive Daten verarbeitet? Gibt es externe Modellservices oder Unterauftragnehmer? Und: Kann die KI-Funktion abgeschaltet oder begrenzt werden, ohne dass der Service komplett unbrauchbar wird? Wenn dieses Screening sauber ist, können Sie sehr früh entscheiden, ob ein normaler Beschaffungsweg reicht oder ob zusätzliche Anforderungen nötig sind.
Der zweite Hebel ist die saubere Verbindung zwischen Einkauf und interner Klassifizierung. Ein KI-Register kann nur so gut sein wie die Informationen, die hineinfließen. Und genau diese Informationen liegen bei Drittprodukten häufig beim Anbieter. Wenn Sie sie nicht gezielt abfragen und dokumentieren, wird Klassifizierung zur Schätzung. Das führt entweder zu zu niedriger Einstufung (Pflichten unterschätzt) oder zu zu hoher Einstufung (Governance wird zu schwer und wird umgangen). Beides ist schlecht. Deshalb ist es sinnvoll, dass Vendor Management für KI-relevante Produkte einen kompakten Informationssatz standardisiert: Was ist der Zweck der KI-Funktion? Welche Daten gehen hinein und hinaus (grob)? Welche Grenzen sind bekannt? Welche Qualitätsmechanismen gibt es? Welche Änderungsmechanismen gibt es (Release-Info, Modellwechsel, Versionierung)? Welche Support- und Eskalationswege existieren, wenn die KI Fehlverhalten zeigt oder ausfällt? Und: Wie kann man das Feature einschränken oder deaktivieren? Das sind keine akademischen Fragen, sondern Betriebshygiene.
Ein dritter Hebel ist die Vertrags- und Steuerungslogik. Viele Verträge sind hervorragend darin, Verfügbarkeit und allgemeine Supportpflichten zu regeln. Für KI reicht das häufig nicht, wenn der Einsatzkontext kritisch ist. Sie brauchen nicht zwangsläufig lange Spezialklauseln. Aber Sie brauchen Klarheit an den Stellen, die später entscheiden, ob Sie steuerungsfähig sind: Änderungsmitteilungen (wann und wie werden relevante Änderungen angekündigt), Transparenz über Subprozessoren und Abhängigkeiten, Support- und Eskalationsregeln für schwerwiegende Vorfälle, und eine realistische Daten- und Exit-Logik (Export, Deaktivierung, Ersatzprozess). In der Praxis ist „Exit“ oft nicht kurzfristig machbar – aber ein Minimalfallback ist fast immer machbar, wenn man ihn früh denkt.
Das führt zum Punkt, der im Alltag am meisten unterschätzt wird: Betrieb und Vendor-Steuerung. KI-Funktionen sind nicht statisch. Anbieter verändern Modelle, Parameter, Features, Sicherheitsmechanismen. Wenn Sie im Vendor-Management keinen Takt haben, um solche Änderungen zu erkennen und zu bewerten, dann sind Sie im Blindflug. Und Blindflug ist das Gegenteil dessen, was AI Governance leisten soll. Ein realistischer Takt muss nicht häufig sein, aber er muss für kritische Anbieter verlässlich sein: kurze Reviews, in denen Leistung, relevante Änderungen, bekannte Probleme, offene Maßnahmen und Risiken zusammenkommen. Der Vorteil ist, dass Sie dadurch nicht nur „compliant“ wirken, sondern tatsächlich schneller reagieren können, wenn etwas kippt.
Ein typisches Praxisbeispiel macht das greifbar. Eine Standardplattform integriert ein neues KI-Feature, das Inhalte generiert, die später an Kunden gehen. Anfangs wird es manuell geprüft, später „spart man Zeit“ und prüft weniger. Irgendwann ändert der Anbieter das Modell oder das Verhalten, die Tonalität kippt, es entstehen Fehler oder unangemessene Ausgaben. Wenn Sie dann keine klare Ownership, keinen Monitoring- und Incident-Weg und keine Anbieterkommunikation im Griff haben, wird das Thema schnell größer als nötig. Nicht, weil KI „gefährlich“ ist, sondern weil Steuerung fehlt. Und diese Steuerung beginnt nicht erst in der IT, sondern beim sauberen Set-up in Beschaffung und Vendor Management: Wer ist Owner, wie werden Änderungen erkannt, was ist der Fallback, wie wird eskaliert, und wo ist die Evidenz, dass man das sauber geführt hat?
In vielen Unternehmen lohnt es sich daher, Einkauf und Vendor Management nicht als „Zulieferer“ der AI Governance zu behandeln, sondern als gleichwertigen Steuerungsbaustein. Das bedeutet nicht, dass Einkauf plötzlich technische Prüfungen machen soll. Es bedeutet, dass Einkauf die richtigen Hebel bedient: Screening, Informationsbasis, Vertragsanker, Steuerungstakt. Wenn diese Hebel sauber sind, wird die Arbeit für Governance, Risk, IT und Compliance deutlich leichter. Wenn sie fehlen, müssen diese Funktionen später versuchen, über interne Prozesse etwas zu reparieren, was im Einkauf bereits verloren ging: Einfluss.
Ein weiterer Aspekt ist die interne Kommunikation. Viele Konflikte rund um KI entstehen, weil Teams KI als Produktivitätstool sehen und Governance als Bremse. Das ist ein Kulturproblem, aber es lässt sich pragmatisch entschärfen, wenn Beschaffung und Governance denselben Satz benutzen: „Wir ermöglichen Nutzung – aber mit klarer Verantwortung und klaren Grenzen.“ Wenn das als Standard im Vendor-Flow verankert ist, wirkt es nicht wie ein nachträglicher Eingriff, sondern wie ein normaler Qualitäts- und Risikoschritt. Und genau das ist entscheidend, damit KI nicht in Schattennutzung ausweicht.
Wenn Sie sich fragen, woran man erkennt, dass Vendor Management KI wirklich „im Griff“ hat, sind es oft sehr praktische Signale: Gibt es eine saubere Liste, welche Anbieter KI-Funktionen liefern? Ist klar, welche davon in kritischen Prozessen wirken? Können Sie bei einem Anbieterwechsel oder einem Modell-Update schnell sagen, welche internen Use Cases betroffen sind? Gibt es definierte Ansprechpartner und Eskalationswege? Können Sie im Audit oder gegenüber Kunden belegen, warum Sie eine Lösung so klassifiziert haben, welche Kontrollen greifen und wie Änderungen gesteuert werden? Wenn Sie diese Fragen mit wenig Suchaufwand beantworten können, ist Ihre Frontlinie stabil.
Der EU AI Act macht diese Frontlinie nicht optional. Selbst wenn Sie nicht direkt in einer „hoch riskanten“ Kategorie unterwegs sind, wächst die externe Erwartung: Kunden fragen, interne Revision fragt, und spätestens wenn ein Vorfall passiert, wird gefragt, wie Sie das Feature geführt haben. Wer dann nur mit Produktbroschüren und allgemeinen Vertragsklauseln antworten kann, verliert Zeit und Vertrauen. Wer dagegen zeigen kann, dass Beschaffung, Betrieb und Governance eine gemeinsame Spur erzeugen, wirkt reif – und ist in der Regel auch handlungsfähiger, wenn es wirklich zählt.
Am Ende ist das eine gute Nachricht: Sie müssen KI-Compliance nicht als neues Monsterprogramm aufbauen. Sie müssen nur sicherstellen, dass Beschaffung und Vendor Management nicht „blind“ KI ins Unternehmen holen. Wenn Screening, Informationsbasis, Vertragsanker und Steuerungstakt sitzen, skaliert AI Governance deutlich leichter. Und genau das ist die unterschätzte Realität: Die sauberste AI Governance entsteht nicht im Register – sie entsteht dort, wo Sie entscheiden, welche Technologie in Ihr Haus kommt und unter welchen Bedingungen sie betrieben werden darf.
| Hinweis: Teile dieses Beitrags könnten unter Einsatz von KI-gestützten Tools erstellt oder überarbeitet worden sein. Weitere Informationen finden Sie im Impressum/Disclaimer. | Marken- und Bildrechte: Dargestellte Logos und genannten Marken liegen ausschließlich bei den jeweiligen Rechteinhabern. Nutzung erfolgt ausschließlich zu illustrativen Zwecken. |
Wenn Sie den Blog-Beitrag abonnieren, senden wir Ihnen eine E-Mail, sobald es Updates auf dieser Website gibt.

Kommentare 48
Der Ansatz ist nachvollziehbar. Offen bleibt für mich, wie sich die Anforderung in einen belastbaren Arbeitsablauf übersetzen lässt. Wo würdet ihr mit der Prüfung beginnen?
Für mich wäre ein begrenzter Anwendungsfall der beste Einstieg. Dann sieht man relativ schnell, ob die Information tatsächlich zu einer anderen Priorität oder Entscheidung führt.
Für mich gehört noch ein fester Zeitpunkt zur Nachprüfung dazu. Erst dann lässt sich beurteilen, ob die Maßnahme nur erledigt wurde oder tatsächlich etwas verbessert hat.
Ich würde ebenfalls mit einem konkreten Fall starten. Wichtig sind dabei eine eindeutige Zuständigkeit, ein überprüfbares Ergebnis und ein Termin, an dem die Wirkung erneut bewertet wird.
Damit wird es für mich deutlich greifbarer. Vor allem die vorher festgelegte Entscheidungsfolge verhindert, dass der Pilot nur als zusätzlicher Bericht endet.
Den Punkt würde ich gern vertiefen. Wo würdest du bei der Zusammenarbeit mit externen Dienstleistern zuerst genauer hinschauen?
Bei kritischen Leistungen und klaren Übergabepunkten. Gerade dort sollte nachvollziehbar sein, wer im Störungsfall welche Aufgabe übernimmt.
Wer entscheidet, welches Restrisiko akzeptiert wird, und wie lange gilt diese Entscheidung? Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Welche minimale Lösung wäre für Prüfung der Nachweise des Anbieters vertretbar, wenn unter Zeitdruck eine Ausnahme erforderlich wird?
Ich würde die Ausnahme befristen und mit einem benannten Verantwortlichen sowie einer späteren Überprüfung verbinden. Entscheidend wäre für mich, ob das Ergebnis für den konkreten Fall nachprüfbar bleibt. Bei Prüfung der Nachweise des Anbieters sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Wie verhindert man, dass eine Lieferantenprüfung nur aus ausgefüllten Fragebögen besteht?
Ich würde die Antworten an den tatsächlich bezogenen Leistungen prüfen. Bei kritischen Abhängigkeiten müsste auch klar sein, was im Störungsfall konkret passiert. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Den Nutzen sehe ich. Trotzdem würde ich vermeiden, jede Ausnahme sofort mit einer weiteren Richtlinie zu beantworten.
Ich würde die Ausnahme nicht verstecken, sondern mit Begründung, zuständiger Person und Prüfanlass festhalten. Dann kann man auch später erkennen, ob die Grundlage noch gilt. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Das wäre für mich ein sinnvoller Einstieg. Wichtig wäre dann, den ersten Fall auch wirklich auszuwerten und nicht nur abzuschließen. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Wie prüft man Konzentrationsrisiken, wenn verschiedene Lieferanten dieselbe technische Basis verwenden? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Das ist ein wichtiger Punkt. Dann würde ich die gemeinsame Abhängigkeit gesondert betrachten. Verschiedene Vertragspartner bedeuten für mich nicht automatisch voneinander unabhängige Leistungen. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Könnte diese Lösung nicht gerade bei kleinen Teams zu viel Aufwand verursachen? Ich würde die Mindestanforderung deutlicher abgrenzen. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Dazu eine Rückfrage: Wie werden Unterauftragnehmer berücksichtigt, wenn man nur den direkten Vertragspartner kennt? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Mein Vorschlag wäre: Ich würde die Informationsgrenzen offenlegen und gezielt nach wesentlichen Abhängigkeiten fragen. Eine vollständige Übersicht zu behaupten wäre mir ohne belastbare Grundlage zu viel. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Ich finde den Ansatz plausibel, aber noch sehr grundsätzlich. An welchem konkreten Entscheidungspunkt würde er einen Unterschied machen? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Wie verhindert ihr bei Prüfung der Nachweise des Anbieters, dass eine vorläufige Lösung ohne erneute Prüfung dauerhaft bestehen bleibt?
Ich würde einen festen Wiedervorlagetermin und eine klare Entscheidung über Fortführung oder Abschluss vorsehen. Wichtig ist, dass die Ausnahme nicht allein deshalb bestehen bleibt, weil niemand mehr nachfragt. Mit Blick auf Prüfung der Nachweise des Anbieters würde ich den Umfang der Prüfung bewusst auf diese Entscheidung begrenzen.
Wann wäre bei Priorisierung kritischer Dienstleister eine erneute Entscheidung sinnvoller als die bloße Fortschreibung eines Status?
Eine neue Entscheidung wäre für mich erforderlich, wenn Grenzen oder tragende Annahmen nicht mehr passen. Eine Statusmeldung allein erklärt noch nicht, wie die Veränderung bewertet wurde. Für Priorisierung kritischer Dienstleister würde ich den ersten Prüfschritt bewusst klein halten.
Ein weiterer Punkt: Wie bleibt eine partnerschaftliche Zusammenarbeit möglich, wenn immer mehr Nachweise verlangt werden? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Das ist ein wichtiger Punkt. Ich würde die Anforderungen begründen und nach ihrer Bedeutung priorisieren. Ungezielte Zusatzfragen kosten auf beiden Seiten Zeit, ohne die Abhängigkeit unbedingt besser zu erklären. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Ich lese das etwas anders. Für mich steht zuerst die Frage im Raum, ob der zugrunde liegende Bedarf überhaupt ausreichend geklärt ist. Meine Ausgangsfrage bleibt: Wie bleibt eine partnerschaftliche Zusammenarbeit möglich, wenn immer mehr Nachweise verlangt werden?
Ich würde das Ergebnis vorher festlegen: Was soll danach klarer, schneller oder belastbarer sein? Ohne diesen Bezug ist der Erfolg einer Änderung schwer zu beurteilen. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Ein weiterer Punkt: Was bleibt in der eigenen Verantwortung, obwohl ein Dienstleister die Technik betreibt? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Das ist ein wichtiger Punkt. Für mich müssten Zuständigkeiten und Übergaben sichtbar sein. Ein vertraglich zugeordnetes Thema ist erst dann praktikabel, wenn auch der tatsächliche Ablauf dazu passt. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Mir wäre die laufende Pflege wichtiger als die perfekte erste Fassung. Wie könnte man das mit überschaubarem Aufwand organisieren? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Die Grenze sehe ich dort, wo zusätzlicher Aufwand keine bessere Entscheidung mehr unterstützt. Das müsste man an einem konkreten Fall prüfen und nicht pauschal behaupten. Auf die Ausgangsfrage bezogen: Für mich müssten Zuständigkeiten und Übergaben sichtbar sein. Ein vertraglich zugeordnetes Thema ist erst dann praktikabel, wenn auch der tatsächliche Ablauf dazu passt.
Ich bleibe beim Aufwand etwas skeptisch. Eine kleine, überprüfbare Lösung könnte hier zunächst mehr bringen als ein umfassendes Konzept. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Könnte diese Lösung nicht gerade bei kleinen Teams zu viel Aufwand verursachen? Ich würde die Mindestanforderung deutlicher abgrenzen. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Ein weiterer Punkt: Was macht einen Ausstiegsplan brauchbar, bevor der Anbieter tatsächlich ausfällt? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Mein Vorschlag wäre: Für mich wären die notwendigen Daten, Ressourcen und Übergaben entscheidend. Der Plan müsste eine realistische Weiterarbeit beschreiben, nicht nur die Kündigung des Vertrags. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Den Nutzen sehe ich. Trotzdem würde ich vermeiden, jede Ausnahme sofort mit einer weiteren Richtlinie zu beantworten. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Wie verhindert man, dass integrierte Governance nur mehrere Register auf derselben Plattform bedeutet? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Für mich liegt der Schwerpunkt hier: Ich würde auf gemeinsame Entscheidungen und klare Zuständigkeiten schauen. Ein gemeinsames Werkzeug allein verbindet die Arbeitsweisen noch nicht. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Der Grundgedanke passt für mich. Trotzdem: Wie verhindert man, dass die Verantwortung zwischen mehreren Beteiligten hängen bleibt? Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Ein vorhandener Nachweis wäre für mich zunächst nur ein Hinweis. Seine Aussagekraft hängt davon ab, ob er wirklich den betrachteten Ablauf und Zeitraum abdeckt. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Dazu eine Rückfrage: Was wäre ein sinnvoller Umgang mit Risiken, die sich nur schlecht messen lassen? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Für mich liegt der Schwerpunkt hier: Ich würde Annahmen dokumentieren und verschiedene Szenarien vergleichen. Die fehlende präzise Messung wäre für mich kein Grund, das Thema aus der Entscheidung auszublenden. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Wie würdet ihr praktische Umsetzbarkeit einer Exitstrategie konkret prüfen, wenn verschiedene Systeme dieselbe Information unterschiedlich abbilden?
Mein Vorschlag wäre, eine maßgebliche Quelle bestimmen und Abweichungen gezielt untersuchen, bevor Kennzahlen daraus abgeleitet werden. Anschließend sollte klar sein, wer die Wirkung prüft und wann erneut entschieden wird. Bei praktische Umsetzbarkeit einer Exitstrategie sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Bei laufende Steuerung kritischer Dienstleister scheint mir die zeitliche Perspektive wichtig. Eine einmalige Prüfung sagt wenig darüber aus, ob die Lösung dauerhaft funktioniert.
Mich überzeugt besonders der Bezug zu laufende Steuerung kritischer Dienstleister. Ein konkreter Anwendungsfall könnte zeigen, wo der Ansatz noch zu abstrakt bleibt.