Suche

Wonach suchen Sie?

Durchsuchen Sie Leistungen, Anwendungsfälle und unser Praxiswissen.

Mindestens 2 Zeichen eingeben

Beliebte Einstiege

Daten & Governance

Was passiert bei Vertragsende oder Anbieterwechsel mit Daten und Konfigurationen?

Ein Anbieterwechsel scheitert selten nur am Modell. Abhängigkeiten stecken in Datenformaten, Prompt-Logik, Vektorspeichern, Identitäten, Evaluationen, Connectors und Betriebswissen.

Die kurze Antwort

Vor Vertragsende muss festgelegt sein, welche Daten und Konfigurationen exportierbar sind, wie lange der Zugriff bleibt, wie Migration und Weiterbetrieb funktionieren und wie Anbieter und Unterauftragnehmer verbleibende Kopien löschen. Der Abschluss sollte technisch und organisatorisch nachgewiesen werden.

Kurz zusammengefasst

  • Exit-Anforderungen gehören vor Vertragsabschluss in Architektur und Vertrag.
  • Nicht nur Dokumente, sondern auch Prompts, Konfigurationen, Rechte, Tests und Logs sind migrationsrelevant.
  • Exportierbarkeit bedeutet noch nicht, dass ein anderes System das Format ohne Umbau nutzen kann.
  • Löschung, Zugriffsentzug und verbleibende Backups müssen überprüfbar abgeschlossen werden.

Was tatsächlich mitgenommen werden muss

Ein vollständiger Exit umfasst Geschäftsdaten, Anwendungslogik und Betriebsnachweise. Je stärker proprietäre Plattformfunktionen genutzt werden, desto mehr muss vorab geklärt werden.

Was tatsächlich mitgenommen werden muss
Exit-ArtefaktPortables Format oder ErsatzTest vor VertragsendeAbschlussnachweis
Quelldaten und BerechtigungenOffene Dokument- oder Datenformate plus exportierbare BerechtigungszuordnungAnzahl, Versionen und repräsentative Zugriffsfälle in neutraler Umgebung abgleichen.Letzter konsistenter Export, Prüfsumme und Abnahme durch den Data Owner.
Prompts, Workflows und Agent-KonfigurationVersionierte Texte, Schemas, Regeln und Tool-Definitionen ausserhalb proprietärer EditorenEinen produktiven Ablauf ohne den visuellen Baukasten des Anbieters rekonstruieren.Repository-Version, Abhängigkeitsliste und dokumentierte nicht portable Funktionen.
Indizes und EmbeddingsDokumentiertes Exportformat oder reproduzierbarer Neuaufbau aus freigegebenen QuellenEinen Teilbestand neu aufbauen und Retrieval-Qualität sowie Rechte vergleichen.Runbook, Quellenstand und Qualitätsbaseline für den Neuaufbau.
Evaluationen und BetriebsnachweiseTestfälle, Sollresultate, Feedback, Logs, Kosten und VorfallhistorieDasselbe Release-Gate und denselben Betriebsreport in der Zielumgebung ausführen.Abgenommener Vergleich, aufbewahrte Audit-Nachweise und Owner für offene Punkte.
Konten und verbleibende KopienEntzugsliste und vertraglicher Löschprozess für Live-Daten, Backups und UnterauftragnehmerEin Testkonto deaktivieren und prüfen, dass Integrationen und Schlüssel nicht mehr funktionieren.Entzugsprotokoll, Löschbestätigung, bekannte Backup-Fristen und Restrisikoentscheid.

Der Vertrag muss den Ausstieg ermöglichen

Allgemeine Löschzusagen genügen nicht. Fristen, Formate, Unterstützung, Kosten und Behandlung von Backups und Unterauftragnehmern sollten konkret geregelt sein.

  • Exportformate, Schnittstellen und Zeitraum für den Zugriff nach Kündigung
  • Unterstützung bei Migration und definierte Kosten
  • Löschfristen für aktive Systeme, Backups und Unterauftragnehmer
  • Nachweis oder Bestätigung der Löschung
  • Fortgeltung von Vertraulichkeit, Sicherheit und Vorfallmeldung
  • Regeln bei Insolvenz, Dienstende oder kurzfristiger Sperrung

Portabilität muss praktisch getestet werden

Ein Export kann vollständig und trotzdem kaum nutzbar sein. Ein früher Probelauf zeigt, ob Inhalte, Rechte und Konfigurationen lesbar, vollständig und rekonstruierbar sind.

  1. Schritt 1

    Inventarisieren

    Alle Daten, Konfigurationen, Schlüssel und Abhängigkeiten dem System zuordnen.

  2. Schritt 2

    Probeexport durchführen

    Dateien und Metadaten herunterladen und auf Vollständigkeit prüfen.

  3. Schritt 3

    Wiederherstellung testen

    Einen kleinen Teil in einer neutralen oder alternativen Umgebung rekonstruieren.

  4. Schritt 4

    Abweichungen dokumentieren

    Nicht portable Funktionen und nötige Umbauten sichtbar machen.

Der Exit endet mit kontrollierter Stilllegung

Nach der Migration müssen alte Integrationen, Konten und Schlüssel deaktiviert werden. Verbleibende Daten und Aufbewahrungspflichten werden abgeglichen; der Abschluss landet im AI-Inventar und in den Betriebsnachweisen.

  • Schreibzugriffe stoppen und letzten konsistenten Export erstellen.
  • Benutzer, Servicekonten, API-Schlüssel und Single-Sign-on-Verbindungen entziehen.
  • Webhooks, Connectors und Datenlieferungen deaktivieren.
  • Löschbestätigung und bekannte Backup-Fristen sichern.
  • Monitoring auf Restverkehr und fehlgeschlagene Abhängigkeiten prüfen.
  • Verantwortliche bestätigen Migration, Löschung und Abschluss.
Beispiel aus dem Unternehmensalltag

Beispiel: Wechsel eines Wissensassistenten

Ein Unternehmen besitzt die Originaldokumente, hat aber keine exportierbaren Quellenberechtigungen oder Testfälle. Vor dem Wechsel rekonstruiert es deshalb die Berechtigungsmatrix, exportiert Prompts und Feedback und baut den Index beim neuen Anbieter aus den Originalquellen neu auf. Erst nach bestandenem Paralleltest werden Schlüssel entzogen und die Löschung beim alten Anbieter bestätigt.

Was Sie mitnehmen sollten

Testen Sie Export und Wiederaufbau, solange die Beziehung zum Anbieter normal läuft. Ein Exit-Plan ist erst belastbar, wenn Daten, Logik, Rechte und Betrieb praktisch migrierbar sind.

Quellen und Vertiefung

Diese Primärquellen vertiefen Definitionen, technische Grundlagen oder verantwortlichen Einsatz.

Inhaltlich geprüft

Stand: 17. Juli 2026. Allgemeine Einordnung, keine Rechtsberatung. Die konkrete Rechtslage und der anwendbare Geltungsbereich sind für den jeweiligen Einsatz zu prüfen.

Sie möchten das auf Ihre Situation übertragen?

Wir klären gemeinsam, was für Ihren Prozess, Ihre Daten und Ihre Systeme sinnvoll ist – verständlich und ohne unnötige Komplexität.

Projekt besprechen