Marketing OS: Warum das beste KI-Modell nicht ausreicht und was du stattdessen brauchst

Wir stellen gerade die falsche Frage

Wie viele unserer Marketing-Prozesse würden aufhören zu funktionieren, wenn das KI-Modell, auf dem sie laufen, teurer wird?

Ich stelle diese Frage seit einigen Monaten in Co-Creation-Sessions mit CMOs und Marketingteams. Die Reaktion ist meistens dieselbe: ein kurzes Zögern, dann ein ehrliches "Gute Frage."

Das Problem beginnt nicht mit dem Anthropic-Börsengang. Es beginnt früher. Und es ist keine Frage der Tool-Wahl.

Warum der Börsengang ein Signal ist, kein Schock

Frontier-Modelle sind seit Jahren billiger, als sie eigentlich sein dürften. Das ist keine technische Meisterleistung. Es ist eine Markteroberungsstrategie.

Wer heute tief in Marketing-Workflows eingebettet wird, wer zur Infrastruktur eines Teams wird, hat in zwei bis drei Jahren einen strukturellen Vorteil. Und kann dann entsprechend preisen.

Das Muster ist nicht neu. Wir kennen es von Cloud-Anbietern, von SaaS-Plattformen, von jedem Anbieter, der anfangs günstig war und dessen Preise gestiegen sind, sobald die Abhängigkeit aufgebaut war.

Ein Börsengang verändert die Anreizstruktur. Wer an öffentliche Märkte geht, beantwortet ab dem ersten Handelstag andere Fragen. Nicht mehr nur Wachstum der Nutzung. Sondern Wachstum der Profitabilität.

Das bedeutet nicht, dass die Preise morgen explodieren. Es bedeutet, dass der strukturelle Druck, der bisher gegen Preiserhöhungen sprach, sich langfristig dreht.

Das eigentliche Problem: Modell-Abhängigkeit ist keine Infrastruktur

Ich beobachte in Marketing-Teams immer dasselbe Muster. KI wird eingeführt. Die ersten Workflows laufen auf dem besten verfügbaren Modell, verständlicherweise, weil die Ergebnisse beeindrucken und der Preis akzeptabel ist. Dann wächst das System. Mehr Use Cases, mehr Automationen, mehr tägliche Prozesse.

Irgendwann ist der Zustand eingetreten, den ich am meisten fürchte: Das System funktioniert nur noch mit einem bestimmten Modell.

Das ist nicht Nachlässigkeit. Das ist die logische Konsequenz davon, Ergebnisse zu optimieren, ohne gleichzeitig die Architektur zu optimieren.

Ein Workflow, der ausschließlich auf einem Frontier-Modell läuft, ist kein Marketing OS. Es ist eine teure Gewohnheit. Sobald der Preis für dieses Modell steigt oder ein Konkurrenzmodell die Aufgabe besser oder günstiger erledigt, ist der Umbauaufwand erheblich.

Die meisten Teams wissen das intuitiv. Sie tun trotzdem wenig dagegen, weil der Druck noch fehlt.

Der Druck kommt jetzt.

Was ist ein Marketing OS?

Ein Marketing Operating System ist kein Tool. Es ist eine Architekturentscheidung.

Konkret: Es ist die Gesamtheit aus Workflows, Prompt-Logik, Routing-Entscheidungen und Integrations-Schichten, die dafür sorgt, dass das richtige Modell für die richtige Aufgabe eingesetzt wird. Und dass das System weiterläuft, wenn ein Anbieter das Modell wechselt, umbenennt oder verteuert.

Die entscheidende Frage lautet: Funktioniert dein Marketing-System auch dann, wenn sich das Modell ändert? Oder ist dein System eigentlich nur ein Wrapper um ein Modell?

Warum nicht jede Aufgabe ein Frontier-Modell braucht

Nicht jede Aufgabe in einem Marketing-Workflow braucht das leistungsfähigste verfügbare Modell.

Eine Betreff-Zeile generieren, einen Text kategorisieren, einen Datensatz normalisieren: Das erledigt ein kleineres, günstigeres Modell genauso gut. Es braucht nur einen Bruchteil der Kosten.

Die kreative Synthesis, die strategische Analyse, das nuancierte Kundenfeedback: Dort zahlt sich das Frontier-Modell aus.

Teams, die das nicht unterscheiden, zahlen Opus-Preise für Haiku-Aufgaben. Das ist kein Edge Case. Das ist der Standard in den meisten Marketing-Umgebungen heute.

Die Kunst liegt im Routing. Welche Aufgaben brauchen wirklich das teuerste Modell? Und welche funktionieren mit einem kleineren Modell genauso gut?

Wie ein anbieteragnostisches Marketing OS aufgebaut wird

Anbieteragnostisch bedeutet nicht, kein Lieblingsmodell zu haben. Es bedeutet, dass das System nicht aufhört zu funktionieren, wenn sich das Modell ändert.

Das erfordert drei Bausteine:

Erstens: eine Abstraktionsschicht. Modellaufrufe in Workflows sollten nicht direkt an einen Anbieter gebunden sein. Wenn heute "rufe Claude Opus auf" in den Prompts steht, ist jede Preisänderung ein manueller Umbau. Eine Routing-Logik, die entscheidet, welches Modell für welche Aufgabe optimal ist, hält das System stabil, egal was Anthropic, OpenAI oder Google mit ihren Preisen machen.

