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.

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.

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.

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.

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.

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.

Dieser Beitrag erklärt, warum wir es gebaut haben, was es kann, wo es ehrlich aufhört, und stellt am Ende eine offene Frage.

DIE PFLICHT, KURZ UND KORREKT

Die elektronische Rechnung ist im deutschen B2B keine Option mehr, sondern Pflicht, und der Zeitplan ist konkret.

• Seit dem 1. Januar 2025 muss jedes inländische Unternehmen E-Rechnungen empfangen und verarbeiten können. Ohne Ausnahme, ohne Umsatzgrenze, auch Kleinunternehmer.
• Bis Ende 2026 sind beim Versand noch Papier oder PDF erlaubt, das PDF aber nur mit Zustimmung des Empfängers.
• Ab 2027 müssen Unternehmen mit mehr als 800.000 Euro Vorjahresumsatz E-Rechnungen ausstellen, ab 2028 dann alle.

Gemeint ist mit E-Rechnung kein PDF-Anhang, sondern ein strukturiertes Format nach der europäischen Norm EN 16931. ZUGFeRD ist die in Deutschland gängige Variante: eine PDF/A-3-Datei mit eingebettetem XML. Der Mensch sieht ein lesbares PDF, die Software liest das XML direkt aus, ohne Abtippen und ohne Texterkennung. Die Grafik unten zeigt genau diese zwei Sichten auf dieselbe Datei.

WARUM WIR NICHT EINFACH EIN ABO GENOMMEN HABEN

Den Auslöser kennt jeder: die Pflicht kommt, also braucht man ein Werkzeug. Die naheliegende Antwort ist ein Abo, und genau da haben wir innegehalten.

Für einen im Kern einfachen Vorgang, ein PDF mit eingebettetem XML zu erzeugen, laufen schnell wiederkehrende Kosten auf: gängige Rechnungs-Tools beginnen bei rund 10 Euro im Monat und reichen für den E-Rechnungs-Versand je nach Tarif deutlich höher. Für ein Haus, das nur wenige Rechnungen im Monat schreibt, zahlt man damit dauerhaft für eine Vollbuchhaltung, die man gar nicht nutzt.

Der eigentliche Grund war aber nicht der Preis, sondern die Daten. Eine Rechnung enthält Namen, Adressen und oft Bankverbindungen. Schickt man sie durch ein Cloud-Tool, ist das eine Auftragsverarbeitung nach Art. 28 DSGVO: ein Vertrag, ein Drittanbieter, Daten, die das Haus verlassen. Selbstgehostet entfällt das komplett. Das ist dieselbe Logik, die wir bei Sprachmodellen vertreten, nachzulesen in On-Premise vs. Cloud-LLM: Nutzen behalten, Datenhoheit nicht abgeben.

WAS BELEGT KONKRET TUT

Belegt ist bewusst klein und scharf umrissen. Es ist ein Generator, kein Buchhaltungs-Ersatz.

Technisch ist es eine Web-Anwendung, die man auf dem eigenen Rechner oder Server betreibt. Die Daten liegen lokal in einer Datei, sensible Felder wie Bankverbindungen sind dabei verschlüsselt abgelegt. Es erzeugt ZUGFeRD- und Factur-X-Rechnungen im Profil EN 16931, also der Stufe, die rechtlich als vollwertige E-Rechnung zählt, prüft sie gegen die Norm, vergibt fortlaufende Rechnungsnummern, verwaltet Firmen- und Kundenprofile, und behält offene Posten und Auswertungen im Blick.

Die zwei Dinge, die uns am meisten Zeit sparen: ein geführter Ablauf, der eine konforme Rechnung in wenigen Schritten fertigstellt, und dass die erzeugte Datei sofort die Maschinensicht mitbringt, die der Empfänger braucht. Wir nutzen es selbst, jeden Monat. Das ist die ehrlichste Empfehlung, die wir geben können: wir haben es nicht für einen Markt gebaut, sondern für uns. Es ist eines von mehreren kleinen Werkzeugen, die so entstanden sind, wie das Event-Scout-Tool.

WO ES EHRLICH AUFHÖRT

Ein selbstgehostetes Einzeltool hat reale Grenzen, und die zu verschweigen wäre genau die Art Marketing, die wir nicht machen.

🔸 Die Norm bewegt sich. EN 16931 und die Code-Listen werden regelmäßig aktualisiert. Ein Generator muss gepflegt werden, sonst erzeugt er irgendwann nicht mehr konforme Rechnungen. Das ist Arbeit, die jemand leisten muss.
🔸 Aufbewahrung ist nicht inklusive. Erzeugen ist nicht dasselbe wie revisionssicher archivieren. Die GoBD verlangen eine unveränderbare Aufbewahrung im Originalformat, inzwischen acht Jahre. Das löst ein reiner Generator nicht, das bleibt Aufgabe des Nutzers.
🔸 Es ersetzt keinen Steuerberater. Eine technisch valide Rechnung kann inhaltlich trotzdem unvollständig sein. Eine direkte Anbindung an die Kanzlei oder an Buchhaltungssysteme gibt es nicht.

Fair zusammengefasst: Belegt schließt die Pflicht-Lücke Erzeugung und Validierung sauber und abofrei. Archivierung und Steuer-Workflow bleiben außerhalb. Wer das mit einer Vollsuite verwechselt, wird enttäuscht. Wer genau diese eine Lücke hat, bekommt ein Werkzeug ohne Ballast.

SOLLEN WIR ES TEILEN, UND WIE?

Hier endet der Beitrag bewusst mit einer Frage statt einer Antwort, denn wir wissen es selbst noch nicht.

Es gibt zwei plausible Wege. Der eine: wir geben Belegt frei, als selbstgehostete Lösung, die jeder kleine Betrieb auf der eigenen Maschine laufen lassen kann, abofrei und mit den Daten im eigenen Haus. Der andere: wir bieten eine gepflegte Variante an, die wir aktuell halten, bei der Einrichtung helfen und für die Norm-Updates geradestehen, gegen einen fairen Beitrag. Beides hat seine Logik, und die Wartungslast aus dem letzten Abschnitt ist genau der Grund, warum die Antwort nicht trivial ist.

Deshalb diese ehrliche Bitte: Wenn ein lokales, datenschutzkonformes, abofreies ZUGFeRD-Tool für Sie oder Ihren Betrieb nützlich wäre, schreiben Sie uns. Würde es Ihnen reichen, es selbst zu betreiben, oder wäre Ihnen eine betreute Version lieber? Genau dieses Signal hilft uns zu entscheiden, ob aus etwas, das wir für uns gebaut haben, etwas wird, das wir teilen.

Claude Code, Codex, Cursor, Antigravity und Opencode lösen dieselbe Aufgabe auf sehr unterschiedliche Weise. Die eine Frage, die das Feld teilt, ist einfach: muss euer Code das Haus verlassen dürfen? Wer das mit Ja beantworten kann, wählt nach Stack. Wer es nicht kann, hat genau eine ernsthafte Option. Dieser Text ordnet die fünf entlang dieser Frage und endet mit der Entscheidung, die ich einem deutschen Team empfehle.

FÜNF WERKZEUGE, EINE ERSTE FRAGE

Die fünf sitzen auf verschiedenen Ebenen, und der Formfaktor sagt schon viel über den Einsatz.

• Claude Code ist ein Terminal-Agent von Anthropic: stark bei Mehrdatei-Änderungen, großem Kontext und einer agentischen Schleife im Terminal.
• Codex von OpenAI gibt es als CLI, Cloud-Sandbox und IDE-Integration aus einem gemeinsamen Nutzungsfenster.
• Cursor ist die KI-IDE mit Agenten- und Hintergrund-Agenten-Modus und freier Modellwahl.
• Antigravity ist Googles agentenzentrierte IDE, seit dem 20.11.2025 verfügbar, mit einer Manager-Oberfläche zum Starten und Beobachten paralleler Agenten (Google).
• Opencode ist ein quelloffener Terminal-Agent unter MIT-Lizenz, modellunabhängig über viele Anbieter und selbst gehostete Endpunkte (opencode.ai).

Wie diese Werkzeuge sich in einen Stack einfügen, von der API bis zur CLI, haben wir in API, MCP oder CLI ausgelegt. Hier geht es um die Auswahl, und die beginnt mit der Datenlage.

VERLÄSST EUER CODE DAS HAUS?

Diese eine Frage sortiert das Feld schneller als jede Funktionsliste, weil sie über Compliance und Vertraulichkeit entscheidet, bevor irgendein Feature zählt.

Vier der fünf senden Code in eine fremde Cloud. Claude Code, Codex, Cursor und Antigravity laufen gegen gehostete Modelle in den USA. Das ist nicht per se ein Ausschluss: für viele Projekte ist das in Ordnung, und im Enterprise-Tarif lassen sich Zero-Data-Retention und No-Train-Klauseln verhandeln. Aber der Code geht raus, und das muss man bewusst akzeptieren, nicht übersehen.

Opencode ist die Ausnahme. Weil es modellunabhängig ist und einen lokalen Endpunkt ansprechen kann, läuft es vollständig gegen ein selbst gehostetes Modell. Dann verlässt der Code das Haus nie. Das ist genau die Trennlinie, die über alles Weitere entscheidet. Welches Open-Weight-Modell ihr dahinter setzt, ist eine eigene Entscheidung, die wir in Open-Weight-Modell fürs deutsche B2B durchgehen.

WENN DIE CLOUD OKAY IST: NACH STACK WÄHLEN

Akzeptiert ihr die gehostete Cloud bewusst, dann entscheidet der Stack, nicht das Benchmark. Eine knappe Karte:

Die pragmatische Regel: Anthropic-Haus nimmt Claude Code, OpenAI-Haus nimmt Codex, ein IDE-zentriertes Team nimmt Cursor oder Antigravity. Benchmark-Zahlen wie SWE-Bench-Werte um die 85 Prozent kursieren, sind aber meist Anbieterangaben und selten unabhängig nachgeprüft; ich würde keine Werkzeugwahl darauf stützen. Was ein Coding-Agent außerhalb der reinen Entwicklung leistet, zeigt unser Beitrag Claude Code jenseits des Engineerings.

WENN DER CODE IM HAUS BLEIBEN MUSS: OPENCODE PLUS EIGENES MODELL

Darf der Code nicht raus, bleibt eine ernsthafte Option, und sie ist gut.

Opencode ist quelloffen unter MIT, spricht viele Anbieter und, entscheidend, einen lokalen Endpunkt an. Gepaart mit einem selbst gehosteten Open-Weight-Modell entsteht ein Coding-Agent, bei dem weder Quelltext noch Prompts die eigene Infrastruktur verlassen. Für regulierte Daten, Mandantengeheimnisse oder schlicht vorsichtige Kunden ist das oft der einzige tragfähige Aufbau. Ein offenes Coding-Modell wie Kimi K2.7 haben wir dafür eigens angeschaut.

Der Preis dieser Kontrolle ist Eigenarbeit: ihr stellt Modell, Hardware und Betrieb selbst zusammen, es gibt keine gemanagte Cloud-Agenten-Flotte. In der Praxis hilft es, dem Agenten Struktur zu geben, etwa eine Codebasis-Karte, wie wir sie in Graphify beschrieben haben. Der Aufwand ist real, aber er kauft etwas, das die gehosteten Werkzeuge nicht bieten können.

WIE ICH DAS ENTSCHEIDE

Ihr braucht keine einzelne Antwort für die ganze Firma, sondern die richtige je nach Datenlage. So gehe ich vor:

1. Datenlage klären. Darf der betreffende Code in eine US-Cloud? Diese Antwort kommt von Recht und Kunde, nicht vom Entwicklerteam.
2. Wenn ja, nach Stack wählen. Anthropic-Haus zu Claude Code, OpenAI-Haus zu Codex, IDE-Team zu Cursor oder Antigravity, jeweils mit verhandelten ZDR- und No-Train-Bedingungen.
3. Wenn nein, Opencode plus eigenes Modell. Die einzige Option, bei der der Code das Haus nicht verlässt.
4. Lock-in im Blick behalten. Verlangt jedes Werkzeug seine eigene Bindung, also haltet euch einen Weg zurück zu einer tieferen Ebene offen, falls ein Anbieter die Bedingungen ändert.

