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.

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.

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é 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.

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.

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.

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.

Questo articolo spiega perché lo abbiamo costruito, cosa sa fare, dove si ferma onestamente, e alla fine pone una domanda aperta.

L'OBBLIGO, IN BREVE E IN MODO CORRETTO

La fattura elettronica nel B2B tedesco non è più un'opzione, ma un obbligo, e il calendario è concreto.

• Dal 1° gennaio 2025 ogni azienda nazionale deve essere in grado di ricevere ed elaborare fatture elettroniche. Senza eccezioni, senza soglia di fatturato, anche per i piccoli imprenditori.
• Fino alla fine del 2026 nell'invio sono ancora ammessi carta o PDF, ma il PDF solo con il consenso del destinatario.
• Dal 2027 le aziende con un fatturato dell'anno precedente superiore a 800.000 euro dovranno emettere fatture elettroniche, dal 2028 tutte le altre.

Per fattura elettronica non si intende un allegato PDF, ma un formato strutturato secondo la norma europea EN 16931. ZUGFeRD è la variante diffusa in Germania: un file PDF/A-3 con XML incorporato. La persona vede un PDF leggibile, il software legge direttamente l'XML, senza dover ridigitare nulla e senza riconoscimento del testo. Il grafico sottostante mostra esattamente queste due viste dello stesso file.

PERCHÉ NON ABBIAMO SEMPLICEMENTE SOTTOSCRITTO UN ABBONAMENTO

Il motivo scatenante lo conoscono tutti: l'obbligo arriva, quindi serve uno strumento. La risposta più ovvia è un abbonamento, ed è proprio lì che ci siamo fermati a riflettere.

Per un'operazione di per sé semplice, generare un PDF con XML incorporato, si accumulano rapidamente costi ricorrenti: gli strumenti di fatturazione più diffusi partono da circa 10 euro al mese e, per l'invio di fatture elettroniche, arrivano a cifre ben più alte a seconda del piano. Per un'azienda che scrive solo poche fatture al mese, si finisce per pagare stabilmente una contabilità completa che non viene nemmeno utilizzata.

Il vero motivo però non era il prezzo, ma i dati. Una fattura contiene nomi, indirizzi e spesso coordinate bancarie. Farla passare per uno strumento cloud significa un trattamento dei dati per conto terzi ai sensi dell'art. 28 del GDPR: un contratto, un fornitore terzo, dati che lasciano l'azienda. In modalità self-hosted questo problema non esiste. È la stessa logica che sosteniamo per i modelli linguistici, come descritto in On-Premise vs. Cloud-LLM: mantenere il beneficio senza cedere la sovranità sui dati.

COSA FA CONCRETAMENTE BELEGT

Belegt è volutamente piccolo e ben delimitato. È un generatore, non un sostituto della contabilità.

Tecnicamente è un'applicazione web che si gestisce sul proprio computer o server. I dati risiedono localmente in un file, e i campi sensibili come le coordinate bancarie sono conservati in forma crittografata. Genera fatture ZUGFeRD e Factur-X nel profilo EN 16931, ossia il livello che conta legalmente come fattura elettronica a pieno titolo, le verifica rispetto alla norma, assegna numeri di fattura progressivi, gestisce i profili di aziende e clienti, e tiene sotto controllo le partite aperte e i report.

Le due cose che ci fanno risparmiare più tempo: un percorso guidato che completa una fattura conforme in pochi passaggi, e il fatto che il file generato porti già con sé la vista macchina di cui ha bisogno il destinatario. Lo usiamo noi stessi, ogni mese. È il consiglio più onesto che possiamo dare: non lo abbiamo costruito per un mercato, ma per noi. È uno dei diversi piccoli strumenti nati così, come lo strumento Event-Scout.

DOVE SI FERMA, ONESTAMENTE

Uno strumento singolo self-hosted ha limiti reali, e tacerli sarebbe esattamente il tipo di marketing che non facciamo.

🔸 La norma si evolve. EN 16931 e le liste di codici vengono aggiornate regolarmente. Un generatore deve essere mantenuto, altrimenti a un certo punto genera fatture non più conformi. È un lavoro che qualcuno deve svolgere.
🔸 La conservazione non è inclusa. Generare non è la stessa cosa che archiviare in modo inalterabile e verificabile. Le norme GoBD richiedono una conservazione immutabile nel formato originale, ormai per otto anni. Un semplice generatore non risolve questo aspetto, resta compito dell'utente.
🔸 Non sostituisce un commercialista. Una fattura tecnicamente valida può comunque essere incompleta nel contenuto. Non esiste un collegamento diretto con lo studio commercialista o con i sistemi contabili.

Riassumendo in modo onesto: Belegt colma la lacuna obbligatoria di generazione e validazione in modo pulito e senza abbonamento. Archiviazione e flusso fiscale restano fuori. Chi confonde questo con una suite completa resterà deluso. Chi ha esattamente questa lacuna riceve uno strumento senza zavorra.

DOVREMMO CONDIVIDERLO, E COME?

Qui l'articolo si chiude volutamente con una domanda invece che con una risposta, perché nemmeno noi lo sappiamo ancora.

Ci sono due strade plausibili. Una: rilasciamo Belegt come soluzione self-hosted che ogni piccola impresa può far girare sulla propria macchina, senza abbonamento e con i dati in azienda. L'altra: offriamo una variante gestita, che manteniamo aggiornata, per la quale aiutiamo nella configurazione e ci facciamo garanti degli aggiornamenti della norma, dietro un contributo equo. Entrambe hanno una loro logica, e l'onere di manutenzione descritto nella sezione precedente è esattamente il motivo per cui la risposta non è banale.

Per questo una richiesta onesta: se uno strumento ZUGFeRD locale, conforme alla protezione dei dati e senza abbonamento fosse utile per voi o per la vostra azienda, scriveteci. Vi basterebbe gestirlo da soli, o preferireste una versione assistita? Proprio questo segnale ci aiuta a decidere se qualcosa che abbiamo costruito per noi diventerà qualcosa che condividiamo.

Claude Code, Codex, Cursor, Antigravity e Opencode risolvono lo stesso compito in modi molto diversi. L'unica domanda che divide il campo è semplice: il vostro codice deve poter uscire di casa? Chi può rispondere sì sceglie in base allo stack. Chi non può, ha esattamente un'opzione seria. Questo testo ordina i cinque strumenti lungo questa domanda e si conclude con la decisione che raccomando a un team tedesco.

CINQUE STRUMENTI, UNA PRIMA DOMANDA

I cinque strumenti si collocano su livelli diversi, e il fattore di forma dice già molto sull'uso previsto.

• Claude Code è un agente da terminale di Anthropic: forte su modifiche multi-file, contesto ampio e un ciclo agentico nel terminale.
• Codex di OpenAI è disponibile come CLI, sandbox cloud e integrazione IDE, con una finestra di utilizzo condivisa.
• Cursor è l'IDE con IA, con modalità agente e agente in background e libera scelta del modello.
• Antigravity è l'IDE incentrata sugli agenti di Google, disponibile dal 20.11.2025, con un'interfaccia manager per avviare e osservare agenti paralleli (Google).
• Opencode è un agente da terminale open source con licenza MIT, indipendente dal modello su molti fornitori ed endpoint self-hosted (opencode.ai).

Come questi strumenti si inseriscano in uno stack, dall'API alla CLI, lo abbiamo illustrato in API, MCP o CLI. Qui si tratta della scelta, e questa inizia con la situazione dei dati.

IL VOSTRO CODICE ESCE DI CASA?

Questa singola domanda ordina il campo più rapidamente di qualsiasi elenco di funzionalità, perché decide su compliance e riservatezza prima che qualunque funzione conti.

Quattro dei cinque strumenti inviano il codice in una cloud altrui. Claude Code, Codex, Cursor e Antigravity girano contro modelli ospitati negli Stati Uniti. Questo non è di per sé un'esclusione: per molti progetti va bene così, e nel piano enterprise si possono negoziare clausole di zero data retention e no-train. Ma il codice esce, e questo va accettato consapevolmente, non trascurato.

Opencode è l'eccezione. Poiché è indipendente dal modello e può rivolgersi a un endpoint locale, gira interamente contro un modello self-hosted. Allora il codice non esce mai di casa. Questa è esattamente la linea di demarcazione che decide tutto il resto. Quale modello open-weight mettiate dietro è una decisione a sé, che affrontiamo in Modello open-weight per il B2B tedesco.

SE IL CLOUD VA BENE: SCEGLIETE IN BASE ALLO STACK

Se accettate consapevolmente la cloud ospitata, allora è lo stack a decidere, non il benchmark. Una mappa sintetica:

La regola pragmatica: chi è in casa Anthropic prende Claude Code, chi è in casa OpenAI prende Codex, un team incentrato sull'IDE prende Cursor o Antigravity. Circolano numeri di benchmark come valori SWE-Bench intorno all'85 percento, ma sono per lo più dichiarazioni dei fornitori e raramente verificati in modo indipendente; io non baserei una scelta di strumento su questi. Cosa renda un agente di coding al di fuori del puro sviluppo lo mostra il nostro articolo Claude Code oltre l'ingegneria.

SE IL CODICE DEVE RESTARE IN CASA: OPENCODE PIÙ UN MODELLO PROPRIO

Se il codice non può uscire, resta un'opzione seria, ed è valida.

Opencode è open source con licenza MIT, dialoga con molti fornitori e, in modo decisivo, con un endpoint locale. Abbinato a un modello open-weight self-hosted, nasce un agente di coding in cui né il codice sorgente né i prompt lasciano la propria infrastruttura. Per dati regolamentati, segreti dei clienti o semplicemente clienti prudenti, questo è spesso l'unico assetto praticabile. Un modello di coding aperto come Kimi K2.7 lo abbiamo esaminato apposta qui.

Il prezzo di questo controllo è il lavoro in proprio: assemblate voi stessi modello, hardware e gestione operativa, non esiste una flotta di agenti cloud gestita. In pratica aiuta dare struttura all'agente, per esempio una mappa della codebase, come l'abbiamo descritta in Graphify. Lo sforzo è reale, ma compra qualcosa che gli strumenti ospitati non possono offrire.

COME LO DECIDO IO

Non vi serve un'unica risposta per tutta l'azienda, ma quella giusta a seconda della situazione dei dati. Ecco come procedo io:

1. Chiarire la situazione dei dati. Il codice in questione può andare in una cloud statunitense? Questa risposta viene dal legale e dal cliente, non dal team di sviluppo.
2. Se sì, scegliere in base allo stack. Casa Anthropic verso Claude Code, casa OpenAI verso Codex, team IDE verso Cursor o Antigravity, ciascuno con condizioni di ZDR e no-train negoziate.
3. Se no, Opencode più un modello proprio. L'unica opzione in cui il codice non esce di casa.
4. Tenere d'occhio il lock-in. Se ogni strumento richiede il proprio vincolo, mantenete aperta una via di ritorno verso un livello più profondo, nel caso un fornitore cambi le condizioni.

