Der Kauf eines AI-Systems ist nicht mit dem Kauf herkömmlicher Software gleichzusetzen. Eine klassische Anwendung verarbeitet möglicherweise wichtige Daten, doch ihr Kernverhalten ist in der Regel spezifiziert, testbar und zwischen Releases relativ stabil. Ein Modell, Agent oder Copilot schafft eine komplexere operative Realität. Sein Verhalten hängt von der Modellversion, den Systemanweisungen, angebundenen Daten, der Retrieval-Logik, Tools, Nutzereingaben und den umgebenden Kontrollen ab. Verändert sich eine dieser Komponenten, kann sich auch das Risikoprofil des Systems verändern.
Deshalb reicht ein übliches Lieferantenfragebogen nicht aus. Er kann nützliche Erklärungen einholen, schafft aber selten eine operative Kontrolle, die das Unternehmen beim Go-Live, während eines Vorfalls oder beim Ende einer Lieferantenbeziehung nutzen kann. Der bessere Beschaffungsmechanismus ist ein AI Supplier Evidence Pack: eine strukturierte, wiederverwendbare Sammlung von Artefakten, die zeigt, was genau ausgerollt wird, wie das System Daten verarbeitet, welche Entscheidungen bei Menschen verbleiben und welche Nachweise die Aussage stützen, dass es für den vorgesehenen Einsatz bereit ist.
Für die Geschäftsführung ist das kein administrativer Mehraufwand. Es ist ein Weg, aus einer vagen Zusicherung wie „Der Lieferant ist compliant“ eine Entscheidung zu machen, die nachvollzogen, hinterfragt und verantwortet werden kann. Für IT-, Security- und Datenteams ersetzt es wiederholte E-Mail-Abstimmungen durch eine Grundlage, die geprüft werden kann, wenn sich der Use Case erweitert oder die zugrunde liegende Technologie verändert.
Warum vertragliche Zusagen keine operative Kontrolle schaffen
Viele Beschaffungsprozesse verorten AI Governance noch immer im Vertrag. Der Lieferant bestätigt, geltende Anforderungen einzuhalten, unterzeichnet Vereinbarungen zur Auftragsverarbeitung, liefert Security-Klauseln und stellt möglicherweise ein allgemeines Dokument zur Produktsicherheit bereit. Diese Unterlagen sind wichtig. Sie beantworten jedoch nicht die Fragen, die entstehen, sobald ein AI-System die tägliche Arbeit beeinflusst.
Nehmen wir einen Copilot für ein Customer-Service-Team. Der Käufer muss nicht nur wissen, dass der Lieferant „sichere AI“ einsetzt. Er muss wissen, welches Modell aufgerufen wird, wohin Prompts und Ausgaben übertragen werden, ob Kundendaten zur Laufzeit abgerufen werden, wie lange Logs gespeichert bleiben und ob Agents Aktionen in angebundenen Systemen ausführen können. Noch gewichtiger werden diese Fragen, wenn ein Agent Vertragsnachträge formulieren, einen CRM-Datensatz aktualisieren, eine Bestellanforderung anlegen oder einen Workflow auslösen kann.
Ein Vertrag soll üblicherweise Haftung zwischen Parteien regeln. Ein Evidence Pack soll einen sicheren Betrieb ermöglichen. Es hilft dem Unternehmen festzuhalten, was es genehmigt hat, welche Annahmen zugrunde lagen und welche Kontrollen auch nach dem Launch funktionieren müssen.
Die zentrale Frage in der Beschaffung lautet daher nicht, ob der Lieferant einen Compliance-Fragebogen ausfüllen kann. Sie lautet, ob er nachweisen kann, dass das konkrete Deployment bekannt, klar abgegrenzt und steuerbar ist.
Mit einer Deployment-Identität beginnen, nicht mit einem Produktnamen
„AI-Assistent“ ist für Governance keine brauchbare Beschreibung. Ein Produktname allein ebenso wenig. Ein Supplier Evidence Pack sollte eine Deployment-Identität festlegen, die das tatsächlich im Unternehmen eingeführte System abbildet.
Dazu gehören der Lieferant, wesentliche Unterauftragnehmer, der oder die Modellanbieter, die relevante Modellfamilie und Modellversion, soweit diese Informationen verfügbar sind, sowie das Hosting-Modell. Es sollte außerdem festgehalten werden, ob die Anwendung ein General-Purpose-Modell direkt verwendet, Anfragen über mehrere Modelle routet, RAG einsetzt oder ein Modell für eine klar definierte Aufgabe per Fine-Tuning anpasst.
Diese Details sind wichtig, weil Käufer oft annehmen, sie bewerteten ein einzelnes System, obwohl sie tatsächlich eine Kette von Systemen bewerten. Ein Anbieter liefert möglicherweise die Workflow-Schicht, ein anderer hostet das Modell, ein separater Dienst übernimmt die Dokumentenextraktion und eine Cloud-Plattform speichert operative Logs. Jede dieser Beziehungen kann Datenverarbeitung, Verfügbarkeit, Security-Verantwortlichkeiten und die praktische Fähigkeit beeinflussen, einen Vorfall zu untersuchen.
Das Evidence Pack sollte auf das konkrete Deployment zugeschnitten sein und nicht aus wiederverwerteten Marketingunterlagen bestehen. Kann der Lieferant die Komponenten nicht benennen, die Daten verarbeiten oder Outputs beeinflussen, fehlt dem Käufer noch die nötige Klarheit für die Freigabe des Produktivbetriebs.
Die Datenverarbeitungslandkarte für den Betrieb nutzbar machen
Datenlandkarten werden häufig als Compliance-Übung erstellt und anschließend abgelegt. Bei AI-Systemen ist das eine verpasste Chance. Die Karte sollte für die Menschen verständlich sein, die den Service betreiben, nicht nur für Rechtsspezialisten.
Sie sollte zeigen, was in das System eingeht: Nutzereingaben, hochgeladene Dokumente, abgerufenes internes Wissen, Gesprächsverläufe und Metadaten. Sie sollte aufzeigen, wo jede Datenkategorie verarbeitet und gespeichert wird, ob sie zur Serviceverbesserung oder zum Modelltraining verwendet wird und wie Löschanfragen oder Aufbewahrungsregeln gehandhabt werden. Ebenso muss sie erläutern, was das System verlässt: generierter Text, Tool Calls, Audit-Aufzeichnungen, Benachrichtigungen und Exporte in andere Geschäftsanwendungen.
Entscheidend ist die Unterscheidung zwischen Inhalts- und Kontrolldaten. Ein Lieferant kann zusagen, nicht auf Kundeninhalten zu trainieren, und dennoch Prompts, Outputs oder Metadaten für operative Zwecke speichern. Das kann angemessen sein, muss aber sichtbar sein. Das Unternehmen muss wissen, was sich deaktivieren lässt, was für die Fehleranalyse erforderlich ist und was über die Nutzersitzung hinaus gespeichert bleibt.
Für ein Mittelstandsunternehmen muss diese Landkarte nicht zu einer Abhandlung über Enterprise Architecture werden. Sie muss praktische Fragen schnell beantworten können, wenn ein Fachverantwortlicher wissen möchte, ob Personalakten, Konstruktionsunterlagen, Kundeninformationen oder geschäftskritische Inhalte in einem bestimmten Workflow verwendet werden dürfen.
Die Rolle einordnen, bevor Unterlagen diskutiert werden
Diskussionen über AI Governance beginnen häufig mit einer langen Liste von Dokumenten. Sinnvoller ist es, mit der Rolle des Unternehmens und dem vorgesehenen Einsatz zu beginnen. Ein Unternehmen, das einen Standard-Copilot intern einsetzt, hat ein anderes Verantwortungsprofil als ein Unternehmen, das ein AI-System für Kunden anpasst, in ein Produkt integriert oder einen Agent entwickelt, der folgenreiche Workflow-Entscheidungen trifft.
Das Evidence Pack sollte die Einschätzung des Lieferanten zu seiner Rolle, die vorgesehene Rolle des Käufers und die Begründung dieser Einordnung dokumentieren. Außerdem sollten Zweck, Nutzergruppe, Einsatzkontext und vorhersehbare Missbrauchsfälle festgehalten werden. Das ist besonders wichtig, wenn das System Beschäftigung, Finanzen, Sicherheit, Kundenberechtigung oder andere sensible Entscheidungen berührt.
Es geht nicht darum, jeden kleinen internen Assistenten durch denselben Prozess wie ein High-Impact-System zu führen. Es geht darum, den gegenteiligen Fehler zu vermeiden: Ein System als risikoarm zu behandeln, nur weil es als „Produktivität“ etikettiert wurde. Ein Schreibassistent, der lediglich einen ersten Entwurf einer Besprechungszusammenfassung vorschlägt, unterscheidet sich erheblich von einem Agent, der auf Grundlage dieser Zusammenfassung Geschäftsdaten aktualisiert oder Kundenkommunikation versendet.
Ein Beschaffungsteam sollte darauf bestehen, dass der Lieferant diese Grenzen in verständlicher Sprache beschreibt. Was sich nicht erklären lässt, lässt sich auch nicht überwachen.
Evaluierungsnachweise verlangen, die zur tatsächlichen Aufgabe passen
Allgemeine Modell-Benchmarks sind eine schwache Grundlage für eine Kaufentscheidung. Sie können breite Fähigkeiten belegen, sagen aber wenig darüber aus, ob das System mit den Dokumenten, der Terminologie, den Workflows und der Fehlertoleranz des Unternehmens zuverlässig funktioniert.
Ein brauchbares Evidence Pack enthält einen Evaluierungsansatz für den tatsächlichen Use Case. Bei einem Wissensassistenten bedeutet das, zu testen, ob Antworten auf freigegebenen Quellen beruhen, ob Zitate oder Links Nutzer zum richtigen Material führen und was geschieht, wenn die Quellenbasis keine Antwort enthält. Bei einem Workflow zur Dokumentenverarbeitung geht es um Extraktionsqualität, Ausnahmebehandlung und den Weg für unsichere Fälle. Bei einem Agent geht es um Tool-Berechtigungen, Aktionsgrenzen und das Verhalten bei Fehlern.
Die Evaluierung muss auch Verweigerungs- und Eskalationsverhalten umfassen. Käufer sollten nicht nur fragen, wann das System gut funktioniert. Sie sollten fragen, was es tut, wenn Informationen fehlen, Anweisungen im Widerspruch stehen, ein externes Tool ausfällt oder ein Nutzer eine Aktion außerhalb des genehmigten Rahmens verlangt.
Die Ergebnisse müssen keine unmögliche Gewissheit suggerieren. AI-Systeme bleiben probabilistisch. Entscheidend ist, ob der Lieferant einen disziplinierten Testprozess nachweisen, bekannte Einschränkungen offenlegen und die Kontrolle benennen kann, die verhindert, dass aus einem gewöhnlichen Fehler ein Geschäftsvorfall wird.
Logging und menschliche Übersteuerung als Produktanforderungen behandeln
Ein System, das nicht untersucht werden kann, kann nicht gesteuert werden. Vor dem Go-Live sollte der Käufer verstehen, welche Betriebsaufzeichnungen existieren und ob sie dem Unternehmen ermöglichen, ein relevantes Ereignis nachzuvollziehen. Dazu gehören üblicherweise relevante Nutzeraktivitäten, Modell- oder Workflow-Konfigurationen, gegebenenfalls abgerufene Quellen, Tool Calls, Freigaben, Fehler sowie Änderungen an Berechtigungen oder Prompts.
Logging muss unter dem Gesichtspunkt der Datenminimierung konzipiert werden. Jede Eingabe auf unbegrenzte Zeit zu erfassen, ist kein Zeichen von Reife. Ziel ist ein angemessener Audit Trail, der Vorfallsuntersuchungen, Qualitätsverbesserung und Verantwortlichkeit unterstützt, ohne einen unnötigen zweiten Datenspeicher zu schaffen.
Menschliche Aufsicht braucht eine ähnliche Präzision. „Ein Mensch bleibt im Loop“ reicht nicht, wenn niemand weiß, wer dieser Mensch ist, wann er eingreift oder ob er befugt ist, den Prozess zu stoppen. Das Evidence Pack sollte den Eskalationsweg, die Möglichkeit zur Deaktivierung des Systems oder eines risikoreichen Tools sowie den Fallback-Prozess zeigen, wenn der AI-Service nicht verfügbar oder unzuverlässig ist.
Bei agentischen Systemen wird Beschaffung zur Architekturfrage. Ein glaubwürdiges Design trennt in der Regel Empfehlung und Ausführung, begrenzt Tool-Zugriffe, setzt Freigabeschleusen für wesentliche Aktionen ein und ermöglicht einen schnellen Entzug von Berechtigungen. Ein Agent mit weitreichenden Zugriffsrechten und ohne praktikablen Kill Switch ist keine innovative Beschaffungsentscheidung, sondern eine unkontrollierte operative Abhängigkeit.
Security-Nachweise und einen Ausstiegsweg einbeziehen
Security-Nachweise sollten sich auf den konkreten Service beziehen und nicht auf die allgemeine Unternehmensposition des Lieferanten beschränkt bleiben. Käufer brauchen Klarheit über Identity and Access Management, Mandantentrennung, Verschlüsselung, Umgang mit Schwachstellen, administrative Zugriffe und Vorfallkommunikation. Wenn das System mit internen Tools verbunden ist, verdient der Integrationspfad mindestens ebenso viel Aufmerksamkeit wie das Modell selbst. Eine gut abgesicherte Modellschnittstelle gleicht keinen Connector mit übermäßigen Berechtigungen aus.
Der letzte Teil des Evidence Packs wird häufig vernachlässigt: der Ausstieg. AI-Lieferanten können schnell tief eingebunden werden, weil sich Prompts, Evaluierungen, Retrieval-Strukturen, Workflow-Logik und Nutzergewohnheiten um ihre Plattform ansammeln. Käufer sollten festlegen, was exportiert werden kann, wie Geschäftsdaten zurückgegeben oder gelöscht werden, welche Konfigurationen dokumentiert werden können und was bei Vertragsende mit Logs und Zugangsdaten geschieht.
Ausstiegsplanung bedeutet nicht, dass ein Scheitern des Lieferanten erwartet wird. Sie ist eine Disziplin, die verhindert, dass Bequemlichkeit zu Lock-in wird. Sie verbessert auch die Kaufentscheidung von heute, denn ein Lieferant, der Portabilität und Löschung klar erklären kann, versteht in der Regel sein eigenes Betriebsmodell.
Das Evidence Pack als lebendige Go-Live-Kontrolle etablieren
Das Pack sollte nach der Vertragsunterzeichnung nicht verschwinden. Es sollte zur Grundlage für die Freigabe des Produktivbetriebs und für das anschließende Change Management werden. Eine neue Modellversion, zusätzliche Agent-Funktionen, eine neue Datenquelle, geänderte Aufbewahrungseinstellungen oder eine erweiterte Nutzergruppe können eine Aktualisierung der Nachweise erforderlich machen. Das ist keine Bürokratie um ihrer selbst willen, sondern erkennt an, dass ein AI-Deployment ein sich veränderndes System ist.
Die Verantwortlichkeiten sollten eindeutig sein. Procurement kann die Nachweise einholen, doch IT, Security, Datenschutz, Recht und der Fachverantwortliche müssen jeweils die Teile validieren, die sie fachlich beurteilen können. Von der Geschäftsführung sollte nicht erwartet werden, technische Logs zu prüfen. Sie sollte jedoch erkennen können, ob die Entscheidung einen klaren Owner, bekannte Einschränkungen, einen glaubwürdigen Übersteuerungsweg und eine beherrschbare Lieferantenabhängigkeit hat.
Ein Supplier Evidence Pack macht aus AI Vendor Due Diligence mehr als eine Zugangshürde. Es schafft eine gemeinsame Betriebsdokumentation. Für Unternehmen, die von isolierten Experimenten zu produktiven Workflows übergehen, ist diese Dokumentation oft der Unterschied zwischen einer kontrollierten Fähigkeit und einer Black Box mit Bestellnummer.
Ein Diagnostic hilft Ihrem Unternehmen, die für ein AI-Deployment erforderlichen Nachweise, Verantwortlichkeiten und Go-Live-Kontrollen festzulegen — bevor Annahmen von Lieferanten zu operativen Risiken werden.
Hinweis zum Kontext: Dieser Artikel bietet praxisorientierte Orientierung und zitiert keine externen Quellen.