Anbieterwechsel bei KI: Welche Daten und Vorlagen bleiben nutzbar?

Ein KI-Anbieterwechsel ist erst praktisch geprüft, wenn die benötigte Arbeit im neuen System mit den übertragenen Daten und Regeln funktioniert. Ein heruntergeladenes Archiv beweist nur, dass Dateien vorliegen. Es zeigt noch nicht, ob Quellenbezüge, Zugriffsrechte, Vorlagen und Prüffälle erhalten bleiben. Diese Bestandteile müssen vor der Beschaffung und erneut vor dem tatsächlichen Wechsel betrachtet werden.

Der folgende Exit-Check ist ein eigener Praxisvorschlag für Teams, die KI in wiederkehrenden Arbeitsabläufen einsetzen. Er behandelt technische und organisatorische Nutzbarkeit. Vertragliche Ansprüche auf Datenexport oder Löschung sind nicht Gegenstand des Artikels; dafür müssen die tatsächlich geltenden Vereinbarungen separat geprüft werden. Alle Mengen und Systembezeichnungen im Beispiel sind fiktiv.

Definiere die Arbeit, die nach dem Wechsel weitergehen muss

Beginne nicht mit der Liste verfügbarer Exportformate. Beschreibe zuerst die Aufgaben, die das neue System übernehmen muss. Ein Wissensassistent braucht andere Bestandteile als eine reine Schreibvorlage. Ein Dokumentenworkflow kann zusätzlich Zuordnungen, Freigabestatus und Verbindungen zu Fachsystemen benötigen. Der Umfang ergibt sich aus der Arbeit, nicht aus dem Exportmenü.

Lege für jede Aufgabe ein überprüfbares Ergebnis fest. Beispielsweise muss eine neue Person eine freigegebene Quelle finden, einen Entwurf mit Fundstelle erzeugen und ihn im vorgesehenen Prozess prüfen. Diese Abnahme verbindet Daten und Nutzung. Ein technisch erfolgreicher Import ohne diesen Test lässt die eigentliche Frage offen.

Halte ausserdem fest, welche historischen Daten wirklich benötigt werden. Nicht jeder alte Chat gehört in das neue System. Für Nachvollziehbarkeit relevante Vorgänge können andere Anforderungen haben als verworfene Versuche. Die Auswahl muss nach den geltenden internen Regeln erfolgen. Ein Anbieterwechsel ist kein Anlass, vorsorglich alle Inhalte in eine neue Umgebung zu kopieren.

Unterscheide Daten, Bedeutung und Verhalten

Ein Export kann den Text einer Vorlage enthalten, aber ihre hinterlegte Dateiauswahl verlieren. Er kann Dokumente enthalten, aber keine Zugriffsgruppen. Er kann einen Gesprächsverlauf enthalten, aber nicht die damals verwendete Modellkonfiguration. Diese Unterschiede müssen in der Bestandsaufnahme sichtbar sein.

RFC 8259 zu JSON beschreibt ein strukturiertes Datenaustauschformat. Daraus folgt keine semantische Gleichheit zwischen Anwendungen. Auch die W3C-Empfehlung Data on the Web Best Practices zu Formaten und Metadaten garantiert keine vollständige Migration zwischen KI-Anbietern. Beide Quellen stützen die Bedeutung lesbarer, beschriebener Daten; der konkrete Wechseltest bleibt eine eigene Aufgabe.

Für die Planung trenne daher drei Fragen: Sind die Inhalte zugänglich? Ist ihre Bedeutung dokumentiert? Funktioniert die benötigte Verarbeitung im Zielsystem? Eine positive Antwort auf die erste Frage beantwortet die beiden anderen nicht. Diese Trennung verhindert, dass ein Exporthäkchen im Beschaffungsbogen als vollständiger Exit-Nachweis gilt.

Erstelle ein Inventar der benötigten Bestandteile

Das Inventar enthält die für die ausgewählten Arbeitsabläufe tatsächlich nötigen Objekte. Nutze vorhandene Register und ergänze fehlende Beziehungen dort. Eine zweite, dauerhaft getrennte Liste erzeugt bei späteren Änderungen neue Abweichungen. Die folgende Tabelle ist ein eigenes Muster für die Prüfung.

Ein nicht exportierbarer Bestandteil ist zunächst eine Lücke, kein automatisches Ausschlusskriterium. Vielleicht lässt er sich aus einer anderen verbindlichen Quelle neu aufbauen. Dann müssen Aufwand, Verantwortung und Prüfung dokumentiert werden. Ohne diesen Ersatzweg bleibt die benötigte Funktion offen.

Ein fiktives Paket mit einer versteckten Abhängigkeit

Ein Team plant den Wechsel seines Wissensassistenten. Es exportiert zwanzig Dokumente und acht Arbeitsvorlagen. Alle Dateien lassen sich öffnen. Beim ersten Import fehlen jedoch die Zuordnungen zu zwei Produktvarianten. Der neue Assistent kann deshalb auf eine Frage die richtige Aussage aus der falschen Variante liefern.

