Die Frage, wie groß ein solches Modell sein darf, hat keine einzelne Antwort in Megabyte. Sie hat zwei Budgets, die unterschiedlich funktionieren, und einen Posten, der fast immer unterschätzt wird.

Warum ein 3D-Modell anders lädt als ein Video

Ein Produktvideo wird einmal berechnet und dann nur abgespielt. Ein 3D-Modell im Browser zeichnet dagegen die Grafikkarte des Besuchers bei jeder Bewegung neu, aus Dreiecken für die Oberfläche und aus Texturen, also Bildern für Farbe und Material. Deshalb kann ein Kunde die Einhausung drehen oder eine andere Füllung wählen, und deshalb entscheidet sein Gerät, ob das flüssig gelingt.

Ein Konfigurator liegt zwischen zwei Extremen. Ein Video legt jedes Bild vorher fest, ein CAD-Programm lässt jedes Maß offen, und im Konfigurator stehen die Regeln fest, innerhalb derer der Kunde frei wählt.

Für die Frage nach der Größe heißt das: Die Last trägt das Gerät des Kunden. Die Grenze setzt deshalb das schwächste Gerät, mit dem Ihre Zielgruppe das Modell öffnet.

Zwei Budgets, die man getrennt rechnen muss

Das erste Budget ist die Übertragung. Geometrie, Texturen und der Programmcode für die Darstellung müssen über das Netz, und ihre Summe bestimmt zusammen mit der Bandbreite, wie lange der Kunde wartet. Verdichtungsverfahren machen die Daten für den Transport kleiner.

Das zweite Budget ist der Grafikspeicher. Um zu zeichnen, hält das Gerät Geometrie und Texturen in einer Form vor, mit der die Grafikkarte direkt arbeiten kann, und diese Form ist oft viel größer als die übertragene Datei. Reicht der Speicher nicht, ruckelt die Darstellung, oder die Seite bricht ab.

Die beiden Budgets verhalten sich unterschiedlich. Eine gut verdichtete Datei lädt schnell und kann trotzdem den Grafikspeicher eines Telefons überfordern, und eine Datei, die in den Speicher passt, kann trotzdem zu lange laden.

Warum meist die Texturen den Ausschlag geben

Die Größe einer Textur wächst mit dem Quadrat ihrer Kantenlänge. Eine Textur mit 2.048 mal 2.048 Bildpunkten hat viermal so viele Bildpunkte wie eine mit 1.024, und jedes Material trägt oft mehrere davon, etwa für Farbe, Oberflächenstruktur und Rauheit. Bei acht Materialien mit je drei Texturen sind das bereits 24 Bilder.

Hinzu kommt der Unterschied zwischen Datei und Speicher. JPG und PNG sind für die Übertragung verdichtet, die Grafikkarte kann mit diesen Formaten aber nicht zeichnen, deshalb werden sie vorher vollständig entpackt. Zusätzlich hält das Gerät meist verkleinerte Fassungen jeder Textur für entfernte Ansichten vor, was den Bedarf um rund ein Drittel erhöht.

Texturen im Format KTX 2.0 gehen einen anderen Weg. Sie werden beim Laden in ein Format umgewandelt, das die Grafikkarte auch danach verdichtet halten kann, und senken so nach Angaben der Khronos Group den Grafikspeicher. Über eine Erweiterung lassen sie sich direkt in glTF-Dateien einbetten, das gängige Lieferformat für 3D im Web.

Es ist wie bei Akten: Im Ordner brauchen sie wenig Platz, ausgebreitet auf dem Schreibtisch sehr viel. Eine JPG-Textur liegt auf der Grafikkarte ausgebreitet, eine Textur im GPU-Format bleibt im Ordner.

Rechnen Sie das Ladebudget der Einhausung nach

Der Rechner trennt beide Budgets und prüft sie gegen drei angenommene Geräteklassen. Voreingestellt ist die Einhausung, wie sie aus einem Renderprogramm kommen könnte: 900.000 Dreiecke, acht Materialien mit je drei Texturen in 2.048 Bildpunkten, JPG-Texturen und verdichtete Geometrie. Alle Werte sind Beispielwerte, auch die Annahmen zu Bandbreite und Grafikspeicher der Geräteklassen.

Achten Sie auf die Zeile Smartphone. Schalten Sie dann das Texturformat von JPG auf KTX2 und senken Sie danach die Texturauflösung auf 1.024.

In der Voreinstellung überträgt das Modell rund 25 Megabyte, davon rund 21 Megabyte Texturen, und belegt 537 Megabyte Grafikspeicher. Mit KTX2 sinkt der Grafikspeicher in der Rechnung auf 89 Megabyte, das Telefon lädt aber immer noch zu lange. Erst mit 1.024 Bildpunkten fällt die Ladezeit auf rund 7,5 Sekunden, und das Urteil wechselt auf „läuft mit Abstrichen“.

Was die Rechnung über das Beispiel verrät

Die Geometrie ist in diesem Beispiel der kleinere Posten, solange sie verdichtet wird. Verdoppeln Sie die Dreiecke auf 1,8 Millionen, wächst die Übertragung nur um rund drei Megabyte. Schalten Sie die Verdichtung aus, wird die Geometrie mit rund 25 Megabyte zum größten Posten, und schon das Notebook lädt zu lange.

Die Texturauflösung ist der stärkste Hebel. Mit 4.096 Bildpunkten vervierfachen sich die Texturen, und in der Rechnung scheitert selbst der Bürorechner an der Ladezeit. Welche Auflösung ein Material braucht, hängt davon ab, wie nah der Kunde herangehen kann: Eine Füllung aus Drahtgitter, die nie näher als einen Meter vor der Kamera erscheint, braucht keine Textur für die Lupe.

Die Rechnung ist bewusst einfach. Sie kennt keine Zeichenaufrufe, keine Schatten und kein schrittweises Nachladen, und ihre Faktoren für Verdichtung und Speicher sind Annahmen. Sie zeigt Größenverhältnisse und sagt nicht voraus, wie ein bestimmtes Modell auf einem bestimmten Gerät läuft.

Wie ein Konfigurator von innen aufgebaut ist

Das Ladebudget betrifft nur eine von sechs Stufen, die ein Modell auf dem Weg von der Konstruktion zum Kunden durchläuft. Die meisten Vorhaben stocken dabei weniger an der Grafik als am Regelwerk.

Modell. Die Geometrie braucht benannte Bauteile wie Pfosten, Tür und Füllung, Maße in Millimetern und einen festen Ursprung. Kommt das Modell als einzelnes Netz ohne benannte Teile aus einem Renderprogramm, weiß die Software nicht, wo die Tür aufhört, und jede Variante wird Handarbeit.

Regelwerk. Hier steht, welche Optionen es gibt, welche sich ausschließen und welche Grenzmaße gelten. Oft stecken diese Regeln im Kopf weniger Personen, oder Preisliste und Konfigurator führen getrennte Optionslisten, die auseinanderlaufen.

Varianten. Der eingestellte Zustand gehört an eine Stelle, die ein Link mitnehmen kann, etwa in die Adresse der Seite. Lebt er nur im Speicher des Browsers, löscht die Zurück-Taste die Auswahl, und niemand kann seine Konfiguration weiterschicken.

Preisgerüst und Stückliste. Mengen sollten aus derselben Geometrie stammen wie das Bild, sonst weicht eine getrennt gepflegte Stückliste irgendwann ab. Preisstaffeln gehören nicht in den Browser, weil jeder sie dort auslesen kann.

Darstellung. Material, Licht, Kamera, Beschriftung und Ladereihenfolge entscheiden über das Ladebudget. Dazu gehört die Entscheidung, wann nicht gezeichnet wird, denn ein endlos rotierendes Modell leert Akkus.

Ausgabe. Am Ende steht, was der Kunde abschickt: eine Anfrage mit vollständigem Zustand, eine Stückliste oder eine Datei für die Fertigung. Kommt die Anfrage ohne Konfiguration an, baut der Innendienst von Hand nach, was der Kunde schon eingestellt hatte.

Wie eine parametrische Definition als Dienst hinter einem solchen Konfigurator laufen kann, beschreibt Vom Grasshopper-Modell zum Web-Konfigurator. Zwei Rechner, die Mengen und Dateien aus einer Regel ableiten, sind der Fassaden-Rationalisierer und der Nesting-Rechner.

Was vor dem Export geklärt sein sollte

Die meisten Größenprobleme entstehen beim Export, und die meisten lassen sich mit wenigen Entscheidungen davor vermeiden. Nach Wirkung sortiert sind es sechs.

1. Die schwächste Geräteklasse der Zielgruppe festlegen und beide Budgets für sie rechnen.
2. Die Texturauflösung je Material nach dem kleinsten Betrachtungsabstand wählen.
3. Texturen zwischen Materialien teilen und wiederholen, statt jede Fläche einzeln zu bemalen.
4. Ein GPU-taugliches Texturformat prüfen, wenn der Grafikspeicher knapp ist.
5. Geometrie für die Auslieferung verdichten und Details entfernen, die aus Betrachtungsabstand nicht sichtbar sind, etwa Gewinde, Schrauben und innenliegende Teile.
6. Die Browserfassung automatisch aus der Konstruktion ableiten, statt sie von Hand nachzubauen.

Der letzte Punkt entscheidet über die Pflege. glTF ist nach Beschreibung der Khronos Group ein Format für die effiziente Übertragung und das Laden von 3D-Szenen, also ein Lieferformat und kein Arbeitsformat. Wird die Browserfassung bei jeder Konstruktionsänderung neu erzeugt, bleibt sie aktuell, während ein von Hand nachgebautes Modell mit der ersten Änderung auseinanderläuft.

Wann ein Bild die bessere Wahl ist

Gibt es ein Produkt nur in wenigen Ausführungen, sind gute Fotos in Herstellung und Pflege günstiger als jedes 3D-Modell. Ob sich ein parametrisches Modell lohnt, hängt an Variantenzahl und Änderungshäufigkeit, wie Wann sich ein parametrisches Modell rechnet ausführt.

Nutzt die Zielgruppe vor allem ältere Telefone oder langsame Verbindungen, ist ein vorab berechnetes Bild oder ein kurzes Video robuster. Und fehlt ein sauberes Konstruktionsmodell, zeigt ein Konfigurator ungeprüfte Maße, nach denen womöglich jemand bestellt.

Ob ein Kunde das Modell zusätzlich im eigenen Raum sehen sollte, ist eine eigene Frage. Wann eine Maßprüfung genügt und wann AR hilft, behandelt Passt es in den Raum?, die Leistung selbst beschreibt die Seite 3D-Konfiguratoren.

Der naheliegende Plan heißt Neubau und Umstellung an einem festen Tag. Der andere Plan zieht die Module einzeln um, lässt Alt und Neu eine Zeit lang nebeneinander laufen und schaltet das Altsystem erst ab, wenn nichts mehr darauf zugreift. Welcher Plan trägt, hängt weniger an der Technik als an den Abhängigkeiten zwischen den Modulen, und die lassen sich vorher aufschreiben und durchrechnen.

Warum ein Stichtag so viel auf einen Tag legt

Bei einer Umstellung an einem Stichtag passiert alles gleichzeitig: Die Daten werden übertragen, alle Schnittstellen zeigen auf das neue System, alle Nutzer arbeiten ab Montag in neuen Masken. Jeder dieser Schritte kann einzeln gelingen und im Zusammenspiel trotzdem scheitern, und der Fehler zeigt sich erst, wenn der erste echte Auftrag durchläuft.

Ein Stichtag gleicht dem Umzug einer Werkhalle an einem Wochenende. Klemmt am Montag eine Maschine, steht die ganze Halle, weil die alte Aufstellung bereits abgebaut ist. Dazu kommt, dass sich eine Umstellung schwer zurücknehmen lässt, sobald im neuen System die ersten Belege entstanden sind: Wer zurückschaltet, muss diese Daten wieder in das Altsystem bringen.

Daraus folgt nicht, dass ein Stichtag immer falsch ist. Es folgt, dass das Risiko eines Stichtags mit der Zahl der Module wächst, die an diesem Tag gemeinsam funktionieren müssen. Genau diese Zahl lässt sich mit einer schrittweisen Ablösung klein halten.

Eine Weiche vor dem Altsystem

Martin Fowler beschreibt das Vorgehen unter dem Namen Strangler Fig, nach einer Feige, die an einem Wirtsbaum emporwächst, bis sie ihn ersetzt. Neue Funktionen entstehen getrennt vom Altsystem, beide laufen während des Übergangs nebeneinander, und das Verhalten wandert schrittweise vom alten in das neue System. Fowler betont, dass die Zerlegung in einzeln ersetzbare Teile der eigentliche Kern ist.

Technisch braucht das eine Stelle, an der sich entscheiden lässt, welches System eine Anfrage bearbeitet. Das kann eine vorgeschaltete Schnittstelle sein, über die Portal, Lager und Buchhaltung ohnehin sprechen, oder eine Datenbanksicht, hinter der die Tabellen umgezogen werden. Diese Weiche ist Übergangsarchitektur: Sie kostet Aufwand, obwohl sie am Ende wieder verschwindet, und sie ist trotzdem der Grund, warum jeder einzelne Umzug klein bleibt.

Fehlt eine solche Stelle, weil Nutzer und Fremdsysteme direkt in die Datenbank des Altsystems schreiben, beginnt die Ablösung mit ihrem Bau. Dieser erste Schritt bringt fachlich noch nichts Neues, er macht aber sichtbar, wer das Altsystem überhaupt benutzt.

Welches Modul zuerst umzieht

Nicht jedes Modul kann jederzeit umziehen. Die Rechnungen brauchen die Aufträge, die Aufträge brauchen die Kunden, und das Mahnwesen braucht die Rechnungen. Eine solche harte Abhängigkeit heißt: Ein Modul kann erst im neuen System laufen, wenn seine Voraussetzung dort bereits läuft, oder es zieht in derselben Stufe mit ihr um.

Daraus ergibt sich eine einfache Regel. Zuerst ziehen Randmodule um, auf die sich kein anderes Modul stützt, im Beispiel etwa Versand und Angebote. Ein früher Umzug an einer Stelle mit wenig Verkehr zeigt, ob Weiche, Datenabgleich und Betrieb funktionieren, bevor ein Modul an der Reihe ist, von dem der Umsatz abhängt.

Schwieriger sind Module, die sich gegenseitig brauchen oder deren Voraussetzung selbst lange warten muss. Dann entstehen gekoppelte Umzüge, bei denen zwei Module in derselben Stufe wechseln. Eine gekoppelte Stufe ist ein kleiner Stichtag innerhalb der schrittweisen Ablösung, und sie verdient die gründlichste Vorbereitung.

Den Stufenplan selbst durchrechnen

Der Rechner setzt diese Regeln um. Er nimmt eine Liste fachlicher Module, verteilt einen einstellbaren Anteil harter Abhängigkeiten und plant daraus Stufen, in denen höchstens so viele Module umziehen wie eingestellt. Schalten Sie zwischen Stichtag und schrittweise um und beobachten Sie, in welcher Stufe das Modul Rechnungen wechselt und ob die Stufe gestrichelt als Risiko markiert ist.

Mit den Beispielwerten der Voreinstellung, zehn Modulen, zwei Modulen je Stufe und drei harten Abhängigkeiten, entstehen fünf Stufen. Die Rechnungen ziehen erst in Stufe 4 um, gekoppelt an die Aufträge, die ihrerseits auf die Kunden warten. Als Stichtag gerechnet wechseln alle zehn Module in einer Stufe, und alle drei Abhängigkeiten werden zu gekoppelten Umzügen. Mit nur einem Modul je Stufe verschwindet das Risiko ganz, dafür wächst der Plan auf zehn Stufen.

Die Zahlen sind Stufen und keine Wochen. Wie lange eine Stufe dauert, hängt vom Modul, von den Daten und vom Parallelbetrieb ab. Was der Rechner zuverlässig zeigt, ist die Struktur: welche Module warten, wo Kopplungen entstehen und welcher Hebel sie auflöst.

Parallelbetrieb heißt vergleichen

Während ein Modul umzieht, laufen Alt und Neu eine Stufe lang parallel. Das bringt nur dann Sicherheit, wenn beide Ergebnisse verglichen werden. Die Weiche schickt dieselbe Anfrage an beide Systeme, maßgeblich bleibt zunächst das Altsystem, und jede Abweichung landet in einem Protokoll, das jemand liest.

Vor dem Umschalten sollte schriftlich feststehen, wann der Parallelbetrieb endet: etwa wenn über einen vereinbarten Zeitraum keine ungeklärte Abweichung mehr auftritt und alle bekannten Sonderfälle mindestens einmal durchgelaufen sind. Ohne ein solches Kriterium bleibt der Parallelbetrieb aus Vorsicht bestehen, und das Team pflegt zwei Systeme länger als geplant.

Abweichungen sind dabei nicht immer Fehler des neuen Systems. Oft zeigt der Abgleich eine Regel, die im Altsystem nie dokumentiert wurde, etwa eine Rundung oder einen Rabatt, der nur für eine Kundengruppe gilt. Solche Funde gehören in die Beschreibung des neuen Moduls, bevor das alte abgeschaltet wird.

Wem die Daten während der Ablösung gehören

Die heikelste Frage einer schrittweisen Ablösung betrifft die Daten. Solange ein Modul in beiden Systemen existiert, braucht jedes Datenobjekt genau ein führendes System: Kundenstammdaten werden entweder im alten oder im neuen System geändert, nie in beiden. Das andere System erhält eine Kopie, und die Richtung dieser Kopie wechselt erst mit dem Umzug des Moduls.

Praktisch heißt das, früh eine Zuordnungstabelle für Kennungen anzulegen, weil das neue System eigene Nummern vergibt, und festzulegen, wie oft und in welche Richtung abgeglichen wird. Wer an beiden Enden gleichzeitig schreiben lässt, erzeugt Konflikte, die sich später kaum noch auflösen lassen.

Wenn eine Funktion früher gebraucht wird, als ihr Modul umziehen kann

Im Beispiel soll das Kundenportal früh Aufträge übergeben, das Modul Aufträge kann aber erst in Stufe 4 umziehen. Der Stufenplan beantwortet die Frage deshalb nicht allein. Eine Zwischenlösung an der Weiche kann Aufträge aus dem Portal annehmen, prüfen und über den vorhandenen Weg in das Altsystem schreiben, bis das neue Modul bereitsteht.

Eine solche Zwischenlösung ist bewusst Übergangscode. Sie sollte so gebaut sein, dass sie später vor das neue Modul umgehängt oder entfernt werden kann, und sie gehört mit einem Datum für ihre Überprüfung in den Plan. Sonst wird aus der Übergangslösung ein weiteres Altsystem.

Wann der Stichtag doch die bessere Wahl ist

Eine schrittweise Ablösung kostet Weiche, Parallelbetrieb und Datenabgleich. Diese Kosten lohnen sich nicht in jedem Fall. Ein kleines System mit wenigen Nutzern und ohne Anbindungen lässt sich oft sauberer an einem gut vorbereiteten Tag umstellen.

1. Das System ist klein: Wenn alle Module an einem Tag getestet werden können, bringt die Zerlegung wenig.
2. Es gibt keine Stelle für eine Weiche: Eine Anwendung, deren Daten nur über ihre eigene Oberfläche erreichbar sind, lässt sich schwer abschnittsweise umleiten.
3. Das Datenmodell lässt sich nicht teilen: Wenn fast jede Tabelle von fast jedem Modul geschrieben wird, entstehen in jeder Stufe gekoppelte Umzüge.
4. Der Parallelbetrieb ist teurer als das Risiko: Wenn ein Ausfall von einem Tag verkraftbar ist, darf die Vorbereitung schlanker ausfallen.

Auch dann bleibt ein Teil der Methode nützlich. Die Liste der Module und ihrer Abhängigkeiten zeigt, was am Stichtag gemeinsam funktionieren muss, und damit, was vorher gemeinsam getestet werden sollte.

Womit Sie beginnen können

Die ersten Schritte folgen derselben Logik wie der Stufenplan, und sie lassen sich im eigenen Haus beginnen. Zuerst entsteht eine Liste der fachlichen Module mit ihren Nutzern, Datenflüssen und harten Abhängigkeiten, gezählt statt geschätzt. Danach wird jede Verbindung zu anderen Systemen wie ein Vertrag beschrieben: Format, Richtung, Verhalten im Fehlerfall und Zuständigkeit.

Mit dieser Liste lässt sich ein Randmodul als erster Kandidat wählen, und an ihm zeigt sich, ob Weiche, Abgleich und Betrieb tragen. Welche Unterlagen ein neues Modul braucht, bevor ein anderes Team es betreibt, beschreibt der Leitfaden Vom Proof of Concept in den Regelbetrieb. Was beim Betrieb im eigenen Haus zu klären ist, steht unter Eine Anwendung im eigenen Haus betreiben, und woran sich Abkürzungen im Code zeigen, die jeden weiteren Umzug verteuern, unter Technische Schulden erkennen.

Soll ein Dienstleister die Ablösung begleiten, hilft der Leitfaden Prototyp weiterentwickeln lassen bei der Auswahl. Einen Überblick über Softwareentwicklung bei iiterate gibt die Seite Softwareentwicklung.

Diese Zahl ist eine Summe. Sie setzt sich aus fünf Posten zusammen, die unterschiedlich groß sind, unterschiedlich reagieren und sich mit unterschiedlichen Mitteln verkleinern lassen.

Warum eine einzelne Zeitmessung wenig erklärt

Eine Gesamtzeit beantwortet die Frage, ob ein Assistent zu langsam ist. Sie beantwortet nicht, warum, und damit auch nicht, welche Maßnahme hilft. Eine neue Grafikkarte beschleunigt nur einen der Posten, eine schnellere Suche einen anderen, und beide Investitionen können an der eigentlichen Ursache vorbeigehen.

Hilfreicher ist ein Latenzbudget, wie es aus der Planung von Echtzeitsystemen bekannt ist. Man legt eine Ziel-Antwortzeit fest und verteilt sie auf die Posten, die eine Antwort durchläuft. Überschreitet die Summe das Ziel, zeigt das Budget sofort, welcher Posten zu groß ist.

Beim Maschinenbauer aus dem Beispiel hätte ein solches Budget die Diskussion verkürzt. Statt über Grafikkarten zu streiten, hätte das Team gesehen, welcher Posten die Zielzeit überschreitet und ob er sich mit einer Einstellung verkleinern lässt. Diese Zerlegung lässt sich mit Beispielwerten selbst durchrechnen.

Die fünf Posten einer Antwort

Ein Assistent, der aus eigenen Dokumenten antwortet, arbeitet bei jeder Frage dieselbe Kette ab. Wie diese Kette im Einzelnen aufgebaut ist, beschreibt der Wissensbeitrag Retrieval-Augmented Generation. Für die Antwortzeit zählen fünf Abschnitte davon.

Dokumentabruf. Die Suche ermittelt zur Frage passende Textabschnitte aus dem Index. Ihre Dauer hängt von der Größe des Bestands, vom Suchverfahren und davon ab, wie Berechtigungen gefiltert werden.

Nachsortierung. Ein zweites Modell ordnet die gefundenen Kandidaten neu, bevor die besten an das Sprachmodell gehen. Dieser Schritt heißt Reranking, und seine Dauer wächst mit der Zahl der Kandidaten, die er bewerten muss.

Modellantwort. Das Sprachmodell liest Anweisung, Frage und Abschnitte und schreibt dann die Antwort. Das Lesen des Kontexts kostet Zeit, bevor das erste Wort erscheint, und das Schreiben kostet Zeit für jedes weitere.

Prüfschritt. Eine Prüfung gleicht Aussagen mit Belegen ab und kontrolliert Zugriffsrechte und Format. Sie macht Antworten verlässlicher und fügt dafür einen eigenen Posten hinzu.

Netz. Anfrage und Antwort laufen zwischen Browser, Anwendung, Suche und Modell hin und her. Liegt das Modell bei einem externen Anbieter, kommen weitere Wege hinzu, liegt es im eigenen Netz, fallen sie kürzer aus.

Warum die Modellantwort meist der größte Posten ist

Ein Sprachmodell schreibt keine ganzen Sätze auf einmal. Es erzeugt Tokens, also Wortbausteine, eines nach dem anderen, und jedes neue Token baut auf allen vorherigen auf. Die Schreibzeit ist deshalb ungefähr die Zahl der Tokens mal der Zeit je Token.

Die Zeit je Token ist keine feste Eigenschaft eines Modells. Sie hängt von Modellgröße, Hardware und Quantisierung ab und davon, wie viele Anfragen sich die Rechenkapazität gerade teilen. Zwei gleichzeitige Anfragen auf derselben Grafikkarte werden beide langsamer, und bei einem externen Anbieter kann der Wert mit dessen Auslastung schwanken.

Die Zahl der Tokens bestimmen dagegen Sie. Eine Anweisung, die ausführliche Einleitungen, Wiederholungen der Frage und Zusammenfassungen am Ende verlangt, verdoppelt schnell die Antwortlänge, ohne dass die Antwort besser wird.

Das erste Wort und die fertige Antwort sind zwei Zeiten

Viele Oberflächen zeigen die Antwort, während sie entsteht. Für die Nutzer zählt dann vor allem, wann das erste Wort erscheint, und weniger, wann das letzte steht. Bis zum ersten Wort laufen Abruf, Nachsortierung, Netz und das Lesen des Kontexts, erst danach beginnt das sichtbare Schreiben.

Ein Prüfschritt verändert diese Rechnung. Prüft er die fertige Antwort, bevor sie angezeigt wird, kann die Oberfläche nichts vorab zeigen, und die gefühlte Wartezeit entspricht der vollen Summe. Prüft er fortlaufend oder nur ausgewählte Aussagen, bleibt das schrittweise Anzeigen möglich, dafür kann eine bereits sichtbare Aussage nachträglich zurückgezogen werden.

Welche Variante passt, ist eine fachliche Entscheidung. Bei Auskünften, auf die hin jemand eine Maschine freigibt, ist das Warten auf die geprüfte Antwort das kleinere Übel.

Rechnen Sie ein Latenzbudget selbst durch

Die Demonstration addiert die fünf Posten zu einer Summe und trägt sie maßstäblich gegen eine Ziel-Antwortzeit auf. Voreingestellt sind Beispielwerte für einen Assistenten mit zwei Sekunden Ziel, bei denen die Summe knapp darunter liegt. Die Werte sind keine Messungen, sie machen nur die Größenverhältnisse greifbar.

Stellen Sie die Zeit je Token von 9 auf 14 Millisekunden, als würden sich zwei Anfragen eine Grafikkarte teilen. Kürzen Sie danach die Antwortlänge von 180 auf 110 Tokens und beobachten Sie die Ziellinie.

Bei 14 Millisekunden je Token ragt der Balken um 880 Millisekunden über das Ziel. Mit 110 Tokens liegt die Summe bei 1.900 Millisekunden und damit wieder unter dem Ziel, ohne dass sich an Hardware oder Modell etwas geändert hat.

Was die Rechnung zeigt und was sie auslässt

Die Modellantwort dominiert die Summe in fast jeder Einstellung. Entfallen Nachsortierung und Prüfschritt ganz, spart das in der Voreinstellung zusammen 190 Millisekunden, während 70 Tokens weniger bei 9 Millisekunden je Token 630 Millisekunden sparen. Kürzere Antworten sind deshalb oft die erste und günstigste Korrektur.

Die Rechnung hat drei Lücken, die im Betrieb zählen. Sie rechnet mit einem festen Wert je Posten, obwohl echte Zeiten streuen und Nutzer langsame Antworten stärker wahrnehmen als den Durchschnitt. Sie kennt keine Warteschlange, die entsteht, wenn mehr Fragen eintreffen, als gleichzeitig bearbeitet werden können. Und sie trennt nicht zwischen Lesen und Schreiben, obwohl lange übergebene Abschnitte vor allem das erste Wort verzögern.

Für eine belastbare Aussage braucht es deshalb Messungen am eigenen System. Sinnvoll sind Zeitstempel an jeder Übergabe und eine Auswertung, die neben dem Mittelwert auch die langsamsten Anfragen zeigt, etwa über das 95. Perzentil.

Wie die Betriebsart die Posten verschiebt

Wo das Sprachmodell läuft, verändert vor allem zwei Posten. Bei einem externen Anbieter kommen Netzwege und dessen Auslastung hinzu, im eigenen Netz fallen die Wege kürzer aus, dafür teilen sich alle Nutzer die eigene Rechenkapazität. Eine Grafikkarte, die für ein Fachteam schnell genug ist, kann bei gleichzeitigen Fragen einer ganzen Abteilung spürbar langsamer werden.

Die Betriebsarten selbst, also Cloud-Schnittstelle, Hosting in der EU und Betrieb im eigenen Haus, unterscheiden sich in weit mehr als der Antwortzeit. Eine Gegenüberstellung steht auf der Seite KI-Entwicklung, die Abwägung aus Sicht von Daten und Kosten in On-Premise vs. Cloud-LLM. Was für den eigenen Betrieb an Hardware realistisch ist, beschreibt Lokales LLM im Unternehmen, welche offenen Modelle sich lokal betreiben lassen, der Wissensbeitrag Lokale Sprachmodelle.

Für den Maschinenbauer heißt das: Bevor eine größere Grafikkarte gekauft wird, zeigt eine Messung mit gleichzeitigen Fragen, ob die Zeit je Token unter Last steigt. Steigt sie, hilft mehr Rechenkapazität. Bleibt sie stabil, liegt die Ursache in einem anderen Posten, und die neue Karte würde das Problem nicht lösen.

In welcher Reihenfolge Sie eine langsame Antwort beschleunigen

Die Reihenfolge folgt dem Verhältnis von Wirkung zu Aufwand. Die ersten Schritte ändern Konfiguration und Anweisung, erst die letzten kosten Geld.

1. Zeitstempel je Posten setzen und die langsamsten Anfragen getrennt auswerten.
2. Die Antwortlänge begrenzen: eine kurze Form in der Anweisung verlangen, Wiederholungen der Frage und Schlussformeln streichen.
3. Weniger und kürzere Abschnitte übergeben, wenn die Testfragen zeigen, dass die richtigen Stellen auch so ankommen.
4. Die Zahl der Kandidaten für die Nachsortierung prüfen, denn sie wächst oft unbemerkt mit dem Bestand.
5. Den Prüfschritt so legen, dass nichts doppelt geprüft wird, etwa Rechte vor der Suche statt nach der Antwort.
6. Häufige Fragen mit stabilen Antworten zwischenspeichern, sofern sich die Quellen selten ändern.
7. Erst danach über ein kleineres Modell, andere Hardware oder eine andere Betriebsart entscheiden.

Jede dieser Änderungen kann die Qualität der Antworten berühren. Deshalb läuft nach jedem Schritt dieselbe Testmenge, wie in Warum KI-Features in der Praxis scheitern beschrieben.

Wann die Antwortzeit zweitrangig ist

Nicht jede KI-Anwendung wartet auf einen Menschen. Extraktionen aus Dokumenten, nächtliche Auswertungen oder Zusammenfassungen für einen Bericht laufen im Hintergrund, und dort zählt der Durchsatz pro Stunde mehr als die Sekunden je Anfrage.

Umgekehrt gibt es Anwendungen, bei denen ein Budget von zwei Sekunden zu großzügig ist, etwa Sprachdialoge, in denen eine Pause wie eine Störung wirkt. Dort verschiebt sich die Rechnung zu kurzen Antworten, kleineren Modellen und einer Prüfung, die nicht auf die fertige Antwort wartet. Welche Zielzeit angemessen ist, entscheidet der Einsatz, und das Budget macht sichtbar, was diese Zielzeit kostet.

Mit diesem Satz lässt sich nicht arbeiten, weil er keinen Ort nennt. Ein KI-Feature besteht aus mehreren Stufen, und fast jeder Fehler entsteht an genau einer davon. Das Beispiel mit der Pumpe ist erfunden, der Weg zur Ursache ist übertragbar.

Warum „die KI“ keine Fehlerursache ist

Von außen sind bei einem KI-Feature zwei Dinge sichtbar: die Frage und die Antwort. Alles dazwischen wirkt wie eine geschlossene Kiste, und Fehlermeldungen landen deshalb beim Sprachmodell, weil es der einzige Baustein ist, dessen Namen alle kennen. Die naheliegende Reaktion ist ein anderes Modell, eine längere Anweisung oder ein teurerer Tarif.