Noi stessi lavoriamo con diversi di questi strumenti a seconda del progetto, ed è proprio questo il punto: la scelta è legata al progetto, non alla visione del mondo. Il piccolo strumento interno che abbiamo costruito con un agente invece di commissionarlo si trova in Building event-scout. Quali dei vostri repository oggi non dovrebbero in realtà finire in una cloud altrui, e quale strumento usate comunque per farlo?

Questa è la mappa di questa superficie: a cosa serve ogni parte e dove si trovano gli spigoli vivi.

CINQUE MODI PER ESTENDERE, UN PRINCIPIO

Sotto nomi diversi, ogni punto di estensione fa la stessa cosa: sposta il know-how dal prompt a file versionati che l'agente carica quando gli servono.

• Le skill sono cartelle di istruzioni, script e risorse. Una breve descrizione resta nel contesto; la skill completa si carica solo quando l'agente la ritiene rilevante. Questa è la progressive disclosure: economica da mantenere presente, dettagliata al momento della chiamata.
• Gli slash command sono scorciatoie con un nome che si espandono in un prompt fisso. Il modo semplice per codificare una volta una richiesta ripetuta e riutilizzarla.
• Gli hook sono comandi shell attivati da eventi del ciclo di vita: avvio della sessione, prima di una chiamata a uno strumento, dopo, all'arresto. Un hook pre-tool può controllare e bloccare una chiamata prima che venga eseguita.
• I connector MCP danno all'agente accesso autenticato a sistemi che altrimenti non raggiungerebbe: un database, un issue tracker, un'API interna. Ogni server porta con sé le proprie credenziali.
• I subagent sono istanze di agente a sé stanti, avviate per un sotto-compito mirato, con contesto e istruzioni propri.

Un plugin raggruppa una qualsiasi combinazione di questi elementi in un'unità installabile. Il principio alla base di tutto: codificate il vostro know-how come file nel vostro repository, non come abitudini nella testa di una persona. La variante di integrazione di sistema di questa scelta l'abbiamo trattata in API, MCP o CLI.

SKILL E MCP NON SONO RIVALI

La domanda più frequente in questo momento è "skill o MCP", e la risposta onesta è che risolvono problemi diversi.

MCP è accesso: collega l'agente a un sistema che da solo non raggiungerebbe, con credenziali e stato. Le skill sono know-how: competenza ripetibile che l'agente applica a sistemi che già possiede. L'analogia che circola coglie bene il punto: MCP sono i corridoi del negozio di bricolage, le skill sono il commesso esperto che sa in quale corridoio andare.

L'economia dei token determina la forma di una buona architettura. Una skill costa poche decine di token finché non viene richiamata. Una manciata di server MCP può costare decine di migliaia di token di contesto prima ancora che inizi il primo compito, perché ogni server annuncia in anticipo tutti i suoi strumenti. Lo schema di lavoro verso cui converge la maggior parte dei professionisti è quindi molte skill snelle e pochi connector scelti bene, non un accumulo di tutto ciò che si installa. La demo qui sotto ripercorre i cinque tipi di estensione, nonché il costo e il rischio che ciascuno comporta.

PERCHÉ LO STANDARD APERTO CONTA PER LA SOVRANITÀ

Il cambiamento più utile degli ultimi tempi è che il livello di estensione ha smesso di essere la funzionalità di un singolo fornitore.

Gli Agent Skill sono stati pubblicati come standard aperto nel dicembre 2025, e il formato è stato adottato da diversi fornitori di agenti nel giro di poche settimane. In pratica questo significa che una skill scritta per un harness non vi resta intrappolata. Per un'azienda tedesca che valuta il rischio di essere "legata a un unico fornitore statunitense", questa è una risposta parziale sul livello che potete controllare: il know-how che codificate è portabile, anche se il modello sottostante è preso in affitto.

Combinatelo con connector che puntano a sistemi ospitati nell'UE o on-premise, e la questione della residenza dei dati regge di pari passo con quella delle capacità. Il know-how è vostro ed è portabile; i dati restano dove devono restare. È una posizione più duratura che scommettere il workflow sulla roadmap di un unico fornitore, la stessa considerazione alla base della scelta di un coding agent in base all'harness, non al modello.

OGNI PUNTO DI ESTENSIONE È UNA SUPERFICIE DI ATTACCO

La stessa potenza che rende utile l'harness lo rende pericoloso, e i rischi sono recenti e documentati, non ipotetici.

Gli hook eseguono comandi shell arbitrari, il che costituisce esattamente una superficie di esecuzione. Check Point ha reso pubblica nel febbraio 2026 la CVE-2025-59536: un file di impostazioni malevolo in un repository clonato poteva eseguire hook prima ancora che comparisse la finestra di dialogo di fiducia. Un problema correlato, la CVE-2026-21852, riguardava l'esfiltrazione di chiavi API tramite una sovrascrittura delle variabili d'ambiente. MCP porta con sé un proprio problema di supply chain: ogni server conserva credenziali, e alcune scansioni hanno trovato centinaia di server MCP esposti su internet senza autenticazione. E i marketplace di skill elencano ormai migliaia di skill della community, facili da installare e difficili da verificare, con segnalazioni di skill semplicemente malevole in circolazione.

Nulla di tutto ciò è un motivo per non estendere l'harness. È il motivo per estenderlo in modo consapevole.

GOVERNATE IL CATALOGO, NON COLLEZIONATE PLUGIN

La disciplina che separa un'architettura di produzione da un esperimento scientifico è un catalogo verificato e approvato: un insieme noto di skill, hook e connector che qualcuno ha letto, con un gate di fiducia prima che si aggiunga qualcosa di nuovo.

Non è affascinante, ed è tutto il gioco. Quali hook possono eseguire shell. Quali server MCP conservano quali credenziali. Quali skill sono approvate, e chi le ha approvate. Per un team di una PMI, questo è il punto in cui il sapere istituzionale diventa uno strumento duraturo che sopravvive al ricambio del personale, e in cui il lavoro smette di essere la configurazione ingegnosa di un singolo ingegnere e diventa qualcosa che appartiene all'azienda. Quando abbiamo costruito il nostro strumento interno di scouting come piccola app agentica, il valore non stava nell'ingegnosità, ma nel fatto che il processo era ora un file verificato in un repository invece che un ricordo. Lo abbiamo scritto in Costruire una piccola micro-app agentica.

Il modello potete cambiarlo il prossimo trimestre. Il catalogo delle estensioni è il bene che conservate. La domanda che vale la pena porsi prima di installare il prossimo plugin è quindi semplice: chi lo ha verificato, e a cosa può accedere?

Questo articolo è una panoramica pragmatica: i casi d'uso che reggono, gli incentivi che esistono davvero in Renania-Palatinato (RLP), e l'unico ostacolo che frena quasi tutto.

QUALI SOLUZIONI DI IA REGGONO DAVVERO

Le soluzioni che si dimostrano valide nelle PMI sono poco appariscenti e vicine ai processi esistenti. Fanno risparmiare tempo, raramente generano nuovo fatturato.

🔸 Intelligenza documentale. Leggere e classificare automaticamente fatture, bolle di consegna, contratti ed e-mail. Soglia d'ingresso minima, effetto rapido e tangibile.
🔸 Gestione della conoscenza con RAG. Un sistema informativo aziendale sul patrimonio documentale interno: manuali, documentazione dei processi, offerte, storico assistenza. Alleggerisce onboarding e supporto, e il know-how non si perde con il ricambio del personale.
🔸 Automazione di offerte e fatture. Generare testi di offerta e calcoli a partire dalle pratiche, ordinare i flussi di fatturazione. Con l'obbligo di fatturazione elettronica è comunque all'ordine del giorno.
🔸 Agenti di servizio sul proprio know-how. Supporto di primo livello e FAQ, ancorati ai dati aziendali invece che a un chatbot cloud generico.
🔸 LLM locali per dati sensibili. Elaborare dati del personale, dei clienti, di progettazione o dei pazienti in locale o su hosting tedesco.

La lettura pragmatica: nelle PMI l'IA incide soprattutto sull'efficienza, raramente in modo diretto sul fatturato. Chi non sceglie con precisione il caso d'uso brucia budget, tanto più che la spesa per l'innovazione tende piuttosto a diminuire.

IL QUADRO DEGLI INCENTIVI IN RENANIA-PALATINATO, SENZA MITI

Prima di parlare di incentivi, una premessa di pulizia: molti programmi che circolano sono ormai chiusi o non sono mai stati della Renania-Palatinato (RLP). DigiBoost RLP è chiuso dal 2022, il programma nazionale go-digital è terminato a fine 2024, e il citato buono di digitalizzazione da 20.000 euro appartiene alla Renania Settentrionale-Vestfalia, non a RLP.

Ciò che è realmente attivo nel 2025 e nel 2026:

• Betriebsberatungsprogramm RLP. Attivo da dicembre 2025, contributo tra l'altro per digitalizzazione e intelligenza artificiale. Sostituisce il precedente BITT.
• IBI-EFRE Rheinland-Pfalz. Contributo per l'innovazione aziendale e la digitalizzazione, per le PMI con sede in RLP.
• Innovationsgutschein RLP. Fino a 20.000 euro non rimborsabili per incarichi di ricerca e sviluppo affidati a soggetti esterni.
• Mittelstand-Digital Zentrum Kaiserslautern. Consulenza gratuita e neutrale rispetto ai fornitori, workshop e dimostratori.

L'incentivo, dunque, c'è. Non sostituisce però la decisione su cosa si vuole effettivamente realizzare. È proprio in questo che aiuta la selezione nel grafico qui sotto.

IL VERO OSTACOLO È LA PROTEZIONE DEI DATI, NON LA TECNICA

Quando i progetti di IA falliscono nelle PMI, raramente è colpa del modello. Falliscono sulla domanda di dove possano risiedere i dati.

Il 77% delle aziende indica la protezione dei dati come ostacolo maggiore, davanti alla carenza di personale qualificato con il 70%. Allo stesso tempo il 73% consente ai propri collaboratori l'uso di modelli linguistici, ma solo il 23% li limita a modelli di proprietà aziendale. In parole chiare: circa la metà lascia girare senza controllo modelli cloud liberamente disponibili. Questa non è digitalizzazione, è IA ombra, una fuga di dati annunciata.

A ciò si aggiunge una maturità dei dati insufficiente, quasi un quarto non dispone di dati adeguati, e un legittimo scetticismo sul ROI. Il divario non è tra IA sì o no. Sta tra l'uso informale e un quadro sicuro e produttivo.

SOVRANO NON SIGNIFICA PIÙ COSTOSO, SIGNIFICA GOVERNABILE

