Dieser Beitrag wurde mit KI-Unterstützung erstellt, fachlich geprüft und redaktionell freigegeben.

Artikelbild-Kennzeichnung: AI GENERATED

Ein Anbieterwechsel bei KI beginnt selten mit der Frage, welches Modell die bessere Antwort schreibt. In einer österreichischen Tischlerei kann ein Assistent Angebotsentwürfe strukturieren, im Tourismusbetrieb beantwortet er wiederkehrende Gästeanfragen, in der Steuerkanzlei fasst er interne Notizen zusammen. Sobald ein Tool mit Kundendaten, Fachwissen oder einem Website-Workflow verbunden ist, verändert ein Wechsel jedoch Datenwege, Zuständigkeiten und Kontrollmöglichkeiten. Wer nur Preis, Geschwindigkeit und Demo vergleicht, bemerkt kritische Unterschiede oft erst nach dem Umzug.

Ein Governance-Prüfplan macht die Entscheidung handhabbar. Er übersetzt die abstrakte Frage „Welcher KI-Anbieter ist besser?“ in überprüfbare Arbeitspakete: Welcher konkrete Einsatz soll weiterlaufen? Welche Daten gelangen wohin? Wer darf Ergebnisse freigeben? Was geschieht bei einer falschen, unvollständigen oder nicht verfügbaren Antwort? Das Ziel ist nicht, jede Unsicherheit auszuschließen. Ziel ist eine nachvollziehbare Entscheidung, die zum eigenen Betrieb und zum tatsächlichen Risiko passt.

Erst den Einsatz verstehen, dann Anbieter vergleichen

Ein Wechselprojekt braucht ein klares Objekt. „Wir verwenden KI im Unternehmen“ ist dafür zu unscharf. Listen Sie pro Einsatzfall Zweck, Nutzergruppe, Eingaben, Ausgabe, angebundene Systeme und die zuständige Person auf. Ein Vertriebsassistent, der nur öffentliche Produktmerkmale zu einem Entwurf kombiniert, ist etwas anderes als ein Support-Chat, der Bestellnummern entgegennimmt oder ein Tool, das Bewerbungsunterlagen zusammenfasst. Die Bestandsaufnahme sollte deshalb auch Testzugänge, Browser-Erweiterungen, Automationen und Funktionen in bestehender Software erfassen. Praktische Hilfestellung für diese erste Inventur gibt auch unser Beitrag KI-Kompetenz nach AI Act für KMU in Österreich.

Ordnen Sie danach jeden Einsatzfall einer einfachen Risikostufe zu. Niedrig ist etwa ein interner Ideenentwurf ohne personenbezogene oder vertrauliche Eingaben. Mittel kann ein Entwurf für Kundenkommunikation sein, den ein Mensch verbindlich prüft. Hoch ist ein Prozess, dessen Ergebnis Preis, Vertrag, Personal, Gesundheit, Bonität oder Sicherheitsentscheidungen beeinflusst. Diese Einteilung ist keine Rechtsbewertung. Sie verhindert aber den typischen Fehler, einen öffentlich sichtbaren Chatbot mit derselben Testtiefe zu behandeln wie eine interne Ideensammlung.

Für die Organisation ist außerdem wichtig: Nicht der Einkauf allein entscheidet. Die fachliche Eigentümerin oder der fachliche Eigentümer beschreibt den Zweck, IT prüft Anbindungen und Rechte, Datenschutz oder externe Beratung bewertet die Datenverarbeitung, und die Geschäftsführung akzeptiert verbleibende Risiken. Die EU-KI-Verordnung verlangt von Anbietern und Betreibern, nach bestem Bemühen ein ausreichendes Maß an KI-Kompetenz bei den beteiligten Personen sicherzustellen. Ein kurzer, rollenbezogener Wechsel-Workshop ist dafür deutlich wirksamer als eine allgemeine Tool-Ankündigung.

Der Prüfplan in sieben Arbeitsschritten

1. Entscheidungskriterien vor der Demo festlegen

Schreiben Sie vor Gesprächen mit Anbietern eine gewichtete Liste. Für einen kleinen Hersteller können verlässliche Quellenbezüge, deutschsprachige Bedienung, Rollenrechte und eine klare Exportmöglichkeit wichtiger sein als ein Spitzenwert in einer allgemeinen Benchmark. Ein Reisebetrieb priorisiert möglicherweise Gesprächsübergaben und Ausfallsicherheit, eine Agentur Versionskontrolle und Mandantentrennung. Ergänzen Sie zu jedem Kriterium eine prüfbare Frage: „Kann ein Teammitglied Zugriffe nach Rolle vergeben?“, „Lässt sich die Wissensbasis vollständig exportieren?“, „Welche Einstellung verhindert die Nutzung unserer Eingaben für eine optionale Verbesserung?“