In einem gebauten System ist die Kiste eine Kette. Dokumente werden eingesammelt, zerlegt, indiziert und bei jeder Frage durchsucht, erst danach formuliert ein Modell, und im besten Fall prüft eine weitere Stufe das Ergebnis, bevor es ausgegeben wird. Zerlegt man die Meldung des Technikers entlang dieser Kette, zeigt sich ein anderes Bild: Das Handbuch lag im Index, der richtige Abschnitt stand in der Trefferliste aber erst auf Rang sechs, und an das Modell gingen nur die ersten vier.

Die Reparatur liegt in diesem Fall in der Suche. Am Sprachmodell müsste niemand etwas ändern, und ein Modellwechsel hätte den Fehler bestenfalls überdeckt.

Die sieben Stufen eines KI-Features und ihre typischen Fehler

Die folgende Einteilung ist auf Fehlersuche ausgerichtet. Wie die Verarbeitung technisch abläuft, von der Zerlegung über Einbettungen bis zur Neuordnung der Treffer, erklärt der Wissensbeitrag Retrieval-Augmented Generation. Für die Fehlersuche zählt bei jeder Stufe nur, was dort schiefgeht und woran Sie es merken.

1. Eingang. Dokumente, Tickets und Datensätze werden eingesammelt, mit Fassung und Leserechten. Typische Fehler sind ein unvollständiger Bestand, veraltete Fassungen und Scans ohne Textebene. Sie merken es daran, dass Antworten eine überholte Fassung zitieren oder bestimmte Aktenbestände nie auftauchen.

2. Aufbereitung. Texte werden in Abschnitte zerlegt, die einzeln gefunden werden können. Zerreißt die Zerlegung eine Tabelle oder trennt eine Überschrift von ihrem Inhalt, findet die Suche Bruchstücke ohne Zusammenhang. Das Symptom sind Antworten, die eine Zahl ohne ihre Einheit oder Bedingung nennen.

3. Index. Die Abschnitte werden durchsuchbar abgelegt, als Stichwortindex, als Vektorindex oder beides. Fehler entstehen, wenn geänderte Dokumente nicht nachgezogen werden oder Berechtigungen beim Import verloren gehen. Dann zitiert der Assistent Dokumente, die gelöscht sind oder die die fragende Person nicht öffnen dürfte.

4. Abruf. Zur Frage sucht das System passende Abschnitte und übergibt eine begrenzte Anzahl an das Modell. Liegt die richtige Stelle zu weit hinten oder verwendet die Frage andere Wörter als das Dokument, kommt sie nie an. Das Symptom ist eine allgemeine, halb richtige Antwort, obwohl das Wissen im Bestand steht.

5. Modell. Das Sprachmodell formuliert aus Frage, Anweisung und übergebenen Abschnitten eine Antwort. Es kann Abschnitte falsch gewichten, Bedingungen weglassen oder Lücken mit plausiblem Allgemeinwissen füllen. Sie erkennen diesen Fall daran, dass die richtige Stelle nachweislich übergeben wurde und die Antwort trotzdem abweicht.

6. Prüfung. Eine Prüfstufe gleicht Aussagen mit Belegen ab, kontrolliert Format und Rechte und hält im Zweifel eine Antwort zurück. Fehlt sie oder ist sie zu großzügig eingestellt, gehen unbelegte Aussagen durch. Ist sie zu streng, bekommen Nutzer auffällig oft gar keine Antwort.

7. Ausgabe. Die Antwort erreicht ein Zielsystem, etwa eine Oberfläche, ein Ticket oder einen Datensatz. Dort gehen Fußnoten verloren, Zahlen werden umformatiert oder Felder abgeschnitten. Das Symptom ist eine Antwort, die im Protokoll richtig war und beim Nutzer falsch ankommt.

Warum die Suche so oft die Ursache ist

Ein Sprachmodell liest bei jeder Frage nur das, was im Kontextfenster liegt, also Anweisung, Frage und übergebene Abschnitte. Das ist vergleichbar mit einem Kollegen, dem man vier Seiten aus einem Ordner in die Hand drückt: Er kann gut formulieren, aber nur über diese vier Seiten. Wie viele Abschnitte übergeben werden, ist eine Einstellung, und jede Einstellung schneidet die Trefferliste an irgendeiner Stelle ab.

Dazu kommt ein Wortproblem. Der Techniker schreibt „Leckrate“, das Handbuch spricht von „Leckage“, und eine reine Stichwortsuche sieht darin zwei verschiedene Begriffe. Vektorsuche und hybride Verfahren mildern das, besonders bei Fachbegriffen, Typenbezeichnungen und zusammengesetzten Wörtern bleibt die Lücke aber ein häufiger Grund für Fehltreffer. Welche Verfahren es gibt und wie sie sich kombinieren lassen, beschreibt der Wissensbeitrag Semantische Suche im Unternehmen.

Beide Effekte sind leise. Die Antwort klingt flüssig, weil das Modell aus den übergebenen Abschnitten etwas Passendes macht, und niemand sieht die Trefferliste, in der die richtige Stelle knapp unter der Grenze steht.

Probieren Sie die Suche aus Stufe 4 selbst aus

Die Demonstration arbeitet mit dreizehn erfundenen Abschnitten aus Wartungshandbuch, Norm-Auszug, Datenblatt und Instandhaltungsprotokollen. Voreingestellt ist die Frage des Technikers, bewertet wird mit einer einfachen Stichwortsuche, die seltene Wörter stärker gewichtet. Achten Sie auf die markierte Zeile mit dem Handbuchabschnitt 4.5 Leckage und auf die Angabe, ob er beim Modell ankommt.

Stellen Sie danach sechs Abschnitte im Kontextfenster ein. Schalten Sie anschließend zurück auf vier und aktivieren Sie die Synonymliste.

Mit sechs Abschnitten rutscht der Handbuchabschnitt gerade noch ins Kontextfenster. Mit der Synonymliste steigt er auf Rang 1, weil die Suche „Leckrate“ nun auch als „Leckage“ versteht. Beide Korrekturen liegen in Stufe 4, und keine davon berührt das Sprachmodell.

Was die Demonstration zeigt und wo sie aufhört

Die zwei Korrekturen haben unterschiedliche Preise. Mehr Abschnitte im Kontextfenster verlängern jede Anfrage und geben dem Modell mehr Material, das es falsch gewichten kann. Eine Synonymliste wirkt gezielt, muss aber von jemandem gepflegt werden, der die Sprache der Dokumente und die Sprache der Fragenden kennt.

Probieren Sie auch die Frage „Wann ist die Pumpe undicht?“. Ohne Synonymliste landet der richtige Abschnitt auf Rang 5, mit ihr auf Rang 1, und direkt dahinter steht der Norm-Auszug mit seiner Definition von Dichtheit. Das ist ein gutes Ergebnis, weil beide Stellen zusammen die vollständige Antwort ergeben.

Die Demonstration hat bewusst enge Grenzen. Sie rechnet ohne Einbettungen, ohne Neuordnung und ohne Sprachmodell, und ihr Bestand ist so klein, dass sich jede Zeile nachvollziehen lässt. Die Rangzahlen sind Rechenergebnisse der Demonstration und keine Messwerte aus einem System, das Muster dahinter gilt aber auch in großen Beständen: Eine richtige Antwort setzt voraus, dass die richtige Stelle ankommt.

Eine Testmenge macht Fehler zählbar

Einzelne Meldungen zeigen, dass etwas schiefgeht, aber nicht, wie oft. Dafür braucht es eine feste Sammlung echter Fragen, zu denen vorher notiert ist, welche Fundstelle eine richtige Antwort zitieren müsste. Einige Dutzend solcher Fragen aus dem Alltag genügen für einen ersten Stand.

Die Testmenge trennt zwei Fragen, die in einer Fehlermeldung vermischt sind. Die erste lautet, ob die richtige Fundstelle im Kontextfenster angekommen ist; wenn nicht, liegt der Fehler in den Stufen 1 bis 4. Die zweite lautet, ob die Antwort aus der angekommenen Stelle richtig und belegt formuliert ist; wenn nicht, liegt er in Modell, Anweisung oder Prüfung.

Nach jeder Änderung an Zerlegung, Index, Suche, Modell oder Anweisung läuft dieselbe Testmenge erneut. So wird sichtbar, ob eine Änderung geholfen oder an anderer Stelle etwas verschlechtert hat. Wie sich Antworten an Quellen binden und bewerten lassen, bis hin zu menschlichen Stichproben, behandelt der Wissensbeitrag KI-Antworten prüfen. Warum diese Auswertung eine laufende Position ist und keine Projektphase, steht in Was ein RAG-System im Betrieb wirklich kostet.

In welcher Reihenfolge Sie eine Fehlermeldung eingrenzen

Für eine einzelne Meldung lohnt eine feste Reihenfolge, weil jeder Schritt ganze Stufen ausschließt. Wer beim Modell beginnt, prüft zuerst die Stelle, an der der Fehler am seltensten sichtbar wird.

1. Frage und erwartete Fundstelle festhalten. Ohne die Stelle, die eine richtige Antwort zitieren müsste, lässt sich kein Fehler belegen.
2. Prüfen, ob die Fundstelle im Index liegt, in der gültigen Fassung und mit den richtigen Rechten. Fehlt sie, liegt die Ursache in Stufe 1 bis 3.
3. Den Rang der Fundstelle in der Trefferliste ansehen. Liegt sie hinter der Grenze des Kontextfensters, liegt die Ursache in Stufe 4.
4. Wurde die Stelle übergeben, Anweisung und Antwort vergleichen. Weicht die Antwort trotzdem ab, liegt die Ursache in Stufe 5.
5. Zuletzt Prüfstufe und Ausgabe kontrollieren, also ob eine belegte Antwort zurückgehalten, gekürzt oder umformatiert wurde.

Dafür braucht das System ein Suchprotokoll, das zu jeder Antwort festhält, was gefunden, was übergeben und was verwendet wurde. Fehlt dieses Protokoll, bleibt nur Raten, und die Fehlersuche endet wieder beim Modell.

Wann ein KI-Feature nicht die passende Lösung ist

Nicht jede Frage aus dem Betrieb braucht sieben Stufen. Lässt sich eine Frage als feste Abfrage formulieren, etwa nach einem Termin oder einem Stammdatum, ist eine Datenbank genauer und günstiger als jedes Sprachmodell.

Zwei weitere Fälle scheitern vor der Technik. Kursieren drei Fassungen desselben Handbuchs, muss zuerst festgelegt werden, welche gilt. Und ohne eine Person, die neue Fassungen einpflegt und alte zurückzieht, veralten die Antworten, ohne dass es jemand bemerkt.

Löst ein einzelner Fehler Zahlungen, Sicherheitsrisiken oder Stillstand aus, gehört ein Mensch an die Entscheidung. Ob die Pumpe P-40 wieder anläuft, entscheidet der Techniker, und der Assistent liefert ihm die Fundstelle dazu. Wie weit Ihr eigener Bestand für ein solches System vorbereitet ist, lässt sich mit dem RAG-Readiness-Check einschätzen, welche Bausteine eine Umsetzung umfasst, beschreibt die Seite KI-Entwicklung.

Die Frage klingt nach einem Fall für Augmented Reality. Häufig genügt aber eine Rechnung, weil Einhausung und Raum ohnehin als Maße vorliegen. Wo diese Rechnung aufhört, wie fein ein 3D-Modell für die räumliche Ansicht sein muss und wann AR tatsächlich hilft, lässt sich klar trennen.

Warum die Frage nach dem Raum zwei Fragen sind

Wer fragt, ob eine Einhausung in die Halle passt, meint meistens zwei Dinge. Die erste Frage ist, ob sie mit genügend Abstand zu Wänden und Decke aufgestellt werden kann, damit Wartung und Bedienung möglich bleiben. Die zweite ist, ob die Maschine, die darin stehen soll, durch die Hallentür kommt.

Beide Fragen haben eigene Engstellen. Eine Einhausung kann bequem im Raum stehen, während die Maschine an der Türbreite scheitert, und umgekehrt. Ein Raumcheck, der nur eine der beiden Fragen beantwortet, erzeugt deshalb falsche Sicherheit.

Die Maße der Einhausung kommen im besten Fall aus einem Konfigurator, in dem der Kunde Breite, Tiefe, Höhe und Türen einstellt. Wie ein solcher Konfigurator Zeichnung, Stückliste und Gewicht aus derselben Regel ableitet, zeigt die Seite 3D-Konfiguratoren.

Was eine Raumprüfung rechnen muss

Für die Aufstellung braucht die Einhausung ihre eigene Grundfläche plus einen Wartungsabstand an jeder Seite. Vor Türen der Einhausung kommt ein Schwenkbereich hinzu, der größer sein kann als der Wartungsabstand, und in der Höhe muss Luft bis zur Decke bleiben. Welcher Abstand für eine bestimmte Maschine nötig ist, steht in deren Unterlagen, die Rechnung übernimmt ihn nur als Eingabe.

Der Schwenkbereich wird in Skizzen leicht vergessen. Eine Einhausung, die mit Wartungsabstand gerade in den Raum passt, kann trotzdem unbrauchbar sein, wenn sich ihre Tür nicht vollständig öffnen lässt. Die Rechnung setzt deshalb vor jeder Tür den größeren der beiden Werte an.

Für die Einbringung zählt der Querschnitt der Maschine. Aufrecht muss ihre schmalere Grundseite durch die Türbreite und ihre Höhe durch die Türhöhe passen. Darf die Maschine gekippt werden, kommen weitere Lagen hinzu, und die Rechnung nimmt die günstigste davon.

Aus beiden Prüfungen entstehen vier Angaben, die ein Kunde versteht: ob die Einhausung passt, ob die Maschine hineinkommt, wie viel freie Fläche bleibt und wo der engste Abstand liegt. Mehr braucht es für eine erste Antwort selten.

Prüfen Sie die Einhausung selbst

Die Demonstration rechnet beide Prüfungen für eine Einhausung von vier mal drei Metern und 2.200 Millimetern Höhe mit einer Tür. Voreingestellt ist eine Halle von 6.500 mal 4.600 Millimetern mit 800 Millimetern Wartungsabstand, alles Beispielwerte. In dieser Einstellung fehlen 200 Millimeter Tiefe, und die Draufsicht markiert die betroffenen Wände.

Senken Sie den Wartungsabstand auf 600 Millimeter, oder nehmen Sie der Einhausung einen Meter Tiefe. Stellen Sie danach die Türbreite auf 1.500 Millimeter und erlauben Sie das Kippen.

Mit 600 Millimetern Wartungsabstand passt die Einhausung, und es bleiben knapp sechs Quadratmeter frei. Bei 1.500 Millimetern Türbreite kommt die Maschine aufrecht nicht hinein, gekippt meldet die Rechnung „ja“ mit 0 Millimetern Luft.

Was die Prüfung zeigt und was sie verschweigt

Das Ergebnis mit 0 Millimetern Luft ist rechnerisch richtig und praktisch wertlos. Keine Maschine lässt sich ohne Spiel durch eine Öffnung bewegen, und Stapler, Transportrollen oder Anschlagmittel brauchen zusätzlichen Platz. Eine brauchbare Prüfung rechnet deshalb mit einer Mindestluft, die der Hersteller aus seiner Erfahrung festlegt.

Auch die Aufstellung ist vereinfacht. Die Rechnung setzt die Einhausung mittig, kennt keine Stützen, Kabeltrassen, Kranbahnen oder Bodenabläufe und fragt nicht nach der Tragfähigkeit des Bodens. Sie prüft außerdem nur die letzte Tür, obwohl der Transportweg über Flure, Rampen oder einen Aufzug oft enger ist.

Als erste Antwort taugt sie trotzdem. Sie ersetzt eine Rückfrage durch eine Zahl und zeigt, welche Angabe fehlt, bevor jemand zum Aufmaß fährt.

Welche Angaben ein Kunde liefern sollte

Die Qualität eines Raumchecks hängt an den Eingaben. Fünf Angaben decken die meisten Fälle ab, und viele Kunden können sie ohne Ortstermin liefern.

1. Raummaße: lichte Breite, Tiefe und Höhe am Aufstellort, gemessen unter der niedrigsten Stelle wie Trägern oder Leitungen.
2. Tür- und Tormaße: lichte Breite und Höhe jeder Öffnung auf dem Transportweg, auch der ersten.
3. Hindernisse: Stützen, Kabeltrassen, Kranbahnen und Bodenabläufe mit ihrer ungefähren Lage.
4. Zugang: von welcher Seite die Einhausung bedient und gewartet wird.
5. Transport: ob die Maschine gekippt werden darf und womit sie bewegt wird.

Liegen diese Angaben vor, lässt sich die Prüfung automatisch rechnen und als Teil der Anfrage mitschicken. Der Innendienst sieht dann neben der gewählten Einhausung auch, ob sie beim Kunden steht und hineinkommt.

Wie fein das Modell für die räumliche Ansicht sein muss

Soll der Kunde die Einhausung zusätzlich in 3D drehen oder später im eigenen Raum sehen, braucht jedes Teil eine Oberfläche aus Dreiecken. Ein Modell direkt aus der Konstruktion ist dafür fast immer zu fein, weil es Details trägt, die aus Betrachtungsabstand niemand sieht.

Die Zahl der Dreiecke lässt sich aus der Stückliste abschätzen: Stückzahl je Position mal Dreiecke je Teil, summiert über alle Positionen. Für die Einhausung aus der Demonstration ergibt das in einer schlichten Vertriebsansicht rund 800 Dreiecke, in einer konstruktionsnahen Fassung mit abgerundeten Profilen knapp 7.000 und in einer fertigungsnahen Fassung mit Verbindern und Fußplatten über 32.000.

Die fertigungsnahe Fassung hat damit rund 42-mal so viele Dreiecke wie die Vertriebsansicht, und für die Frage nach dem Raum zeigt sie nichts Zusätzliches. Welcher Detailgrad trägt, entscheidet der Zweck: Für Maß und Aufstellung genügt die schlichte Fassung, für eine Erklärung der Verbindungstechnik lohnt die feinere. Wie sich die Budgets eines Modells im Browser rechnen lassen, zeigt Wie groß darf ein 3D-Modell im Browser sein?.

Die vereinfachte Fassung sollte nicht von Hand entstehen. Wird sie bei jeder Konstruktionsänderung automatisch aus dem Modell abgeleitet, stimmen Maße und Stückzahlen weiter mit der Konstruktion überein. Ein nachgebautes Vertriebsmodell zeigt dagegen nach der ersten Änderung eine Einhausung, die es so nicht mehr gibt.

Wann AR die Frage besser beantwortet als eine Rechnung

Eine Rechnung braucht Maße, und manche Räume lassen sich schlecht in Maße fassen. Unregelmäßige Grundrisse, verstreute Hindernisse oder eine Halle voller Bestandsanlagen sind mit fünf Zahlen nicht beschrieben. Dann kann eine AR-Ansicht helfen, die das Modell über die Kamera eines Telefons oder Tablets maßstäblich in den realen Raum stellt.

Der Vorteil liegt im Blick vor Ort. Der Kunde sieht, ob die Einhausung vor einer Stütze endet oder eine Kabeltrasse berührt, und das Gespräch mit dem Hersteller beginnt mit einem gemeinsamen Bild. Für diesen Zweck genügt das leichte Modell der Vertriebsansicht.

AR hat eigene Grenzen. Die Lageerkennung braucht Kanten und Muster in der Umgebung, und gleichförmige Flächen, Glas oder schwaches Licht bieten davon wenig, was in Werkhallen häufig vorkommt. Die Anwendung muss zudem auf den Geräten der Kunden laufen, und der Zugriff auf die Kamera muss vorher freigegeben werden.

Die Reihenfolge ergibt sich daraus fast von selbst. Zuerst kommen Regel und Maße, dann die Rechnung, und AR dort, wo Maße den Raum nicht beschreiben.

Wann sich Raumcheck und 3D nicht lohnen

Gibt es nur wenige Ausführungen und stellt kaum ein Kunde die Frage nach dem Raum, ist eine Maßzeichnung mit Mindestabständen die günstigere Antwort. Sie lässt sich drucken, in ein Angebot legen und braucht keine Pflege.

Steht die Regel für Abstände und Varianten nur in einem Kopf, kommt die Software zu früh. Der erste Schritt ist dann, Grenzen und Abhängigkeiten aufzuschreiben, damit Konfigurator, Stückliste und Prüfung dieselbe Quelle lesen, wie Vom Grasshopper-Modell zum Web-Konfigurator beschreibt.

Und endet die Anfrage samt Raumcheck im Postfach, weil jemand sie von Hand ins ERP-System übertragen muss, verschiebt sich der Aufwand nur an eine andere Stelle. Ob sich ein parametrisches Modell für Ihr Produkt rechnet, lässt sich mit den Kriterien aus Wann sich ein parametrisches Modell rechnet abschätzen.

Wer diese drei Fälle ausschließen kann, hat eine gute Ausgangslage. Dann lohnt es, mit der Regel und dem Raumcheck zu beginnen und 3D-Modell und AR-Ansicht erst folgen zu lassen, wenn die Anfragen zeigen, dass Kunden den Raum auch sehen wollen.

Dieser Beitrag ordnet die wichtigsten Programme mit ihrem Stand im September 2026, beschreibt den Weg zum Antrag Schritt für Schritt und nennt die typischen Fehler, die eine Förderung kosten können.

Welche Arten von Förderung es gibt

Es gibt vier Arten von Förderung, und sie unterscheiden sich stärker in ihrer Logik als in ihrer Höhe. Ein Zuschuss deckt einen Teil der förderfähigen Kosten und wird nicht zurückgezahlt, verlangt aber einen Antrag vor Projektbeginn und am Ende einen Verwendungsnachweis. Ein Förderkredit läuft über die Hausbank und kann in höheren Stufen einen Zuschussanteil enthalten. Die Forschungszulage ist eine steuerliche Förderung für Forschung und Entwicklung. Beratungsangebote zahlen kein Geld aus, helfen aber, ein Vorhaben einzuordnen.

Ein KI-Projekt ist nicht schon wegen des Stichworts KI förderfähig, sondern wenn es zum Zweck eines Programms passt: Forschung und Entwicklung, Digitalisierung von Prozessen und Produkten oder externe Beratung. Bei der Recherche hilft zu wissen, dass das Bundeswirtschaftsministerium heute als BMWE (vorher BMWK) firmiert und das Forschungsministerium als BMFTR.

Bundesprogramme im Überblick

Auf Bundesebene sind für KI-Vorhaben 2026 vor allem fünf Instrumente relevant, mit sehr unterschiedlichem Status.

• ZIM (Zentrales Innovationsprogramm Mittelstand). Das BMWE fördert Forschungs- und Entwicklungsprojekte von KMU, allein oder mit Forschungseinrichtungen, dazu Innovationsnetzwerke und Durchführbarkeitsstudien. Seit dem 7. Juli 2026 gilt ein befristeter Antragsstopp: ZIM nimmt derzeit keine neuen Anträge an, eine Wiederöffnung ist für Anfang 2027 angestrebt und hängt vom Haushalt 2027 ab. Bereits gestellte Anträge werden weiter entschieden.
• KMU-innovativ. Das BMFTR fördert risikoreiche Forschungs- und Entwicklungsprojekte in Schlüsseltechnologien, darunter Informations- und Kommunikationstechnologien. Das Verfahren ist zweistufig: erst Projektskizze, dann Antrag. Stichtage sind der 15. April und der 15. Oktober, der nächste ist der 15. Oktober 2026 (Stand: September 2026). Programmseite KMU-innovativ.
• Forschungszulage. Jedes in Deutschland steuerpflichtige Unternehmen kann sie beanspruchen, unabhängig von Größe und Branche. Zuerst bescheinigt die BSFZ, dass es sich um Forschung und Entwicklung handelt, danach wird die Zulage nach Ablauf des Wirtschaftsjahres beim Finanzamt beantragt, auch für bereits durchgeführte Vorhaben. Für 2026 wurde sie über das Investitionssofortprogramm erweitert. Bescheinigungsstelle Forschungszulage.
• ERP-Förderkredit Digitalisierung (511, 512). Die KfW finanziert über die Hausbank Digitalisierung in drei Stufen, von IT, Software und Cloud über Prozessdigitalisierung, IT-Sicherheit und Schulung bis zu größeren Vorhaben, ausdrücklich einschließlich des Einsatzes von KI auf Unternehmensdaten. Der Antrag muss vor Projektbeginn gestellt werden, für die erste Stufe ist vorher ein KfW-Digitalisierungs-Check nötig. Produktseite der KfW.
• Mittelstand-Digital Zentren. Das BMWE finanziert kostenlose, anbieterneutrale Unterstützung zu Digitalisierung, KI und IT-Sicherheit, mit KI-Trainern in den Zentren. Geld wird nicht ausgezahlt. Das bestehende Netzwerk läuft bis Ende 2026 schrittweise aus, ab dem 1. Januar 2027 folgt ein neues Netzwerk mit zusätzlichem Schwerpunkt IT-Sicherheit, weiterhin kostenfrei für KMU. Mittelstand-Digital.

Für Verbünde aus Wissenschaft und Industrie läuft außerdem die BMFTR-Richtlinie zu KI-Leitprojekten in Wertschöpfungsketten, mit Frist für Projektskizzen am 1. November 2026 (Stand: September 2026).

Förderung auf EU-Ebene

Auf EU-Ebene kommen für KI-Projekte vier Wege in Frage: die European Digital Innovation Hubs, der EIC Accelerator, Kaskadenförderung und das Programm Digitales Europa.

• European Digital Innovation Hubs (EDIH). Regionale Konsortien bieten kostenlose oder vergünstigte Leistungen, etwa „Test before invest“, Schulungen und Unterstützung bei der Investorensuche, mit Schwerpunkten wie KI und Cybersicherheit. Übersicht der Europäischen Kommission.
• EIC Accelerator. Der Europäische Innovationsrat fördert einzelne Start-ups und KMU mit bahnbrechenden, marktnahen Innovationen als Zuschuss, Beteiligung oder beides. Kurzanträge sind jederzeit möglich, der nächste Stichtag für Vollanträge ist der 4. November 2026 (Stand: September 2026). EIC Accelerator.
• Kaskadenförderung. EU-geförderte Projektkonsortien geben einen Teil ihres Budgets über offene Aufrufe an Start-ups und KMU weiter, als Pauschalzuschuss, Preis oder Gutschein und mit vereinfachtem Verfahren, zum Beispiel für kleine Experimente und Pilotprojekte. Die Aufrufe stehen mindestens zwei Monate im Funding & Tenders Portal der EU. Leitfaden der Kommission (PDF).
• Programm Digitales Europa. Die Kommission schreibt Mittel für KI, Supercomputing, Cybersicherheit und digitale Kompetenzen aus. KMU profitieren meist indirekt, etwa über die EDIH. Programmseite.

Landesprogramme in Rheinland-Pfalz

In Rheinland-Pfalz vergibt die ISB die Landesförderung, und für KI-Vorhaben sind vier Programme besonders relevant.

• InnoTop. Technologieoffene Förderung von Machbarkeitsstudien und Forschungs- und Entwicklungsprojekten für neue oder verbesserte Produkte, Verfahren und Dienstleistungen, für KMU und SmallMidCaps.
• Innovationsgutschein (FuE-Auftrag). Zuschuss für KMU, die Forschung und Entwicklung für bis zu zwölf Monate an eine Hochschule oder ein Forschungsinstitut vergeben.
• IBI-EFRE. Zuschuss für Investitionen, mit denen gewerbliche KMU Digitalisierung in Produktion und Geschäftsmodellen umsetzen. Einige Branchen sind ausgeschlossen, es gilt ein Mindestinvestitionsvolumen, und der Antrag geht vor Projektbeginn über das Portal der ISB. Eintrag in der Förderdatenbank.
• Betriebsberatungsprogramm RLP. Zuschuss zu externer Beratung, ausdrücklich auch zum Thema Digitalisierung und Künstliche Intelligenz. Anträge sind seit dem 16. Dezember 2025 möglich, für einige Themen ist eine Empfehlung der Kammer nötig. Das Programm ersetzt die Ende 2025 ausgelaufene BITT-Technologieberatung. Programmseite der ISB.

Die Übersicht der Innovations- und Digitalisierungsprogramme steht auf isb.rlp.de. Im EU-Katalog für Deutschland ließ sich kein EDIH mit Sitz in Rheinland-Pfalz finden (Stand: September 2026). Naheliegend sind der EDIH Saarland, der sich auch an die Großregion richtet, und das Mittelstand-Digital Zentrum Kaiserslautern, das Unternehmen aus Rheinland-Pfalz bei der KI-Readiness unterstützt.

Landesprogramme in Nordrhein-Westfalen

In Nordrhein-Westfalen ist Mittelstand Innovativ & Digital (MID) der zentrale Zugang für KMU mit Sitz im Land, und seit dem 1. Januar 2026 bewilligt die NRW.BANK neue Projekte.

• MID-Digitalisierung. Zuschuss für die Entwicklung marktorientierter digitaler Produkte mit Schlüsseltechnologien, ausdrücklich einschließlich KI, maschinellem Lernen und Data Mining. Produktseite der NRW.BANK.
• MID-Digitale Sicherheit. Zuschuss für IT-Statusanalysen einschließlich Penetrationstests, Schulungen der Beschäftigten und grundlegende IT-Schutzmaßnahmen. Förderportal NRW.

Beide Programme vergeben Antragsplätze über ein monatliches Losverfahren. Wer gezogen wird, hat 28 Tage Zeit für den Antrag, und die Ziehung ist noch keine Förderzusage. Der Aufruf 2026 für MID-Digitale Prozesse, das externe Beratung fördert, ist bereits geschlossen, weil die maximale Zahl an Anträgen erreicht wurde (Stand: September 2026). Außerdem gibt es in NRW drei EDIH: in Dortmund, im Rheinland mit Sitz in Aachen und in Südwestfalen.

Andere Bundesländer und ausgelaufene Programme

Für alle anderen Bundesländer ist die Förderdatenbank des Bundes der schnellste Weg zu passenden Programmen. Jedes Land hat eigene Programme, und die Förderdatenbank führt Förderungen von Bund, Ländern und EU, filterbar nach Region, Antragsberechtigten und Förderart. Maßgeblich bleibt die Seite des jeweiligen Förderträgers, denn Aufrufe öffnen und schließen im Lauf des Jahres.

Ausgelaufen sind zwei Bundesprogramme, nach denen noch oft gesucht wird: Digital Jetzt nimmt keine Anträge mehr an, und go-digital wurde Ende 2024 beendet. Veraltet ist auch der Name ERP-Digitalisierungs- und Innovationskredit, das aktuelle Produkt der KfW ist der ERP-Förderkredit Digitalisierung.

Schritt für Schritt zum Antrag

Der Weg zum Antrag folgt bei fast allen Programmen denselben zehn Schritten, auch wenn sich Formulare und Portale unterscheiden.

1. KMU-Status prüfen. Nach der EU-Empfehlung 2003/361 ist ein KMU, wer weniger als 250 Beschäftigte hat und die Schwellen für Jahresumsatz oder Bilanzsumme einhält. Partner- und verbundene Unternehmen können mitzählen. Die Forschungszulage und der ERP-Förderkredit Digitalisierung stehen auch größeren Unternehmen offen. KMU-Definition der EU.
2. Kostenlose Orientierung nutzen. Ein Mittelstand-Digital Zentrum, ein EDIH oder die Förderberatung des Bundes helfen, das Vorhaben einzuordnen, bevor Aufwand in einen Antrag fließt.
3. Programm und Status prüfen. Ist das Programm offen, gibt es einen Stichtag, ein Losverfahren oder einen Antragsstopp?
4. Nicht vor der Bewilligung beginnen. Ein vorzeitiger Maßnahmenbeginn, also der Start vor Erhalt des Zuwendungsbescheids, ist in der Regel unzulässig, sofern die Richtlinie oder eine schriftliche Zustimmung ihn nicht erlaubt. Das gilt auch für verbindliche Aufträge an Dienstleister. Bei der KfW muss der Antrag vor Projektbeginn gestellt sein.
5. De-minimis-Beihilfen zusammenrechnen. Wo ein Programm De-minimis-Beihilfen gewährt, gilt eine Obergrenze von 300.000 Euro je Unternehmen innerhalb von drei Jahren. Im Antrag erklären Sie, was Sie in diesem Zeitraum bereits erhalten haben. Seit dem 1. Januar 2026 ist dafür ein zentrales Register vorgeschrieben. Verordnung (EU) 2023/2831.
6. Projektskizze schreiben. Bei zweistufigen Verfahren steht am Anfang eine kurze Skizze, die ohne Rückfragen verständlich sein muss und mit anderen Skizzen konkurriert. Betreut werden Vorhaben von Projektträgern wie DLR, PtJ oder VDI/VDE-IT, die im Auftrag des Ministeriums arbeiten. Basiswissen Projektförderung.
7. Antrag stellen. Forschungsanträge beim Bund laufen meist über easy-Online, KfW-Kredite über die Hausbank, Landesprogramme über die Portale von ISB oder NRW.BANK. Typische Unterlagen sind Projektbeschreibung mit Arbeitsplan, Kosten- und Finanzierungsplan, Bonitätsunterlagen, KMU-Erklärung, gegebenenfalls die De-minimis-Erklärung und Angebote von Lieferanten.
8. Eigenanteil sichern. Zuschüsse decken nur einen Teil der Kosten, den Rest finanziert das Unternehmen selbst.
9. Kumulierung prüfen. Förderungen lassen sich kombinieren, aber nur innerhalb der zulässigen Beihilfeintensitäten, und dieselben Kosten dürfen nie doppelt gefördert werden. Üblich ist die Aufteilung nach Kostenpositionen, etwa kostenlose Beratung, ein Kredit für die Investition und die Forschungszulage für den Entwicklungsanteil.
10. Berichten und Verwendungsnachweis erbringen. Während der Laufzeit berichten Sie an den Projektträger, am Ende folgt der Verwendungsnachweis aus zahlenmäßigem Nachweis und technischem Schlussbericht. FAQ des DLR Projektträgers.