Wir selbst arbeiten je nach Projekt mit mehreren dieser Werkzeuge, und genau das ist der Punkt: die Wahl ist projektgebunden, nicht weltanschaulich. Das eine kleine interne Tool, das wir mit einem Agenten gebaut haben, statt es zu beauftragen, steht in Building event-scout. Welche eurer Repositories dürften heute eigentlich gar nicht in eine fremde Cloud, und welches Werkzeug nutzt ihr trotzdem dafür?

Dies ist die Karte dieser Fläche, wofür jedes Teil da ist und wo die scharfen Kanten sitzen.

FÜNF WEGE ZU ERWEITERN, EIN PRINZIP

Unter den Namen tut jeder Erweiterungspunkt dasselbe: er verschiebt Know-how aus dem Prompt in versionierte Dateien, die der Agent lädt, wenn er sie braucht.

• Skills sind Ordner aus Anweisungen, Skripten und Ressourcen. Eine kurze Beschreibung sitzt im Kontext; das volle Skill lädt nur, wenn der Agent es für relevant hält. Das ist progressive Offenlegung: günstig vorzuhalten, ausführlich beim Aufruf.
• Slash-Commands sind benannte Abkürzungen, die sich zu einem festen Prompt entfalten. Der schlichte Weg, eine wiederholte Anfrage einmal zu kodieren und wiederzuverwenden.
• Hooks sind Shell-Befehle, die bei Lebenszyklus-Ereignissen ausgelöst werden: Sitzungsstart, vor einem Werkzeugaufruf, danach, beim Stopp. Ein Pre-Tool-Hook kann einen Aufruf prüfen und blockieren, bevor er läuft.
• MCP-Connectors geben dem Agenten authentifizierten Zugang zu Systemen, die er sonst nicht erreicht: eine Datenbank, einen Issue-Tracker, eine interne API. Jeder Server trägt seine eigenen Zugangsdaten.
• Subagents sind eigene Agenteninstanzen, die für eine fokussierte Teilaufgabe gestartet werden, mit eigenem Kontext und eigenen Anweisungen.

Ein Plugin bündelt beliebige davon in eine installierbare Einheit. Das Prinzip unter allem: kodieren Sie Ihr Know-how als Dateien in Ihrem Repo, nicht als Gewohnheiten im Kopf einer Person. Die Systemintegrations-Variante dieser Wahl haben wir in API, MCP oder CLI ausgelegt.

SKILLS UND MCP SIND KEINE RIVALEN

Die häufigste Frage im Moment ist "Skills oder MCP", und die ehrliche Antwort ist, dass sie unterschiedliche Probleme lösen.

MCP ist Zugang: es verbindet den Agenten mit einem System, das er allein nicht erreicht, mit Zugangsdaten und Zustand. Skills sind Know-how: wiederholbare Expertise, die der Agent auf Systeme anwendet, die er bereits hat. Die kursierende Analogie trifft es: MCP sind die Gänge des Baumarkts, Skills sind der erfahrene Mitarbeiter, der weiß, in welchen Gang man gehen muss.

Die Token-Ökonomie entscheidet die Form eines guten Aufbaus. Ein Skill kostet ein paar Dutzend Token, bis es aufgerufen wird. Eine Handvoll MCP-Server kann Zehntausende Token an Kontext kosten, bevor die erste Aufgabe beginnt, weil jeder Server all seine Werkzeuge vorab ankündigt. Das Arbeitsmuster, auf das die meisten Praktiker zulaufen, ist also viele schlanke Skills und wenige, gut gewählte Connectors, kein Alles-installieren-Haufen. Die Demo unten geht die fünf Erweiterungstypen durch sowie die Kosten und das Risiko, das jeder trägt.

WARUM DER OFFENE STANDARD FÜR SOUVERÄNITÄT ZÄHLT

Die nützlichste jüngste Änderung ist, dass die Erweiterungsschicht aufhörte, das Feature eines einzelnen Anbieters zu sein.

Agent Skills wurden im Dezember 2025 als offener Standard veröffentlicht, und das Format wurde binnen Wochen bei mehreren Agenten-Anbietern übernommen. In der Praxis heißt das, dass ein Skill, das Sie für einen Harness schreiben, dort nicht gefangen ist. Für eine deutsche Firma, die das Risiko "an einen einzigen US-Anbieter gebunden" abwägt, ist das eine Teilantwort auf der Ebene, die Sie kontrollieren: das Know-how, das Sie kodieren, ist portabel, auch wenn das Modell darunter gemietet ist.

Kombinieren Sie das mit Connectors, die auf EU-gehostete oder On-Premise-Systeme zeigen, dann hält die Datenresidenz-Geschichte zugleich mit der Fähigkeits-Geschichte. Das Know-how ist Ihres und portabel; die Daten bleiben, wo sie müssen. Das ist eine haltbarere Position, als den Workflow auf die Roadmap eines einzigen Anbieters zu wetten, dieselbe Überlegung, die hinter der Wahl eines Coding-Agenten nach dem Harness, nicht dem Modell steht.

JEDER ERWEITERUNGSPUNKT IST EINE ANGRIFFSFLÄCHE

Dieselbe Macht, die den Harness nützlich macht, macht ihn gefährlich, und die Risiken sind jung und dokumentiert, nicht hypothetisch.

Hooks führen beliebige Shell-Befehle aus, das ist genau eine Ausführungsfläche. Check Point machte im Februar 2026 CVE-2025-59536 öffentlich: eine bösartige Einstellungsdatei in einem geklonten Repository konnte Hooks ausführen, bevor der Vertrauensdialog überhaupt erschien. Ein Begleitproblem, CVE-2026-21852, betraf die Exfiltration von API-Schlüsseln über eine Umgebungsüberschreibung. MCP bringt ein eigenes Lieferkettenproblem: jeder Server hält Zugangsdaten, und Scans fanden Hunderte MCP-Server, die ohne Authentifizierung im Internet standen. Und die Skill-Marktplätze listen inzwischen Tausende Community-Skills, leicht zu installieren und schwer zu prüfen, mit Berichten über schlicht bösartige im Umlauf.

Nichts davon ist ein Grund, den Harness nicht zu erweitern. Es ist der Grund, ihn bewusst zu erweitern.

REGIEREN SIE DEN KATALOG, SAMMELN SIE KEINE PLUGINS

Die Disziplin, die einen Produktionsaufbau von einem Wissenschaftsexperiment trennt, ist ein geprüfter, freigegebener Katalog: ein bekannter Satz von Skills, Hooks und Connectors, den jemand gelesen hat, mit einem Vertrauens-Gate, bevor etwas Neues hinzukommt.

Das ist unglamourös und es ist das ganze Spiel. Welche Hooks dürfen Shell ausführen. Welche MCP-Server halten welche Zugangsdaten. Welche Skills sind freigegeben, und wer hat sie freigegeben. Für ein Mittelstandsteam ist das der Ort, an dem institutionelles Wissen zu haltbarem Werkzeug wird, das Personalwechsel übersteht, und an dem die Arbeit aufhört, die schlaue Konfiguration eines einzelnen Ingenieurs zu sein, und etwas wird, das dem Unternehmen gehört. Als wir unser eigenes internes Scouting-Werkzeug als kleine agentische App bauten, lag der Wert nicht in der Cleverness, sondern darin, dass der Prozess nun eine geprüfte Datei in einem Repo war statt einer Erinnerung. Wir haben das in Bau einer kleinen agentischen Micro-App aufgeschrieben.

Das Modell können Sie nächstes Quartal tauschen. Der Katalog der Erweiterungen ist das Gut, das Sie behalten. Die Frage, die es sich vor der Installation des nächsten Plugins zu stellen lohnt, ist also einfach: wer hat es geprüft, und worauf kann es zugreifen?

Dieser Beitrag ist ein nüchterner Überblick: die Anwendungsfälle, die tragen, die Förderung, die es in RLP wirklich gibt, und die eine Hürde, die fast alles bremst.

WELCHE KI-LÖSUNGEN REAL TRAGEN

Die Lösungen, die sich im Mittelstand bewähren, sind unspektakulär und nah an bestehenden Prozessen. Sie sparen Zeit, sie erfinden selten neuen Umsatz.

🔸 Dokumentenintelligenz. Rechnungen, Lieferscheine, Verträge und E-Mails automatisch auslesen und einordnen. Niedrigste Einstiegshürde, schneller spürbarer Effekt.
🔸 RAG-Wissensmanagement. Eine firmeneigene Auskunft über den internen Dokumentenbestand: Handbücher, Prozessdoku, Angebote, Servicehistorie. Entlastet Onboarding und Support, und das Wissen geht beim Personalwechsel nicht verloren.
🔸 Angebots- und Rechnungsautomatisierung. Angebotstexte und Kalkulationen aus Vorgängen erzeugen, Rechnungsworkflows ordnen. Mit der E-Rechnungspflicht ohnehin auf der Tagesordnung.
🔸 Service-Agenten auf eigenem Wissen. First-Level-Support und FAQ, geerdet auf Firmendaten statt auf einem allgemeinen Cloud-Chatbot.
🔸 Lokale LLM für sensible Daten. Personal-, Mandanten-, Konstruktions- oder Patientendaten lokal oder in deutschem Hosting verarbeiten.

Die nüchterne Einordnung: KI zahlt im Mittelstand vor allem auf Effizienz ein, selten direkt auf den Umsatz. Wer den Anwendungsfall nicht sauber wählt, verbrennt Budget, gerade weil die Innovationsausgaben eher sinken.

DIE FÖRDERKULISSE IN RLP, OHNE MYTHEN

Bevor es um Förderung geht, eine Aufräumarbeit: Viele kursierende Programme sind tot oder waren nie RLP. DigiBoost RLP ist seit 2022 geschlossen, das bundesweite go-digital lief Ende 2024 aus, und der oft genannte 20.000-Euro-Digitalisierungsgutschein gehört zu Nordrhein-Westfalen, nicht zu RLP.

Was 2025 und 2026 real läuft:

• Betriebsberatungsprogramm RLP. Seit Dezember 2025, Zuschuss unter anderem zu Digitalisierung und Künstlicher Intelligenz. Löst das frühere BITT ab.
• IBI-EFRE Rheinland-Pfalz. Zuschuss für betriebliche Innovation und Digitalisierung, für KMU mit Sitz in RLP.
• Innovationsgutschein RLP. Bis zu 20.000 Euro nicht rückzahlbar für Forschungs- und Entwicklungsaufträge an externe Stellen.
• Mittelstand-Digital Zentrum Kaiserslautern. Kostenfreie, anbieterneutrale Beratung, Workshops und Demonstratoren.

Die Förderung ist also da. Sie ersetzt nur keine Entscheidung darüber, was man eigentlich bauen will. Genau dabei hilft die Auswahl in der Grafik unten.

DIE EIGENTLICHE HÜRDE IST DATENSCHUTZ, NICHT TECHNIK

Wenn KI-Projekte im Mittelstand scheitern, dann selten am Modell. Sie scheitern an der Frage, wo die Daten liegen dürfen.

77 Prozent der Unternehmen nennen Datenschutz als größte Hürde, vor dem Fachkräftemangel mit 70 Prozent. Gleichzeitig erlauben 73 Prozent ihren Mitarbeitenden die Nutzung von Sprachmodellen, aber nur 23 Prozent beschränken sie auf unternehmenseigene Modelle. Das heißt im Klartext: rund die Hälfte lässt frei verfügbare Cloud-Modelle ungesteuert laufen. Das ist keine Digitalisierung, das ist Schatten-KI, ein Datenleck mit Ansage.

Dazu kommt fehlende Datenreife, fast ein Viertel hat keine geeigneten Daten, und eine berechtigte ROI-Skepsis. Die Lücke ist nicht KI ja oder nein. Sie liegt zwischen informeller Nutzung und einem sicheren, produktiven Rahmen.

SOUVERÄN HEISST NICHT TEURER, ES HEISST STEUERBAR

Die Antwort auf die Datenschutzhürde ist nicht, auf KI zu verzichten. Sie ist, den Einsatzort an der Datensensibilität auszurichten, nicht am Marketing.

Für unkritische Aufgaben ist ein Cloud-Modell vertretbar. Sobald personenbezogene, vertrauliche oder geschäftskritische Daten im Spiel sind, gehört die Verarbeitung in eine deutsche oder EU-Umgebung oder auf eigene Hardware. RAG auf dem eigenen Bestand, lokal oder DE-gehostet, gibt den Nutzen eines Sprachmodells, ohne den Inhalt bei jeder Anfrage aus dem Haus zu schicken. Was lokale KI gegenüber der Cloud wann rechtfertigt, ordnen wir in On-Premise vs. Cloud-LLM ein, und wie RAG dabei technisch funktioniert in Was ist RAG.