Verlangen Sie dabei keine Marketingantwort, sondern einen Nachweis aus Vertrag, Produktdokumentation oder einem Testkonto. Halten Sie Annahmen getrennt von belegten Fakten fest. „EU-Region auswählbar“ beweist beispielsweise noch nicht, wo Protokolle, Supportdaten, Sicherungen oder Unterauftragnehmer verarbeitet werden. Diese Trennung spart später Diskussionen, wenn ein Anbieter eine Funktion nur in einer bestimmten Preisstufe, Region oder Konfiguration bereitstellt.

2. Datenfluss und Vertrag gemeinsam lesen

Zeichnen Sie für jeden priorisierten Einsatz eine einfache Karte: Eingabequelle, Verarbeitung, gespeicherte Inhalte, Schnittstellen, Ausgaben und Lösch- beziehungsweise Exportweg. Markieren Sie personenbezogene, vertrauliche und öffentlich verfügbare Informationen in unterschiedlichen Farben. Fragen Sie beim neuen Anbieter nach Auftragsverarbeitung, Unterauftragsverarbeitern, Speicherorten, Aufbewahrungsfristen, Supportzugriffen und dem Weg für Betroffenenanfragen. Die EDPB-Leitlinien zu Verantwortlichen und Auftragsverarbeitern betonen, dass die tatsächlichen Rollen funktional beurteilt werden und Rechenschaftspflicht eine dokumentierbare Praxis verlangt.

Besondere Aufmerksamkeit verdienen Trainings- und Verbesserungsoptionen. Eine Formulierung wie „anonymisierte Nutzung“ ersetzt nicht die Prüfung, welche Daten konkret übertragen werden, wer sie verwendet und welche Einstellung aktiv ist. Die EDPB hat bei KI-Modellen ausdrücklich die Bewertung von Anonymität, berechtigtem Interesse und Folgen einer unrechtmäßigen Verarbeitung eingeordnet. Für sensible oder grenznahe Fälle braucht es eine individuelle Datenschutz- und gegebenenfalls Rechtsprüfung; dieser Plan ersetzt sie nicht.

Wenn der Wechsel einen Website-Chat, Analyse- oder Marketingdienst betrifft, müssen die öffentlich beschriebenen Dienste und die technische Auslieferung zum neuen Datenfluss passen. Für die Pflege von Impressum, Datenschutzerklärung und Cookie Consent auf der Unternehmens-Website kann das AdSimple Business-Paket eine gebündelte Arbeitsgrundlage sein. Es ersetzt aber nicht die Entscheidung, ob der konkrete KI-Dienst, seine Einstellungen und der eigene Einsatzfall passend geprüft wurden.

3. Wissen, Prompts und Rechte portierbar machen

Ein Wechsel scheitert oft nicht am Modell, sondern an verstreutem Betriebswissen. Sichern Sie vor dem Pilot strukturiert: Systemanweisungen, freigegebene Prompt-Vorlagen, Wissensquellen mit Eigentümer, Bewertungsbeispiele, Rollen, API-Schlüsselverweise ohne Geheimnisse in der Projektmappe und eine Liste angebundener Systeme. Notieren Sie bei jeder Quelle, wer Aktualisierungen freigibt und wie veraltete Inhalte entfernt werden. So wandert nicht nur Text von A nach B, sondern ein kontrollierter Prozess.

Planen Sie auch einen Rückweg. Können Gesprächsverläufe, Feedback, Konfigurationen und Wissensdateien exportiert werden? Wer kann einen Zugang entziehen, wenn eine Person das Unternehmen verlässt? Wie werden alte Automationen deaktiviert, ohne dass beide Anbieter gleichzeitig Kundenantworten versenden? Ein sauberer Cutover braucht ein Datum, eine verantwortliche Person und einen dokumentierten Rückfallmodus. Aus dem neuen Tool darf keine zweite, unkontrollierte Wissensinsel entstehen.

4. Mit realistischen, aber sicheren Testfällen messen

