AI Governance · 12 Min.
AI Vendor Risk Management: Wie du Agent-Plattformen prüfst, bevor sie kritische Prozesse sehen
Agent-Plattformen sind nicht nur Softwarelieferanten. Sie können Prozesszugriff, Kundendaten und operative Entscheidungen berühren.
SYSTEMS Grafik zu AI Vendor Risk Management: Risk -> Guardrail -> Audit. Fokus: Wie Unternehmen AI-Agent-Anbieter und Plattformen vor produktivem Einsatz bewerten.
Kurzfassung
AI-Agent-Anbieter können tief in Prozesse und Daten greifen. Vendor Risk muss Datenfluss, Tool-Rechte, Modellwechsel, Logs und Exit prüfen. Nicht jedes AI-Tool gehört direkt in kritische Workflows.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten Architekturentscheidungen.
Warum AI Vendor Risk anders ist Ein normales SaaS-Tool speichert Daten und führt Funktionen aus. Eine Agent-Plattform kann zusätzlich entscheiden, welche Tools sie nutzt und welche Aktionen sie vorbereitet.
Das vergrößert die Risikooberfläche.
Stand Mai 2026: Vendor Risk ist AI-Governance, Security und Betriebsarchitektur NIST AI RMF beschreibt Risikomanagement über den Lebenszyklus von AI-Systemen. Das GenAI-Profil ergänzt Risiken wie Datenherkunft, Evaluation, Missbrauch, Incident-Prozesse und Third-Party-Abhängigkeiten. ISO/IEC 42001 beschreibt ein Managementsystem für verantwortliche Entwicklung, Bereitstellung und Nutzung von AI-Systemen. Der EU AI Act setzt zusätzlich Pflichten für Anbieter und Nutzer bestimmter AI-Systeme und für GPAI-Modelle.
Für Agent-Plattformen heisst das: Der Vendor ist nicht nur ein Tool-Lieferant. Er wird Teil eures Datenflusses, eurer Tool-Landschaft, eurer Auditfähigkeit und teilweise eurer Kundenprozesse.
Die wichtigsten Prüffragen Welche Daten werden verarbeitet? Werden Daten zum Training genutzt? Welche Subprozessoren sind beteiligt? Wie werden Logs gespeichert? Kann man Modelle wechseln? Gibt es Audit und Export?
Diese Fragen gehören vor den Rollout.
Eine gute Due-Diligence-Matrix prüft:
Ohne diese Matrix wird AI-Beschaffung zu Bauchgeführ.
Daten: Inputs, Outputs, Dateien, Logs, Traces, Embeddings, Audio, Bilder. Training: Werden Kundeninhalte für Modellverbesserung genutzt oder ausgeschlossen? Retention: Wie lange werden Daten, Logs und Traces gespeichert? Residency: Welche Regionen sind möglich und für welche Datenarten? Subprozessoren: Welche Dritten sehen welche Daten? Security: SOC 2, ISO, Verschlüsselung, Zugriff, Admin-Rollen, SSO, SCIM. Governance: Audit Logs, DLP, Policies, Rollen, Workspace-Trennung. Tools: MCP, Connectoren, Browser, Code, Voice, Email, CRM, Payment. Evals: Wie werden Qualität, Safety und Regression gemessen? Incident: Wer informiert wen, in welcher Frist, mit welchen Logs? Exit: Export von Prompts, Evals, Tool-Definitionen, Daten und Workflows. Agenten verändern die Risikoklasse Ein Chatbot beantwortet Fragen. Ein Agent kann Daten holen, Tools wählen, Drafts schreiben, Workflows auslösen und manchmal echte Aktionen vorbereiten. Dadurch entstehen neue Vendor-Risk-Fragen:
OWASP LLM und MCP Risiken passen hier direkt hinein: Prompt Injection , Datenabfluss, Tool Poisoning , fehlende Auditierung und Context Over-Sharing sind Vendor-Risk-Themen, nicht nur Engineering-Details.
Darf der Anbieter Tool-Calls sehen? Welche Connectoren laufen im Anbieter-Account, welche in eurem Tenant? Können Admins Tool-Rechte zentral begrenzen? Sind Schreibaktionen standardmäßig approval-pflichtig? Werden Agenten-Entscheidungen nachvollziehbar geloggt? Was passiert bei Modellwechseln oder Tool-Update? Kann ein Anbieterfehler Kundendaten, Vertragsdaten oder operative Entscheidungen betreffen? Vertragsfragen für Agent-Plattformen Vor produktivem Einsatz sollten Einkauf, Legal, Security und Fachbereich diese Punkte klären:
Ein Anbieter, der nur eine Demo zeigt, aber diese Fragen nicht beantworten kann, gehört nicht an kritische Prozesse.
Datenverarbeitung: Controller/Processor, DPA, TOMs, Subprozessoren. Modellnutzung: kein Training auf Kundendaten oder explizite Opt-out-Regeln. Logging: Zugriff, Aufbewahrung, Redaction, Export. Compliance: ISO/SOC, Datenschutz, Branchenanforderungen, EU-AI-Act-Rolle. Verfügbarkeit: SLA, Support, Incident-Kommunikation. Änderungen: Modell-, Tool-, Connector- und Preisupdates. Exit: Datenportabilität, Löschung, Workflow-Export. Haftung: Fehlaktionen, Security-Incidents, Datenverlust, Drittanbieter. Exit-Strategie Agenten-Workflows dürfen nicht so gebaut sein, dass ein Anbieterwechsel unmöglich wird. Prompts, Evals, Tool-Definitionen und Prozesslogik sollten dokumentiert sein.
Sonst entsteht Lock-in in der operativen Schicht.
Eine Exit-fähige Architektur hält:
Exit ist nicht Pessimismus. Exit ist Verhandlungsfähigkeit.
Systemprompts und Policies versioniert. Evals als portable Datensätze. Tool-Schemas getrennt vom Anbieter-UI. Connector-Governance in eigener Dokumentation. Logs und Traces exportierbar. Modellrouting nicht hart auf einen Anbieter verdrahtet. kritische Businesslogik ausserhalb proprietärer Builder, wenn Wechsel wichtig ist. Vendor Scorecard Bewerte jeden Anbieter von 1 bis 5:
Wenn ein Anbieter bei Daten, Tool-Rechten oder Audit schwach ist, darf er nicht in Kunden-, Zahlungs-, Vertrags- oder Adminprozesse.
Datenkontrolle. Admin- und Rollenmodell. Tool- und Connector-Governance. Audit und Tracing. Evals und Regression. Incident Response. Kosten-Transparenz. Compliance-Fit. Exit-Fähigkeit. Der SYSTEMS-Blick Wir prüfen AI-Vendor nicht nur technisch, sondern prozessual. Welche Arbeit hängt daran, welches Risiko entsteht, was passiert beim Ausfall?
So wird AI-Beschaffung strategisch statt impulsiv: klare Risiko-Scores, Datenflusskarten, Tool-Grenzen, Evals, Incident-Regeln und eine Exit-Strategie, bevor der Agent echte Verantwortung bekommt.