La risposta all'ostacolo della protezione dei dati non è rinunciare all'IA. È allineare il luogo di elaborazione alla sensibilità dei dati, non al marketing.

Per compiti non critici un modello cloud è accettabile. Non appena entrano in gioco dati personali, riservati o critici per il business, l'elaborazione deve avvenire in un ambiente tedesco o UE oppure su hardware proprio. Il RAG sul proprio patrimonio documentale, in locale o su hosting tedesco, offre l'utilità di un modello linguistico senza inviare il contenuto all'esterno a ogni richiesta. Quando e perché l'IA locale sia preferibile al cloud lo analizziamo in On-Premise vs. Cloud-LLM, e come funzioni tecnicamente il RAG in Cos'è il RAG.

Resta onesto dirlo: non ogni soluzione deve essere on-premise. L'arte sta nell'assegnazione corretta, e proprio questa non la toglie di mezzo nessuno strumento né alcuna delibera di finanziamento.

UN PRIMO PASSO REALISTICO

Il percorso praticabile è pragmatico e per tappe, non la grande promessa dell'IA tutta insieme.

Dare priorità al caso d'uso da cui dipendono tempo o errori. Verificare le fondamenta dei dati, perché il RAG su un patrimonio caotico non genera valore. Costruire un piccolo pilota con una misura di successo chiara. Solo poi scalare. Queste tappe si possono cofinanziare tramite il Betriebsberatungsprogramm RLP o l'Innovationsgutschein, e affiancare gratuitamente tramite il Mittelstand-Digital Zentrum. Abbiamo descritto il percorso completo nella roadmap pratica per l'IA.

Noi di iiterate abbiamo sede a Koblenz e Remagen e mettiamo insieme esattamente queste tre cose: strategia, realizzazione e compliance. Le PMI di RLP ci stanno già lavorando. Il compito è trasformare la sperimentazione informale in qualcosa di sovrano e solido. Da dove comincereste voi, e dove si trovano i vostri dati più sensibili?

Veo, Kling e Seedance offrono clip impressionanti, ma sono chiusi e gestiti in hosting. Wan Animate di Alibaba è l'unico modello aperto della serie, e dunque la leva interessante per chi non vuole cedere il controllo del materiale. Questo articolo inquadra i quattro modelli per un'azienda tedesca che realizza demo di prodotto e video di marketing, e prende sul serio la normativa che entra in vigore in agosto.

L'AUDIO È DIVENTATO STANDARD, LA QUALITÀ UN OBBLIGO

Il cambiamento più importante dell'anno è che la qualità visibile non è più un vantaggio competitivo, ma un requisito d'ingresso.

L'audio nativo è diventato lo standard. Veo 3 ha introdotto un audio generato in sincrono, e all'inizio del 2026 anche Kling 2.6 e Seedance 2.0 di ByteDance generavano dialoghi e rumori in un unico passaggio. I modelli muti appaiono ormai superati per il lavoro di demo. Allo stesso tempo le clip restano brevi: otto secondi nativi sono la norma, Seedance 2.0 arriva a circa quindici, i pezzi più lunghi nascono per concatenazione, non da un unico blocco.

I laboratori cinesi guidano diverse classifiche. Seedance era in testa ai confronti indipendenti da testo a video nel giugno 2025, davanti a Veo 3 e Kling (arXiv). Queste posizioni cambiano ogni mese. Proprio per questo la scelta non va ancorata alla classifica, ma ai tre criteri che restano stabili.

I QUATTRO A CONFRONTO

Una nota importante sulla denominazione: in ByteDance Seedream è il modello immagine e Seedance il modello video. Qui si parla di Seedance.

• Veo 3.1 (Google, chiuso). Migliore aderenza al prompt, audio sincrono a 48 kHz, l'integrazione più profonda in una pipeline tramite Vertex AI e Flow. Gestito in hosting, l'output porta la filigrana SynthID di Google.
• Kling 2.6 (Kuaishou, chiuso). Ottimo image-to-video e buon movimento, con audio nativo dalla versione 2.6, fino a circa dieci secondi. Raggiungibile via API con conservazione dei dati a Singapore.
• Seedance 2.0 (ByteDance, chiuso). Clip più lunghe, fino a circa quindici secondi, e pianificazione della camera. Accompagnato da una questione legale aperta, dopo che Disney ha inviato una diffida a febbraio 2026, il che rappresenta un rischio reale per l'uso commerciale.
• Wan Animate (Alibaba, aperto). Pubblicato sotto Apache 2.0 e ospitabile in autonomia, specializzato in animazione di figure, trasferimento del movimento e sostituzione di personaggi a partire da un'immagine di riferimento (Hugging Face). Meno rifinito e con clip più brevi rispetto ai modelli in hosting, ma con pieno controllo.

Runway, Sora 2 di OpenAI e MiniMax completano il quadro, ma per la domanda decisiva qui si trovano nella stessa posizione: potenti, ma chiusi.

L'OBBLIGO DI ETICHETTATURA ARRIVA IL 2 AGOSTO

Nel 2026 la vera novità è la normativa, non il prossimo modello. Chi utilizza il video IA a livello commerciale deve risolvere prima la questione dell'etichettatura.

Gli obblighi di trasparenza dell'articolo 50 del regolamento AI Act dell'UE diventano applicabili dal 2 agosto 2026 (EU AI Act). I contenuti sintetici devono essere marcati in modo leggibile dalla macchina, e i deepfake devono essere etichettati. In pratica: la provenienza è una funzione di compliance, non un extra gradevole. I modelli in hosting la includono in parte, Google ad esempio tramite SynthID, altri tramite attestazioni di contenuto C2PA. Wan ospitato in autonomia, invece, non porta alcuna filigrana obbligatoria, quindi l'etichettatura resta nelle vostre mani, come passaggio proprio e documentato della pipeline.

Quali contenuti IA rientrano nel regolamento e cosa va attuato entro quando lo abbiamo illustrato in EU AI Act 2026 e nell'ambito di GDPR e IA.

IL MODELLO APERTO È LA LEVA

Se il materiale non può uscire dall'azienda, il modello aperto è la risposta vera, non quella più bella.

Wan nelle versioni da 2.1 a 2.2 e Wan Animate sono interamente sotto licenza Apache 2.0, quindi piena libertà di uso commerciale, redistribuzione e fine-tuning senza dover chiedere il permesso a casa. La variante più piccola gira su una singola scheda da 24 GB, la variante 14B richiede circa 80 GB. Ospitato in autonomia su infrastruttura europea, se necessario isolata, nessun filmato lascia il vostro controllo, e non ci sono condizioni d'uso di terzi né dipendenza geopolitica. Il prezzo è meno rifinitura e clip più brevi rispetto a Veo o Seedance, cosa che si accetta consapevolmente in cambio della sovranità.

È la stessa logica che applichiamo ai modelli linguistici: un modello aperto e controllato batte l'ultima percentuale di qualità, quando il punto è il controllo (IA europea sovrana). Anche per i modelli del mondo si delinea la stessa strada aperta (NVIDIA Cosmos 3).

COME LO DECIDO PER UN PROGETTO DIMOSTRATIVO

La decisione segue la situazione dei dati e lo scopo, non il demoreel più bello. Ecco come procedo:

1. Materiale sensibile o regolamentato. Se il video mostra prodotti prima del lancio sul mercato, clienti o contenuti interni, allora Wan ospitato in autonomia su infrastruttura UE, con l'etichettatura come passaggio proprio della pipeline.
2. Marketing pubblico, contenuto non critico, rifinitura decisiva. Allora un modello in hosting come Veo o Seedance, ma con condizioni scelte consapevolmente e provenienza chiarita.
3. In ogni caso risolvere l'etichettatura prima del 2 agosto, non dopo.

Nel nostro lavoro creativo mescoliamo questi approcci a seconda del progetto, e il punto non è incoronare un modello vincitore. Il punto è che la qualità visibile è diventata la parte facile, mentre le domande difficili, situazione dei dati, diritti ed etichettatura, decidono l'impiego. Quale dei vostri video in programma affidereste davvero a un servizio statunitense in hosting, e quale appartiene sulla vostra infrastruttura?

Qwen, Kimi, Nemotron e Minimax nel 2026 sono tutti seriamente utilizzabili. Ma solo tre dei quattro portano una licenza davvero libera, solo una famiglia si adatta bene all'hardware delle PMI, e nessun fornitore pubblica un confronto pulito proprio di questi quattro in tedesco. Questo testo ordina i quattro secondo i criteri che un acquirente deve realmente verificare, e termina con la decisione che raccomando a una PMI.

Prima la licenza, poi il benchmark

La licenza è il primo cancello, perché decide su ogni utilizzo commerciale on-premise ancora prima che un solo benchmark conti.

Tre dei quattro sono qui semplici. Qwen3 è sotto Apache 2.0, Minimax M2 sotto MIT, Kimi K2 sotto una licenza MIT modificata (Hugging Face). Sono concessioni vere e libere: uso commerciale, ridistribuzione, fine-tuning, nessuna chiamata a casa.

🔸 Nemotron è il caso particolare.
La Open Model License di NVIDIA non è una licenza Apache o MIT pura. Vincola l'uso alle condizioni di NVIDIA e termina automaticamente se si rimuovono i meccanismi di protezione integrati (NVIDIA). Il modello è buono, ma questa clausola finisce prima sul tavolo dell'ufficio legale, non dell'ingegneria. Abbiamo descritto l'approccio di NVIDIA nel dettaglio nell'articolo su Nemotron 3.

Chi usa la sovranità come argomento dovrebbe saper leggere la licenza come un contratto, perché è esattamente quello che è.

Quanto è buono davvero il tedesco?

La risposta onesta: non esiste un confronto pulito a quattro vie di questi modelli in tedesco, quindi bisogna crearlo da soli.

Un'infrastruttura di valutazione tedesca esiste. SuperGLEBer, la classifica Occiglot Euro-LLM e MMLU-ProX su 29 lingue coprono il tedesco (ACL Anthology). Ciò che manca è un confronto testa a testa pubblicato proprio di questi quattro su testo tedesco. Qwen3 è stato addestrato su 119 lingue ed è la famiglia con il multilinguismo più ampiamente documentato (Qwen); per Kimi, Nemotron e Minimax i fornitori non indicano il tedesco come punto di forza specifico.

La conseguenza pratica è scomoda, ma chiara: le posizioni nei benchmark sui test in inglese dicono poco sulla qualità sui vostri contratti, offerte o testi di supporto in tedesco. L'unico test affidabile è quello sul vostro stesso materiale. Come leggere le classifiche senza lasciarsi ingannare è spiegato nell'articolo sul modello locale.

Che cosa gira sul vostro hardware

La compatibilità con l'hardware ordina il campo più rapidamente di qualsiasi benchmark, perché un modello che non si adatta alle vostre schede semplicemente si esclude da solo.

