Anbieterabhängigkeit für IT-Leitung: Praxisleitfaden

Anbieterabhängigkeit für IT-Leitung ist kein Makel, den Unternehmen um jeden Preis vermeiden müssen. Sie wird zum Risiko, wenn niemand erkennt, welche Daten, Schnittstellen, Verträge und Kompetenzen an einen Dienst gebunden sind – und was ein Wechsel tatsächlich verlangen würde. Gerade bei Cloud-, KI- und Plattformdiensten hilft deshalb kein pauschales ‚Multi-Cloud‘ oder ‚lokal ist sicherer‘. Entscheidend ist eine belastbare Entscheidung: Wo bringt eine Bindung nachweisbaren Nutzen, wo gefährdet sie Handlungsfähigkeit und welche Mindestoptionen braucht das Unternehmen?

Dieser Praxisleitfaden richtet sich an IT-Leitungen im Mittelstand. Er übersetzt das abstrakte Thema Vendor Lock-in in eine Bestandsaufnahme, eine einfache Bewertungsmatrix und einen 90-Tage-Plan. Er ersetzt keine Rechtsberatung und keine Prüfung eines konkreten Vertrags. Er hilft aber, die richtigen Fragen rechtzeitig mit Fachbereich, Einkauf, Datenschutz, Recht und Betrieb zu klären.

Anbieterabhängigkeit für IT-Leitung: die Kurzantwort

Steuerbar wird Anbieterabhängigkeit, wenn IT-Leitung fünf Dinge sichtbar macht: die Kritikalität des Dienstes, proprietäre Bausteine, den Zugriff auf Daten, die Wechselkosten und die vorhandenen Fähigkeiten für einen Übergang. Erst dann lässt sich entscheiden, ob eine Abhängigkeit akzeptabel ist, reduziert werden sollte oder einen belastbaren Exit-Test braucht.

Die Bundesnetzagentur beschreibt Providerwechsel nicht als bloße Kündigung, sondern als Zusammenspiel von Vertragsinformationen, Datenexport, Schnittstellen, Übergangsbetrieb und Datenabruf. Das gilt für viele IaaS-, PaaS- und SaaS-Konstellationen ebenso wie für den Wechsel zu eigener Infrastruktur. Die Erläuterungen der Bundesnetzagentur zum Providerwechsel sind dafür eine nützliche Orientierung.

Sechs Formen der Abhängigkeit unterscheiden

Ein Anbietername auf der Rechnung sagt noch wenig über das Risiko aus. Praktisch wird die Analyse, wenn sie verschiedene Bindungen trennt. Kommerzielle Bindung entsteht etwa durch lange Laufzeiten, Preismodelle oder Bündelangebote. Technische Bindung entsteht durch proprietäre Datenmodelle, Spezialfunktionen, nicht dokumentierte Schnittstellen oder individuell gewachsene Integrationen. Hinzu kommen organisatorische Bindungen: Nur einzelne Mitarbeitende kennen Konfiguration, Berechtigungen oder Wiederanlaufprozesse.

• Vertrag: Laufzeit, Verlängerung, Kündigung, Unterstützung im Übergang und Kostenannahmen nachvollziehen.
• Architektur: Proprietäre Dienste, Abhängigkeiten zwischen Komponenten und technische Ersatzmöglichkeiten dokumentieren.
• Daten: Eigentum, Zugriff, Exportformate, Metadaten, Aufbewahrung und Wiederherstellung prüfen.
• Schnittstellen: APIs, Authentifizierung, Rate Limits, Webhooks und Dokumentation auf Portabilität bewerten.
• Betrieb: Monitoring, Backups, Identitäten, Berechtigungen, Support und Übergangsbetrieb einbeziehen.
• Kompetenzen: Wissen über Konfiguration, Migration und Ersatzbetrieb nicht bei einzelnen Personen oder dem Anbieter allein bündeln.

Die britische Regierung unterscheidet ebenfalls kommerziellen und technischen Lock-in. Ihre Leitlinie zum technischen Lock-in in der Cloud nennt unter anderem anbietergebundene Architektur, fehlende gleichwertige Alternativen und fehlende Kompetenzen als Ursachen. Das ist kein Argument gegen spezialisierte Dienste. Es ist ein Argument dafür, Nutzen und Ausstiegsoptionen gemeinsam zu bewerten.

