Dieser Beitrag sammelt die Anwendungsfälle, bei denen Latenz nicht Komfort ist, sondern Bedingung, und beschreibt, woran sie bisher gescheitert sind.

Warum Doom das bessere Argument ist als der Benchmark

Ein Spiel liefert die Bedingungen, die ein Benchmark verschweigt. Der Aktionsraum ist fest und klein. Der Zustand ist vollständig beschreibbar. Und es gibt ein hartes Zeitfenster, in dem geantwortet sein muss, sonst ist die Antwort wertlos, egal wie gut sie ist.

Genau an dieser Stelle scheitert ein Token-für-Token-Modell nicht an Intelligenz, sondern an Verfahren. Der Nachweis ist deshalb keine Spielerei: Wer zeigt, dass eine Entscheidung in ein Frame-Budget passt, hat gezeigt, dass sie auch in ein Zahlungsvorgang-Budget passt.

Die Spiele-Projekte als Belastungstest

Die Community hat das schnell durchdekliniert. typesafe-snake lässt den Code die legalen Züge erzeugen und das Modell einen davon je Tick wählen. jev-plays-pokemon-red läuft auf einem Emulator und ruft das Modell nur an Verzweigungen auf, mit Brier-Scores auf den eigenen Vorhersagen als Qualitätsmaß. Dazu kommen Mario-, Drohnen- und Fahr-Demos, mehrere davon in unter einer Stunde gebaut.

Der Blitzschach-Test ist die klarste Zahl aus dieser Gruppe. Jev antwortete in rund 2,6 Sekunden je Zug, während Vergleichsmodelle 6 bis 15 Sekunden brauchten und aus gewonnener Stellung auf Zeit verloren. Die Zugqualität war nicht der entscheidende Faktor, die Einhaltung des Budgets war es.

Handel, Sprachagenten und Browser-Automatisierung

Dieselbe Eigenschaft trägt Anwendungen ohne Spielcharakter. jev-trader baut eine Marktentscheidungsschleife im Sub-Sekunden-Bereich und dokumentiert Trocken- und Echtbetrieb getrennt. QuantDinger setzt das Modell als Vorprüfung vor einen Einstieg und blockiert abgelehnte Aufträge, mit protokolliertem Rückfallpfad.

Bei Sprachagenten geht es um die Entscheidung, ob unterbrochen werden darf und wann eine Antwort beginnt. Das muss im Rhythmus eines Gesprächs passieren, also deutlich unter einer Sekunde. Browser-Automatisierung hat dasselbe Profil: Welches Element ist gemeint, aus einer sichtbaren Menge, sofort. Für gesprochene Navigation werden rund 0,0002 US-Dollar je Entscheidung bei etwa 300 Millisekunden berichtet.

Was das für gewöhnliche Systeme bedeutet

Die meisten B2B-Systeme haben kein Frame-Budget, aber sie haben Budgets, die niemand aufgeschrieben hat. Ein Zahlungsvorgang darf nicht auf eine Betrugsbewertung warten. Eine Suchanfrage darf nicht auf die Neusortierung ihrer Treffer warten. Ein Assistent, der drei Sekunden braucht, wird nicht benutzt, egal wie gut die Antwort ist.

Diese Budgets waren bisher der Grund, warum Prüfungen weggelassen wurden. Fällt die Begründung weg, fällt auch der Grund weg. Wie sich ein Antwortzeitbudget für einen KI-Assistenten überhaupt aufteilt, haben wir in Antwortzeit eines KI-Assistenten beschrieben.

Die harten Grenzen im Echtzeitbetrieb

Ein Auswahlaufruf trägt bis zu 255 Optionen, eine Skala 2 bis 10 Stufen. Die Ratengrenzen liegen bei rund 250.000 Tokens je Sekunde und 1.200 Anfragen je Minute und sind laut Anbieter dynamisch. Für eine Schleife, die zehnmal je Sekunde entscheidet, ist die Anfragegrenze und nicht die Latenz der bindende Faktor.

Und es bleibt bei Text. Kein Bild, kein Audio, kein Video. Wer einen Spielzustand oder eine Kameraszene bewerten lassen will, muss sie vorher in eine Zustandsbeschreibung übersetzen. Diese Übersetzung ist die eigentliche Ingenieursarbeit, nicht der Modellaufruf.

Dieser Beitrag beschreibt sechs davon und benennt jeweils die Fragen, aus denen die Entscheidungsschicht besteht. Es sind Muster, keine fertigen Systeme.

Rechnungsabgleich und Eingangsprüfung

Eine eingehende Rechnung wird gegen Bestellung, Vertrag, Lieferantenstammdaten und Liefernachweis gehalten. Die Fragen sind unabhängig voneinander: Stimmt die Position mit der Bestellung überein, liegt der Preis im vertraglich vereinbarten Rahmen, ist der Lieferant bekannt, existiert ein Liefernachweis. Jede Frage bekommt eine eigene Wahrscheinlichkeit, und erst der Code verrechnet sie zu einer Freigabe.

Das ist der Unterschied zu einem einzigen Modellaufruf, der "prüfe diese Rechnung" fragt. Vier getrennte Urteile lassen sich einzeln nachvollziehen und einzeln nachjustieren. Ein zusammengefasstes Urteil nicht.

Reisekosten und Spesenfreigabe

Ein Spesenbeleg wird zunächst auf Lesbarkeit geprüft, dann klassifiziert, dann gegen die Reisekostenrichtlinie gehalten. Bewirtungsbelege sind der Fall, an dem die meisten Automatisierungen scheitern, weil die Regel selten eindeutig ist und der Betrag allein nicht reicht.

Als Fragensatz funktioniert das gut: Ist der Beleg lesbar, welche Kategorie, überschreitet der Betrag die Grenze für diese Kategorie, fehlt eine erforderliche Angabe. Was unterhalb der Konfidenzschwelle liegt, geht an einen Menschen, und zwar mit der Angabe, welche der vier Fragen unsicher war.

Schadensmeldungen und Erstbewertung

In der Erstbewertung einer Schadensmeldung existiert meist bereits eine Prüfliste. Sie wird heute entweder von Hand abgearbeitet oder in ein Formular gepresst. Als Satz unabhängiger Ja-Nein-Fragen auf demselben Vorgang bleibt jede Einzelwahrscheinlichkeit erhalten, statt zu einer Ampel zusammenzufallen.

Der operative Gewinn liegt nicht in der Automatisierung der Entscheidung, sondern in der Reihenfolge. Fälle, bei denen alle Fragen eindeutig sind, kommen zuerst durch. Fälle mit einer unsicheren Antwort landen vorne in der menschlichen Warteschlange statt hinten.

Prüfberichte und regulatorische Durchsicht

Ein Dokument gegen einen Anforderungskatalog zu halten ist ein Stapel unabhängiger Fragen auf einem Zustand. Vertragsklauseln gegen eine Vorgabenliste, ein Prüfbericht gegen eine Norm, eine Dokumentation gegen eine Checkliste. Das Modell beantwortet jede Anforderung einzeln, der Bericht entsteht im Code.

Wichtig ist die Grenze: Das Ergebnis ist eine Vorsortierung, keine Bewertung. Wer eine Begründung braucht, braucht einen Menschen oder ein generierendes Modell, und warum das nicht dasselbe ist, steht in Eine Zahl ohne Begründung.

Sicherheitsmeldungen und Alarmkontext

Eine Sicherheitsmeldung wird mit dem Kontext zusammengeführt, in dem sie entstanden ist, und dann auf drei Dinge geprüft: War die Handlung autorisiert, gibt es eine harmlose Erklärung, wie stark ist die Beweislage. Die dritte Frage ist die wichtigste, weil sie darüber entscheidet, ob überhaupt jemand geweckt wird.

Dasselbe Muster trägt die Durchsicht abgeschlossener Agentenläufe, wenn ein Unternehmen KI-Agenten auf eigene Systeme lässt. Rechteüberschreitung, Aufgabenerfüllung, Auffälligkeit, je als eigene Frage.

Extraktion mit Kontrolle statt Extraktion allein

Das wirksamste Muster für Dokumenten-Pipelines ist eine Kaskade. Ein kleines, günstiges Modell extrahiert die Felder. Eine typisierte Entscheidungsschicht prüft jeden Wert einzeln gegen den Quelltext. Nur was durchfällt, geht an ein größeres Modell oder an einen Menschen.

Damit verschiebt sich die Qualitätsfrage von "wie gut extrahiert das Modell" zu "wie zuverlässig erkennen wir einen falschen Wert". Die zweite Frage ist messbar, die erste war es nie. Welche Fehlerbilder in Dokumentenstrecken typisch sind, behandelt Wo ein KI-Feature schiefgeht.

Dieser Beitrag geht durch die öffentlichen Projekte, die seit dem 15. September entstanden sind, und benennt das wiederkehrende Muster dahinter. Die Sammlungen liegen offen, unter anderem als awesome-jev und awesome-jev-by-typesafe.

Triage ist der erste Reflex

Die naheliegendste Anwendung ist ein Posteingang, der sortiert werden muss. TypeSafe selbst zeigt das an einem Triage-Dashboard für GitHub-Repositories: Zu jedem Issue beantwortet das Modell denselben festen Fragensatz, also Art, Schwere, Dringlichkeit, Duplikat und nächster Schritt. Unsichere Fälle und Stellen, an denen Menschen widersprochen haben, bekommen eigene Aufmerksamkeit, und jede menschliche Korrektur wird aufbewahrt und bei späteren Läufen wieder mitgegeben.

Dasselbe Muster trägt den Support-Posteingang. Der Code sammelt Vorgang und Geschäftsregeln ein, das Modell beantwortet Kategorie, Dringlichkeit und Frustrationsgrad, und die Zuweisung an eine Warteschlange bleibt gewöhnlicher Code. Die Reihenfolge ist wichtig: erst die Warteschlangen verbessern, dann automatisieren.

Retrieval, Suche und die Prüfung von Behauptungen

Die zweite große Gruppe sitzt vor oder hinter einer Suche. jev-reranker ist eine Rust-Kommandozeile, die Treffer mit Ja-Nein-Fragen neu ordnet, filtert und kürzt. nlgrep sucht in Dateien nach einer in natürlicher Sprache formulierten Bedingung und gibt gerankte Dateien mit Fundstellen zurück. jevql schiebt dieselben Fragen als Filter und Sortierung in eine Postgres-Abfrage.

Aufschlussreicher als die Werkzeuge ist die Fragenliste, die sich eingebürgert hat. Ein abgerufener Abschnitt wird nicht nur auf Relevanz geprüft, sondern auch darauf, ob er die Antwort stützt, ob er ihr widerspricht und ob er eine eingeschleuste Anweisung enthält. Vier unabhängige Urteile auf demselben Zustand, in einem Aufruf.

Code, Commits und CI als Entscheidungsproblem

Eine überraschend dichte Gruppe sitzt in der Entwicklungskette selbst. jev-git prüft gestagte Diffs vor dem Commit auf Geheimnisse und zerstörerische Kommandos. is-malicious bewertet Quell-, Konfigurations- und CI-Dateien, wobei Schwellenwerte und Schweregrade im Code bleiben. jev-pref liest Projektkonventionen aus einer AGENTS.md und prüft Diffs dagegen, also semantisches Linting statt Formatprüfung.

Der gemeinsame Nenner: Regeln, die bisher als Regex oder als Kommentar im Pull Request existierten, werden zu Ja-Nein-Fragen, die auf jedem Commit laufen können, weil sie nichts kosten.

Agenten, die ihre eigenen Schritte bewerten

Die interessanteste Gruppe steuert andere KI-Systeme. JevRouter wählt aus einer Menge von Fähigkeiten aus, während Verfügbarkeit, Rechte und Fallback im Code bleiben. jev-guard bewertet geplante Werkzeugaufrufe nach Risiko und gibt sie frei, fragt nach oder verweigert. wakegate entscheidet vor dem Fortsetzen eines schlafenden Agenten, ob ein Ereignis überhaupt zu ihm gehört.

Beobachtbarkeit gehört in dieselbe Gruppe. jevlogs annotiert OpenTelemetry-Datensätze und überspringt teure Analyse für Spuren ohne Aussagewert. Ein abgeschlossener Agentenlauf lässt sich im Nachhinein auf Rechteüberschreitungen, Aufgabenerfüllung und Zufriedenheit prüfen, ohne dass ein Mensch ihn liest.

Zahlen, die aus echten Läufen stammen

Ein paar Projekte veröffentlichen ihre eigenen Messungen, und die sind belastbarer als jeder Anbieter-Benchmark. jev-skip, eine Browser-Erweiterung, die Sponsoren-Abschnitte in YouTube-Videos anhand der Untertitel erkennt, meldet eine Trefferquote von 77 Prozent der Sponsoren-Sekunden über 23 Videos bei 0,0008 US-Dollar je Video. Eine Audit-Studie mit 1.204 gecrawlten Seiten kam auf 4.816 typisierte Urteile je Lauf und 0,0048 US-Dollar je Triage-Stapel aus zwölf Fragen.

Die Zahl, die im Alltag zählt, ist nicht der Faktor gegenüber einem Sprachmodell, sondern die Absolutkosten je Entscheidung. Bei diesen Größenordnungen verschwindet die Frage, ob eine Prüfung sich lohnt.

Das Muster hinter allen Projekten

Fast jedes dieser Projekte trennt gleich. Das Modell beantwortet eine enge Frage über einen übergebenen Zustand. Der Code besitzt die Optionsmenge, den Schwellenwert, die Rechte, die Reihenfolge und den Fallback. Wo ein Projekt diese Trennung aufgibt und das Modell entscheiden lässt, was es tun darf, taucht im Repository kurz darauf eine Ausnahmebehandlung auf.

Die zweite Wiederkehr ist die Bündelung. Statt fünf Aufrufe nacheinander zu machen, werden alle plausibel benötigten Fragen in einem Aufruf gestellt, auch die, deren Antwort vielleicht gar nicht gebraucht wird. Bei kostenlosen Ausgabe-Tokens ist das billiger als die zweite Netzwerkrunde. Was das für den Entwurf einer Pipeline bedeutet, steht in Wo ein Entscheidungsmodell tatsächlich hingehört.

Für alles, was den Antrag, den Anspruch, die Rechnung oder das Arbeitsverhältnis eines Menschen berührt, wirkt die fehlende Begründung zunächst wie das eigentliche Problem. Sie ist es nicht. Sie ist eine Aussage darüber, wo der Nachweis liegen muss.

Die generierte Begründung war nie ein Nachweis

Ein Sprachmodell, das einen Fall klassifiziert, kann um eine Begründung gebeten werden, und die liest sich gut. Genau darin liegt die Falle. Der Text entsteht im Nachhinein und ist kein Protokoll der Berechnung, die zur Entscheidung geführt hat. Er ist eine plausible Geschichte über eine Entscheidung, nicht die Entscheidung. Abgelegt wurde er trotzdem als Prüfspur.

Ein Entscheidungsmodell nimmt diese Illusion weg. Es liefert eine typisierte Ausgabe und eine kalibrierte Wahrscheinlichkeit, und nichts, was einer Begründung ähnelt. Der Nachweis muss also um das Modell herum gebaut werden statt von ihm angefordert.

Wie der Nachweis aussieht

In der Praxis protokolliert die Entscheidungsschicht den übergebenen Zustand, die exakt gestellte Frage, die typisierte Antwort, die Wahrscheinlichkeit, den zu diesem Zeitpunkt geltenden Schwellenwert und die Version des Fragensatzes. Das ist reproduzierbar. Bei gleichem Zustand lässt sich zeigen, was das System gefragt wurde und was es zurückgegeben hat. Ein generierter Absatz kann das nicht leisten.

Der Fragensatz selbst wird damit zum versionierten Artefakt. Ändert sich eine Frage, ändert sich die Grundlage aller späteren Entscheidungen, und das muss sichtbar sein. In Systemen, die wir bauen, liegt dieser Satz im Repository und nicht in einer Konfigurationsoberfläche.

Kalibrierung verdient einen präzisen Satz

Kalibrierung ist eine Eigenschaft einer Verteilung. Gibt das Modell über viele Fälle hinweg 0,8 an, sind davon etwa acht von zehn korrekt. Über den konkret vorliegenden Fall sagt das nichts.

Der Schwellenwert ist damit eine Richtungsentscheidung über akzeptierten Fehler und gehört in ein Dokument, das ein Mensch unterzeichnet hat, nicht in eine Konstante im Quellcode. Teams, die das ernst nehmen, messen die Kalibrierung auf einem zurückgehaltenen Teil der eigenen Daten nach, statt sie vorauszusetzen.

Aufsicht braucht Grenzen, keinen Fließtext

Die Anforderungen des EU AI Act an menschliche Aufsicht bei höherem Risiko zeigen in dieselbe Richtung. Aufsicht ist dann wirksam, wenn die prüfende Person sieht, was das System bekommen hat, was es entschieden hat und wo die Grenze liegt. Ein selbstbewusster Satz, erzeugt von genau dem System, das die Entscheidung getroffen hat, leistet das nicht. Ein protokollierter Zustand mit Frage, Score und Schwellenwert leistet es.

Es gibt eine Variante, die schlechter ist als beide Optionen. Ein Entscheidungsmodell liefert eine Zahl, und ein Sprachmodell wird anschließend gebeten, diese Zahl zu erklären. Das wirkt gründlich und ist es nicht. Die Erklärung wird aus der Ausgabe rekonstruiert, nie aus der Berechnung.

Die Form, auf die wir hinbauen

Typisierte Entscheidungen dort, wo die Antwort eine Klasse, ein Score oder ein Boolescher Wert ist. Generierung nur dort, wo ein Mensch tatsächlich Fließtext braucht. Ein Entscheidungsnachweis, der außerhalb von beidem liegt und nicht davon abhängt, dass eines von beidem einsehbar ist. Menschliche Prüfung ausgelöst durch das Wahrscheinlichkeitsband statt durch das Thema, damit die Fälle nahe der Grenze Aufmerksamkeit bekommen und nicht die Fälle, die jemand für heikel gehalten hat.

Als Prinzip ist daran nichts neu. Neu ist, dass die Entscheidungsschicht günstig genug geworden ist, damit sich die Architektur auch in gewöhnlichen B2B-Workloads lohnt und nicht nur in Systemen, an denen ohnehin eine Aufsichtsbehörde hängt.

Ein Entscheidungsmodell ersetzt nicht das Sprachmodell im Stack. Es ersetzt die Sprachmodell-Aufrufe, die nie wirklich Sprachaufgaben waren. Dieser Beitrag benennt fünf solche Stellen und beschreibt einen Test, der ohne Business Case auskommt.

Klassifikation beim Eingang

Jede Dokumenten-Pipeline beginnt mit der Entscheidung, was überhaupt eingegangen ist. Rechnung, Lieferschein, Vertragsnachtrag oder etwas Unlesbares, das einen Menschen braucht. Die meisten Teams lösen das mit einem kleinen Modellaufruf plus JSON-Schema und härten anschließend wochenlang den Parser.

Eine typisierte Auswahl mit Konfidenzwert eliminiert das Parsing-Problem vollständig, weil die Ausgabe nie Text war. Der Schwellenwert, ab dem ein Fall an einen Menschen geht, wird damit zu einer eingestellten Größe statt zu einer Heuristik im Code.

Filterung im Retrieval

Bei Retrieval Augmented Generation ist nicht der fehlende Textabschnitt der teure Fehler, sondern der irrelevante, der zu einer selbstbewusst falschen Antwort synthetisiert wird. Jeden Kandidaten vor der Synthese auf tatsächliche Relevanz zu bewerten ist der wirksamste Guardrail der Pipeline und wird am häufigsten weggelassen, weil ein Sprachmodell dafür einen zusätzlichen Aufruf pro Abschnitt bedeutet.