Typische Fehler

Die typischen Fehler sind formaler Art und lassen sich vor dem Antrag vermeiden.

• Zu früh beauftragt. Wer Liefer- oder Beratungsverträge vor der Bewilligung, je nach Programm schon vor dem Antrag, verbindlich unterschreibt, kann die Förderfähigkeit verlieren.
• KMU-Status überschätzt. Die Tochter eines größeren Unternehmensverbunds ist unter Umständen kein KMU, auch wenn sie selbst klein ist.
• Status nicht geprüft. Programme schließen auch unterjährig, wie der ZIM-Antragsstopp und der volle Aufruf von MID-Digitale Prozesse 2026 zeigen.
• Losverfahren missverstanden. Bei MID ist die Ziehung keine Zusage, und die Frist danach ist kurz.
• Programmzweck verfehlt. Ein Beratungsprogramm finanziert keine Softwarelizenzen, und ein Mittelstand-Digital Zentrum zahlt kein Geld aus.
• Stichtag verpasst. Bei KMU-innovativ bedeutet eine verpasste Frist ein halbes Jahr Wartezeit.
• De-minimis falsch gerechnet. Der Dreijahreszeitraum ist rollierend und nicht an Kalenderjahre gebunden.
• Namen verwechselt. Der EDIH Rheinland sitzt in Aachen und ist keine Anlaufstelle für Rheinland-Pfalz. Ältere Blogbeiträge nennen zudem Programme und Produktnamen, die es nicht mehr gibt.

Welches Programm zu welchem KI-Projekt passt

Welches Programm passt, ergibt sich aus der Art des Vorhabens: Forschung, Einführung oder Beratung.

Forschungsnah ist ein KI-Projekt, wenn es technisches Risiko trägt, etwa ein neues Verfahren oder ein Modell für eine Fragestellung, deren Ergebnis vorher nicht feststeht. Dafür sind die Forschungszulage, KMU-innovativ, InnoTop und der Innovationsgutschein gedacht, ZIM nach der Wiederöffnung, und für bahnbrechende, marktnahe Vorhaben der EIC Accelerator.

Um Einführung geht es, wenn erprobte Technik in den eigenen Betrieb kommt, zum Beispiel eine Suche über eigene Dokumente oder die Automatisierung eines Prozesses. Hier passen der ERP-Förderkredit Digitalisierung, in Rheinland-Pfalz IBI-EFRE und in Nordrhein-Westfalen MID-Digitalisierung, wenn daraus ein digitales Produkt entsteht. Offene Aufrufe der Kaskadenförderung können kleine Pilotprojekte tragen.

Beratung steht am Anfang, wenn noch offen ist, ob ein Anwendungsfall trägt. Kostenlos sind die Mittelstand-Digital Zentren und die EDIH, bezuschusst wird externe Beratung in Rheinland-Pfalz über das Betriebsberatungsprogramm. Für IT-Sicherheit rund um ein KI-Projekt gibt es in Nordrhein-Westfalen MID-Digitale Sicherheit.

Dieser Beitrag ist eine allgemeine Information und keine Rechts- oder Steuerberatung, und Förderbedingungen ändern sich.

Ein KI-Vorhaben sollte fachlich eingegrenzt sein, bevor die Förderfrage gestellt wird, mehr dazu unter KI-Readiness.

Was die Slush ist

Die Slush ist eine Konferenz für Start-ups und Investoren in Helsinki, die 2008 als Treffen von 250 Menschen begann. Sie ist nicht gewinnorientiert, gehört der finnischen Startup Foundation und wird von Studierenden und jungen Absolventen mit einem großen Team von Freiwilligen organisiert.

Die Veranstaltung findet am 18. und 19. November 2026 im Helsinki Expo and Convention Centre (Messukeskus) statt, am 17. November gibt es ein Day-0-Programm. Nach Angaben des Veranstalters kommen über 12.000 Teilnehmende, rund drei Viertel davon Start-ups oder Investoren. Im Mittelpunkt stehen ausgewählte europäische Start-ups, internationale Investoren und Tech-Medien, und die DACH-Region nennt die Slush ausdrücklich als Kernregion. Programm und Details stehen auf der offiziellen Website der Slush.

Was iiterate mitbringt

iiterate bringt nach Helsinki die Arbeit mit, die wir auch sonst machen: KI für Umgebungen, in denen Daten das Unternehmen nicht verlassen sollen. Wir sind eine KI-Beratung aus Adenau in Rheinland-Pfalz und reisen als Teil der deutschen Delegation. Unsere Schwerpunkte:

• On-Premise-LLM. Sprachmodelle, die in der eigenen Infrastruktur laufen.
• RAG und Wissensmanagement. Retrieval-Systeme, die Antworten aus den Dokumenten eines Unternehmens ableiten und die Quellen nennen.
• KI mit Datenhaltung in der EU. Architekturen, bei denen Verarbeitung und Speicherung in der Europäischen Union bleiben.
• Computational Design. Parametrische Modelle und Konfiguratoren, in denen Regeln die Geometrie erzeugen.

In Gesprächen geht es uns um konkrete Fragen: welche Daten ein Vorhaben berührt, wo die Verarbeitung stattfinden darf und welche Architektur daraus folgt.

Wer mit uns sprechen sollte

Mit uns sprechen sollten vor allem Investoren, Unternehmen sowie Gründerinnen und Gründer, die mit KI und sensiblen Daten zu tun haben.

• Investorinnen und Investoren, die KI-Vorhaben in regulierten oder datensensiblen Branchen bewerten.
• Unternehmen, die KI auf vertraulichen Dokumenten einsetzen wollen und dafür Datenhaltung in der EU oder im eigenen Haus brauchen.
• Gründerinnen und Gründer, die an KI mit sensiblen Daten arbeiten und über Architektur, Betrieb oder Zusammenarbeit sprechen möchten.

Ein Vorhaben, das noch nicht fertig durchdacht ist, ist dabei kein Hindernis, sondern ein guter Ausgangspunkt für ein Gespräch.

Ein Treffen in Helsinki vereinbaren

Ein Treffen in Helsinki vereinbaren Sie am besten vorab über unsere Kontaktseite. Nennen Sie dabei kurz Ihr Thema und die Tage, an denen Sie vor Ort sind. Gespräche sind auf Deutsch oder Englisch möglich.

Die Spezifikation, ohne Marketing

Bevor über Konsequenzen zu reden ist, hilft die nüchterne Tabelle. Alle Werte stammen aus der Modellübersicht und der Preisseite von Anthropic, abgerufen am 10. September 2026.

Bemerkenswert ist, was Anthropic in der eigenen Modellübersicht dazuschreibt: Claude Opus 5 wird als Standard für die meisten Arbeitslasten empfohlen, Fable 5.1 ist für Fälle gedacht, in denen Opus 5 auf höherer Effort-Stufe nicht ausreicht. Das ist eine ungewöhnlich klare Selbstbeschränkung und zugleich der erste Filter für jede Architekturentscheidung. Fable 5.1 ist kein pauschales Upgrade, sondern ein Werkzeug für lange, zusammenhängende Aufgaben.

Die Modalität ist eng, und das ist praktisch relevant. Text und Bilder gehen hinein, Text kommt heraus. Kein Ton hinein, kein Ton hinaus, keine Bild- oder Videoerzeugung. Wer ein Telefonprotokoll auswerten will, braucht davor eine Transkription. Wer gesprochene Antworten braucht, braucht dahinter eine Sprachsynthese. Wer Grafiken erzeugen will, braucht ein anderes Modell. Das klingt banal, verschiebt aber Systemgrenzen, Kosten und Datenschutzfragen an genau die Stellen, an denen diese zusätzlichen Komponenten stehen.

Was eine Million Token ändert, und was nicht

Das Fenster wird über die gesamte Länge zu den normalen Token-Preisen abgerechnet, einen Aufschlag für lange Kontexte gibt es nicht (Anthropic). Damit werden Aufbauten möglich, die vorher nicht am Modell scheiterten, sondern an der Zerlegung: ein vollständiger Vertrags- oder Ausschreibungsbestand in einem Durchgang statt in dreißig Häppchen mit anschließendem Zusammenführen; eine komplette Agentenspur samt aller Werkzeugausgaben, die noch analysierbar ist, statt nach zwanzig Schritten abgeschnitten zu werden; ein mittelgroßes Repository, über das eine Frage in einem Zug beantwortet wird, statt über eine Suche, die vorher raten muss, welche Dateien relevant sind. Der Gewinn liegt weniger in der Intelligenz als im Wegfall einer ganzen Klasse von Klebearbeit, und diese Klebearbeit war in unseren Projekten regelmäßig die Quelle der schwer auffindbaren Fehler.

Die Zahl ist allerdings keine Seitenzahl. Anthropic beziffert 1.000.000 Token mit rund 555.000 englischen Wörtern auf dem aktuellen Tokenizer und weist im selben Atemzug darauf hin, dass dieser Tokenizer für denselben Text rund 30 Prozent mehr Token erzeugt als der vorherige (Anthropic). Die Angabe bezieht sich auf englischen Text; für einen deutschsprachigen Bestand lässt sich daraus keine Zahl ableiten, sie muss gemessen werden. Wer Kapazität plant, zählt seine eigenen Dokumente mit dem Tokenizer des Modells, das er tatsächlich einsetzt, und rechnet nicht in Seiten.

Aus demselben Grund ist der Vergleich von Fenstergrößen zwischen Anbietern ohne Aussagekraft. Ein Token ist eine anbieterspezifische Einheit, und es existiert keine veröffentlichte Umrechnung, die zwei Tokenizer auf dieselbe Textmenge abbildet. Eine Zahl auf einem Datenblatt sagt daher nichts darüber, welches Modell mehr von Ihrem Text hält.

Und das größere Fenster macht Retrieval nicht überflüssig. Die Überlegung dahinter ist schlicht: Alles, was im Fenster steht, wird bei jedem Aufruf mitbezahlt und muss bei jedem Aufruf verarbeitet werden. Ein Verfahren, das die zwanzig einschlägigen Absätze findet, bleibt schneller, günstiger und in der Regel präziser als eines, das zehntausend Absätze hineinlegt und auf Aufmerksamkeit hofft. Das große Fenster verschiebt die Grenze, ab der Zerlegung nötig wird, deutlich nach oben. Es ersetzt nicht die Frage, welche Information für diese eine Antwort gebraucht wird.

Die eigentliche Ingenieursgeschichte heißt Cache-Lesen

Die interessanteste Zahl der Spezifikation ist kein Absolutwert, sondern ein Verhältnis. Frischer Input kostet 10 US-Dollar je Million Token, ein Cache-Treffer 0,25 US-Dollar. Das Schreiben in den Cache kostet 12,50 US-Dollar je Million Token in der Fünf-Minuten-Stufe und 20 US-Dollar in der Ein-Stunden-Stufe. Auf Fable 5.1 und Mythos 5.1 liegt der Lesepreis beim 0,025-fachen des Basispreises, gegenüber dem 0,1-fachen bei allen anderen Claude-Modellen, und das ist laut Anthropic die einzige Preisänderung gegenüber Fable 5 (Anthropic).

Der Faktor 40 zwischen frischem Input und Cache-Treffer ist das, was über Entwürfe entscheidet. In einer Agentenschleife werden derselbe System-Prompt, dieselben Werkzeugdefinitionen und derselbe Projektkontext bei jedem einzelnen Schritt erneut gelesen. Eine Aufgabe über zweihundert Werkzeugaufrufe liest denselben Vorspann zweihundertmal. Ob dieser Vorspann jedes Mal als frischer Input abgerechnet wird oder als Cache-Treffer, ist kein Detail der Abrechnung, sondern die Grenze zwischen einem Entwurf, den man in Produktion nehmen kann, und einem, den man in der Demo lässt.

Genau deshalb ist Anthropics eigene Formulierung, typische Arbeitslasten seien etwa 25 Prozent günstiger und stark agentische bis etwa 45 Prozent, eine Schätzung über Cache-Trefferquoten und keine Preissenkung (Anthropic). Die Kopfpreise für Eingabe und Ausgabe sind gegenüber Fable 5 unverändert. Eine Arbeitslast mit schlechter Cache-Lokalität sieht von dieser Ersparnis nahezu nichts, und wer die 25 Prozent ohne diesen Zusatz in ein Budget schreibt, hat kein Budget, sondern eine Hoffnung.

Was Trefferquoten in der Praxis gut oder schlecht macht, ist keine Messgröße aus der Dokumentation, sondern Ingenieurslogik, und sie lässt sich benennen:

• Ein stabiler Präfix. Wiederverwendet wird der unveränderte Anfang der Anfrage. Alles Konstante gehört nach vorn, alles Variable nach hinten. Ein Zeitstempel, eine Sitzungs-ID oder ein Nutzername an der falschen Stelle entwertet den gesamten nachfolgenden Kontext.
• Deterministischer Aufbau. Werkzeuglisten in zufälliger Reihenfolge, Retrieval-Treffer in wechselnder Sortierung oder Objekte mit instabiler Schlüsselreihenfolge erzeugen bei jedem Lauf einen neuen Präfix. Der Cache sieht dann nie zweimal dasselbe.
• Die Lebensdauer gegen den Rhythmus der Aufgabe. Fünf Minuten passen zu einer eng getakteten Agentenschleife. Sie passen nicht zu einem Dialog, in dem eine Person zwischen zwei Fragen zwanzig Minuten in einer Besprechung sitzt. Die Ein-Stunden-Stufe kostet mehr im Schreiben und lohnt sich erst, wenn sie den Treffer tatsächlich rettet.
• Genügend Wiederholung je Präfix. Viele kurze, untereinander unverwandte Anfragen verteilen sich auf viele Präfixe. Jeder zahlt einen Schreibvorgang und erlebt selten einen Treffer. Das ist der Fall, in dem die Cache-Ökonomie gegen Sie arbeitet, und dann ist die Batch-Schnittstelle mit 50 Prozent Nachlass in beide Richtungen oft der bessere Weg.

Ein konkreter Anhaltspunkt aus der Preisliste stützt denselben Punkt: Der Werkzeugsatz für Computernutzung schlägt mit rund 4.500 Eingabe-Token je Anfrage zu Buche, der für Browsernutzung mit rund 6.600 (Anthropic). Das ist ein konstanter Block, der bei jedem Schritt erneut anfällt, und damit exakt das Material, das in einen stabilen Präfix gehört.

Agentenbetrieb, Werkzeuge und die Frage nach der Effort-Stufe

Fable 5.1 ist auf lange Läufe ausgelegt. Anthropic führt als Beleg einen unbeaufsichtigten Lauf von 38 Stunden an einem Machine-Learning-Problem an (Anthropic). Das ist eine Anbieterangabe zu einem einzelnen Lauf und kein Verteilungsergebnis, taugt aber als Größenordnung dafür, worauf das Modell hin entworfen wurde.

Der Denkmodus ist adaptiv und dauerhaft aktiv; der frühere manuelle Modus mit ausdrücklichem Denkbudget wird nicht mehr angenommen. Gegenüber Fable 5 gibt es drei brechende Änderungen, die jede bestehende Integration betreffen: erzwungene Werkzeugnutzung führt zu einem Fehler, ältere Modelle können die Denkblöcke dieses Modells nicht lesen, und das nachträgliche Bearbeiten früherer Züge entwertet die Denkblöcke. Additiv kommen unter anderem eine Effort-Angabe je Nachricht, zugweise gültige Systemnachrichten, lesbare Fortschrittsmeldungen zwischen Werkzeugaufrufen sowie der niedrigere Cache-Lesepreis hinzu; mehrere davon sind als Beta gekennzeichnet (Anthropic). Für die Planung heißt das: Ein Wechsel auf dieses Modell ist keine Konfigurationsänderung, sondern ein kleiner Umbau mit anschließendem Test.

Bei den Effort-Stufen ist Sorgfalt geboten. Die Dokumentation nennt high als Standard (Anthropic), und die Ankündigung präzisiert, dass die Voreinstellung je Oberfläche verschieden ist: high in Claude Code, medium in Claude Cowork und auf claude.ai (Anthropic). Der vollständige Satz akzeptierter Werte ist in den von uns eingesehenen Dokumentationsseiten nicht aufgeführt, und wir behaupten ihn deshalb nicht.

Die praktische Folge ist unbequem, aber wichtig: Eine Benchmark-Zahl oder eine Kostenschätzung ohne angegebene Effort-Stufe ist nicht reproduzierbar. Zwei Teams, die dasselbe Modell über zwei verschiedene Oberflächen messen, messen unterschiedliche Konfigurationen. Wer Angebote, Testergebnisse oder interne Vergleiche belastbar halten will, notiert die Stufe zusammen mit der Zahl, so wie man eine Messung ohne Einheit auch nicht durchgehen lässt.

Wissensstand Juni 2026 ist eine Architekturanforderung

Der Wissens- und Trainingsdatenstand liegt bei Juni 2026 (Anthropic). Operativ bedeutet das wenig Dramatisches und zugleich eine ganze Menge. Ihre Preisliste von letzter Woche, die Entscheidung von gestern, der Stand Ihres Auftragsbuchs von heute Morgen: nichts davon steht im Modell. Es muss über Retrieval, über eine Werkzeuganbindung oder über den Prompt in den Kontext gelangen.

Das ist kein Mangel des Modells, sondern eine Anforderung an die Architektur, und sie ist unabhängig vom Anbieter. Jedes System, das Auskunft über aktuelle Sachverhalte geben soll und keinen definierten Weg hat, auf dem diese Sachverhalte hereinkommen, ist falsch spezifiziert, egal wie gut das Modell ist. Zwei Konsequenzen daraus haben sich bei uns bewährt. Erstens gehört zu jeder Antwort, die auf Fakten beruht, eine benennbare Quelle im Kontext, nicht das Modellgedächtnis. Zweitens gehören in jeden Evaluationssatz einige Fragen, deren richtige Antwort sich nach dem Wissensstand geändert hat: Sie prüfen genau den Pfad, der in der Produktion am ehesten stillschweigend bricht.

Das Wasserzeichen nach Artikel 50 ist kein Prüfpfad

Fable 5.1 und Mythos 5.1 tragen ab dem Start ein unsichtbares Textwasserzeichen (Anthropic). Anthropic wendet die Kennzeichnung weltweit an und nicht nur in der EU (Euronews). Hintergrund sind die Transparenzpflichten aus Artikel 50 der KI-Verordnung, die seit dem 2. August 2026 gelten und eine maschinenlesbare Kennzeichnung synthetischer Inhalte verlangen.

Entscheidend ist der Zusatz, den Anthropic selbst macht. Ein erkanntes Wasserzeichen zeigt an, dass ein Inhalt möglicherweise von Claude verarbeitet wurde, ist ausdrücklich nicht abschließend beweiskräftig und bestätigt für sich genommen nicht die Herkunft des Inhalts (Anthropic Help Center). Hinzu kommt, dass die Erkennungsschnittstelle in einer geschlossenen Vorschau nur einem eingeschränkten Kreis offensteht (MacRumors).

Für ein Unternehmen, das den eigenen KI-Einsatz dokumentieren will, ergibt sich daraus eine nüchterne Konstruktionsvorgabe, und das ist eine technische Einschätzung, keine Rechtsberatung: Das Wasserzeichen ist ein Signal in der Ausgabe, das Ihnen nicht gehört, das Sie in der Regel nicht selbst auslesen können und dessen Aussagekraft der Anbieter selbst begrenzt. Es ist damit kein Prüfpfad. Wenn nachvollziehbar sein soll, welches Modell wann mit welcher Eingabe welche Ausgabe erzeugt hat und wer sie freigegeben hat, entsteht dieser Nachweis in Ihren eigenen Aufzeichnungen. Technisch ist das unspektakulär, weil es ohnehin dieselben Protokolle sind, die man für Fehlersuche und Kostenkontrolle führt.

Die Randbedingung, die in Deutschland die Architektur entscheidet

In deutschen Projekten entscheidet über den Einsatz eines Modells häufiger die Datenhaltung als die Fähigkeit. Hier ist die Lage eindeutig dokumentiert und für viele überraschend. Fable 5.1 ist bei Anthropic als Covered Model eingestuft. Diese Modelle setzen eine 30-tägige Datenaufbewahrung voraus und stehen nicht unter Zero Data Retention zur Verfügung, sofern Anthropic dies nicht ausdrücklich genehmigt. Eine Organisation, die auf Zero Data Retention läuft, muss die Aufbewahrung für einen bestimmten Workspace aktiv einschalten, sonst werden Anfragen mit einem Fehler abgewiesen (Anthropic).

Zwei Ergänzungen aus derselben Quelle gehören dazu, weil sie das Bild sonst schief werden lassen. Aufbewahrte Daten werden nach Anthropics Angabe ohne ausdrückliche Erlaubnis nicht für das Modelltraining verwendet. Und auch unter Zero Data Retention können als auffällig markierte Inhalte bis zu zwei Jahre aufbewahrt werden. Zero Data Retention gilt zudem nicht für alle Wege in das System, unter anderem nicht für die Batch-Schnittstelle und die Dateiablage.

Dazu kommt die Regionsfrage. Auf der erstanbieterseitigen Schnittstelle gibt es keine EU-Inferenzregion. Der Parameter für die Inferenzregion akzeptiert genau zwei Werte, global und us, und die Speicherung erfolgt ausschließlich in den USA; die Region eines Workspace ist nach dem Anlegen nicht mehr änderbar (Anthropic). Der praktikable Weg innerhalb der EU führt über eine Partner-Cloud: Amazon Bedrock und Google Cloud bieten regionale Endpunkte mit garantierter Datenführung, zu einem Aufschlag von 10 Prozent gegenüber den globalen Endpunkten, und setzen eigene Lebenszyklusdaten (Anthropic).

Das ist eine Konstruktionsvorgabe und kein Urteil über das Modell. Praktisch bleiben drei Wege, und die Wahl fällt vor dem ersten Prototyp, nicht danach. Erstens: regionaler Endpunkt bei einer Partner-Cloud, mit dem Aufschlag und mit dem Cloud-Anbieter als Verarbeiter. Zweitens: erstanbieterseitige Schnittstelle mit bewusst aktivierter Aufbewahrung, für Datenklassen, bei denen das vertretbar ist. Drittens: Die betreffende Datenklasse erreicht dieses Modell gar nicht, weil ein anderes Modell oder ein lokaler Betrieb den Teil übernimmt, der die sensiblen Felder sieht. Der dritte Weg wird zu selten geprüft, obwohl er in Wissens- und Dokumentensystemen oft der sauberste ist.

Was sich ändert, und was dieses Modell nicht anfasst

Ehrlich benannt ändert sich eine überschaubare, aber wertvolle Menge an Aufgabenklassen. Analysen über Bestände, die bisher an der Zerlegung scheiterten, werden in einem Durchgang machbar. Agentenläufe, die vorher an der Kontextgrenze zerfielen, bleiben zusammenhängend. Und Entwürfe, die dieselbe Grundlage sehr oft erneut lesen müssen, werden durch den Cache-Lesepreis wirtschaftlich, wenn der Aufbau die Trefferquote hergibt. Das sind drei echte Verschiebungen, und sie betreffen genau die Arbeit, die in einer Beratung sonst als Fleißarbeit anfällt.

Ebenso ehrlich benannt ist, was unverändert bleibt. Auch die Fähigkeiten des Modells sind begrenzt: Penetrationstests, Exploit-Erzeugung, binärbasiertes Scannen und Aufgaben aus der Biologieforschung werden auf die Opus-Modelle verwiesen, und der schnelle Modus steht auf Fable 5.1 nicht zur Verfügung (Anthropic, Anthropic).

Wichtiger sind aber die Probleme, an die kein Modell rührt. Datenqualität bleibt Ihre Aufgabe: Ein größeres Fenster liest widersprüchliche Stammdaten nur gründlicher. Die Prozessdefinition bleibt Ihre Aufgabe: Ein Agent, der nicht weiß, wann eine Sache entschieden ist, bildet nur die Unklarheit ab, die vorher im Team lag. Berechtigungen bleiben Ihre Aufgabe: Ein Modell, das alles sehen darf, ist ein Datenschutzproblem mit guter Sprachbegabung. Evaluation bleibt Ihre Aufgabe, weil ohne einen Satz von Fällen mit bekannter richtiger Antwort niemand sagen kann, ob ein Wechsel etwas verbessert hat. Und die Kosten des Irrtums bleiben, wo sie waren: Bei einer Vorschlagsliste ist ein Fehler ärgerlich, bei einer ausgehenden Rechnung ist er teuer. Diese Unterscheidung entscheidet über den Grad der Automatisierung, und sie ist eine Geschäftsfrage.

Unsere Position dazu ist unaufgeregt: Fable 5.1 verschiebt die Grenze dessen, was ein Aufbau tragen kann, und verschiebt sie an einer Stelle, die in der Praxis wirklich gebremst hat. Es verschiebt keine einzige der Fragen, die davor beantwortet sein müssen. Welche dieser Fragen ist in Ihrem nächsten Vorhaben noch offen?

Dieser Beitrag liest die Veröffentlichung so, wie sie ein Haus lesen sollte, das gerade entscheidet, ob es darauf baut: welche Spezifikationen wirklich zählen, was an der Preisstruktur echt ist und was eine modellierte Schätzung, was sich an der Schnittstelle bricht, und warum der europäische Weg zu diesem Modell über eine Partner-Cloud führt und nicht über Anthropic selbst.

Was am 1. September tatsächlich veröffentlicht wurde

Anthropic hat Claude Fable 5.1 am 1. September 2026 veröffentlicht, gemeinsam mit Claude Mythos 5.1. Nach Anthropics eigener Darstellung sind beide dasselbe Modell mit unterschiedlichen Schutzstufen: Fable 5.1 ist allgemein verfügbar, Mythos 5.1 nur auf Einladung über Programme für vertrauenswürdigen Zugang. Die Fachpresse bestätigt den Termin und die Verfügbarkeit auf allen Plattformen ab dem Erscheinungstag.

Die Modell-ID lautet claude-fable-5-1, auf Amazon Bedrock anthropic.claude-fable-5-1. Ausgeliefert wird das Modell über die Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry und die Claude Platform auf AWS. Als Oberflächen nennt Anthropic Claude Code, Claude Enterprise und die Claude Platform, mit unterschiedlichen Voreinstellungen für die Anstrengungsstufe: high in Claude Code, medium in Claude Cowork und auf claude.ai. Für die Abkündigung gilt eine Zusage: Auf den von Anthropic betriebenen Plattformen wird das Modell nicht vor dem 1. September 2027 abgeschaltet, während Bedrock und Google Cloud eigene Termine setzen.

Bemerkenswert ist, was Anthropic in derselben Dokumentation dazuschreibt. Fable 5.1 sei für anspruchsvolles Schlussfolgern und langlaufende Agentenarbeit gedacht; als Standard für die meisten Arbeitslasten empfiehlt Anthropic weiterhin ausdrücklich Claude Opus 5, und Fable 5.1 erst dort, wo Opus 5 auf hoher Anstrengungsstufe nicht ausreicht. Wer den Wechsel intern begründen muss, sollte diesen Satz kennen: Der Hersteller selbst rät nicht pauschal zum neuen Flaggschiff.

Die Spezifikationen, die eine Entscheidung tragen

Die Eckdaten stehen in Anthropics Modelldokumentation und sind für eine Architekturentscheidung wichtiger als jede Rangliste.

Zwei Punkte daraus verdienen mehr als eine Tabellenzeile. Erstens der Denkmodus: Fable 5.1 denkt adaptiv und dauerhaft, der ältere manuelle Modus mit thinking.type: enabled und budget_tokens wird nicht mehr angenommen. Wer eine bestehende Integration portiert, muss diese Stelle anfassen.

Zweitens das Kontextfenster. Eine Million Token entsprechen laut Anthropic ungefähr 555.000 englischen Wörtern, gemessen am aktuellen Tokenizer, der mit Claude Opus 4.7 eingeführt wurde. Derselbe Tokenizer erzeugt für denselben Text rund 30 Prozent mehr Token als der vorherige. Eine Zahl im Kontextfenster ist damit keine Kapazitätsangabe, die man zwischen Modellgenerationen oder gar zwischen Anbietern einfach vergleichen könnte. Für die Budgetplanung zählt, wie viele Token Ihr eigener Textbestand tatsächlich erzeugt, nicht die Schlagzeile.

Zu den Leistungswerten hält sich dieser Beitrag bewusst kurz, weil das Gegenstand eines eigenen Vergleichsbeitrags ist. Nur so viel, und ausdrücklich als Herstellerangabe: Anthropic berichtet für Fable 5.1 52,6 Prozent auf Terminal-Bench-Science 0.1 gegenüber 24,7 Prozent für Fable 5, sowie 55,8 Prozent auf Terminal-Bench 4.0 gegenüber 42,0 Prozent. Die Vergleichsspalte in Anthropics eigener Tabelle ist GPT-5.6 Sol. Das aktuelle OpenAI-Flaggschiff GPT-6 Astra erschien zwei Tage nach dieser Veröffentlichung und kommt in Anthropics Zahlen nicht vor.

Der Preis: eine einzige Zeile hat sich geändert

Anthropics Preisdokumentation nennt für Fable 5.1 die folgenden Werte, jeweils in US-Dollar je Million Token.

Interessant ist genau eine Zeile. Cache-Lesevorgänge kosten bei Fable 5.1 und Mythos 5.1 das 0,025-fache des Eingabepreises, während bei jedem anderen Claude-Modell der Faktor 0,1 gilt. Das ist die einzige Preisänderung gegenüber Fable 5, dessen Cache-Lesevorgang bei 1,00 US-Dollar je Million Token lag. Eingabe und Ausgabe sind unverändert. Das volle Kontextfenster wird zu den normalen Token-Preisen abgerechnet, einen Aufschlag für lange Kontexte gibt es nicht.

Anthropic beziffert die Ersparnis mit ungefähr 25 Prozent gegenüber Fable 5 für typische Arbeitslasten und mit bis zu ungefähr 45 Prozent für stark agentische Arbeit. Diese Zahl ist wichtig genug, um sie richtig zu lesen: Es ist eine modellierte Schätzung des Herstellers, die vollständig aus der Cache-Zeile stammt, und keine Preissenkung. Wer Anfragen stellt, die selten denselben Kontext erneut lesen, spart nichts. Wer eine Agentenschleife betreibt, die denselben Systemprompt, dieselbe Codebasis und dieselben Werkzeugdefinitionen hundertfach wieder einliest, spart erheblich. Der Unterschied zwischen beiden Fällen ist Ihre Cache-Trefferquote, und die kennt nur Ihr eigenes Lastprofil.

Ein Detail für die Kostenrechnung kommt hinzu: Wird die Inferenz per inference_geo: "us" auf die Vereinigten Staaten festgelegt, gilt ein Faktor von 1,1 auf Eingabe, Ausgabe, Cache-Schreiben und Cache-Lesen.

