AI-Anbieter-Lock-in: Minderungsstrategien für CIOs und CTOs

Von Victor Hoang · Aktualisiert am 19. Mai 2026

Ihre Organisation hat 2024 GPT-4 für ihre AI-Infrastruktur gewählt. Sie haben 15 interne Tools darauf aufgebaut. Ihr Prompt-Engineering-Team hat drei Monate damit verbracht, System-Prompts und Few-Shot-Beispiele zu optimieren. Ihre Entwickler haben individuelle API-Integrationen über sechs interne Systeme hinweg gebaut.

Dann hat OpenAI die Enterprise-API-Preise um 40 % erhöht. Oder das Modell mit sechs Monaten Vorlauf eingestellt. Oder Anthropic hat ein Modell veröffentlicht, das für Ihren konkreten Anwendungsfall deutlich besser ist, bei geringeren Kosten pro Token. Oder eine Datenpanne in der Infrastruktur von OpenAI führt zu einem 72-stündigen Zeitraum, in dem Ihre AI-gestützten Abläufe stillstehen.

Wie schnell können Sie wechseln? Wenn Sie diese Frage nicht durchdacht haben, haben Sie sich möglicherweise bereits festgelegt.

Anbieter-Lock-in bei herkömmlicher Software ist kostspielig, aber meist begrenzt. Sie können Ihre Daten aus Salesforce exportieren, auch wenn es Aufwand kostet. Sie können von AWS (Amazon Web Services) migrieren, auch wenn es ein Jahr dauert. Die Wechselkosten sind groß, aber endlich. Gartner prognostiziert, dass bis 2027 35 % der Länder an regionsspezifische AI-Plattformen gebunden sein werden, die proprietäre Kontextdaten nutzen. Das zeigt, dass AI-Plattform-Lock-in zunehmend ein geopolitisches und nicht nur ein kommerzielles Problem wird.

AI-Anbieter-Lock-in hat zusätzliche Dimensionen, die ihn schwerer zu beziffern und teurer aufzulösen machen. Ihre Prompt-Engineering-Arbeit ist modellspezifisch. Ihr Fine-Tuning ist modellspezifisch. Die Intuition Ihres Teams im Umgang mit der AI ist modellspezifisch. Und Ihre Geschäftsergebnisse sind auf das Verhalten des jeweiligen Modells abgestimmt. Ein Modellwechsel kann die Ausgabequalität so verändern, dass nachgelagerte Workflows brechen, selbst wenn das neue Modell objektiv „besser" ist. Das Vendor Evaluation Framework für AI-Tools behandelt, wie Sie das Lock-in-Risiko vor der Auswahl bewerten; dieser Artikel behandelt, was zu tun ist, wenn Sie bereits in einer Anbieterbeziehung stecken.

Dieser Artikel behandelt die drei Formen von AI-Anbieter-Lock-in, konkrete Minderungsmaßnahmen für jede davon und den wichtigen Realitätscheck: Ein Teil des Lock-ins ist akzeptabel, und das Ziel ist informierter Lock-in statt null Lock-in.

Warum Lock-in bei AI anders ist als bei herkömmlicher Software

Key Facts: AI-Anbieter-Lock-in

• 94 % der Organisationen sind besorgt über AI-Anbieter-Lock-in, wobei 45 % sagen, er habe bereits ihre Fähigkeit beeinträchtigt, bessere Tools einzuführen. (Parallels 2026 Cloud Survey)
• Nur 6 % der Enterprise-Führungskräfte sagen, sie könnten ihren primären AI-Anbieter ohne Störungen wechseln, und 47 % sagen, eine wichtige Geschäftsfunktion käme zum Erliegen, wenn ihr primärer Anbieter ausfiele. (Zapier)
• Unternehmen, die von Anfang an auf Portabilität gesetzt haben, haben bei einem Wechsel des AI-Anbieters 60-80 % niedrigere Migrationskosten als jene, die ohne Abstraktionsschichten eng integriert haben. (Kellton)

Bei herkömmlicher Software geht es beim Anbieter-Lock-in primär um Datenportabilität und Integrationsaufwand. Wenn Sie Salesforce verlassen wollen, exportieren Sie Ihre Kontakte, Accounts und Opportunities als CSV-Dateien, importieren sie in HubSpot und bauen Ihre Integrationen neu auf. Die Daten kommen mit. Das Produktwissen (wie man Salesforce nutzt) ist weitgehend übertragbar, weil die Produktkategorien stabil sind.