Qwen3 qui è l'eccezione. Le varianti dense da 4B a 32B girano quantizzate su una o due GPU, e la variante MoE 30B-A3B offre qualità da modello con solo circa 3B di carico di calcolo attivo. Questo è il taglio adatto a un tipico box on-premise nelle PMI.

Kimi K2 e Minimax M2 sono modelli MoE di frontiera. Minimax attiva sì solo 10B parametri, ma i pesi completi richiedono un server multi-GPU; Kimi, con 1 bilione di parametri totali, ancora di più. Nemotron 3 Nano, con 3,6B parametri attivi, è molto parsimonioso e gira su una scheda sola, ma retrocede a causa della licenza. Quanto costi concretamente questa realtà di VRAM lo abbiamo calcolato nell'articolo sull'hardware.

La geopolitica sta nei pesi, non nell'API

Con i modelli open-weight la questione della sovranità si sposta: i pesi girano completamente offline, quindi non esiste un interruttore remoto. Ciò che resta è quanto è incorporato nel modello stesso.

Tre dei quattro laboratori sono cinesi (Qwen, Kimi, Minimax), uno statunitense (Nemotron). Poiché i pesi girano in locale, la vera domanda non è la sede del server, bensì l'orientamento all'interno del modello stesso. Test indipendenti riportano alti tassi di rifiuto dei modelli cinesi su temi politicamente delicati, più marcati in lingua cinese e più deboli, ma presenti, in tedesco (ChinaBench). Questi dati sono autopubblicati e non sottoposti a peer review, quindi vanno letti con cautela, ma l'effetto è abbastanza reale da meritare un paragrafo onesto nel capitolato.

Per il puro lavoro testuale B2B, quindi bozze, estrazione, classificazione e retrieval sui vostri documenti, questo effetto è per lo più gestibile. È una questione di qualità dell'output e di immagine esterna, non una falla di sicurezza. Il quadro più ampio sulla sovranità, i modelli europei e quanto valga davvero l'etichetta li trattiamo nell'articolo sull'IA europea sovrana.

Come lo decido per una PMI

La decisione non è patriottica né guidata dalla classifica, segue un ordine preciso. Ecco come procedo:

1. Verificare la licenza. Solo i modelli con una concessione Apache o MIT autentica entrano nella rosa ristretta senza bisogno di un parere legale. Qui sono Qwen3, Kimi K2 e Minimax M2.
2. Testare sul vostro tedesco. Non il benchmark in inglese, ma cinquanta dei vostri testi reali fatti girare su due candidati e valutati alla cieca.
3. Verificare l'hardware. Ciò che si adatta alle vostre una o due schede vince quasi sempre, perché altrimenti l'esercizio diventa costoso e fragile.

Per la maggior parte delle PMI questo porta a Qwen3 come punto di partenza: licenza libera, ampiamente multilingue, nella giusta fascia hardware. Kimi e Minimax sono la scelta quando il server è comunque già presente e reasoning o agenti sono in primo piano. Il modello di coding open-weight Kimi K2.7 lo abbiamo esaminato apposta per questo.

E, come sempre da noi: costruite l'architettura in modo da poter sostituire il modello. Il prossimo modello open-weight migliore arriverà di sicuro. La vera domanda non è quale sia oggi in testa, ma quali dei vostri compiti abbiano davvero bisogno del modello più potente e quali richiedano solo uno buono, che sia vostro. Quali dei vostri testi affidereste a un modello che non avete testato voi stessi?

Questo articolo è la versione pratica di questa configurazione e la versione onesta dei suoi limiti.

Il vault è il bene, l'agente è in affitto

Tenete separato ciò che è duraturo da ciò che è sostituibile, e la maggior parte del design ne consegue.

Ciò che è duraturo è il vostro vault: semplici file .md, [[Wikilinks]], frontmatter YAML. Nessun database, nessun formato proprietario, nessun passaggio di esportazione. Ciò che è sostituibile è l'agente che lo legge. I due progetti community di riferimento in questo campo, obsidian-second-brain e obsidian-mind, forniscono entrambi supporto deliberato per Claude Code, Codex CLI e Gemini CLI. Il vault è l'investimento; il modello è un inquilino che potete disdire.

È la stessa considerazione che applichiamo al cablaggio dell'IA in qualsiasi stack: possedere l'interfaccia, affittare la capacità. L'abbiamo scritto per l'integrazione di sistemi in API, MCP o CLI. La gestione personale della conoscenza è lo stesso argomento in scala da scrivania.

Che cosa cambia quando un agente può leggere le vostre note

Un agente con accesso ai file trasforma un vault statico in uno che si mantiene da sé, entro i limiti che stabilite.

• CLAUDE.md è il manuale operativo. Eseguite claude dalla directory radice del vault, e questo carica il file a ogni sessione: la mappa delle vostre cartelle, le vostre convenzioni di collegamento, i vostri modelli di nota, i vostri comportamenti predefiniti. È l'unico file portante in qualsiasi configurazione funzionante. /init scrive una prima bozza.
• Il contesto di sessione è un hook, non magia. obsidian-mind inietta all'avvio della sessione un estratto della stella polare, un elenco di attività e una lista dei file, in modo che l'agente non parta a vuoto. È un hook SessionStart che gira sulla vostra macchina, niente di più.
• L'archiviazione diventa uno skill. Slash command e subagent svolgono i compiti di routine: archiviare una nota clippata nella cartella corretta, generare una Map of Content, trovare note orfane, scrivere il log giornaliero. obsidian-second-brain ne fornisce decine.
• Il frontmatter è lo strato leggibile dalla macchina. Data, stato, fonte, un indicatore di confidenza in YAML più i wikilink danno all'agente una struttura per recuperare e incrociare i riferimenti, invece di indovinare dalla prosa.

Lo spostamento più recente sono note che sovrascrivono invece di accodare: una nuova fonte aggiorna e riconcilia le note esistenti invece di accumulare un'altra voce datata. Utile, e il primo punto in cui è opportuna cautela, è la sezione dopo la prossima.

Retrieval, non scarico: la realtà dei token

Non caricate l'intero vault. Lasciate che l'agente recuperi le poche note di cui una domanda ha bisogno.

La configurazione ingenua spinge il vault nel contesto e collassa dopo poche centinaia di note. La configurazione parsimoniosa lascia tutto sul disco e attinge solo ciò che serve, tramite ricerca da riga di comando o grep. I praticanti riportano il divario come circa 100 token per una ricerca CLI nel vault contro decine di migliaia per caricare un intero progetto. Il meccanismo non è affascinante: cercare, leggere le tre note pertinenti, rispondere.

Questo continua a contare, anche ora che Claude Code opera con una finestra di contesto da un milione di token. Il rate limit mobile morde molto prima che la finestra si riempia: un vault che risponde in 100 token vi permette di porre cento domande, dove la configurazione che scarica tutto ve ne concede una manciata. Il retrieval parsimonioso è ciò che rende un secondo cervello utile ogni giorno invece che impressionante una sola volta.

La linea della protezione dei dati è l'inferenza, non l'archiviazione

La community vende "tutto resta nel vostro vault, niente SaaS". Questo è vero per l'archiviazione ed è falso per l'inferenza, e la differenza è tutto il rischio.

Il vostro Markdown resta sul vostro disco. Ma per impostazione predefinita ogni richiesta invia le note rilevanti da leggere a un'API cloud. Per un vault hobbistico con ricette va bene. Per un vault con note su clienti, contratti o qualunque cosa soggetta a un accordo sul trattamento dati, a ogni domanda i dati lasciano la casa. La portabilità del semplice Markdown non è la stessa cosa della protezione dei dati locale.

Altre due riserve oneste. Il prompt injection è strutturale: un agente che legge le vostre note non può separare in modo netto le "istruzioni" dal "contenuto", qualsiasi Markdown che entra nel vault, una pagina web clippata, una nota condivisa, un PDF acquisito, può portare istruzioni secondo cui poi agisce. E il rischio non è ipotetico: nell'aprile 2026 gli attaccanti hanno abusato di plugin della community Obsidian per eseguire codice quando una vittima apriva un vault condiviso, riportato da The Hacker News. Un agente con accesso in scrittura ai file e alla shell aumenta questa posta, non la riduce. Note che si sovrascrivono da sole possono anche inventare silenziosamente un backlink o sovrascrivere una riga corretta, e la modifica è salvata prima che voi la leggiate.

Lo stesso schema, mantenuto sovrano

Tutto ciò che è positivo in questa configurazione sopravvive quando portate il modello in casa. Il problema della protezione dei dati è l'unica parte che richiede il cambiamento.

La versione sovrana mantiene il vault e il workflow e scambia l'inferenza cloud con un modello locale: uno strato di retrieval sopra il vostro Markdown, servito da un modello sul vostro stesso hardware o in hosting UE. Mantenete la sovranità in chiaro, il manuale operativo CLAUDE.md, gli skill, e smettete di inviare i contenuti a ogni domanda. Per un'azienda delle PMI questo è il ponte da un esperimento personale a una vera gestione della conoscenza interna, manuali di prodotto, documentazione di processo, cronologia dell'assistenza, senza che una questione di accordo sul trattamento dati incomba su ogni richiesta. Quando questo passo vale la pena e quanto costa è il tema di On-Premise vs. Cloud-LLM.

L'inquadramento hobbistico dice "costruite un secondo cervello". L'inquadramento aziendale è la stessa macchina, diretta verso il sapere dell'azienda invece che verso il vostro. La domanda interessante è, di nuovo, non se funzioni. È chi può leggere le note. Quindi: dove invia realmente le sue domande il vostro vault proprio adesso?

Questo articolo inquadra entrambe le velocità: che cosa è già forte, dove si inceppa, e che cosa ne consegue per un'impresa del territorio.

La ricerca c'è, ed è densa

Il lato della ricerca non ha nulla da nascondere rispetto a nessun altro Land. È solo fortemente concentrato.

Kaiserslautern porta il nucleo: sede principale del DFKI, la RPTU con otto cattedre di IA, il Fraunhofer IESE e ITWM, oltre a una cooperazione con il Max Planck Institut. Qui ha sede anche il primo centro di innovazione e qualità per l'IA della Mission KI a livello federale, con un budget federale di 32 milioni di euro. Coblenza costruisce il secondo polo: l'università ha avviato a luglio 2025 un hub IA interdisciplinare, e la Hochschule Koblenz gestisce con DigiMit un centro di competenza per la regione.

L'inquadramento onesto sta accanto a questo. Il cluster è concentrato su Kaiserslautern e Coblenza, il territorio è collegato più debolmente, e nel confronto federale la Renania-Palatinato si colloca nella parte alta, non al vertice. Nella digitalizzazione guidano Baviera, Berlino e Amburgo, nell'innovazione il Baden-Württemberg.

Il Land punta esso stesso su un'IA sovrana

