AI-Modelle 2026: welches wir wofür einsetzen.

Es gibt eine Frage, die wir im ersten Audit-Call ausnahmslos hören: "Aber nutzt ihr ChatGPT?". Die kurze Antwort lautet nein. Die lange Antwort ist die technische Architektur, mit der wir autonome Systeme in einundzwanzig Tagen in Produktion bringen. Es lohnt sich, sie vollständig zu erklären, denn dies ist der Punkt, an dem ein AI-Anbieter aufhört, austauschbar zu sein.

Die Lüge vom "einzigen Modell"

Der Mainstream-Markt ist besessen vom "besten Modell überhaupt". Es gibt ein ständiges Wettrennen festzustellen, ob das neueste GPT-5 vom neuesten Claude Opus 4.7 geschlagen wurde, ob Gemini 3 in einem bestimmten Benchmark schneller ist, ob ein neues Frontier-Modell die Rangliste endlich verschoben hat. Es ist ein nützliches Gespräch für Tech-Journalisten, aber völlig irrelevant für jeden, der Produktivsysteme baut.

Bei Jigen feuern wir keinen Anbieter an. Wir nutzen alle. Unsere Infrastruktur basiert auf einem starren Ingenieursprinzip: task-getriebenes dynamisches Routing. Wir schicken keine komplexe Mathematik-Query an dasselbe Modell, das wir für Cold-Outreach per E-Mail nutzen. Es wäre wie ein Skalpell zu nehmen, um einen Nagel einzuschlagen. Der Anbieter, der vorschlägt "wir machen alles auf einem Modell", gesteht damit, nie ein Produktivsystem mit realen Kosten geführt zu haben — denn wer es geführt hat, kennt sie.

Wie Jigen orchestriert · die Karte 2026

Wenn wir einen Aurora-Agenten bauen oder einen Back-Office-Flow automatisieren, ist das Hirn des Systems ein Orchestrator, der Tasks in Echtzeit an spezifische Modelle verteilt. Die Karte, die wir heute verwenden:

1 · Langes Reasoning, komplexe Analyse, schweres Coding. Für die Manipulation strukturierter Daten, Skript-Orchestrierung und logisch-mathematische Tasks ist unser Workhorse Claude Opus 4.7. Seine Fähigkeit, komplexen Anweisungen rigide zu folgen, ohne zu entgleisen, macht ihn zur naheliegenden Wahl für die tiefe Ingenieurs-Schicht. Er kostet mehr als die anderen, aber das Qualitäts-/Fehler-Verhältnis rechtfertigt es, wenn der Task keine Regressionen toleriert.

2 · Schnelle Tool-Calls, operative Automatisierungen mit hohem Volumen. Für Tasks, die mittleres Reasoning, aber niedrige Latenz und hohes Volumen benötigen — Lead-Qualifikation, E-Mail-Klassifikation, strukturierte Extraktion aus PDF — ist der Workhorse Claude Sonnet 4.6. Mittlere Kosten, doppelte Geschwindigkeit gegenüber Opus, ausreichende Qualität für 90% der operativen Tasks.

3 · Allgemeines Reasoning, Vision und unstrukturierte PDFs. Wenn das System Screenshots von Legacy-Oberflächen interpretieren, gemischte Bild+Text-Dokumente analysieren oder allgemeine multimodale Logik handhaben muss, vertrauen wir auf die GPT-5-Familie. Sie ist robust, vorhersehbar, hat ausgereifte native Tool-Calls und ist der Anbieter, dessen Preise in den letzten Monaten am schnellsten gefallen sind — nützlich für volumenstarke Tasks.

4 · Websuche, frischer Kontext, Abfragen mit Zeitbezug. Für Tasks, die Informationen jenseits des Cutoffs des Hauptmodells benötigen — Wettbewerbsanalyse, Event-Monitoring, Preisbenchmarking — nutzen wir Gemini 3 mit nativem Suchmaschinenzugriff. Der Punkt ist nicht die Reasoning-Qualität (Claude und GPT sind in vielen Kategorien vergleichbar oder besser), der Punkt ist der Zugang zu aktuellem Kontext in einem einzigen Round-Trip.