Im Sub-Cent-Bereich bewertet man alle, und zwar nicht nur auf Relevanz: ob der Abschnitt die Antwort überhaupt stützt, ob er der Frage widerspricht, ob er eine eingeschleuste Anweisung enthält. Das sind vier Nouls auf demselben Zustand. Wie dieselbe Schicht in der Praxis eingesetzt wird, zeigt Was Entwickler mit Jev tatsächlich bauen.

Tool- und Routing-Auswahl

Agentische Systeme verbringen einen überraschend großen Teil ihres Latenzbudgets mit der Entscheidung, welches Werkzeug als Nächstes aufgerufen wird. Diese Entscheidung ist eine Auswahl aus einer festen Menge. Sie braucht keine Begründung, sie muss richtig und schnell sein.

Der belastbare Teil des Musters liegt in der Trennung der Achsen: Die Antwort sagt, was gewählt wurde, die Konfidenz sagt, wie sicher. Eine umkehrbare Aktion darf bei geringer Konfidenz laufen, eine unumkehrbare nicht. Damit wird aus einem Modellaufruf eine Freigabelogik, die im Code liegt und dort auch geprüft werden kann.

Prüfung der Extraktion und Guardrails

Nach der Extraktion eines Feldes muss etwas beurteilen, ob es vollständig und plausibel wirkt. Teams überspringen das, prüfen stichprobenartig oder leiten alles an einen Menschen weiter. Ein kalibrierter Score pro Feld macht daraus einen Schwellenwert, den man gegen ein reales Fehlerbudget einstellen kann statt gegen ein Bauchgefühl.

Policy-Prüfungen sind ebenfalls Klassifikationen. Üblicherweise laufen sie nur auf Anfragen, die jemand als riskant markiert hat, weil sie überall zu langsam und zu teuer waren. Diese Einschränkung entfällt weitgehend.

Wie man es ohne Business Case testet

Einen Monat produktiver Klassifikationsaufrufe nehmen und erneut abspielen. Genauigkeit und p95-Latenz gegen den heutigen Stand vergleichen. Dann nicht den Gesamtscore ansehen, sondern die Abweichungen, denn die Abweichungen zeigen, ob die Aufgabe jemals eine Sprachaufgabe war. Der Test kostet weniger als das Meeting darüber, ob man ihn durchführt. Die Schnittstelle dafür liegt bereits in gängigen Werkzeugketten, etwa als evaluate-Aufruf im AI SDK.

Der größere operative Gewinn steckt nicht in der Inferenzersparnis. Die meisten B2B-KI-Pipelines haben dünne Observability, weil die Bewertung jedes Schritts einen weiteren Modellaufruf kostet und dafür niemand Budget einplant. Sinkt die Bewertung auf einen Rundungsfehler, lässt sich jeder Schritt jedes Laufs bewerten, die Verteilung festhalten und Drift erkennen, bevor ein Nutzer sie meldet.

Nicht geeignet ist das Muster für alles, was eine Begründung liefern, an einen Menschen schreiben oder über den übergebenen Zustand hinausgreifen muss. Ein Entscheidungsmodell hat kein Weltwissen und keine Begründung. Arbeit dieser Art dorthin zu geben ist der Weg, auf dem ein erster Pilot scheitert.

Dieser Beitrag ordnet die These ein, benennt die belastbaren Zahlen und die Grenzen, und beschreibt, was daraus für die Architektur von B2B-Pipelines folgt.

Die Benennung ist die These

"System One" übernimmt die Trennung von Daniel Kahneman zwischen schnellem, intuitivem Urteil und langsamem, bewusstem Schlussfolgern. Das Modell selbst ist nach William Stanley Jevons benannt, dem Ökonomen hinter dem Jevons-Paradoxon: Wird eine Ressource billiger, steigt der Gesamtverbrauch, statt zu sinken. TypeSafe sagt damit offen, was passieren soll, sobald eine Entscheidung einen Bruchteil eines Cents kostet.

Die architektonische These trifft etwas, das in fast jeder B2B-Pipeline sichtbar ist. Die meisten Entscheidungen innerhalb eines Produktivsystems sind keine System-2-Probleme. Ist dieses Dokument eine Rechnung oder ein Lieferschein. Braucht dieses Ticket einen Menschen. Ist dieser abgerufene Textabschnitt für die gestellte Frage überhaupt relevant. Wirkt dieses extrahierte Feld vollständig. Das sind Klassifikationen, gelöst mit Modellen, die für Konversation gebaut sind, zu Konversationslatenz und Konversationspreisen.

Drei Fragetypen, mehr gibt es nicht

Die gesamte Schnittstelle besteht aus drei Primitiven. Noul beantwortet eine Ja-Nein-Frage mit einer Wahrscheinlichkeit zwischen 0 und 1. Choice wählt eine Option aus einer festen Menge von bis zu 255 Einträgen und liefert die vollständige Verteilung mit. Score ordnet auf einer Skala von zwei bis zehn Stufen ein und gibt einen wahrscheinlichkeitsgewichteten Mittelwert zurück.

Zustand und Fragen teilen sich ein Budget von rund 64.000 Tokens, wobei Zustand plus längste Einzelfrage bei etwa 32.000 Tokens liegen müssen. Nur Text, keine Bilder, kein Audio, kein Video. Die Enge dieser Schnittstelle ist kein Mangel, sondern der Punkt: Was zurückkommt, muss nicht geparst werden, weil es nie Text war.

Herstellerzahlen bleiben Herstellerzahlen

TypeSafe nennt bis zu 193-fach schneller und 444-fach günstiger als Frontier-Modelle bei eng gefassten Entscheidungsaufgaben. Das sind Benchmarks des Anbieters auf Aufgaben, die der Anbieter ausgewählt hat. Eine unabhängige Bestätigung der Größenordnung wird Monate dauern, und eng gefasste Benchmark-Aufgaben sind der freundlichste denkbare Fall für ein Entscheidungsmodell.

Die Richtung steht trotzdem kaum infrage, und der Markt hat das schnell deutlich gemacht. Vercel hat Jev ins AI Gateway aufgenommen und binnen weniger Tage als am schnellsten adaptierten Modell-Launch der Plattformgeschichte bezeichnet. Netlify zog nach. Ein Open-Source-CRM hat einen Pull Request gemerged, der eine völlig neue Modellkategorie einführt, "evaluation", samt darauf aufsetzendem Klassifikations-Node. Infrastruktur bewegt sich für eine marginale Verbesserung nicht so schnell.

Der eigentliche Effekt ist der zweiter Ordnung

Die meisten KI-Systeme behandeln heute jeden Schritt als Generierungsproblem, weil Generierung das einzige verfügbare Werkzeug war. Ein großes Modell übernimmt Routing, Extraktion, Bewertung und Formulierung, und die gesamte Pipeline erbt die Eigenschaften ihrer langsamsten und teuersten Komponente.

Trennt man die schnellen typisierten Entscheidungen von der langsamen generativen Arbeit, ändert sich die Form des Systems. Kostet eine Klassifikation fast nichts, hört man auf zu rationieren. Retrieval wird gefiltert statt Kontext vollgestopft. Jedes extrahierte Feld wird bewertet statt stichprobenartig geprüft. Die Policy-Prüfung läuft auf jeder Anfrage, nicht nur auf den als riskant markierten. Jevons, wie angekündigt.

Die Grenzen sind strukturell, nicht vorübergehend

Jev liefert eine Zahl ohne Begründung. Das wird relevant in dem Moment, in dem jemand fragt, warum ein Fall so geroutet wurde. Das Modell hat kein Weltwissen, es kennt ausschließlich den übergebenen Zustand. Kalibrierung ist eine Eigenschaft der Verteilung über viele Vorhersagen, keine Garantie für die einzelne Antwort. Was daraus für Nachweis und Aufsicht folgt, steht in Eine Zahl ohne Begründung.

Auch die schärfste Kritik in der Diskussion auf Hacker News verdient Beachtung. Ein großer Teil der Geschwindigkeit könnte aus eingeschränktem Single-Token-Decoding gegen eine feste Auswahlmenge stammen statt aus einer neuen Architektur. Träfe das zu, wäre der Vorteil reproduzierbar und der Burggraben schmal.

An der Lehre ändert das nichts. Entscheidungsarbeit und Spracharbeit haben unterschiedliche Kostenkurven, unterschiedliche Latenzbudgets und unterschiedliche Fehlermodi. Sie als eine Schicht zu bauen war eine Bequemlichkeit des Werkzeugs, keine Eigenschaft des Problems. Wo die Trennung in einer laufenden Pipeline konkret verläuft, beschreibt Wo ein Entscheidungsmodell tatsächlich hingehört.

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

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

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

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

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

Zwei Budgets, die man getrennt rechnen muss

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

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

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

Warum meist die Texturen den Ausschlag geben

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

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

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

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

Rechnen Sie das Ladebudget der Einhausung nach

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

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

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

Was die Rechnung über das Beispiel verrät

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

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

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

Wie ein Konfigurator von innen aufgebaut ist

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

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

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

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

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

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

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

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

Was vor dem Export geklärt sein sollte

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

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

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

Wann ein Bild die bessere Wahl ist

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

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

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

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

Warum ein Stichtag so viel auf einen Tag legt

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

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

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

Eine Weiche vor dem Altsystem

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

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

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

Welches Modul zuerst umzieht

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

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

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

Den Stufenplan selbst durchrechnen

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

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

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

Parallelbetrieb heißt vergleichen

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

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

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

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

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

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

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

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

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

Wann der Stichtag doch die bessere Wahl ist

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

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

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

Womit Sie beginnen können

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

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

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

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

Warum eine einzelne Zeitmessung wenig erklärt

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

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

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

Die fünf Posten einer Antwort

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

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

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

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

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

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

Warum die Modellantwort meist der größte Posten ist

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

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

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

Das erste Wort und die fertige Antwort sind zwei Zeiten

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

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

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

Rechnen Sie ein Latenzbudget selbst durch

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

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

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

Was die Rechnung zeigt und was sie auslässt

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

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

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

Wie die Betriebsart die Posten verschiebt

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

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

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

In welcher Reihenfolge Sie eine langsame Antwort beschleunigen

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

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

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

Wann die Antwortzeit zweitrangig ist

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

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

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

Warum „die KI“ keine Fehlerursache ist

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

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

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

Die sieben Stufen eines KI-Features und ihre typischen Fehler

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

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

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

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

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

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

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

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

Warum die Suche so oft die Ursache ist

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

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

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

Probieren Sie die Suche aus Stufe 4 selbst aus

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

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

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

Was die Demonstration zeigt und wo sie aufhört

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

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

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

Eine Testmenge macht Fehler zählbar

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

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

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

In welcher Reihenfolge Sie eine Fehlermeldung eingrenzen

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

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

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

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

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

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

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

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

Warum die Frage nach dem Raum zwei Fragen sind

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

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

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

Was eine Raumprüfung rechnen muss

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

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

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

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

Prüfen Sie die Einhausung selbst

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

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

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

Was die Prüfung zeigt und was sie verschweigt

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

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

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

Welche Angaben ein Kunde liefern sollte

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

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

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

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

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

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

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

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

Wann AR die Frage besser beantwortet als eine Rechnung

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

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

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

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

Wann sich Raumcheck und 3D nicht lohnen

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

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

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

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

Este artículo ordena los programas más importantes según su situación en septiembre de 2026, describe paso a paso el camino hacia la solicitud y señala los errores típicos que pueden costarle la ayuda.

Qué tipos de ayuda existen

Existen cuatro tipos de ayuda, y se diferencian más por su lógica que por su importe. Una subvención cubre una parte de los costes subvencionables y no se devuelve, pero exige una solicitud antes de empezar el proyecto y, al final, una justificación del uso de los fondos (Verwendungsnachweis). Un préstamo bonificado se tramita a través de su banco (Hausbank) y en los niveles superiores puede incluir un componente de subvención. La Forschungszulage es un incentivo fiscal a la investigación y el desarrollo. Las ofertas de asesoramiento no pagan dinero, pero ayudan a situar un proyecto.

Un proyecto de IA no es subvencionable solo por la palabra clave IA, sino cuando encaja con la finalidad de un programa: investigación y desarrollo, digitalización de procesos y productos o consultoría externa. Al investigar, conviene saber que el Ministerio Federal de Economía opera ahora como BMWE (antes BMWK) y el Ministerio de Investigación como BMFTR.

Programas federales de un vistazo

A nivel federal, en 2026 son especialmente relevantes para proyectos de IA cinco instrumentos, con una situación muy distinta.

• ZIM (Zentrales Innovationsprogramm Mittelstand, programa central de innovación para pymes). El BMWE financia proyectos de investigación y desarrollo de pymes, solas o con centros de investigación, así como redes de innovación y estudios de viabilidad. Desde el 7 de julio de 2026 rige una suspensión temporal de solicitudes: ZIM no acepta actualmente nuevas solicitudes, se aspira a reabrirlo a principios de 2027 y la reapertura depende del presupuesto de 2027. Las solicitudes ya presentadas se siguen resolviendo.
• KMU-innovativ. El BMFTR financia proyectos de investigación y desarrollo de alto riesgo en tecnologías clave, entre ellas las tecnologías de la información y la comunicación. El procedimiento tiene dos fases: primero un esbozo de proyecto y después la solicitud. Los plazos son el 15 de abril y el 15 de octubre, y el próximo es el 15 de octubre de 2026 (situación a septiembre de 2026). Página del programa KMU-innovativ.
• Forschungszulage (incentivo fiscal a la I+D). Puede solicitarla cualquier empresa sujeta a tributación en Alemania, con independencia de su tamaño y sector. Primero la BSFZ certifica que se trata de investigación y desarrollo, y después el incentivo se solicita a la oficina tributaria al cierre del ejercicio, también para proyectos ya realizados. Para 2026 se amplió mediante el Investitionssofortprogramm (programa de inversión inmediata). Organismo certificador de la Forschungszulage.
• ERP-Förderkredit Digitalisierung (511, 512). A través de su banco, la KfW financia la digitalización en tres niveles, desde TI, software y nube, pasando por la digitalización de procesos, la seguridad informática y la formación, hasta proyectos de mayor envergadura, incluido expresamente el uso de IA sobre datos de la empresa. La solicitud debe presentarse antes de empezar el proyecto, y para el primer nivel se requiere antes un KfW-Digitalisierungs-Check. Página del producto de la KfW.
• Mittelstand-Digital Zentren. El BMWE financia apoyo gratuito e independiente de proveedores sobre digitalización, IA y seguridad informática, con formadores de IA en los centros. No se paga dinero. La red actual finaliza progresivamente hasta finales de 2026, y a partir del 1 de enero de 2027 le sigue una nueva red con un enfoque adicional en seguridad informática, igualmente gratuita para las pymes. Mittelstand-Digital.

Para consorcios de ciencia e industria está abierta además la directriz del BMFTR sobre proyectos emblemáticos de IA en cadenas de valor, con plazo para esbozos de proyecto el 1 de noviembre de 2026 (situación a septiembre de 2026).

Ayudas a nivel de la UE

A nivel de la UE, hay cuatro vías para proyectos de IA: los European Digital Innovation Hubs, el EIC Accelerator, la financiación en cascada y el programa Europa Digital.

• European Digital Innovation Hubs (EDIH). Consorcios regionales ofrecen servicios gratuitos o subvencionados, como «test before invest», formación y apoyo en la búsqueda de inversión, con prioridades como la IA y la ciberseguridad. Resumen de la Comisión Europea.
• EIC Accelerator. El Consejo Europeo de Innovación apoya a start-ups y pymes individuales con innovaciones disruptivas cercanas al mercado, mediante subvención, participación en el capital o ambas. Las propuestas breves pueden presentarse en cualquier momento, y el próximo plazo para propuestas completas es el 4 de noviembre de 2026 (situación a septiembre de 2026). EIC Accelerator.
• Financiación en cascada. Consorcios de proyectos financiados por la UE transfieren parte de su presupuesto a start-ups y pymes mediante convocatorias abiertas, como importes a tanto alzado, premios o bonos y con procedimientos simplificados, por ejemplo para pequeños experimentos y proyectos piloto. Las convocatorias permanecen abiertas al menos dos meses en el portal Funding & Tenders de la UE. Guía de la Comisión (PDF).
• Programa Europa Digital. La Comisión convoca fondos para IA, supercomputación, ciberseguridad y competencias digitales. Las pymes se benefician sobre todo de forma indirecta, por ejemplo a través de los EDIH. Página del programa.

Programas regionales en Renania-Palatinado

En Renania-Palatinado, las ayudas del estado federado las concede el ISB, y para proyectos de IA son especialmente relevantes cuatro programas.

• InnoTop. Financiación tecnológicamente neutral de estudios de viabilidad y proyectos de investigación y desarrollo para productos, procesos y servicios nuevos o mejorados, dirigida a pymes y SmallMidCaps.
• Innovationsgutschein (FuE-Auftrag). Un bono de innovación: subvención para pymes que encargan trabajos de investigación y desarrollo de hasta doce meses a una universidad o a un instituto de investigación.
• IBI-EFRE. Subvención para inversiones con las que pymes comerciales implantan la digitalización en la producción y en los modelos de negocio. Algunos sectores están excluidos, se aplica un volumen mínimo de inversión y la solicitud se presenta a través del portal del ISB antes de empezar el proyecto. Ficha en la Förderdatenbank.
• Betriebsberatungsprogramm RLP. Subvención para consultoría externa, también expresamente sobre digitalización e inteligencia artificial. Las solicitudes son posibles desde el 16 de diciembre de 2025, y para algunos temas se necesita una recomendación de la cámara. El programa sustituye a la consultoría tecnológica BITT, finalizada a finales de 2025. Página del programa del ISB.

El resumen de los programas de innovación y digitalización está en isb.rlp.de. En el catálogo de la UE para Alemania no se encontró ningún EDIH con sede en Renania-Palatinado (situación a septiembre de 2026). Las opciones más cercanas son el EDIH Saarland, que también se dirige a la Gran Región, y el Mittelstand-Digital Zentrum Kaiserslautern, que apoya a empresas de Renania-Palatinado en la preparación para la IA.

Programas regionales en Renania del Norte-Westfalia

En Renania del Norte-Westfalia, Mittelstand Innovativ & Digital (MID) es la vía de acceso central para las pymes con sede en el estado, y desde el 1 de enero de 2026 es el NRW.BANK quien aprueba los nuevos proyectos.

• MID-Digitalisierung. Subvención para desarrollar productos digitales orientados al mercado con tecnologías clave, incluidas expresamente la IA, el aprendizaje automático y la minería de datos. Página del producto del NRW.BANK.
• MID-Digitale Sicherheit. Subvención para análisis del estado de la seguridad informática, incluidas pruebas de penetración, formación del personal y medidas básicas de protección informática. Portal de ayudas de NRW.

Ambos programas asignan las plazas de solicitud mediante un sorteo mensual. Quien resulta seleccionado dispone de 28 días para presentar la solicitud, y el sorteo todavía no supone un compromiso de ayuda. La convocatoria 2026 de MID-Digitale Prozesse, que financia consultoría externa, ya está cerrada porque se alcanzó el número máximo de solicitudes (situación a septiembre de 2026). Además, en Renania del Norte-Westfalia hay tres EDIH: en Dortmund, en Renania con sede en Aquisgrán y en Westfalia del Sur.

Otros estados federados y programas finalizados

Para todos los demás estados federados, la Förderdatenbank (base de datos federal de ayudas) es el camino más rápido hacia los programas adecuados. Cada estado tiene sus propios programas, y la Förderdatenbank recoge ayudas federales, regionales y de la UE, filtrables por región, beneficiarios y tipo de ayuda. La referencia sigue siendo la página del organismo concedente, porque las convocatorias abren y cierran a lo largo del año.

Han finalizado dos programas federales que todavía se buscan con frecuencia: Digital Jetzt ya no admite solicitudes y go-digital terminó a finales de 2024. También está desfasado el nombre ERP-Digitalisierungs- und Innovationskredit, ya que el producto actual de la KfW es el ERP-Förderkredit Digitalisierung.

Paso a paso hacia la solicitud