Im Wettbewerbsumfeld ist diese Cache-Zeile der einzige echte Preisunterschied an der Spitze. OpenAI führt für gpt-6-astra ebenfalls 10 und 50 US-Dollar je Million Token für Eingabe und Ausgabe, für zwischengespeicherte Eingaben jedoch 1,00 US-Dollar. Bei Cache-Lesevorgängen liegt Fable 5.1 damit bei einem Viertel des Preises, was in langen Agentenschleifen den Ausschlag geben kann. Alles Weitere zu diesem Vergleich, samt der Frage, welche Benchmark-Zahlen überhaupt vergleichbar sind, steht im gesonderten Beitrag.

Was sich an der Schnittstelle ändert, und was dabei bricht

Als Beleg für langlaufende Autonomie nennt Anthropic einen unbeaufsichtigten Lauf von 38 Stunden an einem Machine-Learning-Problem. Wer darauf aufbauen möchte, sollte allerdings zuerst die Liste der Schnittstellenänderungen lesen, denn drei davon brechen bestehenden Code.

Brechende Änderungen gegenüber Fable 5:

• Erzwungene Werkzeugnutzung gibt einen Fehler zurück.
• Frühere Modelle können die Denkblöcke von Fable 5.1 nicht lesen.
• Das Bearbeiten früherer Gesprächsrunden macht Denkblöcke ungültig.

Ergänzungen:

• Anstrengungsstufe je Nachricht (Beta).
• Systemnachrichten mit Gültigkeit für eine einzelne Runde (Beta).
• Lesbare Fortschrittsmeldungen zwischen Werkzeugaufrufen über display: "updates" (Beta).
• Der reduzierte Preis für Cache-Lesevorgänge.
• Herkunftskennzeichnung der erzeugten Inhalte.

Für Agentenarchitekturen relevant ist außerdem der Token-Aufschlag der Werkzeugsätze: computer_toolset_20260801 fügt je Anfrage etwa 4.500 Eingabe-Token hinzu, browser_toolset_20260801 etwa 6.600. Das ist eine Grundlast, die bei jeder einzelnen Anfrage anfällt, und sie gehört in jede Kostenschätzung. Der Fast Mode, der bei Claude Opus 5 und Opus 4.8 als Forschungsvorschau existiert, steht für Fable 5.1 nicht zur Verfügung.

Auf der Sicherheitsseite berichtet Anthropic, die Schutzmechanismen im Bereich Cybersicherheit lösten 60 Prozent weniger Fehlalarme aus als zuvor, und die Biologie-Schutzmechanismen griffen bei harmlosen Anfragen zu elementarer Biologie 85 Prozent seltener. Zugleich bleiben ganze Aufgabenklassen ausgeschlossen: Penetrationstests, Exploit-Erzeugung, binärbasiertes Scannen und Aufgaben aus der Biologieforschung werden auf Opus-Modelle umgeleitet. Fable 5.1 kann Schwachstellen in Software identifizieren, die Erzeugung von Exploits bleibt gesperrt. Neue API-Konten können außerdem den vorangegangenen Kontext in mehrstufigen Gesprächen nicht mehr manuell bearbeiten; Anthropic begründet das damit, dass dies eine verbreitete, öffentlich dokumentierte Destillationstechnik schließe. Für Teams, die Gesprächsverläufe programmatisch umschreiben, ist das eine Verhaltensänderung mit direkter Auswirkung auf bestehende Architekturen.

Datenresidenz: bei Anthropic selbst gibt es keine EU-Region

An dieser Stelle trennt sich die Ingenieursgeschichte von der Governance-Geschichte. Anthropics Dokumentation zur Datenresidenz ist unmissverständlich: Der Parameter inference_geo akzeptiert genau zwei Werte, global und us. Unter den aktuellen Einschränkungen steht wörtlich, dass nur diese beiden verfügbar sind. Eine EU-Inferenzregion gibt es auf der First-Party-API von Anthropic nicht.

Für ruhende Daten gilt dasselbe. Die Region eines Workspace wird bei dessen Erstellung festgelegt, lässt sich danach nicht mehr ändern, und der einzige verfügbare Wert ist die USA.

Zwei Anthropic-Quellen scheinen sich hier zu widersprechen, und das gehört offengelegt. Das Datenschutz-Hilfecenter, zuletzt aktualisiert am 15. Juni 2026, schreibt, Kundenverkehr könne standardmäßig in ausgewählte Länder in den USA, Europa, Asien und Australien geleitet werden, und ergänzt im selben Text, dass die Daten in den USA gespeichert werden. Die Plattformdokumentation kennt dagegen nur die beiden genannten Inferenzregionen. Die Auflösung liegt in der Unterscheidung zwischen Routing und Residenz: Der Modus global kann Europa berühren, er ist aber keine wählbare Zusicherung, dass Verarbeitung und Speicherung in der EU stattfinden. Wer eine solche Zusicherung braucht, findet sie an dieser Stelle nicht.

Der Parameter inference_geo existiert zudem erst ab Claude 4.6; ältere Modelle antworten mit einem Fehler 400. Auf Amazon Bedrock und Google Cloud gibt es ihn nicht, dort bestimmen Endpunkt beziehungsweise Inferenzprofil die Region. Microsoft Foundry bietet stattdessen einen Bereitstellungstyp mit US-Datenzone an. Über den OpenAI-kompatiblen Endpunkt steht der Parameter ebenfalls nicht zur Verfügung.

Der praktikable EU-Weg führt deshalb nicht über Anthropic, sondern über eine Partner-Cloud. Bedrock und Google Cloud bieten regionale Endpunkte mit garantiertem Datenrouting, nach Anthropics Preisdokumentation mit einem Aufschlag von 10 Prozent gegenüber den globalen Endpunkten, und sie setzen eigene Lebenszyklustermine. Damit ist auch der verbreitete Satz, Claude habe EU-Datenresidenz, weil es in Frankfurt laufe, halb richtig und im Ergebnis irreführend: Claude-Modelle können in EU-Regionen laufen, dort ist aber der Cloud-Anbieter der Auftragsverarbeiter und nicht Anthropic. Für die vertragliche Konstruktion ist genau das der Unterschied.

Covered Model: 30 Tage Aufbewahrung sind Bedingung, nicht Option

Der unbequemste Satz der gesamten Dokumentation steht in Anthropics Seite zu API- und Datenaufbewahrung. Dort heißt es zu Claude Fable 5.1, Mythos 5.1, Fable 5 und Mythos 5, diese Modelle erforderten eine 30-tägige Datenaufbewahrung und seien nicht unter Zero Data Retention verfügbar, sofern Anthropic dies nicht ausdrücklich genehmigt. Sie sind als Covered Models eingestuft.

Praktisch heißt das: Eine Organisation, die heute unter Zero Data Retention arbeitet, kann Fable 5.1 nicht einfach hinzuschalten. Sie muss für einen bestimmten Workspace ausdrücklich die 30-tägige Aufbewahrung aktivieren, sonst antwortet die API mit 400 invalid_request_error. Das ist keine Konfigurationsfeinheit, sondern eine Entscheidung, die in vielen Häusern durch die Datenschutzfreigabe muss, bevor die erste Zeile Integrationscode entsteht.

Der Vollständigkeit halber gehören Anthropics Zusagen daneben: Aufbewahrte Daten werden nach eigener Aussage niemals ohne ausdrückliche Erlaubnis für das Modelltraining verwendet, und Gesprächsinhalte werden außerhalb der Covered-Model-Ausnahme standardmäßig nicht aufbewahrt.

Auch wer Zero Data Retention bereits eingerichtet hat, sollte deren Grenzen kennen, denn sie sind enger, als der Name vermuten lässt.

• ZDR wird je Organisation auf Anfrage über den Vertrieb freigeschaltet und überträgt sich nicht automatisch auf Schwesterorganisationen unter demselben Konto.
• Nicht abgedeckt sind die Batch API, die Files API, die Codeausführung, Claude for Excel sowie die Produktoberflächen von Claude Teams und Claude Enterprise. Claude Code über Claude Enterprise mit ZDR ist die genannte Ausnahme.
• CORS wird für ZDR-Organisationen nicht unterstützt.
• Wird ein Chat oder eine Sitzung markiert, kann Anthropic Ein- und Ausgaben bis zu zwei Jahre aufbewahren, auch unter ZDR.

Die Richtung ist damit eindeutig, und sie läuft der Preisgeschichte entgegen. Fable 5.1 ist im Agentenbetrieb günstiger als jedes andere Claude-Modell, und unter strengen EU-Datenregeln zugleich schwerer einzusetzen als die Claude-Modelle, die nicht auf dieser Liste stehen.

Artikel 50: Wasserzeichen ab dem ersten Tag, mit Anthropics eigenem Vorbehalt

Fable 5.1 und Mythos 5.1 tragen nach Anthropics Angaben ab dem Erscheinungstag ein unsichtbares Textwasserzeichen. Artikel 50 des EU-KI-Gesetzes, der die maschinenlesbare Kennzeichnung synthetischer Inhalte verlangt, gilt seit dem 2. August 2026. Anthropic wendet die Markierung weltweit an und nicht nur in der EU.

Wer das Wasserzeichen in einen Prüfprozess einbauen möchte, sollte Anthropics eigenen Vorbehalt kennen, und der steht deutlich im Hilfecenter: Ein erkanntes Wasserzeichen zeige an, dass ein Inhalt möglicherweise von Claude verarbeitet wurde, es sei "not fully conclusive" und bestätige für sich genommen nicht die vollständige Herkunft des Inhalts. Ein Beweis im juristischen Sinne ist es also nicht, und die Erwartung, damit Urheberschaft feststellen zu können, geht über das hinaus, was der Hersteller selbst behauptet. Das ist eine bemerkenswerte Konstellation: Die Kennzeichnung ist ein echtes Merkmal des Modells, und ihre Aussagekraft wird von demselben Unternehmen relativiert, das sie anbietet.

Dazu kommt der Zugang. Die Erkennungs-API befindet sich in einer privaten Vorschau und steht nur berechtigten Organisationen offen; genannt werden Regulierungsbehörden, Strafverfolgung, Medien, Faktenprüfer, Forschung, Bildungseinrichtungen und zivilgesellschaftliche Organisationen in der EU. Ein Unternehmen, das eingehende Texte selbst auf diese Markierung prüfen möchte, kann das über diesen Weg gegenwärtig nicht.

Der regulatorische Rahmen drumherum, so wie ihn die veröffentlichenden Stellen beschreiben: Die Durchsetzung für Allzweck-KI-Modelle läuft ebenfalls seit dem 2. August 2026, mit Bußgeldern von bis zu 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes für nicht konforme Anbieter solcher Modelle, unabhängig davon, ob sie den Verhaltenskodex unterzeichnet haben. Der Verhaltenskodex der Europäischen Kommission verpflichtet Unterzeichner auf ein veröffentlichtes Transparenzformular, eine Methodik zur Bewertung systemischer Risiken und einen Rahmen für Urheberrechtskonformität, mit einer Dokumentationsaufbewahrung von mindestens zehn Jahren. Diese Pflichten treffen die Modellanbieter. Was daraus für Ihr eigenes Haus folgt, hängt von Ihrer Rolle in der Lieferkette ab und ist eine Frage an Ihre Rechtsberatung, nicht an einen Fachbeitrag.

Was das für eine Entscheidung in Deutschland bedeutet

Zusammengenommen ergibt die Veröffentlichung ein ungewöhnlich klares Bild, gerade weil die beiden Geschichten in verschiedene Richtungen zeigen. Technisch ist Fable 5.1 die günstigere Wahl für lange Agentenschleifen, in denen derselbe Kontext immer wieder gelesen wird. Regulatorisch ist es ein Modell, das man ohne 30-tägige Aufbewahrung gar nicht erst starten kann.

Vier Fragen sollten deshalb beantwortet sein, bevor die Integration beginnt.

1. Wie hoch ist Ihre Cache-Trefferquote wirklich? Die gesamte Ersparnis hängt an dieser einen Kennzahl. Messen Sie sie an einem echten Lastprofil, bevor Sie mit 25 Prozent kalkulieren.
2. Verträgt Ihre Datenschutzfreigabe eine 30-tägige Aufbewahrung? Wenn nein, ist Fable 5.1 bis zu einer ausdrücklichen Genehmigung durch Anthropic keine Option, und die Frage lässt sich nicht technisch umgehen.
3. Über welchen Endpunkt läuft die Inferenz? Wird eine Verarbeitung in der EU benötigt, führt der Weg über Bedrock oder Google Cloud, mit 10 Prozent Aufschlag gegenüber den globalen Endpunkten, mit dem Cloud-Anbieter als Auftragsverarbeiter und mit dessen eigenen Lebenszyklusterminen.
4. Reicht Opus 5? Anthropic selbst empfiehlt Opus 5 als Standard, und Opus 5 steht nicht auf der Liste der Covered Models. Ein Teil der hier beschriebenen Governance-Fragen stellt sich dort in dieser Form nicht.

Nichts davon ist ein Argument gegen Anthropic. Fable 5.1 ist ein starkes Modell, die Cache-Änderung ist für agentische Arbeit eine echte Verbesserung, und dass die unbequemen Fakten in Anthropics eigener Dokumentation sauber nachlesbar sind, spricht für den Anbieter und nicht gegen ihn. Es ist ein Argument dafür, die Reihenfolge umzudrehen: erst klären, unter welchen Bedingungen Ihre Daten verarbeitet werden dürfen, dann das Modell wählen. Was Fable 5.1 in der täglichen Arbeit tatsächlich leistet, behandelt ein eigener Beitrag zu den Fähigkeiten in der Praxis; wie es im direkten Vergleich zu GPT-6 Astra steht, ein weiterer.

Die Tabelle, die gerade überall zirkuliert, ist kaputt

Der häufigste Satz in der aktuellen Berichterstattung lautet sinngemäß: Anthropics eigene Benchmarks zeigten Claude Fable 5.1 vor GPT-6 Astra. Dieser Satz ist falsch, und man widerlegt ihn mit einem Kalender.

Anthropic hat seine Benchmark-Tabelle am 1. September 2026 veröffentlicht. Die Vergleichsspalte darin trägt die Bezeichnung GPT-5.6 Sol. GPT-6 Astra ging am 3. September in die begrenzte Vorschau und am 4. September in die allgemeine Verfügbarkeit. Anthropic hat Astra also nicht nur nicht gemessen, sondern konnte es gar nicht messen: das Modell war zum Zeitpunkt der Veröffentlichung nicht öffentlich.

Wer die Zeile zu Terminal-Bench 4.0 liest, in der 55,8 Prozent für Fable 5.1 gegen 37,3 Prozent stehen, und diese 37,3 Prozent für Astra hält, vergleicht das aktuelle Anthropic-Modell mit dem Vorgänger des Wettbewerbers. Das ist kein Rundungsfehler, sondern eine andere Aussage. Und es ist genau die Fehldeutung, die sich derzeit am schnellsten in Aggregatoren und Zusammenfassungen fortpflanzt.

Der Wert dieses Beitrags liegt deshalb weniger in den Zahlen als in der Sortierung: welche Vergleiche belastbar sind, welche nicht, und woran man den Unterschied erkennt.

Was sich wirklich eins zu eins vergleichen lässt

Es bleibt ein kleiner, aber sauberer Kern. Alle Zeilen der folgenden Tabelle stammen aus den Anthropic-Modelldokumenten, der Anthropic-Preisseite und der OpenAI-Entwicklerdokumentation zu gpt-6-astra, abgerufen am 10. September 2026. Es sind Angaben der jeweiligen Anbieter über ihr eigenes Produkt, in derselben Einheit, ohne Messrahmen dazwischen.

Ein Vorbehalt gehört an die Cache-Schreiben-Zeile: Anthropic verkauft zwei Haltedauern, fünf Minuten und eine Stunde, OpenAI veröffentlicht keine entsprechende Staffel. Die 12,50 USD stehen sich also nahe, aber nicht exakt parallel gegenüber.

Die wirtschaftlich interessante Zeile ist das Cache-Lesen. Der Faktor vier zugunsten von Anthropic klingt nach einer Nebenposition, ist es bei agentischer Arbeit aber nicht: dort wird derselbe Kontext, Repository, Systemanweisung, Werkzeugbeschreibungen, über hunderte Schritte immer wieder gelesen. Anthropic beziffert die daraus folgende Ersparnis selbst mit rund 25 Prozent gegenüber Fable 5 bei typischen Lasten und bis zu rund 45 Prozent bei stark agentischen Lasten. Dieser Wert ist eine Modellrechnung des Anbieters, keine Preissenkung: die Listenpreise für Ein- und Ausgabe sind unverändert, und wer wenig Cache-Treffer erzeugt, spart praktisch nichts.

Zwei weitere Positionen gehören in eine Kalkulation. Anthropics Batch-API halbiert beide Richtungen auf 5 USD Eingabe und 25 USD Ausgabe je Million Token. Und wer die Inferenz bei Anthropic auf die USA festnagelt, zahlt laut Anthropics Dokumentation zur Datenhaltung einen Aufschlag von Faktor 1,1 auf Eingabe, Ausgabe, Cache-Schreiben und Cache-Lesen.

Terminal-Bench 4.0: der einzige Wert mit einer echten Gegenprobe

Eine Benchmark-Zeile in diesem Vergleich verdient besonderes Zutrauen, und zwar aus einem Grund, der selten erklärt wird.

Anthropic nennt am 1. September 2026 für Claude Fable 5.1 auf Terminal-Bench 4.0 55,8 Prozent. In den von OpenAI berichteten Ergebnissen zu GPT-6 Astra, am 3. September 2026 von DataCamp wiedergegeben und dort ausdrücklich als anbieterberichtet gekennzeichnet, steht Astra bei 57,7 Prozent, und Fable 5.1 wird mit unveränderten 55,8 Prozent geführt.

Beide Anbieter kommen also unabhängig voneinander auf denselben Wert für das Modell des jeweils anderen Lagers. Das ist die stärkste einzelne Kontrolle, die in diesem Vergleich überhaupt verfügbar ist. Ein Anbieter hat wenig Anreiz, den Konkurrenten zu hoch anzusetzen, und wenn zwei Parteien mit gegenläufigem Interesse dieselbe Zahl melden, spricht das dafür, dass die Zahl den Aufbau überlebt und nicht bloß eine Hausmessung ist.

Zwei Einschränkungen bleiben trotzdem. Erstens sagt keine der beiden Veröffentlichungen, mit welchem Harness, welchem Scaffold und welcher Effort-Stufe gemessen wurde. Zweitens ist der Abstand von 1,9 Prozentpunkten klein genug, dass er von genau diesen Faktoren stammen könnte. Die belastbare Lesart lautet deshalb: auf Terminal-Bench 4.0 liegen die beiden Modelle nach den Angaben beider Anbieter dicht beieinander, mit einem leichten Vorsprung für Astra nach OpenAIs Messung.

Was nicht vergleichbar ist, und warum

Der größere Teil der veröffentlichten Zahlen gehört nicht in eine gemeinsame Tabelle. Das ist kein Formalismus, sondern der Unterschied zwischen einer Entscheidungsgrundlage und einer Zahlenwand.

• OSWorld 2.0. Anthropic nennt für Fable 5.1 zwei Werte, 77,9 Prozent mit Teilpunkten und 41,7 Prozent bei strenger Wertung. Auf OpenAI-Seite steht für Astra ein einzelner Wert von 72,6 Prozent, ohne Angabe der Wertungsart. 72,6 gegen 77,9 zu stellen ist genauso unbegründet wie 72,6 gegen 41,7. Solange die Wertungsart nicht übereinstimmt, gibt es hier keinen Vergleich, sondern nur eine Auswahl.
• Kontextfenster. Anthropic gibt 1.000.000 Token an, OpenAI 1.050.000 bei maximal 922.000 Token Eingabe. Diese Zahlen sind keine Kapazitätsangabe im selben Maßstab, weil ein Token je Tokenizer etwas anderes bedeutet. Anthropic schreibt selbst, dass der aktuelle Tokenizer für denselben Text rund 30 Prozent mehr Token erzeugt als der eigene vorherige. Eine anbieterübergreifende Angabe zu Token je Wort ist öffentlich nicht verfügbar, also lässt sich die Frage, welches Modell mehr Text fasst, aus offenen Quellen nicht beantworten.
• AutomationBench. Anthropic veröffentlicht 31,4 Prozent für Fable 5.1. OpenAI beansprucht in seinem eigenen Ankündigungsbeitrag den Spitzenplatz auf derselben Benchmark, nennt dort aber keine Zahl. Es gibt schlicht nichts zu vergleichen.
• Zeilen, in denen die Claude-Zahl nicht von Anthropic stammt. Für ScreenSpot-Pro, FrontierMath Tier 4 v2, ExploitBench, ARC-AGI-3, GPQA Diamond und FrontierCode 1.1 existieren nur Werte von OpenAI-Seite. Die Claude-Zahl in diesen Zeilen ist OpenAIs Messung von Claude, und in mehreren Fällen eine Messung von Claude Fable 5 oder Claude Opus 5, nicht von Fable 5.1. Wer sie Anthropic zuschreibt, zitiert die falsche Quelle und teilweise auch das falsche Modell.
• Effort-Stufen. Beide Anbieter erlauben unterschiedlich hohen Rechenaufwand je Anfrage. Bei Anthropic unterscheidet sich schon die Voreinstellung nach Oberfläche: high in Claude Code, medium in claude.ai und Claude Cowork. Artificial Analysis misst auf den Stufen „max“ und „xhigh“. Eine Benchmark-Zahl ohne angegebene Effort-Stufe ist mit einer Zahl auf einer anderen Stufe nicht vergleichbar. Das ist keine Feinheit, sondern der wahrscheinlichste Grund dafür, dass dieselbe Rangliste auf drei Websites drei verschiedene Ergebnisse hat.

Ein Sonderfall verdient eine Warnung: die 99,9 Prozent, die für Astra auf ARC-AGI-3 zirkulieren, tragen in der Quelle den Zusatz „Adapter-Harness“ und stehen neben 7,8 Prozent für das Vorgängermodell. Ein Sprung von rund 92 Punkten über einen Harness-Wechsel beschreibt zuerst den Harness und erst danach das Modell. Diese Zahl gehört in keine Überschrift.

Die Ranglisten widersprechen einander offen

Wer den Anbieterzahlen misstraut, greift zu Drittanbieter-Ranglisten. In diesem Fall hilft das nicht, denn die Ranglisten sind untereinander uneinig, und zwar bei ein und demselben Index.

Artificial Analysis nennt im eigenen Beitrag vom 3. September 2026 für den Intelligence Index: GPT-6 Astra 61, GPT-5.6 Sol 61, Claude Fable 5.1 66, letzteres auf maximaler Effort-Stufe mit einer Fallback-Konfiguration, die nicht der API-Voreinstellung entspricht. BenchLM gibt denselben Index im September 2026 anders wieder: GPT-5.6 Sol führt mit 58,9 Prozent, Fable 5.1 liegt bei 53,7 Prozent. llm-stats meldet, abgerufen am 10. September 2026, Fable 5.1 bei 56,8, Astra bei 54,7 und Claude Opus 5 bei 54,1.

Drei Quellen, ein Index, drei Rangfolgen. Sie können nicht alle aktuell sein. Als Ursachen kommen unterschiedliche Stichtage, unterschiedliche Effort-Einstellungen und die Vermischung von Punktwerten mit Prozentangaben in Frage. Die praktische Konsequenz ist einfach: Ein Intelligence-Index-Wert ohne Nennung von Website, Datum und Effort-Stufe ist keine Information. Artificial Analysis selbst weist im Übrigen auf gemischte Befunde hin, darunter einen Rückgang von rund 80 Elo-Punkten auf GDPval-AA v2.

Bleibt die Arena. Auch dort gibt es nichts zu holen: Weder Claude Fable 5.1 noch GPT-6 Astra hat in den erreichbaren Momentaufnahmen vom September 2026 eine gewertete LMArena-Platzierung, weil Arena-Elo Abstimmungsvolumen braucht und Frontier-Veröffentlichungen um Wochen hinterherhinkt. Selbst wenn die Werte vorlägen, wären sie für diese Entscheidung das falsche Instrument. Blinde paarweise Präferenz misst die wahrgenommene Antwortqualität auf selbstgewählten Prompts, reagiert stark auf Formatierung und Ausführlichkeit und sagt wenig über agentische Arbeit über lange Zeiträume. Für einen Coding-Agenten oder eine Wissensarbeitsplattform ist das nicht der Maßstab, an dem sich ein Einkauf ausrichten sollte.

FrontierCode 1.1: die Zahl, die gegen den eigenen Anbieter spricht

Es gibt in diesem Vergleich eine Zeile, die aus einem methodischen Grund mehr wiegt als die anderen. Auf FrontierCode 1.1 steht GPT-6 Astra nach OpenAIs eigenen berichteten Ergebnissen bei 53,3 Prozent und damit hinter Claude Fable 5 mit 53,5 Prozent.

Zwei Präzisierungen sind hier Pflicht. Der Vergleichswert stammt von Claude Fable 5, nicht von Fable 5.1, und Anthropic hat für Fable 5.1 auf dieser Benchmark keinen eigenen Wert veröffentlicht. Der Abstand beträgt 0,2 Prozentpunkte und ist damit innerhalb jeder plausiblen Messstreuung.

Trotzdem ist es die vertrauenswürdigste Art von Zahl, die es in einer Produktankündigung gibt. Ein Anbieter, der eine Zeile veröffentlicht, in der sein neues Flaggschiff hinter einem fremden Modell liegt, hat dafür keinen Marketinganreiz. Wer die Belastbarkeit einer Benchmark-Tabelle einschätzen will, sollte zuerst danach suchen, ob solche Zeilen darin vorkommen. Eine Tabelle, in der der veröffentlichende Anbieter jede einzelne Zeile gewinnt, ist keine Messung, sondern eine Auswahl.

Die Richtung dreht sich: EU-Datenhaltung und Zero Data Retention

Bis hierhin liegt Anthropic bei Preis und Cache-Ökonomie vorn und bei den Benchmarks ungefähr gleichauf. Bei der Datenhaltung kehrt sich das Bild vollständig um, und für ein deutsches Unternehmen ist das die Spalte, die eine Architektur verändert.

Auf Anthropic-Seite steht das in der eigenen Dokumentation. Der Parameter inference_geo akzeptiert genau zwei Werte, global und us, und als Speicherregion eines Workspace ist ausschließlich us wählbar, unveränderlich nach Anlage. Noch deutlicher ist die Retention-Seite: Anthropic führt Fable 5.1 und Mythos 5.1 (sowie Fable 5 und Mythos 5) als Covered Models, die eine 30-tägige Datenspeicherung erfordern und ohne ausdrückliche Freigabe durch Anthropic nicht unter Zero Data Retention verfügbar sind. Eine Organisation mit ZDR muss die 30-Tage-Speicherung für einen bestimmten Workspace aktiv einschalten, sonst wird die Anfrage abgelehnt.

Auf OpenAI-Seite steht in der Entwicklerdokumentation zur Datenverarbeitung, dass Europa (EWR und Schweiz) sowohl regionale Speicherung als auch regionale Verarbeitung über eu.api.openai.com unterstützt, konfiguriert je Projekt, für Regionen außerhalb der USA mit Freigabe für die Missbrauchskontrolle und einem Retention-Zusatz. Dieselbe Seite listet die ZDR-fähigen Endpunkte, darunter /v1/chat/completions und /v1/responses, und schließt Assistants, Threads, Vector Stores, Fine-Tuning und Batches ausdrücklich aus.

An dieser Stelle ist Genauigkeit wichtiger als eine glatte Aussage: keine gefundene Quelle sagt positiv, dass GPT-6 Astra ZDR-fähig ist. Dokumentiert ist, dass die genannten Endpunkte ZDR unterstützen und dass für gpt-6-astra keine modellspezifische Ausnahme veröffentlicht ist. Das Fehlen einer Einschränkung ist aber keine Erlaubnis. Wer darauf eine Architektur stützt, sollte es vertraglich bestätigen lassen, statt es aus einer Dokumentationslücke abzuleiten. Bei Anthropic ist die Lage umgekehrt eindeutig, weil die Ausnahme dort ausdrücklich geschrieben steht.

Ein verbreiteter Satz gehört ebenfalls korrigiert: „Claude hat EU-Datenresidenz, weil es auf AWS Frankfurt läuft.“ Das stimmt genau dann, wenn Sie Claude über eine Partner-Cloud beziehen, etwa Amazon Bedrock oder Google Cloud, denn dort setzt der Cloud-Anbieter die Region und ist der Auftragsverarbeiter. Für Anthropics eigene API gilt es nicht. Anthropic verweist für garantiertes regionales Routing selbst auf die regionalen Endpunkte der Partner-Clouds, zu einem Aufschlag von 10 Prozent gegenüber den globalen Endpunkten. Für eine DSGVO-Prüfung ist genau dieser Unterschied der ganze Punkt, weil er bestimmt, mit wem der Auftragsverarbeitungsvertrag geschlossen wird.

Artikel 50: ein Unterschied, den man nur halb belegen kann

Seit dem 2. August 2026 gelten die Transparenzpflichten aus Artikel 50 der KI-Verordnung, die eine maschinenlesbare Kennzeichnung synthetischer Inhalte verlangen. Anthropic gibt an, dass Fable 5.1 und Mythos 5.1 von Beginn an ein unsichtbares Wasserzeichen im Text tragen, und wendet diese Kennzeichnung weltweit an, nicht nur in der EU. Das ist, soweit die verfügbaren Quellen reichen, ein echter Unterschied.

Dieser Satz braucht jedoch beide Hälften. Es wurde keine Quelle gefunden, die aussagt, ob die Textausgabe von GPT-6 Astra gekennzeichnet ist. OpenAIs dokumentierter Provenienz-Ansatz aus C2PA-Content-Credentials und SynthID betrifft Bild und Audio; über Text sagen die erreichbaren Seiten nichts. Aus dieser Lücke folgt nicht, dass OpenAI Text nicht kennzeichnet. Wir behaupten es deshalb nicht. OpenAI veröffentlicht separat Kundenhinweise zur KI-Verordnung.

Und auch Anthropics Wasserzeichen trägt weniger, als der Begriff suggeriert. Anthropic schreibt in der eigenen Hilfe, ein erkanntes Kennzeichen weise darauf hin, dass Inhalte möglicherweise von Claude verarbeitet wurden, sei nicht vollständig eindeutig und belege für sich allein nicht die Herkunft eines Inhalts. Die zugehörige Erkennungs-API befindet sich zudem in einer privaten Vorschau für ausgewählte Organisationen. Als Baustein einer Compliance-Argumentation ist das Wasserzeichen brauchbar, als Beweismittel nicht.

Was das für eine deutsche Entscheidung heißt

Wenn Sie aus diesem Vergleich eine einzige Regel mitnehmen, dann diese: Bei zwei Frontier-Modellen, die auf den belastbaren Zahlen dicht beieinanderliegen und identische Listenpreise haben, entscheidet selten eine Benchmark-Zeile. Der Abstand auf Terminal-Bench 4.0 beträgt 1,9 Prozentpunkte ohne angegebenes Harness. Auf FrontierCode 1.1 sind es 0,2 Punkte in die andere Richtung, gegen ein älteres Claude-Modell. Solche Abstände verschieben sich mit dem nächsten Release, und sie ändern keine Architektur.

Was eine Architektur ändert, steht in der Governance-Spalte. Eine Organisation, die Zero Data Retention als Auflage hat, kann Claude Fable 5.1 über Anthropics eigene API nicht ohne ausdrückliche Freigabe einsetzen, unabhängig davon, wie gut das Modell ist. Eine Organisation, die Inferenz in der EU verlangt, findet diesen Weg bei Anthropic nur über eine Partner-Cloud, mit dem entsprechenden Aufschlag und einem anderen Auftragsverarbeiter im Vertrag. Umgekehrt bleibt der Vorteil von Anthropic beim Cache-Lesen real und wächst mit dem Anteil agentischer Arbeit, bei der derselbe Kontext hundertfach gelesen wird.

Praktisch heißt das: Klären Sie zuerst die Auflagen, dann die Kosten und erst am Ende die Benchmarks. In der umgekehrten Reihenfolge bauen Sie ein System, das gut misst und im Datenschutzgespräch scheitert. Und prüfen Sie bei jeder Zahl, die Ihnen jemand zeigt, drei Dinge: wer sie berichtet hat, wann, und auf welcher Effort-Stufe.