5 · Massenklassifikation, binäre Entscheidungen mit hohem Volumen. Für Tasks, die nur einen Ja/Nein-Output, eine Kategorie aus vier, eine Schwelle benötigen, nutzen wir die kleinen Tier — Claude Haiku 4.5 oder GPT-5 mini. Kosten: ein Bruchteil der Top-Tier. Latenz: unter 200ms. Es können Tausende Aufrufe pro Sekunde laufen, ohne dass die Task-Kosten den Task-Wert übersteigen.

Wahlmatrix · welches Modell, warum

Für diejenigen, die ein schnelles Raster wollen, hier wie wir über die Trade-offs denken. Es ist keine universelle Wahrheit — es ist das Muster, das für die typischen Tasks eines Produktivsystems 2026 funktioniert:

Die Matrix ist nicht statisch. Wir überprüfen sie quartalsweise — Q1, Q2, Q3, Q4 jedes Jahres — und wenn ein Anbieter eine Version veröffentlicht, die das Qualitäts-/Kostenverhältnis bei einem Task ändert, aktualisieren wir die Karte. Eine Praxis, die Disziplin erfordert: ohne geplante Reviews fossilisiert das Routing auf Entscheidungen, die vor sechs Monaten aus Gründen getroffen wurden, an die sich niemand mehr erinnert.

Der Wettbewerbsvorteil der Orchestrierung

Mit diesem Paradigma zu entwickeln, bietet drei asymmetrische Vorteile.

Isolierung von den Modellkriegen. Wenn morgen ein Anbieter die Preise um fünfzig Prozent anhebt oder eine Downtime von achtundvierzig Stunden erleidet, halten unsere Kunden nicht an. Der Orchestrator führt einen automatischen Fallback auf das zweitbeste verfügbare Modell für diesen spezifischen Task aus. Der Prompt ist anbieterunabhängig geschrieben (mit kleinen Adaptern für spezifische Tool-Call-Syntaxen), der Test ist auf zwei Anbietern wiederholbar, der Fallback ist eine Sekunden-Entscheidung, kein Drei-Monats-Projekt.

Senkung der Inferenz-Kosten. Statt Premium-Kosten für ein Top-Modell zu zahlen, nur um drei Entitäten aus einer eingehenden E-Mail zu extrahieren (ein Task, den ein kleines Tier in Millisekunden zu nahezu null Kosten löst), reservieren wir die schwere Artillerie nur für Entscheidungen hoher Ebene. Der Unterschied bei realen Volumina ist enorm: ein schlecht orchestriertes System, das Opus für alles nutzt, kann das Vierzigfache eines gut orchestrierten Systems auf demselben Volumen kosten.

Geschwindigkeit der Übernahme von Neuerungen. Wenn ein neues Modell erscheint — Claude 4.8, GPT-5.5, Gemini 4 — müssen wir das System nicht neu schreiben. Wir fügen den neuen Anbieter als Option hinzu, testen ihn auf einer Teilmenge von Tasks, nehmen ihn ins Routing auf, wenn er die Qualitäts-/Kostenkriterien besteht. Durchschnittliche Zeit, um ein neues Modell in Produktion einzubinden: zwei-drei Tage. Agenturen, die ihre Architektur an einen einzigen Anbieter gebunden haben, brauchen sechs Monate für die Migration, wenn der Anbieter die Bedingungen ändert — und zahlen in der Zwischenzeit die Differenz.

Reale Kosten · Beispielzahlen

Ein anonymisiertes Beispiel eines Systems, das heute für einen unserer Kunden in Produktion läuft. Ein Inbound-Lead-Qualifikations-Agent: erhält eine E-Mail, entscheidet, ob es ein Ziel ist, extrahiert strukturierte Daten, schreibt die erste automatisierte Antwort.

Schlecht orchestrierte Architektur (ein einziges Top-Modell für alles):

• Initiale Klassifikation "ist das ein echter Lead?" auf Opus 4.7 → ~9 Cent pro Aufruf
• Datenextraktion auf Opus 4.7 → ~12 Cent pro Aufruf
• Antwortschreiben auf Opus 4.7 → ~14 Cent pro Aufruf
• Gesamt pro Lead: ~35 Cent. Bei tausend Leads pro Monat: ~350 EUR/Monat reine Inferenz.