Ciò che colpisce è con che cosa lavora il Land: non con un abbonamento cloud statunitense, ma con una propria linea sovrana.

L'agenda IA del Land indica un tris di pilastri IA, e uno dei tre si chiama esplicitamente LLM on-premise. Con GPU4GenAI il Land investe in infrastruttura GPU propria presso il DFKI, e da settembre 2025 è in corso una cooperazione triennale con il DFKI che porta l'IA nell'amministrazione del Land: analisi documentale, piattaforme dati sicure, sistemi di assistenza.

Questo è più di una nota a margine. Se la mano pubblica in Renania-Palatinato costruisce un'IA conforme alla protezione dei dati e gestita in locale, allora la consulenza su on-premise e sovranità per le PMI non è un tema di nicchia, ma un tema in continuità con ciò che il Land sta già dimostrando. Il grafico sotto mostra il problema di fondo: nodi forti, troppo poche linee verso il territorio.

Nelle PMI la situazione è diversa

Al banco di lavoro la velocità è diversa, e i numeri sono sobri.

In un sondaggio della Hochschule Koblenz nella Renania-Palatinato settentrionale (176 imprese, dicembre 2025), solo l'8,5 per cento valuta oggi l'IA come centrale per il modello di business, ma tra cinque anni sarà il 42 per cento. Oltre un quarto usa già strumenti di IA, circa la metà sta testando progetti pilota. Un secondo studio regionale di IHK e Handwerkskammer Koblenz mostra lo schema vero e proprio: quasi due terzi usano l'IA, la maggior parte di questi da al massimo due anni, quasi il 90 per cento si affida a software esterno, e la sfida più citata è la certezza del diritto.

Ricerca di punta e diffusione capillare sono quindi due cose diverse. L'una è presente qui, l'altra non ancora.

Il divario è nell'attuazione, non nella tecnologia

L'ostacolo nelle PMI è raramente il modello. È il percorso dall'idea a un impiego sicuro e produttivo.

A livello federale solo circa un terzo delle imprese ha una strategia IA elaborata, e in Renania-Palatinato viene citata ripetutamente la mancanza di competenze specialistiche come freno. E il quasi 90 per cento che si affida a software esterno acquista così dipendenza, spesso da servizi cloud statunitensi, proprio dove le stesse imprese indicano la certezza del diritto come preoccupazione maggiore. È una contraddizione annunciata.

Va aggiunta una relativizzazione onesta: i tassi di utilizzo sovrastimano la maturità. Molto è uso informale di strumenti liberamente disponibili, senza strategia, senza governance, senza un quadro chiaro di protezione dei dati. Nelle PMI la domanda non è più da tempo se fare IA sì o no. È se farla in modo sovrano e produttivo invece che informale e rischioso. Che cosa questo significhi in pratica lo abbiamo illustrato nella tabella di marcia pratica per l'IA nelle PMI.

Che cosa significa per le imprese della Renania-Palatinato

La strategia più naturale è quella già seguita dal Land: raccogliere benefici senza rinunciare alla sovranità sui dati.

L'elemento mancante non è un ulteriore strumento, ma lo strato tra finanziamento e ricerca da un lato e impiego produttivo e sovrano dall'altro. In concreto significa: modelli locali o ospitati in Germania per i dati sensibili, gestione della conoscenza RAG sul proprio patrimonio documentale, e un percorso sobrio dalla scelta del caso d'uso fino all'esercizio pilota. Quando l'IA locale conviene rispetto al cloud lo inquadriamo in On-Premise vs. Cloud-LLM.

Noi di iiterate abbiamo sede a Coblenza e Remagen, quindi proprio nel mezzo del secondo polo IA del Land, ed è esattamente questo strato di diffusione il nostro lavoro: unire strategia, realizzazione e compliance, invece di lasciare le PMI da sole tra il decreto di finanziamento e il banco di lavoro. La ricerca in Renania-Palatinato è un dato acquisito. La domanda più interessante è quanto velocemente arrivi sul territorio, e chi tracci le linee per farlo.

Questo testo spiega perché il contesto lungo è costoso, quali approcci subquadratici esistono, che cosa delle promesse più clamorose è dimostrato, e che cosa comporta concretamente per il RAG on-premise. La raccomandazione finale non è spettacolare, ed è proprio per questo sostenibile.

Perché il contesto lungo è costoso

Il motivo sta nella matematica dell'auto-attenzione: il suo costo cresce in modo quadratico con la lunghezza dell'input.

In un Transformer classico ogni token viene confrontato con ogni altro. Se la lunghezza del contesto raddoppia, il costo computazionale dell'attenzione si quadruplica all'incirca. A questo si aggiunge la memoria: la cache chiave-valore che il modello porta con sé durante la generazione cresce in modo lineare con la lunghezza e su una GPU fissa consuma rapidamente la memoria disponibile. Questo è il vero collo di bottiglia nell'esercizio on-premise, dove l'hardware è dato e non si può affittare in modo elastico.

È esattamente qui che intervengono gli approcci subquadratici. Cercano di spingere il costo della sequenza verso la linearità, quindi O(n) invece di O(n al quadrato), e di limitare la memoria per token. Che cosa questo significhi per la realtà hardware in azienda lo abbiamo calcolato in LLM locale.

Il panorama subquadratico

Esistono diverse strade, e il vincitore pratico degli anni dal 2024 al 2026 non è il più puro, bensì l'ibrido.

• Modelli a spazio di stato (Mamba). Mamba (dicembre 2023) e Mamba-2 (maggio 2024) modellano le sequenze in tempo lineare con una memoria di stato fissa invece di una cache crescente (arXiv). Il prezzo: uno stato fisso è un compressore con perdita ed è più debole nel ricordo esatto di punti molto lontani nel testo.
• Attenzione lineare (RWKV, RetNet). Riformulano l'attenzione in modo che il costo cresca in modo pressoché lineare. Compromesso simile sulla memoria associativa.
• Ibridi in produzione. Nessuno rilascia modelli puramente subquadratici di qualità di punta. Tutti mescolano invece una minoranza di livelli ad attenzione piena con una maggioranza di livelli a spazio di stato o lineari: Jamba (AI21, 2024), MiniMax-01 (gennaio 2025), Falcon-H1 (maggio 2025), Nemotron-H di NVIDIA, IBM Granite 4.0 (ottobre 2025) e Qwen3-Next (settembre 2025). I livelli pieni preservano la memoria, quelli snelli comprano il vantaggio in termini di costi e memoria.

La linea NVIDIA dietro Nemotron, che usa esattamente questa struttura ibrida, l'abbiamo descritta in Nemotron 3.

Che cosa promette il 'subQ' e che cosa di questo è dimostrato

Il termine richiede cautela, perché porta due significati, uno architetturale e uno di marketing.

Accanto alla famiglia subquadratica generale esiste un prodotto concreto: la start-up Subquadratic è uscita dall'ombra nel maggio 2026 con un finanziamento di circa 29 milioni di dollari e pubblicizza un'attenzione subquadratica e sparsa. I titoli sono altisonanti: un modello di ricerca con 12 milioni di token di contesto, circa un quinto dei costi rispetto ai modelli di punta, un throughput più volte superiore (The New Stack).

La valutazione onesta: una parte è verificata da terzi, ad esempio un risultato RULER-128K, mentre le cifre spettacolari sui 12 milioni di token e sul fattore di velocità sono dichiarazioni del fornitore da singole esecuzioni e non riprodotte in modo indipendente. È un indizio promettente, non una base per gli acquisti. Proprio questa distinzione, dimostrato contro dichiarato, è la disciplina che applichiamo a ogni nuovo modello.

Che cosa comporta per il RAG on-premise

Il vantaggio concreto è memoria e throughput su hardware fisso, ed è esattamente la leva giusta per il RAG on-premise.

• Cache limitata, memoria pianificabile. I livelli a spazio di stato portano uno stato fisso, quindi la memoria non esplode con la lunghezza. IBM dichiara per Granite 4.0 oltre il 70 % in meno di fabbisogno con contesto lungo, un dato del produttore, ma plausibile e nella direzione di più sessioni simultanee per GPU.
• Modello e contesto su una scheda. NVIDIA riporta che un modello Nemotron-H da 51 miliardi di parametri, cache inclusa, entra in una singola scheda da 80 GB, anche questo un dato del produttore.
• Disciplina di chunking più rilassata. Un contesto più economico consente finestre più grandi e un taglio dei documenti meno ansioso.

Le riserve oneste ci stanno. Nel RAG a forte carico di memoria, ad esempio il riferimento esatto su testi molto lunghi, i modelli puramente subquadratici restano ancora indietro rispetto all'attenzione piena, gli ibridi colmano il divario in gran parte ma non del tutto. L'ecosistema degli strumenti, quindi quantizzazione, serving e fine-tuning, è ancora indietro rispetto ai modelli densi affermati. E la frase più importante: contesto lungo non equivale a buon retrieval. Un modello solido con un buon RAG oggi batte quasi sempre il tentativo di riversare semplicemente milioni di token. Che cosa faccia esattamente il RAG è spiegato in Che cos'è il RAG e Il potere del RAG.

Come lo tratto oggi

Il subquadratico merita di essere osservato, ma non merita una scommessa. Ecco come lo tratto:

1. Costruire il livello RAG in modo indipendente dal modello. Dietro un'interfaccia stabile, così da poter inserire un ibrido della classe Granite 4 non appena l'ecosistema degli strumenti sarà maturo.
2. Partire con un modello solido e ben supportato, non con l'architettura più recente, e ricavare il valore dalla qualità del retrieval.
3. Ignorare le promesse non dimostrate. Un fattore mille dichiarato aspetta finché qualcuno di indipendente non lo riproduce.

È lo stesso schema che applichiamo nel confronto tra on-premise e cloud: decidere consapevolmente, costruire in modo sostituibile (On-Premise vs. Cloud-LLM). La domanda interessante non è se i modelli subquadratici renderanno un giorno il contesto lungo economico. Probabilmente lo faranno. La domanda è se la vostra architettura sia pronta a coglierne il vantaggio, senza scommetterci oggi. Il vostro livello RAG è costruito in modo tale che possiate sostituire il modello senza dover riscrivere tutto?

La maggior parte dei team che integrano l'IA nei propri sistemi non deve incoronare un vincitore. Deve collocare ogni chiamata all'altezza giusta. Questo articolo definisce i tre livelli in modo sobrio, mostra quando ciascuno è adatto, indica i costi spesso trascurati e si conclude con una decisione che potete difendere. Due domande chiariscono la maggior parte dei casi: quante integrazioni gestite, e chi deve verificarle?

Tre livelli, non tre rivali

Ogni modello si colloca a un diverso livello di astrazione, con un compromesso chiaro tra controllo e comodità.