Ehrlich bleibt: nicht jede Lösung muss on-premise sein. Die Kunst ist die Zuordnung, und genau die nimmt einem kein Tool und kein Förderbescheid ab.

EIN REALISTISCHER ERSTER SCHRITT

Der begehbare Weg ist nüchtern und in Etappen, nicht das große KI-Versprechen auf einmal.

Use-Case priorisieren, an dem Zeit oder Fehler hängen. Das Datenfundament prüfen, denn RAG auf chaotischem Bestand liefert keinen Wert. Einen kleinen Piloten mit klarem Erfolgsmaß bauen. Dann erst skalieren. Diese Etappen lassen sich über das Betriebsberatungsprogramm RLP oder den Innovationsgutschein kofinanzieren und kostenlos über das Mittelstand-Digital Zentrum flankieren. Den vollständigen Ablauf haben wir im praktischen KI-Fahrplan beschrieben.

Wir bei iiterate sitzen in Koblenz und Remagen und bringen genau diese drei Dinge zusammen: Strategie, Bau und Compliance. Der RLP-Mittelstand ist schon dran. Die Aufgabe ist, aus dem informellen Ausprobieren etwas Souveränes und Belastbares zu machen. Womit würden Sie anfangen, und wo liegen Ihre sensibelsten Daten?

Veo, Kling und Seedance liefern beeindruckende Clips, sind aber geschlossen und gehostet. Wan Animate von Alibaba ist das eine offene Modell der Reihe, und damit der interessante Hebel für alle, die Material nicht aus der Hand geben wollen. Dieser Text ordnet die vier für ein deutsches Unternehmen, das Produktdemos und Marketingvideos baut, und nimmt die Regulierung ernst, die im August scharf wird.

AUDIO WURDE STANDARD, QUALITÄT WURDE PFLICHT

Der wichtigste Wandel des Jahres ist, dass die sichtbare Qualität kein Vorsprung mehr ist, sondern Einsatz.

Nativer Ton ist Standard geworden. Veo 3 brachte synchron erzeugtes Audio, und bis Anfang 2026 generierten auch Kling 2.6 und ByteDances Seedance 2.0 Dialog und Geräusche in einem Durchgang. Stumme Modelle wirken für Demoarbeit inzwischen veraltet. Zugleich bleiben die Clips kurz: acht Sekunden nativ sind typisch, Seedance 2.0 schafft rund fünfzehn, längere Stücke entstehen durch Aneinanderhängen, nicht aus einem Guss.

Chinesische Labore führen mehrere Ranglisten an. Seedance stand im Juni 2025 an der Spitze unabhängiger Text-zu-Video-Vergleiche, vor Veo 3 und Kling (arXiv). Solche Plätze wechseln monatlich. Das ist genau der Grund, die Auswahl nicht an der Rangliste festzumachen, sondern an den drei Kriterien, die stabil bleiben.

DIE VIER IM ÜBERBLICK

Ein wichtiger Hinweis zur Benennung vorab: bei ByteDance ist Seedream das Bildmodell und Seedance das Videomodell. Hier geht es um Seedance.

• Veo 3.1 (Google, geschlossen). Beste Prompt-Treue, synchroner 48-kHz-Ton, die tiefste Einbindung in eine Pipeline über Vertex AI und Flow. Gehostet, die Ausgabe trägt Googles SynthID-Wasserzeichen.
• Kling 2.6 (Kuaishou, geschlossen). Starkes Bild-zu-Video und gute Bewegung, seit Version 2.6 mit nativem Ton, bis etwa zehn Sekunden. Erreichbar über API mit Datenhaltung in Singapur.
• Seedance 2.0 (ByteDance, geschlossen). Längere Clips bis rund fünfzehn Sekunden und Kameraplanung. Begleitet von einer offenen Rechtsfrage, nachdem Disney im Februar 2026 eine Unterlassung verschickte, was für kommerzielle Nutzung ein reales Risiko ist.
• Wan Animate (Alibaba, offen). Unter Apache 2.0 veröffentlicht und selbst hostbar, spezialisiert auf Figuren-Animation, Bewegungsübertragung und Charakterersatz aus einem Referenzbild (Hugging Face). Weniger Politur und kürzere Clips als die gehosteten, dafür volle Kontrolle.

Runway, OpenAIs Sora 2 und MiniMax füllen das Feld weiter, sind für die hier entscheidende Frage aber gleich gelagert: stark, aber geschlossen.

DIE KENNZEICHNUNGSPFLICHT KOMMT AM 2. AUGUST

Die Regulierung ist 2026 das eigentliche Ereignis, nicht das nächste Modell. Wer KI-Video kommerziell einsetzt, muss die Kennzeichnung vorher lösen.

Die Transparenzpflichten aus Artikel 50 der EU-KI-Verordnung werden ab dem 2. August 2026 anwendbar (EU AI Act). Synthetische Medien müssen maschinenlesbar markiert und Deepfakes gekennzeichnet werden. Praktisch heißt das: Provenienz ist eine Compliance-Funktion, kein nettes Extra. Gehostete Modelle bringen das teils mit, Google etwa über SynthID, andere über C2PA-Inhaltsnachweise. Selbst gehostetes Wan trägt dagegen kein erzwungenes Wasserzeichen, also liegt die Kennzeichnung dann in eurer Hand, als eigener, dokumentierter Schritt in der Pipeline.

Welche KI-Inhalte unter die Verordnung fallen und was bis wann umzusetzen ist, haben wir in EU AI Act 2026 und im Rahmen von GDPR und KI ausgelegt.

DAS OFFENE MODELL IST DER HEBEL

Wenn Material das Haus nicht verlassen darf, ist das offene Modell die eigentliche Antwort, nicht das schönste.

Wan in den Versionen 2.1 bis 2.2 und Wan Animate steht durchgängig unter Apache 2.0, also voller kommerzieller Nutzung, Weitergabe und Feintuning ohne Anruf nach Hause. Die kleinere Variante läuft auf einer einzelnen 24-GB-Karte, die 14B-Variante braucht rund 80 GB. Selbst gehostet auf europäischer, notfalls abgeschotteter Infrastruktur verlässt kein Footage eure Kontrolle, und es gibt keine fremden Nutzungsbedingungen und keine geopolitische Abhängigkeit. Der Preis ist weniger Politur und kürzere Clips als bei Veo oder Seedance, was man für die Souveränität bewusst in Kauf nimmt.

Das ist dieselbe Logik, die wir bei Sprachmodellen ziehen: ein offenes, kontrolliertes Modell schlägt die letzten Prozent Qualität, wenn Kontrolle der Punkt ist (souveräne europäische KI). Auch bei Weltmodellen zeichnet sich derselbe offene Weg ab (NVIDIA Cosmos 3).

WIE ICH DAS FÜR EIN DEMO-PROJEKT ENTSCHEIDE

Die Entscheidung folgt der Datenlage und dem Zweck, nicht dem schönsten Demoreel. So gehe ich vor:

1. Sensibles oder reguliertes Material. Zeigt das Video Produkte vor Marktstart, Kunden oder Internes, dann selbst gehostetes Wan auf EU-Infrastruktur, und die Kennzeichnung als eigener Pipeline-Schritt.
2. Öffentliches Marketing, unkritischer Inhalt, Politur entscheidend. Dann ein gehostetes Modell wie Veo oder Seedance, aber mit bewusst gewählten Bedingungen und geklärter Provenienz.
3. In jedem Fall die Kennzeichnung vor dem 2. August lösen, nicht danach.

In unserer eigenen Kreativarbeit mischen wir das je nach Projekt, und der Punkt ist nicht, ein Modell zum Sieger zu küren. Der Punkt ist, dass die sichtbare Qualität das Leichte geworden ist und die schwierigen Fragen, Datenlage, Rechte und Kennzeichnung, über den Einsatz entscheiden. Welches eurer geplanten Videos könntet ihr überhaupt einem gehosteten US-Dienst anvertrauen, und welches gehört auf eure eigene Infrastruktur?

Qwen, Kimi, Nemotron und Minimax sind 2026 alle ernsthaft brauchbar. Aber nur drei der vier tragen eine wirklich freie Lizenz, nur eine Familie passt sauber auf Mittelstands-Hardware, und kein Anbieter veröffentlicht einen sauberen Vergleich genau dieser vier auf Deutsch. Dieser Text ordnet die vier nach den Kriterien, die ein Käufer tatsächlich prüfen muss, und endet mit der Entscheidung, die ich einem Mittelständler empfehle.

Zuerst die Lizenz, dann der Benchmark

Die Lizenz ist das erste Tor, weil sie über jede kommerzielle On-Prem-Nutzung entscheidet, bevor ein einziger Benchmark zählt.

Drei der vier sind hier unkompliziert. Qwen3 steht unter Apache 2.0, Minimax M2 unter MIT, Kimi K2 unter einer modifizierten MIT-Lizenz (Hugging Face). Das sind echte, freie Grants: kommerzielle Nutzung, Weitergabe, Feintuning, kein Anruf nach Hause.

🔸 Nemotron ist der Sonderfall.
NVIDIAs Open Model License ist keine reine Apache- oder MIT-Lizenz. Sie knüpft die Nutzung an NVIDIAs Bedingungen und endet automatisch, wenn man die eingebauten Schutzmechanismen entfernt (NVIDIA). Das Modell ist gut, aber diese Klausel landet zuerst bei der Rechtsabteilung, nicht beim Engineering. Wir haben den NVIDIA-Ansatz im Detail im Beitrag zu Nemotron 3 beschrieben.

Wer Souveränität als Argument nutzt, sollte die Lizenz lesen können wie einen Vertrag, denn genau das ist sie.

Wie gut ist das Deutsch wirklich?

Die ehrliche Antwort: es gibt keinen sauberen Vier-Wege-Vergleich dieser Modelle auf Deutsch, also muss man ihn selbst herstellen.

Deutsche Eval-Infrastruktur existiert. SuperGLEBer, das Occiglot Euro-LLM-Leaderboard und MMLU-ProX über 29 Sprachen decken Deutsch ab (ACL Anthology). Was fehlt, ist ein publizierter Kopf-an-Kopf-Vergleich genau dieser vier auf deutschem Text. Qwen3 wurde auf 119 Sprachen trainiert und ist die Familie mit der breitesten belegten Mehrsprachigkeit (Qwen); für Kimi, Nemotron und Minimax nennen die Anbieter Deutsch nicht eigens als Schwerpunkt.

Die praktische Konsequenz ist unbequem, aber klar: Benchmark-Plätze auf englischen Tests sagen wenig über die Qualität auf euren deutschen Verträgen, Angeboten oder Support-Texten. Der einzige belastbare Test ist der auf eurem eigenen Material. Wie man Leaderboards überhaupt liest, ohne sich täuschen zu lassen, steht im Beitrag zum lokalen Modell.

Was auf eurer Hardware läuft

Die Hardware-Passung sortiert das Feld schneller als jeder Benchmark, weil ein Modell, das nicht auf eure Karten passt, schlicht ausscheidet.

Qwen3 ist hier die Ausnahme. Die dichten Varianten von 4B bis 32B laufen quantisiert auf ein bis zwei GPUs, und die 30B-A3B-MoE-Variante liefert Modellqualität bei nur rund 3B aktiver Rechenlast. Das ist der Zuschnitt, der zu einer typischen On-Prem-Box im Mittelstand passt.

Kimi K2 und Minimax M2 sind Frontier-MoE-Modelle. Minimax aktiviert zwar nur 10B Parameter, doch die vollen Gewichte verlangen einen Mehr-GPU-Server; Kimi mit 1 Billion Gesamtparametern erst recht. Nemotron 3 Nano ist mit 3,6B aktiven Parametern sehr sparsam und läuft auf einer Karte, fällt aber wegen der Lizenz zurück. Was diese VRAM-Realität konkret kostet, haben wir im Hardware-Beitrag durchgerechnet.

Die Geopolitik liegt in den Gewichten, nicht in der API

Bei Open-Weight-Modellen verschiebt sich die Souveränitätsfrage: Die Gewichte laufen vollständig offline, also gibt es keinen entfernten Abschalter. Was bleibt, ist das, was im Modell eingebacken ist.