Bei AI wirkt Lock-in auf drei zusätzlichen Ebenen.

Modellverhalten ist nicht portabel. Wenn Sie Workflows aufgebaut haben, die vom spezifischen Verhalten von GPT-4o abhängen (Tonalität, Formatierungspräferenzen, Fehlerbehandlung, Reaktion auf bestimmte Prompt-Muster), liefert ein Wechsel zu Claude 3.7 Sonnet nicht dasselbe Verhalten, selbst wenn die Ergebnisse technisch besser sind. Ihre nachgelagerten Systeme, menschlichen Prüfprozesse und Ausgabevorlagen sind auf das alte Modell kalibriert.

Optimierungsarbeit ist modellspezifisch. Prompt Engineering ist kein übertragbares Artefakt. System-Prompts, die für GPT-4 optimiert wurden, schneiden auf Anthropic-Modellen oft deutlich schlechter ab, wenn man sie nicht grundlegend neu entwickelt. Fine-Tuning ist vollständig modellspezifisch. Ein feinabgestimmtes GPT-Modell ergibt kein feinabgestimmtes Claude.

Das Gelernte ist nicht übertragbar. Wenn Sie sechs Monate damit verbracht haben zu lernen, wie sich ein bestimmtes Modell in Randfällen verhält, wo es zu Halluzinationen neigt und wie es mit mehrdeutigen Anweisungen umgeht, wandert dieses Wissen nicht mit. Die Lernkurve beginnt von vorn.

Nichts davon macht Lock-in unvermeidbar, aber es macht versehentlichen Lock-in deutlich teurer als bei herkömmlicher Software.

Die 3 Formen von AI-Anbieter-Lock-in

Modell-Lock-in

Modell-Lock-in entsteht, wenn Ihre Anwendungslogik eng an das spezifische Verhalten des Modells eines Anbieters gekoppelt ist. Sie haben Prompts dafür optimiert, Ihre Qualitätssicherungsprozesse (QA) sind auf dessen Ergebnisse kalibriert, und Ihr Team versteht das spezifische Verhalten gut genug, um effektiv damit zu arbeiten.

Das Signal für Modell-Lock-in: Auf die Frage „Was bräuchte es, um zu einem anderen Modell zu wechseln?" lautet die Antwort „mehrere Wochen Neutest und Neuoptimierung über alle unsere AI-Workflows hinweg". Das ist Modell-Lock-in.

Die Einstellung von Modellen (Deprecation) ist der Hauptauslöser für Modell-Lock-in-Kosten. OpenAI hat den ursprünglichen GPT-3.5-Instruct-Endpunkt im Januar 2024 mit sechs Monaten Vorlauf eingestellt. Das GPT-4-Portfolio wurde mehrfach aktualisiert, wobei sich die Modell-IDs änderten. Organisationen, die sich auf bestimmte Modellversionen festgelegt hatten (gpt-4-0314, gpt-4-0613), mussten ihre Implementierungen jedes Mal neu testen.

Anthropic hat sein Modellportfolio ähnlich aktualisiert. Claude 1, Claude 2, Claude 2.1, Claude 3 Haiku, Sonnet und Opus, Claude 3.5 und die Claude-4-Serie folgten in weniger als drei Jahren aufeinander. Die Leistungsverbesserungen zwischen den Versionen sind erheblich, aber jedes Update erfordert eine erneute Validierung Ihrer Produktivimplementierungen.

Minderung von Modell-Lock-in:

Die wichtigste architektonische Maßnahme ist eine Abstraktionsschicht, die Ihre Anwendungslogik von der Modell-API trennt. Tools wie LiteLLM (eine Python-Bibliothek, die eine einheitliche Schnittstelle über OpenAI, Anthropic, Cohere und andere Anbieter bietet) oder LangChain (ein Anwendungs-Framework, das Modellaufrufe abstrahiert) ermöglichen es, das zugrunde liegende Modell über einen Konfigurationsparameter zu wechseln, statt API-Integrationscode neu zu schreiben. Die Entscheidung Build vs. Buy vs. Integrate ist hier der vorgelagerte Kontext: Der „Integrate"-Pfad empfiehlt ausdrücklich, diese Abstraktionsschicht als Teil des Integrationsdesigns zu bauen.