Eine Demo mit allgemeinen Fragen ist kein Eignungstest. Erstellen Sie 15 bis 30 Testfälle aus dem echten Arbeitsalltag, jedoch ohne echte Kunden-, Personal- oder Geheimdaten. Ersetzen Sie Namen und Nummern durch synthetische Werte. Nehmen Sie typische Aufgaben, bekannte Grenzfälle, mehrdeutige Anfragen, veraltete Wissensstände und Fälle auf, in denen das System ausdrücklich „Ich weiß es nicht“ sagen soll. Für eine Manufaktur könnten das Materialanfrage, Liefertermin ohne Lagerbestand, Reklamation und eine unzulässige technische Zusage sein.

Bewerten Sie beide Anbieter mit denselben Kriterien: sachliche Richtigkeit, Quellenbezug, Vollständigkeit, Tonalität, Umgang mit Unsicherheit, Einhaltung der Rollenregel und Zeit bis zur menschlichen Übergabe. Dokumentieren Sie nicht nur eine Durchschnittsnote. Ein einzelner gravierender Fehler kann bei einem sensiblen Einsatzfall wichtiger sein als viele flüssige Antworten. Der freiwillige NIST AI Risk Management Framework strukturiert Risikomanagement entlang von Govern, Map, Measure und Manage. Für KMU genügt zunächst die praktische Übersetzung: verantwortlich machen, Einsatz kartieren, testen, Maßnahmen festhalten.

5. Sicherheits- und Betriebsprobe durchführen

Der neue Dienst muss nicht nur gute Antworten geben, sondern im Alltag beherrschbar bleiben. Prüfen Sie deshalb getrennt: Mehrfaktor-Anmeldung, Rechte nach Rolle, Protokollierung, Export, Löschung, Schnittstellenberechtigungen, Rate Limits, Fehlernachrichten und Eskalationskontakt. Lassen Sie im Test absichtlich eine Wissensquelle fehlen, simulieren Sie eine nicht erreichbare Schnittstelle und versuchen Sie, eine Antwort außerhalb des freigegebenen Umfangs zu erzwingen. Das Ergebnis muss nicht immer automatisch blockieren. Entscheidend ist, dass der vorgesehene menschliche Weg funktioniert und sichtbar wird.

Ebenso wichtig ist der Betrieb nach der Einführung: Wer kontrolliert Stichproben? In welchem Intervall wird die Wissensbasis überprüft? Wie werden Vorfälle, Nutzerfeedback und fehlerhafte Ausgaben erfasst? Legen Sie für hoch bewertete Risiken eine eindeutige Reaktion fest: stoppen, auf einen Menschen umleiten, korrigieren, informieren oder erneut testen. Ein Wechsel ohne diese Betriebsroutine verlagert Risiken lediglich vom alten in den neuen Anbieter.

6. Pilot begrenzen und Rückfall einüben

Starten Sie nicht mit allen Kundengruppen und allen Abläufen. Wählen Sie einen abgegrenzten Bereich, zum Beispiel interne Entwürfe für zwei Wochen oder einen Support-Chat für eine überschaubare Produktlinie. Definieren Sie vorab messbare Abbruchkriterien: wiederholte falsche Produktinformationen, fehlende Übergaben, nicht erklärbare Datenflüsse oder eine nicht verfügbare Kernfunktion. Dann ist der Rückfall keine Panikentscheidung, sondern ein geplanter Schritt.

Kommunizieren Sie im Team klar, was im Pilot erlaubt ist und was nicht. Besonders bei Kundennachrichten, Angeboten oder fachlich sensiblen Auskünften gehört eine menschliche Freigabe in den Ablauf, solange der Einsatzfall sie verlangt. Der Pilot liefert zugleich die Unterlagen für die endgültige Entscheidung: Testprotokoll, offene Risiken, gewählte Einstellungen, Verantwortlichkeiten und nächste Überprüfung.

7. Freigabe als Betriebsentscheidung dokumentieren

Am Ende steht keine perfekte Punktzahl, sondern eine begründete Entscheidung. Halten Sie fest, welcher Anbieter für welchen Zweck freigegeben ist, welche Daten nicht eingegeben werden dürfen, wer Adminrechte besitzt, welche Kontrollen laufen und wann die nächste Überprüfung erfolgt. Ergänzen Sie den Ausstiegsplan: Exportformat, Kündigungsfrist, Löschbestätigung, Verantwortliche und alternative Arbeitsweise bei Ausfall. Das Protokoll muss nicht lang sein. Eine Seite mit Entscheidungen, Links zu Nachweisen und offenen Punkten ist für ein KMU oft besser nutzbar als ein umfangreiches Konzept ohne Eigentümer.

Die Entscheidungsmatrix: Was muss erfüllt sein?