Drei der vier Labore sind chinesisch (Qwen, Kimi, Minimax), eines US-amerikanisch (Nemotron). Weil die Gewichte lokal laufen, ist die eigentliche Frage nicht der Serverstandort, sondern die Ausrichtung im Modell selbst. Unabhängige Tests berichten von hohen Ablehnungsraten chinesischer Modelle bei politisch heiklen Themen, am stärksten in chinesischer Sprache und schwächer, aber vorhanden, auf Deutsch (ChinaBench). Diese Zahlen sind selbst publiziert und nicht peer-reviewed, also vorsichtig zu lesen, aber der Effekt ist real genug für einen ehrlichen Absatz im Lastenheft.

Für reine B2B-Textarbeit, also Entwürfe, Extraktion, Klassifikation und Retrieval über eure eigenen Dokumente, ist dieser Effekt meist beherrschbar. Es ist eine Frage der Ausgabequalität und der Außenwirkung, nicht ein Sicherheitsleck. Den größeren Souveränitätsbogen, europäische Modelle und was das Label wirklich wert ist, ziehen wir im Beitrag zu souveräner europäischer KI.

Wie ich das für einen Mittelständler entscheide

Die Entscheidung ist nicht patriotisch und nicht vom Leaderboard getrieben, sie folgt einer Reihenfolge. So gehe ich vor:

1. Lizenz prüfen. Nur Modelle mit echtem Apache- oder MIT-Grant kommen ohne juristische Rückfrage in die engere Wahl. Das sind hier Qwen3, Kimi K2 und Minimax M2.
2. Auf eigenem Deutsch testen. Nicht das englische Benchmark, sondern fünfzig eurer realen Texte gegen zwei Kandidaten laufen lassen und blind bewerten.
3. Hardware abgleichen. Was auf eure ein bis zwei Karten passt, gewinnt fast immer, weil der Betrieb sonst teuer und fragil wird.

Für die meisten Mittelständler landet das bei Qwen3 als Startpunkt: frei lizenziert, breit mehrsprachig, im richtigen Hardware-Fenster. Kimi und Minimax sind die Wahl, wenn der Server ohnehin steht und Reasoning oder Agenten im Vordergrund stehen. Das Open-Weight-Coding-Modell Kimi K2.7 haben wir dafür eigens angeschaut.

Und, wie immer bei uns: baut die Architektur so, dass ihr das Modell tauschen könnt. Das nächste bessere Open-Weight-Modell kommt bestimmt. Die eigentliche Frage ist nicht, welches heute vorne liegt, sondern welche eurer Aufgaben überhaupt das stärkste Modell brauchen und welche nur ein gutes, das euch gehört. Welche eurer Texte würdet ihr einem Modell anvertrauen, das ihr nicht selbst getestet habt?

Dieser Beitrag ist die Praktiker-Fassung dieses Aufbaus und die ehrliche Fassung seiner Grenzen.

Der Vault ist das Gut, der Agent ist gemietet

Halten Sie das Haltbare und das Austauschbare getrennt, und der Großteil des Designs folgt daraus.

Das Haltbare ist Ihr Vault: schlichte .md-Dateien, [[Wikilinks]], YAML-Frontmatter. Keine Datenbank, kein proprietäres Format, kein Export-Schritt. Das Austauschbare ist der Agent, der ihn liest. Die zwei führenden Community-Projekte in diesem Feld, obsidian-second-brain und obsidian-mind, liefern beide bewusst für Claude Code, Codex CLI und Gemini CLI. Der Vault ist die Investition; das Modell ist ein Mieter, den Sie kündigen können.

Das ist dieselbe Überlegung, die wir aufs Verdrahten von KI in jeden Stack anwenden: die Schnittstelle besitzen, die Fähigkeit mieten. Wir haben sie für die Systemintegration in API, MCP oder CLI aufgeschrieben. Persönliches Wissensmanagement ist dasselbe Argument im Schreibtischmaßstab.

Was sich ändert, wenn ein Agent Ihre Notizen lesen kann

Ein Agent mit Dateizugriff verwandelt einen statischen Vault in einen, der sich selbst pflegt, innerhalb der Grenzen, die Sie setzen.

• CLAUDE.md ist das Betriebshandbuch. Führen Sie claude aus dem Vault-Wurzelverzeichnis aus, und es lädt diese Datei in jeder Sitzung: Ihre Ordnerkarte, Ihre Verlinkungskonventionen, Ihre Notizvorlagen, Ihre Standardverhalten. Es ist die einzige tragende Datei in jedem funktionierenden Aufbau. /init schreibt einen ersten Entwurf.
• Sitzungskontext ist ein Hook, keine Magie. obsidian-mind injiziert beim Sitzungsstart einen Nordstern-Auszug, eine Aufgabenliste und eine Dateiauflistung, damit der Agent nicht leer beginnt. Das ist ein SessionStart-Hook, der auf Ihrer Maschine läuft, mehr nicht.
• Ablegen wird zum Skill. Slash-Commands und Subagents erledigen die Pflichten: eine geclippte Notiz in den richtigen Ordner ablegen, eine Map of Content erzeugen, verwaiste Notizen finden, das Tageslog schreiben. obsidian-second-brain liefert Dutzende davon.
• Frontmatter ist die maschinenlesbare Schicht. Datum, Status, Quelle, ein Konfidenzmarker in YAML plus Wikilinks geben dem Agenten Struktur zum Abrufen und Querverweisen, statt aus Prosa zu raten.

Die neueste Verschiebung sind Notizen, die überschreiben statt anhängen: eine neue Quelle aktualisiert und gleicht bestehende Notizen ab, statt einen weiteren datierten Eintrag zu stapeln. Nützlich, und die erste Stelle, an der Vorsicht angebracht ist, das ist der übernächste Abschnitt.

Retrieval, nicht Abladen: die Token-Realität

Laden Sie nicht den ganzen Vault. Lassen Sie den Agenten die wenigen Notizen holen, die eine Frage braucht.

Der naive Aufbau schiebt den Vault in den Kontext und bricht bei ein paar Hundert Notizen zusammen. Der sparsame Aufbau lässt alles auf der Festplatte und zieht nur, was passt, per Kommandozeilensuche oder grep. Praktiker berichten die Lücke als rund 100 Token für eine CLI-Vault-Suche gegen Zehntausende für das Laden eines Projekts als Ganzes. Die Mechanik ist unglamourös: suchen, die drei passenden Notizen lesen, antworten.

Das zählt weiterhin, auch wenn Claude Code nun ein Kontextfenster von einer Million Token betreibt. Das rollende Ratenlimit beißt lange, bevor das Fenster voll ist, ein Vault, der in 100 Token antwortet, lässt Sie hundert Fragen stellen, wo der Alles-abladen-Aufbau Ihnen eine Handvoll gibt. Sparsames Retrieval ist es, was ein zweites Gehirn täglich brauchbar macht statt einmal beeindruckend.

Die Datenschutzlinie ist die Inferenz, nicht die Speicherung

Die Community verkauft "alles bleibt in Ihrem Vault, kein SaaS". Das stimmt für die Speicherung und ist falsch für die Inferenz, und der Unterschied ist das ganze Risiko.

Ihr Markdown bleibt auf Ihrer Festplatte. Aber standardmäßig sendet jede Anfrage die relevanten Notizen zum Lesen an eine Cloud-API. Für einen Hobby-Vault mit Rezepten in Ordnung. Für einen Vault mit Kundennotizen, Verträgen oder allem, was einem AVV unterliegt, verlassen bei jeder Frage Daten das Haus. Schlicht-Markdown-Portabilität ist nicht dasselbe wie lokaler Datenschutz.

Zwei weitere ehrliche Vorbehalte. Prompt Injection ist strukturell: ein Agent, der Ihre Notizen liest, kann "Anweisungen" nicht sauber von "Inhalt" trennen, jedes Markdown, das in den Vault gelangt, eine geclippte Webseite, eine geteilte Notiz, ein aufgenommenes PDF, kann Anweisungen tragen, nach denen er dann handelt. Und das Risiko ist nicht hypothetisch: im April 2026 missbrauchten Angreifer Obsidian-Community-Plugins, um Code auszuführen, wenn ein Opfer einen geteilten Vault öffnete, berichtet von The Hacker News. Ein Agent mit Datei-Schreib- und Shell-Zugriff erhöht diesen Einsatz, senkt ihn nicht. Sich selbst überschreibende Notizen können auch still einen Backlink erfinden oder eine korrekte Zeile überschreiben, und die Änderung ist gespeichert, bevor Sie sie lesen.

Dasselbe Muster, souverän gehalten

Alles Gute an diesem Aufbau überlebt, wenn Sie das Modell ins Haus holen. Das Datenschutzproblem ist der einzige Teil, der die Änderung braucht.

Die souveräne Fassung behält den Vault und den Workflow und tauscht Cloud-Inferenz gegen ein lokales Modell: eine Retrieval-Schicht über Ihrem Markdown, bedient von einem Modell auf Ihrer eigenen Hardware oder in EU-Hosting. Sie behalten die Klartext-Hoheit, das CLAUDE.md-Betriebshandbuch, die Skills, und Sie hören auf, die Inhalte bei jeder Frage hinauszusenden. Für eine Mittelstandsfirma ist das die Brücke von einem persönlichen Experiment zu echtem internem Wissensmanagement, Produkthandbücher, Prozessdoku, Servicehistorie, ohne dass eine AVV-Frage über jeder Anfrage hängt. Wann sich dieser Schritt lohnt und was er kostet, ist das Thema von On-Premise vs. Cloud-LLM.

Die Hobbyisten-Rahmung lautet "baue ein zweites Gehirn". Die geschäftliche Rahmung ist dieselbe Maschine, gerichtet auf das Wissen des Unternehmens statt auf Ihres. Die interessante Frage ist, wieder, nicht, ob es funktioniert. Es ist, wer die Notizen lesen darf. Also: wohin sendet Ihr Vault gerade jetzt tatsächlich seine Fragen?

Dieser Beitrag ordnet beide ein: was schon stark ist, wo es hakt, und was daraus für ein Unternehmen vor Ort folgt.

Die Forschung ist da, und sie ist dicht

Die Forschungsseite muss sich vor keinem Bundesland verstecken. Sie ist nur stark konzentriert.

Kaiserslautern trägt den Kern: Hauptstandort des DFKI, die RPTU mit acht KI-Professuren, Fraunhofer IESE und ITWM, dazu eine Kooperation mit dem Max-Planck-Institut. Das bundesweit erste KI-Innovations- und Qualitätszentrum der Mission KI sitzt ebenfalls hier, mit 32 Mio. Euro Bundesbudget. Koblenz baut den zweiten Pol: die Universität hat im Juli 2025 einen interdisziplinären KI-Hub gestartet, die Hochschule Koblenz betreibt mit DigiMit ein Kompetenzzentrum für die Region.

Die ehrliche Einordnung steht gleich daneben. Das Cluster ist KL- und Koblenz-gewichtet, die Fläche ist schwächer angebunden, und im bundesweiten Vergleich liegt RLP im Vorderfeld, nicht an der Spitze. Bei Digitalisierung führen Bayern, Berlin und Hamburg, bei Innovation Baden-Württemberg.

Das Land setzt selbst auf souveräne KI

Bemerkenswert ist, womit das Land arbeitet: nicht mit einem US-Cloud-Abo, sondern mit einer eigenen, souveränen Linie.

Die KI-Agenda des Landes nennt einen KI-Dreiklang, und eine der drei Säulen heißt ausdrücklich LLM On-Premise. Mit GPU4GenAI investiert das Land in eigene GPU-Infrastruktur am DFKI, und seit September 2025 läuft eine auf drei Jahre angelegte Kooperation mit dem DFKI, die KI in die Landesverwaltung bringt: Dokumentenauswertung, sichere Datenplattformen, Assistenzsysteme.

Das ist mehr als eine Randnotiz. Wenn die öffentliche Hand in RLP datenschutzkonforme, lokal betriebene KI baut, dann ist On-Premise- und Souveränitäts-Beratung für den Mittelstand kein Nischenthema, sondern ein Anschlussthema an das, was das Land vormacht. Die Grafik unten zeigt das Grundproblem: starke Knoten, zu wenige Linien in die Fläche.

Im Mittelstand sieht die Lage anders aus

An der Werkbank ist die Geschwindigkeit eine andere, und die Zahlen sind nüchtern.

