Wenn dein KI-Anbieter ein Modell abschaltet, entscheidet nicht die Technik, ob dein Betrieb weiterläuft, sondern dein Vertrag. Acht Klauseln machen den Unterschied zwischen geordneter Migration und stillstehendem Prozess: von Deprecation-Vorlauf über Datenexport bis zum Verfügbarkeits-SLA. Dieser Artikel zeigt dir, welche das sind und welche Frage du dem Anbieter jeweils stellst.
Der Vertrag mit deinem KI-Anbieter ist die Versicherung gegen die Abschaltung, die du nicht kommen siehst. Foto: Cytonn Photography auf Pexels
Warum entscheidet der Vertrag mit deinem KI-Anbieter über deine Betriebssicherheit?
Weil der Anbieter jederzeit Modelle ändern, verteuern oder abschalten kann und nur dein Vertrag festlegt, was du dann verlangen darfst. Eine saubere technische Integration nützt wenig, wenn das zugrunde liegende Modell ohne Vorwarnung verschwindet und du keinen vertraglichen Anspruch auf Vorlauf, Datenexport oder ein Nachfolgemodell hast.
Im Mittelstand hängen an einem Modell oft mehr Prozesse, als die Geschäftsführung auf dem Schirm hat: Angebotstexte, Kundenkommunikation, interne Recherche, Dokumentenprüfung. Fällt das Modell aus, fällt die Kette aus. Der Vertrag ist der Punkt, an dem du dieses Risiko vorab begrenzt, statt im Ernstfall zu verhandeln, wenn du keine Verhandlungsmacht mehr hast.
Was ist im Juni 2026 passiert und warum betrifft dich das?
Am 12. Juni 2026 zwang die US-Regierung Anthropic per Exportkontroll-Anordnung, die Modelle Claude Fable 5 und Mythos 5 abzuschalten. claude-opus-4-8, claude-sonnet-4-6 und claude-haiku-4-5 liefen weiter, aber wer seinen Prozess fest auf claude-fable-5 verdrahtet hatte, stand von einem Tag auf den anderen ohne sein Modell da. Wir haben den Ablauf in der Chronik unserer Fable-5-Statusseite beschrieben, wie die Exportkontroll-Anordnung vom 12. Juni 2026 zwei Modelle abschaltete.
Das war keine Insolvenz und kein Hackerangriff, sondern eine behördliche Anordnung. Genau dieser Fall steht in den wenigsten Standardverträgen sauber geregelt. Je nach Vertrag und anwendbarem Recht kann eine solche Anordnung als höhere Gewalt gelten und den Anbieter aus der Haftung nehmen, weshalb du diesen Fall ausdrücklich regeln solltest. Wenn du wissen willst, welche Modelle weiterliefen und welche zu welchem Preis ersetzbar waren, hilft der Vergleich Claude Fable 5 vs. Opus 4.8.
Ein Modell, ein Anbieter, und eine einzige Anordnung legt beides still: Das Klumpenrisiko ist kein theoretisches Szenario mehr, sondern ein dokumentierter Vorfall.
Welche Deprecation- und Vorlauf-Klausel brauchst du gegen plötzliche Modell-Abschaltungen?
Du brauchst eine Klausel, die dem Anbieter einen festen, schriftlichen Mindest-Vorlauf vor jeder Modell-Abkündigung vorschreibt und ein benanntes Nachfolgemodell zusagt. Ohne diese Zusage kann ein Anbieter ein Modell mit kurzer Frist abkündigen, und du trägst den vollen Migrationsdruck allein.
Eine starre Monatszahl lässt sich pauschal nicht festlegen, weil dein Aufwand von der Integrationstiefe abhängt. Für kritische Prozesse sind sechs bis zwölf Monate ein sinnvoller Verhandlungsanker. Genauso wichtig ist, dass der Vorlauf das migrationsfähige Nachfolgemodell mitbenennt, sonst weißt du zwar, wann das alte Modell verschwindet, aber nicht, wohin du migrieren sollst. Welches Modell als Ersatz taugt, ordnet unser Vergleich der KI-Assistenten für den Mittelstand ein.
Wie sichern dir Exit-, Notfall-Migrations- und Datenexport-Klauseln den Weiterbetrieb?
Diese drei Klauseln stellen sicher, dass du beim Wechsel des Anbieters deine Daten mitnimmst und genug Zeit für die Umstellung hast. Eine Exit-Klausel mit Übergangsfrist verhindert, dass dein Zugang am Tag der Kündigung hart abgeschaltet wird. Eine Notfall-Migrations-Regel greift, wenn der Anbieter selbst ausfällt, etwa durch eine Abschaltung wie am 12. Juni.
Die Datenexport-Klausel ist der unterschätzte Teil. Sie legt fest, in welchem Format und in welcher Frist du Embeddings, Fine-Tuning-Daten, Logs und Konfigurationen zurückbekommst und wann der Anbieter sie löscht. Achte darauf, dass Embeddings eines abgeschalteten Modells oft nicht direkt auf ein anderes Modell passen und neu berechnet werden müssen. Wie sich der dahinterliegende Vendor-Lock-in und seine Kostenseite auflösen lassen, zeigen wir unter Token-Kosten und Vendor-Lock-in im Griff behalten.
Was muss ein Verfügbarkeits-SLA abdecken, auch bei behördlicher Abschaltung?
Ein belastbares SLA nennt eine konkrete Verfügbarkeitszusage, Reaktions- und Wiederherstellungszeiten und Service-Credits bei Unterschreitung. Entscheidend ist die Frage, wie der Vertrag mit höherer Gewalt und behördlichen Anordnungen umgeht, denn genau hier verstecken sich die Haftungsausschlüsse.
Viele Standard-SLAs nehmen den Anbieter bei höherer Gewalt komplett aus der Pflicht. Eine behördliche Modell-Abschaltung kann darunter fallen. Du willst deshalb geregelt haben, was in diesem Fall passiert: Bekommst du Zugang zu einem Ersatzmodell, gibt es Service-Credits, gilt eine Sonderkündigung? Verlass dich nicht darauf, dass der Anbieter das von sich aus fair regelt. Du verhandelst es oder es steht nicht drin.
Welche DSGVO-Klauseln gehören in jeden KI-Vertrag (AVV, Datenresidenz, Subprozessoren)?
In jeden Vertrag gehören ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO, eine wählbare Datenresidenz und eine transparente Subprozessor-Liste mit Änderungsanzeige. Diese drei Bausteine sind die Pflichtgrundlage, sobald personenbezogene Daten durch das Modell laufen, und das tun sie in fast jedem realen Einsatz.
Bei der Datenresidenz hilft, dass Claude über mehrere Wege verfügbar ist: direkte Anthropic-API, Amazon Bedrock, Google Vertex AI und Microsoft Foundry. Bedrock und Vertex bieten EU-Regionen, die Datenresidenz ist also wählbar. Eine EU-Region allein macht den Einsatz aber noch nicht DSGVO-konform. Du brauchst zusätzlich den abgeschlossenen AVV und Klarheit über mögliche Drittlandtransfers zum US-Mutterkonzern. Bei Subprozessoren zählt nicht nur die aktuelle Liste, sondern das Recht, über Änderungen vorab informiert zu werden und widersprechen zu können.
Was regeln Trainings- und Retention-Klauseln und worauf musst du achten?
Trainings-Klauseln regeln, ob der Anbieter deine Eingaben zum Training seiner Modelle nutzen darf. Retention-Klauseln regeln, wie lange er deine Daten speichert. Für Geschäftsdaten willst du ein schriftliches Opt-out vom Training und eine klar definierte, kurze Aufbewahrungsfrist.
Verlass dich hier nicht auf die Voreinstellung oder eine Marketing-Aussage auf der Website. Was zählt, ist die vertragliche Zusage. Lass dir schriftlich geben, dass deine Inhalte nicht ins Training fließen, und lass die Speicherdauer und den Löschmechanismus konkret benennen. Bei sensiblen Daten ist das kein Komfort, sondern eine Voraussetzung für den Einsatz überhaupt.
Wie ordnest du den EU AI Act vertraglich ein, ohne dich auf Marketing zu verlassen?
Du ordnest ihn ein, indem du deine konkrete Anwendung einer Risikoklasse zuordnest und die daraus folgenden Pflichten vertraglich auf den Anbieter abbildest, etwa Zusicherungen zu technischer Dokumentation und Konformität. Was du nicht tun solltest, ist dich auf ein Werbeversprechen wie “AI-Act-ready” zu verlassen, denn das ist keine vertragliche Zusage.
Ob und wie stark dich der EU AI Act trifft, hängt vom Einsatzzweck ab. Ein internes Recherche-Tool wird anders eingestuft als ein System, das über Menschen entscheidet. Diese Einordnung ist eine juristische Frage, keine technische. Dieser Artikel ersetzt keine Rechtsberatung. Kläre die konkrete Risikoklasse und die daraus folgenden Pflichten mit einer fachkundigen Kanzlei und lass die Zusicherungen dann in den Vertrag schreiben.
Welche Klauseln gehören in deinen KI-Vendor-Vertrag (Übersicht mit Prüf-Fragen)?
Die folgende Tabelle fasst die acht Kern-Bausteine zusammen. Spalte drei enthält jeweils eine konkrete, verhandelbare Frage, die du dem Anbieter so stellen kannst.
| Klausel | Warum du sie brauchst | Prüf-Frage an den Anbieter |
|---|---|---|
| Modell-Deprecation-Vorlauf | Schützt vor plötzlicher Abschaltung ohne Zeit zum Umstellen | Wie viele Monate Vorlauf garantiert ihr schriftlich vor einer Modell-Abkündigung, und wird ein migrationsfähiges Nachfolgemodell benannt? |
| Notfall-Migration und Exit | Sichert geordneten Wechsel statt hartem Abschalten bei Kündigung oder Anbieterausfall | Welche Übergangsfrist und welche Unterstützung beim Wechsel sagt ihr zu, wenn wir oder ihr den Vertrag beenden? |
| Datenexport und Portabilität | Stellt sicher, dass du Daten und Embeddings nutzbar mitnimmst | In welchem Format und in welcher Frist liefert ihr unsere Daten, Embeddings und Logs zurück, und wann werden sie gelöscht? |
| Verfügbarkeits-SLA inkl. behördlicher Abschaltung | Regelt Ausfall und höhere Gewalt statt sie offenzulassen | Welche Verfügbarkeit sagt ihr zu, und was passiert konkret bei einer behördlichen Abschaltung oder höherer Gewalt? |
| Datenresidenz und AVV (DSGVO) | Pflichtgrundlage, sobald personenbezogene Daten durchs Modell laufen | Stellt ihr einen AVV nach Art. 28 bereit, und in welcher Region werden unsere Daten verarbeitet? |
| Subprozessor-Transparenz und Änderungsanzeige | Macht die Verarbeitungskette nachvollziehbar und widerspruchsfähig | Wo finden wir die aktuelle Subprozessor-Liste, und wie früh kündigt ihr Änderungen an? |
| Trainings- und Retention-Klauseln | Verhindert ungewollte Nutzung deiner Daten und unklare Speicherdauer | Bestätigt ihr schriftlich, dass unsere Inhalte nicht ins Training fließen, und wie lange speichert ihr sie? |
| Haftung und Service-Credits | Gibt der Verfügbarkeitszusage finanzielles Gewicht | Welche Service-Credits oder Haftung greifen bei Unterschreitung des SLA, und gibt es Haftungsobergrenzen? |
Wie führst du den Vertrags-Review in der Praxis durch?
Geh den Review strukturiert und mit der Fachabteilung durch, nicht als reine Einkaufsformalität. Die folgende Reihenfolge bringt dich von der Bestandsaufnahme bis zur rechtlichen Gegenprüfung.
Vertrags-Review in 8 Schritten
- Bestandsaufnahme: Liste auf, welche Modelle und Anbieter du nutzt und welche Prozesse daran hängen, und stufe jeden nach Kritikalität ein.
- Prüfe die Deprecation- und Vorlauf-Klausel und fixiere einen schriftlichen Mindest-Vorlauf für die kritischen Modelle.
- Verankere ein Exit- und Notfall-Migrations-Recht inklusive einer konkreten Übergangsfrist.
- Kläre Datenexport-Format, Rückgabe und Löschung am Vertragsende und teste den Export einmal real.
- Spiegele das Verfügbarkeits-SLA gegen reale Ausfallszenarien, auch gegen eine behördliche Abschaltung.
- Fordere AVV, Datenresidenz und die Subprozessor-Liste an und prüfe sie auf DSGVO-Konformität.
- Lass dir Trainings-Opt-out und Aufbewahrungsfristen schriftlich bestätigen.
- Lies das Ergebnis mit IT, Fachabteilung und Rechtsberatung gegen und prüfe parallel deine technische Resilienz wie Abstraktionsschicht und Fallback.
Wie verzahnst du Verträge mit deiner technischen Resilienz?
Verträge und Technik sind zwei Seiten desselben Schutzes: Die Klauseln geben dir das Recht auf Vorlauf und Export, die Technik macht dich schnell genug, dieses Recht auch zu nutzen. Eine Abstraktionsschicht zwischen deinem Code und dem Modell sorgt dafür, dass ein Modellwechsel eine Konfigurationsänderung bleibt und kein Umbau.
Konkret stützt du dich auf einen Adapter, der mehrere Anbieter und Regionen kapselt, einen Kill-Switch per Feature-Flag, einen Circuit Breaker und automatischen Fallback auf ein Ersatzmodell, abgesichert durch einen Smoke-Test nach jedem Wechsel. Modell-Routing nach Aufgabentyp und Kostenhebel wie Prompt-Caching oder die Batch-API runden das ab. Wer KI-gestützte Prozesse absichern will und dafür Unterstützung sucht, findet sie beim Performance-Marketing-Team von Collective Brain.
Häufige Fragen
Was ist der Unterschied zwischen einem AVV und einem SLA bei KI-Anbietern?
Ein AVV (Auftragsverarbeitungsvertrag nach Art. 28 DSGVO) regelt, wie der Anbieter mit deinen personenbezogenen Daten umgeht: Zweckbindung, Subprozessoren, Löschung. Ein SLA (Service Level Agreement) regelt die technische Leistung: Verfügbarkeit, Reaktionszeiten, Service-Credits bei Ausfall. Du brauchst beide, weil sie unterschiedliche Risiken abdecken. Der AVV schützt deine Datenschutz-Pflichten, das SLA deinen laufenden Betrieb.
Wie lange Vorlauf sollte eine Deprecation-Klausel mindestens vorsehen?
Eine feste Zahl gibt es nicht, weil dein Migrationsaufwand davon abhängt, wie tief das Modell in deine Prozesse eingebaut ist. In der Praxis sind sechs bis zwölf Monate schriftlicher Vorlauf ein verhandelbarer Anker für kritische Anwendungen. Wichtig ist außerdem, dass der Anbieter ein benanntes Nachfolgemodell zusagt, auf das du migrieren kannst, nicht nur ein abstraktes Abkündigungsdatum.
Reicht eine EU-Region bei Amazon Bedrock oder Google Vertex AI für DSGVO-Konformität aus?
Eine EU-Region ist ein wichtiger Baustein, aber allein nicht ausreichend. Du brauchst zusätzlich einen abgeschlossenen AVV, eine geprüfte Subprozessor-Liste und Klarheit darüber, ob ein Drittlandtransfer (etwa zu einem US-Mutterkonzern) stattfindet. Die Regionenwahl bestimmt, wo deine Daten verarbeitet werden, aber die rechtliche Bewertung hängt am gesamten Vertragswerk. Lass das von deiner Rechtsberatung prüfen.
Was passiert mit meinen Daten und Embeddings, wenn der Anbieter ein Modell abschaltet?
Das hängt davon ab, was in deinem Vertrag steht. Ohne explizite Klausel gibt es keine Garantie, dass du Embeddings, Fine-Tuning-Daten oder Logs in einem nutzbaren Format zurückbekommst. Deshalb gehört eine Datenexport- und Portabilitätsklausel in den Vertrag, die Format, Frist und Löschung nach Vertragsende festlegt. Beachte: Embeddings eines abgeschalteten Modells sind oft nicht direkt auf ein anderes Modell übertragbar und müssen neu berechnet werden.
Macht der EU AI Act zusätzliche Vertragsklauseln nötig?
Je nach Einsatzzweck kann der EU AI Act Dokumentations-, Transparenz- und Risikopflichten auslösen, die sich vertraglich auf deinen Anbieter abbilden lassen, etwa durch Zusicherungen zu technischer Dokumentation und Konformität. Ob und in welchem Umfang dich das trifft, hängt von deiner konkreten Anwendung und ihrer Risikoklasse ab. Dieser Artikel ersetzt keine Rechtsberatung; kläre die Einordnung mit einer fachkundigen Kanzlei.
Quellen & Referenzen
- Anthropic, Modellübersicht und Verfügbarkeit (Anthropic-API, Amazon Bedrock, Google Vertex AI, Microsoft Foundry). docs.anthropic.com
- Verordnung (EU) 2016/679 (DSGVO), Art. 28 zur Auftragsverarbeitung. eur-lex.europa.eu
- Verordnung (EU) 2024/1689 (EU AI Act), Risikoklassen und Pflichten. eur-lex.europa.eu
- Amazon Bedrock, EU-Regionen und Datenresidenz. docs.aws.amazon.com
- Google Cloud Vertex AI, Standorte und Datenresidenz. cloud.google.com
