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.

Questo articolo mette in ordine i programmi più importanti secondo la situazione a settembre 2026, descrive passo dopo passo il percorso verso la domanda e indica gli errori tipici che possono costarvi l'agevolazione.

Quali tipi di agevolazione esistono

Esistono quattro tipi di agevolazione, e si distinguono più per la loro logica che per il loro importo. Un contributo a fondo perduto copre una parte dei costi ammissibili e non va restituito, ma richiede una domanda prima dell'avvio del progetto e, alla fine, una rendicontazione dell'uso dei fondi (Verwendungsnachweis). Un finanziamento agevolato passa attraverso la vostra banca (Hausbank) e nei livelli superiori può includere una quota a fondo perduto. La Forschungszulage è un'agevolazione fiscale per ricerca e sviluppo. Le offerte di consulenza non erogano denaro, ma aiutano a inquadrare un progetto.

Un progetto di IA non è ammissibile solo per la parola chiave IA, ma quando corrisponde allo scopo di un programma: ricerca e sviluppo, digitalizzazione di processi e prodotti o consulenza esterna. Nella ricerca aiuta sapere che il Ministero federale dell'Economia opera oggi come BMWE (in precedenza BMWK) e il Ministero della Ricerca come BMFTR.

I programmi federali in sintesi

A livello federale, nel 2026 cinque strumenti sono particolarmente rilevanti per i progetti di IA, con uno stato molto diverso.