In einer Befragung der Hochschule Koblenz im nördlichen RLP (176 Unternehmen, Dezember 2025) bewerten nur 8,5 Prozent KI heute als zentral fürs Geschäftsmodell, in fünf Jahren immerhin 42 Prozent. Über ein Viertel nutzt bereits KI-Werkzeuge, rund die Hälfte testet in Pilotprojekten. Eine zweite regionale Studie von IHK und Handwerkskammer Koblenz zeigt das eigentliche Muster: knapp zwei Drittel nutzen KI, davon die meisten erst seit höchstens zwei Jahren, fast 90 Prozent setzen dabei auf externe Software, und die größte genannte Herausforderung ist die Rechtssicherheit.

Spitzenforschung und Diffusion in die Breite sind also zwei verschiedene Dinge. Das eine ist hier vorhanden, das andere noch nicht.

Die Lücke ist die Umsetzung, nicht die Technik

Das Hindernis im Mittelstand ist selten das Modell. Es ist der Weg von der Idee zum sicheren, produktiven Einsatz.

Bundesweit haben nur rund ein Drittel der Unternehmen eine ausgearbeitete KI-Strategie, in RLP wird wiederholt fehlendes Fachwissen als Bremse genannt. Und die fast 90 Prozent, die auf externe Software setzen, kaufen damit Abhängigkeit ein, oft von US-Cloud-Diensten, genau dort, wo dieselben Unternehmen Rechtssicherheit als größte Sorge angeben. Das ist ein Widerspruch mit Ansage.

Eine ehrliche Relativierung gehört dazu: Nutzungsquoten überzeichnen die Reife. Vieles ist informeller Gebrauch frei verfügbarer Werkzeuge, ohne Strategie, ohne Governance, ohne klaren Datenschutzrahmen. Die Frage ist im Mittelstand längst nicht mehr KI ja oder nein. Sie lautet souverän und produktiv statt informell und riskant. Was das praktisch heißt, haben wir im praktischen KI-Fahrplan für den Mittelstand ausbuchstabiert.

Was das für Unternehmen in RLP heißt

Die naheliegende Strategie ist die, die das Land bereits fährt: Nutzen einsammeln, ohne die Datenhoheit abzugeben.

Der fehlende Baustein ist nicht ein weiteres Werkzeug, sondern die Schicht zwischen Förderung und Forschung auf der einen und produktivem, souveränem Einsatz auf der anderen Seite. Konkret heißt das: lokale oder in Deutschland gehostete Modelle für sensible Daten, RAG-Wissensmanagement auf dem eigenen Dokumentenbestand, und ein nüchterner Pfad von der Use-Case-Auswahl bis zum Pilotbetrieb. Wann sich lokale KI gegenüber der Cloud lohnt, ordnen wir in On-Premise vs. Cloud-LLM ein.

Wir bei iiterate sitzen in Koblenz und Remagen, also mitten im zweiten KI-Pol des Landes, und genau diese Diffusionsschicht ist unsere Arbeit: Strategie, Bau und Compliance zusammenbringen, statt Mittelständler zwischen Förderbescheid und Werkbank allein zu lassen. Die Forschung in RLP ist gesetzt. Die spannendere Frage ist, wie schnell sie in der Fläche ankommt, und wer dafür die Linien zieht.

Dieser Text erklärt, warum langer Kontext teuer ist, welche subquadratischen Ansätze es gibt, was die lautesten Versprechen davon belegt sind, und was das konkret fürs On-Prem-RAG bringt. Die Empfehlung am Ende ist unspektakulär und genau deshalb tragfähig.

Warum langer Kontext teuer ist

Der Grund liegt in der Mathematik der Selbstaufmerksamkeit: ihr Aufwand wächst quadratisch mit der Länge der Eingabe.

In einem klassischen Transformer vergleicht jeder Token jeden anderen. Verdoppelt sich die Kontextlänge, vervierfacht sich grob der Rechenaufwand für die Aufmerksamkeit. Dazu kommt der Speicher: der Schlüssel-Wert-Cache, den das Modell während der Generierung mitführt, wächst linear mit der Länge und frisst auf einer festen GPU schnell den verfügbaren Speicher. Das ist der eigentliche Engpass beim On-Prem-Betrieb, wo die Hardware gesetzt ist und nicht elastisch dazugemietet wird.

Genau hier setzen subquadratische Ansätze an. Sie versuchen, die Sequenzkosten Richtung linear zu drücken, also O(n) statt O(n hoch zwei), und den Speicher pro Token zu begrenzen. Was das für die Hardware-Realität im Unternehmen bedeutet, haben wir in lokales LLM durchgerechnet.

Die subquadratische Landschaft

Es gibt mehrere Wege, und der praktische Gewinner der Jahre 2024 bis 2026 ist nicht der reinste, sondern der hybride.

• Zustandsraum-Modelle (Mamba). Mamba (Dezember 2023) und Mamba-2 (Mai 2024) modellieren Sequenzen in linearer Zeit mit einem festen Zustandsspeicher statt eines wachsenden Caches (arXiv). Der Preis: ein fester Zustand ist ein verlustbehafteter Kompressor und schwächer beim exakten Erinnern weit zurückliegender Stellen.
• Lineare Aufmerksamkeit (RWKV, RetNet). Formulieren die Aufmerksamkeit so um, dass die Kosten etwa linear wachsen. Ähnlicher Kompromiss bei der assoziativen Erinnerung.
• Hybride in Produktion. Niemand liefert reine subquadratische Modelle in Spitzenqualität aus. Stattdessen mischen alle eine Minderheit voller Aufmerksamkeits-Schichten mit einer Mehrheit aus Zustandsraum- oder linearen Schichten: Jamba (AI21, 2024), MiniMax-01 (Januar 2025), Falcon-H1 (Mai 2025), NVIDIAs Nemotron-H, IBM Granite 4.0 (Oktober 2025) und Qwen3-Next (September 2025). Die vollen Schichten bewahren die Erinnerung, die schlanken kaufen den Kosten- und Speichervorteil.

Die NVIDIA-Linie hinter Nemotron, die genau diesen hybriden Aufbau nutzt, haben wir in Nemotron 3 beschrieben.

Was 'subQ' verspricht, und was davon belegt ist

Der Begriff verlangt Vorsicht, denn er trägt zwei Bedeutungen, eine architektonische und eine vermarktete.

Neben der allgemeinen subquadratischen Familie gibt es ein konkretes Produkt: das Start-up Subquadratic kam im Mai 2026 mit einer Finanzierung von rund 29 Millionen Dollar aus dem Verborgenen und wirbt mit einer subquadratischen, sparsamen Aufmerksamkeit. Die Schlagzeilen sind groß: ein Forschungsmodell mit 12 Millionen Token Kontext, rund ein Fünftel der Kosten gegenüber Spitzenmodellen, ein Vielfaches an Geschwindigkeit (The New Stack).

Die ehrliche Einordnung: ein Teil ist von Dritten geprüft, etwa ein RULER-128K-Ergebnis, die spektakulären Zahlen zu 12 Millionen Token und zum Geschwindigkeitsfaktor sind dagegen Anbieterangaben aus Einzeldurchläufen und nicht unabhängig reproduziert. Das ist ein vielversprechender Hinweis, keine Beschaffungsgrundlage. Genau diese Trennung, belegt gegenüber behauptet, ist die Disziplin, die wir bei jedem neuen Modell anlegen.

Was das fürs On-Prem-RAG bringt

Der konkrete Gewinn ist Speicher und Durchsatz auf fester Hardware, und das ist für On-Prem-RAG genau die richtige Stellschraube.

• Begrenzter Cache, planbarer Speicher. Die Zustandsraum-Schichten tragen einen festen Zustand, der Speicher explodiert also nicht mit der Länge. IBM nennt für Granite 4.0 über 70 Prozent weniger Bedarf bei langem Kontext, eine Herstellerangabe, aber plausibel und in Richtung mehr gleichzeitiger Sitzungen pro GPU.
• Modell und Kontext auf einer Karte. NVIDIA berichtet, dass ein Nemotron-H-Modell mit 51 Milliarden Parametern samt Cache in eine einzelne 80-GB-Karte passt, ebenfalls eine Herstellerangabe.
• Lockerere Chunking-Disziplin. Günstigerer Kontext erlaubt größere Fenster und weniger ängstliches Zerschneiden der Dokumente.

Ehrliche Vorbehalte gehören dazu. Bei erinnerungslastigem RAG, etwa der exakten Fundstelle über sehr lange Texte, liegen reine subquadratische Modelle noch hinter voller Aufmerksamkeit, Hybride schließen die Lücke weitgehend, aber nicht ganz. Das Werkzeug-Umfeld, also Quantisierung, Serving und Feintuning, hinkt den etablierten dichten Modellen hinterher. Und der wichtigste Satz: langer Kontext ist nicht gleich gutes Retrieval. Ein solides Modell mit gutem RAG schlägt heute fast immer den Versuch, einfach Millionen Token hineinzukippen. Was RAG überhaupt leistet, steht in Was ist RAG und Die Kraft von RAG.

Wie ich das heute behandle

Subquadratisch ist beobachten wert, aber keine Wette wert. So gehe ich damit um:

1. Die RAG-Schicht modellunabhängig bauen. Hinter einer stabilen Schnittstelle, sodass sich ein Hybrid der Granite-4-Klasse einsetzen lässt, sobald das Werkzeug-Umfeld reif ist.
2. Mit einem soliden, gut unterstützten Modell starten, nicht mit der neuesten Architektur, und den Wert aus der Retrieval-Qualität holen.
3. Unbelegte Versprechen ignorieren. Ein behaupteter Faktor von tausend wartet, bis ihn jemand Unabhängiges reproduziert.

Das ist dasselbe Muster, das wir bei On-Prem gegen Cloud ziehen: bewusst entscheiden, tauschbar bauen (On-Premise vs. Cloud-LLM). Die spannende Frage ist nicht, ob subquadratische Modelle eines Tages den langen Kontext billig machen. Sie werden es vermutlich. Die Frage ist, ob eure Architektur bereit ist, den Gewinn mitzunehmen, ohne dass ihr heute darauf wettet. Ist eure RAG-Schicht so gebaut, dass ihr das Modell tauschen könnt, ohne alles neu zu schreiben?

Die meisten Teams, die KI in ihre Systeme einbinden, müssen keinen Sieger küren. Sie müssen jeden Aufruf auf die richtige Höhe legen. Dieser Beitrag definiert die drei nüchtern, zeigt, wann welche passt, benennt die oft übersehenen Kosten und endet mit einer Entscheidung, die Sie vertreten können. Zwei Fragen klären das meiste: Wie viele Integrationen betreiben Sie, und wer muss sie prüfen?

Drei Ebenen, keine drei Rivalen

Jedes Muster liegt auf einer anderen Abstraktionsebene, mit einem klaren Kompromiss zwischen Kontrolle und Bequemlichkeit.

• Ein direkter API-Aufruf ist der unterste Baustein. Ihr Code ruft ein Modell oder einen Dienst über HTTP auf. Sie erhalten maximale Kontrolle und Standard-Werkzeuge und schreiben den Klebstoff selbst: Authentifizierung, Anfrage, Antwort-Parsing, Fehlerbehandlung.
• MCP, das Model Context Protocol, standardisiert die Verbindung, nicht das Modell. Es ist ein offener Standard, den Anthropic im November 2024 eingeführt hat und der einem Modell einen einheitlichen Weg gibt, Werkzeuge und Daten zu entdecken und aufzurufen, sodass ein MCP-fähiger Client mit einem MCP-Server sprechen kann, den er noch nie gesehen hat (Wikipedia). Es verbreitete sich schnell: Im Lauf von 2025 wurde es von OpenAI, Google und Microsoft übernommen, erreichte bis April 2025 mehr als 5.800 Community-Server und meldete bis Ende 2025 zweistellige Millionenzahlen an monatlichen SDK-Downloads, bevor Anthropic es an eine Initiative der Linux Foundation übergab (Thoughtworks, The New Stack).
• Eine agentische CLI ist die oberste Ebene. Ein Werkzeug wie Claude Code bündelt ein Modell, eine Reihe von Werkzeugen und eine Reasoning-Schleife zu einem Terminal-Workflow. Am wenigsten Klebstoff, am meisten Meinung, am schnellsten für offene Aufgaben.