Gut orchestrierte Architektur (gleicher funktionaler Outcome):

• Initiale Klassifikation auf Haiku 4.5 → ~0,3 Cent pro Aufruf
• Datenextraktion auf Sonnet 4.6 → ~3 Cent pro Aufruf
• Antwortschreiben auf Opus 4.7 (das ist der Task, bei dem Qualität zählt) → ~14 Cent pro Aufruf
• Gesamt pro Lead: ~17,3 Cent. Bei tausend Leads pro Monat: ~173 EUR/Monat.

Fünfzig Prozent Ersparnis bei gleicher Funktionalität, ohne messbare Output-Qualitätsverschlechterung. Reale Zahlen, nicht illustrativ. Bei Volumina von zehntausenden Aufrufen pro Monat — dem typischen Fall eines mittleren Kunden — wird der Delta zum Unterschied zwischen einem nachhaltigen System und einem, das der Kunde nicht mehr nutzt, sobald er die erste API-Rechnung sieht.

Der Mythos der proprietären Daten

Ein weiteres Buzzword, das Agenturen gerne verkaufen, ist die Illusion, "die AI Ihres Unternehmens zu erschaffen, indem man ein Modell von Grund auf trainiert". Eine ungerechtfertigte Investition, die zum Premium-Preis verkauft wird. In neunundneunzig Prozent der Unternehmensfälle produziert das Training von Grund auf ein Modell, das schlechter ist als jenes, das man per API nutzen könnte, kostet das Zehnfache und wird beim ersten Upgrade des Frontier-Modells obsolet (was typischerweise alle drei bis sechs Monate passiert).

Wir arbeiten mit hochoptimierten Retrieval-Augmented-Generation-Architekturen. Wir nehmen das Unternehmenswissen des Kunden, indexieren es in einer Vektordatenbank und füttern es mit dem in diesem präzisen Moment besten Modell, das nur den nötigen Kontext erhält. Die Daten bleiben beim Kunden, das System ist in Echtzeit aktualisierbar (ohne irgendetwas neu zu trainieren), das Ergebnis geht in drei Wochen in Produktion statt in sechs Monaten, und — entscheidender Punkt — wenn das nächste Modell erscheint, wird der Anbieter in dreissig Minuten getauscht, nicht in drei Monaten.

Echte Ausnahmen zum Muster (wo Fine-Tuning Sinn macht): Domänen mit sehr engem Fachvokabular, wo selbst Frontier-Modelle eine messbare, wiederholte Lücke zeigen. Vertikales Recht, klinische Pharma, komplexer proprietärer Code. Dort ist Fine-Tuning eine Entscheidung, die nach dem Beweis getroffen wird, dass Retrieval nicht reicht, nie davor.

Datensicherheit · wo sie tatsächlich leben

Ein Punkt, den viele Kunden fragen und wenige Agenturen ehrlich erklären. Die Daten, die durch ein orchestriertes AI-System fliessen, leben an drei Orten, jeder mit unterschiedlichen Regeln:

Daten beim Kunden · immer. Die Datenbank mit dem Unternehmenswissen (Dokumente, Verträge, Knowledge Base) bleibt in der Infrastruktur des Kunden, auf einer Cloud unter seiner Kontrolle. Kein Dokument "reist" dauerhaft zu den AI-Anbietern.

Daten in Transit · ephemer. Wenn ein Agent eine Abfrage stellt, erhalten die AI-Anbieter den Prompt — der den vom RAG abgerufenen Kontext einschliesst — und produzieren eine Antwort. Standardmässig trainieren die Enterprise-Bedingungen von Claude, GPT und Gemini ihre Modelle nicht auf API-Daten. Es können zusätzliche DPAs unterzeichnet werden, die jegliches Storage der Prompts blockieren. Der Kunde weiss genau, welche Daten passieren, weil jeder Aufruf geloggt wird.