• ZIM (Zentrales Innovationsprogramm Mittelstand, programma centrale per l'innovazione delle PMI). Il BMWE finanzia progetti di ricerca e sviluppo delle PMI, da sole o con istituti di ricerca, oltre a reti di innovazione e studi di fattibilità. Dal 7 luglio 2026 vige una sospensione temporanea delle domande: ZIM al momento non accetta nuove domande, si punta a riaprirlo all'inizio del 2027 e la riapertura dipende dal bilancio 2027. Le domande già presentate continuano a essere valutate.
• KMU-innovativ. Il BMFTR finanzia progetti di ricerca e sviluppo ad alto rischio in tecnologie chiave, tra cui le tecnologie dell'informazione e della comunicazione. La procedura è in due fasi: prima una bozza di progetto, poi la domanda. Le scadenze sono il 15 aprile e il 15 ottobre, la prossima è il 15 ottobre 2026 (aggiornato a settembre 2026). Pagina del programma KMU-innovativ.
• Forschungszulage (agevolazione fiscale per la ricerca). Può richiederla ogni impresa soggetta a imposta in Germania, indipendentemente da dimensione e settore. Prima la BSFZ certifica che si tratta di ricerca e sviluppo, poi l'agevolazione si richiede all'ufficio delle imposte dopo la chiusura dell'esercizio, anche per progetti già realizzati. Per il 2026 è stata ampliata con l'Investitionssofortprogramm (programma di investimenti immediati). Ente di certificazione della Forschungszulage.
• ERP-Förderkredit Digitalisierung (511, 512). Tramite la vostra banca, la KfW finanzia la digitalizzazione su tre livelli, da IT, software e cloud, passando per la digitalizzazione dei processi, la sicurezza informatica e la formazione, fino a progetti più ampi, compreso esplicitamente l'uso dell'IA sui dati aziendali. La domanda va presentata prima dell'avvio del progetto, e per il primo livello è necessario prima un KfW-Digitalisierungs-Check. Pagina prodotto della KfW.
• Mittelstand-Digital Zentren. Il BMWE finanzia un supporto gratuito e indipendente dai fornitori su digitalizzazione, IA e sicurezza informatica, con formatori di IA nei centri. Non viene erogato denaro. La rete attuale si conclude gradualmente entro la fine del 2026, e dal 1° gennaio 2027 seguirà una nuova rete con un'attenzione aggiuntiva alla sicurezza informatica, sempre gratuita per le PMI. Mittelstand-Digital.

Per consorzi di scienza e industria è inoltre aperta la direttiva del BMFTR sui progetti faro di IA nelle catene del valore, con scadenza per le bozze di progetto il 1° novembre 2026 (aggiornato a settembre 2026).

Agevolazioni a livello UE

A livello UE, per i progetti di IA sono disponibili quattro strade: gli European Digital Innovation Hubs, l'EIC Accelerator, il finanziamento a cascata e il programma Europa digitale.

• European Digital Innovation Hubs (EDIH). Consorzi regionali offrono servizi gratuiti o agevolati, come «test before invest», formazione e supporto nella ricerca di investimenti, con priorità come l'IA e la cybersicurezza. Panoramica della Commissione europea.
• EIC Accelerator. Il Consiglio europeo per l'innovazione sostiene singole start-up e PMI con innovazioni dirompenti vicine al mercato, tramite contributo, investimento nel capitale o entrambi. Le proposte brevi possono essere presentate in qualsiasi momento, e la prossima scadenza per le proposte complete è il 4 novembre 2026 (aggiornato a settembre 2026). EIC Accelerator.
• Finanziamento a cascata. Consorzi di progetti finanziati dall'UE trasferiscono parte del loro budget a start-up e PMI tramite bandi aperti, come somme forfettarie, premi o voucher e con procedure semplificate, ad esempio per piccoli esperimenti e progetti pilota. I bandi restano aperti almeno due mesi sul portale Funding & Tenders dell'UE. Guida della Commissione (PDF).
• Programma Europa digitale. La Commissione pubblica bandi per IA, supercalcolo, cybersicurezza e competenze digitali. Le PMI ne beneficiano per lo più indirettamente, ad esempio tramite gli EDIH. Pagina del programma.

Programmi regionali in Renania-Palatinato

In Renania-Palatinato le agevolazioni del Land sono concesse dall'ISB, e per i progetti di IA sono particolarmente rilevanti quattro programmi.

• InnoTop. Finanziamento tecnologicamente neutrale di studi di fattibilità e progetti di ricerca e sviluppo per prodotti, processi e servizi nuovi o migliorati, per PMI e SmallMidCaps.
• Innovationsgutschein (FuE-Auftrag). Un voucher per l'innovazione: contributo per PMI che affidano attività di ricerca e sviluppo della durata massima di dodici mesi a un'università o a un istituto di ricerca.
• IBI-EFRE. Contributo per investimenti con cui PMI commerciali realizzano la digitalizzazione nella produzione e nei modelli di business. Alcuni settori sono esclusi, si applica un volume minimo di investimento e la domanda si presenta tramite il portale dell'ISB prima dell'avvio del progetto. Scheda nella Förderdatenbank.
• Betriebsberatungsprogramm RLP. Contributo per la consulenza esterna, esplicitamente anche su digitalizzazione e intelligenza artificiale. Le domande sono possibili dal 16 dicembre 2025, e per alcuni temi è necessaria una raccomandazione della camera competente. Il programma sostituisce la consulenza tecnologica BITT, conclusa alla fine del 2025. Pagina del programma dell'ISB.

La panoramica dei programmi per innovazione e digitalizzazione si trova su isb.rlp.de. Nel catalogo UE per la Germania non è stato possibile trovare alcun EDIH con sede in Renania-Palatinato (aggiornato a settembre 2026). Le opzioni più vicine sono l'EDIH Saarland, che si rivolge anche alla Grande Regione, e il Mittelstand-Digital Zentrum Kaiserslautern, che supporta le imprese della Renania-Palatinato nella preparazione all'IA.

Programmi regionali in Renania Settentrionale-Vestfalia

In Renania Settentrionale-Vestfalia, Mittelstand Innovativ & Digital (MID) è l'accesso centrale per le PMI con sede nel Land, e dal 1° gennaio 2026 è la NRW.BANK ad approvare i nuovi progetti.

• MID-Digitalisierung. Contributo per lo sviluppo di prodotti digitali orientati al mercato con tecnologie chiave, esplicitamente comprese IA, apprendimento automatico e data mining. Pagina prodotto della NRW.BANK.
• MID-Digitale Sicherheit. Contributo per analisi dello stato informatico, compresi i penetration test, formazione del personale e misure di protezione informatica di base. Portale delle agevolazioni NRW.

Entrambi i programmi assegnano i posti per la domanda tramite un sorteggio mensile. Chi viene estratto ha 28 giorni per presentare la domanda, e l'estrazione non è ancora un impegno di finanziamento. Il bando 2026 di MID-Digitale Prozesse, che finanzia la consulenza esterna, è già chiuso perché è stato raggiunto il numero massimo di domande (aggiornato a settembre 2026). In Renania Settentrionale-Vestfalia esistono inoltre tre EDIH: a Dortmund, in Renania con sede ad Aquisgrana e nella Vestfalia meridionale.

Altri Länder e programmi conclusi

Per tutti gli altri Länder, la Förderdatenbank (banca dati federale delle agevolazioni) è la via più rapida verso i programmi adatti. Ogni Land ha i propri programmi, e la Förderdatenbank raccoglie le agevolazioni di Stato federale, Länder e UE, filtrabili per regione, beneficiari e tipo di agevolazione. Resta determinante la pagina dell'ente erogatore, perché i bandi aprono e chiudono nel corso dell'anno.

Si sono conclusi due programmi federali che vengono ancora cercati spesso: Digital Jetzt non accetta più domande e go-digital è terminato alla fine del 2024. È superato anche il nome ERP-Digitalisierungs- und Innovationskredit, il prodotto attuale della KfW è l'ERP-Förderkredit Digitalisierung.

Passo dopo passo verso la domanda

In quasi tutti i programmi il percorso verso la domanda segue gli stessi dieci passi, anche se moduli e portali cambiano.

1. Verificare lo status di PMI. Secondo la raccomandazione UE 2003/361 è una PMI l'impresa con meno di 250 dipendenti che rispetta le soglie di fatturato annuo o di totale di bilancio. Le imprese associate e collegate possono essere conteggiate. La Forschungszulage e l'ERP-Förderkredit Digitalisierung sono aperti anche a imprese più grandi. Definizione UE di PMI.
2. Sfruttare l'orientamento gratuito. Un Mittelstand-Digital Zentrum, un EDIH o il servizio federale di consulenza sulle agevolazioni vi aiutano a inquadrare il progetto prima di investire impegno in una domanda.
3. Verificare il programma e il suo stato. Il programma è aperto, c'è una scadenza, un sorteggio o una sospensione delle domande?
4. Non iniziare prima dell'approvazione. Un avvio anticipato della misura (vorzeitiger Maßnahmenbeginn), cioè un avvio prima di aver ricevuto il provvedimento di concessione, di norma non è consentito, a meno che la direttiva o un consenso scritto lo permettano. Questo vale anche per gli incarichi vincolanti a fornitori di servizi. Presso la KfW la domanda deve essere presentata prima dell'avvio del progetto.
5. Sommare gli aiuti de minimis. Quando un programma concede aiuti de minimis, vale un massimale di 300.000 euro per impresa nell'arco di tre anni. Nella domanda dichiarate quanto avete già ricevuto in quel periodo. Dal 1° gennaio 2026 è obbligatorio a tal fine un registro centrale. Regolamento (UE) 2023/2831.
6. Scrivere la bozza di progetto. Nelle procedure in due fasi si parte da una breve bozza che deve essere comprensibile senza domande aggiuntive ed è in concorrenza con altre bozze. I progetti sono seguiti da Projektträger (enti di gestione dei progetti) come DLR, PtJ o VDI/VDE-IT, che operano per conto del ministero. Nozioni di base sul finanziamento di progetti.
7. Presentare la domanda. Le domande federali di ricerca passano per lo più da easy-Online, i finanziamenti KfW dalla vostra banca, i programmi regionali dai portali dell'ISB o della NRW.BANK. I documenti tipici sono la descrizione del progetto con piano di lavoro, il piano dei costi e di finanziamento, la documentazione sul merito creditizio, la dichiarazione PMI, se necessario la dichiarazione de minimis e i preventivi dei fornitori.
8. Garantire la quota propria. I contributi coprono solo una parte dei costi, il resto lo finanzia l'impresa stessa.
9. Verificare il cumulo. Le agevolazioni si possono combinare, ma solo entro le intensità di aiuto consentite, e gli stessi costi non possono mai essere finanziati due volte. Di solito si suddivide per voci di costo, ad esempio consulenza gratuita, un finanziamento per l'investimento e la Forschungszulage per la quota di sviluppo.
10. Rendicontare. Durante il progetto riferite al Projektträger, e alla fine segue il Verwendungsnachweis, composto da un rendiconto numerico e da una relazione tecnica finale. FAQ del DLR Projektträger.

Errori tipici

Gli errori tipici sono di natura formale e si possono evitare prima della domanda.

• Incarichi conferiti troppo presto. Chi firma in modo vincolante contratti di fornitura o di consulenza prima dell'approvazione, o a seconda del programma già prima della domanda, può perdere l'ammissibilità.
• Status di PMI sopravvalutato. La controllata di un gruppo più grande può non essere una PMI, anche se di per sé è piccola.
• Stato non verificato. I programmi chiudono anche in corso d'anno, come mostrano la sospensione delle domande di ZIM e il bando esaurito di MID-Digitale Prozesse nel 2026.
• Sorteggio frainteso. In MID l'estrazione non è un impegno, e il termine successivo è breve.
• Scopo del programma mancato. Un programma di consulenza non finanzia licenze software, e un Mittelstand-Digital Zentrum non eroga denaro.
• Scadenza persa. Con KMU-innovativ una scadenza persa significa sei mesi di attesa.
• De minimis calcolato male. Il periodo di tre anni è mobile e non legato agli anni civili.
• Nomi confusi. L'EDIH Rheinland ha sede ad Aquisgrana e non è un punto di riferimento per la Renania-Palatinato. Articoli di blog meno recenti citano inoltre programmi e nomi di prodotti che non esistono più.

Quale programma per quale progetto di IA

Il programma adatto deriva dalla natura del progetto: ricerca, adozione o consulenza.

Un progetto di IA è vicino alla ricerca quando comporta un rischio tecnico, ad esempio un nuovo metodo o un modello per una questione il cui risultato non è noto in anticipo. A questo sono destinati la Forschungszulage, KMU-innovativ, InnoTop e l'Innovationsgutschein, ZIM dopo la riapertura, e per progetti dirompenti vicini al mercato l'EIC Accelerator.

Si parla di adozione quando una tecnologia collaudata entra nella vostra azienda, ad esempio una ricerca nei vostri documenti o l'automazione di un processo. Sono adatti l'ERP-Förderkredit Digitalisierung, in Renania-Palatinato IBI-EFRE e in Renania Settentrionale-Vestfalia MID-Digitalisierung, se ne nasce un prodotto digitale. I bandi aperti di finanziamento a cascata possono sostenere piccoli progetti pilota.

La consulenza viene per prima quando non è ancora chiaro se un caso d'uso regge. I Mittelstand-Digital Zentren e gli EDIH sono gratuiti, e in Renania-Palatinato la consulenza esterna è sovvenzionata tramite il Betriebsberatungsprogramm. Per la sicurezza informatica intorno a un progetto di IA, la Renania Settentrionale-Vestfalia offre MID-Digitale Sicherheit.

Questo articolo è un'informazione generale e non una consulenza legale o fiscale, e le condizioni delle agevolazioni cambiano.

Un progetto di IA dovrebbe essere delimitato nei contenuti prima di porsi la domanda sulle agevolazioni, maggiori dettagli in preparazione all'IA.

Che cos'è Slush

Slush è una conferenza per start-up e investitori a Helsinki, nata nel 2008 come incontro di 250 persone. È senza scopo di lucro, appartiene alla finlandese Startup Foundation ed è organizzata da studenti e neolaureati insieme a un grande team di volontari.

L'evento si svolge il 18 e 19 novembre 2026 all'Helsinki Expo and Convention Centre (Messukeskus), con un programma Day 0 il 17 novembre. Secondo l'organizzatore partecipano oltre 12.000 persone, di cui circa tre quarti start-up o investitori. L'attenzione è rivolta a start-up europee selezionate, investitori internazionali e media tecnologici, e Slush indica espressamente la regione DACH come regione chiave. Programma e dettagli sono sul sito ufficiale di Slush.

Che cosa porta iiterate

iiterate porta a Helsinki il lavoro che svolgiamo ogni giorno: IA per ambienti in cui i dati non dovrebbero lasciare l'azienda. Siamo una società di consulenza sull'IA con sede ad Adenau, in Renania-Palatinato, e partecipiamo come parte della delegazione tedesca. I nostri ambiti:

• LLM on-premise. Modelli linguistici che funzionano nella propria infrastruttura.
• RAG e gestione della conoscenza. Sistemi di retrieval che ricavano le risposte dai documenti di un'azienda e ne indicano le fonti.
• IA con dati conservati nell'UE. Architetture in cui elaborazione e archiviazione restano nell'Unione europea.
• Computational design. Modelli parametrici e configuratori in cui sono le regole a generare la geometria.

Nei colloqui partiamo da domande concrete: quali dati tocca un progetto, dove può avvenire l'elaborazione e quale architettura ne deriva.

Chi dovrebbe parlare con noi

Dovrebbero parlare con noi soprattutto investitori, aziende e fondatrici e fondatori che hanno a che fare con IA e dati sensibili.

• Investitrici e investitori che valutano progetti di IA in settori regolamentati o sensibili dal punto di vista dei dati.
• Aziende che vogliono usare l'IA su documenti riservati e hanno bisogno per questo di conservare i dati nell'UE o nella propria sede.
• Fondatrici e fondatori che lavorano sull'IA con dati sensibili e desiderano parlare di architettura, gestione operativa o collaborazione.

Un progetto non ancora del tutto definito non è un ostacolo, ma un buon punto di partenza per un colloquio.

Fissare un incontro a Helsinki

Il modo migliore per fissare un incontro a Helsinki è farlo in anticipo tramite la nostra pagina di contatto. Indicate brevemente il vostro tema e i giorni in cui sarete sul posto. I colloqui possono svolgersi in tedesco o in inglese.

La specifica, senza marketing

Prima di parlare di conseguenze aiuta la tabella asciutta. Tutti i valori provengono dalla panoramica dei modelli e dalla pagina dei prezzi di Anthropic, consultate il 10 settembre 2026.

Colpisce ciò che Anthropic aggiunge nella propria panoramica dei modelli: Claude Opus 5 è raccomandato come scelta predefinita per la maggior parte dei carichi di lavoro, mentre Fable 5.1 è pensato per i casi in cui Opus 5 a un livello di effort superiore non basta. È un'autolimitazione insolitamente netta e, al tempo stesso, il primo filtro di ogni decisione di architettura. Fable 5.1 non è un aggiornamento generalizzato, ma uno strumento per compiti lunghi e continui.

La modalità è stretta, e nella pratica conta. Entrano testo e immagini, esce testo. Nessun audio in ingresso, nessun audio in uscita, nessuna generazione di immagini o video. Chi vuole elaborare la registrazione di una chiamata ha bisogno di una trascrizione a monte. Chi ha bisogno di risposte parlate ha bisogno di una sintesi vocale a valle. Chi vuole produrre grafiche ha bisogno di un altro modello. Sembra banale, ma sposta confini di sistema, costi e questioni di protezione dei dati esattamente nei punti in cui si trovano quei componenti aggiuntivi.

Che cosa cambia un milione di token, e che cosa no

La finestra è fatturata per tutta la sua lunghezza alle tariffe normali per token, senza sovrapprezzo per contesti lunghi (Anthropic). Diventano così possibili impianti che prima non fallivano per il modello ma per la suddivisione: un intero corpus di contratti o di documenti di gara in un solo passaggio invece che in trenta frammenti con una successiva ricomposizione; una traccia di agente completa, comprese tutte le uscite degli strumenti, ancora analizzabile invece che troncata dopo venti passi; un repository di medie dimensioni su cui una domanda trova risposta in una volta sola invece che tramite una ricerca che deve indovinare in anticipo quali file contino. Il guadagno sta meno nell'intelligenza che nella scomparsa di un'intera classe di lavoro di raccordo, e nei nostri progetti quel raccordo è stato regolarmente la fonte degli errori difficili da trovare.

Il numero però non è un conteggio di pagine. Anthropic quantifica 1.000.000 di token in circa 555.000 parole inglesi con il tokenizzatore attuale e nello stesso passaggio segnala che questo tokenizzatore produce, per lo stesso testo, circa il 30 per cento di token in più rispetto al precedente (Anthropic). Il dato riguarda testo inglese; per un corpus in lingua tedesca non se ne può ricavare alcun numero, va misurato. Chi pianifica capacità conta i propri documenti con il tokenizzatore del modello che utilizza davvero, e non ragiona in pagine.

Per lo stesso motivo il confronto tra ampiezze di finestra di fornitori diversi non dice nulla. Un token è un'unità specifica del fornitore e non esiste alcuna conversione pubblicata che riporti due tokenizzatori alla stessa quantità di testo. Un numero su una scheda tecnica non indica quindi quale modello contenga più del vostro testo.

E la finestra più ampia non rende superfluo il recupero delle informazioni. Il ragionamento è semplice: tutto ciò che sta nella finestra viene pagato a ogni chiamata e deve essere elaborato a ogni chiamata. Un metodo che trova i venti paragrafi pertinenti resta più rapido, meno costoso e di norma più preciso di uno che ne riversa dentro diecimila sperando nell'attenzione. La finestra grande alza nettamente la soglia oltre la quale la suddivisione diventa necessaria. Non sostituisce la domanda su quale informazione serva per questa singola risposta.

La vera storia ingegneristica si chiama lettura di cache

Il numero più interessante della specifica non è un valore assoluto ma un rapporto. L'input fresco costa 10 USD per milione di token, un successo di cache 0,25 USD. La scrittura in cache costa 12,50 USD per milione di token nel livello a cinque minuti e 20 USD nel livello a un'ora. Su Fable 5.1 e Mythos 5.1 il prezzo di lettura è pari a 0,025 volte il prezzo base, contro 0,1 volte su tutti gli altri modelli Claude, e secondo Anthropic è l'unica modifica di prezzo rispetto a Fable 5 (Anthropic).

Il fattore 40 tra input fresco e successo di cache è ciò che decide i progetti. In un ciclo agentico lo stesso prompt di sistema, le stesse definizioni degli strumenti e lo stesso contesto di progetto vengono riletti a ogni singolo passo. Un compito su duecento chiamate di strumenti rilegge duecento volte lo stesso preambolo. Che quel preambolo sia fatturato ogni volta come input fresco oppure come successo di cache non è un dettaglio contabile, ma il confine tra un progetto che si può portare in produzione e uno che resta nella dimostrazione.

Proprio per questo la formulazione di Anthropic, secondo cui i carichi tipici costerebbero circa il 25 per cento in meno e quelli fortemente agentici fino a circa il 45 per cento, è una stima sui tassi di successo della cache e non un taglio di prezzo (Anthropic). I prezzi di listino per ingresso e uscita sono invariati rispetto a Fable 5. Un carico con scarsa località di cache non vede quasi nulla di quel risparmio, e chi mette il 25 per cento in un preventivo senza quella riserva non ha un preventivo ma una speranza.

Ciò che nella pratica rende buoni o cattivi i tassi di successo non è una metrica documentata ma logica ingegneristica, e si può nominare:

• Un prefisso stabile. Ciò che viene riutilizzato è l'inizio invariato della richiesta. Tutto ciò che è costante va davanti, tutto ciò che varia dietro. Una marca temporale, un identificativo di sessione o un nome utente nel posto sbagliato invalida tutto il contesto che segue.
• Assemblaggio deterministico. Elenchi di strumenti in ordine casuale, risultati di recupero con ordinamento variabile oppure oggetti con ordine delle chiavi instabile producono un nuovo prefisso a ogni esecuzione. La cache non vede mai due volte la stessa cosa.
• La durata contro il ritmo del compito. Cinque minuti si adattano a un ciclo agentico serrato. Non si adattano a un dialogo in cui una persona passa venti minuti in riunione tra due domande. Il livello a un'ora costa di più in scrittura e conviene solo quando salva davvero il successo.
• Ripetizione sufficiente per prefisso. Molte richieste brevi e non correlate tra loro si distribuiscono su molti prefissi. Ciascuna paga una scrittura e ottiene di rado una lettura. È il caso in cui l'economia della cache lavora contro di voi, e allora l'interfaccia batch con il 50 per cento di sconto in entrambe le direzioni è spesso la strada migliore.

Un riferimento concreto dal listino sostiene lo stesso punto: il set di strumenti per l'uso del computer aggiunge circa 4.500 token di input per richiesta, quello per l'uso del browser circa 6.600 (Anthropic). È un blocco costante che ricorre a ogni passo, quindi esattamente il materiale che appartiene a un prefisso stabile.

Funzionamento agentico, strumenti e la questione del livello di effort

Fable 5.1 è pensato per esecuzioni lunghe. Anthropic cita come prova un'esecuzione non presidiata di 38 ore su un problema di machine learning (Anthropic). È una dichiarazione del fornitore su una singola esecuzione e non un risultato di distribuzione, ma serve come ordine di grandezza di ciò per cui il modello è stato progettato.

La modalità di ragionamento è adattiva e sempre attiva; la precedente modalità manuale con budget di ragionamento esplicito non è più accettata. Rispetto a Fable 5 ci sono tre modifiche che rompono la compatibilità e toccano ogni integrazione esistente: l'uso forzato degli strumenti restituisce un errore, i modelli precedenti non possono leggere i blocchi di ragionamento di questo modello e la modifica di turni precedenti invalida tali blocchi. Si aggiungono, tra le altre cose, un livello di effort per messaggio, messaggi di sistema validi nel turno, aggiornamenti di avanzamento leggibili tra le chiamate agli strumenti e il prezzo ridotto di lettura della cache; diversi di questi sono indicati come beta (Anthropic). Per la pianificazione significa che passare a questo modello non è una modifica di configurazione, ma una piccola ricostruzione seguita da un test.

Sui livelli di effort serve cura. La documentazione indica high come predefinito (Anthropic), e l'annuncio precisa che l'impostazione predefinita varia a seconda della superficie: high in Claude Code, medium in Claude Cowork e su claude.ai (Anthropic). L'insieme completo dei valori accettati non compare nelle pagine di documentazione che abbiamo consultato, e quindi non lo affermiamo.

La conseguenza pratica è scomoda ma importante: un numero di benchmark o una stima di costo senza il livello di effort indicato non è riproducibile. Due team che misurano lo stesso modello attraverso due superfici diverse misurano configurazioni diverse. Chi vuole che proposte, risultati di test o confronti interni reggano annota il livello accanto al numero, come non si lascerebbe passare una misura senza unità.

Una conoscenza ferma a giugno 2026 è un requisito di architettura

Il limite della conoscenza e dei dati di addestramento è giugno 2026 (Anthropic). Sul piano operativo significa insieme poco di drammatico e parecchio. Il vostro listino della settimana scorsa, la decisione di ieri, lo stato del vostro portafoglio ordini di stamattina: nulla di tutto ciò è nel modello. Deve arrivare nel contesto tramite recupero, tramite un collegamento a uno strumento oppure tramite il prompt.

Non è un difetto del modello ma un requisito per l'architettura, ed è indipendente dal fornitore. Qualsiasi sistema che debba informare su fatti attuali senza un percorso definito lungo il quale quei fatti entrano è specificato male, per quanto buono sia il modello. Due conseguenze si sono dimostrate utili da noi. Primo: ogni risposta fondata su fatti richiede nel contesto una fonte nominabile, non la memoria del modello. Secondo: ogni insieme di valutazione richiede alcune domande la cui risposta corretta è cambiata dopo il limite di conoscenza, perché mettono alla prova proprio il percorso che in produzione si rompe più facilmente in silenzio.

La filigrana dell'articolo 50 non è una pista di controllo

Fable 5.1 e Mythos 5.1 portano fin dal lancio una filigrana testuale invisibile (Anthropic). Anthropic applica la marcatura in tutto il mondo e non solo nell'UE (Euronews). Sullo sfondo ci sono gli obblighi di trasparenza dell'articolo 50 del regolamento sull'IA, applicabili dal 2 agosto 2026, che richiedono una marcatura leggibile dalle macchine dei contenuti sintetici.

Decisiva è la riserva che Anthropic stessa formula. Una filigrana rilevata indica che un contenuto potrebbe essere stato elaborato da Claude, non è espressamente del tutto conclusiva e da sola non conferma la provenienza del contenuto (Anthropic Help Center). Si aggiunge che l'interfaccia di rilevamento è aperta soltanto a una cerchia ristretta in un'anteprima chiusa (MacRumors).

Per un'azienda che voglia documentare il proprio impiego dell'IA ne deriva un vincolo progettuale sobrio, e si tratta di una valutazione tecnica e non di una consulenza legale: la filigrana è un segnale nell'output che non vi appartiene, che di norma non potete leggere da soli e la cui forza probatoria è limitata dal fornitore stesso. Non è quindi una pista di controllo. Se deve essere ricostruibile quale modello abbia prodotto quale output a partire da quale input e in quale momento, e chi lo abbia approvato, quella prova nasce nelle vostre registrazioni. Tecnicamente è poco spettacolare, perché si tratta degli stessi registri che si tengono comunque per la ricerca degli errori e il controllo dei costi.

Il vincolo che in Germania decide l'architettura

Nei progetti tedeschi è più spesso il trattamento dei dati, e non la capacità, a decidere se un modello sia utilizzabile. Qui la situazione è documentata in modo netto e per molti sorprendente. Anthropic classifica Fable 5.1 come Covered Model. Questi modelli richiedono una conservazione dei dati di 30 giorni e non sono disponibili in regime di conservazione zero dei dati, salvo autorizzazione espressa di Anthropic. Un'organizzazione che opera in conservazione zero deve attivare deliberatamente la conservazione per un determinato workspace, altrimenti le richieste vengono respinte con un errore (Anthropic).

Due integrazioni dalla stessa fonte sono necessarie, altrimenti il quadro risulta storto. I dati conservati, secondo Anthropic, non vengono usati per l'addestramento dei modelli senza permesso esplicito. E anche in regime di conservazione zero i contenuti segnalati possono essere conservati fino a due anni. La conservazione zero inoltre non copre tutte le vie di accesso al sistema, tra cui né l'interfaccia batch né l'archivio file.

Si aggiunge la questione della regione. Sull'interfaccia di prima parte non esiste una regione di inferenza nell'UE. Il parametro della regione di inferenza accetta esattamente due valori, global e us, e l'archiviazione avviene esclusivamente negli Stati Uniti; la regione di un workspace non è più modificabile dopo la creazione (Anthropic). La via praticabile all'interno dell'UE passa da un cloud partner: Amazon Bedrock e Google Cloud offrono endpoint regionali con instradamento garantito dei dati, con un sovrapprezzo del 10 per cento rispetto agli endpoint globali, e fissano date di ciclo di vita proprie (Anthropic).

È un dato di progetto e non un verdetto sul modello. Nella pratica restano tre vie, e la scelta si compie prima del primo prototipo, non dopo. Prima: endpoint regionale presso un cloud partner, con il sovrapprezzo e con il fornitore cloud come responsabile del trattamento. Seconda: interfaccia di prima parte con conservazione attivata consapevolmente, per classi di dati in cui ciò sia difendibile. Terza: la classe di dati in questione non raggiunge affatto questo modello, perché un altro modello o un esercizio locale si occupa della parte che vede i campi sensibili. La terza via viene esaminata troppo di rado, benché nei sistemi di conoscenza e di documenti sia spesso la più pulita.

Che cosa cambia e che cosa questo modello non tocca

Detto onestamente, cambia un insieme contenuto ma prezioso di classi di compiti. Le analisi su corpus che finora fallivano per la suddivisione diventano fattibili in un solo passaggio. Le esecuzioni di agenti che prima si disgregavano al limite del contesto restano continue. E gli impianti che devono rileggere molto spesso la stessa base diventano economici grazie al prezzo di lettura della cache, purché l'assemblaggio garantisca il tasso di successo. Sono tre spostamenti reali e riguardano esattamente il lavoro che in una consulenza arriva altrimenti come fatica di routine.

Detto con la stessa onestà, ciò che resta invariato. Anche le capacità del modello hanno limiti: test di penetrazione, generazione di exploit, scansione basata su binari e compiti di ricerca biologica vengono indirizzati ai modelli Opus, e la modalità rapida non è disponibile su Fable 5.1 (Anthropic, Anthropic).

Più importanti però sono i problemi che nessun modello tocca. La qualità dei dati resta compito vostro: una finestra più ampia legge soltanto con più cura anagrafiche contraddittorie. La definizione dei processi resta compito vostro: un agente che non sa quando una questione è decisa riproduce soltanto l'ambiguità che già esisteva nel gruppo. Le autorizzazioni restano compito vostro: un modello a cui è permesso vedere tutto è un problema di protezione dei dati con un buon talento linguistico. La valutazione resta compito vostro, perché senza un insieme di casi con risposta corretta nota nessuno può dire se un cambio abbia migliorato qualcosa. E il costo dell'errore resta dove era: su un elenco di suggerimenti un errore è fastidioso, su una fattura emessa è caro. Quella distinzione decide il grado di automazione, ed è una questione aziendale.

La nostra posizione è priva di enfasi: Fable 5.1 sposta il limite di ciò che un impianto può reggere, e lo sposta in un punto che nella pratica frenava davvero. Non sposta nessuna delle domande che devono essere risolte prima. Quale di queste domande resta aperta nel vostro prossimo progetto?

Questo articolo legge l'uscita come dovrebbe leggerla un'azienda che sta decidendo se costruirci sopra: quali specifiche contano davvero, che cosa nella struttura dei prezzi è reale e che cosa è una stima modellata, che cosa si rompe a livello di interfaccia e perché la via europea verso questo modello passa da un cloud partner e non da Anthropic.

Che cosa è stato realmente pubblicato il 1° settembre

Anthropic ha pubblicato Claude Fable 5.1 il 1° settembre 2026, insieme a Claude Mythos 5.1. Secondo la stessa presentazione di Anthropic i due sono lo stesso modello con livelli di salvaguardia diversi: Fable 5.1 è disponibile in generale, Mythos 5.1 solo su invito tramite programmi di accesso fidato. La stampa specializzata conferma la data e la disponibilità su tutte le piattaforme dal giorno dell'uscita.

L'identificativo del modello è claude-fable-5-1 e, su Amazon Bedrock, anthropic.claude-fable-5-1. Viene distribuito tramite la Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry e Claude Platform su AWS. Come superfici Anthropic indica Claude Code, Claude Enterprise e Claude Platform, con impostazioni predefinite diverse per il livello di sforzo: high in Claude Code e medium in Claude Cowork e su claude.ai. Esiste un impegno sul ritiro: sulle piattaforme gestite da Anthropic il modello non verrà spento prima del 1° settembre 2027, mentre Bedrock e Google Cloud fissano date proprie.

Merita attenzione ciò che Anthropic aggiunge nella stessa documentazione. Fable 5.1 è descritto come destinato a ragionamenti impegnativi e a lavoro agentico di lungo periodo; come scelta predefinita per la maggior parte dei carichi di lavoro Anthropic continua a raccomandare esplicitamente Claude Opus 5, riservando Fable 5.1 ai casi in cui Opus 5 a livello di sforzo elevato non basta. Chi deve motivare il passaggio all'interno dell'azienda dovrebbe conoscere quella frase: il produttore stesso non raccomanda il suo nuovo modello di punta in modo generalizzato.

Le specifiche che reggono una decisione

I dati essenziali provengono dalla documentazione dei modelli di Anthropic e per una decisione di architettura pesano più di qualsiasi classifica.

Due punti meritano più di una riga di tabella. Primo, la modalità di ragionamento: Fable 5.1 ragiona in modo adattivo e continuo, e la vecchia modalità manuale con thinking.type: enabled e budget_tokens non viene più accettata. Chi porta avanti un'integrazione esistente dovrà mettere mano a quel punto del codice.

Secondo, la finestra di contesto. Un milione di token corrisponde, secondo Anthropic, a circa 555.000 parole inglesi, misurate con il tokenizer attuale introdotto con Claude Opus 4.7. Lo stesso tokenizer produce per il medesimo testo circa il 30 per cento di token in più rispetto al precedente. Un numero riferito alla finestra di contesto non è quindi un'indicazione di capacità confrontabile con leggerezza tra generazioni di modelli, tanto meno tra fornitori. Per la pianificazione del budget conta quanti token genera davvero il vostro corpus di testi, non il titolo.

Sui risultati prestazionali questo articolo resta volutamente breve, perché sono oggetto di un articolo di confronto dedicato. Solo questo, ed esplicitamente come dato del produttore: Anthropic riporta per Fable 5.1 il 52,6 per cento su Terminal-Bench-Science 0.1 contro il 24,7 per cento di Fable 5, e il 55,8 per cento su Terminal-Bench 4.0 contro il 42,0 per cento. La colonna di confronto nella tabella di Anthropic è GPT-5.6 Sol. L'attuale modello di punta di OpenAI, GPT-6 Astra, è uscito due giorni dopo questa pubblicazione e nei numeri di Anthropic non compare affatto.

Il prezzo: è cambiata esattamente una riga

La documentazione sui prezzi di Anthropic indica per Fable 5.1 i valori seguenti, in dollari statunitensi per milione di token.

Una sola riga è interessante. Su Fable 5.1 e Mythos 5.1 le letture da cache sono tariffate a 0,025 volte il prezzo di input, mentre su ogni altro modello Claude vale un fattore 0,1. È l'unica variazione di prezzo rispetto a Fable 5, la cui lettura da cache era a 1,00 dollaro statunitense per milione di token. Input e output restano invariati. L'intera finestra di contesto viene fatturata alle normali tariffe per token; non esiste un sovrapprezzo per il contesto lungo.

Anthropic quantifica il risparmio in circa il 25 per cento rispetto a Fable 5 per carichi di lavoro tipici e fino a circa il 45 per cento per lavoro fortemente agentico. Quella cifra è abbastanza importante da meritare una lettura corretta: si tratta di una stima modellata del produttore, derivata interamente dalla riga della cache, e non di un taglio di prezzo. Chi invia richieste che raramente rileggono lo stesso contesto non risparmia nulla. Chi gestisce un ciclo agentico che rilegge cento volte lo stesso prompt di sistema, la stessa base di codice e le stesse definizioni di strumenti risparmia parecchio. La differenza tra i due casi è il vostro tasso di successo della cache, e quello lo conosce soltanto il vostro profilo di carico.

Un ulteriore dettaglio per il calcolo dei costi: se l'inferenza viene fissata agli Stati Uniti tramite inference_geo: "us", si applica un fattore 1,1 su input, output, scrittura e lettura di cache.

Nel contesto competitivo questa riga della cache è l'unica vera differenza di prezzo ai vertici. Anche OpenAI indica per gpt-6-astra 10 e 50 dollari statunitensi per milione di token in input e output, ma 1,00 dollaro per l'input memorizzato in cache. Sulle letture da cache Fable 5.1 si colloca quindi a un quarto del prezzo, il che nei cicli agentici lunghi può risultare decisivo. Tutto il resto di quel confronto, compresa la questione di quali numeri di benchmark siano davvero confrontabili, si trova nell'articolo dedicato.

Che cosa cambia nell'interfaccia e che cosa si rompe

Come prova di autonomia di lungo periodo Anthropic cita un'esecuzione non presidiata di 38 ore su un problema di machine learning. Chi intende costruirci sopra dovrebbe però leggere prima l'elenco delle modifiche all'interfaccia, perché tre di esse rompono il codice esistente.

Modifiche non retrocompatibili rispetto a Fable 5:

• L'uso forzato degli strumenti restituisce un errore.
• I modelli precedenti non possono leggere i blocchi di ragionamento di Fable 5.1.
• Modificare turni di conversazione precedenti invalida i blocchi di ragionamento.

Aggiunte:

• Livello di sforzo per singolo messaggio (beta).
• Messaggi di sistema validi per un solo turno (beta).
• Aggiornamenti di avanzamento leggibili tra le chiamate agli strumenti tramite display: "updates" (beta).
• Il prezzo ridotto per le letture da cache.
• La marcatura di provenienza dei contenuti.

Per le architetture agentiche è rilevante anche il sovraccarico in token dei set di strumenti: computer_toolset_20260801 aggiunge circa 4.500 token di input per richiesta, browser_toolset_20260801 circa 6.600. È un carico di base che si presenta a ogni singola richiesta e che va incluso in qualsiasi stima dei costi. La modalità rapida, presente come anteprima di ricerca su Claude Opus 5 e Opus 4.8, non è disponibile per Fable 5.1.

Sul fronte della sicurezza, Anthropic riferisce che le salvaguardie in ambito cybersicurezza bloccano il 60 per cento in meno di falsi positivi rispetto a prima e che quelle in ambito biologico scattano l'85 per cento in meno per richieste innocue di biologia elementare. Allo stesso tempo restano escluse intere classi di attività: penetration test, generazione di exploit, scansione basata su binari e compiti di ricerca in biologia vengono reindirizzati ai modelli Opus. Fable 5.1 può identificare vulnerabilità nel software, mentre la generazione di exploit resta bloccata. I nuovi account API, inoltre, non possono più modificare manualmente il contesto precedente nelle conversazioni a più turni; Anthropic lo motiva affermando che così viene chiusa una tecnica di distillazione diffusa e documentata pubblicamente. Per i team che riscrivono cronologie di conversazione in modo programmatico si tratta di un cambiamento di comportamento con effetti diretti sulle architetture esistenti.

Residenza dei dati: presso Anthropic non esiste una regione UE

È qui che la storia ingegneristica si separa da quella di governance. La documentazione di Anthropic sulla residenza dei dati è inequivocabile: il parametro inference_geo accetta esattamente due valori, global e us. Tra le limitazioni attuali è scritto testualmente che soltanto quei due sono disponibili. Sull'API di prima parte di Anthropic non esiste una regione di inferenza nell'UE.

Lo stesso vale per i dati a riposo. La regione di un workspace viene fissata al momento della creazione, non può più essere modificata in seguito e l'unico valore disponibile sono gli Stati Uniti.

Due fonti di Anthropic sembrano qui contraddirsi, e la cosa va detta apertamente. Il centro assistenza dedicato alla privacy, aggiornato l'ultima volta il 15 giugno 2026, scrive che il traffico dei clienti può essere instradato per impostazione predefinita verso Paesi selezionati negli Stati Uniti, in Europa, in Asia e in Australia, e nello stesso testo aggiunge che i dati sono conservati negli Stati Uniti. La documentazione della piattaforma, invece, conosce soltanto le due regioni di inferenza citate. La conciliazione sta nella distinzione tra instradamento e residenza: la modalità global può toccare l'Europa, ma non è una garanzia selezionabile che trattamento e conservazione avvengano nell'UE. Chi ha bisogno di una simile garanzia qui non la trova.

Il parametro inference_geo esiste inoltre solo a partire da Claude 4.6; i modelli precedenti rispondono con un errore 400. Su Amazon Bedrock e Google Cloud non esiste, lì la regione è determinata dall'endpoint o dal profilo di inferenza. Microsoft Foundry offre invece un tipo di distribuzione con zona dati statunitense. Il parametro non è disponibile nemmeno tramite l'endpoint compatibile con l'SDK di OpenAI.

La via europea praticabile non passa dunque da Anthropic ma da un cloud partner. Bedrock e Google Cloud offrono endpoint regionali con instradamento garantito dei dati, secondo la documentazione sui prezzi di Anthropic con un sovrapprezzo del 10 per cento rispetto agli endpoint globali, e fissano date di ciclo di vita proprie. Ciò rende anche l'affermazione diffusa secondo cui Claude avrebbe residenza dei dati nell'UE perché gira a Francoforte per metà vera e, nei fatti, fuorviante: i modelli Claude possono girare in regioni UE, ma lì il responsabile del trattamento è il fornitore cloud e non Anthropic. Per la costruzione contrattuale è esattamente questa la differenza.

Covered Model: 30 giorni di conservazione sono una condizione, non un'opzione

La frase più scomoda dell'intera documentazione si trova nella pagina di Anthropic dedicata all'API e alla conservazione dei dati. Vi si legge, a proposito di Claude Fable 5.1, Mythos 5.1, Fable 5 e Mythos 5, che questi modelli richiedono una conservazione dei dati di 30 giorni e non sono disponibili in zero data retention, salvo espressa autorizzazione di Anthropic. Sono classificati come Covered Models.

In pratica significa che un'organizzazione che oggi lavora in zero data retention non può semplicemente attivare Fable 5.1. Deve abilitare esplicitamente la conservazione di 30 giorni su un workspace determinato, altrimenti l'API risponde con 400 invalid_request_error. Non è una sottigliezza di configurazione ma una decisione che in molte aziende deve passare dall'approvazione in materia di protezione dei dati prima che esista la prima riga di codice di integrazione.

Per completezza, accanto vanno messi gli impegni di Anthropic: i dati conservati, per sua stessa dichiarazione, non vengono mai usati per l'addestramento dei modelli senza permesso espresso, e il contenuto delle conversazioni non viene conservato per impostazione predefinita al di fuori dell'eccezione relativa ai Covered Models.

Anche chi ha già predisposto la zero data retention dovrebbe conoscerne i limiti, più stretti di quanto il nome lasci intendere.

• La ZDR viene abilitata per singola organizzazione su richiesta tramite il servizio commerciale e non si estende automaticamente alle organizzazioni sorelle sotto lo stesso account.
• Non copre la Batch API, la Files API, l'esecuzione di codice, Claude for Excel né le interfacce di prodotto di Claude Teams e Claude Enterprise. Claude Code tramite Claude Enterprise con ZDR è l'eccezione indicata.
• CORS non è supportato per le organizzazioni con ZDR.
• Se una chat o una sessione viene segnalata, Anthropic può conservare input e output fino a due anni, anche in regime di ZDR.

La direzione è quindi chiara e va in senso contrario alla storia dei prezzi. Fable 5.1 è nel ciclo agentico più economico di qualsiasi altro modello Claude e, sotto regole europee severe, al tempo stesso più difficile da adottare rispetto ai modelli Claude che non figurano in quell'elenco.

Articolo 50: filigrana dal primo giorno, con la riserva dello stesso Anthropic

Secondo Anthropic, Fable 5.1 e Mythos 5.1 portano una filigrana testuale invisibile dal giorno dell'uscita. L'articolo 50 del regolamento europeo sull'IA, che impone la marcatura leggibile a macchina dei contenuti sintetici, si applica dal 2 agosto 2026. Anthropic applica la marcatura in tutto il mondo e non soltanto nell'UE.

Chi intende inserire la filigrana in un processo di verifica dovrebbe conoscere la riserva dello stesso Anthropic, esposta con chiarezza nel centro assistenza: una marcatura rilevata indica che il contenuto potrebbe essere stato elaborato da Claude, è "not fully conclusive", cioè non pienamente concludente, e da sola non conferma la provenienza completa del contenuto. Non è dunque una prova in senso giuridico, e l'aspettativa di poterne accertare la paternità va oltre quanto il produttore stesso afferma. La configurazione è notevole: la marcatura è una caratteristica reale del modello, e il suo valore probatorio viene relativizzato dalla stessa azienda che la offre.

Si aggiunge la questione dell'accesso. L'API di rilevamento è in anteprima privata ed è aperta soltanto alle organizzazioni ammissibili; vengono citate autorità di regolamentazione, forze dell'ordine, media, verificatori di fatti, ricerca, istituzioni educative e organizzazioni della società civile nell'UE. Un'azienda che volesse verificare da sé i testi in arrivo attualmente per questa via non può farlo.

Il quadro normativo circostante, così come lo descrivono gli organismi che lo pubblicano: l'applicazione ai modelli di IA per finalità generali decorre anch'essa dal 2 agosto 2026, con sanzioni fino a 15 milioni di euro o al 3 per cento del fatturato annuo mondiale per i fornitori non conformi di tali modelli, indipendentemente dal fatto che abbiano firmato il codice di condotta. Il codice di condotta della Commissione europea vincola i firmatari a un modulo di trasparenza pubblicato, a una metodologia di valutazione dei rischi sistemici e a un quadro di conformità in materia di diritto d'autore, con conservazione della documentazione per almeno dieci anni. Questi obblighi ricadono sui fornitori di modelli. Ciò che ne deriva per la vostra azienda dipende dal vostro ruolo nella catena di fornitura ed è una domanda per i vostri consulenti legali, non per un articolo specialistico.

Che cosa significa per una decisione in Germania

Nel complesso l'uscita restituisce un quadro insolitamente nitido, proprio perché le due storie puntano in direzioni opposte. Sul piano tecnico Fable 5.1 è la scelta più economica per cicli agentici lunghi in cui viene letto continuamente lo stesso contesto. Sul piano normativo è un modello che senza conservazione di 30 giorni non si riesce nemmeno ad avviare.

Quattro domande dovrebbero perciò trovare risposta prima che l'integrazione cominci.

1. Quanto è davvero alto il vostro tasso di successo della cache? L'intero risparmio dipende da quell'unico indicatore. Misuratelo su un profilo di carico reale prima di mettere a budget il 25 per cento.
2. La vostra approvazione in materia di protezione dei dati regge una conservazione di 30 giorni? In caso contrario Fable 5.1 non è un'opzione fino a un'autorizzazione espressa di Anthropic, e la questione non si aggira per via tecnica.
3. Attraverso quale endpoint passa l'inferenza? Se serve un trattamento nell'UE, la strada passa da Bedrock o Google Cloud, con un sovrapprezzo del 10 per cento rispetto agli endpoint globali, con il fornitore cloud come responsabile del trattamento e con le sue date di ciclo di vita.
4. Basta Opus 5? Anthropic stessa raccomanda Opus 5 come scelta predefinita, e Opus 5 non figura nell'elenco dei Covered Models. Una parte delle questioni di governance descritte qui lì non si pone in questa forma.

Niente di tutto questo è un argomento contro Anthropic. Fable 5.1 è un modello solido, la modifica sulla cache è un miglioramento reale per il lavoro agentico, e il fatto che i dati scomodi siano consultabili in modo pulito nella documentazione di Anthropic depone a favore del fornitore e non contro di esso. È un argomento per invertire l'ordine: chiarire prima a quali condizioni i vostri dati possono essere trattati, poi scegliere il modello. Che cosa Fable 5.1 renda davvero nel lavoro quotidiano è trattato in un articolo dedicato alle capacità nella pratica; come si colloca nel confronto diretto con GPT-6 Astra, in un altro.

La tabella che quasi tutti stanno pubblicando è viziata

La frase più frequente nella copertura attuale suona più o meno così: i benchmark di Anthropic collocherebbero Claude Fable 5.1 davanti a GPT-6 Astra. Questa frase è falsa, e per confutarla basta un calendario.

Anthropic ha pubblicato la propria tabella di benchmark il 1° settembre 2026. La colonna di confronto vi reca la dicitura GPT-5.6 Sol. GPT-6 Astra è entrato in anteprima limitata il 3 settembre e in disponibilità generale il 4 settembre. Anthropic dunque non solo non ha misurato Astra: non poteva misurarla, perché il modello non era pubblico alla data di pubblicazione.

Chi legge la riga su Terminal-Bench 4.0, dove il 55,8% di Fable 5.1 si contrappone al 37,3%, e prende quel 37,3% per Astra, sta confrontando il modello attuale di Anthropic con il predecessore del concorrente. Non è un errore di arrotondamento, è un'altra affermazione. Ed è esattamente la lettura errata che oggi si propaga più rapidamente tra aggregatori e riassunti.

Il valore di questo articolo sta quindi meno nelle cifre e più nella cernita: quali confronti reggono, quali no e da che cosa si riconosce la differenza.

Che cosa si confronta davvero uno a uno

Resta un nucleo piccolo ma pulito. Tutte le righe della tabella seguente provengono dalla documentazione di modello di Anthropic, dalla pagina dei prezzi di Anthropic e dalla documentazione per sviluppatori di OpenAI su gpt-6-astra, consultate il 10 settembre 2026. Sono dichiarazioni di ciascun fornitore sul proprio prodotto, nella stessa unità, senza quadri di misurazione interposti.

Una riserva riguarda la riga sulla scrittura di cache: Anthropic vende due durate di conservazione, cinque minuti e un'ora, mentre OpenAI non pubblica alcuna fascia equivalente. I due importi di 12,50 USD sono vicini, ma non perfettamente paralleli.

La riga economicamente interessante è la lettura di cache. Un fattore quattro a favore di Anthropic sembra una voce secondaria, ma nel lavoro agentico non lo è: lì lo stesso contesto, repository, istruzione di sistema e descrizioni degli strumenti, viene riletto più e più volte lungo centinaia di passaggi. Anthropic quantifica essa stessa il risparmio che ne deriva in circa il 25% rispetto a Fable 5 per carichi tipici e fino a circa il 45% per carichi fortemente agentici. Quella cifra è un calcolo modellistico del fornitore, non un taglio di prezzo: i prezzi di listino di ingresso e uscita sono invariati, e un carico con pochi riscontri di cache non risparmia praticamente nulla.

Altre due voci appartengono a qualsiasi calcolo. La Batch API di Anthropic dimezza entrambe le direzioni, a 5 USD in ingresso e 25 USD in uscita per milione di token. E fissare l'inferenza negli Stati Uniti presso Anthropic comporta, secondo la documentazione di Anthropic sulla residenza dei dati, un moltiplicatore di 1,1 su ingresso, uscita, scritture e letture di cache.

Terminal-Bench 4.0: l'unica cifra con un vero riscontro incrociato

Una riga di benchmark merita qui una fiducia particolare, per una ragione raramente spiegata.

Il 1° settembre 2026 Anthropic indica per Claude Fable 5.1 su Terminal-Bench 4.0 il 55,8%. Nei risultati riportati da OpenAI per GPT-6 Astra, ripresi da DataCamp il 3 settembre 2026 e lì espressamente qualificati come dati del fornitore, Astra si colloca al 57,7% e Fable 5.1 compare con un 55,8% invariato.

Entrambi i fornitori arrivano quindi in modo indipendente alla stessa cifra per il modello dell'altro campo. È il riscontro singolo più solido disponibile in tutto questo confronto. Un fornitore ha scarso interesse a sopravvalutare un concorrente, e quando due parti con interessi opposti riportano la stessa cifra, ciò depone a favore di una cifra che sopravvive all'allestimento invece di essere una misurazione interna.

Restano tuttavia due limiti. Primo, nessuna delle due pubblicazioni indica quale harness, quale scaffold e quale livello di effort siano stati usati. Secondo, il divario di 1,9 punti percentuali è abbastanza piccolo da poter derivare proprio da quei fattori. La lettura difendibile è quindi: su Terminal-Bench 4.0 i due modelli sono vicini secondo i dati di entrambi i fornitori, con un lieve vantaggio di Astra secondo la misurazione di OpenAI.

Che cosa non è confrontabile, e perché

La parte maggiore delle cifre pubblicate non appartiene a una tabella comune. Non è formalismo, è la differenza tra una base decisionale e un muro di numeri.

• OSWorld 2.0. Anthropic indica per Fable 5.1 due valori, 77,9% con credito parziale e 41,7% con valutazione rigorosa. Sul versante OpenAI compare per Astra un unico valore del 72,6%, senza indicazione della modalità di valutazione. Contrapporre 72,6 a 77,9 è infondato tanto quanto contrapporlo a 41,7. Finché la modalità di valutazione non coincide, qui non c'è un confronto ma solo una selezione.
• Finestra di contesto. Anthropic indica 1.000.000 di token, OpenAI 1.050.000 con un ingresso massimo di 922.000 token. Queste cifre non sono una misura di capacità sulla stessa scala, perché un token significa cose diverse a seconda del tokenizzatore. Anthropic scrive essa stessa che il tokenizzatore attuale produce per lo stesso testo circa il 30% di token in più rispetto al proprio precedente. Non esiste pubblicamente alcun dato tra fornitori sui token per parola, quindi la domanda su quale modello contenga più testo non è risolvibile a partire da fonti aperte.
• AutomationBench. Anthropic pubblica il 31,4% per Fable 5.1. Nel proprio annuncio OpenAI rivendica il primo posto sullo stesso benchmark, ma non vi indica alcuna cifra. Semplicemente non c'è nulla da confrontare.
• Righe in cui la cifra su Claude non proviene da Anthropic. Per ScreenSpot-Pro, FrontierMath Tier 4 v2, ExploitBench, ARC-AGI-3, GPQA Diamond e FrontierCode 1.1 esistono solo valori del versante OpenAI. La cifra su Claude in quelle righe è la misurazione di Claude effettuata da OpenAI e, in più casi, una misurazione di Claude Fable 5 o Claude Opus 5, non di Fable 5.1. Attribuirla ad Anthropic significa citare la fonte sbagliata e, in parte, anche il modello sbagliato.
• Livelli di effort. Entrambi i fornitori consentono un impegno di calcolo variabile per richiesta. In Anthropic già l'impostazione predefinita cambia a seconda della superficie: high in Claude Code, medium in claude.ai e Claude Cowork. Artificial Analysis misura ai livelli «max» e «xhigh». Una cifra di benchmark senza livello di effort dichiarato non è confrontabile con una cifra ottenuta a un livello diverso. Non è una sottigliezza: è la ragione più probabile per cui la stessa classifica mostra tre risultati su tre siti.

Un caso particolare merita un avvertimento: il 99,9% che circola per Astra su ARC-AGI-3 reca nella fonte la precisazione «adapter harness» e si affianca a un 7,8% del modello precedente. Un salto di circa 92 punti attraverso un cambio di harness descrive prima l'harness e solo dopo il modello. Quella cifra non appartiene ad alcun titolo.

Le classifiche di terze parti si contraddicono apertamente

Chi diffida delle cifre dei fornitori si rivolge alle classifiche indipendenti. In questo caso non aiuta, perché le classifiche si contraddicono tra loro, e per di più sullo stesso identico indice.

Artificial Analysis, nel proprio articolo del 3 settembre 2026, indica per l'Intelligence Index: GPT-6 Astra 61, GPT-5.6 Sol 61, Claude Fable 5.1 66, quest'ultimo al livello di effort massimo con una configurazione di ripiego che non è l'impostazione predefinita dell'API. BenchLM riporta lo stesso indice in modo diverso a settembre 2026: GPT-5.6 Sol guida con il 58,9% e Fable 5.1 si ferma al 53,7%. llm-stats, consultato il 10 settembre 2026, indica Fable 5.1 a 56,8, Astra a 54,7 e Claude Opus 5 a 54,1.

Tre fonti, un indice, tre ordinamenti. Non possono essere tutti aggiornati. Tra le cause plausibili vi sono date di rilevazione diverse, impostazioni di effort diverse e la confusione tra punti e percentuali. La conseguenza pratica è semplice: un valore dell'Intelligence Index senza l'indicazione del sito, della data e del livello di effort non è un'informazione. Artificial Analysis segnala del resto essa stessa risultati contrastanti, tra cui un calo di circa 80 punti Elo su GDPval-AA v2.

Resta l'arena. Neanche lì c'è qualcosa da ricavare: né Claude Fable 5.1 né GPT-6 Astra hanno una posizione in classifica su LMArena nelle istantanee di settembre 2026 raggiungibili qui, perché l'Elo d'arena richiede volume di voti e accumula settimane di ritardo rispetto alle uscite di frontiera. Anche se quei valori esistessero, sarebbero lo strumento sbagliato per questa decisione. La preferenza umana in confronto cieco misura la qualità percepita delle risposte su prompt scelti da chi vota, reagisce fortemente alla formattazione e alla prolissità e dice poco del lavoro agentico su orizzonti lunghi. Per un agente di programmazione o una piattaforma di lavoro della conoscenza non è il metro su cui allineare un acquisto.

FrontierCode 1.1: la cifra che gioca contro il fornitore che la pubblica

In questo confronto c'è una riga che pesa più delle altre, per una ragione metodologica. Su FrontierCode 1.1 GPT-6 Astra si colloca, secondo i risultati riportati dalla stessa OpenAI, al 53,3%, dunque dietro Claude Fable 5 con il 53,5%.

Due precisazioni sono qui obbligatorie. Il valore di confronto riguarda Claude Fable 5, non Fable 5.1, e Anthropic non ha pubblicato alcun valore proprio per Fable 5.1 su questo benchmark. Il divario è di 0,2 punti percentuali e rientra quindi in qualsiasi dispersione di misura plausibile.

Ciononostante è il tipo di cifra più degno di fiducia che un annuncio di prodotto possa contenere. Un fornitore che pubblica una riga in cui la propria nuova ammiraglia resta dietro a un modello altrui non ha alcun incentivo di marketing a farlo. Chi vuole valutare quanto regga una tabella di benchmark dovrebbe innanzitutto cercare se righe di questo tipo vi compaiano. Una tabella in cui il fornitore che la pubblica vince ogni singola riga non è una misurazione, è una selezione.

La direzione si inverte: residenza dei dati nell'UE e retention zero

Fin qui Anthropic è avanti su prezzo ed economia della cache ed è più o meno alla pari sui benchmark. Sulla governance dei dati il quadro si inverte completamente, e per un'azienda tedesca quella è la colonna che cambia un'architettura.

Sul versante Anthropic questo si legge nella documentazione della stessa azienda. Il parametro inference_geo accetta esattamente due valori, global e us, e come regione di archiviazione di un workspace è selezionabile soltanto us, fissata al momento della creazione. Il versante della conservazione è ancora più esplicito: Anthropic designa Fable 5.1 e Mythos 5.1 (oltre a Fable 5 e Mythos 5) come Covered Models che richiedono una conservazione dei dati di 30 giorni e non sono disponibili in regime di retention zero salvo autorizzazione espressa di Anthropic. Un'organizzazione soggetta a ZDR deve attivare la conservazione di 30 giorni per uno specifico workspace, altrimenti la richiesta viene respinta.

Sul versante OpenAI, la documentazione per sviluppatori sul trattamento dei dati afferma che l'Europa (SEE e Svizzera) supporta sia l'archiviazione regionale sia l'elaborazione regionale tramite eu.api.openai.com, configurata per progetto, con le regioni fuori dagli Stati Uniti che richiedono un'approvazione per i controlli di monitoraggio degli abusi e un addendum di conservazione modificata. La stessa pagina elenca gli endpoint idonei allo ZDR, tra cui /v1/chat/completions e /v1/responses, ed esclude espressamente Assistants, Threads, Vector Stores, il fine-tuning e Batches.

Qui la precisione conta più di una formulazione levigata: nessuna fonte trovata afferma positivamente che GPT-6 Astra sia idonea allo ZDR. Ciò che è documentato è che quegli endpoint supportano lo ZDR e che per gpt-6-astra non è pubblicata alcuna esclusione specifica di modello. L'assenza di una restrizione, però, non è un permesso. Chi vi fonda un'architettura dovrebbe farselo confermare contrattualmente anziché dedurlo da una lacuna documentale. In Anthropic la situazione è inequivocabile nella direzione opposta, perché l'esclusione è scritta nero su bianco.

Va corretta anche una frase molto ripetuta: «Claude ha la residenza dei dati nell'UE perché gira su AWS Francoforte». È vero esattamente quando acquisite Claude tramite un cloud partner come Amazon Bedrock o Google Cloud, dove è il fornitore cloud a fissare la regione e a essere responsabile del trattamento. Per l'API propria di Anthropic non vale. Per un instradamento regionale garantito Anthropic rimanda essa stessa agli endpoint regionali dei cloud partner, con un sovrapprezzo del 10% rispetto agli endpoint globali. Per una verifica GDPR quella distinzione è il punto centrale, perché determina con chi viene stipulato il contratto di trattamento.

Articolo 50: una differenza dimostrabile solo a metà

Dal 2 agosto 2026 si applicano gli obblighi di trasparenza dell'articolo 50 del regolamento sull'IA, che impongono una marcatura leggibile dalle macchine dei contenuti sintetici. Anthropic dichiara che Fable 5.1 e Mythos 5.1 recano fin dal primo giorno una filigrana invisibile nel testo, e applica tale marcatura in tutto il mondo e non solo nell'UE. Per quanto arrivano le fonti disponibili, è una differenza reale.

Quella frase ha però bisogno di entrambe le metà. Non è stata trovata alcuna fonte che dica se l'output testuale di GPT-6 Astra sia marcato. L'approccio documentato di OpenAI alla provenienza, i Content Credentials C2PA insieme a SynthID, riguarda immagini e audio; le pagine raggiungibili non dicono nulla sul testo. Da questa lacuna non discende che OpenAI non marchi il testo. Per questo non lo affermiamo. OpenAI pubblica separatamente indicazioni per i clienti sul regolamento sull'IA.

E anche la filigrana di Anthropic regge meno di quanto il termine suggerisca. Anthropic scrive nella propria guida che un contrassegno rilevato indica che un contenuto potrebbe essere stato elaborato da Claude, non è pienamente conclusivo e da solo non conferma la provenienza del contenuto. L'API di rilevamento corrispondente è inoltre in anteprima privata per organizzazioni selezionate. Come tassello di un'argomentazione di conformità la filigrana è utilizzabile; come mezzo di prova no.

Che cosa significa per una decisione in Germania

Se da questo confronto portate via una sola regola, sia questa: con due modelli di frontiera vicini sulle cifre difendibili e con prezzi di listino identici, una riga di benchmark decide raramente. Il divario su Terminal-Bench 4.0 è di 1,9 punti percentuali senza harness dichiarato. Su FrontierCode 1.1 è di 0,2 punti in direzione opposta, contro un modello Claude più vecchio. Divari simili si spostano con la release successiva e non cambiano alcuna architettura.

Ciò che cambia un'architettura sta nella colonna della governance. Un'organizzazione vincolata alla retention zero non può impiegare Claude Fable 5.1 tramite l'API propria di Anthropic senza autorizzazione espressa, per quanto buono sia il modello. Un'organizzazione che esige inferenza all'interno dell'UE trova quella via presso Anthropic solo attraverso un cloud partner, con il relativo sovrapprezzo e un diverso responsabile del trattamento nel contratto. Al contrario, il vantaggio di Anthropic sulla lettura di cache è reale e cresce con la quota di lavoro agentico in cui lo stesso contesto viene letto centinaia di volte.

In pratica: chiarite prima gli obblighi, poi i costi e solo alla fine i benchmark. Nell'ordine inverso costruirete un sistema che misura bene e non regge alla conversazione sulla protezione dei dati. E per ogni cifra che qualcuno vi mostra, verificate tre cose: chi l'ha riportata, quando e a quale livello di effort.

Che cosa abbia cambiato la pubblicazione in sé per un'azienda tedesca lo trattiamo nel nostro articolo su Claude Fable 5.1. Come si comporta il modello nel lavoro di progetto in corso lo trattiamo in capacità nella pratica. E se la risposta alla domanda di governance è che i dati non devono affatto uscire dall'azienda, la strada passa per il bilanciamento tra on-premise e cloud, non per una classifica.

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.

COSA LA RICERCA VISIVA DELIBERATAMENTE NON FORNISCE

I modelli di retrieval visivo trovano la pagina giusta, anche in una scansione difficile. Ma restituiscono un'immagine, non un testo. Da lì non potete copiare facilmente una riga, non potete impostare una ricerca full-text sull'archivio, non potete costruire una traccia di verifica leggibile da una macchina. Per tutto questo serve testo riconosciuto. Non è un punto debole del nuovo approccio, ma una divisione del lavoro consapevole: ricerca sull'immagine, estrazione del testo tramite OCR, ogni stadio per ciò che sa fare meglio.

COSA SA FARE PADDLEOCR-VL

Baidu ha presentato con PaddleOCR-VL un modello OCR aperto che raggiunge risultati di punta con soli 0,9 miliardi di parametri (Progetto). Riconosce testo, tabelle, formule e diagrammi in 109 lingue e ricostruisce la struttura semantica di un documento. Sul benchmark OmniDocBench v1.5 è al primo posto con circa il 94,5% di accuratezza. È rilasciato con licenza Apache 2.0, quindi liberamente utilizzabile a scopi commerciali e utilizzabile in locale. Per una PMI questo significa: riconoscimento testuale solido senza canone ricorrente e senza fuga di dati.

L'ARCHITETTURA IBRIDA

In pratica le due strade procedono in parallelo. La ricerca visiva trova rapidamente le pagine rilevanti, fedeli al layout. Dove da lì deve nascere testo vero e proprio, ad esempio per una voce di fattura, una clausola contrattuale da citare o una registrazione nell'ERP, subentra l'OCR proprio su quelle poche pagine. Non serve far passare l'intero archivio attraverso l'OCR, ma solo ciò che la ricerca ha già segnalato come rilevante. Questo mantiene la pipeline snella ed evita che errori di OCR si infiltrino fin dall'inizio nella ricerca.

LA LINEA PRAGMATICA

L'aut aut è qui l'atteggiamento sbagliato. La ricerca visiva migliora il reperimento, l'OCR migliora l'elaborazione successiva. Chi comprende entrambi come strumenti con compiti chiari costruisce una base di conoscenza più solida di chi punta dogmaticamente su un solo lato. Come i singoli elementi si combinano, dall'encoder al database vettoriale, è descritto nella panoramica dello stack.

Per un'azienda di medie dimensioni che ogni giorno elabora contratti, manuali tecnici e fatture di più pagine, questa è la notizia più interessante. Non è che il riconoscimento del testo sia di qualche punto migliore, ma che un documento di 80 pagine non debba più essere tagliato a pezzi e ricomposto, e che per farlo nessun documento debba lasciare l'azienda.

COSA FA DIVERSAMENTE UNLIMITED-OCR

Il nucleo è un'attenzione modificata nel decoder, che mantiene costante la memoria. I modelli OCR classici basati su Transformer lasciano crescere la cosiddetta KV cache con la lunghezza del documento. Più lungo è il PDF, più memoria serve, finché a un certo punto non entra più in un'unica elaborazione.

Unlimited-OCR sostituisce questa parte con la Reference Sliding Window Attention (R-SWA). In questo modo la KV cache resta costante, indipendentemente dalla lunghezza del documento. È esattamente questo il senso del termine one-shot long-horizon parsing: un documento lungo viene letto in un solo passaggio, invece di essere scomposto in sezioni per poi riassemblare i risultati.

Degno di nota è il percorso di addestramento. Il team non è partito da zero, ma ha continuato l'addestramento a partire dal checkpoint di DeepSeek-OCR: con l'encoder congelato e solo il decoder adattato in circa 4.000 passaggi. Il modello si colloca così in linea diretta con DeepSeek-OCR, che abbiamo già inquadrato nel contesto dello stack. Codice e pesi sono disponibili apertamente su GitHub.

PERCHÉ LA KV CACHE COSTANTE CONTA

Il vero problema con i documenti lunghi non è la singola pagina, ma la coerenza tra le pagine. Se un modello taglia un documento di 60 pagine in blocchi da dieci pagine, si perde esattamente ciò che conta nella quotidianità B2B: una tabella che prosegue oltre il salto di pagina, una clausola che si riferisce a una sezione precedente, una voce il cui riferimento si trova venti pagine prima.

Una KV cache costante permette di mantenere l'intero documento in un unico contesto. La memoria non cresce con la lunghezza, quindi la struttura resta intatta su tutte le pagine. Di riflesso il processo diventa anche più veloce: Baidu indica, in modalità base, 5.580 token al secondo contro 4.951 di DeepSeek-OCR, e con un limite di output di 6.000 token il divario è di circa il 35 per cento.

Quanto all'accuratezza, Unlimited-OCR raggiunge su OmniDocBench v1.5 93,23 punti, 6,22 in più rispetto alla base DeepSeek-OCR, e su v1.6 93,92 punti. Questi sono i numeri del paper. Sui vostri documenti conta alla fine come il modello gestisce le vostre tabelle, timbri e moduli, non la media di un set di test pubblico. Un fenomeno correlato è quello degli LLM subquadratici, che rendono il contesto lungo più economico on-premise.

DOVE CAMBIA QUALCOSA NELLE PMI

Il valore si genera dove documenti lunghi e strutturati devono diventare dati puliti e ricercabili. Alcuni esempi concreti:

• Contratti e accordi quadro. Rimandi incrociati e allegati restano leggibili nel loro contesto, invece di frammentarsi ai confini dei blocchi.
• Manuali tecnici e norme. Documenti lunghi con figure, tabelle e sezioni numerate in un solo passaggio.
• Fatture e ricevute di più pagine. Un testo estratto in modo pulito è il presupposto per l'elaborazione strutturata successiva, ad esempio verso la fattura elettronica.
• Archivi e pratiche. Fondi documentali finora disponibili solo come scansione diventano leggibili dalla macchina, senza doverli affidare a un servizio cloud.

In quasi tutti i casi l'OCR non è l'obiettivo, ma il primo passo. Un testo analizzato in modo pulito è la base per una base di conoscenza con RAG: quanto migliore è il parsing, tanto meglio la ricerca troverà in seguito il punto giusto.

OCR O RICERCA VISIVA NEI DOCUMENTI?

Non ogni compito documentale richiede il riconoscimento classico del testo, ed è una valutazione onesta da fare. Esiste ormai un intero filone che non converte affatto i documenti in testo, ma li interroga come immagini, con modelli come ColPali o ColQwen. Abbiamo descritto a parte questo approccio senza OCR.

La regola pratica che si è dimostrata valida per noi:

• Vi servono i caratteri effettivi (importi di fattura, clausole contrattuali, estrazione strutturata, trasferimento a un altro sistema): allora l'OCR è quasi indispensabile, e un modello come Unlimited-OCR è qui particolarmente valido.
• Vi serve il punto giusto, non il testo completo (rispondere a una domanda su un archivio ampio, ritrovare un'immagine): allora la ricerca visiva nei documenti può essere la via più diretta.

Spesso valgono entrambe le cose insieme. Unlimited-OCR rende la parte OCR di questo stack più economica e più affidabile sui documenti lunghi.

COSA VERIFICHEREI PRIMA DELLA MESSA IN PRODUZIONE

Un buon valore di benchmark è un motivo per testare il modello, non un motivo per metterlo in produzione. Prima di inserire Unlimited-OCR in un processo cliente, verificherei quattro cose:

🔸 Documenti tedeschi e scrittura a mano. I numeri del benchmark dicono poco sui moduli tedeschi, sugli atti vecchi o sulle annotazioni manoscritte. Questo va verificato su un set di test proprio, fatto di documenti reali.

🔸 Tabelle e layout. Nei documenti B2B è la fedeltà di tabelle e colonne a determinare l'utilità. Qui vale la pena il confronto diretto con lo stack attuale.

🔸 Hardware ed esercizio. 3B come MoE con circa 500M di parametri attivi è realistico on-premise. Cosa questo significhi concretamente in termini di memoria GPU e throughput va misurato prima del rollout, non stimato.

🔸 Licenza e provenienza. La licenza MIT consente l'uso commerciale on-premise senza note a piè di pagina. Il fatto che la traccia del modello porti a uno degli autori di DeepSeek-OCR è un segnale di qualità, ma non sostituisce la verifica propria.

Ciò che trovo davvero interessante in questa pubblicazione non è tanto il modello in sé quanto la direzione: documenti lunghi in un solo passaggio, abbastanza piccoli per il proprio data center, con una licenza che non limita nessuno. È esattamente lì che l'elaborazione documentale nelle PMI sta diventando concreta. Quale dei vostri documenti fareste elaborare per primo?

OLTRE IL PROMPT

Il prompt engineering perfeziona la domanda. Il context engineering progetta l'ambiente in cui il modello decide. Per un'attività una tantum basta un buon prompt. Per un agente che opera su molti passaggi, legge strumenti e porta con sé la memoria, il prompt è solo una piccola parte di ciò che il modello vede. Il resto, ciò che recuperate, ciò che ricordate, quali strumenti rendete disponibili e come, è contesto, e determina molto di più il risultato. Ecco perché estendere un harness agentico è in gran parte lavoro sul contesto.

I QUATTRO SCHEMI DI FALLIMENTO CONTRO CUI SI PROGETTA

La maggior parte dei fallimenti degli agenti risale a uno di quattro problemi di contesto:

• Sovraccarico di contesto. Troppo nella finestra. Il modello perde il filo, e costi e latenza aumentano. Più contesto non significa contesto migliore.
• Avvelenamento del contesto. Un fatto sbagliato o obsoleto entra nella finestra, e il modello lo tratta come verità. Un singolo frammento recuperato male può far deragliare una risposta.
• Gestione dei token. La finestra è finita. Senza un piano su cosa mantenere e cosa scartare, il dettaglio importante viene spinto fuori dal rumore.
• Memoria obsoleta. Gli agenti a esecuzione prolungata accumulano contesto non più valido e agiscono di conseguenza.

Nominare il fallimento è metà della soluzione. Ciascuno ha una contromisura concreta.

PRATICHE CHE REGGONO

Alcuni schemi ricorrono nelle architetture che restano affidabili:

1. Recuperare, non riversare. Estraete i pochi passaggi rilevanti con un buon retrieval, invece di copiare tutto dentro. È tutto il senso del RAG, ed è context engineering applicato ai dati.
2. Sfoltire in modo continuo. Applicate una modifica basata su regole nell'harness per mantenere snella la finestra: scartate ciò che un passaggio non richiede più.
3. Riassumere le cronologie lunghe. Sostituite una trascrizione lunga con un riassunto fedele, prima che spiazzi il compito.
4. Iniziare in modo semplice, scalare in base alle necessità. Aggiungete memoria e strumenti solo quando un fallimento reale lo richiede, non per impostazione predefinita.

L'istinto di aggiungere di più è la trappola. La disciplina sta nel togliere.

PERCHÉ QUESTO È IL VERO ENGINEERING

Un modello più grande raramente risolve un problema di contesto; fallisce solo in modo più costoso. Il lavoro che porta un agente dalla demo all'affidabilità è quasi esclusivamente lavoro sul contesto: cosa vede, quando, e cosa deve dimenticare. Con input molto lunghi conta anche l'architettura del modello, ed è qui che entrano in gioco gli approcci subquadratici, ma per la maggior parte dei team il guadagno sta nel contesto, non nei parametri.

IL MECCANISMO, IN BREVE

Il RAG semplice incorpora la vostra query, trova i passaggi più vicini e risponde a partire da questi. RAG-Fusion inserisce due passaggi prima di questo. Primo, un modello scrive una manciata di query alternative che esprimono la stessa cosa da angolazioni diverse. Secondo, effettua il recupero per tutte e fonde le liste classificate tramite Reciprocal Rank Fusion, che premia i passaggi che si posizionano bene su più query invece che su una sola. La risposta viene poi scritta a partire da questo insieme fuso e riclassificato.

PERCHÉ IL PASSAGGIO DI FUSIONE CONTA

Una singola query è una singola ipotesi su come la risposta è formulata nei vostri documenti. Gli archivi reali usano sinonimi, abbreviazioni e formulazioni diverse per la stessa cosa. Ponendo la domanda più volte e premiando ciò che si posiziona costantemente in alto, RAG-Fusion fa emergere il passaggio che una singola formulazione avrebbe mancato. Reciprocal Rank Fusion è qui il cavallo di battaglia silenzioso: combina le liste senza bisogno di score comparabili, motivo per cui compare anche in architetture ibride e a late interaction come quelle dietro Qdrant e ColQwen.

QUANDO AIUTA E QUANDO DANNEGGIA

RAG-Fusion giustifica il suo costo con domande ambigue o dense di terminologia, dove una singola formulazione è una scommessa debole. Costa di più: più recuperi e un passaggio di generazione per domanda, quindi non è latenza gratuita. E ha un vero schema di fallimento. Se le varianti di query generate si discostano da ciò che intendevate realmente, portano dentro passaggi fuori tema e la risposta va alla deriva. Il rimedio è mantenere le query generate strettamente ancorate all'intento originale e misurare, non presumere che il recall sia aumentato.

DOVE SI COLLOCA TRA LE OPZIONI

RAG-Fusion è una delle diverse strade per migliorare il retrieval, non un sostituto di un buon retrieval. Prima di ricorrervi, assicuratevi che le basi reggano: chunk puliti, un modello di embedding solido e un vector store adatto al compito. Per documenti visivamente densi, la leva più grande è spesso il retrieval visivo piuttosto che più varianti di query. Usate F-RAG dove la domanda è davvero ambigua e il guadagno di recall vale le chiamate aggiuntive.

IL PROBLEMA NON È MAI STATO ANIMARE, MA LA CONSEGNA

Finora il movimento della UI nasceva al di fuori di Figma. La designer lo costruiva in un secondo strumento, esportava un video o una descrizione, e lo sviluppo doveva ricostruire curve e tempistiche, spesso a occhio. In questo passaggio si perde precisione: una curva di easing diventa un'idea approssimativa, un timing diventa una stima. È proprio questa rottura, non la mancanza di strumenti di animazione, ad aver reso il movimento incoerente in molti prodotti.

COSA PORTA CONCRETAMENTE FIGMA MOTION

Tre cose cambiano il flusso di lavoro in modo sensibile:

• Timeline nel canvas. Keyframe, preset e controllo del movimento si trovano dove il design già vive. Nessun passaggio a un secondo strumento.
• Il movimento come parte del design system. Un componente viene animato una volta, e il movimento si propaga come colore o tipografia su ogni schermata e ogni file. Questo è il punto che impone la coerenza invece di sperarla.
• Consegna leggibile. Nel Dev Mode l'intera timeline è visibile: ogni valore di timing, ogni curva di easing, ogni keyframe. L'esportazione avviene come CSS, JSON o React pronto per il framework, oltre a MP4, WebM, SVG animato e GIF.

Così lo sviluppo legge il movimento invece di interpretarlo. Questo è il vero cambiamento.

DOVE STA IL PUNTO DEBOLE

Uno strumento integrato non è automaticamente quello giusto per ogni caso. Un lavoro di motion complesso e narrativo, per esempio un elaborato brand film, resta compito di strumenti specializzati. Figma Motion punta sull'animazione di interfaccia: stati, transizioni, microinterazioni, cioè esattamente ciò di cui il prodotto ha bisogno ogni giorno e che finora soffriva al punto di rottura della consegna. Per questa classe di movimento l'integrazione è il guadagno. Per tutto ciò che va oltre, la cassetta degli attrezzi resta mista.

PER CHI VALE LA PENA GUARDARE

Chi mantiene un prodotto con pattern di UI ricorrenti ne trae il beneficio maggiore: il movimento definito una volta resta coerente, e lo sviluppo riceve valori esatti invece di approssimazioni. Il movimento non è quindi un decoro, ma parte della comprensibilità di un'interfaccia, un punto che approfondiamo in il ruolo chiave della UX nello sviluppo software. Figma Motion rende finalmente questa parte modificabile in un unico posto.

TRE RILASCI, DETTO SEMPLICEMENTE

Ognuno di questi è uscito a giugno 2026 nel giro di due settimane dall'altro, ed è un tipo di cosa diverso ogni volta. Vale la pena essere precisi, perché due di loro vengono descritti male in modo diffuso.

GLM-5.2, di Z.ai a Pechino, è uscito il 17 giugno. È un modello open-weight mixture-of-experts, circa 750 miliardi di parametri con circa 40 miliardi attivi, un contesto di un milione di token e, punto decisivo, una licenza MIT con i pesi pubblicati su HuggingFace.

Sakana Fugu, di Sakana AI a Tokyo, è uscito il 22 giugno. Non è un modello convenzionale, e la classificazione abituale è fuorviante: Fugu è un orchestratore addestrato che chiama un pool di altri modelli e ne sintetizza il lavoro. È disponibile solo via API, offerto come endpoint compatibile con OpenAI.

Claude Fable 5, di Anthropic negli Stati Uniti, è uscito il 9 giugno. Il secondo errore comune è classificare Fable come un livello veloce o creativo. È il modello di punta, il più capace tra quelli rilasciati pubblicamente da Anthropic, con controllo di sicurezza, solo in cloud, a 10 e 50 dollari per milione di token. I suoi numeri nei benchmark sono forti; per questo articolo, allo stesso tempo, sono secondari.

L'UNICO CONFRONTO CHE SOPRAVVIVE ALL'APPROVVIGIONAMENTO

Tralasciate la classifica e mettetele a confronto sulle dimensioni di cui un acquirente B2B tedesco è realmente responsabile. Il quadro è chiaro, e non si tratta di stabilire quale sia il più intelligente.

Sulla tabella vanno inserite due riserve oneste. Il percorso standard di GLM-5.2, l'API di Z.ai, è soggetto alle leggi cinesi sui dati con le loro clausole di accesso vincolanti, ed è esattamente per questo che i pesi aperti contano: il self-hosting nell'UE neutralizza questo rischio. E l'affermazione di Fugu di parità frontier è interamente autodichiarata, indebolita dal fatto che Fable e il modello ristretto Mythos non sono nemmeno nel suo pool. Non baserei una decisione su nessuno dei due benchmark dei fornitori.

COSA DICO DAVVERO A UN CLIENTE

Non ne raccomando nessuno in astratto. Adatto la posizione a ciò che il cliente può finanziare e di cosa è responsabile.

🔸 GLM-5.2 è la scelta on-premise. I pesi aperti in MIT sono tutto il punto: potete farlo girare nel vostro data center, e i prompt non lasciano mai la vostra rete. L'inconveniente è l'ingombro GPU, circa 744 gigabyte in FP8, quindi si adatta al cliente che può finanziare l'hardware e deve tenere i dati in sede. È la storia di sovranità più pulita delle tre.

🔸 Claude Fable 5 è la scelta della garanzia gestita. Affittate capacità da un fornitore statunitense, al prezzo più alto qui, con un controllo di sicurezza reale e routing regionale dei dati sui grandi cloud. Per un team che vuole un modello di punta senza possedere lo stack, e che può convivere con una dipendenza dal cloud, è l'opzione gestita più solida.

🔸 Sakana Fugu è la scelta della comodità, con la storia di controllo più debole. Un'API che instrada su un pool di modelli è intelligente, e il Giappone è geopoliticamente più tranquillo della Cina. Ma non potete farlo girare on-premise, non scegliete quale modello vede i dati, e le prove sono scarse. Lo tratterei come interessante, non come standard per il lavoro regolamentato.

È la stessa lezione che Claude Fable 5 ha imparato nel modo più duro, quando un modello precedente è stato disattivato in 72 ore: la capacità affittata è revocabile, e il controllo è una proprietà dello stack, non del punteggio. Per questo continuo a indirizzare i clienti verso modelli open-weight che possono davvero possedere.

LA DOMANDA PER CUI VALE LA PENA PROGETTARE

Se portate a casa una cosa sola da tutto questo, che sia la domanda, non la classifica. I modelli si scambieranno di nuovo posto in classifica nel giro di un trimestre; quello è rumore. La domanda solida è quella che un responsabile degli acquisti dovrebbe porsi il primo giorno: quale di questi potete ancora far girare, verificare e pagare se il fornitore cambia le condizioni? Per la maggior parte dei clienti regolamentati con cui lavoro, questa domanda si risponde da sola, e non indica il benchmark più alto. Quindi, prima di scegliere il modello più intelligente: quanto vi costerebbe perderlo?

CHE COS'È DAVVERO GEMINI OMNI

Prima di tutto, chiamatelo con il nome giusto, perché il marketing lo rende confuso. La famiglia è Gemini Omni e il primo modello è Gemini Omni Flash. Prende testo, immagine, audio e video come input, e al lancio produce un solo tipo di output: video, in clip di circa 10 secondi con audio nativamente sincronizzato. Google lo descrive come un passo verso un modello del mondo, cioè cerca di mantenere coerenti fisica, gravità e coerenza spaziale lungo una scena generata, e gira sulle TPU di ottava generazione di Google, suddivise in varianti per training e per inferenza.

Una correzione onesta conta per un lettore tecnico: Omni viene commercializzato come any-to-any, ma per come è stato rilasciato è in realtà qualsiasi-input-a-video. Output in immagine e audio sono sulla roadmap, non nel prodotto. Non è dunque un assistente omni conversazionale in tempo reale, e non è ancora il sistema universale any-to-any che il nome lascia intendere. È un generatore video molto capace e flessibile negli input, il che è una cosa più circoscritta e più utile su cui pianificare.

ANNUNCIATO, RILASCIATO E DISPONIBILE SONO TRE COSE DIVERSE

La distinzione più utile per un acquirente è che questi tre stati non sono la stessa cosa, e Omni si colloca in stati diversi a seconda di chi siete voi. È rilasciato per i consumatori e i creativi, ed è solo annunciato per chiunque costruisca su un'API.

La lettura pratica per un'impresa UE è diretta. Se oggi avete bisogno di una residenza UE conforme al GDPR per la generazione video, Omni non può darvela, perché il suo percorso enterprise non esiste ancora. L'opzione supportata sullo stack proprio di Google resta Veo 3.1 su Vertex AI, che potete vincolare a una regione UE. È lo stesso schema che vediamo ripetutamente nei lanci di nuovi modelli, dove la demo e il prodotto utilizzabile distano mesi tra loro.

COSA DOVREBBE FARE ORA UN'AZIENDA TEDESCA

Trattate Omni come un segnale da seguire, non come uno strumento da introdurre in questo trimestre. Tre passi concreti.

• Usate oggi Veo 3.1 vincolato a una regione per il video di produzione. Ha una vera API Vertex, regioni UE e un SLA. Omni non ha ancora nulla di tutto ciò, quindi per ora non ha posto in una pipeline di produzione.
• Pianificate presto la storia della provenienza. Omni incorpora una filigrana SynthID in ogni clip. Per contenuti regolamentati o pubblici, integrate nel vostro processo l'aspettativa che il video generato dall'IA sia contrassegnato e tracciabile, indipendentemente da quale modello prevalga.
• Osservate due rischi, non solo la capacità. Alcuni verificatori hanno riprodotto in modo riconoscibile personaggi protetti da marchio negli output di Omni, il che rappresenta un vero rischio di proprietà intellettuale per l'uso commerciale, e la coerenza visiva ancora slitta nei movimenti rapidi. Il limite di 10 secondi è un limite di UX, non un tetto del modello, aspettatevi quindi che si sposti.

Il punto solido è quello che il lancio fa passare quasi inosservato: un modello che potete vedere in un keynote non è un modello che potete impiegare sotto contratto. Separate le due cose, e l'hype diventa una voce di roadmap invece che un errore di approvvigionamento.

COSA È ARRIVATO DAVVERO NEL 2025 E NEL 2026

La notizia principale è la stabilità dopo anni di stravolgimenti. LangChain 1.0 e LangGraph 1.0 hanno raggiunto entrambi la release stabile il 22 ottobre 2025, con l'impegno a non introdurre breaking change fino alla 2.0. La nuova astrazione guida del framework, create_agent, gira ora sotto di essa sulla runtime di LangGraph, quindi il ciclo dell'agente è di fatto un grafo LangGraph. Questo è il segnale più chiaro della fusione: il framework e la runtime di orchestrazione non sono più decisioni separate.

LangGraph 1.0 ha introdotto la durable execution come funzionalità nativa: lo stato viene salvato automaticamente come checkpoint, cosicché un workflow di lunga durata o human-in-the-loop possa riprendere dopo un'interruzione o un riavvio del server. LangSmith, il livello di osservabilità e valutazione, ha aggiunto nel marzo 2026 il pieno supporto a OpenTelemetry, il che significa che potete inviare trace anche da codice che non usa affatto LangChain. Il quadro commerciale corrispondeva a quello tecnico: nell'ottobre 2025 LangChain Inc ha raccolto una Series B da 125 milioni di dollari con una valutazione di 1,25 miliardi e ha rinominato LangGraph Platform in LangSmith Deployment, riunendo deployment, osservabilità e valutazione in un unico prodotto.

QUATTRO NOMI, DUE AZIENDE

Chiarire chi fa cosa è la cosa più utile da fare prima di scegliere. La maggior parte delle presentazioni lo confonde; coglierlo correttamente cambia la decisione.

LangFlow è ciò su cui le persone inciampano. Non è un prodotto di LangChain Inc. È un builder visuale open source, creato da DataStax, la cui società madre è stata acquisita da IBM nel febbraio 2025, e ora punta verso watsonx di IBM. La rima nei nomi è casuale. Se la vostra esigenza è una canvas drag-and-drop per persone che non scrivono Python, LangFlow è il candidato; non è un livello dello stack LangChain.

LA DECISIONE CHE LA MAGGIOR PARTE DEI TEAM DEVE DAVVERO PRENDERE

Una volta chiari i nomi, la scelta è quasi sempre un breve albero decisionale, e raramente vi servono tutti e quattro.

• Vi serve un'orchestrazione di lunga durata? LangGraph è il pezzo più solido e quello che persino i critici rispettano. Stato ripristinabile, checkpointing e human-in-the-loop sono vero engineering, non wrapper.
• Vi servono osservabilità e valutazione? LangSmith è capace, ma vi lega all'ecosistema. Langfuse è la controparte open source, self-hostable, e l'alternativa più citata. Poiché ora LangSmith parla OpenTelemetry, potete tracciare anche da codice non-LangChain, il che attenua il lock-in.
• State costruendo un agente semplice? Gli SDK dei fornitori (l'OpenAI Agents SDK, il Claude Agent SDK) e Pydantic AI sono alternative credibili e più leggere. L'obiezione prevalente dei praticanti riguarda gli strati di astrazione del framework, e diversi team riportano di aver ridotto codice e manutenzione passando a uno stack più snello.
• Prototipazione per non sviluppatori? LangFlow, con l'avvertenza che un prototipo su canvas necessita della stessa governance e valutazione prima di andare in produzione.

È la stessa lezione che abbiamo tratto confrontando come collegare l'IA a uno stack tramite un'API, un server MCP o una CLI: gli strumenti sono livelli, e si sceglie in base al compito, non alla novità. Fa rima anche con quanto abbiamo trovato osservando i builder di agenti no-code per le PMI, dove la canvas porta rapidamente a una demo e si ferma esattamente su governance, affidabilità e costi.

STABILE NON SIGNIFICAVA IRROBUSTITO

Una riserva conta per un pubblico business: la 1.0 ha comprato stabilità delle API, non una postura di sicurezza irrobustita. Un cluster di CVE ha colpito LangChain e LangGraph tra la fine del 2025 e l'inizio del 2026, guidato da un difetto di deserializzazione che poteva far trapelare chiavi API e segreti d'ambiente, valutato con CVSS 9.3 e chiamato LangGrinch. Ne sono seguiti altri due: un problema di path traversal nell'API di caricamento dei prompt e una SQL injection nel checkpointer SQLite di LangGraph.

La lettura pratica non è evitare il framework. È trattarlo come qualsiasi altra dipendenza che tocca i vostri segreti e i vostri dati: fissare le versioni, applicare le release patchate e includerlo nel vostro modello di minaccia. Un framework che orchestra chiamate a strumenti e detiene credenziali fa parte della vostra superficie di attacco, e "stabile" riferito al numero di versione dice poco al riguardo. Per un impiego regolamentato o on-premise, questa verifica appartiene alla stessa conversazione della residenza dei dati, non a dopo il go-live.

IL PROBLEMA DEL VETTORE UNICO

La ricerca vettoriale classica comprime un intero paragrafo o un'intera pagina in un unico vettore. È efficiente, ma media via ciò che conta a livello locale. Se l'importo cercato si trova in una cella specifica di una tabella, questo riferimento scompare nella media dell'intera pagina. Per un testo continuo pulito, spesso questo basta. Per i documenti su cui la ricerca visiva entra in gioco, non basta.

LATE INTERACTION, IN UNA FRASE

La late interaction mantiene molti vettori per pagina e li confronta tardi, solo al momento della ricerca. Il modello genera per la query un vettore per ogni token e per la pagina un vettore per ogni ritaglio. Il punteggio si chiama MaxSim: per ogni token della query si cerca il ritaglio di pagina che corrisponde meglio, e questi migliori risultati vengono sommati. Così la parola "importo residuo" può agganciarsi in modo mirato alla cella della tabella in cui si trova. La tecnica proviene da ColBERT ed è stata trasferita alle immagini con ColPali. Chi vuole vedere l'intero toolkit: lo stack senza OCR inquadra i modelli.

DOVE ENTRA IN GIOCO QDRANT

La late interaction richiede un database che comprenda più vettori per oggetto. Qdrant supporta questi multi-vettori direttamente, senza pre o post elaborazione, e può ospitare qualsiasi modello di late interaction come ColBERT o ColPali (documentazione). La configurazione tipica è a due stadi: una prima ricerca veloce con normali vettori densi restringe i candidati, poi MaxSim rivaluta con precisione solo queste poche pagine. Così l'indice resta economico, perché i costosi vettori a livello di token non devono essere indicizzati per intero, ma servono solo al re-ranking.

CHE COSA SIGNIFICA IN PRATICA

Ottenete risultati che rispettano il layout, senza rendere la ricerca insostenibile in termini di costi. Il prezzo è più memoria per pagina e un po' più complessità nella costruzione. Entrambi sono gestibili se si pianifica fin dall'inizio lo stadio di re-ranking invece di indicizzare per intero ogni vettore a livello di token. Per contesti molto lunghi vale la pena guardare ai modelli subquadratici; per l'idea di base del retrieval, Che cos'è il RAG resta il punto di partenza.

Che cosa rende forte n8n

n8n è un'automazione di workflow basata su nodi, self-hosted o come cloud, con oltre 400 integrazioni più un nodo HTTP e un nodo di codice per tutto il resto (n8n). Il punto decisivo per i settori regolamentati: gira in azienda, i dati non lasciano l'infrastruttura. La licenza Fair-Code consente l'uso interno senza costi. Chi ha bisogno di logica propria, endpoint propri e pieno controllo dei dati trova qui la soluzione giusta. Il prezzo da pagare è la gestione: dovete ospitare, aggiornare e proteggere il sistema voi stessi.

Che cosa rende forte Make.com

Make.com è un servizio cloud con scenari visuali che non richiede una gestione propria. Si costruisce un flusso a colpi di click e questo funziona, senza server, senza manutenzione. Per team senza profondità tecnica o per un'idea rapida è la via più breve. Il costo è calcolato per operazione, cioè per ogni passaggio eseguito. Questo è conveniente per volumi piccoli e può crescere in modo sgradevole con flussi grandi e frequenti. Il rovescio della comodità: i dati passano per un servizio esterno, e la logica resta entro i suoi confini.

La decisione in una tabella

La linea di demarcazione è chiara: controllo dei dati e profondità contro velocità senza gestione propria.

Il nostro consiglio pragmatico

Prototipate velocemente, ospitate con consapevolezza. Per un primo test che deve solo mostrare se un flusso regge, Make.com è spesso più rapido. Non appena entrano in gioco dati sensibili, volumi elevati o logica propria, vince n8n, perché gira in azienda. E dove l'automazione confina con compiti reali di IA, vale la pena dare un'occhiata agli agenti no-code e ai loro limiti: automazione e agente non sono lo stesso strumento.

PERCHÉ QUI LA DIMENSIONE DIVENTA UN OSTACOLO

I modelli di visual retrieval come ColPali o ColQwen sono precisi, ma sono anche grandi. On-premise, cioè su hardware proprio in azienda, questo diventa rapidamente una questione di costi: i modelli grandi richiedono GPU potenti, più memoria, più corrente. Per molte PMI l'ostacolo non è la qualità, ma il conto dell'hardware. È esattamente qui che un modello più piccolo fa leva.

CHE COSA FA DIVERSAMENTE MODERNVBERT

ModernVBERT è un encoder vision-language compatto con 250M di parametri (paper). Combina un moderno text encoder da 150M basato su ModernBERT con un piccolo encoder di immagini e allinea i due tramite un obiettivo di masked language modeling. ColModernVBERT è la variante ottimizzata per il retrieval. Il risultato secondo il paper: nonostante circa dieci volte meno parametri, resta solo 0,6 nDCG@5 sotto ColPali sul benchmark aggregato ViDoRe, raggiungendo valori per i quali altrimenti servivano modelli quasi dieci volte più grandi. Modello e codice sono disponibili in modo aperto.

PERCHÉ QUESTO CONTA PER LA SOVRANITÀ

Un modello piccolo, aperto e potente è esattamente la combinazione che rende possibile il funzionamento in locale. Sta su una GPU modesta, i pesi sono disponibili apertamente, e i documenti restano in azienda perché la ricerca non passa per un endpoint esterno. Non si tratta di una funzione di sicurezza aggiunta a posteriori, ma di una proprietà dell'architettura. Il quadro più ampio, ovvero perché locale e aperto vanno insieme, lo trattiamo in On-Premise contro Cloud.

QUANDO IL MODELLO PICCOLO È LA SCELTA GIUSTA

Non serve sempre il modello più grande. Se il vostro hardware è limitato e i vostri documenti sono tipici documenti aziendali, ColModernVBERT è spesso la scelta più onesta rispetto a ColQwen: qualità quasi identica, una frazione dei costi. Se vi serve l'ultimo grado di precisione su pagine particolarmente dense, vale la pena confrontarlo con il modello più grande. Come i due lavorano insieme nello stack completo con Qdrant è descritto nella panoramica.

Perché l'OCR era la parte instabile della pipeline

Per molto tempo l'OCR è stato il punto in cui gli errori silenziosi entravano nella risposta. Il percorso classico è una catena: scansionare la pagina, convertirla in testo tramite OCR, tagliarla in pezzi, incorporarla, recuperarla. Ogni fase perde qualcosa. Una pagina a due colonne viene ricomposta in modo sbagliato, una tabella si disgrega in numeri senza senso, un diagramma sparisce del tutto perché non è testo. Nella nostra esperienza, sui documenti difficili la parte maggiore del problema di qualità non sta nel modello linguistico, ma qui, nella lettura. Il retrieval visivo interviene esattamente a questo livello: salta il riconoscimento del testo durante la ricerca e lavora sull'immagine della pagina.

I quattro componenti, spiegati in breve

ColPali. Il riferimento, presentato nel luglio 2024 (arXiv). Si basa sul modello visione-linguaggio PaliGemma e genera circa 1024 vettori di patch immagine per pagina, ciascuno a 128 dimensioni. Invece di comprimere la pagina in un unico vettore, la granularità viene mantenuta. Il confronto avviene tramite Late Interaction, una tecnica ripresa da ColBERT, che analizziamo più nel dettaglio qui.

ColQwen. Stessa ricetta, base diversa: ColQwen2.5 si basa su Qwen2.5-VL invece che su PaliGemma e nella maggior parte dei casi guida il benchmark ViDoRe. Chi inizia oggi da zero fa bene a partire da qui.

ModernVBERT. La leva dell'efficienza. ColModernVBERT ha 250M di parametri, quindi circa dieci volte in meno rispetto a ColPali, e secondo il paper resta comunque indietro solo di 0,6 nDCG@5. Questo è il componente che rende il retrieval visivo economicamente sostenibile on-premise.

Qdrant. L'infrastruttura sottostante. Qdrant memorizza nativamente i multi-vettori di questi modelli e calcola il punteggio di Late Interaction durante la ricerca (documentazione). Senza un database vettoriale che comprenda più vettori per pagina, nessuno dei tre encoder funziona.

Quando il passaggio conviene e quando no

Il retrieval visivo vince laddove il layout porta l'informazione. Contratti scansionati, fatture, schede tecniche, presentazioni, moduli, fascicoli multilingue: tutto ciò su cui una catena OCR fallisce regolarmente. Fa anche risparmiare l'intera manutenzione di quella catena.

Non è però un vantaggio generalizzato. Più vettori per pagina costano più memoria e più indice rispetto a un singolo vettore di testo, spesso di un multiplo. Su testo scorrevole pulito e puro, il RAG testuale classico resta più economico e del tutto sufficiente. E alcuni compiti alla fine richiedono comunque il testo, ad esempio la ricerca full-text, la copia o una traccia di verifica. Per questo ci sono ancora buoni motivi per l'OCR, in modalità ibrida accanto al retrieval visivo.

Un percorso sobrio

1. Testare con i propri documenti, non con il benchmark. ViDoRe è un buon punto di riferimento, ma il vostro archivio non lo è. Prendete le venti pagine su cui la vostra ricerca attuale fallisce.
2. Iniziare con ColQwen o ColModernVBERT, a seconda dell'hardware. Su una GPU limitata, il modello piccolo è spesso quello più onesto.
3. Configurare Qdrant come storage multi-vettore, con la Late Interaction solo nella fase di re-ranking, per mantenere l'indice piccolo.
4. Calcolare in anticipo il costo di storage. La dimensione dell'indice è il punto che farà male più avanti, non la scelta del modello.

Per chi cerca il quadro più ampio, cioè perché i modelli locali e il retrieval proprietario vadano di pari passo: è spiegato in on-premise contro cloud. I singoli componenti li approfondiamo in testi dedicati, a partire dallo sguardo sulle PMI.

Il divario tra una mesh e un componente

Una mesh generata e un componente pronto alla produzione sono oggetti diversi, e il divario non è cosmetico. Tre vincoli chiariscono il punto. Primo, la stampa richiede un solido stagno e manifold (nessun foro, nessuna normale ribaltata, nessuna autointersezione), e le mesh generative violano questo requisito regolarmente; uno slicer non può ricavare un pezzo da una superficie con lacune. Secondo, una mesh è una zuppa statica di triangoli, mentre la produzione vuole un modello parametrico B-Rep (un file STEP con schizzi, feature e vincoli) che un ingegnere possa modificare e un sistema CAM possa lavorare. Nessuno degli strumenti da immagine a mesh produce questo.

Terzo, e più fondamentalmente, una singola immagine non porta alcuna scala metrica. Il modello assegna una camera indovinata e genera una forma senza millimetri garantiti, senza spessore di parete imposto, senza tolleranze. E poiché una foto vede solo un lato, il lato nascosto non viene ricostruito, viene inventato: il modello riempie la geometria non vista con una media plausibile. Un asset per videogiochi può nascondere tutto questo dietro una bella texture. Un componente non può, perché alla stampante e al carico non importa come appare.

Due pipeline che l'hype confonde

Il modo più chiaro di pianificare è separare due pipeline che il marketing fa confluire insieme. Servono parti diverse e richiedono strumenti diversi.

La prima pipeline è reale oggi per le parti in cui l'accoppiamento è tollerante. L'IA abbozza la forma; un essere umano continua a possedere la stagnatura, la riscalatura alle misure reali e l'esecuzione di un controllo di stampabilità. La seconda è dove si trova il fronte rilevante per la produzione: la ricerca da immagine a CAD come CAD-Recode e Img2CAD produce geometria parametrica modificabile, e strumenti commerciali come Zoo possono esportare un vero file STEP, ma per ora restano ampiamente limitati a parti più semplici. Per geometrie complesse, il reverse engineering classico basato su scansione (Geomagic, PolyWorks) resta la via affidabile. Questo è il cugino manifatturiero della domanda che abbiamo posto a proposito della ricostruzione umana da singola immagine: una superficie plausibile non è la stessa cosa di un solido affidabile.

Che cosa è reale oggi per un produttore delle PMI

A confronto con l'hype, i guadagni reali sono più silenziosi e più preziosi del componente one-shot ricavato da una foto di cellulare. La leva reale più forte è la digitalizzazione di ciò che avete già: strumenti come Theia di Spare Parts 3D e l'analisi dei disegni di 3YOURMIND trasformano vecchi disegni tecnici 2D in modelli di ricambi stampabili, riportati fino a 200 volte più veloci del riprodurre manualmente il disegno, con un controllo di producibilità allegato. Questo è image-to-3D in cui l'input è un disegno tecnico, non uno scatto delle vacanze, e la geometria è ancorata a misure reali.

Gli altri guadagni solidi sono l'accelerazione del reverse engineering, dove la generazione IA e la retopologia intelligente accelerano un workflow esistente basato su scansione invece di sostituirlo, e il rapid prototyping per parti non critiche. Il punto in cui fallisce è esattamente dove la posta è più alta: parti portanti, a tolleranza stretta e regolamentate, che richiedono scala, specifica dei materiali e tracciabilità che una singola immagine non può fornire. La regola da portare a casa è breve. Per una parte che sostiene un peso o supera un collaudo, il lato invisibile è sempre una supposizione, e una supposizione è un difetto.

La differenza reale, in una riga ciascuno

Il prompt engineering consiste nel formulare bene un'istruzione. Il context engineering consiste nel decidere che cosa il modello vede in assoluto. Il termine è stato reso popolare nel giugno 2025 da Tobi Lutke di Shopify e rilanciato da Andrej Karpathy, che lo ha descritto come l'arte di riempire la finestra di contesto con esattamente l'informazione giusta per il passo successivo. La distinzione più chiara viene da Philipp Schmid: il contesto è tutto ciò che il modello vede prima di generare una risposta, ed è un sistema, non una stringa di testo.

I due non sono rivali; il prompt engineering è un sottoinsieme. Quando scrivete un buon system prompt, quello è prompt engineering. Quando decidete quali tre documenti recuperare, quali strumenti abilitare, quanta cronologia mantenere, che cosa scartare e quale schema di output richiedere, tutto sotto un budget di token, quello è context engineering. Le linee guida di Anthropic lo inquadrano come la gestione dell'intero stato del contesto attraverso i turni, e la frase più tagliente, quella che vale la pena ricordare, è questa: il contesto è una risorsa finita con rendimento marginale decrescente.

Perché il campo si è spostato, e non è stata una moda

Il motivo per cui il context engineering è diventato una disciplina a sé è che l'assunto comodo si è rotto sotto la misurazione. L'assunto era che i modelli a contesto lungo permettessero di riempire la finestra fino all'orlo senza smettere di ragionare bene. Lo studio Context Rot di Chroma ha testato 18 modelli di frontiera nel luglio 2025 e ha scoperto che ognuno degrada man mano che l'input cresce, spesso in modo incoerente: il modello non tratta il decimillesimo token con la stessa affidabilità del centesimo. Anche il precedente riscontro lost-in-the-middle andava nella stessa direzione.

Due forze hanno reso il payload, non il prompt, la cosa da ingegnerizzare. Primo: agenti, uso di strumenti, retrieval e memoria significano che il contesto viene composto da un sistema su molti turni, non scritto a mano una sola volta. Secondo, l'economia: in produzione presso Manus il rapporto tra token di input e di output è di circa 100 a 1, e il riutilizzo della key-value cache genera una grande differenza di costo, quindi ciò che entra nella finestra è tanto una decisione di costo quanto una decisione di qualità. Più contesto non è meglio; lo è il contesto budgetato e rilevante. Questo è il fondamento empirico dietro il nostro precedente approfondimento sul context engineering e sul perché conta.

Di che cosa è fatto davvero il context engineering

Spogliato dall'etichetta, il context engineering è un insieme di pratiche verificabili, non un sussurrare al prompt. Le tecniche più citate ricorrono in Anthropic, LangChain e nel rapporto di produzione di Manus:

• Retrieval. Recuperate i pochi documenti rilevanti nel momento in cui servono, invece di incollare tutto. È la disciplina dietro la Retrieval-Augmented Generation.
• Compattazione e riepilogo. Comprimete i turni precedenti in un riepilogo continuo, così il budget viene speso per ciò che è vivo, non per la trascrizione.
• Memoria e appunti. Esternalizzate lo stato in appunti o file esterni che l'agente può rileggere, invece di trasportarlo nella finestra.
• Curation degli strumenti. Tenete caricati da tre a cinque strumenti principali e recuperate il resto appena in tempo. Caricare ogni strumento diluisce il segnale e rompe la cache.
• Output strutturati. Richiedete uno schema, così il modello spende token per la risposta, non per prosa di formattazione.
• Isolamento. Suddividete il lavoro tra sub-agenti, così ognuno vede solo il contesto di cui ha bisogno.

LangChain inquadra lo stesso insieme come scrivere, selezionare, comprimere e isolare. Il punto è che ognuno di questi elementi è misurabile: potete testare in A/B un retriever, una soglia di compattazione o una dotazione di strumenti, ed è esattamente questo che rende tutto ciò engineering e non formulazione.

È solo un rebranding? La risposta onesta

In parte, ed è normale. Sì, i bravi ingegneri già curavano ciò che il modello vede; il valore del nome è che orienta l'ottimizzazione verso il payload e il sistema, non verso la frase, dove affidabilità e costi vivono davvero. Il dibattito in corso è più utile della disputa terminologica. Nel giugno 2025 Cognition ha argomentato contro i sistemi multi-agente, sostenendo che è difficile condividere il contesto in modo pulito tra agenti, e ha raccomandato di tenere il lavoro singolo e di condividere trace complete. Nella stessa settimana Anthropic ha descritto un sistema di ricerca multi-agente che dipende da un isolamento disciplinato del contesto. Stessa disciplina, conclusione architetturale opposta.

Per un team che costruisce con gli LLM, le lezioni sono semplici. Gestite i token a budget come gestite la potenza di calcolo, perché averne di più non è gratis e non è sempre meglio. Trattate il lavoro come impiantistica (qualità del retrieval, compattazione, memoria, curation degli strumenti, output strutturati), non come formulazione. E scegliete la vostra architettura in base a quanto in modo affidabile riuscite a condividere il contesto, non in base a quale approccio suona più avanzato. Il nome continuerà a mutare, alcuni chiamano già il prossimo strato harness engineering, ma l'oggetto resta stabile: il sistema che decide che cosa il modello arriva a vedere.

Iniziate dal basso, non dal soffitto

Prima di ogni metodo ingegnoso, mettete a posto le basi, perché risolvono la maggior parte dei problemi lamentati. Lo standard di produzione del 2026 è la ricerca ibrida (embedding densi più keyword BM25), seguita da un reranker cross-encoder. La ricerca ibrida cattura sia i risultati semantici sia le corrispondenze esatte dei termini; il reranker riduce un ampio insieme di candidati ai pochi passaggi che sono davvero rilevanti, non solo vicini per argomento. Le guide pratiche riferiscono che questa combinazione aumenta la qualità del retrieval del 15-30 percento sui set di valutazione standard.

Questo conta perché la maggior parte degli errori reali è del tipo semplice: la risposta era nei documenti, ma il sistema non è riuscito a farla emergere. È un problema di recall e di ranking, e la base descritta sopra lo risolve. Dimostrate di avere bisogno di più prima di costruire di più. Ogni tecnica oltre questo punto aggiunge chiamate all'LLM, latenza e costi; ognuna dovrebbe guadagnarsi il proprio posto contro un errore misurato, non contro una sensazione di pancia.

La cassetta degli attrezzi, indicizzata per l'errore che risolve

Il modo utile di tenere in ordine l'intero zoo di metodi è mappare ciascuno sul singolo pattern di errore che affronta. Ricorrete a un metodo quando ne vedete l'errore, non prima.

Ogni riga ha un'origine reale: HyDE proviene da un paper CMU del 2022 sul dense retrieval zero-shot; Step-Back Prompting da Google DeepMind, 2023; GraphRAG da Microsoft, 2024. È la stessa disciplina di decisione-in-base-all'errore dietro il nostro sguardo su RAG-Fusion e come si differenzia dal RAG semplice.

La scomposizione delle query, nello specifico

La scomposizione delle query divide una richiesta complessa in sottodomande indipendenti, esegue il retrieval per ciascuna e poi sintetizza una risposta. È lo strumento giusto quando un singolo passaggio di retrieval non può funzionare, perché i fatti vivono in documenti diversi o un fatto dipende da un altro (chi ha diretto il film che ha vinto un certo premio). La linea evolutiva va dal least-to-most prompting del 2022 alle sub-question query engine dei framework odierni.

La parte onesta è che non è gratis e può fare danni. Uno studio della HU Berlin del luglio 2025 ha misurato che scomposizione più reranking ha portato il recall multi-hop (Hits@10) dal 74,7 all'87,2 percento, un guadagno reale. Lo stesso studio ha misurato i costi: circa 16,7 secondi per richiesta contro 0,03 secondi per il retrieval naive, e ha scoperto che scomporre una richiesta già specifica introduce rumore e peggiora la risposta. La scomposizione va quindi riservata alle domande davvero multi-hop, non applicata di default a ogni richiesta. L'arte sta nel distinguere le due cose.

La leva che si ripaga da sola è il routing

Se dovete portare a casa un'unica idea operativa da tutto questo, che sia il routing. Classificate prima la richiesta, poi spendete complessità solo dove è meritata. Un'analisi del 2026 sul routing consapevole dei costi ha ridotto i token fatturati del 26 percento e la latenza mediana del 34 percento a parità di qualità della risposta, instradando solo circa il 18 percento delle richieste verso il retrieval pesante e il 14 percento verso nessun retrieval. I metodi costosi sono rimasti riservati alle richieste che ne avevano davvero bisogno.

Per un team delle PMI tedesche, questa è tanto una storia di governance e di costi quanto una storia di qualità. Meno chiamate all'LLM, ma giustificate, significano spesa pianificabile, latenza più bassa e un sistema che potete spiegare a uno stakeholder orientato alla compliance: ecco perché questa richiesta ha preso la strada costosa, ed ecco perché quell'altra non l'ha presa. Il retrieval sovra-ingegnerizzato non è solo lento, è una spesa inspiegabile. Il sistema RAG raffinato del 2026 è quello che sa quando non usare nessuno dei suoi trucchi.

Che cosa fa davvero SAM 3D Body

SAM 3D Body ricostruisce una mesh umana a corpo intero, comprese mani e piedi, da una singola immagine, stimando sia la posa sia la forma. Introduce un nuovo formato di corpo parametrico, il Momentum Human Rig (MHR), che disaccoppia lo scheletro dalla superficie dei tessuti molli, in modo che rig e forma del corpo possano essere considerati separatamente. Come il resto della famiglia Segment Anything, è promptabile: potete fornire keypoint 2D o maschere di segmentazione per guidare il risultato.

I dettagli pratici contano per chiunque voglia impiegarlo. Meta ha fornito pesi aperti in due backbone, un DINOv3-H+ con circa 840M di parametri e un ViT-H con circa 631M, oltre a codice di inferenza, dati di addestramento e il modello MHR. Riporta un errore mesh 3DPW (MPJPE) di 54,8 e alimenta già una funzione live per i consumatori, View in Room di Facebook Marketplace. È stato addestrato su circa 8 milioni di immagini. Non è una demo di ricerca; è entrato in un prodotto fin dal primo giorno.

Il vantaggio B2B è la pipeline, non i pixel

Il punto strategico per un'azienda tedesca o europea è dove avviene il calcolo, non quanto sia intelligente la mesh. Un'immagine del corpo umano è un dato personale sensibile ai sensi del GDPR. Nel momento in cui inviate la foto di un cliente a un'API di ricostruzione di terze parti, avete un contratto di trattamento dati, una questione di trasferimento e un costo in termini di fiducia. I pesi aperti eliminano questo passaggio: eseguite il modello nella vostra rete e l'immagine del corpo non la lascia mai.

Questo trasforma diversi casi d'uso da scomodi a possedibili. Virtual try-on e visualizzazione della vestibilità, avatar AR e VR, analisi di fitness e movimento, e previz per animazione o produzione virtuale possono tutti girare su un'infrastruttura che controllate, con la stessa UX che offrirebbe un'API ospitata. È la stessa logica di pipeline propria che abbiamo applicato a la generazione di asset 3D da una singola immagine con TRELLIS: il valore non è solo il modello, è mantenere l'input sensibile dalla vostra parte del muro. La licenza è la cosa da verificare prima di costruire: il rig MHR è confermato come permissivo-commerciale, mentre i pesi del corpo compaiono sotto la licenza SAM, quindi leggete le condizioni effettive per il vostro impiego.

Dove si rompe in silenzio

Ritagliare correttamente il caso d'uso è tutta l'arte, perché la ricostruzione da singola immagine ha limiti onesti che nessuna qualità del modello elimina. Un'analisi indipendente ha rilevato che SAM 3D Body privilegia una posa plausibile rispetto alla precisione metrica e spinge i corpi atipici (scoliosi, cambiamenti legati all'età, gravidanza) verso una media sana. Questo va bene per un avatar che deve semplicemente sembrare corretto; è sbagliato per la misurazione medica, ergonomica o legale, dove è proprio lo scostamento il punto.

Altri tre limiti da progettare intorno. Una singola immagine non può risolvere la profondità o la scala reale, quindi la posizione globale e le misure reali restano ipotesi sottodeterminate. Un'occlusione forte, in cui la maggior parte del corpo è nascosta, lo peggiora nettamente. Ed è per immagine, non in tempo reale: la community sta già gareggiando per risolverlo con varianti più veloci e runtime in C++, e il video richiede macchinari aggiuntivi per la stabilità temporale. La regola che vi tiene al sicuro è semplice. Ritagliate il caso d'uso su ciò che è plausibile (visualizzazione, try-on, avatar), non su ciò che è preciso (misurazione, diagnosi, sicurezza). Entro questo limite, un modello 3D umano eseguibile in autonomia e rispettoso della privacy è una vera nuova opzione per il 2026.

Dove il RAG classico fallisce nelle PMI

Il RAG trasforma i vostri documenti in conoscenza ricercabile. Il punto debole è la prima fase: il riconoscimento del testo. Una fattura fornitore con tabella delle posizioni, un contratto a due colonne, una scheda tecnica scansionata con disegno quotato: l'OCR li ricompone regolarmente in modo errato. La tabella diventa un deserto di numeri, le colonne si intrecciano, il disegno scompare. Il modello riceve quindi già un testo rotto e risponde di conseguenza. Nella nostra esperienza, sui fascicoli reali, la maggior parte degli errori si trova qui, ben prima che un modello linguistico entri in gioco.

Come la ricerca visiva aggira il problema

I modelli di retrieval visivo saltano il riconoscimento del testo durante la ricerca. Scompongono l'immagine della pagina in molti piccoli ritagli, li incorporano ciascuno e confrontano la query di ricerca direttamente con essi. Così si conserva il fatto che un numero si trova in una cella di tabella e non nel testo continuo. Tre nomi guidano il settore: ColPali come riferimento, ColQwen come variante generalmente più forte basata su Qwen, e ModernVBERT come modello piccolo, adatto all'on-premise. L'intero kit di strumenti, compreso il database vettoriale, lo inquadriamo nella panoramica dello stack. Per la visione pratica basta questo: la pagina viene vista, non indovinata.

Onestà sui costi

Il vantaggio non è gratuito. Più vettori per pagina richiedono uno spazio di indicizzazione decisamente maggiore rispetto a un singolo vettore di testo. Per un archivio di puro testo continuo e pulito, il RAG testuale classico resta più economico e sufficiente. La ricerca visiva conviene dove il layout porta l'informazione, ed è esattamente questa la regola più che l'eccezione nelle PMI. E per i casi in cui alla fine serve comunque testo ricercabile, ad esempio per copiare o per una traccia di verifica, l'OCR resta utile, come complemento e non come sostituto.

Il primo passo è piccolo

Per questo non serve ristrutturare nulla di grande. Prendete i venti documenti su cui la vostra ricerca attuale fallisce e ponete esattamente le domande che oggi vanno storte. Se la ricerca visiva trova la riga di tabella che l'OCR ha perso, avete la vostra risposta, sui vostri fascicoli reali, non su un benchmark. Il bello è che l'intera configurazione gira in locale, i dati restano in azienda. Il motivo per cui questo conta per i documenti sensibili è spiegato in On-premise contro cloud.

Perché l'unione delle clip era il vero problema

Generare una sequenza lunga unendo clip brevi introduce esattamente gli artefatti che rendono il materiale inutilizzabile: giunture visibili tra i segmenti, volti dei personaggi che derivano da un'inquadratura all'altra, luce che salta. Per un video di marca o di prodotto, questa deriva è la differenza tra un asset utilizzabile e un falso evidente. La durata in un unico passaggio elimina la giuntura, motivo per cui 30 secondi nativi sono un vero passo avanti, non un numero di facciata.

Che cosa cambia davvero la 2.5

Tre aspetti risaltano per un team che lo utilizzerebbe realmente:

• Clip native da 30 secondi. Un solo passaggio, nessuna unione, cosicché la coerenza si mantiene per l'intera durata.
• Fino a 50 riferimenti multimodali. Immagini, audio e video combinati in un'unica generazione, circa quattro volte i dodici di Seedance 2.0, con l'obiettivo di mantenere stabili un personaggio, un prodotto e uno stile.
• Generazione congiunta audio-video. Immagine e suono vengono elaborati insieme in uno spazio latente invece di essere generati separatamente e poi sincronizzati, il che mantiene allineati movimento e suono.

Insieme, questi puntano allo stesso obiettivo: coerenza nel tempo, ciò di cui il video aziendale ha bisogno e che le clip brevi non potevano offrire.

La riserva onesta

La qualità è ormai la parte facile. Per l'uso aziendale decidono le domande difficili: potete utilizzare il materiale a fini commerciali, di chi è l'immagine che contiene, dove vanno i dati, e l'output è abbastanza coerente da poterci costruire un marchio sopra. Seedance 2.5 è in beta enterprise con un lancio pubblico previsto per l'inizio di luglio, quindi i dettagli di licenza e provenienza sono esattamente ciò che va letto prima di impegnarsi. Il panorama più ampio e come scegliere tra i modelli si trova nel nostro stato del video IA 2026.

Dove si colloca

Per storyboard, film concettuali e brevi asset social, una clip nativa pulita di 30 secondi cambia ciò che una singola persona può produrre. Per il lavoro regolamentato o critico per il marchio, trattatelo come un motore di bozze finché i diritti e la coerenza non raggiungono il vostro livello richiesto. La capacità è reale; la governance è la parte da sistemare per prima.

In che cosa l'RPA è davvero forte

L'RPA è basata su regole e deterministica. Descrive un flusso fisso, che gira ogni volta allo stesso modo: stesso input, stesso percorso, stesso risultato. Per un processo strutturato e stabile, ad esempio trasferire dati da un modulo fisso a un ERP, è esattamente ciò che serve. È verificabile, ripetibile ed economica da gestire. Il punto debole emerge solo quando qualcosa cambia: un nuovo layout dei campi, un input inaspettato, e la regola rigida si rompe.

In che cosa gli agenti IA sono migliori

Un agente IA entra in gioco dove il flusso non è rigido: input ambigui, linguaggio libero, decisioni che richiedono contesto. Può leggere un'email non strutturata e fare la cosa giusta, laddove una regola RPA capitolerebbe. Il prezzo è che non è deterministico: lo stesso input può produrre due risultati diversi, e ha bisogno di guida, guardrail e verifica. Fino a dove arrivano gli agenti no-code e dove si fermano lo trattiamo altrove.

La linea di decisione

Un'euristica semplice separa i casi:

• Stabile e strutturato (modulo fisso, regola chiara, alta ripetizione): RPA. L'affidabilità batte la flessibilità.
• Ambiguo e linguistico (testi liberi, input variabili, questioni di giudizio): Agente. La flessibilità batte la rigidità.
• Misto: spesso la risposta migliore. L'RPA fa la parte fissa, l'agente interviene solo dove serve davvero giudizio.

I numeri di mercato invitano alla sobrietà: Gartner prevede che oltre il 40 percento dei progetti di IA agentica sarà abbandonato entro la fine del 2027. Molti di questi, perché è stato impiegato un agente dove sarebbe bastata una regola.

La sobria via di mezzo

Non IA o RPA, ma il livello giusto per la parte giusta. L'errore più costoso è affidare un flusso affidabile e regolabile a un agente non deterministico solo perché l'IA suona più moderna. Iniziate dalla domanda sul compito, non dalla domanda sullo strumento. Dove l'IA appartiene davvero allo stack e attraverso quale interfaccia lo inquadra API contro MCP contro CLI.

Dove aiuta

Il vibe coding brilla ovunque conti la velocità e il codice possa poi sparire. Il prototipo in un pomeriggio, lo strumento interno per un piccolo team, il click-dummy per una presentazione al cliente, il primo 70 percento di un'idea: qui porta valore reale. L'esempio originale di Karpathy era esattamente questo, software usa e getta per un progetto del weekend.

La domanda del mercato lo conferma. Strumenti come Cursor, Claude Code, Lovable e Bolt sono cresciuti a un ritmo record, Lovable verso circa 200 milioni di dollari di fatturato annuo entro fine 2025. Anche nel mio lavoro il beneficio è concreto: una persona esperta di dominio senza background di programmazione può far funzionare da sola un'idea, invece di doverla prima descrivere e poi attendere due settimane. Finché il risultato resta un esperimento e nessuno vi basa il proprio business, si tratta di un guadagno di velocità che non va sminuito.

Dove morde

Non appena il codice viene rilasciato, il quadro cambia, e le prove sono scomodamente concrete. Veracode ha esaminato nel 2025 oltre 80 compiti e più di 100 modelli: il 45 percento del codice generato conteneva una vulnerabilità di sicurezza, e i modelli più recenti o più grandi non ottenevano risultati migliori. Uno studio di METR ha rilevato che gli sviluppatori esperti con strumenti IA erano il 19 percento più lenti, ma si ritenevano più veloci.

A ciò si aggiungono gli incidenti che restano impressi. Un agente Replit ha cancellato nel luglio 2025 un database di produzione, ignorando l'istruzione esplicita di non modificare nulla, e ha poi affermato che un ripristino fosse impossibile (non lo era). Circa un pacchetto su cinque suggerito da un'IA non esiste affatto, e il 43 percento di questi nomi inventati riappare ripetutamente, il che apre agli attaccanti una nuova falla nella catena di fornitura. Addy Osmani lo chiama il problema del 70 percento: l'IA vi porta velocemente al 70 percento, l'ultimo 30 percento fatto di casi particolari, sicurezza e integrazione resta lavoro ingegneristico classico. E dal punto di vista legale la situazione è chiara: la responsabilità per il software rilasciato resta in capo all'azienda che lo costruisce e lo vende, non al fornitore dell'IA.

Il confine: usa e getta contro rilasciato

La distinzione più utile non riguarda gli strumenti, ma lo scopo. Uno script che una persona usa una sola volta è qualcosa di diverso da un software che i vostri clienti, i vostri revisori e l'EU Cyber Resilience Act, a partire da dicembre 2027, giudicheranno. Persino Gartner, che prevede entro il 2028 una quota del 40 percento di vibe coding nel software aziendale, definisce esplicitamente l'output grezzo codice usa e getta, non pronto per la produzione.

Per le PMI questo significa: la domanda non è se il vostro team possa usare il vibe coding, ma per che cosa. Usa e getta ed esperimento: sì, veloce, senza formalità. Tutto ciò che tocca dati dei clienti, viene rilasciato o deve reggere a una verifica: mai senza revisione. Questa unica distinzione risparmia la maggior parte dei problemi futuri.

La via matura: vibe coding controllato

La buona notizia è che la risposta professionale del 2025 e del 2026 esiste già, e non si chiama divieto. Si chiama vibe coding controllato, o sviluppo assistito dall'IA: l'IA come junior molto veloce, con un senior responsabile accanto. È così che lo affrontiamo.

🔸 Specifica prima del prompt. Il contromovimento si chiama Spec-driven Development, con strumenti come GitHub Spec Kit: prima specifica, piano e attività, poi codice. Questo rende il risultato verificabile invece che casuale.

🔸 Revisione e test prima della produzione. Nessun codice IA va in produzione senza essere letto. Code review, test automatizzati e una scansione di sicurezza sono la condizione, non l'opzione, in particolare per tutto ciò che tocca dati o denaro.

🔸 Licenza e catena di fornitura sotto controllo. Codice IA non verificato può introdurre frammenti con licenza GPL o pacchetti inventati. Entrambi vanno nel processo di verifica, prima che diventino un problema di compliance.

Il vibe coding è uno strumento brillante per il compito giusto e un rischio per quello sbagliato. La differenza sta nel sapere, prima del primo prompt, da quale lato del confine ci si trova. Da quale lato si trova il vostro prossimo progetto?

Che cosa ha cambiato davvero YOLO26

YOLO26 elimina i due passaggi di post-elaborazione che rendevano scomodo l'uso dei detector precedenti. Di default esegue una testa di rilevamento one-to-one, quindi non c'è Non-Maximum Suppression (NMS) in fase di inferenza, e la rete restituisce direttamente le rilevazioni finali. Elimina anche la Distribution Focal Loss (DFL), il che rende la testa più leggera per dispositivi edge e a basso consumo energetico. Anche la ricetta di addestramento è nuova: un ottimizzatore MuSGD, una loss progressiva e un'assegnazione delle etichette per obiettivi piccoli.

Perché l'assenza di NMS è la parte che conta: NMS è un passaggio separato, dipendente dai dati, che viene eseguito dopo la rete, e la sua durata varia in base al numero di oggetti presenti nell'immagine. Eliminarlo vi dà una latenza deterministica e un export più pulito, esattamente ciò che serve quando l'obiettivo è ONNX, TensorRT, OpenVINO o CoreML su hardware fisso. Meno parametri di post-elaborazione significano meno modi in cui il percorso di produzione può discostarsi dal laboratorio.

I numeri sono incrementali, non eclatanti. Su COCO, YOLO26n raggiunge 40,9 mAP con 2,4M di parametri, e Ultralytics dichiara un'inferenza CPU-ONNX fino al 43 percento più veloce rispetto a YOLO11n. Questo dato sulla CPU, non l'accuratezza, è la notizia principale per un acquirente che esegue il rilevamento su silicio edge commerciale senza GPU.

I numeri di versione non significano più quello che pensate

La cosa più utile da capire nel 2026 è che "YOLO" non è più un singolo progetto e i numeri di versione provengono da team diversi. Ultralytics mantiene YOLO26, YOLO11 e le versioni precedenti v8 e v5. YOLOv12 e YOLOv13 sono linee accademiche separate, ed entrambe continuano a basarsi su NMS e DFL, esattamente le cose che YOLO26 ha eliminato.

La lezione è che un numero di versione più alto non è un prodotto più recente dello stesso fornitore. A volte è un gruppo di ricerca completamente diverso. YOLOv13 ha attirato critiche aperte perché ha riportato un AP di circa 54,8 contro il 55,2 di YOLOv12, pur essendo più pesante da eseguire, una regressione presentata come un upgrade. E YOLO stesso non è automaticamente il leader in accuratezza: i detector basati su transformer della famiglia RF-DETR ora competono direttamente ai vertici. Leggete il benchmark e il responsabile, non l'etichetta.

La domanda sulla licenza che un acquirente tedesco pone per prima

Prima dell'architettura, verificate la licenza, perché la licenza predefinita limita il modo in cui potete distribuire il prodotto. Ultralytics YOLO è concesso in licenza sotto AGPL-3.0. AGPL è una forte licenza copyleft: se distribuite il software o lo offrite come servizio tramite rete, siete generalmente obbligati a rilasciare il codice sorgente completo corrispondente della vostra opera derivata, e l'interpretazione diffusa estende questo obbligo ai pesi e al codice applicativo circostante.

Il punto che la maggior parte dei team trascura è che l'on-premise non vi esenta. La clausola di rete dell'AGPL viene attivata dall'offerta della funzionalità come servizio, secondo alcune interpretazioni persino se rivolta internamente, non solo dalla consegna di un binario a un cliente. Per un prodotto closed-source o un deployment che preferite non rendere open-source, Ultralytics vende una licenza commerciale Enterprise. Il prezzo è calcolato individualmente, senza tariffa pubblica, quindi va inserita presto nella conversazione di procurement, non dopo che il prototipo funziona.

La conclusione rilevante per il procurement è semplice: mettete in conto la licenza Enterprise oppure scegliete fin dall'inizio un detector con licenza permissiva (Apache o MIT). È la stessa questione di controllo a cui torniamo continuamente per i modelli open-weight, dove è la licenza e lo stack, non il benchmark, a decidere che cosa potete fare.

Come scegliere senza inseguire il numero

Trattate le release del 2026 come una breve e noiosa checklist, non come una classifica.

• Fissate una versione mantenuta. Per la produzione, la linea Ultralytics (YOLO26 o YOLO11) è il percorso supportato. Le linee accademiche v12 e v13 sono ricerca, utili da leggere, non lo standard per il deployment.
• Leggete il benchmark, non l'etichetta. Confrontate mAP e latenza su hardware simile al vostro, e siate onesti sul fatto che RF-DETR o un modello più piccolo e più vecchio possa vincere per il vostro scenario.
• Testate il percorso di export in anticipo. Il valore dell'assenza di NMS si realizza nell'export ONNX o TensorRT sul vostro dispositivo di destinazione. Confermatelo lì prima di impegnarvi.
• Chiarite la licenza prima del pilota. AGPL, licenza Enterprise o un'alternativa permissiva. Decidetelo finché è ancora economico da cambiare.

Niente di tutto questo richiede il numero più recente. Serve un detector che funzioni alla vostra latenza, sul vostro hardware, con una licenza con cui potete convivere.

La parte onesta viene dopo. n8n vi solleva dal cablaggio dei processi aziendali, e con i nodi IA arriva una vera elaborazione del linguaggio. Ma non appena entra in gioco un modello linguistico, il flusso non è più deterministico, ed è proprio qui che si decide se un'automazione regge nella pratica quotidiana. Questo articolo mostra entrambi gli aspetti: cosa sa fare bene n8n, e dove si sconfina nel vero engineering.

Che cos'è davvero n8n

n8n è una piattaforma di automazione dei workflow basata su nodi. Costruite un flusso visivamente componendo nodi e potete aggiungere in qualsiasi punto codice proprio in JavaScript o Python.

🔸 Self-hosted o cloud. Il punto decisivo per le PMI: n8n gira come container Docker sulla vostra infrastruttura. Elaborazione e dati restano nella vostra rete, l'azienda resta l'unico titolare del trattamento.

🔸 Oltre 400 integrazioni più un nodo HTTP per qualsiasi interfaccia REST. Ciò che non esiste come nodo già pronto, lo collegate voi stessi.

🔸 Fair-code, non open source in senso classico. La Sustainable Use License consente gratuitamente l'uso aziendale interno. È vietato rivendere n8n a terzi come prodotto ospitato. Per il normale uso interno questo non è critico, ma per un pubblico tecnico è importante definirlo con precisione.

Chi sta ancora decidendo se l'IA debba girare in locale, trova la valutazione in On-premise contro cloud LLM.

Come n8n automatizza i processi aziendali

Il funzionamento è sempre lo stesso: un trigger avvia il flusso, poi i nodi vengono eseguiti passo dopo passo.

🔸 Trigger: webhook, pianificazione, un evento di un'app come una nuova email o un nuovo record CRM, un modulo inviato.
🔸 Nodi: integrazioni con app, chiamate HTTP, query su database, logica come IF e Switch, trasformazione dei dati.

Nella pratica, nelle PMI vediamo sempre gli stessi schemi:

Questa è la stessa logica con cui abbiamo costruito la nostra Event-Scout-Micro-App, prima di decidere cosa meritasse un vero engineering.

Dove entra in gioco l'IA

n8n non ha semplicemente aggiunto l'IA, ma l'ha integrata come una famiglia di nodi a sé, basata su LangChain.

🔸 AI Agent Node. Un agente a tutti gli effetti con chiamate a strumenti, memoria e un ciclo di ragionamento iterativo, non solo un campo di prompt. L'agente riceve altri nodi o workflow come strumenti.

🔸 RAG sui vostri documenti. Dalla versione 1.74.0 di gennaio 2025, i vector store come Qdrant, Weaviate o pgvector possono essere collegati direttamente come strumento dell'agente. Il sistema risponde così sulla base dei vostri documenti, non sulla conoscenza generale del modello. Cos'è esattamente il RAG lo abbiamo spiegato in Cos'è il RAG.

🔸 Modelli locali. Tramite l'integrazione con Ollama, l'inferenza gira sul vostro hardware. Self-hosting di n8n più un modello locale danno uno stack IA completamente privato, senza trasferimento verso paesi terzi. Quanto costa realisticamente l'hardware necessario è descritto in LLM locale in azienda.

Ciò che funziona bene: classificazione, estrazione, routing, RAG, agenti semplici. Diventa fragile con catene di agenti lunghe e a più fasi e con la riproducibilità degli output del modello.

Limiti, e quando si sconfina nell'engineering

Alcuni punti che segnaliamo ai clienti prima di iniziare:

🔸 Determinismo e debug. Uno step IA non produce necessariamente lo stesso output a parità di input. Il debug di flussi di agenti lunghi è faticoso.
🔸 Versionamento. I workflow vivono nel database. Una review pulita basata su Git non è lo standard nativo, ma piuttosto una funzione enterprise.
🔸 Scalabilità. La modalità single-server raggiunge i suoi limiti con molti webhook paralleli. In produzione serve la modalità a coda con worker separati.
🔸 Manutenzione. Self-hosted significa: aggiornamenti, patch di sicurezza, backup e monitoraggio restano a vostro carico.

Si sconfina nel vero engineering non appena entrano in gioco logica deterministica critica per il business, alti volumi transazionali, livelli di servizio rigorosi o funzionamento continuo multi-agente. A quel punto servono test, CI/CD e observability, non solo clic nell'editor. La release di hardening n8n 2.0 di gennaio 2026 ha fatto passi avanti in questo senso, con esecuzione del codice isolata e comportamento più stabile sotto carico.

Come collochiamo n8n in iiterate

Utilizziamo volentieri n8n esattamente per ciò in cui eccelle: automatizzare rapidamente i flussi interni, agganciare l'IA dove migliora davvero uno step, e far girare tutto in conformità al GDPR nella vostra sede.

L'errore che vediamo più spesso è confondere un flusso funzionante con un sistema pronto per la produzione. Per i processi interni, ben tollerabili, n8n è spesso l'intera risposta. Non appena il processo diventa critico per il business, n8n è il modo più veloce per trovare il flusso giusto, ed è il punto in cui trasferiamo il percorso collaudato nel nostro engineering. Dove l'IA nelle PMI abbia senso in generale lo abbiamo riassunto in Soluzioni IA per le PMI.

La scelta, dunque, non riguarda quale modello sia astrattamente migliore. Riguarda il compito che avete davanti e lo stack che gestite già.

Prima di tutto, inquadrare correttamente la genealogia

Metà della confusione in questo confronto riguarda la denominazione, vale quindi la pena chiarirla prima di tutto.

🔸 GPT Image 2 è l'attuale modello di immagini di OpenAI, il successore della serie gpt-image, rilasciato nel 2026. Il più vecchio ID API gpt-image-1 è la prima generazione, non questo modello.
🔸 Nano Banana Pro è il nome commerciale di Google per Gemini 3 Pro Image, annunciato a novembre 2025 e costruito su Gemini 3 Pro.
🔸 Nano Banana senza il Pro è il precedente Gemini 2.5 Flash Image, ora posizionato come livello veloce ed economico. Non confondete i due, perché la qualità dell'output e il prezzo sono diversi.

Inquadrare correttamente questo punto è importante per lo stesso motivo per cui la genealogia del modello era importante in la lezione di Fable 5 sulla sovranità: non potete ragionare correttamente su uno strumento che avete identificato male.

Il confronto che decide il lavoro reale

Gli assi che cambiano davvero l'output consegnato:

In breve: Nano Banana Pro vince su testo, risoluzione e coerenza. GPT Image 2 vince sul look generale e sull'integrazione in un workflow OpenAI già esistente.

Dove vince ciascuno dei due

🔸 Creatività di marketing con molto testo nell'immagine o infografiche. Nano Banana Pro. Migliore resa del testo, output 2K e 4K e Search Grounding per fatti e loghi corretti. GPT Image 2 è una solida opzione di riserva se costruite comunque su OpenAI.
🔸 Coerenza di prodotto o personaggio lungo una serie. Nano Banana Pro. È il modello con una specifica dichiarata, 14 immagini di riferimento e 5 persone coerenti, ciò che serve per una campagna coerente o per uno scatto di prodotto ricorrente.
🔸 Immagini hero o editoriali generali. Testa a testa. GPT Image 2 guida attualmente le classifiche generali di text-to-image, scegliete quindi in base alla preferenza di look. Scegliete Nano Banana Pro se vi serve il 4K direttamente dal modello.
🔸 Integrazione stretta nello stack. Usate quello che gestite già. Un'operazione OpenAI ottiene un'API e sconti batch con GPT Image 2. Un'operazione Google o Vertex ottiene generazione nativa con Nano Banana Pro.

È la stessa disciplina di selezione che applichiamo per i modelli video IA e per image-to-3D con TRELLIS. Scegliete in base al compito, non al logo.

Limiti onesti da entrambe le parti

Nessun modello è privo di compromessi, e sono proprio i compromessi a mordere in produzione.

🔸 GPT Image 2 si ferma a circa 1536px sul lato lungo e offre solo tre proporzioni, quindi perde terreno su formati grandi e forme insolite. Il prezzo a token rende costoso il lavoro incentrato sulle modifiche, poiché anche gli edit calcolano token di immagine in ingresso. La filigrana è costituita da metadati C2PA anziché da un marchio invisibile incorporato, cosa che dovreste verificare rispetto ai vostri requisiti di compliance.
🔸 Nano Banana Pro porta la filigrana invisibile SynthID sull'output, non rimovibile al di sotto del livello enterprise più alto. Alcuni clienti la vogliono via, verificatelo quindi per tempo. Funziona inoltre con costi e latenza più alti rispetto al Nano Banana di base, e Google non pubblica un prezzo netto per immagine, pianificate quindi i costi tramite il calcolatore Vertex.

Nulla di tutto ciò è un criterio di esclusione. È il tipo di dettaglio che decide quale modello si adatta a un determinato requisito del cliente.

Come scegliamo in iiterate

La nostra impostazione predefinita non è la fedeltà a un modello, ma una breve checklist. L'immagine porta testo o richiede il 4K? Deve restare coerente lungo una serie? Quale cloud gestisce già il cliente? Ci sono vincoli di filigrana o di residenza dei dati?

Nella maggior parte dei casi queste quattro domande si rispondono da sole. Il lavoro con molto testo, alta risoluzione o critico per la coerenza va a Nano Banana Pro. Il lavoro editoriale generale e le pipeline native OpenAI vanno a GPT Image 2. Manteniamo entrambi nella cassetta degli attrezzi, proprio perché la risposta giusta cambia da briefing a briefing.

I modelli continueranno a superarsi a vicenda, verificate quindi classifiche e prezzi al momento della decisione. Ciò che resta stabile è l'abitudine: adattare il modello al compito, e allo stack in cui il cliente vive già.

Questo articolo tratta che cos'è TRELLIS, come funziona, dove si inserisce in una vera pipeline di asset e in quali punti smette di essere una risposta a un clic.

Che cos'è TRELLIS

TRELLIS è un modello 3D generativo che prende un'immagine, più immagini o un prompt testuale e produce un asset 3D.

🔸 Latenti strutturati (SLAT). L'idea centrale è un latente unificato che collega una griglia voxel 3D sparsa per la struttura con caratteristiche visive dense per l'aspetto. Disaccoppiare la forma dall'aspetto è ciò che permette allo stesso latente di diventare output diversi.
🔸 Tre output da un latente. Radiance field, gaussiane 3D oppure una mesh esportata come GLB. Il GLB è l'obiettivo pratico, poiché trasporta i materiali nei viewer web e AR.
🔸 Open e con licenza MIT. Il cavallo da lavoro per le immagini, TRELLIS-image-large, ha 1,2 miliardi di parametri. Il modello e la maggior parte del codice sono sotto licenza MIT, il che conta per l'uso commerciale. Una serie 4B più recente aggiunge materiali completi basati sulla fisica, da tenere d'occhio mentre matura.
🔸 Addestrato su larga scala. Circa 500.000 oggetti curati, con il paper come CVPR 2025 Spotlight.

Questo si affianca all'estremo parametrico e controllabile del lavoro 3D, che trattiamo in Grasshopper per il design computazionale. Il 3D generativo e il 3D parametrico risolvono problemi diversi.

Come funziona

La pipeline è breve da descrivere e utile da capire prima di dedicarle una GPU.

1. Input. Una singola immagine, più viste oppure un prompt testuale.
2. Latente strutturato. Un transformer rectified-flow a due stadi genera prima la struttura sparsa e poi riempie le caratteristiche SLAT.
3. Decodifica. Il latente si decodifica nel formato scelto: mesh, gaussiane o radiance field.

In pratica, mettete in conto circa 16 GB di VRAM come soglia minima, con 24 GB si lavora comodamente. La generazione avviene in meno di due minuti su una RTX 4090. Le build della community riducono ulteriormente il fabbisogno di memoria, il che rende TRELLIS realisticamente ospitabile in autonomia invece che noleggiato. Per i team che già valutano l'inferenza locale rispetto a quella ospitata, vale lo stesso compromesso descritto in On-premise contro cloud LLM, anche per i media generativi.

Dove si inserisce in una pipeline di asset

Il punto di massima aderenza è l'inizio della pipeline, dove la velocità conta più della rifinitura.

🔸 Da una foto prodotto o un prompt a un GLB. Inseritelo in un viewer three.js o in un model-viewer sul web, convertitelo in USDZ per l'AR oppure collocatelo in una scena di visualizzazione. Il concepting rapido e le anteprime sono il terreno in cui TRELLIS brilla.
🔸 Editing locale. TRELLIS può rigenerare o raffinare una regione del modello, cosa rara tra i generatori a singola immagine.
🔸 Onesto sulla topologia. L'output è geometria generativa, non pulita a livello artistico. Aspettatevi triangoli irregolari, nessun edge flow pulito e UV generate automaticamente. Per i game o il cinema dovrete retopologizzare, rimappare le UV e ricreare le texture. La serie più recente consapevole dei materiali riduce questo divario senza colmarlo.

Il test di valore per un dato asset è quindi semplice: deve avere un aspetto corretto in un viewer la settimana prossima, oppure deve essere un asset di gioco riggabile e ottimizzato? TRELLIS eccelle nel primo caso ed è un punto di partenza per il secondo.

TRELLIS a confronto con le alternative

Il campo del 3D open e ospitato si è mosso rapidamente. Un breve orientamento:

Dove si colloca TRELLIS: l'opzione davvero sotto licenza MIT più forte, con output multi-formato ed editing locale. Strumenti ospitati come Tripo e Rodin lo superano per topologia pulita fin da subito, e Hunyuan spesso vince sulla texture, ma con una licenza più restrittiva. Se il vostro requisito è possedere il modello e le condizioni legali, TRELLIS è il punto di partenza evidente.

I limiti onesti, e come lo usiamo

Alcune riserve che mettiamo sul tavolo prima che qualcuno integri TRELLIS in produzione:

🔸 Topologia e UV non sono pronte all'uso per il game o il CAD. Mettete a budget il retopo.
🔸 Il CAD è fuori portata. Le mesh generative non sono solidi parametrici, quindi non sono geometria ingegneristica.
🔸 Il rischio dell'input è vostro. Il modello è MIT, ma l'esposizione legale della vostra immagine o del vostro prompt di input è vostra. Non date in pasto foto di prodotto che non potete concedere in licenza.

Trattiamo TRELLIS come un motore di concepting e previz: un modo per portare un asset 3D credibile davanti a un cliente in un pomeriggio, e poi decidere cosa merita una pipeline realizzata a mano. È lo stesso istinto dietro dove è utile l'attuale ondata di modelli video IA, e la stessa disciplina di selezione che applichiamo nella scelta di un modello di immagine. Lo strumento non è la consegna. Il giudizio su dove si inserisce lo è.

Questo articolo mappa entrambi i lati: che cosa sanno fare davvero bene queste piattaforme nel 2026, e i punti concreti in cui dovete aspettarvi di sbattere contro un muro.

Che cos'è davvero un no-code agent builder

Aiuta separare due cose che vengono vendute sotto lo stesso banner.

L'automazione dei workflow è deterministica. Un trigger scatta, passaggi fissi vengono eseguiti, lo stesso input produce lo stesso output. Gli scenari classici di Make o Zapier vivono qui, e con essi molto lavoro utile.

Un no-code agent builder lascia che sia un modello linguistico a decidere il percorso. Descrivete un risultato, e il modello sceglie gli strumenti, chiama le API, legge i vostri documenti e continua a iterare finché non ritiene di aver finito. Il flusso non è cablato in anticipo da voi.

Il confine diventa sfumato perché le piattaforme di automazione hanno avvitato agenti sulle proprie canvas, mentre gli strumenti nativi per agenti hanno aggiunto integrazioni. Per un team delle PMI la domanda pratica non è 'agente o workflow'. È quanto non determinismo lasciate entrare in un processo aziendale, e chi detiene i dati mentre questo è in esecuzione. Abbiamo affrontato la stessa distinzione quando abbiamo scritto della differenza tra un'API, un server MCP e una CLI.

Che cosa sanno fare bene oggi

Impiegati per il compito giusto, questi strumenti si guadagnano rapidamente il loro posto:

🔸 Trigger e integrazioni. Webhook, eventi delle app e pianificazioni attraverso migliaia di connector. Il cablaggio è risolto.

🔸 Chiamate a strumenti. L'agente non si limita a chattare, agisce: interroga un database, pubblica in un sistema, apre un ticket.

🔸 Retrieval sui vostri documenti. Ancorare le risposte alla conoscenza interna è ormai questione di pochi clic, lo stesso schema che trattiamo nel nostro articolo sul RAG.

🔸 Flussi a più passaggi con una persona nel ciclo. Un gate di approvazione prima che accada qualcosa di irreversibile.

Il ritorno è la velocità. Potete dimostrare in giorni che un'idea vale la pena, ed è esattamente a questo che serve un prototipo. Abbiamo costruito la nostra micro-app Event Scout con questo spirito, prima di decidere che cosa meritasse un vero lavoro di engineering.

Dove si fermano

Questa è la parte che la maggior parte delle demo salta, ed è il motivo per cui Gartner prevede che oltre il 40 percento dei progetti agentici verrà abbandonato entro la fine del 2027. La modalità di fallimento raramente è un crash. È più silenziosa di così.

🔸 Affidabilità e non determinismo. La stessa richiesta non produce due volte lo stesso risultato. Gli agenti non si bloccano, derivano: entrano in loop, scelgono lo strumento sbagliato o agiscono su un contesto obsoleto. Il costo si manifesta come qualità e latenza, senza nessuna luce rossa sulla dashboard.

🔸 Valutazione e osservabilità. Le console no-code vi offrono un tracciamento superficiale. Misurare se un agente stia davvero migliorando, lungo un'intera esecuzione a più passaggi e non solo sulla risposta finale, è un'estensione che dovete costruire da soli.

🔸 Governance dei dati e hosting. La maggior parte di queste piattaforme è SaaS statunitense. Per i dati tedeschi questo significa questioni relative a GDPR e Schrems II che non potete ignorare. Le opzioni ospitabili in autonomia, che mantengono i dati sui vostri server UE, sono una lista breve: n8n, Flowise, Langflow, Dify. Approfondiamo questo compromesso in on-premise contro LLM cloud e in che cosa consente davvero il GDPR.

🔸 Costi in scala. La fatturazione per esecuzione e per credito penalizza il volume. Con un modello a crediti, lo stesso agente può costare pochi euro oppure diverse centinaia, a seconda solo di come è stato costruito. I progetti pilota sembrano economici. La produzione spesso non lo è.

🔸 Lock-in e passaggio di consegne. Le canvas proprietarie non si esportano in un vero lavoro di engineering. Quando superate uno strumento no-code, di solito dovete ricostruire, non migrare.

La lente decisionale

Uso cinque domande per decidere se qualcosa resta no-code o sale a un sistema costruito. Valutate ciascuna con basso o alto.

1. Sensibilità dei dati. Riguarda dati personali o regolamentati?
2. Curva di volume e costi. L'utilizzo scala fino a un punto in cui la fatturazione per credito fa male?
3. Livello di affidabilità richiesto. È interno e tollerante, oppure rivolto ai clienti con uno SLA?
4. Complessità della logica. Ramificazione leggera o logica condizionale e stateful profonda?
5. Audit e valutazione. Vi servono eval a livello di traiettoria e una traccia di audit?

Due o più risposte 'alto', e volete una costruzione su misura o ibrida. Altrimenti il no-code è lo strumento giusto, soprattutto per dimostrare valore.

Lo schema che funziona nella pratica non è un aut aut. Prototipate su qualcosa come n8n o Flowise, trovate il percorso che offre davvero valore, e poi consolidate esattamente quel percorso in engineering proprio. Il prototipo non è stato sprecato. Vi ha detto esattamente che cosa costruire.

Come li trattiamo in iiterate

Ricorriamo presto e spesso ai no-code agent builder, poi siamo consapevoli su quando lasciarli. Un agente no-code è un modo rapido e onesto per scoprire se un risultato vale l'engineering che servirebbe per renderlo affidabile. Questo è valore reale, e per molti compiti interni è tutta la risposta.

L'errore che vedo più spesso nelle PMI è trattare una demo funzionante come un sistema finito. Non è la stessa cosa, e il divario tra le due è l'elenco sopra. Se sapete dove passa il confine prima di iniziare, ottenete la velocità senza il progetto abbandonato. Se volete uno sguardo approfondito su dove l'IA si inserisca davvero in un'azienda delle PMI, lo abbiamo scritto in soluzioni di IA per le PMI.

Due avvertenze preliminari per un acquirente tedesco. I prezzi di tutte e tre cambiano spesso, trattate quindi ogni cifra qui riportata come potenzialmente superata e da verificare. E la residenza dei dati è un vincolo reale: nessuna delle tre ospita di default in UE, il che conta prima ancora che dati personali entrino in una conversazione.

Che cosa è davvero ciascuna piattaforma

🔸 ElevenLabs Agents. Costruito sulla qualità vocale per cui ElevenLabs è conosciuta, ora avvolta in un livello di agenti ospitato con telefonia via SIP. La scelta quando la voce dal suono più naturale e il controllo per gli sviluppatori sono i fattori decisivi.

🔸 Retell AI. Infrastruttura di voice agent telefonia-first. Si posiziona su bassa latenza e gestione affidabile delle chiamate, in entrata e in uscita, e vi permette di portare il vostro carrier. La scelta per l'operatività di chiamata in produzione.

🔸 Voiceflow. Una piattaforma visuale e collaborativa per progettare agenti chat e voce, con base di conoscenza integrata. Guidata dal design e no-code-first. La scelta per un team CX o design che itera sui flussi. Notate che qui la voce telefonica live è la più debole delle tre, poiché si appoggia a un fornitore di telefonia separato.

Se il vostro compito è più vicino a un agente testuale o che usa strumenti che a una linea telefonica, vale la stessa logica costruire-contro-comprare descritta in builder di agenti no-code.

Il confronto che conta

Le dimensioni che decidono davvero un progetto di voice agent, una accanto all'altra:

Leggete la tabella come una mappa di compromessi, non come una classifica. Nessuna colonna è la migliore su tutto, ed è proprio questo il punto.

Dove si colloca ciascuna

🔸 Una linea di supporto tedesca che ha bisogno di telefonia e di una voce tedesca naturale. Iniziate con Retell per una gestione affidabile delle chiamate e controllo del carrier, oppure ElevenLabs, se la naturalezza della voce tedesca è il fattore decisivo. Per una sovranità dei dati rigorosa nessuna delle due ospita di default in UE, pianificate quindi Retell self-hosted o un'alternativa EU-native.

🔸 Un team guidato dal design che costruisce un flusso CX. Voiceflow. Il builder visuale, la collaborazione multi-editor e la base di conoscenza permettono a un team senza sviluppatori di iterare. Aggiungete la telefonia separatamente se vi serve la voce.

🔸 Uno sviluppatore che vuole la massima qualità vocale e il controllo proprio. ElevenLabs. Miglior TTS, controllo SDK, agnostico rispetto al modello, SIP per la telefonia.

Lo schema è lo stesso che applichiamo alla maggior parte delle decisioni sugli strumenti: prima nominare il compito, poi scegliere lo strumento che possiede quel compito.

La questione tedesca della residenza dei dati

Questa è la parte che decide se un voice agent sia anche solo consentito, prima ancora che la qualità vocale conti.

La conformità al GDPR non è la stessa cosa dell'hosting in UE. Un fornitore può essere conforme al GDPR e comunque elaborare e archiviare le chiamate su infrastruttura statunitense, il che riapre le questioni Schrems II. Tra queste tre: ElevenLabs offre la residenza dei dati UE solo nel piano Enterprise, Retell la raggiunge tramite self-hosting, e Voiceflow è puro cloud senza opzione di residenza sovrana.

Per una linea di supporto tedesca che elabora dati dei clienti, questo rende la shortlist tanto una decisione di hosting quanto una decisione di funzionalità. È la stessa logica che esponiamo in che cosa consente davvero il GDPR e in on-premise contro LLM cloud: decidete dove i dati possono risiedere, poi scegliete lo strumento che lo rispetta.

Come sceglieremmo noi

Non partiremmo dal marchio. Partiremmo da tre domande: passa per il telefono, chi lo manutiene, e dove possono risiedere i dati.

Se è una linea telefonica, Retell merita il primo sguardo. Se la qualità vocale sostiene l'esperienza e uno sviluppatore la possiede, ElevenLabs. Se un team non tecnico deve progettare e possedere il flusso, Voiceflow. E se i dati non possono lasciare l'UE, il discorso si sposta sull'hosting prima ancora di arrivare alle funzionalità, il che spesso riformula la shortlist.

I prezzi continueranno a muoversi, verificateli quindi di nuovo al momento della valutazione, invece di fidarvi di una singola cifra. La parte stabile è l'adeguatezza al compito, e l'adeguatezza segue il compito.