En casi todos los programas, el camino hacia la solicitud sigue los mismos diez pasos, aunque los formularios y portales sean distintos.

1. Comprobar la condición de pyme. Según la Recomendación de la UE 2003/361, es pyme la empresa con menos de 250 empleados que respeta los umbrales de volumen de negocio anual o de balance general. Las empresas asociadas y vinculadas pueden computar. La Forschungszulage y el ERP-Förderkredit Digitalisierung están abiertos también a empresas más grandes. Definición de pyme de la UE.
2. Aprovechar la orientación gratuita. Un Mittelstand-Digital Zentrum, un EDIH o el servicio federal de asesoramiento sobre ayudas le ayudan a situar el proyecto antes de invertir esfuerzo en una solicitud.
3. Comprobar el programa y su situación. ¿Está abierto el programa, hay un plazo, un sorteo o una suspensión de solicitudes?
4. No empezar antes de la aprobación. Un inicio anticipado de la medida (vorzeitiger Maßnahmenbeginn), es decir, empezar antes de recibir la resolución de concesión, por regla general no está permitido, salvo que la directriz o una autorización escrita lo admitan. Esto se aplica también a los encargos vinculantes a proveedores de servicios. En la KfW, la solicitud debe presentarse antes de empezar el proyecto.
5. Sumar las ayudas de minimis. Cuando un programa concede ayudas de minimis, rige un límite de 300.000 euros por empresa en tres años. En la solicitud declara usted lo que ya ha recibido en ese periodo. Desde el 1 de enero de 2026 es obligatorio para ello un registro central. Reglamento (UE) 2023/2831.
6. Redactar el esbozo de proyecto. En los procedimientos de dos fases se empieza con un esbozo breve, que debe entenderse sin preguntas adicionales y compite con otros esbozos. Los proyectos los gestionan Projektträger (entidades gestoras de proyectos) como DLR, PtJ o VDI/VDE-IT, que actúan por encargo del ministerio. Nociones básicas de la financiación de proyectos.
7. Presentar la solicitud. Las solicitudes federales de investigación se presentan casi siempre a través de easy-Online, los préstamos de la KfW a través de su banco y los programas regionales a través de los portales del ISB o del NRW.BANK. Los documentos habituales son la descripción del proyecto con plan de trabajo, el plan de costes y financiación, documentación de solvencia, la declaración de pyme, en su caso la declaración de minimis y presupuestos de proveedores.
8. Asegurar la aportación propia. Las subvenciones cubren solo una parte de los costes, y la empresa financia el resto por sí misma.
9. Comprobar la acumulación. Las ayudas pueden combinarse, pero solo dentro de las intensidades de ayuda permitidas, y los mismos costes nunca pueden financiarse dos veces. Lo habitual es repartir por partidas de costes, por ejemplo asesoramiento gratuito, un préstamo para la inversión y la Forschungszulage para la parte de desarrollo.
10. Informar y presentar la justificación. Durante el proyecto usted informa al Projektträger, y al final llega el Verwendungsnachweis, compuesto por una justificación económica y un informe técnico final. Preguntas frecuentes del DLR Projektträger.

Errores típicos

Los errores típicos son de carácter formal y pueden evitarse antes de la solicitud.

• Encargar demasiado pronto. Quien firma de forma vinculante contratos de suministro o de consultoría antes de la aprobación, o según el programa incluso antes de la solicitud, puede perder la posibilidad de recibir la ayuda.
• Sobrestimar la condición de pyme. La filial de un grupo más grande puede no ser pyme, aunque ella misma sea pequeña.
• No comprobar la situación. Los programas también cierran a mitad de año, como muestran la suspensión de solicitudes de ZIM y la convocatoria completa de MID-Digitale Prozesse en 2026.
• Malinterpretar el sorteo. En MID, ser seleccionado no es un compromiso, y el plazo posterior es corto.
• Errar la finalidad del programa. Un programa de consultoría no financia licencias de software, y un Mittelstand-Digital Zentrum no paga dinero.
• Perder el plazo. En KMU-innovativ, un plazo perdido supone medio año de espera.
• Calcular mal el de minimis. El periodo de tres años es móvil y no está ligado a años naturales.
• Confundir nombres. El EDIH Rheinland tiene su sede en Aquisgrán y no es un punto de contacto para Renania-Palatinado. Además, entradas de blog antiguas mencionan programas y nombres de productos que ya no existen.

Qué programa encaja con qué proyecto de IA

El programa adecuado se deriva de la naturaleza del proyecto: investigación, implantación o asesoramiento.

Un proyecto de IA está cerca de la investigación cuando conlleva riesgo técnico, por ejemplo un método nuevo o un modelo para una cuestión cuyo resultado no se conoce de antemano. Para ello están pensados la Forschungszulage, KMU-innovativ, InnoTop y el Innovationsgutschein, ZIM tras su reapertura y, para proyectos disruptivos cercanos al mercado, el EIC Accelerator.

Se trata de implantación cuando una tecnología probada llega a su propia empresa, por ejemplo una búsqueda en sus propios documentos o la automatización de un proceso. Aquí encajan el ERP-Förderkredit Digitalisierung, IBI-EFRE en Renania-Palatinado y MID-Digitalisierung en Renania del Norte-Westfalia si de ello resulta un producto digital. Las convocatorias abiertas de financiación en cascada pueden sostener pequeños proyectos piloto.

El asesoramiento va primero cuando aún no está claro si un caso de uso se sostiene. Los Mittelstand-Digital Zentren y los EDIH son gratuitos, y en Renania-Palatinado la consultoría externa se subvenciona a través del Betriebsberatungsprogramm. Para la seguridad informática en torno a un proyecto de IA, Renania del Norte-Westfalia ofrece MID-Digitale Sicherheit.

Este artículo es información general y no asesoramiento jurídico ni fiscal, y las condiciones de las ayudas cambian.

Un proyecto de IA debería estar acotado antes de plantear la cuestión de la financiación, más información en preparación para la IA.

Qué es Slush

Slush es una conferencia para start-ups e inversores en Helsinki que nació en 2008 como un encuentro de 250 personas. No tiene ánimo de lucro, pertenece a la Startup Foundation finlandesa y la organizan estudiantes y recién titulados junto con un gran equipo de voluntarios.

El evento se celebra el 18 y 19 de noviembre de 2026 en el Helsinki Expo and Convention Centre (Messukeskus), con un programa Day 0 el 17 de noviembre. Según el organizador, asisten más de 12.000 personas, de las cuales unas tres cuartas partes son start-ups o inversores. El foco está en start-ups europeas seleccionadas, inversores internacionales y medios tecnológicos, y Slush menciona expresamente la región DACH como región clave. El programa y los detalles están en la web oficial de Slush.

Qué aporta iiterate

iiterate lleva a Helsinki el trabajo que hacemos a diario: IA para entornos en los que los datos no deben salir de la empresa. Somos una consultora de IA de Adenau, en Renania-Palatinado, y viajamos como parte de la delegación alemana. Nuestras áreas:

• LLM on-premise. Modelos de lenguaje que funcionan en su propia infraestructura.
• RAG y gestión del conocimiento. Sistemas de retrieval que obtienen las respuestas de los documentos de una empresa e indican las fuentes.
• IA con residencia de datos en la UE. Arquitecturas en las que el procesamiento y el almacenamiento permanecen en la Unión Europea.
• Computational design. Modelos paramétricos y configuradores en los que las reglas generan la geometría.

En las conversaciones partimos de preguntas concretas: qué datos afecta un proyecto, dónde puede realizarse el procesamiento y qué arquitectura se deriva de ello.

Quién debería hablar con nosotros

Deberían hablar con nosotros sobre todo inversores, empresas y fundadoras y fundadores que trabajan con IA y datos sensibles.

• Inversoras e inversores que evalúan proyectos de IA en sectores regulados o sensibles en materia de datos.
• Empresas que quieren usar IA sobre documentos confidenciales y necesitan para ello residencia de datos en la UE o en sus propias instalaciones.
• Fundadoras y fundadores que trabajan en IA con datos sensibles y desean hablar de arquitectura, operación o colaboración.

Un proyecto que aún no está del todo definido no es un obstáculo, sino un buen punto de partida para una conversación.

Concertar una reunión en Helsinki

Lo mejor es concertar una reunión en Helsinki con antelación a través de nuestra página de contacto. Indique brevemente su tema y los días en que estará allí. Las conversaciones pueden mantenerse en alemán o en inglés.

La especificación, sin marketing

Antes de hablar de consecuencias conviene la tabla sobria. Todos los valores proceden del resumen de modelos y de la página de precios de Anthropic, consultados el 10 de septiembre de 2026.

Llama la atención lo que Anthropic añade en su propio resumen de modelos: recomienda Claude Opus 5 como opción por defecto para la mayoría de las cargas de trabajo, y reserva Fable 5.1 para los casos en los que Opus 5 con un nivel de esfuerzo superior no basta. Es una autolimitación inusualmente clara y, a la vez, el primer filtro de cualquier decisión de arquitectura. Fable 5.1 no es una mejora general, sino una herramienta para tareas largas y continuas.

La modalidad es estrecha, y eso importa en la práctica. Entran texto e imágenes, sale texto. Ni audio de entrada ni de salida, ni generación de imagen o vídeo. Quien quiera procesar la grabación de una llamada necesita una transcripción delante. Quien necesite respuestas habladas necesita síntesis de voz detrás. Quien quiera generar gráficos necesita otro modelo. Suena trivial, pero desplaza los límites del sistema, los costes y las cuestiones de protección de datos exactamente a los puntos donde se sitúan esos componentes adicionales.

Qué cambia un millón de tokens y qué no

La ventana se factura a las tarifas normales por token en toda su extensión, sin recargo por contexto largo (Anthropic). Eso permite montajes que antes no fallaban por el modelo sino por el troceado: un conjunto completo de contratos o pliegos en una sola pasada en lugar de treinta fragmentos con una fusión posterior; una traza de agente entera, con todas las salidas de herramientas, que sigue siendo analizable en lugar de quedar cortada tras veinte pasos; un repositorio de tamaño medio sobre el que una pregunta se responde de una vez en lugar de mediante una búsqueda que debe adivinar de antemano qué archivos importan. La ganancia está menos en la inteligencia que en la desaparición de toda una clase de trabajo de empalme, y en nuestros proyectos ese empalme era con regularidad la fuente de los errores difíciles de encontrar.

Pero la cifra no es un número de páginas. Anthropic estima 1.000.000 de tokens en unas 555.000 palabras inglesas con el tokenizador actual y señala en el mismo movimiento que ese tokenizador produce alrededor de un 30 por ciento más de tokens para el mismo texto que el anterior (Anthropic). El dato se refiere a texto en inglés; para un corpus en alemán no puede deducirse ninguna cifra a partir de ahí, hay que medirla. Quien planifica capacidad cuenta sus propios documentos con el tokenizador del modelo que realmente usa, y no calcula en páginas.

Por el mismo motivo, comparar tamaños de ventana entre proveedores no dice nada. Un token es una unidad propia de cada proveedor, y no existe conversión publicada que lleve dos tokenizadores a la misma cantidad de texto. Una cifra en una ficha técnica no indica, por tanto, qué modelo abarca más de su texto.

Y la ventana mayor no vuelve superflua la recuperación. El razonamiento es sencillo: todo lo que está en la ventana se paga en cada llamada y debe procesarse en cada llamada. Un procedimiento que encuentra los veinte párrafos pertinentes sigue siendo más rápido, más barato y por lo general más preciso que otro que introduce diez mil párrafos y confía en la atención. La ventana grande eleva mucho el umbral a partir del cual el troceado se vuelve necesario. No sustituye a la pregunta de qué información hace falta para esta respuesta concreta.

La verdadera historia de ingeniería se llama lectura de caché

La cifra más interesante de la especificación no es un valor absoluto sino una proporción. La entrada nueva cuesta 10 USD por millón de tokens; un acierto de caché, 0,25 USD. Escribir en la caché cuesta 12,50 USD por millón de tokens en el nivel de cinco minutos y 20 USD en el de una hora. En Fable 5.1 y Mythos 5.1 el precio de lectura es 0,025 veces el precio base, frente a 0,1 veces en todos los demás modelos Claude, y según Anthropic ese es el único cambio de precio respecto a Fable 5 (Anthropic).

El factor 40 entre entrada nueva y acierto de caché es lo que decide los diseños. En un bucle de agente, el mismo prompt de sistema, las mismas definiciones de herramientas y el mismo contexto de proyecto se releen en cada paso. Una tarea de doscientas llamadas a herramientas relee doscientas veces el mismo preámbulo. Que ese preámbulo se facture cada vez como entrada nueva o como acierto de caché no es un detalle contable, sino la frontera entre un diseño que se puede llevar a producción y otro que se queda en la demostración.

Precisamente por eso, la formulación de la propia Anthropic de que las cargas típicas resultan alrededor de un 25 por ciento más baratas y las muy agénticas hasta un 45 por ciento es una estimación sobre tasas de acierto de caché y no una bajada de precio (Anthropic). Los precios de cabecera de entrada y salida no han cambiado respecto a Fable 5. Una carga con mala localidad de caché no ve casi nada de ese ahorro, y quien escribe el 25 por ciento en un presupuesto sin esa salvedad no tiene un presupuesto sino una esperanza.

Lo que hace buenas o malas las tasas de acierto en la práctica no es una métrica documentada sino lógica de ingeniería, y puede enunciarse:

• Un prefijo estable. Lo que se reutiliza es el comienzo inalterado de la petición. Todo lo constante va delante y todo lo variable detrás. Una marca de tiempo, un identificador de sesión o un nombre de usuario en el lugar equivocado invalida todo el contexto que sigue.
• Ensamblaje determinista. Listas de herramientas en orden aleatorio, resultados de recuperación con ordenación cambiante u objetos con orden de claves inestable generan un prefijo nuevo en cada ejecución. La caché no ve entonces dos veces lo mismo.
• La vida útil frente al ritmo de la tarea. Cinco minutos encajan con un bucle de agente de cadencia estrecha. No encajan con un diálogo en el que una persona pasa veinte minutos en una reunión entre dos preguntas. El nivel de una hora cuesta más al escribir y solo compensa cuando de verdad rescata el acierto.
• Suficiente repetición por prefijo. Muchas peticiones cortas y sin relación entre sí se reparten entre muchos prefijos. Cada una paga una escritura y rara vez obtiene una lectura. Ese es el caso en el que la economía de la caché juega en su contra, y entonces la interfaz por lotes con un 50 por ciento de descuento en ambos sentidos suele ser el mejor camino.

Un indicio concreto de la lista de precios respalda el mismo punto: el conjunto de herramientas para uso del ordenador añade unos 4.500 tokens de entrada por petición y el de uso del navegador unos 6.600 (Anthropic). Es un bloque constante que reaparece en cada paso y, por tanto, exactamente el material que corresponde a un prefijo estable.

Operación agéntica, herramientas y la cuestión del nivel de esfuerzo

Fable 5.1 está pensado para ejecuciones largas. Anthropic cita como prueba una ejecución no supervisada de 38 horas sobre un problema de aprendizaje automático (Anthropic). Es una declaración del proveedor sobre una única ejecución y no un resultado de distribución, pero sirve como orden de magnitud de aquello para lo que se diseñó el modelo.

El modo de razonamiento es adaptativo y está siempre activo; el anterior modo manual con presupuesto explícito de razonamiento ya no se acepta. Frente a Fable 5 hay tres cambios de ruptura que afectan a cualquier integración existente: el uso forzado de herramientas devuelve un error, los modelos anteriores no pueden leer los bloques de razonamiento de este modelo y editar turnos anteriores invalida dichos bloques. Como añadidos llegan, entre otros, un nivel de esfuerzo por mensaje, mensajes de sistema válidos por turno, avisos de progreso legibles entre llamadas a herramientas y el precio reducido de lectura de caché; varios están marcados como beta (Anthropic). Para la planificación esto significa que cambiar a este modelo no es un ajuste de configuración, sino una pequeña reconstrucción seguida de pruebas.

Con los niveles de esfuerzo hace falta cuidado. La documentación nombra high como valor por defecto (Anthropic), y el anuncio precisa que ese valor difiere según la superficie: high en Claude Code, medium en Claude Cowork y en claude.ai (Anthropic). El conjunto completo de valores aceptados no figura en las páginas de documentación que consultamos, de modo que no lo afirmamos.

La consecuencia práctica es incómoda pero importante: una cifra de benchmark o una estimación de coste sin nivel de esfuerzo indicado no es reproducible. Dos equipos que miden el mismo modelo a través de dos superficies distintas miden configuraciones distintas. Quien quiera que sus propuestas, resultados de prueba o comparaciones internas se sostengan anota el nivel junto a la cifra, igual que no dejaría pasar una medición sin unidad.

Un conocimiento hasta junio de 2026 es un requisito de arquitectura

El corte de conocimiento y de datos de entrenamiento está en junio de 2026 (Anthropic). En términos operativos eso no significa nada dramático y mucho a la vez. Su lista de precios de la semana pasada, la decisión de ayer, el estado de su cartera de pedidos esta mañana: nada de eso está en el modelo. Tiene que llegar al contexto por recuperación, por una conexión de herramienta o por el prompt.

No es un defecto del modelo sino un requisito para la arquitectura, y es independiente del proveedor. Cualquier sistema que deba informar sobre hechos actuales sin un camino definido por el que esos hechos entren está mal especificado, por bueno que sea el modelo. Dos consecuencias nos han funcionado bien. Primera: toda respuesta basada en hechos exige una fuente nombrable en el contexto, no la memoria del modelo. Segunda: todo conjunto de evaluación necesita algunas preguntas cuya respuesta correcta cambió después del corte, porque prueban justo el camino que en producción se rompe en silencio con más facilidad.

La marca de agua del artículo 50 no es una pista de auditoría

Fable 5.1 y Mythos 5.1 llevan desde el lanzamiento una marca de agua invisible en el texto (Anthropic). Anthropic aplica el marcado en todo el mundo y no solo en la UE (Euronews). El trasfondo son las obligaciones de transparencia del artículo 50 del Reglamento de IA, aplicables desde el 2 de agosto de 2026, que exigen un marcado legible por máquina de los contenidos sintéticos.

Lo decisivo es la salvedad que la propia Anthropic formula. Una marca detectada indica que un contenido pudo haber sido procesado por Claude, expresamente no es concluyente del todo y por sí sola no confirma la procedencia del contenido (Anthropic Help Center). A ello se suma que la interfaz de detección solo está abierta a un círculo restringido en una vista previa cerrada (MacRumors).

Para una empresa que quiera documentar su propio uso de la IA se deriva de ahí una indicación de diseño sobria, y se trata de una valoración técnica y no de asesoramiento jurídico: la marca de agua es una señal dentro de la salida que no le pertenece, que por lo general usted no puede leer y cuyo valor probatorio limita el propio proveedor. No es, por tanto, una pista de auditoría. Si ha de poder rastrearse qué modelo generó qué salida a partir de qué entrada y en qué momento, y quién la aprobó, esa prueba nace en sus propios registros. Técnicamente es poco espectacular, porque son los mismos registros que se llevan de todos modos para depuración y control de costes.

La condición que decide la arquitectura en Alemania

En los proyectos alemanes, el tratamiento de los datos decide sobre el uso de un modelo con más frecuencia que su capacidad. Aquí la situación está documentada con claridad y sorprende a muchos. Anthropic clasifica Fable 5.1 como Covered Model. Estos modelos exigen una conservación de datos de 30 días y no están disponibles bajo retención cero de datos salvo autorización expresa de Anthropic. Una organización que opere con retención cero debe activar deliberadamente la conservación para un espacio de trabajo concreto; de lo contrario las peticiones se rechazan con un error (Anthropic).

Dos añadidos de la misma fuente son necesarios, porque sin ellos el cuadro queda torcido. Los datos conservados, según Anthropic, no se utilizan para el entrenamiento de modelos sin permiso expreso. Y también bajo retención cero pueden conservarse hasta dos años los contenidos marcados como llamativos. La retención cero tampoco cubre todas las vías de entrada al sistema, entre ellas ni la interfaz por lotes ni el almacén de archivos.