• Una chiamata API diretta è il mattone più basso. Il vostro codice richiama un modello o un servizio via HTTP. Ottenete il massimo controllo e strumenti standard, e scrivete voi stessi il collante: autenticazione, richiesta, parsing della risposta, gestione degli errori.
• MCP, il Model Context Protocol, standardizza la connessione, non il modello. È uno standard aperto introdotto da Anthropic nel novembre 2024, che offre a un modello un modo uniforme per scoprire e richiamare strumenti e dati, cosicché un client compatibile con MCP possa dialogare con un server MCP mai visto prima (Wikipedia). Si è diffuso rapidamente: nel corso del 2025 è stato adottato da OpenAI, Google e Microsoft, ha raggiunto oltre 5.800 server della community entro aprile 2025 e ha registrato cifre a due cifre di milioni di download mensili dell'SDK entro fine 2025, prima che Anthropic lo trasferisse a un'iniziativa della Linux Foundation (Thoughtworks, The New Stack).
• Una CLI agentica è il livello più alto. Uno strumento come Claude Code combina un modello, un insieme di strumenti e un ciclo di ragionamento in un flusso di lavoro da terminale. Il minimo collante, il massimo dell'opinione, la massima velocità per compiti aperti.

Si completano a vicenda invece di competere: una CLI agentica può richiamare server MCP che a loro volta incapsulano semplici API (iiterate).

Quando ciascuno si colloca alla giusta altezza

La scelta segue la forma del compito, non la novità dell'opzione. Un breve orientamento:

In pratica: un batch job notturno che interroga un endpoint dovrebbe chiamare l'API direttamente, perché MCP, senza alcun beneficio, aggiungerebbe solo latenza e potenziali fonti di errore. MCP si giustifica non appena più agenti hanno bisogno delle stesse integrazioni, cosicché ogni client MCP ottenga un'interfaccia uniforme invece che ogni agente porti il proprio wrapper. Il punto di svolta riportato dai professionisti si colloca intorno a tre o più integrazioni collegate all'IA (MindStudio). Una CLI agentica è adatta quando il compito è aperto e qualcuno ha bisogno di risultati rapidi attraverso molti strumenti.

I costi che si trascurano

I vantaggi evidenti sono facili da individuare. Sono i costi più silenziosi a decidere se una scelta invecchia bene.

• Token. Un livello di strumenti standardizzato non è gratuito. Se un agente richiama ripetutamente uno strumento, l'overhead di discovery di MCP può costare, per lo stesso compito, molti più token di una chiamata diretta via CLI o API (MindStudio).
• Osservabilità. Le chiamate HTTP compaiono nei vostri log, e strumenti standard come Datadog le tracciano gratuitamente. Il trasporto MCP è relativamente opaco, e il monitoraggio in produzione è ancora in fase di maturazione, per cui pagate con strumentazione propria (IJONIS).
• Lock-in e portabilità. Una pura API mantiene l'integrazione in codice di vostra proprietà. Più si sale di livello, più si dipende da un client, da un ecosistema di server o dall'agente di un fornitore. Tenetevi aperta una via di ripiego a un livello più basso.

La superficie di sicurezza di MCP è nuova e reale

Standardizzare il modo in cui i modelli raggiungono gli strumenti standardizza anche una nuova superficie di attacco, e questa merita una trattazione esplicita.

OWASP indica il prompt injection come la vulnerabilità più importante per le applicazioni LLM nel 2025. MCP aggiunge una variante specifica, il tool poisoning, in cui istruzioni malevole vengono incorporate nella descrizione di uno strumento, più vicino a un attacco alla supply chain sul contesto dell'agente che a un jailbreak lato utente, ed è classificato come CVE-2025-54136 (TrueFoundry). Poiché i server MCP spesso custodiscono credenziali e raggiungono sistemi reali, un server con permessi troppo ampi o non affidabile rappresenta un rischio serio, e la protezione lato client varia molto (Simon Willison, Microsoft). L'atteggiamento pratico: gestire server verificati, assegnare a ciascuno il privilegio minimo e continuare a monitorare, le stesse questioni di governance che valgono non appena un agente tocca dati reali (iiterate).

Una decisione che potete difendere

Non serve un'unica risposta per tutta l'azienda. Serve l'altezza giusta per ogni integrazione. Una regola praticabile:

1. Per impostazione predefinita, un'API diretta per una singola chiamata stabile ad alto volume.
2. Ricorrete a MCP quando più agenti hanno bisogno degli stessi strumenti o volete strumenti intercambiabili dietro un'unica interfaccia.
3. Utilizzate una CLI agentica quando il lavoro è aperto e una persona o un altro agente lo guida.
4. Mantenete a ogni livello il privilegio minimo, log reali e una via per ripiegare a un livello più basso, nel caso un fornitore cambi le condizioni.

Per la maggior parte dei sistemi in produzione, la risposta onesta è un mix: API dirette sotto i servizi, MCP come livello di traduzione e discovery per gli agenti, e una CLI dove lavorano le persone. La modalità di errore non è scegliere lo strumento sbagliato. È adottare il livello più recente solo perché è il più recente, e pagarne i costi per un compito che un livello più basso avrebbe gestito meglio.

Il nucleo dell'articolo non sono gli eventi. È la forma. event-scout è una micro-app agentica: qualcosa che si costruisce una volta con un agente di coding e poi si lascia girare, dove l'agente si occupa del giudizio difficile e semplici script svolgono il cablaggio noioso e ripetibile. Questa suddivisione è tutta la lezione, e si trasferisce a quasi ogni compito interno che un team di una PMI continua a svolgere a mano. event-scout gira sul livello più alto di questi strati, una CLI agentica (iiterate).

COSA FA CONCRETAMENTE

Una volta per ogni esecuzione, event-scout attraversa un database di fonti curato, composto da siti di eventi, calendari, newsletter e alcuni feed LinkedIn. Da tutto ciò che recupera, conserva solo eventi futuri in presenza raggiungibili da Remagen, valuta ciascuno in base a quanto sia utile per noi, elimina i doppioni in un unico archivio e ricostruisce una dashboard che apriamo davvero.

Poco in questo elenco è nuovo di per sé. Ciò che lo fa funzionare è che gira senza supervisione secondo una pianificazione e che il giudizio applicato è il nostro, non un filtro di rilevanza generico. Il risultato non è un feed di ogni evento tech in Germania. È una risposta breve e ordinata a una domanda: dove dovremmo presentarci la prossima volta.

LA FORMA CHE LO HA FATTO FUNZIONARE: AGENTE PER IL GIUDIZIO, SCRIPT PER IL CABLAGGIO

La decisione di design che conta è dove finisce il modello e dove inizia uno script.

Il recupero dei dati è delegato a un helper deterministico. Un piccolo orchestratore Node esegue il rendering di ogni fonte in scadenza in un vero browser headless, così da gestire pagine JavaScript, leggere barriere anti-bot e liste caricate lentamente, e cattura i dati strutturati schema.org degli eventi quando una pagina li rende disponibili. Questo è cablaggio: affidabile, prevedibile e uguale ogni volta.

L'agente legge ciò che il recuperatore ha salvato e si occupa delle parti che sfuggono alla codifica fissa: estrarre eventi reali da pagine caotiche, decidere cosa conta come presenza e come rilevante, valutare ciascuno e riconoscere che due voci si riferiscono allo stesso evento. Un secondo piccolo motore poi unisce i dati, rimuove le voci vecchie e ricostruisce la dashboard.

🔸 Non fate fare al modello ciò che uno script svolge a basso costo.
Eseguire il rendering di una pagina e scrivere un file è lavoro deterministico. Affidarlo al modello sarebbe più lento, più costoso e meno affidabile.

🔸 Non fate fare a uno script ciò che richiede giudizio.
Se una voce formattata a metà sia un evento reale, rilevante e in presenza è esattamente la decisione in cui un modello è bravo e un'espressione regolare no.

Tracciare correttamente questa linea è la parte più importante del motivo per cui lo strumento è affidabile e non solo una demo intelligente.

SI CALIBRA DA SOLO

Uno scout che controlla ogni fonte allo stesso modo a ogni esecuzione spreca gran parte del proprio sforzo, perché gli eventi non emergono in modo uniforme.

Quindi ogni fonte porta la propria breve storia di resa. Le fonti che forniscono in modo affidabile eventi rilevanti vengono controllate a ogni esecuzione. Le fonti che tornano ripetutamente vuote passano a una fase di raffreddamento crescente, una settimana, poi due, poi un mese, e vengono ritestate alla scadenza invece di essere scartate. Una fonte che semplicemente non ha fornito eventi viene retrocessa silenziosamente; solo una fonte che non si carica più volte di fila viene eliminata come guasta.

L'effetto è che l'attenzione fluisce dove gli eventi compaiono davvero, e che il sistema si ricalibra da solo nel corso delle settimane, senza che nessuno lo mantenga. È proprio questa autocalibrazione a rendere "senza supervisione" un'affermazione reale e non solo una speranza.

UNA VALUTAZIONE CON UN PUNTO DI VISTA BATTE UN FEED GENERICO

La valutazione è volutamente nostra. Ogni evento riceve un punteggio su 100, ponderato per la nostra situazione: quanto è vicino e facilmente raggiungibile, quanto densamente lo spazio raduna il tipo di acquirenti che serviamo, quanto è intimo, se esiste una leva concreta come uno sconto o uno slot per un intervento, e quanto presto si svolge.

La ponderazione porta con sé un'opinione che abbiamo sulle vendite. Una grande conferenza si posiziona in alto solo se c'è una leva reale da sfruttare, perché per la vendita basata sulle relazioni una sala piena senza accesso vale meno di una piccola tavola rotonda regionale dove possiamo davvero parlare con le persone. Il risultato si legge come un cruscotto decisionale piuttosto che come un calendario: mostra dove investire una giornata, non tutto ciò che esiste.

Un feed di eventi generico non potrebbe rappresentare questo, perché il giudizio è specifico per il modo in cui un determinato team acquisisce incarichi. Questa specificità è il motivo per cui è valsa la pena costruirlo invece di comprarlo.

PERCHÉ UNA MICRO-APP E NON UN SAAS

event-scout è volutamente piccolo. Il tutto è una manciata di file JSON per le fonti e l'archivio eventi, alcuni script e una dashboard HTML autonoma che si apre direttamente dal disco. Non c'è nessun database da gestire e nessun abbonamento da rinnovare. I dati restano nostri, e così anche la valutazione.

È lo stesso passo che i team non ingegneristici di Anthropic hanno descritto, costruire piccoli strumenti interni con un agente di coding invece di inoltrare una richiesta e aspettare (claude.com). Abbiamo scritto di questo schema anche dal punto di vista dell'utente (iiterate).