Sie ergänzen einander, statt zu konkurrieren: Eine agentische CLI kann MCP-Server aufrufen, die ihrerseits schlichte APIs kapseln (iiterate).

Wann jede auf der richtigen Höhe liegt

Die Wahl folgt der Form der Aufgabe, nicht der Neuheit der Option. Eine kurze Orientierung:

In der Praxis: Ein nächtlicher Batch-Job, der einen Endpunkt anspricht, sollte die API direkt aufrufen, weil MCP ohne Nutzen nur Latenz und Fehlerquellen hinzufügen würde. MCP rechtfertigt sich, sobald mehrere Agenten dieselben Integrationen brauchen, sodass jeder MCP-Client eine einheitliche Schnittstelle erhält, statt dass jeder Agent seinen eigenen Wrapper trägt. Den Kipppunkt, den Praktiker berichten, liegt bei etwa drei oder mehr KI-angebundenen Integrationen (MindStudio). Eine agentische CLI passt, wenn die Aufgabe offen ist und jemand über viele Werkzeuge hinweg schnell Ergebnisse braucht.

Die Kosten, die man übersieht

Die offensichtlichen Vorteile sind leicht zu finden. Die leiseren Kosten entscheiden, ob eine Wahl gut altert.

• Tokens. Eine standardisierte Werkzeugebene ist nicht kostenlos. Wenn ein Agent ein Werkzeug wiederholt aufruft, kann der Discovery-Overhead von MCP für dieselbe Aufgabe weit mehr Tokens kosten als ein direkter CLI- oder API-Aufruf (MindStudio).
• Beobachtbarkeit. HTTP-Aufrufe erscheinen in Ihren Logs, und Standard-Werkzeuge wie Datadog verfolgen sie kostenlos. Der MCP-Transport ist vergleichsweise undurchsichtig, und das Monitoring im Produktivbetrieb reift noch, sodass Sie mit eigener Instrumentierung bezahlen (IJONIS).
• Lock-in und Portabilität. Eine reine API hält die Integration in Code, der Ihnen gehört. Je höher Sie gehen, desto stärker hängen Sie von einem Client, einem Server-Ökosystem oder dem Agenten eines Anbieters ab. Halten Sie sich einen Weg eine Ebene tiefer offen.

Die Sicherheitsfläche von MCP ist neu und real

Zu standardisieren, wie Modelle Werkzeuge erreichen, standardisiert auch eine neue Angriffsfläche, und die verdient eine ausdrückliche Behandlung.

OWASP führt Prompt Injection 2025 als die wichtigste Schwachstelle für LLM-Anwendungen. MCP fügt eine spezifische Variante hinzu, Tool Poisoning, bei der bösartige Anweisungen in die Beschreibung eines Werkzeugs eingebettet werden, näher an einem Supply-Chain-Angriff auf den Kontext des Agenten als an einem nutzerseitigen Jailbreak, und geführt als CVE-2025-54136 (TrueFoundry). Da MCP-Server oft Zugangsdaten halten und reale Systeme erreichen, ist ein zu weit berechtigter oder nicht vertrauenswürdiger Server ein ernstes Risiko, und der Schutz auf Client-Seite variiert stark (Simon Willison, Microsoft). Die praktische Haltung: geprüfte Server betreiben, jedem das geringste Recht geben und weiter überwachen, dieselben Governance-Fragen, die gelten, sobald ein Agent reale Daten berührt (iiterate).

Eine Entscheidung, die Sie vertreten können

Sie brauchen keine einzige Antwort für das ganze Unternehmen. Sie brauchen die richtige Höhe pro Integration. Eine praktikable Regel:

1. Standardmäßig eine direkte API für einen einzelnen, stabilen Aufruf mit hohem Volumen.
2. Greifen Sie zu MCP, wenn mehrere Agenten dieselben Werkzeuge brauchen oder Sie austauschbare Werkzeuge hinter einer Schnittstelle wollen.
3. Nutzen Sie eine agentische CLI, wenn die Arbeit offen ist und ein Mensch oder ein anderer Agent sie steuert.
4. Behalten Sie auf jeder Ebene das geringste Recht, echte Logs und einen Weg, eine Ebene tiefer zurückzufallen, falls ein Anbieter die Bedingungen ändert.

Für die meisten Produktivsysteme ist die ehrliche Antwort ein Mix: direkte APIs unter den Diensten, MCP als Übersetzungs- und Discovery-Ebene für Agenten und eine CLI dort, wo Menschen arbeiten. Der Fehlermodus ist nicht, das falsche Werkzeug zu wählen. Er ist, die neueste Ebene zu übernehmen, weil sie die neueste ist, und ihre Kosten für eine Aufgabe zu zahlen, die eine niedrigere Ebene besser erledigt hätte.

Der Kern des Beitrags sind nicht die Events. Es ist die Form. event-scout ist eine agentische Micro-App: etwas, das man einmal mit einem Coding-Agenten baut und dann laufen lässt, wobei der Agent das schwierige Urteilen übernimmt und schlichte Skripte die langweilige, wiederholbare Verrohrung erledigen. Diese Aufteilung ist die ganze Lehre, und sie überträgt sich auf fast jede interne Aufgabe, die ein Mittelstandsteam weiterhin von Hand erledigt. event-scout läuft auf der obersten dieser Ebenen, einer agentischen CLI (iiterate).

WAS ES KONKRET TUT

Einmal pro Durchlauf arbeitet sich event-scout durch eine kuratierte Quellendatenbank aus Event-Seiten, Kalendern, Newslettern und einigen LinkedIn-Feeds. Aus allem, was es abruft, behält es nur zukünftige Präsenzveranstaltungen in Reichweite von Remagen, bewertet jede danach, wie nützlich sie für uns ist, entfernt Dubletten in einen einzigen Speicher und baut ein Dashboard neu auf, das wir tatsächlich öffnen.

Wenig an dieser Liste ist für sich genommen neu. Was es zum Laufen bringt, ist, dass es unbeaufsichtigt nach einem Zeitplan läuft und dass das angewandte Urteil unseres ist, kein generischer Relevanzfilter. Das Ergebnis ist kein Feed jedes Tech-Events in Deutschland. Es ist eine kurze, gereihte Antwort auf eine Frage: wo sollten wir als Nächstes auftreten.

DIE FORM, DIE ES ZUM LAUFEN BRACHTE: AGENT FÜRS URTEIL, SKRIPTE FÜR DIE VERROHRUNG

Die Design-Entscheidung, die zählt, ist, wo das Modell aufhört und ein Skript anfängt.

Das Abrufen ist an einen deterministischen Helfer delegiert. Ein kleiner Node-Orchestrator rendert jede fällige Quelle in einem echten Headless-Browser, sodass er JavaScript-Seiten, leichte Anti-Bot-Wände und träge nachgeladene Listen bewältigt, und er erfasst strukturierte schema.org-Event-Daten, wenn eine Seite sie freigibt. Das ist Verrohrung: verlässlich, planbar und jedes Mal gleich.

Der Agent liest, was der Abrufer gespeichert hat, und erledigt die Teile, die sich fester Kodierung entziehen: echte Events aus chaotischen Seiten herausziehen, entscheiden, was als Präsenz und relevant zählt, jedes bewerten und erkennen, dass zwei Einträge dasselbe Event sind. Eine zweite kleine Engine führt dann zusammen, entfernt alte Einträge und erzeugt das Dashboard neu.

🔸 Lassen Sie das Modell nicht tun, was ein Skript günstig erledigt.
Eine Seite zu rendern und eine Datei zu schreiben ist deterministische Arbeit. Sie dem Modell zu übergeben wäre langsamer, teurer und weniger verlässlich.

🔸 Lassen Sie ein Skript nicht tun, was Urteil verlangt.
Ob ein halb formatierter Eintrag ein echtes, relevantes Präsenz-Event ist, ist genau die Entscheidung, in der ein Modell gut ist und ein regulärer Ausdruck nicht.

Diese Linie richtig zu ziehen ist der größte Teil davon, warum das Werkzeug verlässlich ist und nicht bloß eine schlaue Demo.

ES STIMMT SICH SELBST AB

Ein Scout, der jede Quelle bei jedem Durchlauf gleich prüft, verschwendet den größten Teil seiner Mühe, weil Events nicht gleichmäßig auftauchen.

Also trägt jede Quelle ihre eigene kurze Ertragshistorie. Quellen, die verlässlich relevante Events liefern, werden bei jedem Durchlauf geprüft. Quellen, die immer wieder leer zurückkommen, weichen auf eine wachsende Abkühlphase aus, eine Woche, dann zwei, dann einen Monat, und werden nach deren Ablauf erneut getestet statt verworfen. Eine Quelle, die schlicht keine Events lieferte, wird still zurückgestuft; nur eine Quelle, die mehrmals hintereinander nicht lädt, wird als defekt ausgemustert.

Der Effekt ist, dass die Aufmerksamkeit dorthin fließt, wo Events tatsächlich auftauchen, und dass es sich über Wochen von selbst justiert, ohne dass es jemand pflegt. Diese Selbstabstimmung ist es, die unbeaufsichtigt zu einer echten Aussage macht und nicht zu einer hoffnungsvollen.

MEINUNGSSTARKE BEWERTUNG SCHLÄGT EINEN GENERISCHEN FEED

Die Bewertung ist bewusst unsere. Jedes Event bekommt einen Wert von 100, gewichtet für unsere Lage: wie nah und leicht erreichbar es ist, wie dicht der Raum die Art von Käufern versammelt, die wir bedienen, wie intim es ist, ob es einen konkreten Hebel wie einen Rabatt oder einen Redeslot gibt und wie bald es stattfindet.

Die Gewichtung trägt eine Meinung, die wir über Vertrieb haben. Eine große Konferenz rangiert nur dann hoch, wenn es einen echten Hebel zu nutzen gibt, denn für beziehungsgeführten Verkauf ist ein voller Saal ohne Zugang weniger wert als ein kleiner regionaler Runder Tisch, an dem wir tatsächlich mit Menschen sprechen können. Das Ergebnis liest sich als Entscheidungs-Cockpit statt als Kalender: es zeigt, wo man einen Tag investieren sollte, nicht alles, was existiert.

Ein generischer Event-Feed könnte das nicht abbilden, weil das Urteil spezifisch dafür ist, wie ein bestimmtes Team Aufträge gewinnt. Diese Spezifität ist der Grund, warum es sich zu bauen lohnte statt zu kaufen.

WARUM EINE MICRO-APP, KEIN SAAS

event-scout ist absichtlich klein. Das Ganze ist eine Handvoll JSON-Dateien für die Quellen und den Event-Speicher, ein paar Skripte und ein eigenständiges HTML-Dashboard, das direkt von der Festplatte öffnet. Es gibt keine Datenbank zu betreiben und kein Abonnement zu erneuern. Die Daten bleiben unsere, und die Bewertung auch.

Das ist derselbe Schritt, den Anthropics eigene Nicht-Engineering-Teams beschrieben haben, kleine interne Werkzeuge mit einem Coding-Agenten zu bauen, statt eine Anfrage einzureichen und zu warten (claude.com). Wir haben über dieses Muster auch aus Nutzersicht geschrieben (iiterate).

Es ist nicht frei von rauen Kanten, und das Gegenteil zu behaupten wäre unredlich. Login-geschützte Quellen brauchen einmal eine von Hand erfasste Sitzung. Ein paar sture Seiten bleiben manuelle Leads statt falscher Ergebnisse. Und wir prüfen jeden Neuaufbau, indem wir die Struktur der Seite direkt kontrollieren, weil ein Screenshot an einem Font-Ladevorgang hängen bleibt. Nichts davon ändert das Fazit: Wenn eine Aufgabe wiederholbar und spezifisch für Ihre Arbeitsweise ist, kann ein Coding-Agent sie in ein kleines Werkzeug im eigenen Besitz verwandeln, für weniger als das SaaS oder die manuellen Stunden, die es ersetzt. Die schwierigere Frage ist nicht, ob Sie eines bauen können. Es ist, welche Ihrer wöchentlichen Pflichten still darauf gewartet hat, eines zu werden.