LiteLLM bietet konkret ein einziges API-Aufrufformat, das an das jeweils angegebene Modell weiterleitet. Ihr Anwendungscode ruft heute litellm.completion(model="gpt-4o", messages=...) auf. Wenn Sie zu claude-3-7-sonnet-20250219 wechseln wollen, ändern Sie den Modellparameter, nicht den umgebenden Code. Die Abstraktion ist nicht perfekt (das Modellverhalten unterscheidet sich weiterhin), aber der Integrationsaufwand entfällt.

Auch ein Rhythmus für Multi-Modell-Tests hilft. Wenn Sie Ihre wichtigsten Workflows jedes Quartal regelmäßig gegen zwei bis drei Modelle benchmarken, wissen Sie, ob eine tragfähige Alternative existiert und wie viel Neuoptimierung ein Wechsel ungefähr erfordern würde. Das ist sowohl eine Lock-in-Minderung (Sie bleiben bei den Alternativen auf dem Laufenden) als auch ein Werkzeug zur Kostenoptimierung (vielleicht finden Sie ein günstigeres Modell mit vergleichbarer Leistung).

Eine wichtige Einschränkung: Abstraktionsschichten verursachen Performance-Overhead und begrenzen mitunter den Zugriff auf modellspezifische Funktionen. Wenn ein bestimmtes Modell eine Fähigkeit hat, die für Ihren Anwendungsfall zentral ist (das erweiterte Kontextfenster von Anthropic, die Bildverarbeitung von OpenAI, die multimodalen Eingaben von Google), stellt die Abstraktionsschicht diese Fähigkeit möglicherweise nicht sauber bereit. Das Ziel ist, die Abstraktionsschicht für Modelle mit vergleichbaren Fähigkeiten zu nutzen, nicht Modell-Interoperabilität zu erzwingen, wo grundlegende Fähigkeitsunterschiede bestehen.

Daten-Lock-in

Daten-Lock-in entsteht, wenn Ihre AI-Trainingsdaten, Fine-Tuning-Datensätze oder Vektor-Embeddings in einem proprietären Format eines Anbieters gespeichert sind, das den Ausstieg teuer und komplex macht.

Das ist häufiger, als Organisationen erkennen, denn AI-Tools bieten oft bequeme Oberflächen zum Speichern und Verwalten AI-spezifischer Daten. Sie bauen eine Wissensdatenbank in Notion AI oder in der SharePoint-Integration von Microsoft Copilot auf. Sie speichern Ihre Kundeninteraktionshistorie in der proprietären Vektordatenbank eines Anbieters. Sie stimmen ein Modell über die Fine-Tuning-Oberfläche eines Anbieters ab, der die feinabgestimmten Gewichte in seiner eigenen Infrastruktur speichert.

Wenn die Anbieterbeziehung endet oder die Preise untragbar werden, müssen Sie diese Daten herausholen. Liegen die Daten in einem proprietären Format vor, extrahieren Sie sie möglicherweise Datensatz für Datensatz über API-Aufrufe, zahlen Gebühren für Professional Services oder verlieren Jahre angesammelten Kontexts.

Minderung von Daten-Lock-in:

Vektor-Embeddings sind das wichtigste AI-spezifische Datenasset, das es zu schützen gilt. Wenn Sie ein RAG-System (Retrieval-Augmented Generation) betreiben, stellen Ihre Dokument-Embeddings eine erhebliche Investition in Aufbereitung und Indexierung dar. Speichern Sie diese in Vektordatenbanken mit offenem Format (FAISS, Chroma, Weaviate, Qdrant) statt in anbietereigenem Embedding-Speicher. Alle unterstützen Standard-Exportformate. Das RAG-Assistant-Pattern behandelt Architekturentscheidungen für das Design von Wissensdatenbanken, die Portabilität von Anfang an natürlich schützen.

Quelldokumente sind ebenso wichtig. Ihre AI-Wissensdatenbank ist nur so portabel wie die zugrunde liegenden Quelldokumente. Speichern Sie Quelldokumente in Ihren eigenen Systemen (Ihr eigener S3-Bucket, Ihr eigener SharePoint-Tenant) statt im Speicher des Anbieters. Die Oberfläche des Anbieters sollte auf Ihre Daten zugreifen, nicht sie festhalten.