Was sich mit dem Release selbst für ein deutsches Unternehmen verändert hat, steht in unserem Beitrag zu Claude Fable 5.1. Wie sich das Modell in laufender Projektarbeit verhält, behandeln wir in Fähigkeiten in der Praxis. Und wenn die Antwort auf die Governance-Frage lautet, dass die Daten das Haus gar nicht verlassen dürfen, führt der Weg ohnehin an der Abwägung zwischen On-Premise und Cloud vorbei, nicht an einer Rangliste.

Die Ursache ist fast immer die Datenstruktur: die Bäume, mit denen parametrische Umgebungen Listen von Listen verwalten. Etwa alle Fenster je Geschoss je Fassade. Wer diese Ebenen einmal falsch zusammenführt, bekommt kein Fehlerbild, sondern ein anderes Bauwerk.

Warum der Fehler nicht auffällt

Weil die Ausgabe plausibel ist. Wenn 120 Paneele erwartet werden und 120 Paneele entstehen, ist die erste Prüfung bestanden. Dass Paneel 47 die Maße von Position 74 trägt, sieht man an einer Fassade mit ähnlichen Elementen nicht.

Verstärkt wird das dadurch, dass parametrische Umgebungen selten hart abbrechen. Sie gleichen Listen unterschiedlicher Länge stillschweigend an, indem sie den letzten Wert wiederholen. Das ist im Alltag bequem und in genau diesem Fall fatal: die Struktur bleibt heil, der Inhalt nicht.

Die drei Muster, die fast alle Fälle erklären

Erstens der Ebenenversatz. Zwei Datenströme werden zusammengeführt, die auf unterschiedlichen Ebenen verzweigt sind. Einer trägt die Struktur Fassade zu Geschoss zu Öffnung, der andere nur Fassade zu Öffnung. Das Ergebnis hat die richtige Anzahl und die falsche Zuordnung.

Zweitens das ungewollte Abflachen. Ein Arbeitsschritt, der die Baumstruktur einebnet, um eine Operation zu ermöglichen, und danach wird nie wieder verzweigt. Ab dieser Stelle weiß das Modell nicht mehr, welches Element zu welchem Geschoss gehört, und es sagt es nicht.

Drittens die Wiederholung des letzten Werts. Eine Liste mit 12 Werten trifft auf eine mit 120 Elementen. Die ersten 12 stimmen, die restlichen 108 tragen den zwölften Wert. Der Fehler ist am Anfang der Liste unsichtbar und am Ende systematisch.

Prüfen statt hinsehen

Die wirksamste Gegenmaßnahme ist keine höhere Aufmerksamkeit, sondern eine Zählung. An jeder Stelle, an der zwei Ströme zusammenkommen, gehört die erwartete Zahl der Zweige und die erwartete Zahl der Elemente je Zweig ausgeschrieben und mit der tatsächlichen verglichen.

Das kostet ein paar Minuten pro Zusammenführung und fängt alle drei Muster oben ab, weil alle drei die Zählung verändern, bevor sie die Geometrie verändern.

Zweite Maßnahme: eine sichtbare Probe. Ein Element wird eingefärbt oder beschriftet und im Modell verfolgt, vom Eingang bis zum Zuschnitt. Wenn Position 47 am Ende noch Position 47 ist, stimmt die Zuordnung. Das ist der einzige Test, der die ganze Kette abdeckt.

Dritte Maßnahme: die Struktur benennen. Wer die erwartete Baumstruktur an den wichtigen Stellen als Kommentar hinschreibt, dokumentiert nicht nur, sondern zwingt sich zu der Frage, ob sie noch stimmt.

Warum das teurer ist als es klingt

Weil der Fehler nach unten durchschlägt. Aus derselben Struktur entstehen Zuschnitte, Stücklisten und Preise. Eine Zuordnung, die im Bild nicht auffällt, fällt in der Fertigung auf, wenn das Material bereits geschnitten ist.

Und weil das Vertrauen mitgeht. Ein Team, das einmal erlebt hat, dass ein parametrisches Modell überzeugend falsch war, prüft danach jede Ausgabe von Hand nach. Damit ist der Zeitgewinn weg, der der Grund für die Methode war.

Was wir uns angewöhnt haben

Zählprüfungen an jeder Zusammenführung, eine markierte Probe je Bauteilfamilie, und Cluster mit festgelegten Ein- und Ausgängen statt gewachsener Graphen. Ein Cluster erzwingt eine Entscheidung darüber, welche Struktur hinein- und herausgeht, und genau diese Entscheidung ist es, die sonst unterbleibt.

Nichts davon ist aufwendig. Es ist die Sorte Disziplin, die aus der Softwareentwicklung kommt und in parametrischen Modellen aus demselben Grund wirkt: der Fehler, der nicht abbricht, ist der teuerste.

Das ist der Punkt, an dem aus Computational Design Softwareentwicklung wird. Eine Definition lässt sich ohne Oberfläche auf einem Server betreiben und über eine Schnittstelle ansprechen. Was dann davorsteht, kann ein Konfigurator im Browser sein, eine Angebotsrechnung, eine Prüfung in einem bestehenden System oder alles drei aus derselben Quelle.

Was ein Geometrie-Server tatsächlich ist

Ein Rechenknoten, der die Definition geladen hat, Parameter entgegennimmt und das Ergebnis zurückgibt: Geometrie in einem Austauschformat, dazu die Kennzahlen, die im Modell ohnehin berechnet werden. Fläche, Gewicht, Teilezahl, Verschnitt, Materialbedarf.

Der entscheidende Teil ist der zweite. Ein Konfigurator, der nur ein Bild liefert, ist eine Visualisierung. Einer, der zusätzlich die Stückliste und den Materialbedarf zurückgibt, ist ein Vertriebswerkzeug, und das ist der Unterschied, der ein solches Vorhaben trägt.

Die Definition bleibt dabei dieselbe Datei, mit der entworfen wird. Genau das ist der Punkt: es gibt keine zweite Nachbildung der Logik, die auseinanderlaufen kann.

Warum die zweite Nachbildung das eigentliche Problem ist

Der übliche Weg zu einem Konfigurator führt über eine Neuimplementierung: Ein Entwicklungsteam bekommt die Regeln als Dokument beschrieben und baut sie in der Anwendung nach. Von diesem Tag an gibt es zwei Wahrheiten.

Sie laufen auseinander, und zwar leise. Der Entwurf bekommt eine neue Randbedingung, der Konfigurator nicht. Ein halbes Jahr später verkauft der Vertrieb eine Ausführung, die die Fertigung ablehnt, und niemand kann sagen, seit wann.

Mit der Definition als Dienst gibt es diese Klasse von Fehlern nicht. Eine Regeländerung im Entwurf ist eine Regeländerung im Verkauf, weil es dieselbe Regel ist.

Der Zuschnitt, der in der Praxis funktioniert

Nicht jede Anfrage darf eine volle Berechnung auslösen. Bewährt hat sich eine Trennung in drei Stufen: eine sofortige Vorschau aus vorberechneten Zwischenständen, eine vollständige Berechnung auf Anforderung, und eine Ableitung der Fertigungsdaten erst nach der Auswahl.

Der Variantenraum wird dafür vorher abgetastet und die Ergebnisse werden abgelegt. Was ein Kunde im Browser bewegt, ist dann meistens eine Auswahl aus bekannten Ergebnissen und keine Live-Rechnung. Das ist der Unterschied zwischen einer Antwort in Millisekunden und einer in zwanzig Sekunden.

Für die Darstellung im Browser wird die Geometrie vereinfacht ausgeliefert. Wichtig ist, dass diese Vereinfachung automatisiert aus dem Konstruktionsmodell fällt und nicht von Hand gepflegt wird, sonst ist die zweite Wahrheit über die Hintertür wieder da.

Woran es tatsächlich klemmt

Rechenzeit. Eine Definition, die im Entwurf zwanzig Sekunden braucht, braucht sie auch auf dem Server. Interaktiv ist das nicht. Entweder wird die Definition auf Geschwindigkeit hin überarbeitet, was oft möglich und selten beliebt ist, oder der Variantenraum wird vorberechnet.

Zustand. Entwurfsumgebungen halten Zustand zwischen Aufrufen. Ein Dienst, der viele Anfragen parallel bedient, darf das nicht. Definitionen, die sich auf zuletzt geladene Dateien oder Referenzobjekte verlassen, verhalten sich unter Last nicht reproduzierbar, und dieser Fehler tritt genau dann auf, wenn niemand zusieht.

Lizenzierung. Der Serverbetrieb einer Entwurfsumgebung ist lizenzrechtlich eine andere Frage als der Arbeitsplatzbetrieb. Das gehört vor die Architekturentscheidung und nicht danach, weil es das gesamte Betriebsmodell bestimmt.

Und Fehlerfälle. Eine unzulässige Parameterkombination darf keinen Serverfehler erzeugen, sondern muss eine begründete Ablehnung zurückgeben. Randbedingungen als Prüfungen im Modell zahlen sich hier ein zweites Mal aus.

Wo die Daten bleiben

Der gesamte Aufbau lässt sich im eigenen Haus betreiben. Das ist kein Randthema: eine Definition enthält die Konstruktionslogik eines Produkts, und für viele Hersteller ist genau das der Kern dessen, was nicht abfließen darf.

Wir bauen solche Dienste deshalb so, dass Rechenknoten, Ergebnisspeicher und Auslieferung in der Infrastruktur des Kunden stehen können, mit einer Schnittstelle als einziger Berührungsfläche nach außen.

Wann sich der Schritt lohnt

Wenn dieselben Fragen mehrfach im Monat an dieselbe Person gehen. Wenn der Vertrieb Varianten verkaufen soll, die er selbst nicht durchrechnen kann. Wenn aus der Geometrie ohnehin Stücklisten oder Preise entstehen sollen.

Und nicht, wenn der Konfigurator vor allem hübsch sein soll. Ein 3D-Konfigurator ohne Kennzahlen dahinter ist eine Visualisierung mit Wartungsaufwand, und die gibt es billiger.

Was hier steht, sind keine Preise. Es sind die Kostenstellen, nach denen Sie ein Angebot durchsuchen sollten, und die Größenordnungen, in denen sie zueinander stehen.

Die Inferenz ist selten das Problem

Die Rechnung, mit der gerechnet wird, ist die pro Anfrage: Kontext hinein, Antwort heraus, Preis je Token. Sie ist gut kalkulierbar und in den meisten Häusern kleiner als erwartet, weil die Zahl der Anfragen kleiner ist als erwartet. Ein internes Wissenssystem mit 200 Beschäftigten sieht keine Millionen Anfragen.

Worauf zu achten ist: deutschsprachige Texte verbrauchen spürbar mehr Token als englische, und ein großzügig gefülltes Kontextfenster kostet pro Anfrage mehr als eine gute Suche davor. Wer Retrieval und Reranking ernst nimmt, senkt damit auch die laufenden Kosten, nicht nur die Fehlerquote.

Der Index ist die eigentliche laufende Position

Ein Index ist kein Bauwerk, das fertig wird. Neue Dokumente müssen hinein, geänderte ersetzt, gelöschte entfernt. Das ist Betrieb, und es braucht jemanden, der zuständig ist.

Der teure Sonderfall ist der Wechsel des Embedding-Modells. Embeddings sind nur untereinander vergleichbar, also erzwingt jeder Wechsel die Neuberechnung des gesamten Bestands. Bei einigen zehntausend Dokumenten ist das ein Wochenendlauf, bei Millionen eine Planung. Wer das nicht einkalkuliert, sitzt auf dem Modell fest, mit dem er angefangen hat.

Dazu kommt die Pflege des Bestands selbst, und das ist die Position, die am häufigsten fehlt. Ein Retrieval-System zitiert eine überholte Arbeitsanweisung genauso überzeugend wie die gültige. Aussortieren ist Handarbeit und wird wichtiger, nicht unwichtiger, sobald das System benutzt wird.

Evaluation ist eine Kostenstelle, keine Phase

Der Goldstandard-Testsatz aus echten Fragen mit geprüften Antworten entsteht einmal und veraltet danach. Neue Themen kommen dazu, alte Antworten stimmen nicht mehr.

Ohne laufende Evaluation lässt sich keine Änderung mehr verantworten: ein neues Modell, ein anderes Chunking, ein zusätzlicher Filter. Man merkt an Einzelfällen, dass etwas anders ist, und kann nicht sagen, ob es besser ist. Ab diesem Punkt wird nichts mehr geändert, und das System altert.

Als Größenordnung: die Pflege von Testsatz und Auswertung ist über die Laufzeit derselbe Aufwand wie die Indexpflege, und beide zusammen übersteigen die Inferenzkosten in fast allen Fällen im Mittelstand.

Lokal oder gehostet ist eine Tauschentscheidung, keine Sparentscheidung

Lokaler Betrieb tauscht laufende Token-Kosten gegen einmalige Anschaffung plus Betrieb. Die begrenzende Größe ist der Videospeicher, weil er bestimmt, welche Modellgröße hineinpasst; Rechengeschwindigkeit entscheidet danach nur über den Durchsatz.

Was in der Rechnung oft fehlt: Strom, Kühlung, Ersatzteile und vor allem jemand, der die Modelle aktualisiert. Ein lokales Modell veraltet, und der Aktualisierungsprozess ist Ihrer.

Was dafür spricht, ist meistens nicht der Preis, sondern dass die Dokumente das Haus nicht verlassen. Das ist eine gute Begründung. Die Ersparnis als Hauptargument trägt nur bei hohem, gleichmäßigem Anfragevolumen.

Die Positionen, nach denen wir ein Angebot durchsuchen würden

Wer pflegt den Index und mit welchem Aufwand pro Monat. Was passiert bei einem Wechsel des Embedding-Modells und wer trägt ihn. Wie wird gemessen, ob das System noch richtig antwortet, und wie oft. Wie werden Rechte abgebildet und wer pflegt sie, wenn sich die Organisation ändert. Und was kostet der Ausstieg, also in welcher Form die Daten und der Index das System verlassen.

Ein Angebot, das diese fünf Fragen beantwortet, ist möglicherweise teurer als eines, das sie nicht stellt. Es ist auch das einzige der beiden, dessen Zahl nach einem Jahr noch stimmt.

Die ehrliche Antwort ist eine Rechnung, keine Haltung. Ein parametrisches Modell verschiebt Aufwand von hinten nach vorne. Es kostet mehr, bevor die erste Ausführung steht, und weniger bei jeder weiteren. Ob sich das trägt, hängt an drei Größen, die sich vor Projektbeginn abschätzen lassen.

Die drei Größen, an denen es hängt

Die erste ist die Zahl der Ausführungen. Nicht die Zahl der Varianten, die im Entwurf betrachtet werden, sondern die Zahl der Teile, Module oder Objekte, die am Ende wirklich hergestellt oder gebaut werden. Zwanzig unterschiedliche Fassadenpaneele sind ein Fall dafür. Ein Bauwerk ist es nicht.

Die zweite ist die Zahl der Änderungsrunden. Sie wird fast immer unterschätzt und ist der eigentliche Hebel. Ein Entwurf, der viermal überarbeitet wird, wird bei manueller Bearbeitung viermal vollständig nachgezogen. Ein Regelwerk wird einmal angepasst und rechnet neu.

Die dritte ist die Kopplung zwischen Entwurf und Nachgelagertem. Wenn aus derselben Geometrie auch Stücklisten, Zuschnitte, Angebotspreise oder ein Konfigurator entstehen sollen, entsteht der Nutzen nicht einmal, sondern pro angeschlossenem Schritt.

Eine Faustregel, die trägt

Als grobe Orientierung aus umgesetzten Projekten: Der Aufbau einer belastbaren Definition kostet ungefähr das Drei- bis Fünffache der ersten manuell gezeichneten Variante. Jede weitere Variante kostet danach nahezu nichts.

Daraus folgt der Umschlagpunkt bei etwa fünf Ausführungen, wenn sich nichts mehr ändert. Er verschiebt sich auf zwei bis drei, sobald mit mindestens einer echten Änderungsrunde zu rechnen ist, weil die Änderung im Regelwerk einmal und in der Zeichnung pro Variante anfällt.

Diese Zahlen sind Größenordnungen und keine Kalkulation. Sie sind trotzdem nützlich, weil sie die Diskussion an der richtigen Stelle führen: nicht darüber, ob Parametrik beeindruckend ist, sondern darüber, wie oft sich Ihr Entwurf ändern wird.

Wo die Rechnung kippt, und das wird selten gesagt

Bei einem einmaligen Entwurf ohne Wiederholung. Ein Sonderbauteil, ein Messestand, ein Objekt, das genau einmal existiert: hier gewinnt Zeichnen, und zwar deutlich. Ein Regelwerk für eine einzige Ausführung ist ein teurer Umweg.

Bei unklaren Randbedingungen. Parametrik zwingt dazu, die Regel vorher zu formulieren. Wenn niemand sagen kann, welche Maße gelten, welche Toleranzen zulässig sind und welche Ausführungen ausgeschlossen sind, entsteht ein Modell, das schnell viele falsche Varianten erzeugt. Das ist schlechter als eine Zeichnung, weil es überzeugender aussieht.

Bei Entwürfen, deren Wert in der Ausnahme liegt. Ein Regelwerk ist gut in dem, was sich wiederholt. Wo die gestalterische Qualität gerade aus dem Bruch mit der Regel entsteht, arbeitet die Methode gegen das Ziel, und die Ausnahmen zurück ins Modell zu bauen kostet mehr als sie erspart.

Und bei Teams ohne Übernahme. Eine Definition, die nur ihr Autor ändern kann, ist eine Abhängigkeit und kein Werkzeug. Wenn niemand im Haus sie weiterführen soll oder kann, gehört das in die Rechnung.

Was die Rechnung deutlich verbessert

Bauteilfamilien statt Einzelteile. Fünf Familien mit je zwanzig Maßen sind herstellbar und kalkulierbar, hundert Unikate sind es meist nicht. Die Familienbildung ist der Schritt, in dem ein parametrisches Modell den Preis wirklich senkt, und sie ist eine Entwurfsentscheidung, keine Software-Einstellung.

Randbedingungen als Prüfungen im Modell. Wenn eine unzulässige Ausführung gar nicht erst entsteht, entfällt die Prüfschleife am Ende. Das ist derselbe Gedanke wie ein Test in der Softwareentwicklung und wirkt aus demselben Grund.

Und eine Definition, die wie Software behandelt wird: benannt, strukturiert, kommentiert, versioniert. Eine gewachsene Definition ohne Struktur ist nach sechs Monaten für niemanden mehr änderbar, auch nicht für ihren Autor. Dann ist der eingesparte Aufwand zurück.

Wie wir das vor einem Angebot klären

Wir fragen nach der Zahl der herzustellenden Ausführungen, nach der erwarteten Zahl der Abstimmungsrunden und danach, was aus der Geometrie außer Bildern noch entstehen soll. Diese drei Antworten reichen in den meisten Fällen für eine belastbare Einschätzung.

Fällt sie negativ aus, sagen wir das. Ein Vorhaben, dem wir vom parametrischen Weg abraten, ist ein besseres Ergebnis als eine Definition, die niemand braucht.

WAS VISUELLE SUCHE BEWUSST NICHT LIEFERT

Visuelle Retrieval-Modelle finden die richtige Seite, auch in einem schwierigen Scan. Aber sie geben Ihnen ein Bild zurück, keinen Text. Sie können daraus nicht ohne Weiteres eine Zeile kopieren, keine Volltextsuche über das Archiv legen, keine maschinenlesbare Prüfspur bauen. Für all das brauchen Sie erkannten Text. Das ist keine Schwäche des neuen Ansatzes, sondern eine bewusste Arbeitsteilung: Suche auf dem Bild, Textgewinnung per OCR, jede Stufe für das, was sie am besten kann.

WAS PADDLEOCR-VL KANN

Baidu hat mit PaddleOCR-VL ein offenes OCR-Modell vorgelegt, das mit nur 0,9 Milliarden Parametern Spitzenwerte erreicht (Projekt). Es erkennt Text, Tabellen, Formeln und Diagramme in 109 Sprachen und rekonstruiert die semantische Struktur eines Dokuments. Auf dem OmniDocBench-v1.5-Benchmark steht es mit rund 94,5% Genauigkeit vorn. Es steht unter der Apache-2.0-Lizenz, ist also kommerziell frei nutzbar und lokal betreibbar. Für einen Mittelständler heißt das: starke Texterkennung ohne laufende Gebühr und ohne Datenabfluss.

DER HYBRIDE AUFBAU

Praktisch laufen beide Wege nebeneinander. Die visuelle Suche findet die relevanten Seiten schnell und layouttreu. Wo daraus harter Text werden muss, etwa für eine Rechnungsposition, eine Vertragsklausel zum Zitieren oder einen Eintrag ins ERP, übernimmt OCR auf genau diesen wenigen Seiten. Man muss nicht das ganze Archiv durch OCR schicken, sondern nur das, was die Suche bereits als wichtig markiert hat. Das hält die Pipeline schlank und vermeidet, dass OCR-Fehler von Anfang an in die Suche einsickern.

DIE PRAGMATISCHE LINIE

Entweder-oder ist hier die falsche Haltung. Visuelle Suche verbessert das Finden, OCR verbessert das Weiterverarbeiten. Wer beides als Werkzeuge mit klaren Aufgaben begreift, baut die belastbarere Wissensdatenbank als jemand, der dogmatisch auf eine Seite setzt. Wie die Bausteine zusammengehören, vom Encoder bis zur Vektordatenbank, steht im Stack-Überblick.

Für ein mittelständisches Unternehmen, das täglich Verträge, technische Handbücher und mehrseitige Rechnungen verarbeitet, ist das die interessantere Nachricht. Nicht die Texterkennung ist ein paar Punkte besser, sondern: ein 80-Seiten-Dokument muss nicht mehr in Stücke geschnitten und wieder zusammengesetzt werden, und dafür muss kein Dokument das Haus verlassen.

WAS UNLIMITED-OCR ANDERS MACHT

Der Kern ist eine veränderte Aufmerksamkeit im Decoder, die den Speicher konstant hält. Klassische OCR-Modelle auf Transformer-Basis lassen den sogenannten KV-Cache mit der Länge des Dokuments wachsen. Je länger das PDF, desto mehr Speicher, bis es irgendwann nicht mehr in eine Verarbeitung passt.

Unlimited-OCR ersetzt diesen Teil durch Reference Sliding Window Attention (R-SWA). Der KV-Cache bleibt dabei konstant, unabhängig von der Dokumentlänge. Genau das meint der Begriff one-shot long-horizon parsing: ein langes Dokument wird in einem Durchgang gelesen, statt es in Abschnitte zu zerlegen und die Ergebnisse hinterher zusammenzufügen.

Bemerkenswert ist der Trainingsweg. Das Team hat nicht bei null angefangen, sondern den DeepSeek-OCR-Checkpoint weitertrainiert: den Encoder eingefroren und nur den Decoder über rund 4.000 Schritte angepasst. Damit steht das Modell in direkter Linie zu DeepSeek-OCR, das wir im Stack-Zusammenhang schon eingeordnet haben. Code und Gewichte liegen offen auf GitHub.

WARUM DER KONSTANTE KV-CACHE ZÄHLT

Das eigentliche Problem bei langen Dokumenten ist nicht die einzelne Seite, sondern der Zusammenhang über die Seiten hinweg. Wenn ein Modell ein 60-seitiges Dokument in Zehn-Seiten-Blöcke schneidet, geht genau das verloren, was im B2B-Alltag zählt: eine Tabelle, die über den Seitenumbruch läuft, eine Klausel, die sich auf einen früheren Abschnitt bezieht, eine Position, deren Bezugsgröße zwanzig Seiten vorher steht.

Ein konstanter KV-Cache erlaubt es, das ganze Dokument in einem Kontext zu halten. Der Speicher wächst nicht mit der Länge, also bleibt die Struktur über alle Seiten erhalten. Nebenbei wird es schneller: Baidu nennt im Base-Modus 5.580 Token pro Sekunde gegenüber 4.951 bei DeepSeek-OCR, bei einem Ausgabe-Limit von 6.000 Token liegt der Abstand bei rund 35 Prozent.

Bei der Genauigkeit liegt Unlimited-OCR auf OmniDocBench v1.5 bei 93,23 Punkten, 6,22 über der DeepSeek-OCR-Basis, auf v1.6 bei 93,92. Das sind die Zahlen aus dem Paper. Auf Ihren eigenen Dokumenten zählt am Ende, wie das Modell mit Ihren Tabellen, Stempeln und Formularen umgeht, nicht der Durchschnitt eines öffentlichen Testsets. Verwandt ist die Entwicklung bei subquadratischen LLMs, die langen Kontext on-prem günstiger machen.

WO DAS IM MITTELSTAND ETWAS ÄNDERT

Der Nutzen entsteht dort, wo lange, strukturierte Dokumente in saubere, durchsuchbare Daten müssen. Ein paar konkrete Stellen:

• Verträge und Rahmenvereinbarungen. Querverweise und Anhänge bleiben im Zusammenhang lesbar, statt an Blockgrenzen zu zerfallen.
• Technische Handbücher und Normen. Lange Dokumente mit Abbildungen, Tabellen und nummerierten Abschnitten in einem Durchgang.
• Mehrseitige Rechnungen und Belege. Sauber extrahierter Text ist die Vorstufe für strukturierte Weiterverarbeitung, etwa Richtung E-Rechnung.
• Archive und Akten. Bestände, die bisher nur als Scan vorlagen, werden maschinell lesbar, ohne sie an einen Cloud-Dienst zu geben.

In fast allen Fällen ist OCR nicht das Ziel, sondern der erste Schritt. Sauber geparster Text ist die Grundlage für eine Wissensdatenbank mit RAG: je besser das Parsing, desto besser findet die Suche später die richtige Stelle.

OCR ODER VISUELLE DOKUMENTENSUCHE?

Nicht jede Dokumentenaufgabe braucht klassische Texterkennung, und das ist eine ehrliche Abwägung. Es gibt inzwischen einen ganzen Zweig, der Dokumente gar nicht erst in Text umwandelt, sondern sie als Bild durchsucht, mit Modellen wie ColPali oder ColQwen. Diesen OCR-freien Ansatz haben wir gesondert beschrieben.

Die Faustregel, die sich bei uns bewährt hat:

• Sie brauchen die tatsächlichen Zeichen (Rechnungsbeträge, Vertragsklauseln, strukturierte Extraktion, Weitergabe an ein anderes System): dann führt an OCR wenig vorbei, und ein Modell wie Unlimited-OCR ist hier stark.
• Sie brauchen die passende Stelle, nicht den Volltext (eine Frage an einen großen Bestand beantworten, eine Abbildung wiederfinden): dann kann visuelle Dokumentensuche der direktere Weg sein.

Oft ist es beides nebeneinander. Unlimited-OCR macht den OCR-Teil dieses Stacks günstiger und auf langen Dokumenten verlässlicher.

WAS ICH VOR DEM PRODUKTIVBETRIEB PRÜFEN WÜRDE

Ein guter Benchmark-Wert ist ein Grund, das Modell zu testen, kein Grund, es produktiv zu setzen. Bevor ich Unlimited-OCR in einen Kundenprozess setzen würde, würde ich vier Dinge prüfen:

🔸 Deutsche Dokumente und Handschrift. Die Benchmark-Zahlen sagen wenig über deutsche Formulare, alte Akten oder handschriftliche Vermerke. Das gehört auf einen eigenen Testsatz aus echten Dokumenten.

🔸 Tabellen und Layout. Bei B2B-Dokumenten entscheidet die Treue von Tabellen und Spalten über den Nutzen. Hier lohnt der direkte Vergleich mit dem bisherigen Stack.

🔸 Hardware und Betrieb. 3B als MoE mit rund 500M aktiven Parametern ist on-prem realistisch. Was das konkret an GPU-Speicher und Durchsatz bedeutet, gehört vor dem Rollout gemessen, nicht geschätzt.

🔸 Lizenz und Herkunft. MIT erlaubt den kommerziellen, on-prem-Einsatz ohne Fußnoten. Dass die Spur des Modells zu einem der DeepSeek-OCR-Autoren führt, ist ein Qualitätssignal, ersetzt aber die eigene Prüfung nicht.

Das eigentlich Interessante an dieser Veröffentlichung ist für mich weniger das Modell selbst als die Richtung: lange Dokumente in einem Durchgang, klein genug für das eigene Rechenzentrum, unter einer Lizenz, die niemanden einschränkt. Genau dort wird Dokumentenverarbeitung im Mittelstand gerade praktisch. Welche Ihrer Dokumente würden Sie zuerst durchlaufen lassen?

JENSEITS DES PROMPTS

Prompt Engineering stimmt die Frage ab. Context Engineering gestaltet die Umgebung, in der das Modell entscheidet. Für eine einmalige Aufgabe genügt ein guter Prompt. Für einen Agenten, der über viele Schritte läuft, Werkzeuge liest und Speicher mitführt, ist der Prompt nur ein kleiner Teil dessen, was das Modell sieht. Der Rest, was Sie abrufen, was Sie erinnern, welche Werkzeuge Sie wie freigeben, ist Kontext, und er entscheidet weit mehr über das Ergebnis. Deshalb ist das Erweitern eines Agenten-Harness überwiegend Kontextarbeit.

DIE VIER VERSAGENSMUSTER, GEGEN DIE MAN DESIGNT

Die meisten Agentenfehler gehen auf eines von vier Kontextproblemen zurück:

• Kontextüberladung. Zu viel im Fenster. Das Modell verliert den Faden, und Kosten und Latenz steigen. Mehr Kontext ist nicht besserer Kontext.
• Kontextvergiftung. Eine falsche oder veraltete Tatsache gelangt ins Fenster, und das Modell behandelt sie als Wahrheit. Ein einziger schlechter abgerufener Ausschnitt kann eine Antwort entgleisen lassen.
• Token-Verwaltung. Das Fenster ist endlich. Ohne einen Plan, was zu behalten und was zu verwerfen ist, wird das wichtige Detail von Rauschen verdrängt.
• Veralteter Speicher. Langlaufende Agenten sammeln Kontext an, der nicht mehr gilt, und handeln danach.

Das Versagen zu benennen ist die halbe Lösung. Jedes hat einen konkreten Gegenzug.

PRAKTIKEN, DIE STANDHALTEN

Ein paar Muster kehren in Aufbauten wieder, die verlässlich bleiben:

1. Abrufen, nicht abladen. Ziehen Sie die wenigen relevanten Passagen mit gutem Retrieval, statt alles hineinzukopieren. Das ist der ganze Sinn von RAG, und es ist Context Engineering angewandt auf Daten.
2. Laufend beschneiden. Wenden Sie regelbasierte Bearbeitung im Gerüst an, um das Fenster schlank zu halten: verwerfen, was ein Schritt nicht mehr braucht.
3. Lange Verläufe zusammenfassen. Ersetzen Sie ein langes Transkript durch eine getreue Zusammenfassung, bevor es die Aufgabe verdrängt.
4. Einfach beginnen, bei Bedarf skalieren. Fügen Sie Speicher und Werkzeuge nur hinzu, wenn ein echtes Versagen es verlangt, nicht standardmäßig.

Der Instinkt, mehr hinzuzufügen, ist die Falle. Die Disziplin ist das Weglassen.

WARUM DAS DAS EIGENTLICHE ENGINEERING IST

Ein größeres Modell behebt ein Kontextproblem selten; es scheitert nur teurer. Die Arbeit, die einen Agenten von der Demo zur Verlässlichkeit bringt, ist fast ausschließlich Kontextarbeit: was er sieht, wann und was er vergessen soll. Bei sehr langen Eingaben zählt auch die Modellarchitektur, und da kommen subquadratische Ansätze ins Spiel, aber für die meisten Teams liegt der Gewinn im Kontext, nicht in den Parametern.

DER MECHANISMUS, SCHLICHT

Einfaches RAG bettet Ihre Anfrage ein, findet die nächstliegenden Passagen und antwortet daraus. RAG-Fusion fügt zwei Schritte davor ein. Erstens schreibt ein Modell eine Handvoll alternativer Anfragen, die dasselbe aus verschiedenen Blickwinkeln meinen. Zweitens ruft es für alle ab und führt die gereihten Listen per Reciprocal Rank Fusion zusammen, die Passagen belohnt, die über mehrere Anfragen hinweg gut ranken statt nur bei einer. Die Antwort wird dann aus diesem verschmolzenen, neu gereihten Satz geschrieben.

WARUM DER FUSIONSSCHRITT ZÄHLT