Zweitens: Aufgaben-Klassifikation. Nicht jeder Task ist gleich komplex. Routineaufgaben, Klassifikationsaufgaben und Generierungsaufgaben haben unterschiedliche Anforderungen an Modellgröße und Qualität. Wer das nicht unterscheidet, optimiert nicht. Er subventioniert.

Drittens: einen getesteten Fallback. Mindestens ein alternatives Modell sollte im Stack aktiv und getestet sein. Nicht als Backup für den Notfall, sondern als regulärer Bestandteil der Routing-Logik. Das hält die Switching-Kosten gering und die Verhandlungsposition stark.

1. Abstraktionsschicht Modellaufrufe dürfen nicht fest an einen Anbieter oder einen Modellnamen gebunden sein. Eine zentrale Routing-Logik wählt je Aufgabe das passende Modell. So bleibt das System stabil, auch wenn sich Preise, Namen oder Verfügbarkeit ändern.
2. Aufgaben-Klassifikation Aufgaben unterscheiden sich in Komplexität und Qualitätsanforderungen. Routine-, Klassifikations- und Generierungsaufgaben lassen sich mit kleineren, günstigeren Modellen zuverlässig lösen. Wer nicht differenziert, optimiert nicht – er subventioniert.
3. Getesteter Fallback Mindestens ein alternatives Modell sollte aktiv integriert und regelmäßig genutzt werden. Nicht nur als Notfall-Backup, sondern als Teil der normalen Routing-Entscheidung. Das senkt Switching-Kosten und stärkt die Verhandlungsposition.

Was der Anthropic-Börsengang damit zu tun hat

Die Nachricht ist nicht, dass Anthropic jetzt schlechter wird. Das Gegenteil ist wahrscheinlicher. Mit dem Kapital wird die Plattform ausgebaut, die Integration vertieft, der Stack stärker.

Das ist genau der Punkt. Je tiefer Claude in die Workflows eingebettet ist, desto höher die Switching-Kosten. Und desto weniger Preisverhandlungsmacht.

Ein Marketing OS dreht dieses Verhältnis um. Du profitierst von der Plattformtiefe, ohne dich ihr auszuliefern. Das System läuft mit Claude. Aber nicht nur mit Claude.

Die zwei Fragen, die jetzt zählen

Wenn du nach diesem Artikel eine Sache tust, dann diese: Beantworte für dich die folgenden zwei Fragen.

Erstens: Welche Aufgaben in eurem Marketing-Workflow erledigt ihr gerade mit einem Frontier-Modell, obwohl ein kleineres Modell ausreichen würde?

Zweitens: Was passiert, wenn der Preis eures Hauptmodells sich verdoppelt? Funktioniert euer System noch, oder baut ihr neu?

Wenn die zweite Frage Unbehagen auslöst, ist das ein Signal.

• 2–3 Jahre – Zeitfenster für strukturellen Vorteil durch frühe Einbettung in Workflows
• 1 alternatives Modell – Mindestanforderung als aktiv getesteter Fallback im Stack
• 12 Monate – Zeitraum, in dem Architektur wichtiger ist als das gewählte Modell

Die meisten Marketing-Teams werden in den nächsten zwölf Monaten nicht wegen des Modells gewinnen, das sie nutzen. Sie werden wegen der Architektur gewinnen, die sie gebaut haben.

Wer jetzt ein anbieteragnostisches, token-optimiertes Marketing OS aufbaut, sichert sich einen strukturellen Vorteil, unabhängig davon, welches Modell nächstes Quartal das beste ist.

Häufige Fragen zu Marketing OS (FAQ)

Woran erkenne ich, dass mein System von einem einzelnen Modell abhängig ist?

Typische Signale sind Prompts oder Automationen, die explizit einen Modellnamen voraussetzen, sowie Workflows, die bei Modellwechseln manuell angepasst werden müssen. Wenn Preisanpassungen eines einzelnen Anbieters sofort zu Umbauarbeiten führen, besteht eine kritische Abhängigkeit.

Welche Aufgaben eignen sich für kleinere, günstigere Modelle?

Routineaufgaben wie Betreffzeilen, Klassifikationen oder Datennormalisierung lassen sich häufig mit kleineren Modellen zuverlässig erledigen. Entscheidend ist, Qualitätskriterien pro Task zu definieren und Ergebnisse regelmäßig zu prüfen.

Wie setze ich eine Abstraktions- und Routing-Schicht pragmatisch um?

Statt Modellnamen in Prompts zu verankern, sollte eine Zwischenschicht je Aufgabe Parameter und Auswahlkriterien verwalten. Diese Logik entscheidet zur Laufzeit, welches Modell genutzt wird, und kann bei Preis- oder Qualitätsänderungen zentral angepasst werden.

Wie viele Fallback-Modelle brauche ich und wie teste ich sie?

Mindestens ein alternatives Modell sollte aktiv eingebunden und regelmäßig in realen Workloads mitlaufen. Vergleichstests auf repräsentativen Aufgaben und ein periodischer Review sichern, dass die Fallback-Optionen wirklich einsatzfähig bleiben.

Was mache ich, wenn sich der Preis meines Hauptmodells kurzfristig erhöht?

Mit einer bestehenden Routing-Schicht lässt sich der Anteil geeigneter Tasks rasch auf günstigere Modelle umstellen. Wichtig ist, vorab Schwellenwerte und Regeln zu definieren, ab wann automatisch umgeroutet wird.