Non è privo di spigoli, e affermare il contrario sarebbe disonesto. Le fonti protette da login richiedono una volta una sessione acquisita a mano. Alcune pagine ostinate restano lead manuali invece di risultati errati. E verifichiamo ogni ricostruzione controllando direttamente la struttura della pagina, perché uno screenshot resta bloccato su un caricamento dei font. Nulla di tutto ciò cambia la conclusione: se un compito è ripetibile e specifico per il vostro modo di lavorare, un agente di coding può trasformarlo in un piccolo strumento di vostra proprietà, per meno del SaaS o delle ore manuali che sostituisce. La domanda più difficile non è se potete costruirne uno. È quale dei vostri obblighi settimanali stesse silenziosamente aspettando di diventarlo.

Claude Code è costruito per sviluppatori, ma il lavoro che ci ha tolto silenziosamente dalle mani riguarda il marketing e il backoffice: i compiti ricorrenti e vincolati a regole che nessuno fa volentieri. Il motivo per cui si adatta bene lì è semplice. Chi conosce un processo, le regole del brand, la checklist di chiusura mensile, il modo in cui taggiamo un export di campagna, scrive quel processo una volta in linguaggio chiaro, e l'agente lo esegue su file reali. Nessun progetto software, nessuno sviluppatore coinvolto. Questo articolo racconta ciò che abbiamo imparato: dove ripaga, dove no, e come iniziare senza rimpianti.

Il vero cambiamento non è il coding. È mettere per iscritto il processo

Per una persona non sviluppatrice, un agente di coding è un modo per trasformare un processo ricorrente in qualcosa che una macchina esegue, senza dover prima costruire software.

Il meccanismo che rende questo possibile al di fuori dello sviluppo sono le Agent Skills. Uno skill è una piccola cartella: un file di istruzioni in linguaggio chiaro, opzionalmente uno o due script e il materiale di riferimento necessario. L'agente vede solo il nome di uno skill e una descrizione di una riga finché il vostro compito non ne ha bisogno, poi legge le istruzioni complete all'occorrenza. Simon Willison, che ha documentato il formato al momento della sua pubblicazione nell'ottobre 2025, ha riassunto chiaramente l'economia della cosa: ogni skill costa solo qualche decina di token finché non viene utilizzato (simonwillison.net, Anthropic).

La conseguenza è la parte che conta per un team di PMI:

🔸 L'autrice è un'esperta di dominio, non una programmatrice.
La persona che conosce il processo scrive lo skill, proprio come istruirebbe un nuovo collaboratore.

🔸 I connector gli danno una portata reale.
Tramite MCP, uno standard di connettori aperto, l'agente può leggere e agire su sistemi reali, in un foglio di calcolo, in un'unità condivisa, in una coda di ticket, entro i limiti dell'accesso che concedete.

🔸 Siete voi a stabilire il raggio d'azione.
Tocca solo ciò che gli permettete di toccare. Questo limite di autorizzazione è tutto il gioco, e ci torneremo più avanti.

Tre compiti poco spettacolari in cui rende davvero

I benefici sono poco appariscenti e ricorrenti. Tre schemi si sono dimostrati validi da noi e nei resoconti pubblici.

Varianti di marketing in grande numero. Il team growth marketing interno di Anthropic ha collegato due sub-agenti specializzati per leggere un CSV con centinaia di annunci attivi, segnalare quelli deboli e scrivere varianti fresche entro rigidi limiti di caratteri, minuti di lavoro invece di ore. Un plugin Figma di supporto genera fino a 100 varianti di layout per esecuzione, scambiando titoli e descrizioni (claude.com). È il loro team, quindi leggetelo come prova che lo schema funziona, non come il vostro numero.

Ripulire i dati di backoffice. Il tedioso metà settimana: convertire un estratto conto della carta in una nota spese, ripulire una lista disordinata, redigere un report ricorrente da un modello. Un singolo fondatore non tecnico su r/SaaS ha descritto come abbia fatto girare praticamente tutta la sua operazione SEO tramite Claude, riportando 1,54 milioni di impressioni di ricerca e 12.900 clic in tre mesi, senza sviluppatori e senza agenzia (r/SaaS). Il resoconto di una singola persona, ma istruttivo.

Strumenti interni, costruiti da chi ne ha bisogno. Il dipartimento legale di Anthropic ha prototipato un piccolo "albero telefonico" che instrada una domanda alla giurista giusta, costruito da una giurista di prodotto che non scrive codice (claude.com). La parte interessante non è lo strumento. È chi lo ha costruito, e che per farlo non serviva alcun ticket.

Ne abbiamo già scritto in precedenza: dove l'IA merita davvero un posto in un'azienda invece di limitarsi a fare bella figura in una demo (iiterate); questo è lo stesso test, applicato a uno strumento.

Perché proprio marketing e operations

Queste funzioni si adattano perché il loro lavoro è ricorrente, vincolato a regole e già presente in file.

Questo coincide perfettamente con ciò che uno skill può racchiudere. Uno skill sulle linee guida del brand porta la palette, le regole tipografiche e il tono di voce. Uno skill di processo porta la checklist di chiusura o un passaggio di compliance. Uno skill di modello porta il documento stesso. Anthropic fornisce uno skill funzionante sulle linee guida del brand come esempio pubblico, con regole di colore, tipografia e layout che un agente applica su richiesta (GitHub, Anthropic).

Il riscontro ricorrente in questi resoconti è che la competenza di dominio guida il risultato più della capacità di programmare. Questo è il vantaggio silenzioso delle PMI. La persona che conosce il processo è già in casa, e uno skill non è altro che il suo processo messo per iscritto.

Dove è lo strumento sbagliato

Un agente di coding è lo strumento sbagliato nel momento in cui il lavoro smette di essere ricorrente, verificabile o sufficientemente sicuro per un agente con ampi permessi. I rischi onesti, nell'ordine in cui mordono:

Raggio d'azione. Un agente con accesso a file e sistemi può cancellare la cartella sbagliata o inviare il messaggio sbagliato. Dategli il privilegio minimo: prima solo accesso in lettura, una cartella, una copia dei dati, non l'originale. I team di sicurezza hanno catalogato cosa va storto quando questo passaggio viene saltato (Docker, Oso).

Affermazioni false ma sicure di sé. Citerà un numero che non ha verificato, in prosa fluente. Mantenete un punto di controllo umano per tutto ciò che esce dall'azienda.

Governance e dati. Nel momento in cui tocca dati personali o dei clienti, si applicano il GDPR e l'AI Act. Sapete dove risiedono i dati e chi può essere sottoposto ad audit prima di collegarlo, la stessa domanda di controllo che sta dietro alla scelta di gestire modelli di proprietà invece di prenderli in affitto (iiterate).

Provenienza. La maggior parte dei casi di studio ben confezionati, inclusi due in questo articolo, provengono da fornitori. Leggeteli come prova che il lavoro è possibile, non come prova del vostro ritorno sull'investimento.

Come iniziare senza rimpianti

Iniziate in piccolo, con un lavoro in cui potete permettervi un errore.

1. Scegliete un compito che sia ricorrente e vincolato a regole e che non sia il vostro processo più importante.
2. Scrivete il processo come skill in linguaggio chiaro, così come istruireste una nuova risorsa capace al suo primo giorno.
3. Concedete l'accesso minimo possibile: solo lettura, una cartella, una copia dei dati.
4. Mantenete un punto di controllo umano per tutto ciò che esce all'esterno o tocca dati personali.
5. Misurate in base alla metrica poco spettacolare, le ore risparmiate nella procedura noiosa, non in base a come vi è sembrata la demo.

Fatto così, i benefici sono piccoli e si sommano, il che è l'opposto di come questa tecnologia viene di solito venduta. La domanda su cui vale la pena soffermarsi non è se un agente di coding possa svolgere lavoro di marketing o di operations. È quali dei vostri processi avete effettivamente messo per iscritto, perché è questo, non il modello, a decidere quanto lontano si arriva.

Il parere centrale dell'EDPB (Comitato europeo per la protezione dei dati) sui modelli di IA si basa sulla formula "caso per caso", e la linea guida congiunta di EDPB e Commissione Europea su come il GDPR si interseca con l'AI Act non è attesa prima dell'inizio del 2026. La domanda utile non è quindi "l'IA è consentita sotto il GDPR". È "a quali condizioni, e quali di queste condizioni controlliamo effettivamente". Questo articolo mappa i pochi confini rigidi, la vasta zona intermedia condizionata e le leve che un team di PMI può azionare. È orientamento, non consulenza legale, quindi coinvolgete il vostro responsabile della protezione dei dati prima di agire.

INIZIATE DALLE POCHE COSE REALMENTE LIMITATE

Un breve elenco di utilizzi dell'IA è vicino a un vero divieto sotto il GDPR. Conoscerlo per primo rende più facile ragionare sul resto.

• Decisioni interamente automatizzate su persone. L'articolo 22 limita le decisioni con effetti giuridici o similmente rilevanti prese senza un coinvolgimento umano significativo. Le autorità di controllo tedesche lo interpretano in modo rigoroso e si aspettano una supervisione umana effettiva, non un'approvazione formale (Hogan Lovells).
• Categorie particolari di dati, di default. I dati sanitari, biometrici, relativi alle convinzioni personali e simili sono in linea di principio esclusi dal trattamento ai sensi dell'articolo 9, a meno che non si applichi un'eccezione specifica. L'AI Act crea un'apertura ristretta: l'articolo 10, paragrafo 5, consente tali dati strettamente per individuare e correggere distorsioni nei sistemi ad alto rischio (IAPP).
• Modelli basati su dati raccolti illecitamente. Il parere EDPB 28/2024 del 18 dicembre 2024 stabilisce che lo sviluppo di un modello con dati personali trattati illecitamente può compromettere la liceità del suo utilizzo, a meno che il modello non sia stato adeguatamente anonimizzato (EDPB).

La maggior parte del lavoro sull'IA si colloca al di fuori di questo breve elenco, dove la risposta è raramente un netto "no". È un "sì, se".

LA MAGGIOR PARTE È CONDIZIONATA, NON VIETATA

La grande zona intermedia del lavoro sull'IA è lecita se riuscite a dimostrare e documentare le condizioni giuste.

Due condizioni fanno la maggior parte del lavoro. La prima è una base giuridica. Per l'addestramento e l'uso di modelli con dati personali, l'EDPB ha proposto un test a tre fasi per il legittimo interesse, che pesa l'interesse stesso, la necessità del trattamento e un bilanciamento con i diritti degli interessati (EDPB). Il legittimo interesse è disponibile, ma va guadagnato attraverso questo test, non presupposto.

La seconda è l'anonimità, che non potete dichiarare da soli. Lo stesso parere stabilisce che un modello addestrato su dati personali non è automaticamente anonimo. È considerato anonimo solo se è molto improbabile sia identificare le persone i cui dati lo hanno addestrato, sia estrarre tali dati tramite query, valutato caso per caso dall'autorità di controllo (IAPP). Il parere si basa così tanto sulla formula "caso per caso" che analisti legali ne hanno contato le occorrenze nel testo (Ropes & Gray). La lettura pratica: la maggior parte del trattamento IA è consentita, a condizione che possiate dimostrare la vostra base giuridica e la vostra documentazione.