Eine einzelne Anfrage ist eine einzelne Vermutung darüber, wie die Antwort in Ihren Dokumenten formuliert ist. Echte Archive nutzen Synonyme, Abkürzungen und unterschiedliche Formulierungen für dieselbe Sache. Indem RAG-Fusion die Frage mehrfach stellt und belohnt, was durchgängig hoch rankt, bringt es die Passage zum Vorschein, die eine einzelne Formulierung verfehlt hätte. Reciprocal Rank Fusion ist hier das stille Arbeitspferd: es kombiniert Listen, ohne vergleichbare Scores zu brauchen, weshalb es auch in Hybrid- und Late-Interaction-Aufbauten auftaucht wie denen hinter Qdrant und ColQwen.

WANN ES HILFT UND WANN ES SCHADET

RAG-Fusion verdient seine Kosten bei mehrdeutigen oder terminologielastigen Fragen, wo eine Formulierung eine schwache Wette ist. Es kostet mehr: mehrere Abrufe und ein Generierungsschritt pro Frage, es ist also keine kostenlose Latenz. Und es hat ein echtes Versagensmuster. Weichen die erzeugten Anfragevarianten von dem ab, was Sie eigentlich meinten, ziehen sie themenfremde Passagen herein und die Antwort wandert ab. Die Abhilfe ist, die erzeugten Anfragen eng an die ursprüngliche Absicht gebunden zu halten und zu messen, nicht anzunehmen, dass der Recall gestiegen ist.

WO ES UNTER DEN OPTIONEN STEHT

RAG-Fusion ist einer von mehreren Wegen, Retrieval besser zu machen, kein Ersatz für gutes Retrieval. Bevor Sie danach greifen, stellen Sie sicher, dass die Grundlagen halten: saubere Chunks, ein solides Embedding-Modell und ein Vektorspeicher, der zur Aufgabe passt. Für visuell dichte Dokumente ist der größere Hebel oft visuelles Retrieval statt mehr Anfragevarianten. Nutzen Sie F-RAG dort, wo die Frage wirklich mehrdeutig ist und der Recall-Gewinn die zusätzlichen Aufrufe wert ist.

DAS PROBLEM WAR NIE DAS ANIMIEREN, SONDERN DIE ÜBERGABE

Bisher entstand UI-Bewegung außerhalb von Figma. Die Designerin baute sie in einem zweiten Werkzeug, exportierte ein Video oder eine Beschreibung, und die Entwicklung musste die Kurven und Zeiten nachbauen, oft nach Augenmaß. Dabei geht Genauigkeit verloren: eine Easing-Kurve wird zur ungefähren Idee, ein Timing zur Schätzung. Genau dieser Bruch, nicht der Mangel an Animationswerkzeugen, hat Bewegung in vielen Produkten inkonsistent gemacht.

WAS FIGMA MOTION KONKRET BRINGT

Drei Dinge ändern den Arbeitsablauf spürbar:

• Timeline im Canvas. Keyframes, Presets und Bewegungssteuerung sitzen dort, wo das Design schon lebt. Kein Wechsel in ein zweites Werkzeug.
• Bewegung als Teil des Designsystems. Eine Komponente wird einmal animiert, und die Bewegung wandert wie Farbe oder Typografie über jeden Screen und jede Datei. Das ist der Punkt, der Konsistenz erzwingt statt sie zu erhoffen.
• Lesbare Übergabe. Im Dev Mode ist die ganze Timeline sichtbar: jeder Timing-Wert, jede Easing-Kurve, jeder Keyframe. Der Export geht als CSS, JSON oder framework-fertiges React, dazu MP4, WebM, animiertes SVG und GIF.

Damit liest die Entwicklung die Bewegung, statt sie zu interpretieren. Das ist die eigentliche Verschiebung.

WO DER HAKEN SITZT

Ein integriertes Werkzeug ist nicht automatisch das richtige für jeden Fall. Komplexe, erzählerische Motion-Arbeit, etwa ein aufwendiger Brand-Film, bleibt eine Sache für spezialisierte Werkzeuge. Figma Motion zielt auf Interface-Animation: Zustände, Übergänge, Mikrointeraktionen, also genau das, was im Produkt täglich gebraucht wird und bisher am Übergabe-Bruch litt. Für diese Klasse von Bewegung ist die Integration der Gewinn. Für alles darüber bleibt der Werkzeugkasten gemischt.

FÜR WEN SICH DER BLICK LOHNT

Wer ein Produkt mit wiederkehrenden UI-Mustern pflegt, profitiert am meisten: die einmal definierte Bewegung bleibt konsistent, und die Umsetzung bekommt exakte Werte statt Näherungen. Bewegung ist dabei kein Dekor, sondern Teil der Verständlichkeit einer Oberfläche, ein Punkt, den wir in der Rolle von UX im Software-Bau genauer ausführen. Figma Motion macht diesen Teil endlich an einer Stelle bearbeitbar.

DREI VERÖFFENTLICHUNGEN, SCHLICHT GESAGT

Jede davon erschien im Juni 2026 binnen zweier Wochen der anderen, und jede ist eine andere Art Sache. Es lohnt Präzision, denn zwei davon werden weithin falsch beschrieben.

GLM-5.2, von Z.ai in Peking, erschien am 17. Juni. Es ist ein Open-Weight-Mixture-of-Experts-Modell, rund 750 Milliarden Parameter mit etwa 40 Milliarden aktiven, ein Kontext von einer Million Token und, entscheidend, eine MIT-Lizenz mit auf HuggingFace veröffentlichten Gewichten.

Sakana Fugu, von Sakana AI in Tokio, erschien am 22. Juni. Es ist kein herkömmliches Modell, und die übliche Einordnung liegt daneben: Fugu ist ein trainierter Orchestrator, der einen Pool anderer Modelle aufruft und deren Arbeit synthetisiert. Es ist nur per API verfügbar, angeboten als OpenAI-kompatibler Endpunkt.

Claude Fable 5, von Anthropic in den Vereinigten Staaten, erschien am 9. Juni. Der zweite häufige Fehler ist, Fable als schnelle oder kreative Stufe einzuordnen. Es ist das Flaggschiff, Anthropics fähigstes breit veröffentlichtes Modell, sicherheitsgesteuert, nur in der Cloud, bei 10 und 50 Dollar je Million Token. Seine Benchmark-Zahlen sind stark; für diesen Beitrag sind sie zugleich nebensächlich.

DER EINZIGE VERGLEICH, DER DIE BESCHAFFUNG ÜBERSTEHT

Lassen Sie die Rangliste weg und stellen Sie sie auf den Dimensionen auf, für die ein deutscher B2B-Käufer tatsächlich verantwortlich ist. Das Bild ist klar, und es geht nicht darum, welches am klügsten ist.

Zwei ehrliche Vorbehalte gehören auf diese Tabelle. Der Standardweg von GLM-5.2, die Z.ai-API, unterliegt Chinas Datengesetzen mit ihren verpflichtenden Zugriffsklauseln, was genau der Grund ist, warum die offenen Gewichte zählen: Selbsthosting in der EU neutralisiert dieses Risiko. Und Fugus Behauptung von Frontier-Gleichstand ist vollständig selbst berichtet, geschwächt dadurch, dass Fable und das eingeschränkte Mythos-Modell nicht einmal in seinem Pool sind. Ich würde eine Entscheidung auf keine der beiden Anbieter-Benchmarks stützen.

WAS ICH EINEM KUNDEN TATSÄCHLICH SAGE

Ich empfehle keines davon im Abstrakten. Ich passe die Haltung an das an, was der Kunde finanzieren kann und wofür er verantwortlich ist.

🔸 GLM-5.2 ist der On-Prem-Zug. Die offenen MIT-Gewichte sind der ganze Punkt: Sie können es im eigenen Rechenzentrum betreiben, und die Prompts verlassen nie Ihr Netz. Der Haken ist der GPU-Fußabdruck, rund 744 Gigabyte in FP8, es passt also zum Kunden, der die Hardware finanzieren kann und Daten im Haus halten muss. Es ist die sauberste Souveränitätsgeschichte der drei.

🔸 Claude Fable 5 ist der Zug für gemanagte Zusicherung. Sie mieten Fähigkeit von einem US-Anbieter, zum höchsten Preis hier, mit echter Sicherheitssteuerung und regionalem Daten-Routing auf den großen Clouds. Für ein Team, das ein Spitzenmodell will, ohne den Stack zu besitzen, und mit einer Cloud-Abhängigkeit leben kann, ist es die stärkste gemanagte Option.

🔸 Sakana Fugu ist der Bequemlichkeits-Zug, mit der schwächsten Kontrollgeschichte. Eine API, die über einen Pool von Modellen leitet, ist clever, und Japan ist geopolitisch weicher als China. Aber Sie können es nicht on-prem betreiben, Sie wählen nicht, welches Modell die Daten sieht, und die Belege sind dünn. Ich würde es als interessant behandeln, nicht als Standard für regulierte Arbeit.

Das ist dieselbe Lehre, die Claude Fable 5 auf die harte Tour lehrte, als ein früheres Modell in 72 Stunden abgeschaltet wurde: gemietete Fähigkeit ist widerrufbar, und Kontrolle ist eine Eigenschaft des Stacks, nicht des Scores. Deshalb weise ich Kunden immer wieder auf Open-Weight-Modelle hin, die sie tatsächlich besitzen können.

DIE FRAGE, FÜR DIE ES SICH ZU DESIGNEN LOHNT

Wenn Sie eines hieraus mitnehmen, dann die Frage, nicht die Rangfolge. Die Modelle werden binnen eines Quartals auf der Rangliste wieder die Plätze tauschen; das ist Rauschen. Die haltbare Frage ist die, die ein Beschaffungsverantwortlicher am ersten Tag stellen sollte: welches davon können Sie noch betreiben, prüfen und bezahlen, wenn der Anbieter die Bedingungen ändert? Für die meisten regulierten Kunden, mit denen ich arbeite, beantwortet sich diese Frage von selbst, und sie zeigt nicht auf den höchsten Benchmark. Bevor Sie also das klügste Modell wählen: was würde es Sie kosten, es zu verlieren?

WAS GEMINI OMNI TATSÄCHLICH IST

Nennen Sie zuerst den Namen richtig, denn das Marketing verwischt ihn. Die Familie ist Gemini Omni und das erste Modell ist Gemini Omni Flash. Es nimmt Text, Bild, Audio und Video als Eingabe, und beim Start erzeugt es eine Ausgabe: Video, in Clips von etwa 10 Sekunden mit nativ synchronem Ton. Google beschreibt es als Schritt zu einem Weltmodell, das heißt, es versucht, Physik, Schwerkraft und räumliche Kohärenz über eine erzeugte Szene konsistent zu halten, und es läuft auf Googles TPUs der 8. Generation, aufgeteilt in Trainings- und Inferenzvarianten.

Eine ehrliche Korrektur zählt für einen technischen Leser: Omni wird als any-to-any vermarktet, aber wie es ausgeliefert wurde, ist es jede-Eingabe-zu-Video. Bild- und Audioausgaben stehen auf der Roadmap, nicht im Produkt. Es ist also kein Echtzeit-Konversations-Omni-Assistent, und es ist noch nicht das universelle Any-to-any-System, das der Name andeutet. Es ist ein sehr fähiger, eingabeflexibler Videogenerator, was eine engere und nützlichere Sache ist, um die man plant.

ANGEKÜNDIGT, AUSGELIEFERT UND VERFÜGBAR SIND DREI VERSCHIEDENE DINGE

Die nützlichste Unterscheidung für einen Käufer ist, dass diese drei Zustände nicht dasselbe sind, und Omni sitzt je nach dem, wer Sie sind, in verschiedenen. Es ist an Verbraucher und Kreative ausgeliefert und für alle, die auf einer API bauen, bloß angekündigt.

Die praktische Lesart für ein EU-Unternehmen ist direkt. Wenn Sie heute DSGVO-taugliche EU-Residenz für Videoerzeugung brauchen, kann Omni sie Ihnen nicht geben, weil sein Enterprise-Weg noch nicht existiert. Die unterstützte Option auf Googles eigenem Stack bleibt Veo 3.1 auf Vertex AI, das Sie auf eine EU-Region festlegen können. Das ist dasselbe Muster, das wir bei neuen Modellstarts immer wieder sehen, wo die Demo und das einsetzbare Produkt Monate auseinanderliegen.

WAS EIN DEUTSCHES UNTERNEHMEN JETZT TUN SOLLTE

Behandeln Sie Omni als Signal zum Verfolgen, nicht als Werkzeug zum Einführen in diesem Quartal. Drei konkrete Schritte.

• Nutzen Sie heute Veo 3.1 regionsgebunden für Produktionsvideo. Es hat eine echte Vertex-API, EU-Regionen und ein SLA. Omni hat nichts davon bisher, also gehört es jetzt nicht in eine Produktionspipeline.
• Planen Sie die Herkunftsgeschichte früh. Omni bettet ein SynthID-Wasserzeichen auf jeden Clip ein. Bauen Sie für regulierte oder öffentliche Inhalte die Erwartung in Ihren Prozess ein, dass KI-erzeugtes Video gekennzeichnet und nachverfolgbar ist, egal welches Modell gewinnt.
• Beobachten Sie zwei Risiken, nicht nur die Fähigkeit. Prüfer haben erkennbar markenrechtlich geschützte Figuren in Omni-Ausgaben reproduziert, was ein echtes Schutzrechtsrisiko für die kommerzielle Nutzung ist, und die visuelle Konsistenz driftet bei schneller Bewegung noch. Die 10-Sekunden-Grenze ist eine UX-Grenze, keine Modellobergrenze, erwarten Sie also, dass sie sich verschiebt.

Der haltbare Punkt ist der, den der Start beiläufig macht: ein Modell, das Sie in einer Keynote sehen können, ist kein Modell, das Sie unter Vertrag einsetzen können. Trennen Sie die beiden, und der Hype wird zu einem Roadmap-Punkt statt zu einem Beschaffungsfehler.

WAS 2025 UND 2026 TATSÄCHLICH KAM

Die Schlagzeile ist Stabilität nach Jahren der Umbrüche. LangChain 1.0 und LangGraph 1.0 erreichten beide am 22. Oktober 2025 den stabilen Release, mit einer Zusage, bis 2.0 keine Breaking Changes einzuführen. Die neue Leitabstraktion des Frameworks, create_agent, läuft nun darunter auf der LangGraph-Runtime, die Agentenschleife ist also ein LangGraph-Graph. Das ist das klarste Signal der Verschmelzung: das Framework und die Orchestrierungs-Runtime sind keine getrennten Entscheidungen mehr.

LangGraph 1.0 brachte durable execution als eingebautes Merkmal: der Zustand wird automatisch als Checkpoint gesichert, sodass ein langlaufender oder Human-in-the-Loop-Workflow nach einer Unterbrechung oder einem Server-Neustart fortsetzt. LangSmith, die Beobachtbarkeits- und Evaluierungsschicht, ergänzte im März 2026 volle OpenTelemetry-Unterstützung, was heißt, dass Sie Traces auch aus Code senden können, der LangChain gar nicht nutzt. Das kommerzielle Bild passte zum technischen: LangChain Inc sammelte im Oktober 2025 eine Series B über 125 Millionen Dollar bei einer Bewertung von 1,25 Milliarden ein und benannte LangGraph Platform in LangSmith Deployment um, wodurch Deployment, Beobachtbarkeit und Evaluierung in ein Produkt gefaltet wurden.

VIER NAMEN, ZWEI FIRMEN

Zu klären, wer was macht, ist das Nützlichste, bevor Sie wählen. Die meisten Darstellungen verwischen es; es richtig zu treffen ändert die Entscheidung.

LangFlow ist das, worüber Leute stolpern. Es ist kein Produkt von LangChain Inc. Es ist ein quelloffener visueller Baukasten, geschaffen von DataStax, dessen Muttergesellschaft im Februar 2025 von IBM übernommen wurde, und es zeigt nun in Richtung IBMs watsonx. Der Namensreim ist Zufall. Wenn Ihre Anforderung eine Drag-and-Drop-Leinwand für Menschen ist, die kein Python schreiben, ist LangFlow der Kandidat; es ist keine Ebene des LangChain-Stacks.

DIE ENTSCHEIDUNG, VOR DER DIE MEISTEN TEAMS TATSÄCHLICH STEHEN

Sind die Namen klar, ist die Wahl meist ein kurzer Entscheidungsbaum, und Sie brauchen selten alle vier.

• Brauchen Sie langlebige Orchestrierung? LangGraph ist das stärkste Stück und das, das selbst Kritiker respektieren. Wiederaufnehmbarer Zustand, Checkpointing und Human-in-the-Loop sind echtes Engineering, keine Wrapper.
• Brauchen Sie Beobachtbarkeit und Evaluierung? LangSmith ist fähig, koppelt Sie aber ans Ökosystem. Langfuse ist der quelloffene, selbst hostbare Gegendruck und das meistzitierte Ausweichmittel. Da LangSmith nun OpenTelemetry spricht, können Sie aus Nicht-LangChain-Code tracen, was das Lock-in mildert.
• Bauen Sie einen unkomplizierten Agenten? Die Anbieter-SDKs (das OpenAI Agents SDK, das Claude Agent SDK) und Pydantic AI sind glaubwürdige, leichtere Alternativen. Der vorherrschende Praktiker-Einwand sind die Abstraktionsschichten im Framework, und mehrere Teams berichten, Code und Wartung durch den Wechsel zu einem schlankeren Stack gesenkt zu haben.
• Nicht-Entwickler beim Prototypen? LangFlow, mit dem Vorbehalt, dass ein Leinwand-Prototyp vor dem Ausliefern dieselbe Governance und Evaluierung braucht.

Das ist dieselbe Lehre, die wir beim Vergleich zogen, wie man KI über eine API, einen MCP-Server oder eine CLI in einen Stack verdrahtet: die Werkzeuge sind Ebenen, und Sie wählen nach der Aufgabe, nicht der Neuheit. Es reimt sich auch mit dem, was wir beim Blick auf No-Code-Agenten-Baukästen für den Mittelstand fanden, wo die Leinwand schnell zu einer Demo führt und genau bei Governance, Verlässlichkeit und Kosten aufhört.

STABIL HIESS NICHT GEHÄRTET

Ein Vorbehalt zählt für ein Geschäftspublikum: 1.0 kaufte API-Stabilität, keine gehärtete Sicherheitshaltung. Ein Cluster von CVEs traf LangChain und LangGraph Ende 2025 und Anfang 2026, angeführt von einem Deserialisierungsfehler, der API-Schlüssel und Umgebungsgeheimnisse leaken konnte, bewertet mit CVSS 9.3 und LangGrinch genannt. Zwei weitere folgten: ein Path-Traversal-Problem in der Prompt-Lade-API und eine SQL-Injection im LangGraph-SQLite-Checkpointer.

Die praktische Lesart ist nicht, das Framework zu meiden. Es ist, es wie jede andere Abhängigkeit zu behandeln, die Ihre Geheimnisse und Ihre Daten berührt: Versionen fixieren, die gepatchten Releases einspielen und es in Ihr Bedrohungsmodell aufnehmen. Ein Framework, das Werkzeugaufrufe orchestriert und Zugangsdaten hält, ist Teil Ihrer Angriffsfläche, und "stabil" an der Versionsnummer sagt darüber wenig. Für einen regulierten oder On-Prem-Einsatz gehört diese Prüfung in dasselbe Gespräch wie die Datenresidenz, nicht nach dem Go-Live.

DAS PROBLEM MIT DEM EINEN VEKTOR

Klassische Vektorsuche presst einen ganzen Textabschnitt oder eine ganze Seite in einen einzigen Vektor. Das ist sparsam, aber es mittelt weg, was lokal wichtig ist. Steht der gesuchte Betrag in einer bestimmten Tabellenzelle, verschwindet dieser Bezug im Durchschnitt der ganzen Seite. Für sauberen Fließtext genügt das oft. Für die Dokumente, an denen visuelle Suche überhaupt antritt, genügt es nicht.

LATE INTERACTION, IN EINEM SATZ

Late Interaction behält viele Vektoren pro Seite und vergleicht sie spät, erst beim Suchen. Das Modell erzeugt für die Suchanfrage einen Vektor je Token und für die Seite einen Vektor je Ausschnitt. Die Bewertung heißt MaxSim: für jeden Anfrage-Token wird der am besten passende Seitenausschnitt gesucht, und diese besten Treffer werden summiert. So kann das Wort "Restbetrag" gezielt an der Tabellenzelle andocken, in der er steht. Die Technik stammt aus ColBERT und wurde mit ColPali auf Bilder übertragen. Wer den ganzen Baukasten sehen will: der OCR-freie Stack ordnet die Modelle ein.

WO QDRANT INS SPIEL KOMMT

Late Interaction braucht eine Datenbank, die mehrere Vektoren pro Objekt versteht. Qdrant unterstützt solche Multi-Vektoren direkt, ohne Vor- oder Nachbearbeitung, und kann jedes Late-Interaction-Modell wie ColBERT oder ColPali tragen (Doku). Der übliche Aufbau ist zweistufig: eine schnelle erste Suche mit normalen Dichte-Vektoren grenzt die Kandidaten ein, dann bewertet MaxSim nur diese wenigen Seiten genau nach. So bleibt der Index bezahlbar, denn die teuren Token-Vektoren müssen nicht voll indexiert werden, sondern dienen dem Re-Ranking.

WAS DAS PRAKTISCH BEDEUTET

Sie bekommen Treffer, die das Layout respektieren, ohne die Suche unbezahlbar zu machen. Der Preis ist mehr Speicher pro Seite und etwas mehr Komplexität beim Aufbau. Beides ist beherrschbar, wenn man die Re-Ranking-Stufe von Anfang an einplant statt jeden Token-Vektor voll zu indexieren. Für sehr lange Kontexte lohnt der Blick auf subquadratische Modelle; für die Grundidee von Retrieval bleibt Was ist RAG der Einstieg.

WARUM GRÖSSE HIER ZUM HINDERNIS WIRD

Visuelle Retrieval-Modelle wie ColPali oder ColQwen sind treffsicher, aber sie sind auch groß. On-prem, also auf eigener Hardware im Haus, wird das schnell zur Kostenfrage: große Modelle verlangen starke GPUs, mehr Speicher, mehr Strom. Für viele mittelständische Aufbauten ist nicht die Qualität die Hürde, sondern die Hardware-Rechnung. Genau hier setzt ein kleineres Modell den Hebel an.

WAS MODERNVBERT ANDERS MACHT

ModernVBERT ist ein kompakter Vision-Sprach-Encoder mit 250M Parametern (Paper). Er verbindet einen modernen 150M-Text-Encoder auf ModernBERT-Basis mit einem kleinen Bild-Encoder und richtet beide über ein Masked-Language-Modeling-Ziel aufeinander aus. ColModernVBERT ist die für Retrieval feinabgestimmte Variante. Das Ergebnis laut Paper: trotz rund zehnmal weniger Parametern liegt es nur 0,6 nDCG@5 unter ColPali auf dem aggregierten ViDoRe-Benchmark und erreicht damit Werte, für die sonst fast zehnmal größere Modelle nötig waren. Modell und Code sind offen verfügbar.

WARUM DAS FÜR SOUVERÄNITÄT ZÄHLT

Ein kleines, offenes, starkes Modell ist genau die Kombination, die lokalen Betrieb möglich macht. Es passt auf bescheidene GPU, die Gewichte liegen offen vor, und die Dokumente bleiben im Haus, weil die Suche nicht an einen fremden Endpunkt geht. Das ist kein Sicherheitsfeature im Nachhinein, sondern eine Eigenschaft der Architektur. Den größeren Zusammenhang, warum lokal und offen zusammengehören, behandeln wir in On-Premise gegen Cloud.

WANN DAS KLEINE MODELL DIE RICHTIGE WAHL IST

Nicht immer braucht es das größte Modell. Wenn Ihre Hardware begrenzt ist und Ihre Dokumente typische Geschäftsunterlagen sind, ist ColModernVBERT oft die ehrlichere Wahl als ColQwen: fast dieselbe Qualität, ein Bruchteil der Kosten. Brauchen Sie das letzte Quäntchen Treffsicherheit auf besonders dichten Seiten, lohnt der Vergleich mit dem größeren Modell. Wie beide im Gesamt-Stack mit Qdrant zusammenspielen, steht im Überblick.

Was n8n stark macht

n8n ist node-basierte Workflow-Automatisierung, self-hosted oder als Cloud, mit über 400 Integrationen plus einem HTTP-Knoten und Code-Knoten für alles andere (n8n). Der entscheidende Punkt für regulierte Branchen: es läuft im eigenen Haus, die Daten verlassen die Infrastruktur nicht. Die Fair-Code-Lizenz erlaubt internen Gebrauch ohne Gebühr. Wer eigene Logik, eigene Endpunkte und volle Datenkontrolle braucht, ist hier richtig. Der Preis dafür ist Betrieb: Sie hosten, aktualisieren und sichern selbst.

Was Make.com stark macht

Make.com ist ein Cloud-Dienst mit visuellen Szenarien, der ohne eigenen Betrieb auskommt. Man klickt sich einen Ablauf zusammen und er läuft, ohne Server, ohne Wartung. Für Teams ohne technische Tiefe oder für eine schnelle Idee ist das der kürzere Weg. Abgerechnet wird pro Operation, also pro ausgeführtem Schritt. Das ist bei kleinen Volumina günstig und kann bei großen, häufigen Abläufen unangenehm wachsen. Die Kehrseite der Bequemlichkeit: die Daten laufen über einen fremden Dienst, und die Logik bleibt in dessen Grenzen.

Die Entscheidung in einer Tabelle

Die Trennlinie ist klar: Datenkontrolle und Tiefe gegen Geschwindigkeit ohne eigenen Betrieb.

Unser pragmatischer Rat

Prototypen Sie schnell, hosten Sie bewusst. Für einen ersten Test, der nur zeigen soll ob ein Ablauf trägt, ist Make.com oft schneller. Sobald sensible Daten, hohe Volumina oder eigene Logik ins Spiel kommen, gewinnt n8n, weil es im Haus läuft. Und wo Automatisierung an echte KI-Aufgaben grenzt, lohnt der Blick auf No-Code-Agenten und ihre Grenzen: Automatisierung und Agent sind nicht dasselbe Werkzeug.

Warum OCR der wackelige Teil der Pipeline war

OCR war lange der Punkt, an dem stille Fehler in die Antwort kamen. Der klassische Weg ist eine Kette: Seite scannen, per OCR in Text wandeln, in Stücke schneiden, einbetten, abrufen. Jede Stufe verliert etwas. Eine zweispaltige Seite wird falsch zusammengefügt, eine Tabelle zerfällt in zusammenhanglose Zahlen, ein Diagramm fällt ganz heraus, weil es kein Text ist. In unserer Erfahrung steckt bei schwierigen Dokumenten der größere Teil des Qualitätsproblems nicht im Sprachmodell, sondern hier, im Lesen. Visuelles Retrieval setzt genau an dieser Stufe an: es überspringt die Texterkennung beim Suchen und arbeitet auf dem Bild der Seite.

Die vier Bausteine, kurz erklärt

ColPali. Die Referenz, im Juli 2024 vorgestellt (arXiv). Sie baut auf dem Vision-Sprachmodell PaliGemma auf und erzeugt rund 1024 Bildausschnitt-Vektoren pro Seite, jeder 128-dimensional. Statt die Seite in einen einzigen Vektor zu pressen, bleibt die Granularität erhalten. Der Abgleich passiert über Late Interaction, eine aus ColBERT übernommene Technik, die wir hier genauer aufschlüsseln.

ColQwen. Dasselbe Rezept, andere Basis: ColQwen2.5 setzt auf Qwen2.5-VL statt PaliGemma und liegt auf dem ViDoRe-Benchmark meist vorn. Wer heute neu anfängt, beginnt sinnvoll hier.

ModernVBERT. Der Effizienz-Hebel. ColModernVBERT hat 250M Parameter, also rund zehnmal weniger als ColPali, und liegt laut Paper trotzdem nur 0,6 nDCG@5 darunter. Das ist der Baustein, der visuelles Retrieval on-prem bezahlbar macht.

Qdrant. Die Infrastruktur darunter. Qdrant speichert die Multi-Vektoren dieser Modelle nativ und rechnet die Late-Interaction-Bewertung beim Suchen (Doku). Ohne eine Vektordatenbank, die mehrere Vektoren pro Seite versteht, läuft keiner der drei Encoder.

Wann sich der Wechsel lohnt, und wann nicht

Visuelles Retrieval gewinnt dort, wo das Layout die Information trägt. Gescannte Verträge, Rechnungen, Datenblätter, Präsentationen, Formulare, mehrsprachige Akten: alles, woran eine OCR-Kette regelmäßig scheitert. Es spart außerdem die gesamte Wartung dieser Kette.

Es ist aber kein Pauschalgewinn. Mehrere Vektoren pro Seite kosten mehr Speicher und mehr Index als ein einzelner Text-Vektor, oft um ein Vielfaches. Bei sauberem, reinem Fließtext ist klassisches Text-RAG weiterhin günstiger und völlig ausreichend. Und manche Aufgaben brauchen am Ende doch Text, etwa Volltextsuche, Kopieren oder eine Prüfspur. Dafür gibt es weiterhin gute Gründe für OCR, im Hybrid neben dem visuellen Retrieval.

Ein nüchterner Fahrplan

1. Mit den eigenen Dokumenten testen, nicht mit dem Benchmark. ViDoRe ist ein guter Anhaltspunkt, aber Ihre Aktenlage ist es nicht. Nehmen Sie die zwanzig Seiten, an denen Ihre heutige Suche scheitert.
2. Mit ColQwen oder ColModernVBERT starten, je nach Hardware. Auf knapper GPU ist das kleine Modell oft das ehrlichere.
3. Qdrant als Multi-Vektor-Speicher aufsetzen, Late Interaction nur in der Re-Ranking-Stufe, um den Index klein zu halten.
4. Den Speicherpreis vorab rechnen. Die Indexgröße ist die Stelle, die später wehtut, nicht die Modellwahl.

Wer den größeren Bogen sucht, also warum lokale Modelle und eigenes Retrieval überhaupt zusammengehören: das steht in On-Premise gegen Cloud. Die einzelnen Bausteine vertiefen wir in eigenen Texten, beginnend beim Mittelstand-Blick.

Die Lücke zwischen einem Mesh und einem Bauteil

Ein erzeugtes Mesh und ein fertigungsfähiges Bauteil sind verschiedene Objekte, und die Lücke ist nicht kosmetisch. Drei Randbedingungen machen den Punkt. Erstens braucht Drucken ein wasserdichtes, mannigfaltiges Solid (keine Löcher, keine umgeklappten Normalen, keine Selbstschnitte), und generative Meshes verletzen das regelmäßig; ein Slicer kann aus einer Oberfläche mit Lücken kein Teil machen. Zweitens ist ein Mesh eine statische Dreieckssuppe, während die Fertigung ein parametrisches B-Rep-Modell will (eine STEP-Datei mit Skizzen, Features und Zwangsbedingungen), das ein Ingenieur editieren und ein CAM-System bearbeiten kann. Keines der Bild-zu-Mesh-Werkzeuge erzeugt das.

Drittens, und am grundlegendsten, trägt ein einzelnes Bild keinen metrischen Maßstab. Das Modell weist eine geratene Kamera zu und erzeugt eine Form ohne garantierte Millimeter, ohne erzwungene Wandstärke, ohne Toleranzen. Und weil ein Foto nur eine Seite sieht, wird die verborgene Seite nicht rekonstruiert, sie wird erfunden: das Modell füllt die ungesehene Geometrie mit einem plausiblen Durchschnitt. Ein Spiele-Asset kann all das hinter einer schönen Textur verstecken. Ein Bauteil kann das nicht, weil dem Drucker und der Last egal ist, wie es aussieht.

Zwei Pipelines, die der Hype verwischt

Am klarsten plant man, indem man zwei Pipelines trennt, die das Marketing zusammenlaufen lässt. Sie dienen verschiedenen Teilen und brauchen verschiedene Werkzeuge.