A eso se suma la cuestión regional. En la interfaz de primera parte no existe una región de inferencia en la UE. El parámetro de región de inferencia acepta exactamente dos valores, global y us, y el almacenamiento se produce exclusivamente en Estados Unidos; la región de un espacio de trabajo no puede modificarse tras su creación (Anthropic). El camino practicable dentro de la UE pasa por una nube socia: Amazon Bedrock y Google Cloud ofrecen puntos de acceso regionales con enrutamiento garantizado de los datos, con un recargo del 10 por ciento frente a los puntos globales, y fijan sus propias fechas de ciclo de vida (Anthropic).

Esto es un dato de diseño y no un veredicto sobre el modelo. En la práctica quedan tres vías, y la elección se hace antes del primer prototipo, no después. Primera: punto de acceso regional en una nube socia, con el recargo y con el proveedor de nube como encargado del tratamiento. Segunda: interfaz de primera parte con conservación activada de forma consciente, para clases de datos en las que eso sea defendible. Tercera: la clase de datos en cuestión no llega en absoluto a este modelo, porque otro modelo o una instalación local asume la parte que ve los campos sensibles. La tercera vía se examina demasiado poco, aunque en sistemas de conocimiento y de documentos suele ser la más limpia.

Qué cambia y qué no toca este modelo

Dicho con honestidad, cambia un conjunto abarcable pero valioso de clases de tareas. Los análisis sobre corpus que hasta ahora fallaban por el troceado se vuelven viables en una sola pasada. Las ejecuciones de agentes que antes se desmoronaban en el límite del contexto se mantienen continuas. Y los diseños que deben releer muy a menudo la misma base se vuelven económicos gracias al precio de lectura de caché, siempre que el montaje dé la tasa de acierto. Son tres desplazamientos reales y afectan justo al trabajo que en una consultoría aparece de otro modo como faena rutinaria.

Dicho con la misma honestidad, lo que permanece igual. También las capacidades del modelo tienen límites: las pruebas de intrusión, la generación de exploits, el análisis basado en binarios y las tareas de investigación biológica se derivan a los modelos Opus, y el modo rápido no está disponible en Fable 5.1 (Anthropic, Anthropic).

Más importantes son, sin embargo, los problemas que ningún modelo toca. La calidad de los datos sigue siendo su tarea: una ventana mayor solo lee con más detenimiento unos datos maestros contradictorios. La definición de procesos sigue siendo su tarea: un agente que no sabe cuándo un asunto está decidido solo reproduce la ambigüedad que ya había en el equipo. Los permisos siguen siendo su tarea: un modelo al que se le deja verlo todo es un problema de protección de datos con buen don de lenguas. La evaluación sigue siendo su tarea, porque sin un conjunto de casos con respuesta correcta conocida nadie puede decir si un cambio mejoró algo. Y el coste del error se queda donde estaba: en una lista de sugerencias un fallo es molesto, en una factura emitida es caro. Esa distinción decide el grado de automatización, y es una cuestión de negocio.

Nuestra posición es sin dramatismo: Fable 5.1 desplaza el límite de lo que un montaje puede sostener, y lo desplaza en un punto que en la práctica frenaba de verdad. No desplaza ni una sola de las preguntas que deben estar resueltas antes. ¿Cuál de esas preguntas sigue abierta en su próximo proyecto?

Este artículo lee la publicación como debería leerla una empresa que está decidiendo si construir sobre ella: qué especificaciones cuentan de verdad, qué hay de real en la estructura de precios y qué es una estimación modelada, qué se rompe en la interfaz y por qué la vía europea hacia este modelo pasa por una nube asociada y no por Anthropic.

Qué se publicó realmente el 1 de septiembre

Anthropic publicó Claude Fable 5.1 el 1 de septiembre de 2026, junto con Claude Mythos 5.1. Según la propia exposición de Anthropic, ambos son el mismo modelo con distintos niveles de salvaguardas: Fable 5.1 está disponible de forma general, Mythos 5.1 solo por invitación a través de programas de acceso de confianza. La prensa especializada confirma la fecha y la disponibilidad en todas las plataformas desde el día del lanzamiento.

El identificador del modelo es claude-fable-5-1 y, en Amazon Bedrock, anthropic.claude-fable-5-1. Se entrega a través de la API de Claude, Amazon Bedrock, Google Cloud, Microsoft Foundry y Claude Platform en AWS. Anthropic menciona como superficies Claude Code, Claude Enterprise y Claude Platform, con valores predeterminados de esfuerzo distintos: high en Claude Code y medium en Claude Cowork y en claude.ai. Existe un compromiso de retirada: en las plataformas operadas por Anthropic el modelo no se apagará antes del 1 de septiembre de 2027, mientras que Bedrock y Google Cloud fijan sus propias fechas.

Merece atención lo que Anthropic añade en esa misma documentación. Fable 5.1 se describe como destinado al razonamiento exigente y al trabajo agéntico de largo recorrido; como opción predeterminada para la mayoría de las cargas de trabajo, Anthropic sigue recomendando explícitamente Claude Opus 5 y reserva Fable 5.1 para los casos en que Opus 5 con esfuerzo alto no basta. Quien tenga que justificar el cambio internamente debería conocer esa frase: el propio fabricante no recomienda su nuevo buque insignia de forma general.

Las especificaciones que sostienen una decisión

Los datos básicos proceden de la documentación de modelos de Anthropic y pesan más en una decisión de arquitectura que cualquier clasificación.

Dos puntos merecen más que una fila de tabla. Primero, el modo de razonamiento: Fable 5.1 razona de forma adaptativa y permanente, y el antiguo modo manual con thinking.type: enabled y budget_tokens ya no se acepta. Quien porte una integración existente tendrá que tocar ese punto del código.

Segundo, la ventana de contexto. Un millón de tokens equivale, según Anthropic, a unas 555.000 palabras en inglés, medidas con el tokenizador actual introducido con Claude Opus 4.7. Ese mismo tokenizador produce alrededor de un 30 % más de tokens para el mismo texto que el anterior. Una cifra de ventana de contexto no es, por tanto, una indicación de capacidad comparable a la ligera entre generaciones de modelos, y menos aún entre proveedores. Para la planificación presupuestaria cuenta cuántos tokens genera realmente su propio corpus de texto, no el titular.

Este artículo se ciñe a propósito a pocos resultados de rendimiento, porque son objeto de un artículo comparativo aparte. Solo esto, y expresamente como cifras del fabricante: Anthropic informa para Fable 5.1 de un 52,6 % en Terminal-Bench-Science 0.1 frente al 24,7 % de Fable 5, y de un 55,8 % en Terminal-Bench 4.0 frente al 42,0 %. La columna de comparación de la tabla de Anthropic es GPT-5.6 Sol. El buque insignia actual de OpenAI, GPT-6 Astra, salió dos días después de esta publicación y no aparece en las cifras de Anthropic.

El precio: solo ha cambiado una línea

La documentación de precios de Anthropic indica los siguientes valores para Fable 5.1, en dólares estadounidenses por millón de tokens.

Solo una línea resulta interesante. En Fable 5.1 y Mythos 5.1 las lecturas de caché se facturan a 0,025 veces el precio de entrada, mientras que en cualquier otro modelo de Claude rige un factor de 0,1. Es el único cambio de precio respecto a Fable 5, cuya lectura de caché estaba en 1,00 dólar estadounidense por millón de tokens. Entrada y salida permanecen iguales. La ventana de contexto completa se factura a las tarifas normales por token; no hay recargo por contexto largo.

Anthropic cifra el ahorro en aproximadamente un 25 % frente a Fable 5 para cargas de trabajo típicas y hasta aproximadamente un 45 % para trabajo fuertemente agéntico. Esa cifra es lo bastante importante como para leerla bien: se trata de una estimación modelada del fabricante que procede íntegramente de la línea de caché, y no de una bajada de precio. Si sus solicitudes rara vez releen el mismo contexto, no ahorra nada. Si opera un bucle agéntico que relee cien veces el mismo prompt de sistema, la misma base de código y las mismas definiciones de herramientas, ahorra mucho. La diferencia entre ambos casos es su tasa de aciertos de caché, y esa solo la conoce su propio perfil de carga.

Un detalle más para el cálculo de costes: si la inferencia se fija a Estados Unidos mediante inference_geo: "us", se aplica un factor de 1,1 a entrada, salida, escritura de caché y lectura de caché.

En el entorno competitivo, esta línea de caché es la única diferencia real de precio en la cima. OpenAI también indica 10 y 50 dólares estadounidenses por millón de tokens de entrada y salida para gpt-6-astra, pero 1,00 dólar para las entradas en caché. En las lecturas de caché Fable 5.1 se sitúa así en una cuarta parte del precio, lo que puede ser decisivo en bucles agénticos largos. Todo lo demás sobre esa comparación, incluida la cuestión de qué cifras de benchmark son realmente comparables, está en el artículo específico.

Qué cambia en la interfaz y qué se rompe

Como prueba de autonomía de largo recorrido, Anthropic cita una ejecución no supervisada de 38 horas sobre un problema de aprendizaje automático. Quien quiera construir sobre eso debería leer primero la lista de cambios de interfaz, porque tres de ellos rompen código existente.

Cambios que rompen respecto a Fable 5:

• El uso forzado de herramientas devuelve un error.
• Los modelos anteriores no pueden leer los bloques de razonamiento de Fable 5.1.
• Editar turnos anteriores invalida los bloques de razonamiento.

Añadidos:

• Nivel de esfuerzo por mensaje (beta).
• Mensajes de sistema con validez para un único turno (beta).
• Actualizaciones de progreso legibles entre llamadas a herramientas mediante display: "updates" (beta).
• El precio reducido de las lecturas de caché.
• El marcado de procedencia de los contenidos.

Para las arquitecturas agénticas también importa el sobrecoste en tokens de los conjuntos de herramientas: computer_toolset_20260801 añade unos 4.500 tokens de entrada por solicitud y browser_toolset_20260801 unos 6.600. Es una carga base que se produce en cada solicitud y que pertenece a toda estimación de costes. El modo rápido, que existe como vista previa de investigación en Claude Opus 5 y Opus 4.8, no está disponible para Fable 5.1.

En el plano de la seguridad, Anthropic informa de que las salvaguardas en ciberseguridad bloquean un 60 % menos de falsos positivos que antes y de que las salvaguardas en biología se activan un 85 % menos en solicitudes benignas de biología elemental. Al mismo tiempo quedan excluidas clases enteras de tareas: pruebas de penetración, generación de exploits, análisis basado en binarios y tareas de investigación en biología se redirigen a modelos Opus. Fable 5.1 puede identificar vulnerabilidades de software, mientras que la generación de exploits sigue bloqueada. Las cuentas de API nuevas tampoco pueden ya editar manualmente el contexto anterior en conversaciones de varios turnos; Anthropic lo justifica diciendo que así se cierra una técnica de destilación habitual y documentada públicamente. Para los equipos que reescriben historiales de conversación de forma programática, es un cambio de comportamiento con efecto directo sobre arquitecturas existentes.

Residencia de datos: en Anthropic no existe una región de la UE

Aquí se separa la historia técnica de la historia de gobernanza. La documentación de Anthropic sobre residencia de datos es inequívoca: el parámetro inference_geo acepta exactamente dos valores, global y us. Entre las limitaciones actuales se afirma literalmente que solo esos dos están disponibles. En la API propia de Anthropic no existe una región de inferencia en la UE.

Lo mismo vale para los datos en reposo. La región de un workspace se fija al crearlo, después ya no puede modificarse, y el único valor disponible es Estados Unidos.

Aquí dos fuentes de Anthropic parecen contradecirse, y conviene decirlo abiertamente. El centro de ayuda de privacidad, actualizado por última vez el 15 de junio de 2026, dice que el tráfico de clientes puede enrutarse por defecto a determinados países de Estados Unidos, Europa, Asia y Australia, y añade en el mismo texto que los datos se almacenan en Estados Unidos. La documentación de la plataforma, en cambio, solo conoce las dos regiones de inferencia citadas. La conciliación está en la distinción entre enrutamiento y residencia: el modo global puede pasar por Europa, pero no es una garantía seleccionable de que el tratamiento y el almacenamiento tengan lugar en la UE. Quien necesite esa garantía no la encontrará aquí.

El parámetro inference_geo existe además solo a partir de Claude 4.6; los modelos anteriores responden con un error 400. No existe en Amazon Bedrock ni en Google Cloud, donde el punto de conexión o el perfil de inferencia determina la región. Microsoft Foundry ofrece en su lugar un tipo de despliegue con zona de datos de EE. UU. El parámetro tampoco está disponible a través del punto de conexión compatible con el SDK de OpenAI.

La vía europea practicable no pasa, por tanto, por Anthropic sino por una nube asociada. Bedrock y Google Cloud ofrecen puntos de conexión regionales con enrutamiento garantizado de datos, con un recargo del 10 % respecto a los puntos de conexión globales según la documentación de precios de Anthropic, y fijan sus propias fechas de ciclo de vida. Eso convierte también la afirmación extendida de que Claude tiene residencia de datos en la UE porque se ejecuta en Fráncfort en algo medio cierto y, en la práctica, engañoso: los modelos de Claude pueden ejecutarse en regiones de la UE, pero allí el encargado del tratamiento es el proveedor de nube y no Anthropic. Para la construcción contractual esa es exactamente la diferencia.

Covered Model: 30 días de retención son condición, no opción

La frase más incómoda de toda la documentación está en la página de Anthropic sobre API y retención de datos. Allí se dice, respecto a Claude Fable 5.1, Mythos 5.1, Fable 5 y Mythos 5, que estos modelos requieren una retención de datos de 30 días y no están disponibles bajo zero data retention salvo autorización expresa de Anthropic. Están clasificados como Covered Models.

En la práctica significa que una organización que hoy trabaja bajo zero data retention no puede simplemente activar Fable 5.1. Debe habilitar expresamente la retención de 30 días en un workspace concreto, o la API responde con 400 invalid_request_error. No es una sutileza de configuración, sino una decisión que en muchas casas debe pasar por la aprobación de protección de datos antes de que exista la primera línea de código de integración.

Por completitud, los compromisos de Anthropic van al lado: los datos retenidos, según sus propias palabras, nunca se usan para entrenar modelos sin permiso expreso, y el contenido de las conversaciones no se retiene por defecto fuera de la excepción de Covered Model.

Incluso quien ya tenga implantado el zero data retention debería conocer sus límites, más estrechos de lo que sugiere el nombre.

• El ZDR se habilita por organización, a petición a través del equipo comercial, y no se extiende automáticamente a organizaciones hermanas bajo la misma cuenta.
• No cubre la API Batch, la API Files, la ejecución de código, Claude for Excel ni las interfaces de producto de Claude Teams y Claude Enterprise. Claude Code a través de Claude Enterprise con ZDR es la excepción mencionada.
• CORS no está soportado para organizaciones con ZDR.
• Si un chat o una sesión se marca, Anthropic puede conservar entradas y salidas hasta dos años, también bajo ZDR.

La dirección es, pues, inequívoca, y va en contra de la historia de precios. Fable 5.1 es más barato en el bucle agéntico que cualquier otro modelo de Claude y, bajo reglas europeas estrictas, al mismo tiempo más difícil de adoptar que los modelos de Claude que no figuran en esa lista.

Artículo 50: marca de agua desde el primer día, con la reserva del propio Anthropic

Según Anthropic, Fable 5.1 y Mythos 5.1 llevan una marca de agua textual invisible desde el día del lanzamiento. El artículo 50 del Reglamento de IA de la UE, que exige el marcado legible por máquina de los contenidos sintéticos, se aplica desde el 2 de agosto de 2026. Anthropic aplica el marcado en todo el mundo y no solo en la UE.

Quien quiera integrar la marca de agua en un proceso de verificación debería conocer la reserva del propio Anthropic, expuesta con claridad en su centro de ayuda: una marca detectada indica que el contenido puede haber sido procesado por Claude, es "not fully conclusive", es decir, no plenamente concluyente, y por sí sola no confirma la procedencia completa del contenido. No es, por tanto, una prueba en sentido jurídico, y esperar establecer con ella la autoría va más allá de lo que el propio fabricante afirma. La constelación es notable: el marcado es una característica real del modelo, y su valor probatorio lo relativiza la misma empresa que lo ofrece.

A ello se suma el acceso. La API de detección está en vista previa privada y abierta solo a organizaciones elegibles; se mencionan autoridades reguladoras, fuerzas del orden, medios, verificadores de datos, investigación, centros educativos y organizaciones de la sociedad civil de la UE. Una empresa que quiera comprobar por su cuenta textos entrantes no puede hacerlo por esta vía en este momento.

El marco regulatorio circundante, tal como lo describen los organismos que lo publican: la aplicación a los modelos de IA de uso general rige también desde el 2 de agosto de 2026, con multas de hasta 15 millones de euros o el 3 % de la facturación anual mundial para los proveedores no conformes de tales modelos, hayan firmado o no el código de buenas prácticas. El código de buenas prácticas de la Comisión Europea obliga a los firmantes a un formulario de transparencia publicado, una metodología de evaluación de riesgos sistémicos y un marco de cumplimiento en materia de derechos de autor, con conservación de la documentación durante al menos diez años. Estas obligaciones recaen sobre los proveedores de modelos. Lo que de ello se derive para su propia casa depende de su papel en la cadena de suministro y es una pregunta para su asesoría jurídica, no para un artículo profesional.

Qué significa esto para una decisión en Alemania

En conjunto, la publicación ofrece una imagen inusualmente clara, precisamente porque las dos historias apuntan en direcciones opuestas. Técnicamente, Fable 5.1 es la opción más barata para bucles agénticos largos en los que se lee una y otra vez el mismo contexto. En términos regulatorios es un modelo que ni siquiera puede arrancarse sin una retención de 30 días.

Por eso deberían quedar resueltas cuatro preguntas antes de empezar la integración.

1. ¿Cuál es realmente su tasa de aciertos de caché? Todo el ahorro depende de esa única métrica. Mídala con un perfil de carga real antes de presupuestar un 25 %.
2. ¿Soporta su aprobación de protección de datos una retención de 30 días? Si no, Fable 5.1 no es una opción hasta que Anthropic lo autorice expresamente, y la cuestión no se puede rodear técnicamente.
3. ¿Por qué punto de conexión pasa la inferencia? Si se requiere tratamiento en la UE, la vía pasa por Bedrock o Google Cloud, con un recargo del 10 % frente a los puntos de conexión globales, con el proveedor de nube como encargado del tratamiento y con sus propias fechas de ciclo de vida.
4. ¿Basta con Opus 5? El propio Anthropic recomienda Opus 5 como opción predeterminada, y Opus 5 no figura en la lista de Covered Models. Parte de las cuestiones de gobernanza descritas aquí no se plantean allí de esta forma.

Nada de esto es un argumento contra Anthropic. Fable 5.1 es un modelo sólido, el cambio en la caché es una mejora real para el trabajo agéntico, y que los hechos incómodos se puedan consultar con limpieza en la propia documentación de Anthropic habla a favor del proveedor y no en su contra. Es un argumento para invertir el orden: aclarar primero bajo qué condiciones pueden tratarse sus datos y elegir después el modelo. Lo que Fable 5.1 rinde realmente en el trabajo diario se aborda en un artículo propio sobre las capacidades en la práctica; cómo se sitúa frente a GPT-6 Astra, en otro.

La tabla que casi todo el mundo publica está rota

La frase más frecuente en la cobertura actual viene a decir esto: los propios benchmarks de Anthropic situarían a Claude Fable 5.1 por delante de GPT-6 Astra. Esa frase es falsa, y basta un calendario para refutarla.