Feinabgestimmte Modellgewichte sind das am schwierigsten zu verwaltende AI-Datenasset. Wenn Sie in Fine-Tuning investiert haben, gehören Ihnen die aus Ihren proprietären Trainingsdaten erzeugten Gewichte nach den meisten Enterprise-Vereinbarungen. Verhandeln Sie im Vertrag ausdrückliche Export-Rechte für die Gewichte. Möglicherweise können Sie diese Gewichte nicht immer anderswo ausführen (feinabgestimmte GPT-4-Gewichte laufen nur auf der Infrastruktur von OpenAI), aber mit dem Export-Recht können Sie zumindest vor der Unterzeichnung prüfen, was Sie verlieren.

Vertragsklauseln zur Minderung von Daten-Lock-in:

Jeder AI-Anbietervertrag sollte enthalten:

• Ausdrückliche Erklärung, dass Kundendaten ohne ausdrückliche Zustimmung nicht für das Modelltraining verwendet werden
• Datenexportrechte, einschließlich Formatspezifikation und Zusage einer Antwortzeit
• Datenlöschrechte mit Löschbestätigung innerhalb von 30 Tagen nach Vertragsende
• Portabilitätsgarantie: Daten werden in offenen Standardformaten zurückgegeben, nicht in proprietären Formaten

Beim letzten Punkt ist Verhandlung am wichtigsten. „Wir stellen Ihre Daten auf Anfrage bereit" reicht nicht aus. „Wir stellen Ihre Daten im [konkreten Format] innerhalb von [Zeitrahmen] bereit und liefern innerhalb von 30 Tagen eine Löschbestätigung" reicht aus.

Integrations-Lock-in

Integrations-Lock-in entsteht, wenn Ihre Systeme tief mit dem spezifischen API-Design, den Antwortformaten und Integrationsmustern eines Anbieters verbunden sind. Individueller Code, der das SDK (Software Development Kit) eines Anbieters umhüllt, interne Tools auf dem Agent-Framework eines Anbieters und Workflow-Automatisierungen, die vom spezifischen Event-Format eines Anbieters abhängen, stellen allesamt Integrations-Lock-in dar.

Das ist die operativ sichtbarste Form von Lock-in. Wenn eine Organisation mit Integrations-Lock-in den Anbieter wechseln will, lautet die erste Frage der Entwicklung: „Wie viele Integrationen müssen wir neu schreiben?" Lautet die Antwort 15 bis 20 individuelle Integrationen in Produktivsystemen, werden die Wechselkosten in Monaten Entwicklungszeit gemessen, nicht in Wochen.

Minderung von Integrations-Lock-in:

API-Abstraktion ist das wichtigste architektonische Muster. Statt jedes interne System direkt die API des AI-Anbieters aufrufen zu lassen, leiten Sie alle AI-Aufrufe über einen internen Service, den Sie kontrollieren. Ihre internen Systeme rufen Ihren Abstraktions-Service auf. Ihr Abstraktions-Service ruft die API des Anbieters auf. Wenn Sie den Anbieter wechseln müssen, aktualisieren Sie den Abstraktions-Service, nicht jedes System, das AI nutzt.

Das verschafft Ihnen auch Observability, die eine direkte Integration nicht bietet. Jeder AI-Aufruf in Ihrer Infrastruktur wird vom Abstraktions-Service protokolliert. Sie können Nutzung, Kosten, Latenz und Fehlerraten an einer Stelle messen. Gartner warnt, dass Organisationen ohne sorgfältige Kostenarchitektur bei ihren GenAI-Kostenberechnungen Fehler von 500 bis 1000 % machen könnten, sobald die Nutzung skaliert. Eine zentrale Überwachung der Kosten pro Aufruf ist daher von Tag eins an unverzichtbar.

Auch Vertragsbedingungen spielen eine Rolle. SLAs (Service Level Agreements) mit Regelungen zur Migrationsunterstützung bieten Ihnen einen gewissen Schutz, falls die Anbieterbeziehung schlecht endet. Konkret: Wenn der Anbieter den Service beendet, welche Unterstützung bei der Migration sagt er zu? Eine Zusage von 90 Tagen Migrationshilfe ist etwas grundlegend anderes als keine Zusage.