Eine einfache Tabelle verhindert, dass der überzeugendste Demo-Termin gewinnt. Legen Sie Spalten für Kriterium, Gewichtung, Nachweis, Testergebnis, Restrisiko und Freigabe an. Vergeben Sie nicht nur Punkte, sondern markieren Sie Ausschlusskriterien. Dazu können fehlende Rollenrechte, kein brauchbarer Export, nicht klärbare Datenflüsse oder ein nicht funktionierender menschlicher Übergabeweg zählen. Ein Anbieter mit vielen guten Einzelwerten bleibt ungeeignet, wenn er ein solches Mindestkriterium nicht erfüllt.

Für die übrigen Punkte reicht eine transparente Skala, etwa von null bis drei: nicht belegt, teilweise belegt, im Test bestätigt, im realistischen Pilot stabil bestätigt. Tragen Sie hinter jeder Bewertung den Beleg ein, zum Beispiel einen Link zur Produktdokumentation, ein Testprotokoll oder die relevante Vertragsstelle. So kann die Geschäftsführung nachvollziehen, warum ein günstigeres Angebot trotz guter Präsentation nicht ausgewählt wurde. Gleichzeitig wird sichtbar, welche offenen Punkte vor einem breiteren Einsatz noch gelöst werden müssen.

Eine sinnvolle Abschlussfrage lautet nicht „Ist der neue Anbieter fehlerfrei?“, sondern „Können wir die bekannten Fehler erkennen, begrenzen und verantwortlich behandeln?“ Diese Perspektive passt besonders zu kleinen Teams mit begrenzter Zeit. Sie konzentriert die Prüfung auf den eigenen Einsatz und schützt davor, aus einer allgemeinen Produktbewertung eine unbelegte Zusage für jeden Geschäftsprozess abzuleiten.

Typische Fehlerbilder beim KI-Anbieterwechsel

Der günstigere Tarif entscheidet allein. Niedrige monatliche Kosten helfen nicht, wenn fehlende Rollen, unklare Datenwege oder manueller Nacharbeitsaufwand den Prozess verteuern. Bewerten Sie den gesamten Arbeitsablauf, nicht nur die Lizenz.

Der Pilot arbeitet mit echten Kundendaten. Das beschleunigt scheinbar den Vergleich, macht aber den Test selbst zum Datenschutz- und Vertrauensrisiko. Verwenden Sie sorgfältig vorbereitete, synthetische Fälle und dokumentieren Sie Ausnahmen gesondert.

Ein gutes Modell ersetzt die Fachfreigabe. Flüssige Sprache kann falsche Preise, nicht belegte technische Zusagen oder unpassende Antworten verdecken. Definieren Sie Fälle, in denen das System nur vorbereitet und ein Mensch entscheidet.

Die alte Integration bleibt unbemerkt aktiv. Doppelte Antworten, unerklärliche Kosten und verstreute Daten entstehen häufig durch vergessene Webhooks, Plug-ins oder Testkonten. Eine Abschaltliste mit Gegenprüfung gehört zum Cutover.

Die Datenschutzerklärung wird als nachträgliche Formalität behandelt. Zuerst den tatsächlichen Datenfluss und die Einstellungen klären, dann die Website-Dokumentation daran ausrichten. Wer die zentralen Website-Pflichten gemeinsam verwalten möchte, kann das Business-Paket von AdSimple als organisatorischen Rahmen für Datenschutztexte und Consent-Management heranziehen.

Fazit: Vergleichbar wird KI erst durch einen klaren Betrieb

Österreichische KMU müssen beim Anbieterwechsel nicht dieselbe Prüfmaschinerie wie ein Großkonzern aufbauen. Sie brauchen aber einen belastbaren Kern: Inventar, Datenfluss, Testfälle, Verantwortlichkeiten, begrenzter Pilot und Ausstiegsweg. Damit wird aus einer Produktdemo eine Betriebsentscheidung. Der beste Anbieter ist nicht pauschal der mit dem spektakulärsten Modell, sondern derjenige, dessen Einsatz sich für den eigenen Zweck verständlich konfigurieren, überprüfen und bei Bedarf wieder beenden lässt.

Beginnen Sie mit einem einzigen priorisierten Einsatzfall und einer Tabelle, die Fragen, Nachweise, Testergebnis und offene Risiken zusammenführt. Erst wenn dieser Ablauf trägt, lohnt sich die Ausweitung auf weitere Teams und Automationen. Bei Zweifeln zu Datenschutz, Vertrag, arbeitsrechtlichen Folgen oder einem besonders risikoreichen Einsatzfall ist fachkundige, individuelle Beratung der richtige nächste Schritt.

Quellen