Anthropic publicó su tabla de benchmarks el 1 de septiembre de 2026. La columna de comparación lleva ahí la denominación GPT-5.6 Sol. GPT-6 Astra pasó a vista previa limitada el 3 de septiembre y a disponibilidad general el 4 de septiembre. Anthropic, por tanto, no solo no midió Astra: no podía medirlo, porque el modelo no era público en la fecha de publicación.

Quien lee la fila de Terminal-Bench 4.0, donde 55,8 % para Fable 5.1 se enfrenta a 37,3 %, y toma ese 37,3 % por Astra, está comparando el modelo actual de Anthropic con el predecesor del competidor. No es un error de redondeo, es otra afirmación. Y es justamente la lectura errónea que hoy se propaga más rápido por agregadores y resúmenes.

El valor de este artículo reside, pues, menos en las cifras que en la clasificación: qué comparaciones se sostienen, cuáles no y en qué se reconoce la diferencia.

Lo que realmente se compara de igual a igual

Queda un núcleo pequeño pero limpio. Todas las filas de la tabla siguiente proceden de la documentación de modelo de Anthropic, de la página de precios de Anthropic y de la documentación para desarrolladores de OpenAI sobre gpt-6-astra, consultadas el 10 de septiembre de 2026. Son declaraciones de cada proveedor sobre su propio producto, en la misma unidad y sin marco de medición de por medio.

Una salvedad corresponde a la fila de escritura de caché: Anthropic vende dos duraciones de retención, cinco minutos y una hora, mientras que OpenAI no publica ningún tramo equivalente. Los dos importes de 12,50 USD están próximos, pero no son perfectamente paralelos.

La fila económicamente interesante es la lectura de caché. Un factor cuatro a favor de Anthropic suena a partida menor, pero en el trabajo agéntico no lo es: allí el mismo contexto, repositorio, instrucción de sistema y descripciones de herramientas se relee una y otra vez a lo largo de cientos de pasos. El propio Anthropic cifra el ahorro resultante en alrededor del 25 % frente a Fable 5 en cargas típicas y hasta alrededor del 45 % en cargas muy agénticas. Esa cifra es un cálculo de modelo del proveedor, no una bajada de precio: los precios de lista de entrada y salida no han cambiado, y una carga con pocos aciertos de caché no ahorra prácticamente nada.

Dos partidas más pertenecen a cualquier cálculo. La API Batch de Anthropic reduce a la mitad ambos sentidos, a 5 USD de entrada y 25 USD de salida por millón de tokens. Y fijar la inferencia en Estados Unidos en Anthropic aplica, según la documentación de Anthropic sobre residencia de datos, un multiplicador de 1,1 sobre entrada, salida, escrituras y lecturas de caché.

Terminal-Bench 4.0: la única cifra con una verificación cruzada real

Una fila de benchmark merece aquí una confianza particular, por un motivo que rara vez se explica.

El 1 de septiembre de 2026, Anthropic indica para Claude Fable 5.1 en Terminal-Bench 4.0 un 55,8 %. En los resultados que OpenAI comunica para GPT-6 Astra, recogidos por DataCamp el 3 de septiembre de 2026 y etiquetados allí expresamente como cifras del proveedor, Astra aparece con 57,7 % y Fable 5.1 figura con un 55,8 % inalterado.

Ambos proveedores llegan, pues, de forma independiente a la misma cifra para el modelo del otro bando. Es la verificación individual más sólida disponible en toda esta comparación. Un proveedor tiene poco incentivo para puntuar al alza a un competidor, y cuando dos partes con intereses opuestos comunican la misma cifra, eso apunta a que la cifra sobrevive al montaje en lugar de ser una medición doméstica.

Aun así quedan dos limitaciones. Primera: ninguna de las dos publicaciones indica con qué harness, qué scaffold y qué nivel de esfuerzo se midió. Segunda: la distancia de 1,9 puntos porcentuales es lo bastante pequeña como para proceder exactamente de esos factores. La lectura defendible es, por tanto: en Terminal-Bench 4.0 ambos modelos están próximos según los datos de los dos proveedores, con una ligera ventaja de Astra según la medición de OpenAI.

Lo que no es comparable, y por qué

La mayor parte de las cifras publicadas no pertenece a una tabla común. No es formalismo, es la diferencia entre una base de decisión y un muro de números.

• OSWorld 2.0. Anthropic da dos valores para Fable 5.1, 77,9 % con crédito parcial y 41,7 % con puntuación estricta. Del lado de OpenAI figura para Astra un valor único de 72,6 %, sin indicación del modo de puntuación. Enfrentar 72,6 a 77,9 es tan infundado como enfrentarlo a 41,7. Mientras el modo de puntuación no coincida, aquí no hay comparación, solo selección.
• Ventana de contexto. Anthropic indica 1.000.000 de tokens, OpenAI 1.050.000 con una entrada máxima de 922.000 tokens. Estas cifras no son una medida de capacidad en la misma escala, porque un token significa algo distinto según el tokenizador. Anthropic escribe él mismo que su tokenizador actual produce alrededor de un 30 % más de tokens para el mismo texto que el suyo anterior. No hay públicamente ninguna cifra de tokens por palabra entre proveedores, de modo que la pregunta de qué modelo alberga más texto no puede responderse desde fuentes abiertas.
• AutomationBench. Anthropic publica un 31,4 % para Fable 5.1. En su propia publicación de anuncio, OpenAI reclama el primer puesto en el mismo benchmark pero no da allí ninguna cifra. Sencillamente no hay nada que comparar.
• Filas en las que la cifra de Claude no procede de Anthropic. Para ScreenSpot-Pro, FrontierMath Tier 4 v2, ExploitBench, ARC-AGI-3, GPQA Diamond y FrontierCode 1.1 solo existen valores del lado de OpenAI. La cifra de Claude en esas filas es la medición de Claude realizada por OpenAI y, en varios casos, una medición de Claude Fable 5 o Claude Opus 5, no de Fable 5.1. Atribuirla a Anthropic supone citar la fuente equivocada y, en parte, el modelo equivocado.
• Niveles de esfuerzo. Ambos proveedores permiten un cómputo variable por petición. En Anthropic incluso el valor por defecto difiere según la superficie: high en Claude Code, medium en claude.ai y Claude Cowork. Artificial Analysis mide en los niveles «max» y «xhigh». Una cifra de benchmark sin nivel de esfuerzo declarado no es comparable con una cifra obtenida en otro nivel. No es una sutileza: es la razón más probable de que una misma clasificación muestre tres resultados en tres sitios web.

Un caso particular merece una advertencia: el 99,9 % que circula para Astra en ARC-AGI-3 lleva en la fuente la coletilla «harness adaptador» y aparece junto a un 7,8 % del modelo anterior. Un salto de unos 92 puntos a través de un cambio de harness describe primero el harness y solo después el modelo. Esa cifra no pertenece a ningún titular.

Las clasificaciones de terceros se contradicen abiertamente

Quien desconfía de las cifras del proveedor recurre a clasificaciones independientes. En este caso no ayuda, porque las clasificaciones se contradicen entre sí, y sobre un único y mismo índice.

Artificial Analysis, en su propio artículo del 3 de septiembre de 2026, da para el Intelligence Index: GPT-6 Astra 61, GPT-5.6 Sol 61, Claude Fable 5.1 66, este último en el nivel de esfuerzo máximo con una configuración de reserva que no es el valor por defecto de la API. BenchLM recoge el mismo índice de otra forma en septiembre de 2026: GPT-5.6 Sol encabeza con 58,9 % y Fable 5.1 queda en 53,7 %. llm-stats, consultado el 10 de septiembre de 2026, sitúa a Fable 5.1 en 56,8, a Astra en 54,7 y a Claude Opus 5 en 54,1.

Tres fuentes, un índice, tres ordenaciones. No pueden estar todas al día. Como causas plausibles cabe pensar en fechas de corte distintas, ajustes de esfuerzo distintos y la mezcla de puntos con porcentajes. La consecuencia práctica es sencilla: un valor del Intelligence Index sin mención del sitio, la fecha y el nivel de esfuerzo no es información. Artificial Analysis, por lo demás, señala resultados dispares, entre ellos una caída de unos 80 puntos Elo en GDPval-AA v2.

Queda la arena. Tampoco allí hay nada que obtener: ni Claude Fable 5.1 ni GPT-6 Astra tienen una posición clasificada en LMArena en las instantáneas de septiembre de 2026 accesibles aquí, porque el Elo de arena necesita volumen de votos y va semanas por detrás de los lanzamientos de frontera. Aun si existieran esos valores, serían el instrumento equivocado para esta decisión. La preferencia humana por comparación ciega mide la calidad percibida de las respuestas sobre indicaciones elegidas por quien vota, reacciona con fuerza al formato y a la extensión y dice poco del trabajo agéntico a lo largo de plazos amplios. Para un agente de programación o una plataforma de trabajo del conocimiento, no es la vara de medir con la que alinear una compra.

FrontierCode 1.1: la cifra que juega en contra de quien la publica

Hay en esta comparación una fila que pesa más que las demás, por un motivo metodológico. En FrontierCode 1.1, GPT-6 Astra queda según los resultados comunicados por la propia OpenAI en 53,3 %, es decir, por detrás de Claude Fable 5 con 53,5 %.

Dos precisiones son aquí obligadas. El valor de comparación corresponde a Claude Fable 5, no a Fable 5.1, y Anthropic no ha publicado ninguna cifra propia para Fable 5.1 en este benchmark. La distancia es de 0,2 puntos porcentuales y queda, por tanto, dentro de cualquier dispersión de medición plausible.

Aun así, es el tipo de cifra más digno de confianza que puede contener un anuncio de producto. Un proveedor que publica una fila en la que su nuevo buque insignia queda por detrás de un modelo ajeno no tiene ningún incentivo comercial para hacerlo. Quien quiera valorar cuánto sostiene una tabla de benchmarks debería mirar primero si en ella aparecen filas así. Una tabla en la que el proveedor que la publica gana todas y cada una de las filas no es una medición, es una selección.

El sentido se invierte: residencia de datos en la UE y retención cero

Hasta aquí Anthropic va por delante en precio y economía de caché y está aproximadamente a la par en los benchmarks. En gobernanza de datos la imagen se invierte por completo, y para una empresa alemana esa es la columna que cambia una arquitectura.

Del lado de Anthropic, esto figura en su propia documentación. El parámetro inference_geo acepta exactamente dos valores, global y us, y como región de almacenamiento de un espacio de trabajo solo puede elegirse us, fijada en el momento de crearlo. El lado de la retención es aún más explícito: Anthropic designa a Fable 5.1 y Mythos 5.1 (así como a Fable 5 y Mythos 5) como Covered Models que exigen una retención de datos de 30 días y no están disponibles bajo retención cero salvo autorización expresa de Anthropic. Una organización con ZDR debe activar la retención de 30 días para un espacio de trabajo concreto, o la petición se rechaza.

Del lado de OpenAI, la documentación para desarrolladores sobre el tratamiento de datos indica que Europa (EEE y Suiza) admite tanto almacenamiento regional como procesamiento regional a través de eu.api.openai.com, configurado por proyecto, y que las regiones fuera de Estados Unidos requieren aprobación para los controles de supervisión de abusos y una adenda de retención modificada. La misma página enumera los puntos finales aptos para ZDR, entre ellos /v1/chat/completions y /v1/responses, y excluye expresamente Assistants, Threads, Vector Stores, el ajuste fino y Batches.

Aquí la precisión importa más que una formulación redonda: ninguna fuente encontrada afirma positivamente que GPT-6 Astra sea apto para ZDR. Lo documentado es que esos puntos finales admiten ZDR y que para gpt-6-astra no se publica ninguna exclusión específica de modelo. Pero la ausencia de una restricción no es un permiso. Quien base en ello una arquitectura debería hacer que se lo confirmen contractualmente en lugar de deducirlo de un vacío documental. En Anthropic la situación es inequívoca en sentido contrario, porque la exclusión está escrita.

También conviene corregir una frase muy repetida: «Claude tiene residencia de datos en la UE porque se ejecuta en AWS Fráncfort». Eso es cierto precisamente cuando se obtiene Claude a través de una nube asociada como Amazon Bedrock o Google Cloud, donde el proveedor de nube fija la región y actúa como encargado del tratamiento. No vale para la API propia de Anthropic. Para un enrutamiento regional garantizado, Anthropic remite él mismo a los puntos finales regionales de las nubes asociadas, con un recargo del 10 % frente a los puntos finales globales. Para una revisión del RGPD esa distinción es el punto central, porque determina con quién se firma el contrato de encargo de tratamiento.

Artículo 50: una diferencia que solo puede probarse a medias

Desde el 2 de agosto de 2026 se aplican las obligaciones de transparencia del artículo 50 del Reglamento de IA, que exigen un marcado legible por máquina de los contenidos sintéticos. Anthropic señala que Fable 5.1 y Mythos 5.1 llevan desde el primer día una marca de agua invisible en el texto, y aplica ese marcado en todo el mundo y no solo en la UE. Hasta donde alcanzan las fuentes disponibles, es una diferencia real.

Esa frase necesita, sin embargo, sus dos mitades. No se ha encontrado ninguna fuente que indique si la salida de texto de GPT-6 Astra está marcada. El enfoque de procedencia documentado de OpenAI, los Content Credentials de C2PA junto con SynthID, se refiere a imagen y audio; las páginas accesibles no dicen nada sobre el texto. De ese vacío no se sigue que OpenAI no marque el texto. Por eso no lo afirmamos. OpenAI publica por separado orientaciones para clientes sobre el Reglamento de IA.

Y la marca de agua de Anthropic sostiene menos de lo que el término sugiere. Anthropic escribe en su propia ayuda que una marca detectada indica que un contenido puede haber sido procesado por Claude, que no es plenamente concluyente y que por sí sola no confirma la procedencia del contenido. La API de detección correspondiente se encuentra además en vista previa privada para organizaciones seleccionadas. Como pieza de una argumentación de cumplimiento, la marca de agua es utilizable; como medio de prueba, no.

Qué significa esto para una decisión en Alemania

Si de esta comparación se lleva usted una sola regla, que sea esta: con dos modelos de frontera próximos en las cifras defendibles y con precios de lista idénticos, rara vez decide una fila de benchmark. La distancia en Terminal-Bench 4.0 es de 1,9 puntos porcentuales sin harness declarado. En FrontierCode 1.1 son 0,2 puntos en sentido contrario, frente a un modelo Claude anterior. Distancias así se desplazan con el siguiente lanzamiento y no cambian ninguna arquitectura.

Lo que sí cambia una arquitectura está en la columna de gobernanza. Una organización obligada a la retención cero no puede emplear Claude Fable 5.1 a través de la API propia de Anthropic sin autorización expresa, por bueno que sea el modelo. Una organización que exija inferencia dentro de la UE encuentra esa vía en Anthropic solo a través de una nube asociada, con el recargo correspondiente y otro encargado del tratamiento en el contrato. A la inversa, la ventaja de Anthropic en la lectura de caché es real y crece con la proporción de trabajo agéntico en el que el mismo contexto se lee cientos de veces.

En la práctica: aclare primero las obligaciones, después los costes y al final los benchmarks. En el orden inverso construirá un sistema que mide bien y fracasa en la conversación sobre protección de datos. Y de cada cifra que le muestren, compruebe tres cosas: quién la comunicó, cuándo y con qué nivel de esfuerzo.

Lo que el lanzamiento en sí cambió para una empresa alemana lo tratamos en nuestro artículo sobre Claude Fable 5.1. Cómo se comporta el modelo en el trabajo de proyecto en curso lo tratamos en capacidades en la práctica. Y si la respuesta a la pregunta de gobernanza es que los datos no pueden salir de casa, el camino pasa por la ponderación entre on-premise y nube, no por una clasificación.

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

Warum der Fehler nicht auffällt

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

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

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

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

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

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

Prüfen statt hinsehen

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

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

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

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

Warum das teurer ist als es klingt

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

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

Was wir uns angewöhnt haben

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

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

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

Was ein Geometrie-Server tatsächlich ist

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

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

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

Warum die zweite Nachbildung das eigentliche Problem ist

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

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

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

Der Zuschnitt, der in der Praxis funktioniert

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

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

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

Woran es tatsächlich klemmt

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

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

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

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

Wo die Daten bleiben

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

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

Wann sich der Schritt lohnt

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

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

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

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

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

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

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

Eine Faustregel, die trägt

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

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

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

Wo die Rechnung kippt, und das wird selten gesagt

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

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

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

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

Was die Rechnung deutlich verbessert

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

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

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

Wie wir das vor einem Angebot klären

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

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

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

Die Inferenz ist selten das Problem

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

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

Der Index ist die eigentliche laufende Position

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

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

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

Evaluation ist eine Kostenstelle, keine Phase

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

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

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

Lokal oder gehostet ist eine Tauschentscheidung, keine Sparentscheidung

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

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

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

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

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

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

LO QUE LA BÚSQUEDA VISUAL DELIBERADAMENTE NO ENTREGA

Los modelos de retrieval visual encuentran la página correcta, incluso en un escaneo difícil. Pero le devuelven una imagen, no texto. No puede copiar sin más una línea de ahí, ni tender una búsqueda de texto completo sobre el archivo, ni construir un rastro de auditoría legible por máquina. Para todo eso necesita texto reconocido. Esto no es una debilidad del nuevo enfoque, sino una división del trabajo deliberada: búsqueda sobre la imagen, obtención de texto por OCR, cada etapa para lo que mejor sabe hacer.

LO QUE PADDLEOCR-VL SABE HACER

Baidu ha presentado con PaddleOCR-VL un modelo OCR abierto que alcanza valores de primer nivel con apenas 0,9 mil millones de parámetros (proyecto). Reconoce texto, tablas, fórmulas y diagramas en 109 idiomas y reconstruye la estructura semántica de un documento. En el benchmark OmniDocBench v1.5 encabeza con alrededor de un 94,5% de precisión. Está bajo la licencia Apache-2.0, por lo que es de uso comercial libre y operable localmente. Para una pyme eso significa: reconocimiento de texto potente sin tarifa recurrente y sin fuga de datos.

EL MONTAJE HÍBRIDO

En la práctica, ambas vías corren en paralelo. La búsqueda visual encuentra las páginas relevantes de forma rápida y fiel al layout. Donde de ahí debe salir texto duro, por ejemplo para una posición de factura, una cláusula contractual que citar o una entrada en el ERP, el OCR se hace cargo justamente de esas pocas páginas. No hay que pasar todo el archivo por OCR, solo lo que la búsqueda ya ha marcado como importante. Eso mantiene el pipeline esbelto y evita que los errores de OCR se filtren en la búsqueda desde el principio.

LA LÍNEA PRAGMÁTICA

El o esto o lo otro es aquí la postura equivocada. La búsqueda visual mejora el encontrar, el OCR mejora el procesar después. Quien entiende ambos como herramientas con tareas claras construye la base de conocimiento más sólida que quien apuesta dogmáticamente por un solo bando. Cómo encajan las piezas, desde el encoder hasta la base de datos vectorial, está en el resumen del stack.

Para una empresa mediana que procesa a diario contratos, manuales técnicos y facturas de varias páginas, esa es la noticia más interesante. No que el reconocimiento de texto sea un par de puntos mejor, sino: un documento de 80 páginas ya no tiene que ser cortado en trozos y recompuesto, y para ello ningún documento tiene que salir de casa.

LO QUE HACE DISTINTO UNLIMITED-OCR

El núcleo es una atención modificada en el decoder que mantiene la memoria constante. Los modelos OCR clásicos basados en transformer dejan crecer la llamada KV-cache con la longitud del documento. Cuanto más largo el PDF, más memoria, hasta que en algún momento ya no cabe en un solo procesamiento.

Unlimited-OCR reemplaza esa parte por Reference Sliding Window Attention (R-SWA). La KV-cache permanece así constante, independientemente de la longitud del documento. Justamente eso significa el término one-shot long-horizon parsing: un documento largo se lee en una sola pasada, en lugar de descomponerlo en secciones y unir los resultados después.