Herstellerneutrale Bewertungskriterien in der Beschaffung verringern das Risiko, überhaupt zu stark in anbieterspezifische Integrationsmuster zu investieren. Wenn Sie Anbieter teilweise danach bewerten, „wie viel individuellen Code werden wir brauchen?", bevorzugen Sie tendenziell Anbieter mit saubererem API-Design und Standard-Integrationsmustern.

Die 3-Lock-in-Typen-Karte

Die 3-Lock-in-Typen-Karte unterscheidet die drei Formen von AI-Anbieter-Lock-in, die jeweils eigene Minderungsstrategien erfordern: Modell-Lock-in (Anwendungslogik, die eng an das Modellverhalten, die Optimierungsarbeit und die Intuition des Teams für einen Anbieter gekoppelt ist), Daten-Lock-in (Trainingsdaten, Fine-Tuning-Datensätze oder Vektor-Embeddings in proprietären Formaten) und Integrations-Lock-in (interne Systeme, die direkt an das spezifische API-Design, die Antwortformate und Eventstrukturen eines Anbieters angebunden sind). Die Minderung erfordert für jeden Typ eigene architektonische Maßnahmen, und wer nur einen Typ adressiert, bleibt gegenüber den anderen beiden exponiert.

Quotable: „Unternehmen, die von Anfang an auf Portabilität gesetzt haben, haben bei einem Wechsel des AI-Anbieters 60-80 % niedrigere Migrationskosten als jene, die ohne Abstraktionsschichten eng integriert haben. Die Investition in Portabilität ist klein; die Migrationskosten ohne sie sind groß." (Kellton)

Quotable: „Informierter Lock-in sieht so aus: ‚Wir haben GPT-4o Vision gewählt, weil es das leistungsstärkste Modell für unseren Anwendungsfall ist, und wir haben einen geprüften 6-Monats-Plan für den Wechsel zu einer Alternative, der sofort umsetzbar ist.' Versehentlicher Lock-in sieht so aus: ‚Wir nutzen dieses Modell seit zwei Jahren und haben nie geprüft, ob wir wechseln könnten.'"

Quotable: „Gartner prognostiziert, dass bis 2027 35 % der Länder an regionsspezifische AI-Plattformen gebunden sein werden, die proprietäre Kontextdaten nutzen. Das zeigt, dass AI-Plattform-Lock-in zu einem geopolitischen und nicht nur zu einem kommerziellen Problem wird." (Gartner)

Rework Analysis: Nach Mustern der Enterprise-AI-Infrastruktur ist Integrations-Lock-in die gefährlichste Form, weil er bis zum Beginn einer Migration am wenigsten sichtbar ist. Modell-Lock-in ist sichtbar (die Kosten für Neutests sind abschätzbar). Daten-Lock-in ist teilweise sichtbar (Sie können auflisten, was wo gespeichert ist). Integrations-Lock-in wird erst sichtbar, wenn Sie den individuellen Code zählen, der das SDK eines Anbieters in jedem internen System umhüllt.

Der Realitätscheck: Informierter Lock-in ist akzeptabel

Das praktische Ziel ist nicht null Lock-in, sondern eine dokumentierte Abhängigkeit, die die Führung versteht und bei veränderter Wirtschaftlichkeit wieder auflösen kann.

Lock-in vollständig zu eliminieren ist kein realistisches Ziel, und es aggressiv zu verfolgen hat seine eigenen Kosten. Übermäßiges Engineering für Anbieterneutralität erhöht die Implementierungskomplexität, verringert die Performance (Abstraktionsschichten erhöhen die Latenz) und hindert Sie oft daran, modellspezifische Funktionen zu nutzen, die Ihren Anwendungsfall wesentlich verbessern würden.

Ein Teil des Lock-ins ist akzeptabel. Die Frage ist, ob Sie eine informierte Entscheidung darüber getroffen haben, welchen Lock-in Sie akzeptieren und zu welchem Preis.

Informierter Lock-in sieht so aus: „Wir haben uns entschieden, eng auf den Vision-Fähigkeiten von GPT-4o aufzubauen, weil es das leistungsstärkste Modell für unseren Anwendungsfall der Rechnungsverarbeitung ist, und die Wechselkosten sind angesichts des Leistungsvorsprungs vertretbar. Wir haben diese Entscheidung dokumentiert und haben einen 6-Monats-Plan für den Wechsel zu einer Alternative, den wir geprüft haben und bei Bedarf gern umsetzen, falls OpenAI Preise oder Verfügbarkeit ändert."