Der Export war technisch lesbar, aber für die Aufgabe noch unvollständig. Das Team ergänzt die Zuordnungen aus dem führenden Dokumentenregister und prüft sie an jeder betroffenen Quelle. Es erfindet keine Varianten anhand ähnlicher Dateinamen. Anschliessend werden Fragen mit eindeutiger und fehlender Produktangabe getestet.

Eine zweite Abhängigkeit liegt in einer Vorlage, die einen bestimmten Dokumentenabruf erwartet. Das neue Werkzeug bietet diesen Abruf nicht in derselben Form. Der fachliche Kern bleibt nutzbar, die technische Ausführung muss jedoch neu gebaut werden. Bis zur Prüfung erhält diese Vorlage keinen aktiven Status im Zielsystem.

Das Beispiel zeigt, warum Mengenvergleiche allein nicht genügen. Zwanzig exportierte und zwanzig importierte Dateien können trotzdem eine wichtige Beziehung verlieren. Prüfe deshalb neben der Anzahl auch Kennungen, Metadaten und die tatsächliche Verwendung. Für die Pflege solcher Abhängigkeiten ergänzt Prompt-Wikis mit klarer Verantwortung den organisatorischen Rahmen.

Prüfe Dateilesbarkeit und Beziehungen getrennt

Öffne eine Auswahl unterschiedlicher Dateitypen und kontrolliere, ob Inhalt und Struktur erhalten sind. Bei Tabellen zählen auch Datentypen, leere Werte und Zeichenkodierung. Bei Dokumenten sind Tabellen, Überschriften und Fundstellen relevant, wenn die spätere Aufgabe sie benötigt. Eine Dateiendung allein sagt nichts über die korrekte Verarbeitung aus.

Prüfe danach die Beziehungen: Verweist eine Vorlage noch auf die richtige Quelle? Bleibt eine überarbeitete Fassung mit ihrem Vorgänger verbunden? Ist der Freigabestatus verständlich? Ein Import kann einzelne Objekte korrekt übernehmen und ihre Verknüpfung verlieren. Gerade diese zweite Prüfung wird leicht übersehen, weil die Oberfläche bereits gefüllt aussieht.

Der Beitrag CSV-Importe mit KI vorbereiten behandelt typische Übergabefehler bei strukturierten Daten. Für den Anbieterwechsel kommt die fachliche Bedeutung hinzu. Ein Statuscode aus dem alten System muss im neuen System ausdrücklich zugeordnet werden. Eine ähnliche Bezeichnung reicht als Nachweis nicht aus.

Übertrage Rechte nicht durch Vermutung

Ein Export enthält nicht automatisch die wirksamen Berechtigungen des Ursprungssystems. Prüfe, welche Gruppen und Einzelrechte tatsächlich übertragen werden und welche neu eingerichtet werden müssen. Ein für Administratoren lesbarer Import kann für den späteren Einsatz zu weit offen oder unzugänglich sein.

Teste mit den vorgesehenen Rollen. Eine Person mit Zugriff auf Produktgruppe A darf nicht allein durch den Wechsel Dokumente aus Gruppe B erhalten. Ebenso muss sie die für ihre Aufgabe nötigen Quellen weiterhin erreichen. Beide Richtungen gehören zur Abnahme: unzulässige Sichtbarkeit verhindern und erlaubte Arbeit ermöglichen.

Die fachliche Zuordnung der Rechte bleibt eine eigene Entscheidung. Ein Modell darf sie nicht aus bisherigen Chatverläufen oder vermuteten Teamzugehörigkeiten ableiten. Der Artikel Zugriffsrechte für KI-Wissensassistenten ergänzt die technische und organisatorische Prüfung dieses Bereichs.

Nutze dieselben Prüffälle vor und nach dem Wechsel

Lege vor dem Wechsel einen kleinen, aussagekräftigen Satz von Arbeitsfällen fest. Dazu gehören normale Aufgaben, fehlende Angaben, widersprüchliche Quellen und nicht erlaubte Zugriffe. Dokumentiere die erwarteten Ergebnisse unabhängig vom Wortlaut der bisherigen Antwort. Sonst wird die alte Formulierung mit fachlicher Richtigkeit verwechselt.

Im Zielsystem prüfst du dieselben Anforderungen. Unterschiedliche Formulierungen sind zulässig, wenn Bedeutung, Quellenbezug und Grenzen erhalten bleiben. Eine neue Antwort kann besser lesbar und trotzdem fachlich schlechter sein. Bewerte deshalb die vorher festgelegten Kriterien einzeln und halte neue Fehlerarten fest.

KI-Vorlagen nach einem Modellwechsel testen beschreibt diesen Vergleich für Modelländerungen. Ein Anbieterwechsel kann zusätzlich Datenzugriff, Oberfläche und Ausführung verändern. Teste diese Bestandteile getrennt genug, um Fehler zuordnen zu können. Ein pauschaler Gesamteindruck erklärt nicht, welche Abhängigkeit noch fehlt.