Notable es la vía de entrenamiento. El equipo no empezó desde cero, sino que entrenó adicionalmente el checkpoint de DeepSeek-OCR: congeló el encoder y solo ajustó el decoder a lo largo de unos 4.000 pasos. Con ello el modelo está en línea directa con DeepSeek-OCR, que ya hemos situado en el contexto del stack. Código y pesos están abiertos en GitHub.

POR QUÉ CUENTA LA KV-CACHE CONSTANTE

El verdadero problema con los documentos largos no es la página individual, sino la coherencia a lo largo de las páginas. Cuando un modelo corta un documento de 60 páginas en bloques de diez páginas, se pierde justamente lo que cuenta en el día a día B2B: una tabla que cruza el salto de página, una cláusula que se refiere a una sección anterior, una posición cuya referencia está veinte páginas antes.

Una KV-cache constante permite mantener todo el documento en un solo contexto. La memoria no crece con la longitud, así que la estructura se conserva a lo largo de todas las páginas. De paso se vuelve más rápido: Baidu menciona en el modo base 5.580 tokens por segundo frente a 4.951 de DeepSeek-OCR, y con un límite de salida de 6.000 tokens la diferencia ronda el 35 por ciento.

En precisión, Unlimited-OCR se sitúa en OmniDocBench v1.5 en 93,23 puntos, 6,22 por encima de la base de DeepSeek-OCR, y en v1.6 en 93,92. Esas son las cifras del paper. En sus propios documentos, al final cuenta cómo el modelo maneja sus tablas, sellos y formularios, no el promedio de un conjunto de pruebas público. Emparentado está el desarrollo de los LLM subcuadráticos, que abaratan el contexto largo on-prem.

DÓNDE CAMBIA ALGO ESTO EN LA PYME

El beneficio surge allí donde documentos largos y estructurados deben convertirse en datos limpios y buscables. Unos cuantos puntos concretos:

• Contratos y acuerdos marco. Las referencias cruzadas y los anexos permanecen legibles en su contexto, en lugar de desmoronarse en los límites de bloque.
• Manuales técnicos y normas. Documentos largos con figuras, tablas y secciones numeradas en una sola pasada.
• Facturas y comprobantes de varias páginas. El texto extraído con limpieza es el paso previo para el procesamiento estructurado posterior, por ejemplo hacia la factura electrónica.
• Archivos y expedientes. Fondos que hasta ahora solo existían como escaneo se vuelven legibles por máquina, sin entregarlos a un servicio en la nube.

En casi todos los casos el OCR no es la meta, sino el primer paso. El texto parseado con limpieza es la base para una base de conocimiento con RAG: cuanto mejor el parsing, mejor encontrará la búsqueda después el pasaje correcto.

¿OCR O BÚSQUEDA VISUAL DE DOCUMENTOS?

No toda tarea documental necesita reconocimiento de texto clásico, y esa es una ponderación honesta. Existe ya toda una rama que ni siquiera convierte los documentos en texto, sino que los busca como imagen, con modelos como ColPali o ColQwen. Este enfoque libre de OCR lo hemos descrito por separado.

La regla práctica que a nosotros nos ha funcionado:

• Necesita los caracteres reales (importes de factura, cláusulas contractuales, extracción estructurada, traspaso a otro sistema): entonces difícilmente hay salida sin OCR, y un modelo como Unlimited-OCR es potente aquí.
• Necesita el pasaje adecuado, no el texto completo (responder una pregunta sobre un gran fondo, reencontrar una figura): entonces la búsqueda visual de documentos puede ser el camino más directo.

A menudo es ambas cosas a la vez. Unlimited-OCR abarata la parte de OCR de ese stack y la hace más fiable en documentos largos.

LO QUE COMPROBARÍA ANTES DE PONERLO EN PRODUCCIÓN

Un buen valor de benchmark es motivo para probar el modelo, no para ponerlo en producción. Antes de poner Unlimited-OCR en un proceso de cliente, comprobaría cuatro cosas:

🔸 Documentos en alemán y escritura a mano. Las cifras de benchmark dicen poco sobre formularios alemanes, expedientes antiguos o anotaciones manuscritas. Eso pertenece a un conjunto de pruebas propio de documentos reales.

🔸 Tablas y layout. En documentos B2B, la fidelidad de tablas y columnas decide la utilidad. Aquí vale la pena la comparación directa con el stack actual.

🔸 Hardware y operación. 3B como MoE con unos 500M de parámetros activos es realista on-prem. Lo que eso significa en concreto en memoria de GPU y rendimiento hay que medirlo antes del despliegue, no estimarlo.

🔸 Licencia y procedencia. MIT permite el uso comercial, on-prem, sin notas al pie. Que el rastro del modelo lleve a uno de los autores de DeepSeek-OCR es una señal de calidad, pero no reemplaza la propia verificación.

Lo realmente interesante de esta publicación es para mí menos el modelo en sí que la dirección: documentos largos en una sola pasada, suficientemente pequeños para el propio centro de datos, bajo una licencia que no restringe a nadie. Justamente ahí el procesamiento de documentos en la pyme se vuelve práctico. ¿Cuáles de sus documentos haría pasar primero?

MÁS ALLÁ DEL PROMPT

La ingeniería de prompts afina la pregunta. La ingeniería de contexto diseña el entorno en el que decide el modelo. Para una tarea puntual, un buen prompt basta. Para un agente que corre a lo largo de muchos pasos, lee herramientas y arrastra memoria, el prompt es una parte pequeña de lo que el modelo ve. El resto, lo que recuperas, lo que recuerdas, qué herramientas expones y cómo, es contexto, y decide mucho más del resultado. Por eso extender un harness de agente es en su mayor parte trabajo de contexto.

LOS CUATRO FALLOS CONTRA LOS QUE DISEÑAR

La mayoría de los fallos de agente se remontan a uno de cuatro problemas de contexto:

• Sobrecarga de contexto. Demasiado en la ventana. El modelo pierde el hilo, y el coste y la latencia suben. Más contexto no es mejor contexto.
• Envenenamiento de contexto. Un hecho erróneo o desactualizado entra en la ventana y el modelo lo trata como verdad. Un solo fragmento recuperado malo puede descarrilar una respuesta.
• Gestión de tokens. La ventana es finita. Sin un plan de qué conservar y qué descartar, el detalle importante queda expulsado por el ruido.
• Memoria obsoleta. Los agentes de larga duración acumulan contexto que ya no aplica, y actúan sobre él.

Nombrar el fallo es la mitad de la solución. Cada uno tiene un contramovimiento concreto.

PRÁCTICAS QUE AGUANTAN

Unos pocos patrones se repiten en montajes que se mantienen fiables:

1. Recupera, no viertas. Trae los pocos pasajes relevantes con buen retrieval en lugar de pegar todo. Ese es todo el sentido de RAG, y es la ingeniería de contexto aplicada a los datos.
2. Poda sobre la marcha. Aplica edición basada en reglas dentro del andamiaje para mantener la ventana esbelta: descarta lo que un paso ya no necesita.
3. Resume el historial largo. Reemplaza una transcripción larga por un resumen fiel antes de que desplace la tarea.
4. Empieza simple, escala según necesidad. Añade memoria y herramientas solo cuando un fallo real las exija, no por defecto.

El instinto de añadir más es la trampa. La disciplina es la sustracción.

POR QUÉ ESTA ES LA INGENIERÍA DE VERDAD

Un modelo más grande rara vez arregla un problema de contexto; solo falla de forma más cara. El trabajo que lleva a un agente de demo a fiable es casi por completo trabajo de contexto: qué ve, cuándo, y qué se le hace olvidar. Para entradas muy largas la arquitectura del modelo también importa, y ahí entran los enfoques subcuadráticos, pero para la mayoría de los equipos la ganancia está en el contexto, no en los parámetros.

EL MECANISMO, CON CLARIDAD

El RAG simple incrusta tu consulta, encuentra los pasajes más cercanos y responde a partir de ellos. RAG-Fusion añade dos pasos por delante. Primero, un modelo escribe un puñado de consultas alternativas que significan lo mismo desde ángulos distintos. Segundo, recupera para todas ellas y fusiona las listas clasificadas con fusión de rango recíproco, que premia los pasajes que se clasifican bien en varias consultas en lugar de en una sola. La respuesta se escribe luego a partir de ese conjunto fusionado y reordenado.

POR QUÉ IMPORTA EL PASO DE FUSIÓN

Una sola consulta es una sola conjetura sobre cómo está formulada la respuesta en tus documentos. Los archivos reales usan sinónimos, abreviaturas y redacciones distintas para lo mismo. Al preguntar de varias formas y premiar lo que se clasifica alto de forma consistente, RAG-Fusion saca a la luz el pasaje que una sola formulación habría perdido. La fusión de rango recíproco es el caballo de batalla silencioso aquí: combina listas sin necesitar puntuaciones comparables, que es también por lo que aparece en montajes híbridos y de interacción tardía como los que hay detrás de Qdrant y ColQwen.

CUÁNDO AYUDA Y CUÁNDO PERJUDICA

RAG-Fusion se gana su coste en preguntas ambiguas o cargadas de terminología, donde una sola formulación es una apuesta débil. Cuesta más: varias recuperaciones y un paso de generación por pregunta, así que no es latencia gratis. Y tiene un modo de fallo real. Si las variantes de consulta generadas se alejan de lo que en realidad querías decir, arrastran pasajes fuera de tema y la respuesta divaga. La solución es mantener las consultas generadas estrechamente ligadas a la intención original, y medir, no suponer, que el recall mejoró.

DÓNDE SE SITÚA ENTRE LAS OPCIONES

RAG-Fusion es una de varias formas de mejorar el retrieval, no un reemplazo de un buen retrieval. Antes de recurrir a ella, asegúrate de que lo básico se sostiene: chunks limpios, un modelo de embeddings sólido y un almacén vectorial adecuado a la tarea. Para documentos visualmente densos, la palanca mayor suele ser el retrieval visual en lugar de más variantes de consulta. Usa F-RAG donde la pregunta sea genuinamente ambigua y la ganancia de recall valga las llamadas adicionales.

EL PROBLEMA NUNCA FUE ANIMAR, SINO EL HANDOFF

Hasta ahora el movimiento de UI surgía fuera de Figma. La diseñadora lo construía en una segunda herramienta, exportaba un vídeo o una descripción, y el desarrollo tenía que reconstruir las curvas y los tiempos, a menudo a ojo. En ese proceso se pierde precisión: una curva de easing se vuelve una idea aproximada, un timing una estimación. Justamente esa ruptura, no la falta de herramientas de animación, ha hecho inconsistente el movimiento en muchos productos.

QUÉ APORTA FIGMA MOTION EN CONCRETO

Tres cosas cambian el flujo de trabajo de forma perceptible:

• Timeline en el canvas. Keyframes, presets y control de movimiento residen donde el diseño ya vive. Sin cambiar a una segunda herramienta.
• Movimiento como parte del sistema de diseño. Un componente se anima una vez, y el movimiento viaja como el color o la tipografía por cada pantalla y cada archivo. Ese es el punto que impone la consistencia en lugar de esperarla.
• Handoff legible. En el Dev Mode todo el timeline es visible: cada valor de timing, cada curva de easing, cada keyframe. La exportación va como CSS, JSON o React listo para el framework, además de MP4, WebM, SVG animado y GIF.

Con ello el desarrollo lee el movimiento en lugar de interpretarlo. Ese es el verdadero desplazamiento.

DÓNDE ESTÁ EL PERO

Una herramienta integrada no es automáticamente la correcta para cada caso. El trabajo de motion complejo y narrativo, por ejemplo una pieza de marca elaborada, sigue siendo cosa de herramientas especializadas. Figma Motion apunta a la animación de interfaz: estados, transiciones, microinteracciones, es decir justamente lo que se necesita a diario en el producto y hasta ahora sufría en la ruptura del handoff. Para esa clase de movimiento, la integración es la ganancia. Para todo lo que va más allá, la caja de herramientas sigue siendo mixta.

PARA QUIÉN VALE LA PENA MIRARLO

Quien mantiene un producto con patrones de UI recurrentes es quien más se beneficia: el movimiento definido una vez permanece consistente, y la implementación recibe valores exactos en lugar de aproximaciones. El movimiento no es aquí decoración, sino parte de la comprensibilidad de una interfaz, un punto que desarrollamos con más detalle en el papel clave del UX en el desarrollo de software. Figma Motion hace por fin editable esa parte en un solo lugar.

QUÉ ES GEMINI OMNI EN REALIDAD

Acierta el nombre primero, porque el marketing lo difumina. La familia es Gemini Omni y el primer modelo es Gemini Omni Flash. Acepta texto, imagen, audio y vídeo como entrada, y en el lanzamiento produce una sola salida: vídeo, en clips de unos 10 segundos con audio sincronizado de forma nativa. Google lo describe como un paso hacia un modelo del mundo, es decir, intenta mantener la física, la gravedad y la coherencia espacial consistentes a lo largo de una escena generada, y corre en las TPU de 8.ª generación de Google divididas en variantes de entrenamiento e inferencia.

Una corrección honesta importa para un lector técnico: Omni se comercializa como cualquier-a-cualquier, pero tal como se entregó es cualquier-entrada-a-vídeo. Las salidas de imagen y audio están en la hoja de ruta, no en el producto. Así que no es un asistente omni conversacional en tiempo real, y aún no es el sistema universal cualquier-a-cualquier que el nombre sugiere. Es un generador de vídeo muy capaz y flexible en la entrada, que es algo más estrecho y más útil sobre lo que planificar.

ANUNCIADO, ENTREGADO Y DISPONIBLE SON TRES COSAS DISTINTAS

La distinción más útil para un comprador es que estos tres estados no son lo mismo, y Omni se sitúa en distintos según quién seas. Está entregado a consumidores y creadores, y meramente anunciado para todos los que construyen sobre una API.

La lectura práctica para una empresa de la UE es directa. Si necesitas residencia en la UE de grado RGPD para generación de vídeo hoy, Omni no puede dártela, porque su vía empresarial aún no existe. La opción soportada en el propio stack de Google sigue siendo Veo 3.1 en Vertex AI, que puedes fijar a una región de la UE. Este es el mismo patrón que seguimos viendo con los lanzamientos de modelos nuevos, donde la demo y el producto desplegable están a meses de distancia.

QUÉ DEBERÍA HACER AHORA UNA EMPRESA ALEMANA

Trata a Omni como una señal a seguir, no como una herramienta a adoptar este trimestre. Tres movimientos concretos.

• Usa Veo 3.1 fijado a región para vídeo de producción hoy. Tiene una API real de Vertex, regiones de la UE y un SLA. Omni no tiene nada de esto todavía, así que no pertenece a un pipeline de producción ahora.
• Planifica pronto la historia de procedencia. Omni incrusta una marca de agua SynthID en cada clip. Para contenido regulado o de cara al público, incorpora a tu proceso la expectativa de que el vídeo generado por IA se etiquete y se pueda rastrear, sin importar qué modelo gane.
• Vigila dos riesgos, no solo la capacidad. Los revisores han reproducido personajes registrados reconocibles en la salida de Omni, lo que es una exposición de propiedad intelectual real para uso comercial, y la consistencia visual aún se desvía en el movimiento rápido. El tope de 10 segundos es un límite de UX, no un techo del modelo, así que espera que se mueva.

El punto duradero es el que el lanzamiento hace por accidente: un modelo que puedes ver en una keynote no es un modelo que puedas desplegar bajo contrato. Separa los dos, y el bombo se convierte en un punto de la hoja de ruta en lugar de un error de compras.

TRES LANZAMIENTOS, EN TÉRMINOS LLANOS

Cada uno de estos salió en una quincena respecto a los otros en junio de 2026, y cada uno es un tipo de cosa distinta. Vale la pena ser preciso, porque dos de ellos se describen mal por todas partes.

GLM-5.2, de Z.ai en Pekín, se publicó el 17 de junio. Es un modelo Mixture-of-Experts de pesos abiertos, unos 750 mil millones de parámetros con cerca de 40 mil millones activos, un contexto de un millón de tokens y, crucialmente, una licencia MIT con los pesos publicados en HuggingFace.

Sakana Fugu, de Sakana AI en Tokio, se publicó el 22 de junio. No es un modelo convencional, y el encuadre común lo entiende mal: Fugu es un orquestador entrenado que llama a un grupo de otros modelos y sintetiza su trabajo. Es solo API, ofrecido como un endpoint compatible con OpenAI.

Claude Fable 5, de Anthropic en Estados Unidos, se publicó el 9 de junio. El segundo error común es archivar a Fable como un nivel rápido o creativo. Es el buque insignia, el modelo más capaz de Anthropic de amplia difusión, con puerta de seguridad, solo en la nube, a 10 y 50 dólares por millón de tokens. Sus cifras de benchmark son fuertes; para este artículo también son irrelevantes.

LA ÚNICA COMPARACIÓN QUE SOBREVIVE A COMPRAS

Quita el ranking y alinéalos en las dimensiones de las que un comprador B2B alemán es realmente responsable. La imagen es clara, y no va sobre cuál es el más inteligente.

Dos salvedades honestas pertenecen a esta tabla. La vía por defecto de GLM-5.2, la API de Z.ai, se sitúa bajo las leyes de datos de China, con sus disposiciones de acceso obligatorio, que es justo por lo que importan los pesos abiertos: autoalojar en la UE neutraliza ese riesgo. Y la afirmación de Fugu de paridad frontera es totalmente autoinformada, debilitada por el hecho de que Fable y el restringido modelo Mythos ni siquiera están en su grupo. Yo no apostaría una decisión al benchmark de ninguno de los dos proveedores.

LO QUE REALMENTE LE DIGO A UN CLIENTE

No recomiendo uno de estos en abstracto. Ajusto la postura a lo que el cliente puede financiar y a lo que es responsable.

🔸 GLM-5.2 es la jugada on-prem. Los pesos abiertos MIT son todo el punto: puedes correrlo en tu propio centro de datos, y los prompts nunca salen de tu red. El pero es la huella de GPU, unos 744 gigabytes en FP8, así que encaja con el cliente que puede financiar el hardware y necesita que los datos se queden en el edificio. Es la historia de soberanía más limpia de los tres.

🔸 Claude Fable 5 es la jugada de garantía gestionada. Estás alquilando capacidad a un proveedor de EE. UU., al precio más alto de aquí, con puerta de seguridad real y enrutamiento regional de datos en las grandes nubes. Para un equipo que quiere un modelo puntero sin poseer el stack, y puede vivir con una dependencia de nube, es la opción gestionada más fuerte.

🔸 Sakana Fugu es la jugada de conveniencia, con la historia de control más débil. Una API que enruta a través de un grupo de modelos es ingeniosa, y Japón es una geopolítica más blanda que China. Pero no puedes correrlo on-prem, no eliges qué modelo ve los datos, y la evidencia es escasa. Yo lo trataría como interesante, no como un valor por defecto para trabajo regulado.

Esta es la misma lección que Claude Fable 5 enseñó por las malas cuando un modelo anterior se apagó en 72 horas: la capacidad alquilada es revocable, y el control es una propiedad del stack, no de la puntuación. Es por lo que sigo señalando a los clientes hacia modelos de pesos abiertos que de verdad pueden poseer.

LA PREGUNTA POR LA QUE VALE LA PENA DISEÑAR

Si te llevas una cosa de esto, que sea la pregunta, no el ranking. Los modelos volverán a intercambiar posiciones en el ranking dentro de un trimestre; esa parte es ruido. La pregunta duradera es la que un responsable de compras debería estar haciéndose el primer día: ¿cuál de estos puedes seguir corriendo, auditando y costeando cuando el proveedor cambie las condiciones? Para la mayoría de los clientes regulados con los que trabajo, esa pregunta se responde sola, y no apunta al benchmark más alto. Así que antes de elegir el modelo más inteligente, ¿qué te costaría perderlo?

QUÉ SE ENTREGÓ REALMENTE EN 2025 Y 2026