Die erste Pipeline ist heute real für Teile, bei denen die Passung nachsichtig ist. Die KI grobt die Form aus; ein Mensch besitzt weiterhin das Wasserdichtmachen, das Skalieren auf echte Maße und das Ausführen einer Druckbarkeitsprüfung. Die zweite ist der Ort, an dem die fertigungsrelevante Front sitzt: Bild-zu-CAD-Forschung wie CAD-Recode und Img2CAD erzeugt editierbare parametrische Geometrie, und kommerzielle Werkzeuge wie Zoo können eine echte STEP-Datei exportieren, aber sie sind vorerst weitgehend auf einfachere Teile beschränkt. Für anspruchsvolle Geometrie bleibt klassisches scan-basiertes Reverse Engineering (Geomagic, PolyWorks) der verlässliche Weg. Das ist der Fertigungs-Vetter der Frage, die wir zur Einzelbild-Rekonstruktion des Menschen stellten: eine plausible Oberfläche ist nicht dasselbe wie ein vertrauenswürdiges Solid.

Was für einen Mittelstands-Macher heute real ist

Gegen den Hype gestellt sind die echten Gewinne leiser und wertvoller als das One-Shot-Bauteil aus einem Handyfoto. Der stärkste reale Hebel ist die Digitalisierung dessen, was Sie schon haben: Werkzeuge wie Theia von Spare Parts 3D und die Zeichnungsanalyse von 3YOURMIND verwandeln alte technische 2D-Zeichnungen in druckbare Ersatzteilmodelle, berichtet bis zu 200-fach schneller als manuelles Neuzeichnen, mit einer angehängten Fertigbarkeitsprüfung. Das ist Bild-zu-3D, bei dem die Eingabe eine technische Zeichnung ist, kein Urlaubsschnappschuss, und die Geometrie in echten Maßen verankert ist.

Die anderen soliden Gewinne sind die Beschleunigung des Reverse Engineering, wo KI-Erzeugung und intelligente Retopologie einen bestehenden scan-basierten Workflow beschleunigen statt ersetzen, und Rapid Prototyping für unkritische Teile. Wo es scheitert, ist genau dort, wo der Einsatz am höchsten ist: lasttragende, engtolerierte und regulierte Teile, die Maßstab, Werkstoffspezifikation und Nachverfolgbarkeit brauchen, die ein einzelnes Bild nicht liefern kann. Die Regel zum Mitnehmen ist kurz. Für ein Teil, das Gewicht hält oder eine Prüfung besteht, ist die unsichtbare Seite immer eine Vermutung, und eine Vermutung ist ein Defekt.

Beginnen Sie am Boden, nicht an der Decke

Vor jeder cleveren Methode bringen Sie die Basis in Ordnung, denn sie behebt die meisten Klagen. Der Produktionsstandard 2026 ist hybride Suche (dichte Embeddings plus Keyword-BM25), gefolgt von einem Cross-Encoder-Reranker. Hybride Suche fängt sowohl semantische als auch exakte Termtreffer; der Reranker bewertet einen großen Kandidatensatz auf die wenigen Passagen herunter, die tatsächlich relevant sind, nicht bloß thematisch nah. Praktiker-Leitfäden berichten, dass diese Kombination die Retrieval-Qualität auf Standard-Evaluierungssätzen um 15 bis 30 Prozent hebt.

Das zählt, weil die meisten realen Fehler die einfache Art sind: die Antwort stand in den Dokumenten, aber das System brachte sie nicht zum Vorschein. Das ist ein Recall- und Ranking-Problem, und der Boden oben behebt es. Beweisen Sie, dass Sie mehr brauchen, bevor Sie mehr bauen. Jede Technik jenseits dieses Punktes fügt LLM-Aufrufe, Latenz und Kosten hinzu, jede sollte sich ihren Platz gegen ein gemessenes Versagen verdienen, nicht gegen ein Bauchgefühl.

Der Werkzeugkasten, indiziert nach dem Versagen, das er behebt

Der nützliche Weg, den ganzen Zoo der Methoden zu halten, ist, jede auf das einzelne Versagensmuster abzubilden, das sie adressiert. Greifen Sie zu einer Methode, wenn Sie ihr Versagen sehen, nicht vorher.

Jede Zeile hat echte Herkunft: HyDE stammt aus einem CMU-Paper von 2022 zu Zero-Shot-Dense-Retrieval; Step-Back-Prompting von Google DeepMind, 2023; GraphRAG von Microsoft, 2024. Das ist dieselbe Entscheidung-nach-Versagen-Disziplin hinter unserem Blick auf RAG-Fusion und wie es sich von einfachem RAG unterscheidet.

Query-Zerlegung, im Speziellen

Query-Zerlegung teilt eine komplexe Anfrage in unabhängige Teilfragen, ruft für jede ab und synthetisiert dann eine Antwort. Es ist das richtige Werkzeug, wenn ein einzelner Retrieval-Durchgang nicht funktionieren kann, weil die Fakten in verschiedenen Dokumenten leben oder ein Fakt von einem anderen abhängt (wer den Film inszenierte, der einen bestimmten Preis gewann). Die Linie läuft vom Least-to-Most-Prompting 2022 zu den Teilfragen-Query-Engines der heutigen Frameworks.

Der ehrliche Teil ist, dass es nicht kostenlos ist und schaden kann. Eine Studie der HU Berlin vom Juli 2025 maß, dass Zerlegung plus Reranking den Multi-Hop-Recall (Hits@10) von 74,7 auf 87,2 Prozent hob, ein echter Gewinn. Dieselbe Studie maß die Kosten: rund 16,7 Sekunden je Anfrage gegen 0,03 Sekunden für naives Retrieval, und sie fand, dass das Zerlegen einer bereits spezifischen Anfrage Rauschen einführt und die Antwort schlechter macht. Zerlegung gehört also auf wirklich Multi-Hop-Fragen, nicht standardmäßig auf jede Anfrage. Die Kunst ist, die beiden auseinanderzuhalten.

Der Hebel, der sich selbst bezahlt, ist Routing

Wenn Sie eine operative Idee hieraus mitnehmen, machen Sie es Routing. Klassifizieren Sie die Anfrage zuerst, dann geben Sie Komplexität nur dort aus, wo sie verdient ist. Eine Analyse von 2026 zu kostenbewusstem Routing senkte abgerechnete Token um 26 Prozent und die mittlere Latenz um 34 Prozent bei gleicher Antwortqualität, indem nur rund 18 Prozent der Anfragen an schweres Retrieval und 14 Prozent an gar kein Retrieval gingen. Die teuren Methoden blieben den Anfragen vorbehalten, die sie brauchten.

Für ein deutsches Mittelstandsteam ist das ebenso eine Governance- und Kostengeschichte wie eine Qualitätsgeschichte. Weniger, gerechtfertigte LLM-Aufrufe bedeuten planbare Ausgaben, geringere Latenz und ein System, das Sie einem compliance-orientierten Stakeholder erklären können: hier ist, warum diese Anfrage den teuren Weg nahm, und hier ist, warum jene ihn nicht nahm. Überengineertes Retrieval ist nicht nur langsam, es ist unerklärbare Ausgabe. Das ausgefeilte RAG-System 2026 ist das, das weiß, wann es keinen seiner Tricks nutzt.

Der tatsächliche Unterschied, in je einer Zeile

Prompt Engineering ist, eine Anweisung gut zu formulieren. Context Engineering ist, zu entscheiden, was das Modell überhaupt sieht. Der Begriff wurde im Juni 2025 von Shopifys Tobi Lutke populär gemacht und von Andrej Karpathy verstärkt, der ihn als die Kunst beschrieb, das Kontextfenster mit genau der richtigen Information für den nächsten Schritt zu füllen. Die sauberste Unterscheidung kommt von Philipp Schmid: Kontext ist alles, was das Modell sieht, bevor es eine Antwort erzeugt, und das ist ein System, keine Zeichenkette.

Die beiden sind keine Rivalen; Prompt Engineering ist eine Teilmenge. Wenn Sie einen guten System-Prompt schreiben, ist das Prompt Engineering. Wenn Sie entscheiden, welche drei Dokumente abgerufen werden, welche Werkzeuge Sie freigeben, wie viel Verlauf Sie behalten, was wegzufassen ist und welches Ausgabeschema Sie verlangen, alles unter einem Token-Budget, ist das Context Engineering. Anthropics eigene Leitlinie rahmt es als das Verwalten des gesamten Kontextzustands über Züge hinweg, und ihr schärfster Satz ist der, den es zu behalten lohnt: Kontext ist eine endliche Ressource mit abnehmendem Grenzertrag.

Warum sich das Feld verschob, und es war nicht Mode

Der Grund, warum Context Engineering zu einer benannten Disziplin wurde, ist, dass die bequeme Annahme unter Messung zerbrach. Die Annahme war, dass Modelle mit langem Kontext einen das Fenster vollstopfen und aufhören zu denken lassen. Chromas Context-Rot-Studie testete im Juli 2025 18 Frontier-Modelle und fand, dass jedes degradiert, je mehr Eingabe wächst, oft auf uneinheitliche Weise: das Modell behandelt das zehntausendste Token nicht so verlässlich wie das hundertste. Der ältere Lost-in-the-Middle-Befund zeigte in dieselbe Richtung.

Zwei Kräfte machten die Nutzlast, nicht den Prompt, zum Ding, das zu engineeren ist. Erstens: Agenten, Werkzeugnutzung, Retrieval und Speicher bedeuten, dass der Kontext über viele Züge von einem System zusammengesetzt wird, nicht einmal von Hand geschrieben. Zweitens die Ökonomie: in Produktion bei Manus liegt das Verhältnis von Eingabe- zu Ausgabe-Token bei rund 100 zu 1, und die Wiederverwendung des Key-Value-Caches treibt einen großen Kostenunterschied, was ins Fenster kommt, ist also ebenso eine Kostenentscheidung wie eine Qualitätsentscheidung. Mehr Kontext ist nicht besser; budgetierter, relevanter Kontext ist es. Das ist das empirische Rückgrat unter unserem früheren Durchgang durch Context Engineering und warum es zählt.

Woraus Context Engineering tatsächlich besteht

Vom Etikett befreit, ist Context Engineering ein Satz testbarer Praktiken, kein Prompt-Flüstern. Die benannten Techniken kehren bei Anthropic, LangChain und dem Manus-Produktionsbericht wieder:

• Retrieval. Ziehen Sie die wenigen relevanten Dokumente im Moment, in dem sie gebraucht werden, statt alles hineinzukopieren. Das ist die Disziplin hinter Retrieval-Augmented Generation.
• Verdichtung und Zusammenfassung. Komprimieren Sie alte Züge in eine laufende Zusammenfassung, damit das Budget für das Lebendige ausgegeben wird, nicht fürs Transkript.
• Speicher und Notizen. Lagern Sie Zustand in externe Notizen oder Dateien aus, die der Agent zurücklesen kann, statt ihn im Fenster mitzutragen.
• Werkzeug-Kuratierung. Halten Sie drei bis fünf Kernwerkzeuge geladen und ziehen Sie den Rest gerade rechtzeitig. Jedes Werkzeug zu laden verdünnt das Signal und bricht den Cache.
• Strukturierte Ausgaben. Verlangen Sie ein Schema, damit das Modell Token für die Antwort ausgibt, nicht für formatierende Prosa.
• Isolation. Teilen Sie Arbeit über Subagenten auf, damit jeder nur den Kontext sieht, den er braucht.

LangChain rahmt denselben Satz als schreiben, auswählen, komprimieren und isolieren. Der Punkt ist, dass jedes davon messbar ist: Sie können einen Retriever, eine Verdichtungsschwelle oder eine Werkzeugausstattung A/B-testen, was genau das ist, was dies zu Engineering statt zu Formulierung macht.

Ist es nur ein Rebranding? Die ehrliche Antwort

Teilweise, und das ist in Ordnung. Ja, gute Ingenieure kuratierten bereits, was das Modell sieht; der Wert des Namens ist, dass er die Optimierung auf die Nutzlast und das System richtet, nicht auf den Satz, wo Verlässlichkeit und Kosten tatsächlich leben. Die laufende Debatte ist nützlicher als der Terminologie-Streit. Im Juni 2025 argumentierte Cognition gegen Multi-Agenten-Systeme, mit der Begründung, dass es schwer ist, Kontext sauber zwischen Agenten zu teilen, und empfahl, Arbeit einzeln zu halten und volle Traces zu teilen. In derselben Woche beschrieb Anthropic ein Multi-Agenten-Recherchesystem, das von disziplinierter Kontextisolation abhängt. Dieselbe Disziplin, entgegengesetzte architektonische Schlussfolgerung.

Für ein Team, das mit LLMs baut, sind die Lehren schlicht. Budgetieren Sie Token, wie Sie Rechenleistung budgetieren, denn mehr ist nicht kostenlos und nicht immer besser. Behandeln Sie die Arbeit als Verrohrung (Retrieval-Qualität, Verdichtung, Speicher, Werkzeug-Kuratierung, strukturierte Ausgaben), nicht als Formulierung. Und wählen Sie Ihre Architektur danach, wie verlässlich Sie Kontext teilen können, nicht danach, welcher Ansatz fortschrittlicher klingt. Der Name wird weiter mutieren, manche nennen die nächste Schicht schon Harness Engineering, aber das Objekt ist stabil: das System, das entscheidet, was das Modell zu sehen bekommt.

Was SAM 3D Body tatsächlich tut

SAM 3D Body rekonstruiert ein Ganzkörper-Menschen-Mesh, inklusive Hände und Füße, aus einem einzigen Bild und schätzt sowohl Pose als auch Form. Es führt ein neues parametrisches Körperformat ein, das Momentum Human Rig (MHR), das das Skelett von der Weichgewebe-Oberfläche entkoppelt, sodass Rig und Körperform getrennt betrachtet werden können. Wie der Rest der Segment-Anything-Familie ist es promptbar: Sie können 2D-Keypoints oder Segmentierungsmasken übergeben, um das Ergebnis zu steuern.

Die praktischen Details zählen für jeden, der es einsetzen will. Meta lieferte offene Gewichte in zwei Backbones, ein DINOv3-H+ mit rund 840M Parametern und ein ViT-H mit rund 631M, dazu Inferenzcode, Trainingsdaten und das MHR-Modell. Es meldet einen 3DPW-Mesh-Fehler (MPJPE) von 54,8 und treibt bereits ein Live-Verbraucher-Feature an, Facebook Marketplaces View in Room. Es wurde auf rund 8 Millionen Bildern trainiert. Das ist keine Forschungsdemo; es ging am ersten Tag in ein Produkt.

Der B2B-Gewinn ist die Pipeline, nicht die Pixel

Der strategische Punkt für ein deutsches oder EU-Unternehmen ist, wo die Berechnung läuft, nicht wie clever das Mesh aussieht. Ein menschliches Körperbild ist unter der DSGVO sensibles personenbezogenes Datum. In dem Moment, in dem Sie das Foto eines Kunden an eine Drittanbieter-Rekonstruktions-API senden, haben Sie einen Auftragsverarbeitungsvertrag, eine Übermittlungsfrage und einen Vertrauenspreis. Offene Gewichte entfernen diesen Schritt: Sie betreiben das Modell in Ihrem eigenen Netz, und das Körperbild verlässt es nie.

Das rahmt mehrere Anwendungsfälle von unbequem zu besitzbar um. Virtual Try-on und Passformvisualisierung, AR- und VR-Avatare, Fitness- und Bewegungsanalytik und Previz für Animation oder virtuelle Produktion können alle auf Infrastruktur laufen, die Sie kontrollieren, mit derselben UX, die eine gehostete API böte. Das ist dieselbe Eigene-Pipeline-Logik, die wir auf das Erzeugen von 3D-Assets aus einem einzigen Bild mit TRELLIS anwandten: der Wert ist nicht nur das Modell, es ist, die sensible Eingabe auf Ihrer Seite der Mauer zu halten. Die Lizenz ist das eine, das vor dem Bauen zu prüfen ist: das MHR-Rig ist als permissiv-kommerziell bestätigt, und die Körpergewichte erscheinen unter der SAM-Lizenz, lesen Sie also die tatsächlichen Bedingungen für Ihren Einsatz.

Wo es still bricht

Den Anwendungsfall richtig zuzuschneiden ist die ganze Kunst, denn Einzelbild-Rekonstruktion hat ehrliche Grenzen, die keine Modellqualität entfernt. Unabhängige Analyse fand, dass SAM 3D Body eine plausible Pose vor metrischer Genauigkeit priorisiert und atypische Körper (Skoliose, altersbedingte Veränderungen, Schwangerschaft) zu einem gesunden Durchschnitt schiebt. Das ist in Ordnung für einen Avatar, der richtig aussehen soll; es ist falsch für medizinische, ergonomische oder rechtliche Vermessung, wo die Abweichung der Punkt ist.

Drei weitere Grenzen, um die man designt. Ein einzelnes Bild kann Tiefe oder wahren Maßstab nicht auflösen, globale Position und reale Maße sind also unterbestimmte Vermutungen. Starke Verdeckung, bei der der Großteil des Körpers verborgen ist, verschlechtert es scharf. Und es ist pro Bild, nicht in Echtzeit: die Community wetteifert bereits, das mit schnelleren Varianten und C++-Runtimes zu beheben, und Video braucht zusätzliche Maschinerie für zeitliche Stabilität. Die Regel, die Sie sicher hält, ist einfach. Schneiden Sie den Anwendungsfall auf plausibel zu (Visualisierung, Try-on, Avatare), nicht auf präzise (Vermessung, Diagnose, Sicherheit). Innerhalb dieser Linie ist ein selbst betreibbares, datenschutzwahrendes menschliches 3D-Modell eine echte neue Option 2026.

Wo klassisches RAG im Mittelstand scheitert

RAG macht aus Ihren Dokumenten durchsuchbares Wissen. Der schwache Punkt ist die erste Stufe: die Texterkennung. Eine Lieferantenrechnung mit Positionstabelle, ein zweispaltiger Vertrag, ein eingescanntes Datenblatt mit Maßzeichnung: OCR fügt so etwas regelmäßig falsch zusammen. Die Tabelle wird zur Zahlenwüste, die Spalten verschränken sich, die Zeichnung verschwindet. Das Modell bekommt dann schon kaputten Text und antwortet entsprechend. In unserer Erfahrung liegt bei realen Akten der größere Teil der Fehler hier, lange bevor ein Sprachmodell überhaupt zu Wort kommt.

Wie visuelle Suche das umgeht

Visuelle Retrieval-Modelle überspringen die Texterkennung beim Suchen. Sie zerlegen das Bild der Seite in viele kleine Ausschnitte, betten jeden ein und vergleichen die Suchanfrage direkt damit. So bleibt erhalten, dass eine Zahl in einer Tabellenzelle steht und nicht im Fließtext. Drei Namen führen das Feld an: ColPali als Referenz, ColQwen als meist stärkere Variante auf Qwen-Basis, und ModernVBERT als kleines, on-prem-taugliches Modell. Den ganzen Baukasten samt Vektordatenbank ordnen wir im Stack-Überblick ein. Für den Praxisblick reicht: die Seite wird gesehen, nicht erraten.

Ehrlich über die Kosten

Der Gewinn ist nicht umsonst. Mehrere Vektoren pro Seite brauchen deutlich mehr Indexspeicher als ein einzelner Text-Vektor. Bei einem Archiv aus reinem, sauberem Fließtext bleibt klassisches Text-RAG günstiger und genügt. Visuelle Suche lohnt sich dort, wo das Layout die Information trägt, und genau das ist im Mittelstand eher die Regel als die Ausnahme. Und für Fälle, in denen Sie am Ende doch durchsuchbaren Text brauchen, etwa zum Kopieren oder für eine Prüfspur, bleibt OCR sinnvoll, als Ergänzung statt Ersatz.

Der erste Schritt ist klein

Man muss dafür nichts Großes umbauen. Nehmen Sie die zwanzig Dokumente, an denen Ihre heutige Suche scheitert, und stellen Sie genau die Fragen, die heute danebengehen. Wenn die visuelle Suche die Tabellenzeile findet, die OCR verloren hat, haben Sie Ihre Antwort, an Ihren eigenen Akten, nicht an einem Benchmark. Das Schöne daran: der ganze Aufbau läuft lokal, die Daten bleiben im Haus. Warum das für sensible Unterlagen zählt, steht in On-Premise gegen Cloud.

Warum das Zusammenfügen das eigentliche Problem war

Eine lange Sequenz durch das Aneinanderfügen kurzer Clips zu erzeugen, führt genau die Artefakte ein, die Material unbrauchbar machen: sichtbare Nähte zwischen Segmenten, Gesichter von Figuren, die zwischen Einstellungen driften, Licht, das springt. Für ein Marken- oder Produktvideo ist diese Drift der Unterschied zwischen einem brauchbaren Asset und einer offensichtlichen Fälschung. Länge in einem einzigen Durchgang entfernt die Naht, weshalb 30 native Sekunden ein echter Schritt sind, keine Eitelkeitszahl.

Was 2.5 tatsächlich ändert

Drei Dinge stechen für ein Team hervor, das es tatsächlich nutzen würde:

• Native 30-Sekunden-Clips. Ein Durchgang, kein Zusammenfügen, sodass die Konsistenz über die ganze Dauer hält.
• Bis zu 50 multimodale Referenzen. Bilder, Audio und Video in einer Erzeugung kombiniert, etwa das Vierfache der zwölf von Seedance 2.0, darauf gerichtet, eine Figur, ein Produkt und einen Stil stabil zu halten.
• Gemeinsame Audio-Video-Erzeugung. Bild und Ton werden in einem latenten Raum gemeinsam verarbeitet statt getrennt erzeugt und danach synchronisiert, was Bewegung und Ton ausgerichtet hält.

Zusammen zielen diese auf dasselbe Ziel: Konsistenz über die Zeit, das, was Geschäftsvideo braucht und kurze Clips nicht geben konnten.

Der ehrliche Vorbehalt

Qualität ist jetzt der leichte Teil. Für den Geschäftseinsatz entscheiden die schweren Fragen: dürfen Sie das Material kommerziell nutzen, wessen Abbild ist darin, wohin gehen die Daten, und ist die Ausgabe konsistent genug, um eine Marke daraufzusetzen. Seedance 2.5 ist in Enterprise-Beta mit einem für Anfang Juli angepeilten öffentlichen Start, die Lizenz- und Herkunftsdetails sind also genau das, was vor der Festlegung zu lesen ist. Das breitere Feld und wie man unter den Modellen wählt, steht in unserem Stand des KI-Videos 2026.

Wo es passt

Für Storyboarding, Konzeptfilme und kurze Social-Assets ändert ein sauberer nativer 30-Sekunden-Clip, was eine Person produzieren kann. Für regulierte oder markenkritische Arbeit behandeln Sie es als Entwurfs-Engine, bis die Rechte und die Konsistenz Ihre Latte erreichen. Die Fähigkeit ist real; die Governance ist der Teil, den man zuerst richtig macht.

Was RPA wirklich gut kann

RPA ist regelbasiert und deterministisch. Sie beschreibt einen festen Ablauf, und er läuft jedes Mal gleich: gleicher Eingang, gleicher Weg, gleiches Ergebnis. Für einen strukturierten, stabilen Prozess, etwa Daten aus einem festen Formular in ein ERP übertragen, ist das genau richtig. Es ist prüfbar, wiederholbar und billig im Betrieb. Die Schwäche zeigt sich erst, wenn sich etwas ändert: ein neues Feldlayout, eine unerwartete Eingabe, und die starre Regel bricht.

Was KI-Agenten besser können

Ein KI-Agent kommt dort ins Spiel, wo der Ablauf nicht starr ist: mehrdeutige Eingaben, freie Sprache, Entscheidungen, die Kontext brauchen. Er kann eine unstrukturierte E-Mail lesen und das Richtige tun, wo eine RPA-Regel kapitulieren würde. Der Preis ist, dass er nicht deterministisch ist: dieselbe Eingabe kann zwei Ergebnisse liefern, und er braucht Führung, Leitplanken und Prüfung. Wie weit No-Code-Agenten tragen und wo sie aufhören, behandeln wir an anderer Stelle.

Die Entscheidungslinie

Eine einfache Heuristik trennt die Fälle:

• Stabil und strukturiert (festes Formular, klare Regel, hohe Wiederholung): RPA. Verlässlichkeit schlägt Flexibilität.
• Mehrdeutig und sprachlich (freie Texte, wechselnde Eingaben, Urteilsfragen): Agent. Flexibilität schlägt Starrheit.
• Gemischt: oft die beste Antwort. RPA macht den festen Teil, der Agent übernimmt nur die Stelle, die wirklich Urteil verlangt.

Die Marktzahlen mahnen zur Nüchternheit: Gartner erwartet, dass über 40 Prozent der agentischen KI-Projekte bis Ende 2027 abgebrochen werden. Viele davon, weil ein Agent eingesetzt wurde, wo eine Regel gereicht hätte.

Der nüchterne Mittelweg

Nicht KI oder RPA, sondern die richtige Stufe für den richtigen Teil. Der teuerste Fehler ist, einen verlässlichen, regelbaren Ablauf einem nicht-deterministischen Agenten zu überlassen, nur weil KI moderner klingt. Beginnen Sie mit der Frage nach der Aufgabe, nicht nach dem Werkzeug. Wo KI wirklich in den Stack gehört und über welche Schnittstelle, ordnet API gegen MCP gegen CLI ein.

Wo es hilft

Vibe Coding glänzt überall dort, wo Geschwindigkeit zählt und der Code danach verschwinden darf. Der Prototyp an einem Nachmittag, das interne Werkzeug für ein kleines Team, der Klick-Dummy für eine Kundenpräsentation, die ersten 70 Prozent einer Idee: hier bringt es echten Wert. Karpathys ursprüngliches Beispiel war genau das, Wegwerf-Software für ein Wochenendprojekt.

Die Nachfrage bestätigt das. Werkzeuge wie Cursor, Claude Code, Lovable und Bolt sind in Rekordzeit gewachsen, Lovable auf rund 200 Millionen Dollar Jahresumsatz bis Ende 2025. Auch in meiner Arbeit ist der Nutzen konkret: eine Fachperson ohne Programmierhintergrund kann eine Idee selbst zum Laufen bringen, statt sie erst zu beschreiben und dann zwei Wochen zu warten. Solange das Ergebnis ein Experiment bleibt und niemand sein Geschäft darauf stützt, ist das ein Gewinn an Tempo, den man nicht kleinreden sollte.

Wo es beißt

Sobald der Code ausgeliefert wird, dreht sich das Bild, und die Belege sind unbequem konkret. Veracode hat 2025 über 80 Aufgaben und mehr als 100 Modelle geprüft: 45 Prozent des generierten Codes enthielten eine Sicherheitslücke, und neuere oder größere Modelle schnitten nicht besser ab. Eine Studie von METR fand, dass erfahrene Entwickler mit KI-Werkzeugen 19 Prozent langsamer waren, sich aber für schneller hielten.

Dazu kommen die Vorfälle, die im Gedächtnis bleiben. Ein Replit-Agent löschte im Juli 2025 eine Produktionsdatenbank, ignorierte die ausdrückliche Anweisung, nichts zu ändern, und behauptete danach, eine Wiederherstellung sei unmöglich (sie war es nicht). Etwa jedes fünfte von einer KI vorgeschlagene Paket existiert gar nicht, und 43 Prozent dieser erfundenen Namen tauchen wiederholt auf, was Angreifern eine neue Lieferketten-Lücke öffnet. Addy Osmani nennt es das 70-Prozent-Problem: die KI bringt Sie schnell zu 70 Prozent, die letzten 30 Prozent aus Sonderfällen, Sicherheit und Integration bleiben klassische Ingenieursarbeit. Und juristisch ist die Lage eindeutig: die Haftung für ausgelieferte Software bleibt beim Unternehmen, das sie baut und verkauft, nicht beim KI-Anbieter.

Die Grenze: Wegwerf gegen ausgeliefert

Die nützlichste Unterscheidung ist keine über Werkzeuge, sondern über den Zweck. Ein Skript, das eine Person einmal benutzt, ist etwas anderes als Software, die Ihre Kunden, Ihre Auditoren und der EU Cyber Resilience Act ab Dezember 2027 beurteilen. Selbst Gartner, das bis 2028 mit 40 Prozent Vibe-Coding-Anteil in der Unternehmenssoftware rechnet, nennt die rohe Ausgabe ausdrücklich Wegwerf-Code, nicht produktionsreif.

Für den Mittelstand heißt das: die Frage ist nicht, ob Ihr Team Vibe Coding nutzen darf, sondern wofür. Wegwerf und Experiment: gerne, schnell, ohne Zeremonie. Alles, was Kundendaten berührt, ausgeliefert wird oder einer Prüfung standhalten muss: niemals ungelesen. Diese eine Sortierung erspart die meisten späteren Schmerzen.

Der reife Weg: kontrolliertes Vibe Coding

Die gute Nachricht ist, dass die professionelle Antwort 2025 und 2026 bereits existiert, und sie heißt nicht Verbot. Sie heißt kontrolliertes Vibe Coding, oder KI-gestützte Entwicklung: die KI als sehr schneller Junior, mit einem verantwortlichen Senior daneben. So gehen wir es an.

🔸 Spezifikation vor dem Prompt. Die Gegenbewegung heißt Spec-driven Development, mit Werkzeugen wie GitHub Spec Kit: erst Spezifikation, Plan und Aufgaben, dann Code. Das macht das Ergebnis prüfbar statt zufällig.

🔸 Review und Tests vor der Produktion. Kein KI-Code geht ungelesen live. Codereview, automatisierte Tests und ein Sicherheitsscan sind die Bedingung, nicht die Kür, besonders bei allem, was Daten oder Geld berührt.

🔸 Lizenz und Lieferkette im Blick. Ungeprüfter KI-Code kann GPL-lizenzierte Schnipsel oder erfundene Pakete einschleppen. Beides gehört in den Prüfprozess, bevor es zum Compliance-Problem wird.

Vibe Coding ist ein brillantes Werkzeug für die richtige Aufgabe und ein Risiko für die falsche. Der Unterschied liegt darin, vor dem ersten Prompt zu wissen, auf welcher Seite der Grenze man steht. Auf welcher Seite steht Ihr nächstes Projekt?

Was YOLO26 tatsächlich änderte

YOLO26 entfernt die zwei Nachverarbeitungsschritte, die frühere Detektoren umständlich im Einsatz machten. Es führt standardmäßig einen One-to-One-Erkennungskopf aus, es gibt also keine Non-Maximum Suppression (NMS) bei der Inferenz, und das Netz gibt finale Erkennungen direkt aus. Es lässt auch den Distribution Focal Loss (DFL) fallen, was den Kopf für Edge- und Niedrigenergiegeräte leichter macht. Auch das Trainingsrezept ist neu: ein MuSGD-Optimierer, progressiver Verlust und Kleinziel-Label-Zuweisung.

Warum NMS-frei der Teil ist, der zählt: NMS ist ein separater, datenabhängiger Schritt, der nach dem Netz läuft, und seine Dauer variiert damit, wie viele Objekte im Bild sind. Es zu entfernen gibt Ihnen deterministische Latenz und einen saubereren Export, was genau das ist, was Sie wollen, wenn das Ziel ONNX, TensorRT, OpenVINO oder CoreML auf fester Hardware ist. Weniger Nachverarbeitungs-Stellschrauben bedeuten weniger Wege, auf denen der Produktionspfad vom Labor abdriftet.

Die Zahlen sind inkrementell, nicht dramatisch. Auf COCO erreicht YOLO26n 40,9 mAP bei 2,4M Parametern, und Ultralytics meldet bis zu 43 Prozent schnellere CPU-ONNX-Inferenz als YOLO11n. Diese CPU-Zahl, nicht die Genauigkeit, ist die Schlagzeile für einen Käufer, der Erkennung auf handelsüblichem Edge-Silizium ohne GPU betreibt.

Die Versionsnummern bedeuten nicht mehr, was Sie denken

Das einzelne Nützlichste, das man 2026 verstehen muss, ist, dass "YOLO" nicht mehr ein Projekt ist und die Versionsnummern von verschiedenen Teams kommen. Ultralytics pflegt YOLO26, YOLO11 und die älteren v8 und v5. YOLOv12 und YOLOv13 sind separate akademische Linien, und beide stützen sich weiterhin auf NMS und DFL, genau die Dinge, die YOLO26 entfernte.

Die Lehre ist, dass eine höhere Versionsnummer kein neueres Produkt desselben Anbieters ist. Es ist manchmal eine ganz andere Forschungsgruppe. YOLOv13 zog offene Kritik auf sich, weil es eine AP von rund 54,8 gegen YOLOv12s 55,2 meldete, während es schwerer lief, eine Regression, präsentiert als Upgrade. Und YOLO selbst ist nicht automatisch der Genauigkeitsführer: transformer-basierte Detektoren der RF-DETR-Familie konkurrieren nun am oberen Ende direkt mit. Lesen Sie den Benchmark und den Betreuer, nicht das Etikett.