Mit einer Abhängigkeitsmatrix vom Bauchgefühl zur Priorität

Beginnen Sie nicht mit allen Verträgen zugleich. Wählen Sie die Dienste, die kritische Geschäftsprozesse, sensible Daten, zentrale KI-Anwendungen oder viele abhängige Systeme betreffen. Für jeden Dienst genügt zunächst eine Zeile. Wichtig ist, dass die Bewertung mit Personen aus Betrieb, Fachseite und Einkauf abgeglichen wird – nicht nur mit einer technischen Vermutung.

Ergänzen Sie je Zeile eine Skala für Kritikalität, Portabilität, Exit-Aufwand, verfügbare Skills und Risiko. Eine einfache Ampel reicht für den Start. Rot bedeutet nicht automatisch „wechseln“. Rot bedeutet: Entscheidung, Verantwortlichkeit und Termin für die nächste Prüfung festlegen.

Daten, Schnittstellen und Workloads getrennt prüfen

Eine exportierbare Datei beweist noch keine Portabilität. Für einen nutzbaren Wechsel müssen Daten vollständig, verständlich und in einer Form verfügbar sein, die ein anderes System verarbeiten kann. Dazu gehören je nach Anwendung Metadaten, Berechtigungen, Versionen, Protokolle oder Konfigurationen. Bei KI-Anwendungen kommen häufig Prompt-Vorlagen, Wissensquellen, Evaluierungsfälle, Freigaberegeln und Zugriffsrollen hinzu.

Die Europäische Kommission ordnet offene und harmonisierte Spezifikationen als wichtige Grundlage für Interoperabilität und Portabilität ein. Ihre Studie zur Interoperabilität von Datenverarbeitungsdiensten macht zugleich deutlich, dass Standardisierung weiter in Entwicklung ist. IT-Leitungen sollten deshalb keine vermeintlich universelle Standardliste voraussetzen, sondern bei jedem Dienst konkrete Export-, API- und Importtests verlangen.

Praktische Prüffragen

1. Können wir unsere produktiven Daten samt erforderlichen Metadaten exportieren und wieder einlesen?
2. Sind Datenmodelle, Schnittstellen und Authentifizierungsverfahren ausreichend dokumentiert?
3. Welche Geschäftslogik steckt in proprietären Workflows, Erweiterungen oder Konfigurationen?
4. Welche Abhängigkeiten bestehen zu Identität, Monitoring, Backup und Netzwerkanbindung?
5. Wer kann eine Testmigration durchführen, prüfen und im Fehlerfall zurückrollen?

Auch eine lokale oder europäische Betriebsoption beantwortet diese Fragen nicht automatisch. Sie kann ein sinnvoller Baustein sein, ersetzt aber weder Datenanalyse noch Übergangskonzept. Für die technische Perspektive auf KI auf eigener Hardware bietet der Beitrag LLMs und Whisper lokal: Praxisleitfaden für KI auf eigener Hardware ergänzende Einblicke.

Vertrag und Beschaffung als Teil des Exit-Designs

Ein Exit-Plan beginnt vor der Beschaffung und bleibt während des Betriebs aktuell. Einkauf und IT sollten daher nicht nur Leistungsumfang und Preis vergleichen, sondern auch die Informationslage für einen späteren Wechsel. Dazu zählen Kündigungsfristen, Unterstützung während der Migration, Zugriff auf Daten nach Vertragsende, Formate, technische Limits und die Verteilung der Aufgaben im Übergang.

Der Data Act verfolgt unter anderem das Ziel, den Wechsel zwischen Cloud-Anbietern zu erleichtern. Die Übersicht der Europäischen Kommission zum Data Act bietet einen aktuellen Ausgangspunkt. Daraus folgt jedoch nicht, dass jeder Wechsel einfach, kostenlos oder technisch gleichwertig wird. Diensttyp, Vertrag, Datenumfang und Architektur bleiben entscheidend. Konkrete rechtliche Pflichten, Fristen und Vertragsfolgen gehören vor einer Entscheidung in eine aktuelle Prüfung anhand der Primärquelle auf EUR-Lex und bei Bedarf in fachkundige Beratung.