Versehentlicher Lock-in sieht so aus: „Wir nutzen GPT-4 seit zwei Jahren und haben nie geprüft, ob wir wechseln könnten. OpenAI hat gerade die Preise geändert, und wir versuchen herauszufinden, wie tief wir festhängen."

Das obige Minderungs-Framework verringert versehentlichen Lock-in. Es ersetzt nicht die Notwendigkeit, bewusste Lock-in-Entscheidungen zu treffen.

Planung für die Einstellung von Modellen

Die Historie der Modelleinstellungen bei den führenden AI-Anbietern gibt Ihnen einen realistischen Planungshorizont dafür, wie lange ein bestimmtes Modell verfügbar sein wird.

Zeitlinie der OpenAI-Einstellungen Stand 2025: Das ursprüngliche GPT-4 (gpt-4-0314) wurde im Juni 2023 mit einer Vorlaufzeit von sechs Monaten eingestellt. GPT-4 (gpt-4-0613) wurde ähnlich behandelt. GPT-3.5-turbo-instruct wurde Anfang 2024 mit sechs Monaten Vorlauf eingestellt.

Anthropic hat schneller iteriert und dabei weniger formell angekündigt, vor allem bei älteren Claude-Versionen.

Die praktische Konsequenz für die Planung: Bauen Sie Ihre AI-Infrastruktur unter der Annahme, dass jede konkrete Modellversion innerhalb von 12 bis 18 Monaten eingestellt wird. Das ist nicht pessimistisch, sondern entspricht dem tatsächlichen Anbieterverhalten am Markt. Der Artikel SaaS AI Maturity Stages zeigt, wie sich die Anbieterlandschaft selbst auf jeder Stufe verändert, was nützlicher Kontext ist, um zu verstehen, warum eine heute festgelegte Wahl bei reifendem Markt möglicherweise neu bewertet werden muss. Das bedeutet:

• Legen Sie sich im Produktivcode nicht ohne geplanten Review-Zyklus auf bestimmte Modellversions-Strings fest
• Bauen Sie Kapazität für Neuvalidierung in die Quartalsarbeit Ihres AI-Teams ein (rechnen Sie mit ein bis zwei größeren Modelltests pro Jahr)
• Planen Sie jedes Jahr ein Budget für Neuoptimierung ein, statt die aktuelle Leistung des Modells als dauerhaft zu betrachten

Es geht dabei nicht um Anbieterrisiko, sondern um das Tempo der AI-Entwicklung. Die Modelle werden wirklich besser, und Sie werden aufrüsten wollen. Die Organisationen, die diesen Übergang reibungslos meistern, sind die, die ihn geplant haben, statt davon überrascht zu werden.

Für den Anbieterbewertungsprozess, der die Lock-in-Einschätzung vor einer Auswahlentscheidung unterstützt, behandelt das Vendor Evaluation Framework für AI-Tools Dimension 4 (Modellflexibilität) im Detail. Für die übergeordnete Buy-Integrate-Build-Entscheidung, die bestimmt, wie tief Sie auf der Plattform eines Anbieters aufbauen, behandelt Die Build-vs.-Buy-vs.-Integrate-Entscheidung das Reifestufen-Framework.

Das AI-Risikoregister: Was zu erfassen ist enthält eine eigene Kategorie für das Risiko der Anbieterabhängigkeit. Die oben beschriebene Minderungsarbeit lässt sich direkt diesem Registereintrag zuordnen. Und das ACE Framework (Ingest, Analyze, Predict, Generate, Execute) hilft, die Schwere des Lock-ins nach Fähigkeit einzuschätzen: Anbieterabhängigkeiten auf Execute-Ebene sind am teuersten aufzulösen, während Lock-in auf Generate-Ebene sich in der Regel allein durch Neuoptimierung der Prompts beherrschen lässt.

Lock-in ist nicht der Feind. Überraschung ist der Feind. Die Organisationen, die AI-Anbieterbeziehungen am besten managen, sind die, die ihre Exponierung verstanden haben, bevor sie zum Problem wurde.