Daten on-premise · nur wenn obligatorisch. Für regulierte Sektoren (Banking, Healthcare mit PHI, Verteidigung) existieren self-hosted-Deployment-Optionen der Anbieter, oder Open-Source-Frontier-Modelle, die on-premise laufen. Kostet mehr, erfordert raffiniertere Ops, aber in diesen Fällen ist es nicht verhandelbar. Der Anbieter, der "alles Cloud, vertraut uns" vorschlägt, ohne das On-Premise-Thema anzugehen, weiss nicht, was er verkauft.

Wann KEIN Modellwechsel

Die entgegengesetzte Versuchung zur Monokultur ist die permanente Fluktuation: bei jedem neuen Modell, das erscheint, schreiben wir die Architektur neu. Auch das ist ein Fehler. Ein Modell in Produktion zu wechseln, hat versteckte Kosten — Prompt-Regressionstests, reale Kostenprüfung auf Kundenvolumen, Output-Validierung auf Grenzfälle — die oft den inkrementellen Nutzen übersteigen.

Die operative Regel, die wir verwenden: wir wechseln ein Modell in Produktion nur, wenn das neue mindestens fünfzehn Prozent messbare Verbesserung am einzelnen Task bietet, für den es bewertet wird (Qualität, Latenz oder Kosten, kein vager Mix), und wenn die Wechselkosten in weniger als dreissig Tagen Ausführung gedeckt werden. Unter dieser Schwelle bleibt das aktuelle Modell. Fluktuation ohne Kriterien kostet mehr als obsolete Modelle.

Schneller Test · ist Ihr Anbieter wirklich multi-Modell?

Ein diagnostisches Raster für die Geschäftsführung eines Unternehmens, das einen AI-Anbieter bewertet. Fünf Fragen:

1. Wie viele verschiedene Anbieter berührt Ihr System an einem typischen Tag? Gesunde Antwort: mindestens zwei (realistischer: drei oder vier). Verdächtige Antwort: nur einer.
2. Wenn der primäre Anbieter vierundzwanzig Stunden offline geht, was passiert mit meinem System? Gesunde Antwort: automatischer Switch zum zweiten Anbieter innerhalb von Minuten, eventuell mit dokumentierter Teildegradierung. Verdächtige Antwort: "ist nie passiert".
3. Was kostet ein Aufruf heute, für jeden Task-Typ meines Systems? Gesunde Antwort: eine Tabelle mit realen Zahlen. Verdächtige Antwort: "kommt auf das Volumen an" ohne Ziffer.
4. Wie wird die Ankunft eines neuen Modells gehandhabt? Wie lange dauert die Integration? Gesunde Antwort: existierende Validierungs-Pipeline, Einbindung in zwei-drei Tagen. Verdächtige Antwort: "wir bewerten Fall für Fall" ohne Fristen.
5. Kann ich das strukturierte Log eines Aufrufs sehen? Welches Modell hat ihn behandelt? Gesunde Antwort: ja, im Dashboard, mit Prompt + Modellversion + Kosten. Verdächtige Antwort: "Logs sind intern".

Drei gesunde Antworten von fünf bedeuten einen kompetenten Anbieter. Zwei oder weniger bedeuten, dass der Anbieter improvisiert — und wenn der Preis des Modells, das er nutzt, steigt, erfährt er es erst, wenn die Rechnung kommt.

Kaufen Sie nicht "Künstliche Intelligenz". Kaufen Sie eine Ingenieurs-Infrastruktur, die gebaut ist, um wachsende Volumen zu tragen, Sie vor Anbieter-Downtimes zu schützen, Inferenzkosten zu senken, neue Modelle ohne Neuschreiben des Systems zu integrieren. Es ist das einzige, das für Ihre Nettomarge zählt — der Rest ist Pitch-Jargon.

Jigen-Lesart: die Modellkarte oben ist unsere zum 2026-Q2. Sie ist dazu bestimmt, sich zu ändern — jedes Quartal überprüfen wir Qualität-/Kosten-/Latenz-Benchmarks und aktualisieren das Routing. Der Anbieter, der sich an einen einzigen Provider bindet oder seinen Stack nie aktualisiert, geht eine Wette ein, die in sechs Monaten teuer wird. Multi-Provider ist keine luxuriöse Architekturoption — es ist der Mindest-Default für ein Produktivsystem 2026.