Eine gute Beschaffungsakte hält deshalb nicht nur den Anbieter fest, sondern auch Annahmen: Welche Daten müssen exportierbar sein? Welche Schnittstellen sind geschäftskritisch? Welche Zeit ist für Übergangsbetrieb realistisch? Welche Tests belegen, dass ein Ersatzpfad funktioniert? So wird ein späterer Wechsel nicht zu einer Suche nach verlorenem Wissen.

Wann Lock-in vertretbar sein kann

Hilfreich ist eine Entscheidungsschleife: Abhängigkeit sichtbar? Kritikalität geklärt? Wechseloption getestet? Vertrag geprüft? Verantwortlichkeit und Budget vorhanden? Review-Termin gesetzt? Erst wenn diese Fragen beantwortet sind, lässt sich eine Bindung bewusst akzeptieren oder gezielt reduzieren.

Eine breitere strategische Einordnung liefert Digitale Souveränität: Ein 36-Monate-Fahrplan für Deutschland. Dieser Beitrag ergänzt diese Perspektive mit einer operativen Matrix für die IT-Leitung.

Ein 90-Tage-Startplan für die IT-Leitung

Tage 1 bis 30: Transparenz schaffen

Erstellen Sie die erste Matrix für fünf bis zehn kritische Dienste. Dokumentieren Sie Geschäftsprozess, Datenarten, technische Abhängigkeiten, Vertrag, Verantwortliche und bereits bekannte Wechselhürden. Notieren Sie dabei auch Unsicherheiten statt sie zu glätten. Eine offene Frage zu Exportformaten ist wertvoller als eine ungetestete Annahme.

Tage 31 bis 60: Risikofälle konkretisieren

Wählen Sie die zwei kritischsten Bindungen und definieren Sie eine kleine Probe: ein Datenexport, ein API-Test, die Wiederherstellung eines Beispieldatensatzes oder die Rekonstruktion eines Workflows. Prüfen Sie mit Einkauf und Fachseite, ob Vertrag, Support und Zuständigkeiten zu dieser Probe passen. Der Test muss keinen vollständigen Anbieterwechsel simulieren; er soll zeigen, welche Informationen, Skills und Aufwände fehlen.

Tage 61 bis 90: Entscheidungen und Reviews verankern

Entscheiden Sie je Risikofall: akzeptieren, reduzieren, testen oder Beschaffung nachschärfen. Halten Sie Maßnahme, Eigentümer, Budgetannahme und Reviewdatum fest. Das Ergebnis ist kein Zertifikat für Souveränität, sondern ein belastbarer Arbeitsstand. Für die Einordnung von KI-Strategie, Governance und ersten Anwendungsfällen kann eine KI-Beratung und ein Use-Case-Workshop in NRW helfen, die technischen und organisatorischen Fragen gemeinsam zu strukturieren.

Was dieser Leitfaden nicht beweist

Die Matrix ersetzt keine vollständige Sicherheits-, Datenschutz- oder Vertragsprüfung. Sie garantiert weder einen erfolgreichen Anbieterwechsel noch Rechtskonformität. Auch Multi-Cloud, Open Source, EU-Hosting oder lokale KI sind keine automatischen Beweise für digitale Souveränität. Sie können Optionen erweitern, müssen aber jeweils mit Datenflüssen, Rollen, Architektur, Vertrag und Betrieb zusammen bewertet werden.

Quellen und fachliche Einordnung

Praxisnahe Einordnung von Consulting Entenmann: Der Leitfaden verbindet die Planung von KI-Einführung mit nachvollziehbaren Fragen zu Daten, Verantwortlichkeiten und Betriebsfähigkeit. Er ist als Orientierung für strukturierte Entscheidungen gedacht, nicht als Versprechen zu Sicherheit, Kosten oder rechtlicher Bewertung.

Autor: Niklas Entenmann.

• Europäische Kommission: Data Act
• Europäische Kommission: Interoperabilität von Datenverarbeitungsdiensten
• Bundesnetzagentur: Providerwechsel bei Datenverarbeitungsdiensten
• UK Government: Managing technical lock-in in the cloud
• EUR-Lex: Verordnung (EU) 2023/2854

Für ein künftiges Titelbild ist eine sachliche Entscheidungsansicht geplant: eine IT-Leitung vor einer Matrix mit Dienst, Daten, Schnittstellen, Vertrag, Exit und Review. Der Alt-Text wird erst nach der Medienprüfung verbindlich festgelegt.