El titular es estabilidad tras años de agitación. LangChain 1.0 y LangGraph 1.0 alcanzaron ambos la versión estable el 22 de octubre de 2025, con el compromiso de no introducir cambios rompedores hasta la 2.0. La nueva abstracción estrella del framework, create_agent, corre ahora sobre el runtime de LangGraph por debajo, así que el bucle de agente es un grafo de LangGraph. Esa es la señal más clara de la fusión: el framework y el runtime de orquestación ya no son elecciones separadas.

LangGraph 1.0 trajo la ejecución duradera integrada: el estado se registra en checkpoints de forma automática, así que un flujo de larga duración o con humano en el bucle se reanuda tras una interrupción o un reinicio de servidor. LangSmith, la capa de observabilidad y evaluación, añadió soporte completo de OpenTelemetry en marzo de 2026, lo que significa que puedes enviarle trazas desde código que no use LangChain en absoluto. La imagen comercial acompañó a la técnica: LangChain Inc levantó una Serie B de 125 millones de dólares a una valoración de 1.250 millones en octubre de 2025, y renombró LangGraph Platform a LangSmith Deployment, plegando despliegue, observabilidad y evaluación en un solo producto.

CUATRO NOMBRES, DOS EMPRESAS

Aclarar quién hace qué es lo más útil antes de elegir. La mayoría de los artículos lo difuminan; acertarlo cambia la decisión.

LangFlow es el que hace tropezar a la gente. No es un producto de LangChain Inc. Es un constructor visual de código abierto creado por DataStax, cuya matriz fue adquirida por IBM en febrero de 2025, y ahora apunta hacia watsonx de IBM. La rima del nombre es una coincidencia. Si tu requisito es un lienzo de arrastrar y soltar para gente que no escribe Python, LangFlow es el candidato; no es una capa del stack de LangChain.

LA DECISIÓN QUE LA MAYORÍA DE LOS EQUIPOS REALMENTE ENFRENTA

Una vez claros los nombres, la elección suele ser un árbol de decisión corto, y rara vez necesitas los cuatro.

• ¿Necesitas orquestación duradera? LangGraph es la pieza más fuerte, y la que hasta los críticos tienden a respetar. Estado reanudable, checkpointing y humano en el bucle son ingeniería de verdad, no envoltorios.
• ¿Necesitas observabilidad y evaluación? LangSmith es capaz, pero te acopla al ecosistema. Langfuse es la contrapresión de código abierto y autoalojable, y la salida de emergencia más citada. Ahora que LangSmith habla OpenTelemetry, puedes trazar desde código que no use LangChain, lo que suaviza el lock-in.
• ¿Construyes un agente sencillo? Los SDK de proveedores (el OpenAI Agents SDK, el Claude Agent SDK) y Pydantic AI son alternativas creíbles y más ligeras. La queja dominante de los profesionales son las capas de abstracción del framework, y varios equipos reportan recortar código y mantenimiento al pasar a un stack más delgado.
• ¿No ingenieros prototipando? LangFlow, con la salvedad de que un prototipo en lienzo aún necesita la misma gobernanza y evaluación antes de entrar en producción.

Esta es la misma lección que sacamos al comparar cómo cablear la IA en un stack a través de una API, un servidor MCP o un CLI: las herramientas son capas, y eliges por la tarea, no por la novedad. También rima con lo que encontramos al mirar constructores de agentes no-code para la pyme, donde el lienzo te consigue una demo rápido y se detiene justo en la gobernanza, la fiabilidad y el coste.

ESTABLE NO SIGNIFICÓ ENDURECIDO

Una salvedad importa para un público de negocio: 1.0 compró estabilidad de API, no una postura de seguridad endurecida. Un grupo de CVE aterrizó contra LangChain y LangGraph a finales de 2025 y comienzos de 2026, encabezado por un fallo de deserialización que podía filtrar claves de API y secretos de entorno, calificado CVSS 9.3 y apodado LangGrinch. Siguieron dos más: un problema de path-traversal en la API de carga de prompts, y una inyección SQL en el checkpointer SQLite de LangGraph.

La lectura práctica no es evitar el framework. Es tratarlo como cualquier otra dependencia que toca tus secretos y tus datos: fija versiones, aplica las releases parcheadas e inclúyelo en tu modelo de amenazas. Un framework que orquesta llamadas a herramientas y guarda credenciales es parte de tu superficie de ataque, y "estable" en el número de versión dice poco sobre eso. Para un despliegue regulado u on-prem, esa revisión pertenece a la misma conversación que la residencia de datos, no después del go-live.

EL PROBLEMA CON EL VECTOR ÚNICO

La búsqueda vectorial clásica comprime todo un pasaje de texto o toda una página en un único vector. Es económico, pero promedia y borra lo que es localmente importante. Si el importe buscado está en una celda concreta de una tabla, esa referencia desaparece en el promedio de toda la página. Para texto corrido limpio suele bastar. Para los documentos ante los que la búsqueda visual siquiera compite, no basta.

LATE INTERACTION, EN UNA FRASE

Late Interaction conserva muchos vectores por página y los compara tarde, solo al buscar. El modelo genera para la consulta un vector por token y para la página un vector por fragmento. La puntuación se llama MaxSim: para cada token de la consulta se busca el fragmento de página que mejor encaja, y esos mejores aciertos se suman. Así la palabra "saldo restante" puede acoplarse con precisión a la celda de tabla en la que está. La técnica proviene de ColBERT y se trasladó a imágenes con ColPali. Quien quiera ver toda la caja de piezas: el stack libre de OCR ordena los modelos.

DÓNDE ENTRA QDRANT EN JUEGO

Late Interaction necesita una base de datos que entienda varios vectores por objeto. Qdrant soporta tales multi-vectores directamente, sin pre ni posprocesamiento, y puede sostener cualquier modelo de Late Interaction como ColBERT o ColPali (documentación). El montaje habitual es en dos etapas: una primera búsqueda rápida con vectores densos normales acota los candidatos, luego MaxSim puntúa con precisión solo esas pocas páginas. Así el índice sigue siendo asequible, porque los costosos vectores de token no tienen que indexarse por completo, sino que sirven para la reordenación.

QUÉ SIGNIFICA ESTO EN LA PRÁCTICA

Obtiene aciertos que respetan el layout, sin volver la búsqueda impagable. El precio es más memoria por página y algo más de complejidad en el montaje. Ambos son manejables si se planifica la etapa de reordenación desde el principio en lugar de indexar por completo cada vector de token. Para contextos muy largos vale la pena mirar los modelos subcuadráticos; para la idea básica de retrieval, Qué es RAG sigue siendo el punto de entrada.

POR QUÉ EL TAMAÑO SE VUELVE AQUÍ UN OBSTÁCULO

Los modelos de retrieval visual como ColPali o ColQwen son certeros, pero también son grandes. On-prem, es decir, sobre hardware propio en casa, eso se vuelve rápido una cuestión de coste: los modelos grandes exigen GPU potentes, más memoria, más electricidad. Para muchos montajes de pyme, el obstáculo no es la calidad, sino la factura del hardware. Justamente aquí aplica un modelo más pequeño la palanca.

QUÉ HACE DISTINTO MODERNVBERT

ModernVBERT es un encoder compacto de visión y lenguaje con 250M de parámetros (paper). Combina un moderno text-encoder de 150M basado en ModernBERT con un pequeño image-encoder y alinea ambos mediante un objetivo de Masked-Language-Modeling. ColModernVBERT es la variante ajustada para retrieval. El resultado según el paper: pese a unas diez veces menos parámetros, queda solo 0,6 nDCG@5 por debajo de ColPali en el benchmark agregado ViDoRe y alcanza así valores para los que antes hacían falta modelos casi diez veces más grandes. Modelo y código están disponibles de forma abierta.

POR QUÉ ESTO CUENTA PARA LA SOBERANÍA

Un modelo pequeño, abierto y potente es justamente la combinación que hace posible la operación local. Cabe en una GPU modesta, los pesos están abiertos, y los documentos permanecen en casa, porque la búsqueda no va a un endpoint ajeno. Eso no es una función de seguridad añadida a posteriori, sino una propiedad de la arquitectura. El contexto mayor, por qué local y abierto van juntos, lo tratamos en On-Premise contra Cloud.

CUÁNDO EL MODELO PEQUEÑO ES LA ELECCIÓN CORRECTA

No siempre hace falta el modelo más grande. Si su hardware es limitado y sus documentos son documentos de negocio típicos, ColModernVBERT es a menudo la elección más honesta que ColQwen: casi la misma calidad, una fracción del coste. Si necesita el último ápice de precisión en páginas especialmente densas, vale la pena la comparación con el modelo más grande. Cómo interactúan ambos en el stack completo con Qdrant está en el resumen.

Qué hace fuerte a n8n

n8n es automatización de flujos basada en nodos, autoalojada o en la nube, con más de 400 integraciones más un nodo HTTP y nodos de código para todo lo demás (n8n). El punto decisivo para sectores regulados: corre en casa, los datos no salen de la infraestructura. La licencia Fair-Code permite el uso interno sin tarifa. Quien necesita lógica propia, endpoints propios y control total de los datos, está aquí en lo correcto. El precio de ello es la operación: usted mismo aloja, actualiza y respalda.

Qué hace fuerte a Make.com

Make.com es un servicio en la nube con escenarios visuales que prescinde de operación propia. Se arma un flujo a clics y corre, sin servidor, sin mantenimiento. Para equipos sin profundidad técnica o para una idea rápida, ese es el camino más corto. Se factura por operación, es decir, por paso ejecutado. Eso es barato con volúmenes pequeños y puede crecer de forma incómoda con flujos grandes y frecuentes. El reverso de la comodidad: los datos corren a través de un servicio ajeno, y la lógica permanece dentro de sus límites.

La decisión en una tabla

La línea divisoria es clara: control de datos y profundidad frente a velocidad sin operación propia.

Nuestro consejo pragmático

Prototipe rápido, aloje de forma consciente. Para una primera prueba que solo deba mostrar si un flujo sostiene, Make.com suele ser más rápido. En cuanto entran en juego datos sensibles, altos volúmenes o lógica propia, gana n8n, porque corre en casa. Y donde la automatización roza tareas reales de IA, vale la pena mirar los agentes no-code y sus límites: automatización y agente no son la misma herramienta.

Por qué el OCR era la parte tambaleante del pipeline

El OCR fue durante mucho tiempo el punto por el que entraban errores silenciosos en la respuesta. El camino clásico es una cadena: escanear la página, convertirla por OCR en texto, cortarla en trozos, incrustar, recuperar. Cada etapa pierde algo. Una página de dos columnas se recompone mal, una tabla se desmorona en cifras inconexas, un diagrama cae del todo, porque no es texto. En nuestra experiencia, en documentos difíciles la mayor parte del problema de calidad no está en el modelo de lenguaje, sino aquí, en la lectura. El retrieval visual aplica justo en esa etapa: se salta el reconocimiento de texto al buscar y trabaja sobre la imagen de la página.

Las cuatro piezas, brevemente explicadas

ColPali. La referencia, presentada en julio de 2024 (arXiv). Se construye sobre el modelo de visión y lenguaje PaliGemma y genera unos 1024 vectores de fragmento de imagen por página, cada uno de 128 dimensiones. En lugar de comprimir la página en un único vector, la granularidad se conserva. El cotejo pasa por Late Interaction, una técnica tomada de ColBERT que desglosamos aquí con más detalle.

ColQwen. La misma receta, otra base: ColQwen2.5 apuesta por Qwen2.5-VL en lugar de PaliGemma y suele ir por delante en el benchmark ViDoRe. Quien empieza hoy de cero, empieza sensatamente aquí.

ModernVBERT. La palanca de eficiencia. ColModernVBERT tiene 250M de parámetros, es decir, unas diez veces menos que ColPali, y según el paper queda aun así solo 0,6 nDCG@5 por debajo. Es la pieza que hace asequible el retrieval visual on-prem.

Qdrant. La infraestructura de debajo. Qdrant almacena los multi-vectores de estos modelos de forma nativa y calcula la puntuación de Late Interaction al buscar (documentación). Sin una base de datos vectorial que entienda varios vectores por página, no corre ninguno de los tres encoders.

Cuándo vale la pena el cambio, y cuándo no

El retrieval visual gana allí donde el layout porta la información. Contratos escaneados, facturas, hojas de datos, presentaciones, formularios, expedientes multilingües: todo aquello en lo que una cadena de OCR fracasa con regularidad. Además ahorra todo el mantenimiento de esa cadena.

Pero no es una ganancia general. Varios vectores por página cuestan más memoria y más índice que un único vector de texto, a menudo varias veces más. Con texto corrido limpio y puro, el RAG de texto clásico sigue siendo más barato y del todo suficiente. Y algunas tareas necesitan al final texto de todos modos, por ejemplo búsqueda de texto completo, copiar o un rastro de auditoría. Para eso sigue habiendo buenas razones para el OCR, en el híbrido junto al retrieval visual.

Una hoja de ruta sobria

1. Probar con los propios documentos, no con el benchmark. ViDoRe es una buena referencia, pero su situación de expedientes no lo es. Tome las veinte páginas en las que su búsqueda actual fracasa.
2. Empezar con ColQwen o ColModernVBERT, según el hardware. En una GPU justa, el modelo pequeño suele ser el más honesto.
3. Montar Qdrant como almacén multi-vector, Late Interaction solo en la etapa de reordenación, para mantener el índice pequeño.
4. Calcular el precio de memoria de antemano. El tamaño del índice es el punto que después duele, no la elección del modelo.

Quien busca el arco mayor, es decir, por qué los modelos locales y el retrieval propio van juntos: eso está en On-Premise contra Cloud. Las piezas individuales las profundizamos en textos propios, empezando por la mirada de la pyme.

La brecha entre una malla y una pieza

Una malla generada y una pieza fabricable son objetos distintos, y la brecha no es cosmética. Tres restricciones lo evidencian. Primero, imprimir necesita un sólido estanco y de variedad (sin agujeros, sin normales invertidas, sin autointersecciones), y las mallas generativas violan esto de forma rutinaria; un slicer no puede hacer una pieza a partir de una superficie con huecos. Segundo, una malla es una sopa estática de triángulos, mientras que la fabricación quiere un modelo B-rep paramétrico (un archivo STEP con bocetos, features y restricciones) que un ingeniero pueda editar y un sistema CAM pueda mecanizar. Ninguna de las herramientas image-to-mesh produce eso.

Tercero, y lo más fundamental, una sola imagen no lleva escala métrica. El modelo asigna una cámara conjeturada y produce una forma sin milímetros garantizados, sin espesor de pared impuesto, sin tolerancias. Y como una foto solo ve un lado, el lado oculto no se reconstruye, se imagina: el modelo rellena la geometría no vista con un promedio plausible. Un asset de videojuego puede esconder todo esto tras una textura bonita. Una pieza no puede, porque a la impresora y a la carga no les importa cómo se ve.

Dos pipelines que el bombo difumina

La forma más clara de planificar es separar dos pipelines que el marketing junta. Sirven a piezas distintas y necesitan herramientas distintas.

El primer pipeline es real hoy para piezas donde el ajuste es indulgente. La IA bloquea la forma; una persona aún se ocupa de hacerla estanca, escalarla a dimensiones reales y correr una comprobación de imprimibilidad. El segundo es donde se sitúa la frontera relevante para la fabricación: la investigación de image-to-CAD como CAD-Recode e Img2CAD genera geometría paramétrica editable, y herramientas comerciales como Zoo pueden exportar un archivo STEP real, pero están en gran medida limitadas a piezas más sencillas por ahora. Para geometría exigente, la ingeniería inversa clásica basada en escaneo (Geomagic, PolyWorks) sigue siendo la ruta fiable. Este es el primo de fabricación de la pregunta que hicimos sobre la reconstrucción humana a partir de una sola imagen: una superficie plausible no es lo mismo que un sólido en el que se puede confiar.

Qué es real para un fabricante de pyme hoy

Frente al bombo, las victorias genuinas son más silenciosas y más valiosas que sacar una pieza de un tirón desde la foto de un móvil. La cuña real más fuerte es digitalizar lo que ya tienes: herramientas como Theia de Spare Parts 3D y el análisis de planos de 3YOURMIND convierten planos técnicos 2D antiguos en modelos de repuestos imprimibles, reportado como hasta 200 veces más rápido que redibujar a mano, con una comprobación de fabricabilidad adjunta. Eso es image-to-3D donde la entrada es un plano de ingeniería, no una instantánea de vacaciones, y la geometría está anclada en dimensiones reales.

Las otras victorias sólidas son la aceleración de la ingeniería inversa, donde la generación por IA y la retopología inteligente aceleran un flujo existente basado en escaneo en lugar de reemplazarlo, y el prototipado rápido de piezas no críticas. Donde falla es justo donde las apuestas son más altas: piezas portantes, de tolerancia estrecha y reguladas, que necesitan escala, especificación de material y trazabilidad que una sola imagen no puede proporcionar. La regla que llevarse es corta. Para una pieza que soporta peso o pasa una auditoría, el lado no visto es siempre una conjetura, y una conjetura es un defecto.

La diferencia real, en una línea cada una

La ingeniería de prompts es redactar bien una instrucción. La ingeniería de contexto es decidir qué ve el modelo en absoluto. El término fue popularizado en junio de 2025 por Tobi Lutke de Shopify y amplificado por Andrej Karpathy, que lo describió como el arte de llenar la ventana de contexto con justo la información adecuada para el siguiente paso. La distinción más limpia viene de Philipp Schmid: el contexto es todo lo que el modelo ve antes de generar una respuesta, y eso es un sistema, no una cadena.

Los dos no son rivales; la ingeniería de prompts es un subconjunto. Cuando escribes un buen prompt de sistema, eso es ingeniería de prompts. Cuando decides qué tres documentos recuperar, qué herramientas exponer, cuánto historial conservar, qué resumir y descartar, y qué esquema de salida exigir, todo bajo un presupuesto de tokens, eso es ingeniería de contexto. La propia guía de Anthropic lo encuadra como gestionar todo el estado del contexto a lo largo de los turnos, y su frase más afilada es la que vale la pena conservar: el contexto es un recurso finito con rendimientos marginales decrecientes.

Por qué el campo cambió, y no fue moda

La razón por la que la ingeniería de contexto se volvió una disciplina con nombre es que la suposición fácil se rompió bajo la medición. La suposición era que los modelos de contexto largo te dejan atiborrar la ventana y dejar de pensar. El estudio Context Rot de Chroma probó 18 modelos frontera en julio de 2025 y encontró que cada uno degrada a medida que crece la entrada, a menudo de formas no uniformes: el modelo no maneja el diezmilésimo token de forma tan fiable como el centésimo. El hallazgo más antiguo de lost-in-the-middle apuntaba en la misma dirección.

Dos fuerzas hicieron de la carga, no del prompt, la cosa a ingenierizar. Primero, los agentes, el uso de herramientas, el retrieval y la memoria significan que el contexto lo ensambla a lo largo de muchos turnos un sistema, no se escribe a mano una vez. Segundo, la economía: en producción en Manus, la proporción de tokens de entrada a salida ronda 100 a 1, y reutilizar la caché clave-valor genera una gran diferencia de coste, así que lo que pones en la ventana es una decisión de coste tanto como de calidad. Más contexto no es mejor; el contexto presupuestado y relevante lo es. Esta es la columna vertebral empírica bajo nuestro recorrido anterior por la ingeniería de contexto y por qué importa.

De qué está hecha realmente la ingeniería de contexto

Despojada de la etiqueta, la ingeniería de contexto es un conjunto de prácticas comprobables, no susurros de prompt. Las técnicas nombradas se repiten en Anthropic, LangChain y el artículo de producción de Manus:

• Retrieval. Trae los pocos documentos relevantes en el momento en que se necesitan, en lugar de pegar todo. Esta es la disciplina detrás de la generación aumentada por recuperación.
• Compactación y resumen. Comprime turnos viejos en un resumen rodante para que el presupuesto se gaste en lo que está vivo, no en la transcripción.
• Memoria y toma de notas. Descarga el estado a notas o archivos externos que el agente pueda releer, en lugar de arrastrarlo en la ventana.
• Curación de herramientas. Mantén de tres a cinco herramientas centrales cargadas y trae el resto justo a tiempo. Cargar cada herramienta diluye la señal y rompe la caché.
• Salidas estructuradas. Exige un esquema para que el modelo gaste tokens en la respuesta, no en la prosa de formato.
• Aislamiento. Reparte el trabajo entre subagentes para que cada uno vea solo el contexto que necesita.

LangChain encuadra el mismo conjunto como escribir, seleccionar, comprimir y aislar. El punto es que cada una de estas es medible: puedes hacer A/B a un recuperador, un umbral de compactación o un conjunto de herramientas, que es exactamente lo que hace de esto ingeniería en lugar de fraseo.

¿Es solo un cambio de marca? La respuesta honesta

En parte, y está bien. Sí, los buenos ingenieros ya curaban lo que el modelo ve; el valor del nombre es que apunta la optimización a la carga y al sistema, no a la frase, que es donde viven de verdad la fiabilidad y el coste. El debate vivo es más útil que la discusión terminológica. En junio de 2025, Cognition argumentó contra los sistemas multiagente, con el fundamento de que compartir contexto con limpieza entre agentes es difícil, y recomendó mantener el trabajo de un solo agente y compartir trazas completas. La misma semana, Anthropic describió un sistema de investigación multiagente que depende de un aislamiento de contexto disciplinado. Misma disciplina, conclusión arquitectónica opuesta.

Para un equipo que construye con LLM, las conclusiones son llanas. Presupuesta tokens como presupuestas cómputo, porque más no es gratis ni siempre mejor. Trata el trabajo como fontanería (calidad del retrieval, compactación, memoria, curación de herramientas, salidas estructuradas), no como fraseo. Y elige tu arquitectura según lo fiablemente que puedas compartir contexto, en lugar de por qué enfoque suena más avanzado. El nombre seguirá mutando, algunos ya llaman a la siguiente capa ingeniería de harness, pero el objeto es estable: el sistema que decide qué puede ver el modelo.

Empieza por el suelo, no por el techo

Antes de cualquier método ingenioso, acierta la base, porque arregla la mayoría de las quejas. El valor por defecto de producción de 2026 es la búsqueda híbrida (embeddings densos más BM25 por palabra clave) seguida de un reranker de cross-encoder. La búsqueda híbrida capta tanto coincidencias semánticas como de término exacto; el reranker repuntúa un gran conjunto de candidatos hasta los pocos pasajes que son de verdad relevantes, no solo temáticamente cercanos. Las guías de profesionales reportan que esta combinación eleva la calidad del retrieval del 15 al 30 por ciento en conjuntos de evaluación estándar.

Esto importa porque la mayoría de los fallos del mundo real son del tipo simple: la respuesta estaba en los documentos, pero el sistema no la sacó a la luz. Eso es un problema de recall y ranking, y el suelo de arriba lo arregla. Demuestra que necesitas más antes de construir más. Cada técnica más allá de este punto añade llamadas al LLM, latencia y coste, así que cada una debe ganarse su lugar contra un fallo medido, no una corazonada.

La caja de herramientas, indexada por el fallo que arregla

La forma útil de sostener todo el zoológico de métodos es mapear cada uno al único modo de fallo que aborda. Recurre a un método cuando veas su fallo, no antes.

Cada fila tiene procedencia real: HyDE viene de un paper de CMU de 2022 sobre retrieval denso zero-shot; el prompting de paso atrás de Google DeepMind, 2023; GraphRAG de Microsoft, 2024. Esta es la misma disciplina de decisión por fallo detrás de nuestra mirada a RAG-Fusion y en qué se diferencia del RAG simple.

Descomposición de consultas, en concreto

La descomposición de consultas divide una consulta compleja en subpreguntas independientes, recupera para cada una y luego sintetiza una respuesta. Es la herramienta correcta cuando una sola pasada de retrieval no puede funcionar, porque los hechos viven en distintos documentos o un hecho depende de otro (quién dirigió la película que ganó un premio concreto). El linaje corre del prompting de menos a más de 2022 a los motores de consulta de subpreguntas de los frameworks actuales.

La parte honesta es que no es gratis, y puede perjudicar. Un estudio de julio de 2025 de HU Berlin midió que la descomposición más reranking elevó el recall multisalto (Hits@10) del 74,7 al 87,2 por ciento, una ganancia real. El mismo estudio midió el coste: unos 16,7 segundos por consulta frente a 0,03 segundos para el retrieval ingenuo, y encontró que descomponer una consulta ya específica introduce ruido y empeora la respuesta. Así que la descomposición pertenece a preguntas genuinamente multisalto, no a cada consulta por defecto. La habilidad es distinguir las dos.

La palanca que se paga sola es el enrutamiento

Si te llevas una idea operativa de esto, que sea el enrutamiento. Clasifica la consulta primero, luego gasta complejidad solo donde se gana. Un análisis de 2026 sobre enrutamiento consciente del coste recortó los tokens facturados un 26 por ciento y la latencia media un 34 por ciento a igual calidad de respuesta, enviando solo alrededor del 18 por ciento de las consultas a retrieval pesado y el 14 por ciento a ningún retrieval en absoluto. Los métodos caros se reservaron para las consultas que los necesitaban.

Para un equipo de una pyme alemana esto es una historia de gobernanza y coste tanto como de calidad. Menos llamadas al LLM justificadas significan gasto predecible, menor latencia y un sistema que puedes explicar a una parte interesada consciente del cumplimiento: aquí está por qué esta consulta tomó el camino caro, y aquí por qué aquella no. El retrieval sobreingenierizado no solo es lento, es gasto inexplicable. El sistema RAG sofisticado en 2026 es el que sabe cuándo no usar ninguno de sus trucos.

Qué sabe hacer bien de verdad la RPA

La RPA es basada en reglas y determinista. Describe un flujo fijo, y corre cada vez igual: misma entrada, mismo camino, mismo resultado. Para un proceso estructurado y estable, por ejemplo transferir datos de un formulario fijo a un ERP, es justamente lo correcto. Es verificable, repetible y barato de operar. La debilidad se muestra solo cuando algo cambia: un nuevo layout de campos, una entrada inesperada, y la regla rígida se rompe.

Qué saben hacer mejor los agentes de IA

Un agente de IA entra en juego allí donde el flujo no es rígido: entradas ambiguas, lenguaje libre, decisiones que necesitan contexto. Puede leer un correo no estructurado y hacer lo correcto, donde una regla de RPA capitularía. El precio es que no es determinista: la misma entrada puede entregar dos resultados, y necesita guía, barandillas y verificación. Hasta dónde llegan los agentes no-code y dónde se detienen lo tratamos en otro lugar.

La línea de decisión

Una heurística simple separa los casos:

• Estable y estructurado (formulario fijo, regla clara, alta repetición): RPA. La fiabilidad le gana a la flexibilidad.
• Ambiguo y lingüístico (textos libres, entradas cambiantes, cuestiones de juicio): agente. La flexibilidad le gana a la rigidez.
• Mixto: a menudo la mejor respuesta. La RPA hace la parte fija, el agente asume solo el punto que de verdad exige juicio.

Las cifras del mercado invitan a la sobriedad: Gartner espera que más del 40 por ciento de los proyectos de IA agéntica se cancelen para finales de 2027. Muchos de ellos, porque se usó un agente donde una regla habría bastado.

El término medio sobrio

No IA o RPA, sino el nivel correcto para la parte correcta. El error más caro es dejar un flujo fiable y reglable a un agente no determinista, solo porque la IA suena más moderna. Empiece con la pregunta por la tarea, no por la herramienta. Dónde pertenece de verdad la IA en el stack y a través de qué interfaz lo ordena API frente a MCP frente a CLI.

Qué hace realmente SAM 3D Body

SAM 3D Body reconstruye una malla humana de cuerpo completo, incluidas manos y pies, a partir de una sola imagen, estimando tanto la pose como la forma. Introduce un nuevo formato de cuerpo paramétrico, el Momentum Human Rig (MHR), que desacopla el esqueleto de la superficie de tejido blando, de modo que el rig y la forma del cuerpo se pueden razonar por separado. Como el resto de la familia Segment Anything es promptable: puedes pasar keypoints 2D o máscaras de segmentación para guiar el resultado.

Los detalles prácticos importan para cualquiera que planee desplegarlo. Meta distribuyó pesos abiertos en dos backbones, un DINOv3-H+ de unos 840M de parámetros y un ViT-H de unos 631M, junto con código de inferencia, datos de entrenamiento y el modelo MHR. Reporta un error de malla en 3DPW (MPJPE) de 54,8, y ya alimenta una función de consumo en vivo, la de Facebook Marketplace View in Room. Se entrenó con unos 8 millones de imágenes. Esto no es una demo de investigación; entró en un producto el día uno.

La victoria B2B es el pipeline, no los píxeles

El punto estratégico para una empresa alemana o de la UE es dónde corre el cómputo, no qué tan ingeniosa se ve la malla. Una imagen de cuerpo humano es dato personal sensible bajo el RGPD. En el momento en que envías la foto de un cliente a una API de reconstrucción de terceros, tienes un contrato de encargo de tratamiento, una cuestión de transferencia y un coste de confianza. Los pesos abiertos eliminan ese paso: ejecutas el modelo dentro de tu propia red, y la imagen del cuerpo nunca sale.

Eso reencuadra varios casos de uso de incómodos a apropiables. La prueba virtual y la visualización de ajuste, los avatares de AR y VR, la analítica de fitness y movimiento, y el previz para animación o producción virtual pueden todos correr en infraestructura que controlas, con la misma UX que daría una API alojada. Esta es la misma lógica de pipeline propio que aplicamos a generar assets 3D a partir de una sola imagen con TRELLIS: el valor no es solo el modelo, es mantener la entrada sensible en tu propio lado del muro. La licencia es lo único que verificar antes de construir: el rig MHR está confirmado como comercial permisivo, y los pesos del cuerpo se distribuyen bajo la SAM Licence, así que lee los términos reales para tu uso.

Dónde se rompe en silencio

Dimensionar el caso de uso correctamente es toda la habilidad, porque la reconstrucción a partir de una sola imagen tiene límites honestos que ninguna cantidad de calidad de modelo elimina. El análisis independiente encontró que SAM 3D Body prioriza una pose plausible sobre la precisión métrica, y empujará cuerpos atípicos (escoliosis, cambios por edad, embarazo) hacia un promedio sano. Eso está bien para un avatar que debe verse bien; está mal para el dimensionamiento médico, ergonómico o legal, donde la desviación es el punto.

Tres límites más para los que diseñar. Una sola imagen no puede resolver profundidad ni escala verdadera, así que la posición global y las dimensiones del mundo real son conjeturas poco restringidas. La oclusión fuerte, donde la mayor parte del cuerpo está oculta, lo degrada de forma pronunciada. Y es por imagen, no en tiempo real: la comunidad ya corre por arreglarlo con variantes más rápidas y runtimes en C++, y el vídeo necesita maquinaria extra para la estabilidad temporal. La regla que te mantiene a salvo es simple. Dimensiona el caso de uso a lo plausible (visualización, prueba, avatares), no a lo preciso (medición, diagnóstico, seguridad). Dentro de esa línea, un modelo humano 3D propio y preservador de la privacidad es una opción nueva real en 2026.

Dónde fracasa el RAG clásico en la pyme

RAG convierte sus documentos en conocimiento buscable. El punto débil es la primera etapa: el reconocimiento de texto. Una factura de proveedor con tabla de posiciones, un contrato de dos columnas, una hoja de datos escaneada con plano acotado: el OCR recompone algo así con regularidad de forma equivocada. La tabla se vuelve un desierto de cifras, las columnas se entrecruzan, el plano desaparece. El modelo recibe entonces ya texto roto y responde en consecuencia. En nuestra experiencia, con expedientes reales la mayor parte de los errores está aquí, mucho antes de que un modelo de lenguaje tome siquiera la palabra.

Cómo lo esquiva la búsqueda visual

Los modelos de retrieval visual se saltan el reconocimiento de texto al buscar. Descomponen la imagen de la página en muchos pequeños fragmentos, incrustan cada uno y comparan la consulta directamente con ellos. Así se conserva que una cifra está en una celda de tabla y no en el texto corrido. Tres nombres encabezan el campo: ColPali como referencia, ColQwen como variante casi siempre más fuerte sobre base Qwen, y ModernVBERT como modelo pequeño y apto para on-prem. Toda la caja de piezas junto con la base de datos vectorial la ordenamos en el resumen del stack. Para la mirada práctica basta: la página se ve, no se adivina.

Honesto sobre los costes

La ganancia no es gratis. Varios vectores por página necesitan bastante más memoria de índice que un único vector de texto. Con un archivo de texto corrido puro y limpio, el RAG de texto clásico sigue siendo más barato y basta. La búsqueda visual vale la pena allí donde el layout porta la información, y justamente eso es en la pyme más la regla que la excepción. Y para casos en los que al final necesita de todos modos texto buscable, por ejemplo para copiar o para un rastro de auditoría, el OCR sigue siendo sensato, como complemento en lugar de sustituto.

El primer paso es pequeño

No hay que reconstruir nada grande para ello. Tome los veinte documentos en los que su búsqueda actual fracasa, y haga justamente las preguntas que hoy se equivocan. Si la búsqueda visual encuentra la fila de tabla que el OCR perdió, tiene su respuesta, en sus propios expedientes, no en un benchmark. Lo bonito de ello: todo el montaje corre localmente, los datos se quedan en casa. Por qué eso cuenta para documentos sensibles está en On-Premise contra Cloud.

Por qué la costura era el verdadero problema

Generar una secuencia larga uniendo clips cortos introduce justamente los artefactos que hacen inutilizable el metraje: costuras visibles entre segmentos, rostros de personajes que se desvían entre planos, iluminación que salta. Para un vídeo de marca o de producto, esa deriva es la diferencia entre un asset usable y una falsificación obvia. La duración en una sola pasada elimina la costura, que es por lo que 30 segundos nativos son un paso real, no una cifra de vanidad.

Qué cambia realmente en la 2.5

Tres cosas destacan para un equipo que de verdad lo usaría:

• Clips nativos de 30 segundos. Una pasada, sin costuras, así que la consistencia se mantiene a lo largo de toda la duración.
• Hasta 50 referencias multimodales. Imágenes, audio y vídeo combinados en una generación, unas cuatro veces las doce de Seedance 2.0, orientadas a mantener estables un personaje, un producto y un estilo.
• Generación conjunta de audio y vídeo. Lo visual y lo auditivo se coprocesan en un espacio latente en lugar de generarse por separado y sincronizarse después, que es lo que mantiene alineados el movimiento y el sonido.

Juntas apuntan al mismo objetivo: consistencia en el tiempo, que es lo que el vídeo de negocio necesita y los clips cortos no podían dar.

La salvedad honesta

La calidad es ahora la parte fácil. Para uso de negocio, las preguntas difíciles lo deciden: ¿puedes usar el metraje comercialmente, de quién es la imagen que aparece, a dónde van los datos, y es la salida lo bastante consistente para ponerle una marca? Seedance 2.5 está en beta empresarial con un lanzamiento público previsto para principios de julio, así que los detalles de licencia y procedencia son justo lo que hay que leer antes de comprometerse. El campo más amplio, y cómo elegir entre los modelos, está en nuestro estado del vídeo con IA 2026.

Dónde encaja

Para storyboarding, películas de concepto y assets sociales cortos, un clip nativo limpio de 30 segundos cambia lo que una sola persona puede producir. Para trabajo regulado o crítico para la marca, trátalo como un motor de borradores hasta que los derechos y la consistencia superen tu listón. La capacidad es real; la gobernanza es la parte a acertar primero.

Dónde ayuda

El Vibe Coding brilla en todo lugar donde cuenta la velocidad y el código puede desaparecer después. El prototipo en una tarde, la herramienta interna para un equipo pequeño, la maqueta clicable para una presentación de cliente, el primer 70 por ciento de una idea: aquí aporta valor real. El ejemplo original de Karpathy era justamente eso, software desechable para un proyecto de fin de semana.

La demanda lo confirma. Herramientas como Cursor, Claude Code, Lovable y Bolt han crecido en tiempo récord, Lovable hasta unos 200 millones de dólares de facturación anual a finales de 2025. También en mi trabajo el beneficio es concreto: una persona experta sin formación en programación puede poner en marcha una idea ella misma, en lugar de describirla primero y luego esperar dos semanas. Mientras el resultado siga siendo un experimento y nadie apoye su negocio en él, es una ganancia de velocidad que no habría que minimizar.

Dónde muerde

En cuanto el código se entrega, la imagen se invierte, y las pruebas son incómodamente concretas. Veracode examinó en 2025 más de 80 tareas y más de 100 modelos: el 45 por ciento del código generado contenía una brecha de seguridad, y los modelos más nuevos o más grandes no salieron mejor parados. Un estudio de METR encontró que los desarrolladores experimentados con herramientas de IA fueron un 19 por ciento más lentos, pero se creyeron más rápidos.

A eso se suman los incidentes que quedan en la memoria. Un agente de Replit borró en julio de 2025 una base de datos de producción, ignoró la instrucción expresa de no cambiar nada, y afirmó después que una restauración era imposible (no lo era). Alrededor de uno de cada cinco paquetes propuestos por una IA no existe siquiera, y el 43 por ciento de esos nombres inventados aparece de forma repetida, lo que abre a los atacantes una nueva brecha de cadena de suministro. Addy Osmani lo llama el problema del 70 por ciento: la IA le lleva rápido al 70 por ciento, el último 30 por ciento de casos especiales, seguridad e integración sigue siendo trabajo de ingeniería clásico. Y jurídicamente la situación es inequívoca: la responsabilidad por el software entregado se queda con la empresa que lo construye y vende, no con el proveedor de IA.

La línea: desechable frente a entregado

La distinción más útil no es una sobre herramientas, sino sobre el propósito. Un script que una persona usa una vez es otra cosa que un software que sus clientes, sus auditores y el Cyber Resilience Act de la UE a partir de diciembre de 2027 juzgan. Incluso Gartner, que cuenta hasta 2028 con un 40 por ciento de cuota de Vibe Coding en el software empresarial, llama expresamente a la salida en bruto código desechable, no listo para producción.

Para la pyme eso significa: la pregunta no es si su equipo puede usar Vibe Coding, sino para qué. Desechable y experimento: con gusto, rápido, sin ceremonia. Todo lo que toca datos de clientes, se entrega o debe resistir una auditoría: nunca sin leer. Esa sola clasificación ahorra la mayoría de los dolores posteriores.

El camino maduro: Vibe Coding controlado

La buena noticia es que la respuesta profesional en 2025 y 2026 ya existe, y no se llama prohibición. Se llama Vibe Coding controlado, o desarrollo asistido por IA: la IA como junior muy rápido, con un senior responsable al lado. Así lo abordamos.

🔸 Especificación antes del prompt. El contramovimiento se llama Spec-driven Development, con herramientas como GitHub Spec Kit: primero especificación, plan y tareas, luego código. Eso hace el resultado verificable en lugar de aleatorio.

🔸 Revisión y pruebas antes de producción. Ningún código de IA entra en vivo sin leer. Revisión de código, pruebas automatizadas y un escaneo de seguridad son la condición, no el adorno, sobre todo en todo lo que toca datos o dinero.

🔸 Licencia y cadena de suministro a la vista. El código de IA sin verificar puede colar fragmentos con licencia GPL o paquetes inventados. Ambos pertenecen al proceso de verificación, antes de que se conviertan en un problema de cumplimiento.

El Vibe Coding es una herramienta brillante para la tarea correcta y un riesgo para la equivocada. La diferencia está en saber, antes del primer prompt, en qué lado de la línea se está. ¿En qué lado está su próximo proyecto?