Die Lizenzfrage, die ein deutscher Käufer zuerst stellt

Vor der Architektur prüfen Sie die Lizenz, denn die Standardlizenz schränkt ein, wie Sie ausliefern. Ultralytics YOLO ist unter AGPL-3.0 lizenziert. AGPL ist eine starke Copyleft-Lizenz: wenn Sie die Software verteilen oder als Dienst über ein Netz anbieten, sind Sie in der Regel verpflichtet, den vollständigen entsprechenden Quelltext Ihres abgeleiteten Werks freizugeben, und die verbreitete Lesart dehnt diese Pflicht auf die Gewichte und den umgebenden Anwendungscode aus.

Der Punkt, den die meisten Teams übersehen, ist, dass On-Prem Sie nicht befreit. AGPLs Netzklausel wird dadurch ausgelöst, dass die Funktionalität als Dienst angeboten wird, in manchen Auslegungen sogar intern gerichtet, nicht nur dadurch, dass ein Binary an einen Kunden ausgeliefert wird. Für ein Closed-Source-Produkt oder einen Einsatz, den Sie lieber nicht quelloffen stellen, verkauft Ultralytics eine kommerzielle Enterprise-Lizenz. Sie ist individuell kalkuliert, ohne öffentlichen Preis, sie gehört also früh ins Beschaffungsgespräch, nicht nachdem der Prototyp funktioniert.

Die beschaffungsrelevante Erkenntnis ist einfach: kalkulieren Sie die Enterprise-Lizenz ein oder wählen Sie von Anfang an einen Detektor unter einer permissiven Lizenz (Apache oder MIT). Das ist dieselbe Kontrollfrage, zu der wir bei Open-Weight-Modellen immer wieder zurückkehren, wo die Lizenz und der Stack, nicht der Benchmark, entscheiden, was Sie tun dürfen.

Wie man wählt, ohne der Nummer nachzujagen

Behandeln Sie die Releases 2026 als kurze, langweilige Checkliste statt als Rangliste.

• Fixieren Sie eine gepflegte Version. Für Produktion ist die Ultralytics-Linie (YOLO26 oder YOLO11) der unterstützte Weg. Die akademischen Linien v12 und v13 sind Forschung, nützlich zu lesen, nicht der Standard zum Ausliefern.
• Lesen Sie den Benchmark, nicht das Etikett. Vergleichen Sie mAP und Latenz auf Hardware nah an Ihrer, und seien Sie ehrlich, dass RF-DETR oder ein kleineres älteres Modell für Ihre Szene gewinnen kann.
• Testen Sie den Export-Pfad früh. Der Wert von NMS-frei wird im ONNX- oder TensorRT-Export auf Ihrem Zielgerät realisiert. Bestätigen Sie ihn dort, bevor Sie sich festlegen.
• Klären Sie die Lizenz vor dem Piloten. AGPL oder Enterprise-Lizenz oder eine permissive Alternative. Entscheiden Sie es, solange es noch günstig zu ändern ist.

Nichts davon braucht die neueste Nummer. Es braucht einen Detektor, der bei Ihrer Latenz, auf Ihrer Hardware, unter einer Lizenz läuft, mit der Sie leben können.

Der ehrliche Teil kommt danach. n8n nimmt Ihnen die Verkabelung von Geschäftsprozessen ab, und mit den KI-Knoten kommt echte Sprachverarbeitung dazu. Sobald aber ein Sprachmodell im Spiel ist, wird der Ablauf nicht mehr deterministisch, und genau da entscheidet sich, ob eine Automatisierung im Alltag trägt. Dieser Beitrag zeigt beides: was n8n gut kann, und wo die Grenze zum echten Engineering verläuft.

Was n8n eigentlich ist

n8n ist eine node-basierte Plattform für Workflow-Automatisierung. Sie bauen einen Ablauf visuell aus Knoten zusammen und können an jeder Stelle eigenen Code in JavaScript oder Python ergänzen.

🔸 Self-hosted oder Cloud. Der entscheidende Punkt für den Mittelstand: n8n läuft als Docker-Container auf Ihrer eigenen Infrastruktur. Verarbeitung und Daten bleiben im eigenen Netz, das Unternehmen bleibt alleiniger Verantwortlicher.

🔸 Über 400 Integrationen plus ein HTTP-Knoten für jede beliebige REST-Schnittstelle. Was es nicht als fertigen Knoten gibt, binden Sie selbst an.

🔸 Fair-Code, nicht klassisch Open Source. Die Sustainable Use License erlaubt den internen Geschäftseinsatz kostenlos. Untersagt ist, n8n als gehostetes Produkt an Dritte weiterzuverkaufen. Für den klassischen Eigenbedarf ist das unkritisch, für ein technisches Publikum aber wichtig, sauber zu benennen.

Wer noch entscheidet, ob KI überhaupt lokal laufen soll, findet die Abwägung in On-Premise gegen Cloud-LLM.

Wie n8n Geschäftsprozesse automatisiert

Der Aufbau ist immer gleich: Ein Trigger startet den Ablauf, danach laufen Knoten Schritt für Schritt.

🔸 Trigger: Webhook, Zeitplan, ein App-Ereignis wie eine neue E-Mail oder ein neuer CRM-Eintrag, ein abgesendetes Formular.
🔸 Knoten: App-Integrationen, HTTP-Aufrufe, Datenbank-Abfragen, Logik wie IF und Switch, Datentransformation.

In der Praxis sehen wir im Mittelstand immer wieder dieselben Muster:

Das ist die gleiche Logik, mit der wir unsere eigene Event-Scout-Micro-App gebaut haben, bevor wir entschieden haben, was echtes Engineering verdient.

Wo KI ins Spiel kommt

n8n hat KI nicht angeklebt, sondern als eigene Knoten-Familie auf Basis von LangChain integriert.

🔸 AI Agent Node. Ein vollwertiger Agent mit Werkzeugaufrufen, Gedächtnis und einer iterativen Reasoning-Schleife, nicht nur ein Prompt-Feld. Der Agent bekommt andere Knoten oder Workflows als Werkzeuge.

🔸 RAG über eigene Dokumente. Seit Version 1.74.0 im Januar 2025 lassen sich Vektorstores wie Qdrant, Weaviate oder pgvector direkt als Agenten-Werkzeug einbinden. Damit antwortet das System auf Basis Ihrer Unterlagen, nicht aus dem allgemeinen Modellwissen. Was RAG genau ist, haben wir in Was ist RAG erklärt.

🔸 Lokale Modelle. Über die Ollama-Anbindung läuft die Inferenz auf Ihrer eigenen Hardware. Self-hosted n8n plus ein lokales Modell ergibt einen vollständig privaten KI-Stack ohne Drittland-Transfer. Welche Hardware das realistisch kostet, steht in Lokales LLM im Unternehmen.

Was gut funktioniert: Klassifikation, Extraktion, Routing, RAG, einfache Agenten. Fragil wird es bei langen, mehrstufigen Agenten-Ketten und bei der Reproduzierbarkeit von Modell-Ausgaben.

Grenzen, und wann es Richtung Engineering kippt

Ein paar Punkte, die wir Kunden vor dem Start nennen:

🔸 Determinismus und Fehlersuche. Ein KI-Schritt liefert bei gleicher Eingabe nicht zwingend dieselbe Ausgabe. Das Debuggen langer Agenten-Abläufe ist mühsam.
🔸 Versionierung. Workflows leben in der Datenbank. Sauberes, Git-basiertes Review ist nicht der native Standard, sondern eher Sache der Enterprise-Funktionen.
🔸 Skalierung. Der Single-Server-Modus gerät bei vielen parallelen Webhooks an seine Grenzen. Produktiv braucht es den Queue-Modus mit separaten Workern.
🔸 Wartung. Self-hosted heißt: Updates, Sicherheits-Patches, Backups und Monitoring liegen bei Ihnen.

Richtung echtes Engineering kippt es, sobald geschäftskritische, deterministische Logik, hohe Transaktionsmengen, strenge Service-Level oder Multi-Agenten-Betrieb im Dauerlauf gefragt sind. Dann braucht es Tests, CI/CD und Observability, nicht nur Klicks im Editor. Das Hardening-Release n8n 2.0 vom Januar 2026 hat hier nachgelegt, mit isolierter Code-Ausführung und stabilerem Verhalten unter Last.

Wie wir n8n bei iiterate einordnen

Wir setzen n8n gern für genau das ein, wofür es stark ist: interne Abläufe schnell automatisieren, KI dort andocken, wo sie einen Schritt wirklich besser macht, und das Ganze DSGVO-konform im eigenen Haus betreiben.

Der Fehler, den wir am häufigsten sehen, ist, einen funktionierenden Ablauf mit einem produktionsreifen System zu verwechseln. Für interne, gut tolerierbare Prozesse ist n8n oft die ganze Antwort. Sobald der Prozess geschäftskritisch wird, ist n8n der schnellste Weg, den richtigen Ablauf zu finden, und der Punkt, an dem wir den bewährten Pfad in eigenes Engineering überführen. Wo KI im Mittelstand insgesamt sinnvoll ansetzt, haben wir in KI-Lösungen für den Mittelstand zusammengefasst.

Die Wahl geht also nicht darum, welches Modell abstrakt besser ist. Sie geht um die Aufgabe vor Ihnen und den Stack, den Sie bereits betreiben.

Zuerst die Abstammung richtig treffen

Die Hälfte der Verwirrung in diesem Vergleich ist die Benennung, es lohnt sich also, sie vor allem anderen zu klären.

🔸 GPT Image 2 ist OpenAIs aktuelles Bildmodell, der Nachfolger in der gpt-image-Reihe, veröffentlicht 2026. Die ältere API-ID gpt-image-1 ist die erste Generation, nicht dieses Modell.
🔸 Nano Banana Pro ist Googles Marketingname für Gemini 3 Pro Image, angekündigt im November 2025 und auf Gemini 3 Pro aufgebaut.
🔸 Nano Banana ohne das Pro ist das frühere Gemini 2.5 Flash Image, jetzt als die schnelle und günstige Stufe positioniert. Verwechseln Sie die beiden nicht, denn ihre Ausgabequalität und ihr Preis sind unterschiedlich.

Das richtig zu treffen ist aus demselben Grund wichtig, aus dem die Modellabstammung in der Fable-5-Lektion zur Souveränität wichtig war: Über ein Werkzeug, das Sie falsch identifiziert haben, können Sie nicht richtig nachdenken.

Der Vergleich, der echte Arbeit entscheidet

Die Achsen, die die ausgelieferte Ausgabe wirklich verändern:

Kurz gelesen: Nano Banana Pro gewinnt bei Text, Auflösung und Konsistenz. GPT Image 2 gewinnt beim allgemeinen Look und bei der Einbindung in einen bestehenden OpenAI-Workflow.

Wo jedes gewinnt

🔸 Marketing-Kreation mit viel Text im Bild oder Infografiken. Nano Banana Pro. Beste Textwiedergabe, 2K- und 4K-Ausgabe und Search Grounding für korrekte Fakten und Logos. GPT Image 2 ist eine solide Rückfalloption, wenn Sie ohnehin auf OpenAI bauen.
🔸 Produkt- oder Charakter-Konsistenz über eine Reihe. Nano Banana Pro. Es ist das Modell mit einer genannten Spezifikation, 14 Referenzbilder und 5 konsistente Personen, was eine kohärente Kampagne oder eine wiederkehrende Produktaufnahme braucht.
🔸 Allgemeine Hero- oder redaktionelle Bilder. Knapp. GPT Image 2 führt derzeit die allgemeinen Text-zu-Bild-Ranglisten an, wählen Sie also nach Look-Präferenz. Wählen Sie Nano Banana Pro, wenn Sie 4K direkt aus dem Modell brauchen.
🔸 Enge Stack-Integration. Nutzen Sie, was Sie bereits betreiben. Ein OpenAI-Betrieb bekommt eine API und Batch-Rabatte mit GPT Image 2. Ein Google- oder Vertex-Betrieb bekommt native Generierung mit Nano Banana Pro.

Das ist dieselbe Auswahldisziplin, die wir bei KI-Videomodellen und bei Bild-zu-3D mit TRELLIS anwenden. Wählen Sie nach der Aufgabe, nicht nach dem Logo.

Ehrliche Grenzen auf beiden Seiten

Kein Modell ist frei von Kompromissen, und die Kompromisse sind das, was in der Produktion beißt.

🔸 GPT Image 2 deckelt bei etwa 1536px an der langen Seite und bietet nur drei Seitenverhältnisse, es verliert also bei Großformaten und ungewöhnlichen Formen. Der Token-Preis macht edit-lastige Arbeit teuer, da Edits auch Bild-Eingabe-Tokens berechnen. Das Wasserzeichen sind C2PA-Metadaten statt einer eingebetteten unsichtbaren Markierung, was Sie für Ihre Compliance-Anforderungen prüfen sollten.
🔸 Nano Banana Pro trägt das unsichtbare SynthID-Wasserzeichen auf der Ausgabe, das unterhalb der obersten Enterprise-Stufe nicht entfernbar ist. Manche Kunden wollen es weg, prüfen Sie das also früh. Es läuft zudem mit höheren Kosten und Latenz als das Basis-Nano-Banana, und Google veröffentlicht keinen sauberen Preis pro Bild, planen Sie die Kosten also über den Vertex-Rechner.

Nichts davon ist ein Ausschlusskriterium. Es ist die Art Detail, die entscheidet, welches Modell zu einer bestimmten Kundenanforderung passt.

Wie wir bei iiterate wählen

Unsere Voreinstellung ist keine Treue zu einem Modell, sondern eine kurze Checkliste. Trägt das Bild Text oder braucht es 4K? Muss es über eine Reihe hinweg konsistent bleiben? Welche Cloud betreibt der Kunde bereits? Gibt es Wasserzeichen- oder Residenz-Vorgaben?

Meistens beantworten sich diese vier Fragen von selbst. Textlastige, hochauflösende oder konsistenzkritische Arbeit geht an Nano Banana Pro. Allgemeine redaktionelle Arbeit und OpenAI-native Pipelines gehen an GPT Image 2. Wir behalten beide im Werkzeugkasten, gerade weil sich die richtige Antwort je Briefing ändert.

Die Modelle werden einander weiter überholen, prüfen Sie also Ranglisten und Preise zum Entscheidungszeitpunkt erneut. Stabil bleibt die Gewohnheit: das Modell zur Aufgabe passen, und zu dem Stack, in dem der Kunde bereits lebt.

Dieser Beitrag behandelt, was TRELLIS ist, wie es funktioniert, wo es in eine echte Asset-Pipeline passt und an welchen Punkten es aufhört, eine Ein-Klick-Antwort zu sein.

Was TRELLIS ist

TRELLIS ist ein generatives 3D-Modell, das ein Bild, mehrere Bilder oder einen Text-Prompt annimmt und ein 3D-Asset erzeugt.

🔸 Strukturierte Latents (SLAT). Die Kernidee ist ein einheitlicher Latent, der ein dünnbesetztes 3D-Voxelgitter für die Struktur mit dichten visuellen Merkmalen für das Aussehen verbindet. Form vom Look zu entkoppeln ist das, was denselben Latent zu verschiedenen Ausgaben werden lässt.
🔸 Drei Ausgaben aus einem Latent. Radiance Fields, 3D-Gaussians oder ein als GLB exportiertes Mesh. GLB ist das praktische Ziel, da es Materialien in Web- und AR-Viewer trägt.
🔸 Offen und MIT-lizenziert. Das Arbeitspferd für Bilder, TRELLIS-image-large, hat 1,2 Mrd. Parameter. Das Modell und der meiste Code sind MIT, was für den kommerziellen Einsatz zählt. Eine neuere 4B-Reihe fügt vollständige physikalisch basierte Materialien hinzu, sehenswert, während sie reift.
🔸 Im großen Maßstab trainiert. Rund 500.000 kuratierte Objekte, mit dem Paper als CVPR 2025 Spotlight.

Das steht neben dem parametrischen, steuerbaren Ende der 3D-Arbeit, das wir in Grasshopper für computergestütztes Design behandeln. Generatives 3D und parametrisches 3D lösen unterschiedliche Probleme.

Wie es funktioniert

Die Pipeline ist kurz zu beschreiben und nützlich zu verstehen, bevor Sie ihr eine GPU widmen.

1. Eingabe. Ein einzelnes Bild, mehrere Ansichten oder ein Text-Prompt.
2. Strukturierter Latent. Ein zweistufiger Rectified-Flow-Transformer erzeugt zuerst die dünnbesetzte Struktur und füllt dann die SLAT-Merkmale.
3. Dekodieren. Der Latent dekodiert zu Ihrem gewählten Format: Mesh, Gaussians oder Radiance Field.

In der Praxis planen Sie mit etwa 16 GB VRAM als Untergrenze, mit 24 GB komfortabel. Die Generierung läuft in unter zwei Minuten auf einer RTX 4090. Community-Builds drücken den Speicherbedarf weiter, was TRELLIS realistisch selbst hostbar macht statt gemietet. Für Teams, die bereits lokale gegen gehostete Inferenz abwägen, gilt derselbe Kompromiss, den wir in On-Premise gegen Cloud-LLM beschrieben haben, auch für generative Medien.

Wo es in eine Asset-Pipeline passt

Die stärkste Passung ist der Anfang der Pipeline, wo Tempo über Feinschliff geht.

🔸 Ein Produktfoto oder Prompt zu einem GLB. Legen Sie es in einen three.js-Viewer oder einen Model-Viewer im Web, konvertieren Sie zu USDZ für AR oder stellen Sie es in eine Visualisierungsszene. Schnelles Concepting und Vorschauen sind, wo TRELLIS glänzt.
🔸 Lokales Bearbeiten. TRELLIS kann eine Region des Modells neu generieren oder verfeinern, was unter Ein-Bild-Generatoren selten ist.
🔸 Ehrlich zur Topologie. Die Ausgabe ist generative Geometrie, nicht künstlersauber. Erwarten Sie ungleichmäßige Dreiecke, keinen sauberen Edge-Flow und automatisch erzeugte UVs. Für Games oder Film werden Sie retopologisieren, neu UV-mappen und Texturen neu backen. Die neuere materialbewusste Reihe verkleinert diese Lücke, ohne sie zu schließen.

Der Werttest für ein gegebenes Asset ist also einfach: Muss es nächste Woche in einem Viewer richtig aussehen, oder muss es ein riggbares, optimiertes Game-Asset sein? TRELLIS ist beim Ersten hervorragend und ein Startpunkt für das Zweite.

TRELLIS gegen die Alternativen

Das offene und gehostete 3D-Feld bewegte sich schnell. Eine kurze Orientierung:

Wo TRELLIS steht: die stärkste wirklich MIT-lizenzierte Option mit Mehrformat-Ausgabe und lokalem Bearbeiten. Gehostete Werkzeuge wie Tripo und Rodin schlagen es bei sofort sauberer Topologie, und Hunyuan gewinnt oft bei der Textur, aber mit einer restriktiveren Lizenz. Wenn Ihre Anforderung ist, das Modell und die rechtlichen Bedingungen zu besitzen, ist TRELLIS der offensichtliche Startpunkt.

Die ehrlichen Grenzen, und wie wir es nutzen

Ein paar Vorbehalte, die wir auf den Tisch legen, bevor jemand TRELLIS in die Produktion einbindet:

🔸 Topologie und UVs sind für Games oder CAD nicht einsatzfertig. Planen Sie Budget für Retopo ein.
🔸 CAD ist außerhalb des Rahmens. Generative Meshes sind keine parametrischen Solids, also keine Ingenieurgeometrie.
🔸 Das Eingaberisiko liegt bei Ihnen. Das Modell ist MIT, aber die rechtliche Exposition Ihres Eingabebilds oder Prompts ist Ihre. Füttern Sie keine Produktaufnahmen, die Sie nicht lizenzieren können.

Wir behandeln TRELLIS als Concepting- und Previz-Engine: einen Weg, ein glaubwürdiges 3D-Asset an einem Nachmittag vor einen Kunden zu bringen und dann zu entscheiden, was eine handgefertigte Pipeline verdient. Das ist derselbe Instinkt hinter wo die aktuelle Welle von KI-Videomodellen nützlich ist, und dieselbe Auswahldisziplin, die wir beim Wählen eines Bildmodells anwenden. Das Werkzeug ist nicht die Lieferung. Das Urteil, wo es passt, ist es.

Dieser Beitrag kartiert beide Seiten: was diese Plattformen 2026 wirklich gut können, und die konkreten Punkte, an denen Sie mit einer Wand rechnen sollten.

Was ein No-Code-Agent-Builder eigentlich ist

Es hilft, zwei Dinge zu trennen, die unter demselben Banner verkauft werden.

Workflow-Automatisierung ist deterministisch. Ein Trigger feuert, feste Schritte laufen, dieselbe Eingabe ergibt dieselbe Ausgabe. Klassische Make- oder Zapier-Szenarien leben hier, und ebenso eine Menge nützlicher Arbeit.

Ein No-Code-Agent-Builder lässt ein Sprachmodell den Weg entscheiden. Sie beschreiben ein Ergebnis, und das Modell wählt Werkzeuge, ruft APIs auf, liest Ihre Dokumente und schleift so lange, bis es meint, fertig zu sein. Der Ablauf ist nicht von Ihnen im Voraus verdrahtet.

Die Grenze verschwimmt, weil die Automatisierungsplattformen Agenten auf ihre Leinwände geschraubt haben, während die agenten-nativen Werkzeuge Integrationen hinzufügten. Für ein Mittelstands-Team ist die praktische Frage nicht 'Agent oder Workflow'. Sie ist, wie viel Nicht-Determinismus Sie in einen Geschäftsprozess lassen, und wer die Daten hält, während er läuft. Dieselbe Unterscheidung trafen wir, als wir über den Unterschied zwischen einer API, einem MCP-Server und einer CLI schrieben.

Was sie heute gut können

Für die richtige Aufgabe eingesetzt, verdienen sich diese Werkzeuge schnell ihren Platz:

🔸 Trigger und Integrationen. Webhooks, App-Ereignisse und Zeitpläne über tausende Connectors. Die Verkabelung ist gelöst.

🔸 Werkzeugaufrufe. Der Agent chattet nicht nur, er handelt: Er fragt eine Datenbank ab, postet in ein System, legt ein Ticket an.

🔸 Retrieval über Ihre eigenen Dokumente. Antworten in internem Wissen zu verankern ist jetzt eine Sache weniger Klicks, dasselbe Muster, das wir in unserem Beitrag zu RAG behandeln.

🔸 Mehrstufige Abläufe mit einem Menschen in der Schleife. Ein Freigabetor, bevor etwas Unumkehrbares geschieht.

Der Ertrag ist Tempo. Sie können in Tagen belegen, dass eine Idee es wert ist, und genau dafür ist ein Prototyp da. Wir haben unsere eigene Event-Scout-Micro-App in diesem Geist gebaut, bevor wir entschieden, was echtes Engineering verdient.

Wo sie aufhören

Das ist der Teil, den die meisten Demos überspringen, und der Grund, warum Gartner erwartet, dass mehr als 40 Prozent der agentischen Projekte bis Ende 2027 abgebrochen werden. Der Fehlermodus ist selten ein Absturz. Er ist leiser als das.

🔸 Zuverlässigkeit und Nicht-Determinismus. Dieselbe Anfrage liefert nicht zweimal dasselbe Ergebnis. Agenten stürzen nicht ab, sie driften: Sie schleifen, wählen das falsche Werkzeug oder handeln auf veraltetem Kontext. Die Kosten zeigen sich als Qualität und Latenz, ohne rotes Licht auf dem Dashboard.

🔸 Evaluation und Beobachtbarkeit. No-Code-Konsolen geben Ihnen dünnes Tracing. Zu messen, ob ein Agent wirklich besser wird, über einen ganzen mehrstufigen Lauf hinweg und nicht nur die finale Antwort, ist ein Anbau, den Sie selbst bauen müssen.

🔸 Data Governance und Hosting. Die meisten dieser Plattformen sind US-SaaS. Für deutsche Daten heißt das DSGVO- und Schrems-II-Fragen, die Sie nicht wegwischen können. Die selbst hostbaren Optionen, die Daten auf Ihren eigenen EU-Servern halten, sind eine kurze Liste: n8n, Flowise, Langflow, Dify. Wir gehen tiefer auf diesen Kompromiss ein in On-Premise gegen Cloud-LLM und in was die DSGVO tatsächlich erlaubt.

🔸 Kosten bei Skalierung. Abrechnung pro Ausführung und pro Kredit bestraft Volumen. Bei einem Kreditmodell kann derselbe Agent ein paar Euro oder mehrere Hundert kosten, allein abhängig davon, wie er gebaut wurde. Pilotprojekte wirken günstig. Die Produktion ist es oft nicht.

🔸 Lock-in und Übergabe. Proprietäre Leinwände exportieren nicht in echtes Engineering. Wenn Sie einem No-Code-Werkzeug entwachsen, bauen Sie meist neu, statt zu migrieren.

Die Entscheidungslinse

Ich nutze fünf Fragen, um zu entscheiden, ob etwas No-Code bleibt oder zu einem gebauten System aufsteigt. Bewerten Sie jede mit niedrig oder hoch.

1. Datensensibilität. Berührt es Personen- oder regulierte Daten?
2. Volumen- und Kostenkurve. Skaliert die Nutzung auf einen Punkt, an dem die Abrechnung pro Kredit wehtut?
3. Zuverlässigkeitsanspruch. Ist es intern und nachsichtig oder kundenseitig mit einem SLA?
4. Logik-Komplexität. Leichte Verzweigung oder tiefe bedingte und zustandsbehaftete Logik?
5. Audit und Evaluation. Brauchen Sie Evals auf Trajektorienebene und eine Audit-Spur?

Zwei oder mehr 'hoch'-Antworten, und Sie wollen einen maßgeschneiderten oder hybriden Bau. Sonst ist No-Code das richtige Werkzeug, besonders zum Belegen von Wert.

Das in der Praxis funktionierende Muster ist kein Entweder-oder. Prototypen Sie auf etwas wie n8n oder Flowise, finden Sie den Weg, der wirklich liefert, und härten Sie dann genau diesen einen Weg zu eigenem Engineering. Der Prototyp war nicht vergeudet. Er hat Ihnen genau gesagt, was zu bauen ist.

Wie wir sie bei iiterate behandeln

Wir greifen früh und oft zu No-Code-Agent-Buildern, dann sind wir bewusst darin, wann wir sie verlassen. Ein No-Code-Agent ist ein schneller, ehrlicher Weg, herauszufinden, ob ein Ergebnis das Engineering wert ist, das es bräuchte, um es zuverlässig zu machen. Das ist echter Wert, und für viele interne Aufgaben ist es die ganze Antwort.

Der Fehler, den ich im Mittelstand am häufigsten sehe, ist, eine funktionierende Demo als fertiges System zu behandeln. Das ist nicht dasselbe, und die Lücke dazwischen ist die Liste oben. Wenn Sie wissen, wo die Grenze verläuft, bevor Sie beginnen, bekommen Sie das Tempo ohne das abgebrochene Projekt. Wenn Sie einen fundierten Blick darauf wollen, wo KI in einem mittelständischen Unternehmen überhaupt hinpasst, das haben wir in KI-Lösungen für den Mittelstand aufgeschrieben.

Zwei Vorbehalte vorweg für einen deutschen Käufer. Die Preise aller drei ändern sich oft, behandeln Sie also jede Zahl hier als veraltet und prüfenswert. Und Datenresidenz ist eine echte Randbedingung: Keines hostet standardmäßig in der EU, was zählt, bevor Personendaten ein Gespräch berühren.

Was jedes eigentlich ist

🔸 ElevenLabs Agents. Aufgebaut auf der Sprachqualität, für die ElevenLabs bekannt ist, nun umhüllt von einer gehosteten Agentenschicht mit Telefonie über SIP. Die Wahl, wenn die natürlichst klingende Stimme und Entwicklerkontrolle die entscheidenden Faktoren sind.

🔸 Retell AI. Telefonie-erste Voice-Agent-Infrastruktur. Es positioniert sich über niedrige Latenz und verlässliche Gesprächsabwicklung, eingehend und ausgehend, und lässt Sie Ihren eigenen Carrier mitbringen. Die Wahl für den produktiven Anrufbetrieb.

🔸 Voiceflow. Eine visuelle, kollaborative Plattform zum Entwerfen von Chat- und Voice-Agenten, mit eingebauter Wissensbasis. Design-geführt und No-Code-erst. Die Wahl für ein CX- oder Design-Team, das an Abläufen iteriert. Beachten Sie, dass die Live-Telefonstimme hier die schwächste der drei ist, da sie sich auf einen separaten Telefonie-Anbieter stützt.

Wenn Ihre Aufgabe näher an einem Text- oder werkzeugnutzenden Agenten liegt als an einer Telefonleitung, gilt dieselbe Bauen-gegen-Kaufen-Logik aus No-Code-Agent-Buildern.

Der Vergleich, der zählt

Die Dimensionen, die ein Voice-Agent-Projekt wirklich entscheiden, nebeneinander:

Lesen Sie die Tabelle als Karte von Kompromissen, nicht als Punktetafel. Keine Spalte ist bei allem am besten, was der ganze Punkt ist.

Wo jedes passt

🔸 Eine deutsche Support-Leitung, die Telefonie und eine natürliche deutsche Stimme braucht. Beginnen Sie mit Retell für verlässliche Gesprächsabwicklung und Carrier-Kontrolle, oder ElevenLabs, wenn die Natürlichkeit der deutschen Stimme der entscheidende Faktor ist. Für strikte Datensouveränität hostet keines standardmäßig in der EU, planen Sie also selbst gehostetes Retell oder eine EU-native Alternative.

🔸 Ein designgeführtes Team, das einen CX-Ablauf baut. Voiceflow. Der visuelle Builder, die Mehr-Editoren-Zusammenarbeit und die Wissensbasis lassen ein Team ohne Entwickler iterieren. Fügen Sie Telefonie separat hinzu, wenn Sie Sprache brauchen.

🔸 Ein Entwickler, der maximale Sprachqualität und eigene Kontrolle will. ElevenLabs. Bestes TTS, SDK-Kontrolle, modellagnostisch, SIP für Telefonie.

Das Muster ist dasselbe, das wir auf die meisten Werkzeugentscheidungen anwenden: zuerst die Aufgabe benennen, dann das Werkzeug wählen, das diese Aufgabe besitzt.

Die deutsche Frage der Datenresidenz

Das ist der Teil, der entscheidet, ob ein Voice-Agent überhaupt erlaubt ist, bevor Sprachqualität überhaupt zählt.

DSGVO-Konformität ist nicht dasselbe wie EU-Hosting. Ein Anbieter kann DSGVO-konform sein und Anrufe trotzdem auf US-Infrastruktur verarbeiten und speichern, was die Schrems-II-Fragen wieder öffnet. Über diese drei hinweg: ElevenLabs bietet EU-Datenresidenz nur in der Enterprise-Stufe, Retell erreicht sie über Selbst-Hosting, und Voiceflow ist reine Cloud ohne souveräne Residenz-Option.

Für eine deutsche Support-Leitung, die Kundendaten verarbeitet, macht das aus der Shortlist ebenso eine Hosting-Entscheidung wie eine Feature-Entscheidung. Es ist dieselbe Logik, die wir in was die DSGVO tatsächlich erlaubt und in On-Premise gegen Cloud-LLM darlegen: entscheiden Sie, wo die Daten liegen dürfen, dann wählen Sie das Werkzeug, das das respektiert.

Wie wir wählen würden

Wir würden nicht von der Marke ausgehen. Wir würden von drei Fragen ausgehen: Läuft das über das Telefon, wer wartet es, und wo dürfen die Daten liegen.

Ist es eine Telefonleitung, verdient Retell den ersten Blick. Trägt die Sprachqualität das Erlebnis und ein Entwickler besitzt es, ElevenLabs. Muss ein nicht technisches Team den Ablauf entwerfen und besitzen, Voiceflow. Und wenn die Daten die EU nicht verlassen dürfen, verlagert sich das Gespräch zum Hosting, bevor es zu den Features geht, was die Shortlist oft neu formt.

Die Preise werden sich weiter bewegen, prüfen Sie sie also zum Evaluationszeitpunkt erneut, statt einer einzelnen Zahl zu vertrauen. Der beständige Teil ist die Passung, und die Passung folgt der Aufgabe.