Wie man die TPRM-Architektur im Hinblick auf agentenbasierte, Laufzeit- und KI-Abhängigkeitsrisiken neu überdenken kann
Beim Drittanbieter-Risikomanagement (TPRM) ging es schon immer darum, die wichtigsten Lieferanten zu identifizieren, deren Zugriffsrechte zu verstehen und das eigene Unternehmen vor Sicherheitslücken, Ausfallzeiten und Störungen zu schützen, die bei einem Ausfall entstehen können. Ein Due-Diligence-Modell auf Lieferantenseite, entwickelt für eine Welt, in der das Drittanbieterrisiko weitgehend statisch war. Im Zeitalter der KI-gestützten Risikobewertung ist dieses Modell nicht mehr ausreichend . Drei Dinge haben sich geändert:
Künstliche Intelligenz erweitert die Angriffsfläche für Drittanbieterrisiken, schafft ein Umfeld für Zero-Day-Exploits und erschwert die Erkennung von Anbieterkonzentrationen. Die meisten TPRM-Programme wurden nicht für diese drei Faktoren konzipiert.
Die traditionelle TPRM-Architektur vernachlässigt komplexe Abhängigkeiten, regulatorische Zugangsprobleme und Ausstiegsschwierigkeiten – Risiken, die in einem Fragebogen nicht sichtbar sind.
Die Laufzeitüberwachung muss Teil der TPRM-Architektur werden, um nicht übereinstimmende Aktionen, Datenumleitungen und verdächtige Speicherschreibvorgänge zu erkennen.
Veränderung Nr. 1: Die Integration von KI erweitert die Risikofläche über KI-native Anbieter hinaus.
Produktivitätsplattformen, HR-Systeme, Finanztools und Cybersicherheitsprodukte erben durch die integrierten KI-Schichten Laufzeitrisiken. Die überwachte Oberfläche ist unbemerkt gewachsen, ohne dass die meisten Programme entsprechend angepasst wurden.
Hier ist ein Streudiagramm, das diese Verschiebung visuell veranschaulicht:
Quelle: Anbieterkategorielandschaft, 2026
Beachten Sie, dass die Mehrheit der gängigen Tools ein erhöhtes bis hohes Laufzeitrisiko aufweist und daher Laufzeitkontrollen benötigt, um sicherzustellen, dass sie wie vorgesehen funktionieren.
Änderung Nr. 2: KI hat eine Zero-Day-Exploit-Umgebung geschaffen, für die die TPRM-Architektur nie ausgelegt war.
Wenn ein Modell Schwachstellen in veralteten Bankensystemen oder kritischer Infrastruktur in großem Umfang aufdecken kann, wird diese Fähigkeit selbst zu einem systemischen Risiko – unabhängig davon, wem sie gehört, wer sie reguliert oder was Ihre Verträge beinhalten. Die Mythos-Modelle von Anthropic und ähnliche, in verschiedenen Laboren entwickelte Spitzentechnologien veranschaulichen genau dies. Regierungen reagieren bereits mit Exportkontrollen, Zugangsbeschränkungen und nationalen Sicherheitsanordnungen, die schneller umgesetzt werden, als es jeder Anbietervertrag hätte vorhersehen können. Das Risiko besteht nicht nur darin, was Ihre Anbieter mit KI machen. Es besteht darin, was KI in den falschen Händen ermöglicht und ob Ihr Programm nachweisen kann, dass es dieses Risiko minimiert.
Änderung Nr. 3: Das Konzentrationsrisiko bei KI-Anbietern nimmt zu und wird immer schwieriger zu erkennen.
Mehrere unterschiedliche Tools in Ihrem Stack können auf demselben zugrunde liegenden Modellanbieter, in derselben Cloud-Region oder auf derselben API-Ebene basieren. Wird diese gemeinsame Ebene durch eine Abschaffung, eine regulatorische Entscheidung oder eine Regierungsanordnung beeinträchtigt, beschränkt sich der Wirkungsbereich nicht auf einen einzelnen Anbieter. Betroffen sind alle darauf aufbauenden Workflows. Die Entwicklung von Mythos liefert hierfür ein klassisches Beispiel. Als Anthropic im Juni 2026 aufgrund einer Anordnung der US-Regierung, die Bedenken hinsichtlich der nationalen Sicherheit äußerte, seine Modelle Fable 5 und Mythos 5 abrupt deaktivierte, verloren alle Unternehmen, die kritische Workflows auf diesen Funktionen aufgebaut hatten, über Nacht den Zugriff. Dem Anbieter ging es gut. Das Produkt funktionierte weiterhin. Doch der Zugriff war dennoch weg.
Dieser Blogbeitrag behandelt, was modernes TPRM berücksichtigen muss, um auf diese drei Veränderungen zu reagieren :
🛡️ Drei Abhängigkeitsrisiken, die Sie vor Ihrem nächsten Verlängerungszyklus analysieren sollten, und
🛡️ Drei Laufzeitsignale, auf die Ihr Monitoring bereits achten sollte.
| Risiko | TPRM-Feld | Eigentümer | Beweisbar |
| Gestapelte Abhängigkeit | Zuordnung von Drittanbietern; Dokumentation von Abhängigkeitsketten | GRC / Sicherheit | Abhängigkeitsdiagramm der Anbieter, das die zugrunde liegenden Modellanbieter, Cloud-Regionen und API-Schichten darstellt; wird bei jeder Verlängerung aktualisiert |
| Schock beim Zugang zu Regulierungsbehörden | Register der regulatorischen Risiken; geografische und rechtliche Zugriffskennzeichen | GRC / Recht | Dokumentierte Bewertung des regulatorischen Zugangsrisikos nach Anbieter, Region und Anwendungsfall; Überprüfung bei geopolitischen oder regulatorischen Änderungen |
| Ausstiegszug | Machbarkeitsanalyse für den Ausstieg; Bewertung der Lieferantenbindung | GRC / Beschaffung | Die Austrittsbewertung wird bei jeder Verlängerung durchgeführt; sie dokumentiert die Wechselkosten, die Abhängigkeit vom Arbeitsablauf und den Wiederherstellungszeitraum. |
| Nicht übereinstimmende Aktionen | Aktionsprotokolle des KI-Agenten; Überwachung des Aufgabenumfangs | Sicherheit | Protokollierte Aktionsverläufe den ursprünglichen Benutzeranfragen zugeordnet; gekennzeichnete Ausnahmen mit Lösungsdatensätzen |
| Datenumleitung | Ausgabeprüfprotokolle; DLP-Überwachung für KI-generierte Inhalte | Sicherheit / GRC | Nachweise dafür, dass KI-Ausgaben auf Kanalebene und nicht nur im Speicher geprüft werden; gekennzeichnete Anomalien mit dokumentierter Überprüfung |
| Misstrauisches Gedächtnis schreibt | Speicherüberwachungsprotokolle; Schreibüberwachung nach der Aufnahme nicht vertrauenswürdiger Inhalte | Sicherheit | Speicherschreibprotokolle mit Zeitstempel; Nachweis der Überprüfung nach der Verarbeitung nicht vertrauenswürdiger Daten durch den Agenten; markierte Änderungen mit dokumentierter Behandlung |
Welcher KI-Anbieter? Abhängigkeitsrisiken Sollte Ihre TPRM-Architektur dies abmildern?
- Gestapelte Abhängigkeit
Ein Anbieter ist heutzutage selten nur eine einzige Abhängigkeit. Ihr Anbieter kann auf einem Modellanbieter, einer Cloud-Region, einer Vektordatenbank, einem Zahlungssystem, einer Identitätsschicht oder einem API-Anbieter basieren, den Sie nie direkt geprüft haben. Das Risiko von KI-Abhängigkeiten besteht darin, dass mehrere Tools, die Sie als separate Abhängigkeiten behandeln (einige wurden sogar als Redundanz oder Backup angeschafft), möglicherweise dieselbe zugrunde liegende Schicht oder dasselbe Basismodell nutzen, von dem Sie nichts wissen und das Sie nicht kontrollieren. Wenn drei geschäftskritische Workflows über denselben Modellanbieter laufen, verteilt sich Ihr Konzentrationsrisiko nicht auf drei Anbieter, sondern ist unter ihnen konzentriert. Und wenn sich diese Schicht ändert, gedrosselt, als veraltet markiert oder abgeschaltet wird, bricht der Workflow zusammen, unabhängig von den Vertragsbedingungen.
Die gesamte Abhängigkeit der KI-Lieferkette abbilden, nicht nur den Namen des Anbieters im Vertrag und nicht nur die Anwendung, die der KI-Funktion vorausgeht.
- Schock beim Zugang zu Regulierungsbehörden
Ausfälle von KI-basierten Drittanbietern können durch Regeländerungen, Exportkontrollrichtlinien, Sanktionsentscheidungen, Datentransferbeschränkungen oder Regierungsanordnungen ausgelöst werden. Der Anbieter mag weiterhin sicher sein. Das Produkt mag weiterhin funktionieren. Der Zugriff ist jedoch möglicherweise nicht mehr für dieselben Nutzer, Regionen, Anwendungsfälle oder Datenflüsse möglich.
Mitte Juni deaktivierte Anthropic abrupt seine Modelle Fable 5 und Mythos 5 aufgrund einer Anordnung der US-Regierung, die Bedenken hinsichtlich der nationalen Sicherheit äußerte. Unternehmen, die kritische Arbeitsabläufe auf diesen Funktionen aufgebaut hatten, verloren über Nacht den Zugriff – ohne vertragliche Ansprüche und ohne Vorwarnung. Dem Anbieter ging es gut. Das Produkt funktionierte. Der Zugriff war einfach weg.
Erfassung von Fällen, in denen der Zugriff von Anbietern von Geografie, Nationalität, Datenstandort oder regulatorischen Rahmenbedingungen abhängt.
- Ausstiegszug
Eine Geschäftsbeziehung wird schwieriger zu steuern, wenn ein Wechsel aufgrund der Abhängigkeit von einem Anbieter unrealistisch wird. Das Risiko steigt durch Integrationen, Workflows, Datenformate, Eingabeaufforderungen und Benutzergewohnheiten. Sobald die Beziehung unangenehm wird, kann ein Wechsel eine grundlegende Prozessüberarbeitung erfordern, nicht nur den Austausch des Tools. Wenn ein Risikobewertungs-Workflow auf der Logik, den Feldern und Automatisierungen eines einzigen Anbieters basiert, wird der Wechsel von einer Beschaffungsaufgabe zu einer operativen Umstellung. Dies kann genau die Workflows stören, für deren Unterstützung die Anbieterbeziehung aufgebaut wurde, Quartale zur Stabilisierung benötigen und letztendlich deutlich höhere operative Kosten verursachen als budgetiert.
Das Risiko und die Machbarkeit eines Lieferantenwechsels sollten vor der Aufnahme des Geschäfts und bei jeder Vertragsverlängerung beurteilt werden, nicht erst, wenn die Geschäftsbeziehung bereits zu gefestigt ist.
Welcher KI-Anbieter? Laufzeitrisiken Sollte die TPRM-Architektur die Nachverfolgung übernehmen?
- Nicht übereinstimmende Aktionen
Agentenbasierte KI und KI-gestützte Systeme sind zwar nicht deterministisch, doch jede Aktionskette sollte im Hinblick auf eine gegebene Aufgabe sinnvoll sein. Beispielsweise kann ein kompromittierter Agent scheinbar normale Aufgaben erledigen: lesen, zusammenfassen, Tools aufrufen, Entwürfe erstellen und Datensätze aktualisieren.
Entscheidend ist jedoch, ob die Aktionen des Systems – einschließlich der verwendeten Tools – für die jeweilige Aufgabe logisch sind. Wenn ein Supportmitarbeiter, der eine Beschwerde zusammenfassen soll, beispielsweise fremde Kontodaten abruft, Gehaltsabrechnungs- oder Abrechnungs-APIs aufruft oder eine ausgehende Nachricht vorbereitet, liegt ein Verstoß gegen den Aufgabenbereich vor, der sofort gemeldet werden muss. Dies ist ein klares Zeichen dafür, dass der Mitarbeiter kompromittiert wurde, und jede Sekunde, die er unkontrolliert im Einsatz ist, vergrößert das Risiko. Handelt es sich bei den verwendeten Tools um Zugangsdaten, Token oder Produktionsschlüssel, sind die Folgen unmittelbar, weitreichend und unter Umständen irreversibel.
Ordnen Sie jede KI-Aktion der ursprünglichen Anfrage zu und kennzeichnen Sie alles, was außerhalb des Aufgabenbereichs liegt. Automatisch, nicht bei der Überprüfung.
- Datenumleitung
Ein weiterer Aspekt in Bezug auf das von uns diskutierte kontextbezogene Verhalten: Wenn ein KI-System beteiligt ist, kann die Datenexfiltration intelligent so gestaltet werden, dass sie völlig normal aussieht, indem generierte Links, Zusammenfassungen, E-Mail-Entwürfe, Support-Antworten, Dokumenttexte, API-Parameter oder Anhänge verwendet werden.
Wenn jedoch ein KI-Assistent private Kundendatensätze liest und Kontodaten in eine generierte Nachricht oder URL einbettet, kann der Kanal legitim erscheinen, während der Inhalt es nicht ist, wodurch Kontrollen, die nicht speziell für die Erkennung solcher Inhalte entwickelt wurden, leicht umgangen werden.
Laufzeitkontrollen, die überprüfen, was das System erzeugt und wohin es es sendet, nicht nur, wo die Daten gespeichert sind und wer Zugriff darauf hat.
- Misstrauisches Gedächtnis schreibt
Persistenter Speicher sorgt dafür, dass Laufzeitrisiken über eine einzelne Sitzung hinaus bestehen bleiben. Eine fehlerhafte Anweisung, eine verfälschte Zusammenfassung oder eine falsche Präferenz können gespeichert werden und das zukünftige Verhalten unbemerkt beeinflussen.
Das zu beachtende Signal ist die Aktualisierung des Speichers, nachdem der Agent nicht vertrauenswürdige Daten wie hochgeladene Dateien, eingehende E-Mails, Support-Tickets, Webseiten oder Chat-Nachrichten verarbeitet hat. Wenn ein Mitarbeiter im Lieferantenrisikomanagement ein Lieferantendokument liest und eine neue Einstellung speichert, die die Weiterleitung zukünftiger Prüfungen beeinflusst, mag dies in der aktuellen Sitzung zwar keine Probleme verursachen, jedoch in jeder nachfolgenden.
Der Nachweis, dass Speicherschreibvorgänge protokolliert, überprüfbar und auf Änderungen überwacht werden, die nach der Verarbeitung nicht vertrauenswürdiger Inhalte durch das System vorgenommen wurden.
Sie sind sich nicht sicher, welche dieser Risiken Ihre aktuelle Architektur nicht berücksichtigt?
Führen Sie das unten stehende dreißigtägige Audit durch, bevor Sie mit dem Wiederaufbau beginnen. Es zeigt Ihnen genau, wo Ihr Programm nicht hinkommt, wer einbezogen werden muss und was zuerst behoben werden sollte:
30-tägige TPRM-Architekturprüfung
Dies ist keine Einzelaufgabe. Die in diesem Blog beschriebenen KI-Drittanbieterrisiken sind fast immer funktionsübergreifend: Sicherheitsinstrumente, GRC-Interpretation und -Dokumentation, Beschaffungsvorgänge bei Vertragsverlängerungen und rechtliche Hinweise auf Zuständigkeitsrisiken. In den 30 Tagen geht es darum, diese Funktionen auf ein gemeinsames Verständnis der Bereiche auszurichten, die Ihre aktuelle Architektur nicht abdeckt.
Woche 1: Zusammenkunft und Abgrenzung
Wer: Sicherheit, GRC, Beschaffung, Recht
Aktionspunkte:
- Eine einzige funktionsübergreifende Sitzung einberufen
- Stellen Sie sich eine Frage: Verfügen Sie für Ihre wichtigsten KI-gestützten Lieferantenbeziehungen über Abhängigkeitsdiagramme, Laufzeitprotokolle und Abschlussbewertungen, die Sie heute auf Anfrage erstellen könnten?
- Dokumentieren Sie jede auftretende Lücke.
- Weisen Sie jedem Gap vor Sitzungsende einen benannten Verantwortlichen zu.
Gewünschte Ausgabe: Priorisierte Lückenliste mit benannten Verantwortlichen
Woche 2: Sprint zur Abhängigkeitsanalyse
Wer: Sicherheit, GRC
Aktionspunkte:
- Ermitteln Sie Ihre zehn wichtigsten KI-Anbieterbeziehungen nach Kritikalität
- Dokumentieren Sie für jeden Anbieter den Modellanbieter, die Cloud-Region, die API-Abhängigkeiten und die Subprozessoren.
- Kennzeichnen Sie alle Workflows, die dieselbe zugrunde liegende Schicht verwenden.
- Tragen Sie die Ergebnisse in ein gemeinsames Register ein.
Gewünschtes Ergebnis: Konzentrationsrisikoregister. Dies sollte ein dynamisches Dokument sein, keine einmalige Angelegenheit.
Woche 3: Laufzeit-Transparenzprüfung
Wer: Sicherheit (Leitung), GRC (Überprüfung)
Aktionspunkte:
- Prüfen Sie, welche Protokollierungs- und Überwachungsmechanismen derzeit für das Verhalten von KI-Agenten in Ihrer Umgebung vorhanden sind.
- Ordnen Sie jede Lücke als Werkzeuglücke, Konfigurationslücke oder Prozesslücke ein.
- Planen Sie Werkzeugkostenlücken in Ihren nächsten Budgetzyklus ein.
- Weisen Sie jedem Konfigurations- und Prozessdefizit vor Ende der Woche einen Verantwortlichen für die Behebung und einen Zeitplan zu.
- GRC prüft die Ergebnisse und legt fest, welche Dokumentations- und Protokollierungsstandards für jede festgestellte Lücke gelten.
Gewünschte Ausgabe: Bericht über die Lücken in der Laufzeit-Transparenz mit Verantwortlichen und Zeitachsen
Woche 4: Abschluss und Überprüfung der Ergebnisse
Wer: Beschaffung, GRC
Aktionspunkte:
- Identifizieren Sie Ihre drei wichtigsten KI-Anbieter mit bevorstehenden Verlängerungszeiträumen
- Führen Sie für jeden einzelnen eine Machbarkeitsanalyse für den Ausstieg durch.
- Stellen Sie alle aktuell vorhandenen Nachweise zusammen, die die Kontrolle über Ihre Beziehungen zu KI-Anbietern belegen.
- Vergessen Sie nicht zu dokumentieren, welche Nachweise Sie nicht erbringen können, damit Sie Ihre Prioritätenliste für den nächsten Prüfzyklus haben.
Gewünschtes Ergebnis: Abschlussbeurteilungen und Nachweise
Wie man eine TPRM-Architektur zur Minderung von KI-Risiken aufbaut
Die sechs in diesem Blog behandelten Risiken stellen Lücken in Ihrer TPRM-Architektur dar. Ein Programm, das auf regelmäßigen Überprüfungen, Fragebogen-basierter Sorgfaltsprüfung und Überwachung auf Vertragsebene beruhte, war einst sinnvoll, doch es fehlt ihm ein struktureller Mechanismus zur Erkennung heutiger Risiken wie etwa gestapelter Abhängigkeiten, Laufzeitkontrollfehlern oder regulatorischen Zugriffsproblemen.
Eine TPRM-Architektur, die diese Risiken erkennen kann, erfüllt drei strukturelle Anforderungen, die traditionellen Programmen fehlen: 1) kontinuierliche Erkennung statt geplanter Datenerfassung, 2) Transparenz in Echtzeit statt punktueller Bewertung und 3) evidenzbasierter Abschluss statt reiner Fragebogenerhebung und retrospektiver Datenerfassung. Im Folgenden wird erläutert, wie sich diese drei strukturellen Unterschiede in der Praxis auf einer Plattform wie Sprinto auswirken.
Zu den drei Abhängigkeitsrisiken
- Sprinto erkennt Anbieter, sobald sie in Ihre Umgebung eingebunden werden, nicht erst, wenn sich jemand daran erinnert (oder die Zeit findet), sie hinzuzufügen.
- Sprinto bildet Abhängigkeitsketten hinter dem Vertrag ab, nicht nur den Anwendungsnamen.
- Sprinto dokumentiert, kennzeichnet und validiert Konzentrationsrisiken, sodass gemeinsame zugrundeliegende Ebenen sichtbar und nachvollziehbar sind.
- Sprinto prüft die Ausstiegsmöglichkeit, die Auswahlkriterien und die Risikominderungspläne vor der Vertragsverlängerung, nicht danach.
Bei den drei Laufzeitsignalen
- Sprinto berechnet das Lieferantenrisiko anhand von Echtzeitsignalen neu, nicht anhand der Momentaufnahme des letzten Quartals.
- Sprinto erkennt und protokolliert automatisch die Einführung von Schatten-KI.
- Sprinto verfolgt kontinuierlich Laufzeitabhängigkeiten – Konfigurationen, Integrationen, Nutzungsmuster.
- Wenn sich etwas ändert, löst Sprinto die richtige Überprüfung aus, weist Verantwortliche zu und verfolgt den Vorgang bis zum bestätigten Abschluss.
Modernes TPRM benötigt einen geschlossenen Regelkreis: Abhängigkeitsketten müssen abgebildet, Laufzeitsignale überwacht, Risiken bei Veränderungen neu berechnet und Beweise gesichert werden, um die Aufsicht im Ernstfall nachvollziehbar zu machen. TPRM-Teams, die ihre Architektur für KI-Anbieter- und Drittanbieterrisiken neu gestalten, verfolgen ein klares Ziel: Da Zero-Day-Exploits allgegenwärtig sind, muss die neue Architektur das TPRM-Programm von einer reinen Anbieterprüfung hin zu einer kontinuierlichen Validierung der Gefährdungslage weiterentwickeln.
Häufig gestellte Fragen
Beginnen Sie mit Ihren wichtigsten KI-gestützten Workflows und erstellen Sie eine rückwärtsgerichtete Abhängigkeitsanalyse. Fragen Sie sich für jeden Workflow: Welcher Anbieter stellt die Technologie bereit? Wovon ist dieser Anbieter abhängig? Und was passiert, wenn der Zugriff über Nacht wegfällt? Allein diese Abhängigkeitsanalyse deckt Ihre dringendsten Schwachstellen auf, ohne dass eine komplette Programmüberarbeitung erforderlich ist. Priorisieren Sie die Workflows, bei denen eine Störung sofort und sichtbar wäre. Denken Sie an kundenorientierte Prozesse, automatisierte Entscheidungsfindung und alles, was sensible Daten verarbeitet. Optimieren Sie die Architektur dort zuerst und erweitern Sie sie anschließend.
In den meisten Organisationen hat heute niemand die alleinige Verantwortung dafür, was Teil des Problems ist. Der Einkauf ist für den Vertrag zuständig, GRC für die Bewertung, die IT-Sicherheit für die Tools. Doch das Laufzeitverhalten fällt in die Lücke zwischen diesen drei Bereichen. Die praktische Lösung: Die IT-Sicherheit muss es instrumentieren, GRC muss es interpretieren und die Nachweise sichern, und der Einkauf muss es bei Vertragsverlängerungen berücksichtigen. Wenn man darauf wartet, dass ein Team die gesamte Verantwortung übernimmt, wird das lange dauern. Definieren Sie stattdessen klare Übergabepunkte.
Prüfer und Aufsichtsbehörden fragen zunehmend nicht nur, ob Sie einen Lieferanten bewertet haben, sondern auch, ob Sie die kontinuierliche Transparenz sichergestellt haben. Zu den Nachweisen, die diese Frage beantworten, gehören: protokollierte Aufrufverläufe von KI-Agenten, Audit-Trails der Speicherschreibvorgänge, Abhängigkeitsdiagramme, die die Ebenen Ihrer Vertragslieferanten aufzeigen, dokumentierte Abschlussbewertungen bei Vertragsverlängerungen sowie Aufzeichnungen, die belegen, dass Konzentrationsrisiken identifiziert, geprüft und entweder gemindert oder formell akzeptiert wurden. Können Sie diese Nachweise auf Anfrage nicht vorlegen, existiert Ihre Governance zwar auf dem Papier, aber nicht in der Praxis.
Fragen Sie zunächst jeden KI-Anbieter in Ihrer Technologieinfrastruktur, welche Modellanbieter, Cloud-Regionen und API-Abhängigkeiten seinem Produkt zugrunde liegen. Die meisten werden Ihnen diese Information auf direkte Nachfrage geben. Vergleichen Sie anschließend die Antworten mit denen Ihrer anderen Anbieter und suchen Sie nach Mustern. Wenn drei Tools alle vom selben Modellanbieter oder derselben Cloud-Region abhängen, besteht ein Konzentrationsrisiko, unabhängig davon, wie viele verschiedene Verträge Sie mit Anbietern abgeschlossen haben. Ziel ist eine Abhängigkeitsübersicht, die die tatsächliche Architektur Ihrer Anbieterbeziehungen aufzeigt und nicht nur die Namen in Ihren Verträgen.
Bei jeder Vertragsverlängerung, ausnahmslos. Die Möglichkeiten eines Ausstiegs ändern sich mit zunehmender Integration, der Anpassung von Arbeitsabläufen an anbieterspezifische Logik und der Entwicklung von Nutzergewohnheiten. Ein Anbieter, der vor 18 Monaten noch problemlos zu ersetzen war, kann heute fest in die bestehende Infrastruktur integriert sein. Die Neubewertung muss nicht langwierig sein. Sie muss lediglich eine Frage ehrlich beantworten: Wenn wir diesen Anbieter in 90 Tagen verlassen müssten, welche Probleme würden auftreten und welche Kosten würden die Behebung verursachen? Sollte die Antwort unangenehm sein, müssen diese Informationen in Ihre Entscheidung zur Vertragsverlängerung einfließen.
Die effektivste Herangehensweise ist nicht technischer, sondern operativer Natur. Erläutern Sie zunächst, wie das traditionelle Lieferantenrisikomanagement einem natürlichen Überprüfungsrhythmus folgt: Bewertung bei der Aufnahme des Kunden, jährliche Neubewertung und Kennzeichnung von Ausnahmen, sobald diese auftreten. Die Kosten dieses Modells sind vorhersehbar und seit Jahren in den meisten GRC-Budgets enthalten.
Stellen Sie dann den Kontrast her. Erklären Sie, dass das Risiko von KI-Anbietern keinen natürlichen Ruhezustand kennt. Die Gefährdung ändert sich zwischen den Überprüfungen, da Modelle aktualisiert, Integrationen vertieft und Agenten umfassendere Zugriffsrechte erhalten. Das bedeutet, dass die Überwachung kontinuierlich und nicht periodisch erfolgen muss. Kontinuierliche Überwachung erfordert Tools, Interpretation und dokumentierte Nachweise, die bei periodischen Überprüfungen nicht erforderlich sind.
– Bei Budgetgesprächen besteht die konkrete Forderung aus drei Punkten: Tools für die Laufzeittransparenz, die es bisher in Ihrem System nicht gab; GRC-Kapazitäten zur Interpretation von Signalen und zur Sicherung von revisionssicheren Nachweisen; und schnellere Prüfzyklen, die bei gleichem Personalaufwand mehr Stunden in Anspruch nehmen.
Für Vorstände und Führungskräfte steht die Frage der Haftung und der Verteidigung im Vordergrund. Verursacht ein KI-System einen Datenvorfall und Ihr Programm verfügt über keine Aufzeichnungen zur Laufzeitüberwachung, können Sie nicht nachweisen, dass Sie das Risiko angemessen gesteuert haben. Genau diese Lücke suchen Aufsichtsbehörden und Wirtschaftsprüfer zunehmend.
– Für die Akteure im Beschaffungswesen ist der Rahmen die Hebelwirkung bei Vertragsverlängerungen: Ohne Ausstiegsanalysen und Abhängigkeitsanalysen verhandelt man Vertragsverlängerungen im Blindflug.
Autorin
Raynah
Raynah ist Content-Strategin bei Sprinto und entwickelt dort Storys, die Compliance für moderne Unternehmen vereinfachen. In den letzten zwei Jahren hat sie format- und funktionsübergreifend daran gearbeitet, Sicherheit und Compliance verständlicher und geschäftsorientierter zu gestalten.Gehen Sie über die Oberfläche hinaus und entdecken Sie die Erkenntnisse zu Governance, Risikomanagement und Compliance, die wirklich wichtig sind.
Sichern Sie sich digitale Vorteile für Ihren Erfolg im Vorstand.
Mehr erfahren
Recherchen und Erkenntnisse, die Ihnen helfen sollen, sich einen Platz am Tisch zu sichern.