Claude Code ist für Entwickler gebaut, aber die Arbeit, die es uns still abgenommen hat, liegt im Marketing und im Backoffice: die wiederkehrenden, regelgebundenen Aufgaben, die niemand gern macht. Der Grund, warum es dort passt, ist einfach. Jemand, der einen Ablauf kennt, die Markenregeln, die Monatsabschluss-Checkliste, die Art, wie wir einen Kampagnen-Export taggen, schreibt diesen Ablauf einmal in klarer Sprache auf, und der Agent führt ihn an echten Dateien aus. Kein Softwareprojekt, kein Entwickler im Spiel. Dieser Beitrag ist, was wir gelernt haben: wo sich das auszahlt, wo nicht, und wie man reuefrei beginnt.

Der eigentliche Wandel ist nicht Coding. Es ist, den Ablauf aufzuschreiben

Für eine Nicht-Entwicklerin ist ein Coding-Agent ein Weg, einen wiederkehrenden Ablauf in etwas zu verwandeln, das eine Maschine ausführt, ohne zuerst Software zu bauen.

Der Mechanismus, der das außerhalb der Entwicklung möglich macht, sind Agent Skills. Ein Skill ist ein kleiner Ordner: eine Anweisungsdatei in klarer Sprache, optional ein oder zwei Skripte und das nötige Referenzmaterial. Der Agent sieht nur den Namen eines Skills und eine einzeilige Beschreibung, bis Ihre Aufgabe ihn braucht, dann liest er die vollständigen Anweisungen bei Bedarf. Simon Willison, der das Format bei seiner Veröffentlichung im Oktober 2025 dokumentierte, brachte die Ökonomie klar auf den Punkt: Jeder Skill kostet nur ein paar Dutzend Tokens, bis er genutzt wird (simonwillison.net, Anthropic).

Die Konsequenz ist der Teil, der für ein Mittelstands-Team zählt:

🔸 Die Autorin ist eine Fachexpertin, keine Programmiererin.
Die Person, die den Prozess kennt, schreibt den Skill, so wie sie einen neuen Mitarbeiter einweisen würde.

🔸 Connectors geben ihm echte Reichweite.
Über MCP, einen offenen Connector-Standard, kann der Agent in echten Systemen lesen und handeln, in einer Tabelle, einem gemeinsamen Laufwerk, einer Ticket-Warteschlange, im Rahmen des Zugriffs, den Sie gewähren.

🔸 Sie bestimmen den Wirkungskreis.
Er berührt nur, was Sie ihn berühren lassen. Diese Berechtigungsgrenze ist das ganze Spiel, und wir kommen weiter unten darauf zurück.

Drei unspektakuläre Aufgaben, bei denen es sich wirklich auszahlt

Die Gewinne sind unglamourös und wiederkehrend. Drei Muster haben sich bei uns und in der öffentlichen Berichterstattung bewährt.

Marketing-Varianten in großer Zahl. Anthropics eigenes Growth-Marketing-Team verband zwei spezialisierte Sub-Agenten, um eine CSV mit Hunderten laufenden Anzeigen zu lesen, die schwachen zu markieren und frische Varianten innerhalb strenger Zeichengrenzen zu schreiben, Minuten Arbeit statt Stunden. Ein begleitendes Figma-Plugin erzeugt bis zu 100 Layout-Varianten pro Durchlauf, indem es Überschriften und Beschreibungen austauscht (claude.com). Es ist ihr eigenes Team, lesen Sie es also als Beleg, dass das Muster funktioniert, nicht als Ihre Zahl.

Aufräumen von Backoffice-Daten. Die zähe Wochenmitte: eine Kartenabrechnung in eine Spesenaufstellung überführen, eine unordentliche Liste bereinigen, einen wiederkehrenden Bericht aus einer Vorlage entwerfen. Ein einzelner, nicht technischer Gründer auf r/SaaS beschrieb, wie er praktisch seinen gesamten SEO-Betrieb über Claude laufen ließ, und berichtete von 1,54 Millionen Sucheinblendungen und 12.900 Klicks in drei Monaten, ohne Entwickler und ohne Agentur (r/SaaS). Der Bericht einer einzelnen Person, aber ein aufschlussreicher.

Interne Werkzeuge, gebaut von der Person, die sie braucht. Anthropics Rechtsabteilung prototypte einen kleinen "Telefonbaum", der eine Frage an die richtige Juristin leitet, gebaut von einer Produktjuristin, die keinen Code schreibt (claude.com). Der interessante Teil ist nicht das Werkzeug. Es ist, wer es gebaut hat, und dass dafür kein Ticket nötig war.

Wir haben schon früher darüber geschrieben, wo KI in einem Unternehmen wirklich ihren Platz verdient statt nur gut zu demonstrieren (iiterate); dies ist derselbe Test, angewendet auf ein Werkzeug.

Warum gerade Marketing und Betrieb

Diese Funktionen passen, weil ihre Arbeit wiederkehrend, regelgebunden ist und bereits in Dateien liegt.

Das deckt sich sauber mit dem, was ein Skill fassen kann. Ein Markenrichtlinien-Skill trägt die Palette, die Typo-Regeln und den Tonfall. Ein Prozess-Skill trägt die Abschluss-Checkliste oder einen Compliance-Schritt. Ein Vorlagen-Skill trägt das Dokument selbst. Anthropic liefert einen funktionierenden Markenrichtlinien-Skill als öffentliches Beispiel, mit Farb-, Typografie- und Layout-Regeln, die ein Agent auf Anfrage anwendet (GitHub, Anthropic).

Der wiederkehrende Befund über diese Berichte hinweg ist, dass Fachwissen das Ergebnis stärker treibt als Programmierkönnen. Das ist der stille Vorteil des Mittelstands. Die Person, die den Prozess kennt, ist bereits im Haus, und ein Skill ist nur ihr Prozess, aufgeschrieben.

Wo es das falsche Werkzeug ist

Ein Coding-Agent ist das falsche Werkzeug in dem Moment, in dem die Arbeit aufhört, wiederkehrend, prüfbar oder sicher genug für einen weit berechtigten Agenten zu sein. Die ehrlichen Risiken, in der Reihenfolge, in der sie beißen:

Wirkungskreis. Ein Agent mit Datei- und Systemzugriff kann den falschen Ordner löschen oder die falsche Nachricht senden. Geben Sie ihm das geringste Recht: zuerst nur Lesezugriff, ein Ordner, eine Kopie der Daten, nicht das Original. Sicherheitsteams haben katalogisiert, was schiefgeht, wenn dieser Schritt übersprungen wird (Docker, Oso).

Selbstsichere Falschaussagen. Es wird eine Zahl nennen, die es nicht geprüft hat, in flüssiger Prosa. Behalten Sie eine menschliche Prüfstelle für alles, was das Haus verlässt.

Governance und Daten. In dem Moment, in dem es Personen- oder Kundendaten berührt, gelten die DSGVO und der EU AI Act. Wissen Sie, wo die Daten liegen und wer auditiert werden kann, bevor Sie es anbinden, dieselbe Kontrollfrage, die dahintersteht, Modelle zu betreiben, die einem gehören, statt sie zu mieten (iiterate).

Herkunft. Die meisten geschliffenen Fallstudien, darunter zwei in diesem Artikel, stammen von Anbietern. Lesen Sie sie als Beleg, dass die Arbeit möglich ist, nicht als Beleg für Ihre Rendite.

Wie man reuefrei beginnt

Fangen Sie klein an, mit Arbeit, bei der Sie sich einen Fehler leisten können.

1. Wählen Sie eine Aufgabe, die wiederkehrend und regelgebunden ist und nicht Ihr wichtigster Prozess.
2. Schreiben Sie den Ablauf als Skill in klarer Sprache, so wie Sie eine fähige neue Kraft an ihrem ersten Tag einweisen würden.
3. Geben Sie geringstmöglichen Zugriff: nur Lesezugriff, ein Ordner, eine Kopie der Daten.
4. Behalten Sie eine menschliche Prüfstelle für alles, was nach draußen geht oder Personendaten berührt.
5. Messen Sie an der unspektakulären Kennzahl, den beim langweiligen Vorgang gesparten Stunden, nicht daran, wie sich die Demo anfühlte.

So gemacht, sind die Gewinne klein und sie summieren sich, was das Gegenteil davon ist, wie diese Technologie üblicherweise verkauft wird. Die Frage, bei der es sich zu verweilen lohnt, ist nicht, ob ein Coding-Agent Marketing- oder Betriebsarbeit erledigen kann. Sie ist, welche Ihrer Abläufe Sie tatsächlich aufgeschrieben haben, denn das, nicht das Modell, entscheidet, wie weit das trägt.

Die zentrale Stellungnahme des Europäischen Datenschutzausschusses zu KI-Modellen stützt sich auf die Formel "Einzelfall", und die gemeinsame Leitlinie von EDSA und Europäischer Kommission dazu, wie die DSGVO auf die EU-KI-Verordnung trifft, wird nicht vor Anfang 2026 erwartet. Die nützliche Frage ist also nicht "ist KI unter der DSGVO erlaubt". Sie lautet "unter welchen Bedingungen, und welche dieser Bedingungen kontrollieren wir tatsächlich". Dieser Beitrag kartiert die wenigen harten Grenzen, die große bedingte Mitte und die Hebel, die ein Mittelstandsteam ziehen kann. Es ist Orientierung, keine Rechtsberatung, ziehen Sie also Ihren Datenschutzbeauftragten hinzu, bevor Sie handeln.

BEGINNEN SIE MIT DEN WENIGEN DINGEN, DIE ECHT EINGESCHRÄNKT SIND

Eine kurze Liste von KI-Nutzungen liegt nah an einem echten Verbot unter der DSGVO. Sie zuerst zu kennen macht den Rest leichter durchdenkbar.

• Allein automatisierte Entscheidungen über Menschen. Artikel 22 beschränkt Entscheidungen mit rechtlicher oder ähnlich erheblicher Wirkung, die ohne bedeutsame menschliche Beteiligung getroffen werden. Deutsche Aufsichtsbehörden lesen das streng und erwarten wirksame menschliche Aufsicht statt eines Abnickens (Hogan Lovells).
• Besondere Kategorien von Daten, standardmäßig. Gesundheits-, biometrische, Weltanschauungs- und ähnliche Daten sind nach Artikel 9 grundsätzlich von der Verarbeitung ausgeschlossen, es sei denn, eine bestimmte Ausnahme greift. Die EU-KI-Verordnung schafft eine enge Öffnung: Artikel 10 Absatz 5 erlaubt solche Daten strikt zur Erkennung und Korrektur von Verzerrungen in Hochrisikosystemen (IAPP).
• Modelle, die auf rechtswidrig erhobenen Daten beruhen. Die EDSA-Stellungnahme 28/2024 vom 18. Dezember 2024 hält fest, dass die Entwicklung eines Modells mit rechtswidrig verarbeiteten personenbezogenen Daten die Rechtmäßigkeit seines Einsatzes beeinträchtigen kann, sofern das Modell nicht ordnungsgemäß anonymisiert wurde (EDSA).

Die meiste KI-Arbeit liegt außerhalb dieser kurzen Liste, wo die Antwort selten ein glattes "nein" ist. Es ist ein "ja, wenn".

DAS MEISTE IST BEDINGT, NICHT VERBOTEN

Die große Mitte der KI-Arbeit ist rechtmäßig, wenn Sie die richtigen Bedingungen zeigen und dokumentieren können.

Zwei Bedingungen leisten den Großteil der Arbeit. Die erste ist eine Rechtsgrundlage. Für das Training und die Nutzung von Modellen mit personenbezogenen Daten legte der EDSA einen dreistufigen Test für das berechtigte Interesse vor, der das Interesse selbst, die Erforderlichkeit der Verarbeitung und eine Abwägung gegen die Rechte der betroffenen Personen wägt (EDSA). Das berechtigte Interesse steht zur Verfügung, aber es wird über diesen Test verdient, nicht unterstellt.

Die zweite ist Anonymität, die Sie nicht selbst erklären dürfen. Dieselbe Stellungnahme hält fest, dass ein auf personenbezogenen Daten trainiertes Modell nicht automatisch anonym ist. Es gilt nur dann als anonym, wenn es sehr unwahrscheinlich ist, sowohl die Personen zu identifizieren, deren Daten es trainiert haben, als auch diese Daten über Anfragen zu extrahieren, im Einzelfall von der Aufsichtsbehörde bewertet (IAPP). Die Stellungnahme stützt sich so stark auf "Einzelfall", dass juristische Analysten die Formel im Text durchzählten (Ropes & Gray). Die praktische Lesart: die meiste KI-Verarbeitung ist erlaubt, unter der Bedingung, dass Sie Ihre Grundlage und Ihre Dokumentation zeigen können.