Plane den Übergang und den Rückweg

Lege fest, welche Vorgänge im alten System abgeschlossen werden und welche im neuen beginnen. Ohne diese Grenze können beide Systeme denselben Fall bearbeiten. Eine doppelte Freigabe oder Nachricht ist dann kein Modellfehler, sondern ein ungeklärter Übergang. Die Zuständigkeit für laufende Fälle muss vor dem Umschalten feststehen.

Ein Rückweg braucht ebenfalls konkrete Bedingungen. Welche Daten sind seit dem Wechsel neu entstanden? Wie werden sie bei einer Rückkehr behandelt? Ein altes Backup allein stellt nicht automatisch den aktuellen Arbeitsstand wieder her. Prüfe den Rückweg in einem freigegebenen Testumfang, bevor er als betriebliche Absicherung bezeichnet wird.

Wenn kein praktikabler Rückweg besteht, muss diese Einschränkung in der Entscheidung sichtbar sein. Dann kann ein begrenzter Start mit wenigen Aufgaben die Folgen überschaubar halten. Das ist eine eigene Empfehlung zur kontrollierten Einführung, keine Garantie gegen Ausfälle. Umfang und Freigabe richten sich nach den tatsächlichen Fehlerkosten.

Erfasse Wechselaufwand als eigene Grösse

Zum Wechsel gehören nicht nur Lizenzkosten. Die Bestandsaufnahme, Datenkorrektur, Neuzuordnung von Rechten und erneute fachliche Prüfung benötigen Arbeit. Erfasse gemessenen Aufwand getrennt von Schätzungen für noch offene Aufgaben. Eine pauschale Zahl ohne Umfang und Annahmen hilft bei der Entscheidung wenig.

Dokumentiere besonders manuelle Schritte, die bei jedem späteren Wechsel erneut anfallen. Wenn eine Vorlage nur durch langes Ausprobieren rekonstruierbar ist, fehlt portable Dokumentation. Wenn Produktzuordnungen nur in Köpfen existieren, fehlt ein verbindlicher Datenbestand. Diese Befunde sind konkrete Verbesserungsaufträge, auch wenn der aktuelle Wechsel noch nicht beschlossen ist.

Die Auswahl eines neuen Systems darf diese Kosten berücksichtigen, ohne daraus eine pauschale Bindung an den bisherigen Anbieter abzuleiten. Ein Wechsel kann trotz Aufwand sinnvoll sein. Massgeblich für eine nachvollziehbare Bewertung sind die benötigte Funktion, der geprüfte Umfang und die offen benannten Abhängigkeiten.

Prüfe einen Export vor einer Kündigungsentscheidung

Wenn ein Wechsel konkret wird, führe den begrenzten Export- und Importversuch vor dem Verlust des bisherigen Zugangs durch. Die tatsächlichen Vertrags- und Zugriffsbedingungen müssen dafür geprüft sein. Ein später entdecktes fehlendes Feld lässt sich schwerer klären, wenn die alte Oberfläche nicht mehr erreichbar ist.

Bewahre die Nachweise des Tests im vorgesehenen Projektprotokoll auf. Dazu gehören Exportumfang, verwendete Fassung und beobachtete Lücken. Zugangsdaten gehören nicht in dieses Protokoll. Ein reproduzierbarer Test braucht die Beschreibung des Zugriffswegs, aber keine im Klartext gespeicherten Geheimnisse.

Die verantwortliche Person entscheidet anhand dieser Ergebnisse, ob der Übergang freigegeben ist oder zunächst eine Lücke geschlossen werden muss. Ein technisch lesbares Archiv kann als Teilergebnis bestehen bleiben. Die Freigabe der eigentlichen Umstellung folgt erst nach dem vereinbarten Funktionstest und der geklärten Behandlung laufender Vorgänge.

Was als abgeschlossener Exit-Test gilt

Ein Exit-Test besteht, wenn die ausgewählten Arbeitsabläufe mit den übertragenen Bestandteilen im Zielsystem fachlich richtig und mit den vorgesehenen Rechten funktionieren. Die Ergebnisse müssen sichtbar geprüft sein. Nicht getestete Funktionen bleiben ausdrücklich ausserhalb der Abnahme. Ein kleiner erfolgreicher Versuch ist kein Nachweis für die vollständige Migration aller Unternehmensdaten.

Halte im bestehenden Entscheidungsprotokoll fest, welche Daten, Vorlagen und Rollen geprüft wurden, welche Lücken bleiben und wer sie bearbeitet. Damit erhält die Beschaffung einen konkreten Nachweis statt einer allgemeinen Exportzusage. Vor einem echten Wechsel wird dieser Nachweis mit dem dann aktuellen Bestand erneuert. Erst die wieder ausgeführte Arbeit zeigt, welche Teile tatsächlich nutzbar geblieben sind.