LE CONDIZIONI SONO PERLOPIÙ ARCHITETTURALI

La parte incoraggiante è che le condizioni da soddisfare dipendono in gran parte da come costruite il sistema, non da chi siete.

• Conservare meno, per meno tempo. La minimizzazione dei dati e la limitazione della finalità si applicano nei punti specifici dell'IA dove i dati si nascondono: i log dei prompt e di sistema, e i vettori in un archivio RAG. Le linee guida dell'EDPB indicano di minimizzare ciò che viene registrato, preferire identificatori aggregati o pseudonimi e mantenere breve la conservazione (analisi EDPB).
• Decidere consapevolmente dove risiedono i dati. Dalla sentenza Schrems II, il trasferimento di dati personali a un fornitore statunitense non è risolto con la sola firma delle clausole contrattuali standard. Dovete verificare se tali clausole possano essere effettivamente fatte valere alla luce del diritto di sorveglianza statunitense, e questa responsabilità non può essere delegata al fornitore (analisi).

Questo è il motivo pratico per cui la residenza dei dati e il funzionamento on-premise sono leve di controllo e non ideologia, lo stesso punto alla base dell'utilizzo di modelli che possedete invece di noleggiare (iiterate).

IL GDPR E IL REGOLAMENTO EUROPEO SULL'IA SONO DUE REGIMI, NON UNO

Aiuta trattare protezione dei dati e regolamentazione dell'IA come obblighi separati che si incontrano, invece che come un unico corpo normativo.

Il GDPR è un regime di diritti fondamentali sui dati personali; l'AI Act è più vicino al diritto della sicurezza dei prodotti per i sistemi di IA (IAPP). Un sistema ad alto rischio può dover rispettare obblighi da entrambi: una valutazione d'impatto sulla protezione dei dati ai sensi dell'articolo 35 del GDPR e una valutazione d'impatto sui diritti fondamentali ai sensi dell'articolo 27 dell'AI Act, che la integra invece di sostituirla. I due si intrecciano anche in modo scomodo. I professionisti del settore segnalano ad esempio che il profiling sotto il GDPR può far rientrare nell'ambito di applicazione un sistema che un'eccezione dell'AI Act sembrava aver escluso (r/gdpr). L'aiuto ufficiale è in arrivo: EDPB e Commissione Europea dovrebbero pubblicare all'inizio del 2026 linee guida congiunte sulla sovrapposizione (IAPP).

UNA POSTURA DI COMPLIANCE SOSTENIBILE PER UN TEAM DI PMI

Non vi serve una certezza che l'autorità di controllo non ha fornito. Vi serve una posizione solida e documentata. Un ordine pratico:

1. Mappate dove i dati personali entrano nel sistema: input, prompt, log, dati di addestramento e l'archivio RAG.
2. Scegliete e documentate una base giuridica per ogni utilizzo. Se vi basate sul legittimo interesse, eseguite il test di bilanciamento invece di presupporlo.
3. Eseguite una valutazione d'impatto prima di implementare qualcosa che profila le persone o decide su di esse, e mantenete un essere umano significativamente coinvolto per i casi dell'articolo 22.
4. Minimizzate e limitate nel tempo ciò che il sistema conserva, in particolare i log dei prompt e i vettori.
5. Decidete consapevolmente la residenza dei dati. Se i dati personali dovessero lasciare l'UE, eseguite la verifica sul trasferimento oppure mantenete il trattamento nell'UE o on-premise.
6. Rivedete la posizione quando usciranno le linee guida congiunte di EDPB e Commissione nel 2026.

In sintesi: sotto il GDPR pochissimo dell'IA è vietato in modo categorico, poche cose lo sono davvero, e il resto è per lo più un documentato "sì, se". Le condizioni che lo determinano sono per lo più architetturali, il che significa che siete voi a stabilirle. Le stesse questioni di governance emergono nel momento in cui un agente interno tocca i dati dei clienti (iiterate). Questo resta orientamento e non consulenza legale, quindi fate del vostro responsabile della protezione dei dati il prossimo lettore.

La scena europea dei modelli, Mistral e gli attori che le orbitano attorno, nel 2026 dispone di denaro reale e di modelli reali. Allo stesso tempo, in termini di pura capacità resta dietro ai vertici statunitensi e cinesi, e la parola europeo su un'etichetta non significa di per sé sovrano. Per un'impresa delle PMI la domanda utile non è quindi se esista un modello europeo. È di quale tipo di controllo abbiate davvero bisogno e che cosa esso vi offre. Questo articolo espone il panorama, i divari onesti e la decisione che vi sta sotto.

Che cosa significa davvero sovrano, e che cosa no

IA sovrana significa che il modello e i suoi dati restano sotto il controllo legale e operativo di un'organizzazione. Le leve che permettono questo sono concrete: pesi aperti che potete ospitare voi stessi, e un hosting che mantiene i dati nell'UE o sulle vostre stesse macchine.

Due riserve oneste impediscono che la parola diventi marketing.

🔸 Un codice postale UE da solo non è sovranità.
Le leggi sull'accesso statale, anche in Francia e Germania, possono imporre l'accesso ai dati in modi contro cui una sede nell'UE non protegge del tutto. Dove si trovano i dati è necessario, non sufficiente.

🔸 La proprietà conta quanto l'origine.
Silo AI, il produttore finlandese dei modelli aperti Poro e Viking, è oggi una controllata di AMD, un'azienda statunitense, il che la sottopone al diritto USA. Un modello nato in Europa ma di proprietà straniera non è automaticamente un modello sovrano (North Atlantic).

La sovranità è quindi una questione di stack e di sua proprietà, non una bandiera sulla homepage.

Mistral, e il denaro che ha reso seria l'Europa

Mistral è il motivo per cui l'IA europea ha smesso di essere una nota a margine, e il modo in cui è arrivato il suo finanziamento è il segnale vero e proprio.

Nel suo round riportato a settembre 2025, Mistral ha raccolto circa 1,7 miliardi di euro con una valutazione di circa 11,7 miliardi di euro, e l'investitore principale è stato ASML, il costruttore olandese di macchinari per chip, con circa 1,3 miliardi di euro (CNBC). Il fatto che un'azienda che vende le macchine per produrre chip avanzati investa in un laboratorio di modelli è una mossa di sovranità, non solo finanziaria. Mistral ha abbinato a ciò l'infrastruttura, puntando a circa 200 megawatt di capacità di calcolo europea entro il 2027, di proprietà anziché noleggiata, in siti vicino a Parigi e in un grande nuovo impianto in Svezia (Data Center Dynamics). Anche la sua trazione enterprise è reale, con collaborazioni nominate al fianco di Airbus, BMW, Amazon e SAP.

La storia che Mistral racconta di sé è la parte utile: non cerca di vincere la pura corsa ai modelli contro i giganti statunitensi, cerca di possedere lo stack europeo che sta sotto i modelli. Per un acquirente a cui importa il controllo, questa collocazione conta più di una posizione in classifica.

E oltre: il resto della panchina europea

Mistral non è tutto il campo, e gli altri rivelano scommesse diverse su dove si trovi il valore europeo.

Aleph Alpha, l'azienda di Heidelberg che un tempo era considerata la speranza tedesca per un modello di punta, ha rinunciato alla corsa al vertice e si è ricostruita attorno a una piattaforma di sovranità e compliance, PhariaAI, orientata a un impiego on-premise e air-gapped in settori regolamentati (Analisi). Black Forest Labs, fondata a Friburgo da parte del team originale di Stable Diffusion, realizza la famiglia aperta di modelli immagine FLUX (Dakota). E Teuken-7B, proveniente dal consorzio OpenGPT-X guidato da Fraunhofer, è un modello scaricabile apertamente, addestrato su tutte le ventiquattro lingue ufficiali dell'UE, costruito per l'auto-hosting (Fraunhofer).

Lo schema notevole è che le mosse europee più forti riguardano sempre di più lo stack, l'apertura e il modello di impiego, invece di un singolo modello di punta. Ed è proprio lì che si trova il vantaggio per un acquirente delle PMI.

L'onesto divario di capacità

La sobrietà è più credibile dell'entusiasmo, quindi ecco il divario in chiaro. Sugli indici di capacità indipendenti, il modello di punta europeo si colloca piuttosto a metà del campo open-weight che al vertice (Artificial Analysis). Anche i finanziamenti sono sbilanciati: il finanziamento combinato dei modelli europei è piccolo accanto alla valutazione di un singolo laboratorio statunitense, più vicino a un errore di arrotondamento che a una rivalità (North Atlantic).

Il passo utile non è negare il divario, ma chiedersi se tocchi il vostro compito. Per bozze, estrazione, classificazione e retrieval sui vostri stessi documenti, un modello open di fascia media completamente sotto il vostro controllo supera per lo più la soglia, e il controllo vale più degli ultimi punti di benchmark. È lo stesso compromesso che abbiamo scelto quando un modello di punta è scomparso da un mercato in settantadue ore: il controllo operativo batte la capacità noleggiata, quando la capacità noleggiata può essere tolta (iiterate). Il vertice è dove i modelli europei restano davvero indietro. Ed è anche la parte del lavoro di cui molte imprese, in realtà, non hanno bisogno.

Che cosa significa per un acquirente delle PMI

La decisione non è patriottica, è architettonica. Tre percorsi pratici, secondo ciò di cui il carico di lavoro ha bisogno:

1. Serve capacità di punta, i dati non sono sensibili. Un modello di punta ospitato resta l'opzione più performante. Usatelo, e accettate consapevolmente la dipendenza.
2. Il controllo è il punto. Per dati regolamentati, protezione del mandante o tutto ciò che dovete poter verificare, ospitate voi stessi un modello europeo aperto o open-weight, oppure usate un'inferenza ospitata nell'UE, e scrivete residenza dei dati e proprietà nella specifica, non nel marketing.
3. Valutate la sovranità sullo stack, non sulla bandiera. Dove girano i pesi, dove si trovano i dati, chi può imporre l'accesso e se potete sostituire il modello. La stessa domanda sul controllo sta sotto il GDPR (iiterate).

La scena europea è finalmente reale abbastanza da essere una risposta seria per il secondo caso, ed è la maggior parte di ciò che ci viene chiesto di costruire. Il motivo per cui vale la pena interessarsene non è la bandiera. È che la capacità noleggiata è revocabile e il controllo è qualcosa che si costruisce. La domanda che vale la pena mantenere non è se l'Europa possa raggiungere il vertice quest'anno. È quali dei vostri carichi di lavoro abbiano davvero bisogno del vertice e quali richiedano solo un modello performante che voi controllate.