DIE BEDINGUNGEN SIND ÜBERWIEGEND ARCHITEKTONISCH

Der ermutigende Teil ist, dass die Bedingungen, die Sie erfüllen müssen, weitgehend davon bestimmt werden, wie Sie das System bauen, nicht davon, wer Sie sind.

• Weniger behalten, kürzer. Datenminimierung und Zweckbindung gelten an den KI-spezifischen Stellen, an denen Daten sich verstecken: Prompt- und System-Logs und die Vektoren in einem RAG-Speicher. EDSA-Leitlinien verweisen darauf, das Geloggte zu minimieren, aggregierte oder pseudonyme Kennungen zu bevorzugen und die Aufbewahrung kurz zu halten (EDSA-Analyse).
• Bewusst entscheiden, wo die Daten liegen. Seit dem Schrems-II-Urteil ist die Übermittlung personenbezogener Daten an einen US-Anbieter nicht durch die Unterzeichnung von Standardvertragsklauseln erledigt. Sie müssen prüfen, ob diese Klauseln angesichts des US-Überwachungsrechts tatsächlich durchgesetzt werden können, und diese Verantwortung lässt sich nicht an den Anbieter abgeben (Analyse).

Das ist der praktische Grund, warum Datenresidenz und On-Premise-Betrieb Steuerungshebel sind statt Ideologie, derselbe Punkt hinter dem Betrieb von Modellen, die Sie besitzen statt mieten (iiterate).

DIE DSGVO UND DIE EU-KI-VERORDNUNG SIND ZWEI REGIME, NICHT EINES

Es hilft, Datenschutz und KI-Regulierung als getrennte Pflichten zu behandeln, die sich treffen, statt als ein einziges Regelwerk.

Die DSGVO ist ein Grundrechte-Regime über personenbezogene Daten; die EU-KI-Verordnung liegt näher am Produktsicherheitsrecht für KI-Systeme (IAPP). Ein Hochrisikosystem kann Pflichten aus beiden schulden: eine Datenschutz-Folgenabschätzung nach Artikel 35 der DSGVO und eine Grundrechte-Folgenabschätzung nach Artikel 27 der KI-Verordnung, die sie ergänzt statt ersetzt. Die beiden greifen auch auf unbequeme Weise ineinander. Praktiker weisen etwa darauf hin, dass DSGVO-Profiling ein System wieder in den Anwendungsbereich ziehen kann, das eine KI-Verordnungs-Ausnahme scheinbar freigab (r/gdpr). Offizielle Hilfe ist unterwegs: EDSA und Europäische Kommission sollen Anfang 2026 gemeinsame Leitlinien zur Überschneidung veröffentlichen (IAPP).

EINE TRAGFÄHIGE COMPLIANCE-HALTUNG FÜR EIN MITTELSTANDSTEAM

Sie brauchen keine Gewissheit, die die Aufsicht nicht geliefert hat. Sie brauchen eine belastbare, dokumentierte Haltung. Eine praktische Reihenfolge:

1. Kartieren Sie, wo personenbezogene Daten ins System gelangen: Eingaben, Prompts, Logs, Trainingsdaten und der RAG-Speicher.
2. Wählen und dokumentieren Sie eine Rechtsgrundlage für jede Nutzung. Stützen Sie sich auf das berechtigte Interesse, führen Sie den Abwägungstest durch statt ihn anzunehmen.
3. Führen Sie eine DSFA durch, bevor Sie etwas einsetzen, das Menschen profiliert oder über sie entscheidet, und halten Sie einen Menschen für Artikel-22-Fälle bedeutsam in der Schleife.
4. Minimieren und befristen Sie, was das System behält, besonders Prompt-Logs und Vektoren.
5. Entscheiden Sie die Datenresidenz bewusst. Würden personenbezogene Daten die EU verlassen, führen Sie die Übermittlungsprüfung durch oder halten Sie die Verarbeitung in der EU oder on-prem.
6. Überprüfen Sie die Haltung erneut, wenn die gemeinsame Leitlinie von EDSA und Kommission 2026 erscheint.

Die Kurzfassung: an KI ist unter der DSGVO sehr wenig kategorisch verboten, ein paar Dinge sind es wirklich, und der Rest ist überwiegend ein dokumentiertes "ja, wenn". Die Bedingungen, die es entscheiden, sind überwiegend architektonisch, was heißt, dass Sie sie setzen. Dieselben Governance-Fragen tauchen in dem Moment auf, in dem ein interner Agent Kundendaten berührt (iiterate). Dies bleibt Orientierung statt Rechtsberatung, machen Sie also Ihren Datenschutzbeauftragten zum nächsten Leser.

Die europäische Modellszene, Mistral und die Akteure darum herum, hat 2026 echtes Geld und echte Modelle. Sie liegt zugleich bei der reinen Fähigkeit hinter der US- und der chinesischen Spitze, und das Wort europäisch auf einem Etikett bedeutet für sich genommen noch nicht souverän. Für ein Mittelstandsunternehmen ist die nützliche Frage also nicht, ob ein europäisches Modell existiert. Sie ist, welche Art von Kontrolle Sie tatsächlich brauchen und was sie Ihnen gibt. Dieser Beitrag legt die Landschaft dar, die ehrlichen Lücken und die Entscheidung darunter.

Was souverän tatsächlich bedeutet, und was nicht

Souveräne KI bedeutet, dass das Modell und seine Daten unter der rechtlichen und operativen Kontrolle einer Organisation bleiben. Die Hebel, die das liefern, sind konkret: offene Gewichte, die Sie selbst hosten können, und ein Hosting, das die Daten in der EU oder auf Ihren eigenen Maschinen hält.

Zwei ehrliche Vorbehalte bewahren das Wort davor, Marketing zu werden.

🔸 Eine EU-Postleitzahl ist für sich genommen keine Souveränität.
Gesetze zum staatlichen Zugriff, auch in Frankreich und Deutschland, können Daten auf Weisen erzwingen, vor denen ein EU-Standort nicht vollständig schützt. Wo die Daten liegen, ist notwendig, nicht hinreichend.

🔸 Eigentum entscheidet ebenso wie Herkunft.
Silo AI, der finnische Hersteller der offenen Modelle Poro und Viking, ist heute eine Tochter von AMD, einem US-Unternehmen, was es unter US-Recht stellt. Ein in Europa entstandenes Modell in ausländischem Besitz ist nicht automatisch ein souveränes (North Atlantic).

Souveränität ist also eine Frage nach dem Stack und seinem Eigentum, keine Flagge auf einer Startseite.

Mistral, und das Geld, das Europa ernst machte

Mistral ist der Grund, warum europäische KI aufhörte, eine Fußnote zu sein, und die Art, wie seine Finanzierung zustande kam, ist das eigentliche Signal.

In seiner im September 2025 berichteten Runde nahm Mistral rund 1,7 Milliarden Euro bei etwa 11,7 Milliarden Euro Bewertung auf, und der Lead-Investor war ASML, der niederländische Chip-Anlagenbauer, mit rund 1,3 Milliarden Euro (CNBC). Dass ein Unternehmen, das die Maschinen zur Herstellung fortschrittlicher Chips verkauft, sich in ein Modell-Labor einkauft, ist ein Souveränitätszug, nicht bloß ein finanzieller. Mistral hat das mit Infrastruktur gepaart und zielt auf rund 200 Megawatt europäische Rechenleistung bis 2027, besessen statt gemietet, an Standorten nahe Paris und einem großen Neubau in Schweden (Data Center Dynamics). Seine Enterprise-Traktion ist ebenfalls real, mit benannter Arbeit an der Seite von Airbus, BMW, Amazon und SAP.

Die Geschichte, die Mistral über sich selbst erzählt, ist der nützliche Teil: Es versucht nicht, das reine Modellrennen gegen die US-Giganten zu gewinnen, es versucht, den europäischen Stack zu besitzen, der unter den Modellen sitzt. Für einen Käufer, dem Kontrolle wichtig ist, zählt diese Einordnung mehr als ein Ranglistenplatz.

Und darüber hinaus: der Rest der europäischen Bank

Mistral ist nicht das ganze Feld, und die anderen offenbaren unterschiedliche Wetten darauf, wo europäischer Wert sitzt.

Aleph Alpha, das Heidelberger Unternehmen, das einst als Deutschlands Hoffnung auf ein Spitzenmodell galt, gab die Jagd nach der Spitze auf und baute sich um eine Souveränitäts- und Compliance-Plattform herum neu auf, PhariaAI, ausgerichtet auf On-Prem- und Air-Gapped-Einsatz in regulierten Branchen (Analyse). Black Forest Labs, in Freiburg von einem Teil des ursprünglichen Stable-Diffusion-Teams gegründet, macht die offene FLUX-Familie von Bildmodellen (Dakota). Und Teuken-7B, aus dem Fraunhofer-geführten OpenGPT-X-Konsortium, ist ein offen herunterladbares Modell, trainiert über alle vierundzwanzig offiziellen EU-Sprachen, gebaut zum Selbst-Hosten (Fraunhofer).

Das bemerkenswerte Muster ist, dass die stärksten europäischen Züge zunehmend um den Stack gehen, die Offenheit und das Einsatzmodell, statt um ein einzelnes Spitzenmodell. Genau dort sitzt zufällig der Vorteil eines Mittelstandskäufers.

Die ehrliche Fähigkeitslücke

Nüchtern ist glaubwürdiger als schwärmerisch, hier also die Lücke klar. Auf unabhängigen Fähigkeitsindizes liegt das europäische Flaggschiff eher in der Mitte des Open-Weight-Feldes als an der Spitze (Artificial Analysis). Auch die Finanzierung ist schief: Europas kombinierte Modellfinanzierung ist klein neben der Bewertung eines einzelnen US-Labors, näher an einem Rundungsfehler als an einer Rivalität (North Atlantic).

Der nützliche Schritt ist nicht, die Lücke zu leugnen, sondern zu fragen, ob sie Ihre Aufgabe berührt. Für Entwürfe, Extraktion, Klassifizierung und Retrieval über Ihre eigenen Dokumente überspringt ein von Ihnen vollständig kontrolliertes Mittelfeld-Open-Modell meist die Hürde, und die Kontrolle ist mehr wert als die letzten paar Benchmark-Punkte. Das ist derselbe Kompromiss, den wir zogen, als ein Spitzenmodell in zweiundsiebzig Stunden aus einem Markt verschwand: operative Kontrolle schlägt gemietete Fähigkeit, wenn die gemietete Fähigkeit genommen werden kann (iiterate). Die Spitze ist, wo europäische Modelle wirklich hinterherhinken. Sie ist auch der Teil der Arbeit, den viele Unternehmen tatsächlich nicht brauchen.

Was das für einen Mittelstandskäufer bedeutet

Die Entscheidung ist nicht patriotisch, sie ist architektonisch. Drei praktische Wege, nach dem, was die Arbeitslast braucht:

1. Spitzenfähigkeit nötig, Daten nicht sensibel. Ein gehostetes Spitzenmodell ist weiterhin die leistungsfähigste Option. Nutzen Sie es, und akzeptieren Sie die Abhängigkeit bewusst.
2. Kontrolle ist der Punkt. Für regulierte Daten, Mandantenschutz oder alles, was Sie prüfen können müssen, hosten Sie ein offenes europäisches oder Open-Weight-Modell selbst, oder nutzen Sie EU-gehostete Inferenz, und schreiben Sie Datenresidenz und Eigentum in die Spezifikation, nicht ins Marketing.
3. Beurteilen Sie Souveränität am Stack, nicht an der Flagge. Wo die Gewichte laufen, wo die Daten liegen, wer Zugriff erzwingen kann und ob Sie das Modell austauschen können. Dieselbe Kontrollfrage sitzt unter der DSGVO (iiterate).

Die europäische Szene ist endlich real genug, um für den zweiten Fall eine ernsthafte Antwort zu sein, und das ist das meiste von dem, worum wir gebeten werden zu bauen. Der Grund, sich zu kümmern, ist nicht die Flagge. Es ist, dass gemietete Fähigkeit widerrufbar ist und Kontrolle etwas ist, das man baut. Die Frage, die es zu halten lohnt, ist nicht, ob Europa dieses Jahr die Spitze erreichen kann. Sie ist, welche Ihrer Arbeitslasten die Spitze wirklich brauchen und welche nur ein leistungsfähiges Modell, das Sie kontrollieren.