Die meisten Beschaffungsprozesse behandeln einen AI Agent noch immer wie ein weiteres Software-Abonnement. Der Anbieter gewährt Zugang, das Unternehmen zahlt eine wiederkehrende Gebühr, die IT prüft die Sicherheitsdokumentation, Legal bewertet die Vereinbarungen zur Datenverarbeitung, und das Fachteam beginnt, das Produkt zu nutzen.
Dieses Modell greift zu kurz.
Ein AI Agent ist nicht einfach eine Anwendung mit einem stabilen Funktionsumfang. Er ist eine operative Abhängigkeit, die aus Modellen, Prompts, Retrieval-Quellen, Konnektoren, Orchestrierungslogik, gehosteter Infrastruktur, externen Tools und Subprozessoren besteht. Jede dieser Ebenen kann Verhalten, Kostenstruktur, Sicherheitslage und Zuverlässigkeit des Services verändern, auf den Ihre Teams angewiesen sind.
Für ein mittelständisches Unternehmen in der DACH-Region lautet die praktische Frage nicht, ob ein AI-Anbieter eine attraktive Benutzeroberfläche bietet. Entscheidend ist, ob der Vertrag dem Unternehmen ausreichend Kontrolle gibt, wenn der Anbieter das System verändert, einen Incident erleidet, Preise anpasst, eine Funktion entfernt oder faktisch nicht mehr nutzbar wird.
Das Beschaffungsteam kauft nicht nur eine Lizenz. Es beauftragt einen Lieferanten, an einem operativen Prozess mitzuwirken.
Die SaaS-Vertragsannahme trägt bei AI Agents nicht mehr
Ein klassisches SaaS-Tool verändert sich üblicherweise auf einer sichtbaren Produktebene. Ein neues Modul erscheint, eine Integration wird eingestellt oder ein Service-Level-Versprechen wird bei der Verlängerung angepasst. Auch diese Änderungen sind relevant, doch der Kernprozess bleibt oft nachvollziehbar: Nutzende geben Daten ein, die Software wendet bekannte Logik an, und das Unternehmen erhält ein vorhersehbares Ergebnis.
AI Agents bringen eine andere Form der Variabilität mit sich. Ein Anbieter kann das zugrunde liegende Modell austauschen, die Systemanweisungen verändern, Retrieval-Einstellungen anpassen, einen neuen Tool Call einführen, das Filterverhalten ändern oder Workloads an einen anderen Provider weiterleiten. Die User Experience kann unverändert aussehen, obwohl sich das Verhalten darunter wesentlich verschoben hat.
Das ist relevant, wenn der Agent die Vertriebsqualifizierung, den Kundenservice, die Dokumentenprüfung, den Wissenszugriff, den internen Support oder operative Entscheidungen unterstützt. Schon eine kleine Änderung daran, wie der Agent eine Anfrage interpretiert, kann die Antwortqualität beeinflussen. Ein neuer Konnektor kann die Datenmenge erweitern, auf die der Agent zugreifen kann. Eine geänderte Model-Routing-Regel kann Latenz, Kosten sowie den geografischen oder vertraglichen Weg verändern, über den Informationen verarbeitet werden.
Der Fehler in der Beschaffung besteht darin, Zugang statt Verhalten zu vertraglich zu regeln. Ein allgemeiner AI-Nachtrag, insbesondere wenn er aus einem herkömmlichen Softwarevertrag übernommen wurde, beantwortet die Fragen, die nach dem Deployment entstehen, selten. Er erwähnt möglicherweise verantwortungsvollen Einsatz und Sicherheit in allgemeinen Formulierungen, sagt aber wenig darüber aus, was passiert, wenn der Anbieter das System verändert, das den Agent überhaupt erst nützlich macht.
Das richtige Ziel ist nicht, jede Komponente dauerhaft einzufrieren. Das wäre wirtschaftlich unrealistisch und technisch kontraproduktiv. Es geht darum, zwischen gewöhnlicher Wartung und Änderungen zu unterscheiden, die eine Information, Prüfung oder Genehmigung erfordern.
Definieren Sie, was als wesentliche Modelländerung gilt
Anbieter brauchen Spielraum, um ihre Services zu warten und weiterzuentwickeln. Unternehmen brauchen Schutz vor unangekündigten Änderungen, die ihre Risikoposition verändern. Beides lässt sich vereinbaren, wenn der Vertrag Änderungskategorien präzise genug definiert.
Eine sinnvolle Informationsklausel orientiert sich an operativen Auswirkungen, nicht an Markennamen. Sie sollte Änderungen beim Modellanbieter oder bei der Modellfamilie erfassen, sofern diese die Eigenschaften der Ergebnisse, die Datenverarbeitung, Sicherheitskontrollen, Verfügbarkeit, Preislogik oder die Fähigkeit des Agents zur Nutzung von Tools und verbundenen Systemen beeinflussen können. Ebenso sollten wesentliche Änderungen an System Prompts, Retrieval-Konfigurationen, Autonomiegrenzen und Subprozessoren erfasst sein.
Es geht nicht darum, bei jeder Optimierung eines internen Parameters eine Mitteilung zu verlangen. Das erzeugt Rauschen und führt dazu, dass alle Beteiligten die Hinweise ignorieren. Stattdessen sollte die Beschaffung einen Schwellenwert verlangen: Änderungen, die den vereinbarten Use Case, die betroffenen Datenkategorien, das Kontrollumfeld, die erwartete Serviceleistung oder die dokumentierte Risikobewertung des Unternehmens vernünftigerweise beeinflussen können.
Damit verschiebt sich das Gespräch von „Darf der Anbieter seine AI aktualisieren?“ zu „Welche Aktualisierungen verändern den Service, den wir bewertet und freigegeben haben?“
Bei geschäftskritischen Workflows reicht eine Information möglicherweise nicht aus. Das Unternehmen kann Zeit benötigen, um das veränderte Verhalten in einer kontrollierten Umgebung zu testen, bevor es produktiv eingesetzt wird. Das ist besonders wichtig, wenn ein Agent extern sichtbare Kommunikation formuliert, vertrauliche Informationen abruft, Aktionen in anderen Systemen auslöst oder regulierte interne Prozesse unterstützt.
Ein Anbieter, der nicht erklären kann, wie er Modelländerungen steuert, signalisiert ein tieferliegendes Problem. Möglicherweise verfügt er über keinen verlässlichen internen Nachweis darüber, welche Version aktiv war, welche Konfigurationen geändert wurden oder welche Kundenumgebungen betroffen waren. Das macht Incident-Untersuchungen und Governance erheblich schwieriger als nötig.
Incident-Klauseln brauchen Nachweise, nicht Beruhigung
Wenn ein AI-gestützter Prozess scheitert, besteht die erste Herausforderung meist in der Rekonstruktion. Was hat die nutzende Person gefragt? Welche Workflow-Version hat die Anfrage verarbeitet? Welche Wissensquelle wurde abgerufen? Welche Tools wurden aufgerufen? War ein externes Modell beteiligt? Welches Ergebnis wurde erzeugt, und welche Handlung folgte daraus?
Ein Vertrag, der den Anbieter lediglich verpflichtet, „den Kunden über Incidents zu informieren“, reicht nicht aus. Eine Benachrichtigung sagt Ihnen, dass etwas passiert ist. Sie liefert Ihrem Unternehmen aber nicht die Nachweise, die nötig sind, um Auswirkungen zu bewerten, Stakeholder zu informieren, den Prozess zu korrigieren oder über die weitere Nutzung des Services zu entscheiden.
Incident-Nachweise sollten eine vertragliche Leistungspflicht sein. Die Vereinbarung sollte festlegen, welche Informationen der Anbieter nach einem relevanten Ereignis bereitstellen kann, vorbehaltlich berechtigter Schutzinteressen anderer Kunden und seines eigenen geistigen Eigentums. In der Praxis können dazu relevante Ereignisprotokolle, die Konfigurationshistorie, Informationen zum Systemstatus und zu Zugriffen, eine Beschreibung betroffener Komponenten sowie die Dokumentation der durchgeführten Abhilfemaßnahmen gehören.
Das ist kein Argument dafür, uneingeschränkten Zugang zur Produktionsumgebung eines Anbieters zu verlangen. Die meisten mittelständischen Käufer benötigen diesen Zugang weder noch könnten sie ihn operativ sinnvoll nutzen. Das Ziel ist enger gefasst: nachvollziehen zu können, ob Verhalten, Datenzugriff oder Servicekontinuität des Agents beeinträchtigt waren, und Nachweise für die eigene interne Prüfung zu sichern.
Dasselbe Prinzip gilt für Sicherheitsvorfälle und Qualitätsprobleme. Ein Agent kann ein erhebliches operatives Problem verursachen, ohne dass ein klassischer Sicherheitsvorfall vorliegt. Nach einem Modell-Update kann er systematisch irreführende Antworten erzeugen, infolge eines Retrieval-Fehlers veraltetes Wissen ausgeben oder über ein verbundenes System unangemessene Aktionen auslösen. Prozesse für das Lieferantenmanagement müssen solche Ereignisse als untersuchungswürdige Incidents behandeln, nicht bloß als Produktunzulänglichkeiten.
Portabilität bedeutet mehr als den Export von Dokumenten
Viele Unternehmen gehen davon aus, dass sie einen AI-Anbieter verlassen können, indem sie ihre Dokumente herunterladen. Das ist nur ein Teil des Exit-Problems.
Der Wert eines Agents liegt häufig im operativen Design darum herum: Prompts, Workflow-Logik, Freigabeschritte, Zuordnungen von Wissensquellen, Evaluierungsfälle, Tool-Konfigurationen, Richtlinien, Gesprächsvorlagen und Regeln dafür, wann ein Mensch übernimmt. Können diese Elemente nicht in nutzbarer Form exportiert werden, bedeutet ein Anbieterwechsel, den Prozess unter Zeitdruck neu aufzubauen.
Eine AI-Exit-Strategie sollte die Assets schützen, die den Workflow funktionsfähig machen. Die Beschaffung sollte identifizieren, welche Artefakte dem Unternehmen gehören und welche bei Vertragsende zurückgegeben oder zugänglich gemacht werden müssen. Die Antwort darf sich nicht auf hochgeladene Dateien beschränken. Sie sollte, soweit technisch möglich, auch den Konfigurations- und Workflow-Status einschließen, der erforderlich ist, um den Service an anderer Stelle nachzubilden.
Dabei ist eine wichtige Unterscheidung nötig. Ein Anbieter ist nicht verpflichtet, seine proprietäre Plattform oder Modellgewichte herauszugeben. Der Kunde sollte jedoch nicht gefangen sein, weil er seine eigenen Prompts, seine eigenen Evaluierungsdaten, seine eigenen Prozesskonfigurationen oder einen nutzbaren Nachweis darüber, wie sein Workflow aufgebaut wurde, nicht erhalten kann.
Hier muss die Due Diligence gegenüber Anbietern praktisch werden. Lassen Sie sich den Exportprozess vor Vertragsunterzeichnung demonstrieren, statt sich lediglich bestätigen zu lassen, dass Portabilität vorhanden sei. Kann das Unternehmen Inhalte seiner Wissensdatenbank einschließlich Metadaten abrufen? Kann es Prompts und Orchestrierungsregeln exportieren? Sind Gesprächsprotokolle verfügbar, wenn dies erforderlich und angemessen ist? Lassen sich Tool-Berechtigungen und Workflow-Konfigurationen klar genug dokumentieren, damit ein Ersatzteam sie neu aufbauen kann?
Ein vages Versprechen wie „Datenexport auf Anfrage“ ist kein Exit-Plan.
Servicekontinuität muss die Übergangsphase einschließen
Exit-Rechte sind nur glaubwürdig, wenn das Unternehmen während der Migration weiterarbeiten kann. Ein Anbieter kann einen Service kündigen, sein Geschäftsmodell verändern, eine Funktion einstellen oder nach einem wesentlichen Incident ungeeignet werden. In jedem dieser Fälle braucht das Unternehmen einen geordneten Übergang statt eines abrupten Verlusts von Fähigkeiten.
Für ein mittelständisches Unternehmen in der DACH-Region bedeutet das nicht zwingend, jedes AI-System doppelt vorzuhalten oder eine teure Standby-Plattform zu betreiben. Es bedeutet, jene Workflows zu identifizieren, bei denen eine Unterbrechung Kundenservice, Umsatzprozesse, interne Produktivität oder Compliance beeinträchtigen würde. Diese Workflows verdienen eine Übergangsregelung, die ihrer Bedeutung angemessen ist.
Der Vertrag sollte klarstellen, welche Unterstützung während eines geplanten Exits verfügbar ist, wie lange das Unternehmen auf Daten und Konfigurationen zugreifen kann und was mit Integrationen sowie verbundenen Systemen geschieht. Er sollte auch die sichere Löschung nach dem vereinbarten Übergang regeln und dem Unternehmen zugleich erlauben, die Unterlagen aufzubewahren, die es berechtigterweise benötigt.
Der glaubwürdigste Exit-Pfad ist ein getesteter Exit-Pfad. Eine kurze Übung während des Onboardings kann zeigen, ob Exporte vollständig sind, ob das Unternehmen seine Prompts und Workflows dokumentiert hat und ob eine andere Plattform die Aufgaben realistisch übernehmen könnte. Das ist kein Pessimismus, sondern grundlegende Lieferantendisziplin.
Die Beschaffung braucht einen Platz in der AI Operating Governance
Das Management von AI-Anbietern kann nicht vollständig bei Beschaffung, Legal oder IT liegen. Jede dieser Funktionen sieht nur einen Teil des Risikos. Die Beschaffung steuert den kommerziellen Hebel und die Vertragsstruktur. Legal bewertet Verpflichtungen und Datenbedingungen. Die IT prüft Integration, Identitäten, Sicherheit und operative Resilienz. Die Fachverantwortlichen verstehen die Folgen, wenn sich Ergebnisse verändern. Die Verantwortlichen für AI Governance müssen diese Perspektiven zusammenführen.
Deshalb sollten Verträge das tatsächliche Operating Model abbilden. Wenn Fachbereiche eigenständig Agents erstellen können, braucht das Unternehmen klare Regeln dafür, wer Anbieter, Konnektoren und Use Cases mit höherem Risiko freigeben darf. Wenn ein zentrales Plattformteam gemeinsame AI-Services betreibt, benötigt es Transparenz über Modelländerungen, Incident-Nachweise und Exit-Abhängigkeiten im gesamten Portfolio.
Das Unternehmen sollte auch den gegenteiligen Fehler vermeiden: für ein risikoarmes Experiment ohne sensible Daten, ohne externe Aktionen und ohne Produktivabhängigkeit Kontrollsprache auf Enterprise-Niveau verhandeln zu wollen. Governance sollte verhältnismäßig sein. Sobald ein AI Agent jedoch Teil eines relevanten Geschäftsprozesses wird, müssen die Lieferantenbedingungen mit der Realität Schritt halten.
Der beste Vertrag für die AI-Beschaffung ist nicht der längste. Es ist der Vertrag, der Verantwortlichkeiten sichtbar macht, bevor ein Problem entsteht: Was darf sich ändern, welche Nachweise sind verfügbar, was kann der Kunde mitnehmen und wie bleibt das Unternehmen handlungsfähig, wenn es den Anbieter verlassen muss.
Ein Diagnostic erfasst Ihre Abhängigkeiten von AI-Anbietern, Vertragslücken und praktischen Exit-Anforderungen, bevor ein sich verändernder Anbieter zu einem operativen Lock-in wird.
Hinweis zum Kontext: Dieser Artikel bietet praktische Hinweise für Beschaffung und Betrieb und stellt keine Rechtsberatung dar.