Modelli e agenti AI 2026: chi usiamo per cosa.

C'è una domanda che riceviamo invariabilmente durante la prima call di audit: "Ma voi usate ChatGPT?". La risposta breve è: non è la domanda giusta. La risposta lunga è l'architettura tecnica con cui mandiamo in produzione sistemi autonomi in ventuno giorni. Vale la pena spiegarla per intero, perché è il punto in cui un fornitore di AI smette di essere intercambiabile.

La menzogna del "modello unico"

Il mercato generalista è ossessionato dal "modello migliore in assoluto". C'è una gara costante a stabilire se GPT-5.5 sia meglio di Claude Opus 4.7, se Gemini 3 sia più veloce in una specifica prova di laboratorio, se il prossimo modello di frontiera abbia finalmente cambiato la classifica. È una conversazione utile per la stampa tecnologica, ma completamente irrilevante per chi costruisce sistemi in produzione.

A Jigen non tifiamo per nessun fornitore. Li usiamo tutti. La nostra infrastruttura si basa su un principio ingegneristico rigido: routing dinamico basato sul compito. Non mandiamo una richiesta complessa di matematica allo stesso modello che usiamo per qualificare contatti commerciali o leggere fatture. Sarebbe come usare un bisturi per piantare un chiodo. Il fornitore che propone "facciamo tutto su un modello" sta confessando che non ha mai gestito un sistema in produzione con costi reali — perché chi li ha gestiti li conosce.

Come orchestra Jigen · la mappa 2026

Quando costruiamo un Agente Aurora o automatizziamo un flusso back-office, il cervello del sistema è un orchestratore che distribuisce i compiti a modelli e agenti specifici in tempo reale. La mappa che usiamo oggi:

1 · Lavoro complesso con strumenti, ricerca, documenti, codice. Per compiti lunghi che richiedono uso di strumenti, verifica dei risultati, passaggi su più file o più fonti, oggi mettiamo GPT-5.5 fra le opzioni principali. Non lo trattiamo come un sostituto automatico di GPT-5 o GPT-5.4: lo testiamo con istruzioni nuove, criteri di successo espliciti e log di costo per compito. Quando il lavoro richiede autonomia reale, la differenza non è solo "risponde meglio"; è che tiene il filo più a lungo e chiede meno micro-guida.

2 · Sviluppo software su basi codice reali. Quando il compito è "modifica questo progetto, esegui i test, prepara una patch", non scegliamo solo un modello: scegliamo un agente di sviluppo. Codex e Claude Code sono strumenti operativi, non chatbot. Leggono il codice, modificano file, lavorano su più passaggi e possono essere inseriti in flussi di revisione. Per migrazioni, rifattorizzazioni, test e correzioni su più file li valutiamo come livello a sé, sopra il modello sottostante.

3 · Ragionamento lungo, analisi complessa, decisioni ad alto rischio. Per la manipolazione di dati strutturati, l'orchestrazione di script e i compiti logico-matematici, Claude Opus 4.7 resta uno dei candidati più forti. La sua utilità emerge quando il compito non tollera regressioni e quando serve mantenere coerenza su molte istruzioni. Costa più dei modelli intermedi, quindi non va sprecato su classificazioni banali.

4 · Agenti su misura. Quando non basta usare Codex o Claude Code "come prodotto", costruiamo l'impalcatura operativa: sessione, permessi, memoria del lavoro, strumenti ammessi, ambiente isolato, log, percorso di riserva. Qui entrano Claude Agent SDK, Responses API, Model Context Protocol e adapter interni. È il livello che trasforma un modello bravo in un sistema governabile.

5 · Automazioni operative ad alto volume. Per i compiti in cui serve un ragionamento medio ma una latenza bassa e un volume alto — qualifica lead, classificazione email, estrazione strutturata da PDF — usiamo modelli intermedi come Claude Sonnet 4.6 o modelli GPT di fascia media. Costo intermedio, buona aderenza allo schema, qualità sufficiente per la maggior parte dei flussi operativi.

6 · Ricerca web, contesto fresco, richieste con riferimento temporale. Per i compiti in cui serve informazione aggiornata oltre il limite temporale del modello principale — analisi concorrenti, monitoraggio eventi, confronto prezzi — usiamo Gemini 3 o altri strumenti con accesso nativo al contesto recente. Il punto non è la qualità astratta del ragionamento: il punto è ottenere fonti aggiornate con meno passaggi.

7 · Classificazione massiva, decisioni binarie ad alto volume. Per i compiti in cui serve solo un output sì/no, una categoria su quattro, una soglia da applicare, usiamo i modelli piccoli — Claude Haiku 4.5, GPT-5 mini o equivalenti. Costo: una frazione dei modelli top. Latenza: molto più bassa. Si possono far girare migliaia di chiamate senza che il costo del compito superi il valore del compito.

La differenza 2026 · modello, agente, impalcatura

Nel 2024 la domanda era: "Quale modello risponde meglio?". Nel 2026 la domanda è: "Quale sistema porta a termine il lavoro con il minor numero di passaggi umani, il minor rischio e il costo più prevedibile?".

Un modello produce testo, codice, JSON, analisi. Un agente usa strumenti, legge file, modifica una base codice, consulta fonti, esegue test, controlla l'esito. L'impalcatura operativa decide cosa può fare l'agente, dove può scrivere, quali strumenti può chiamare, quando deve fermarsi, come si misura il successo e quale percorso di riserva usare se qualcosa degrada.

Questo è il motivo per cui Codex, Claude Code e Claude Agent SDK vanno discussi nello stesso articolo dei modelli. Non sono "accessori per sviluppatori". Sono la prova che il mercato si è spostato dal modello isolato al sistema operativo del lavoro AI.

Per Jigen la scelta funziona così:

• se il compito è una risposta singola, scegliamo il modello;
• se il compito è un cambiamento su un asset reale — codice, documento, tabella, CRM, sito — scegliamo un agente;
• se il compito deve girare ogni giorno senza supervisione, costruiamo o adattiamo l'impalcatura operativa.

Matrice di scelta · quale modello, perché

Per chi vuole una griglia rapida, ecco come pensiamo ai compromessi. Non è una verità universale — è lo schema che funziona per i compiti tipici di un sistema in produzione 2026:

La matrice non è statica. La riguardiamo trimestralmente — Q1, Q2, Q3, Q4 di ogni anno — e quando un fornitore rilascia una versione che cambia il rapporto qualità/costo su un compito, aggiorniamo la mappa. È una pratica che richiede disciplina: senza revisioni programmate, il routing si fossilizza su scelte fatte sei mesi fa per ragioni che nessuno ricorda più.

Il vantaggio competitivo dell'orchestrazione

Sviluppare con questo paradigma offre tre vantaggi asimmetrici.

Isolamento dalle guerre dei modelli. Se domani mattina un fornitore alza i prezzi del cinquanta per cento, o subisce quarantotto ore di disservizio, i nostri clienti non si fermano. L'orchestratore effettua uno spostamento automatico sul secondo miglior modello disponibile per quel compito specifico. Le istruzioni sono scritte in modo indipendente dal fornitore, con piccoli adapter per le diverse sintassi di chiamata agli strumenti. Il test è ripetibile su due fornitori, lo spostamento è una decisione di un secondo, non un progetto di tre mesi.

Abbattimento dei costi di inferenza. Invece di pagare il costo premium per un modello top solo per fargli estrarre tre entità da un'email in ingresso — un compito che un modello piccolo risolve in millisecondi a costo quasi zero — riserviamo l'artiglieria pesante solo per le decisioni di alto livello. La differenza, su volumi reali, è enorme: un sistema mal orchestrato che usa Opus per tutto può costare quaranta volte un sistema ben orchestrato sullo stesso volume.

Velocità di adozione delle novità. Quando esce un nuovo modello o un nuovo agente — GPT-5.5, una nuova versione di Codex, un aggiornamento di Claude Code, Gemini 4 — non dobbiamo riscrivere il sistema. Aggiungiamo la nuova opzione, la testiamo su un sottoinsieme di compiti, la includiamo nel routing se passa i criteri di qualità/costo. Tempo medio per ingaggiare una nuova opzione in produzione: due-tre giorni. Le agenzie che hanno legato la propria architettura a un singolo fornitore impiegano mesi per migrare quando il fornitore cambia condizioni — e nel frattempo pagano la differenza.

Costi reali · numeri di esempio

Un esempio anonimizzato di un sistema che gira oggi in produzione per uno dei nostri clienti. Un agente di qualifica lead inbound: riceve un'email, decide se è target, estrae dati strutturati, scrive la prima risposta automatica.

Architettura mal orchestrata (un solo modello top per tutto):

• Classificazione iniziale "è un lead vero?" su Opus 4.7 → ~9 centesimi a chiamata
• Estrazione dati su Opus 4.7 → ~12 centesimi a chiamata
• Scrittura risposta su Opus 4.7 → ~14 centesimi a chiamata
• Totale per lead: ~35 centesimi. Su mille lead al mese: ~350 euro/mese di sola inferenza.

Architettura ben orchestrata (stesso outcome funzionale):

• Classificazione iniziale su Haiku 4.5 → ~0,3 centesimi a chiamata
• Estrazione dati su Sonnet 4.6 → ~3 centesimi a chiamata
• Scrittura risposta su Opus 4.7 (è il compito dove serve qualità) → ~14 centesimi a chiamata
• Totale per lead: ~17,3 centesimi. Su mille lead al mese: ~173 euro/mese.

Risparmio del cinquanta per cento sulla stessa funzionalità, senza degrado misurabile della qualità d'output. Numeri reali, non illustrativi. Su volumi di decine di migliaia di chiamate al mese — il caso tipico di un cliente medio — il delta diventa la differenza fra un sistema sostenibile e un sistema che il cliente smette di usare appena vede la prima bolletta API.

Il mito dei dati proprietari

Un'altra parola vuota che le agenzie amano vendere è l'illusione di "creare l'AI della tua azienda addestrando un modello da zero". È un investimento ingiustificato venduto a peso d'oro. Nel novantanove per cento dei casi aziendali, il fine-tuning da zero produce un modello inferiore a quello che potresti usare tramite API, costa dieci volte di più, e diventa obsoleto al primo aggiornamento del modello di frontiera, che esce tipicamente ogni tre-sei mesi.

Noi lavoriamo con architetture retrieval-augmented generation iper-ottimizzate. Preleviamo la conoscenza aziendale del cliente, la indicizziamo in un database vettoriale, e la diamo in pasto al modello migliore in quel preciso momento, fornendogli solo il contesto necessario per agire. I dati restano del cliente, il sistema è aggiornabile in tempo reale (senza dover riaddestrare nulla), il risultato entra in produzione in tre settimane invece che in sei mesi, e — punto chiave — quando esce il modello successivo si sostituisce il fornitore in trenta minuti, non in tre mesi.

Eccezioni reali allo schema, dove il fine-tuning ha senso: domini con vocabolario tecnico molto stretto, dove anche i modelli di frontiera mostrano un gap misurabile e ripetuto. Legale verticale, farmaceutico clinico, codice proprietario complesso. In quei casi il fine-tuning è una decisione presa dopo aver dimostrato che il retrieval non basta, mai prima.

Sicurezza dati · dove vivono in pratica

Un punto che molti clienti chiedono e poche agenzie spiegano onestamente. I dati che passano attraverso un sistema AI orchestrato vivono in tre punti, ognuno con regole diverse:

Dati al cliente · sempre. Il database con la conoscenza aziendale (documenti, contratti, knowledge base) resta dentro l'infrastruttura del cliente, su un cloud sotto suo controllo. Nessun documento "viaggia" verso i fornitori AI in modo permanente.

Dati in transito · effimeri. Quando un agente fa una richiesta, i fornitori AI ricevono le istruzioni — che includono il contesto recuperato dal RAG — e producono una risposta. Per impostazione standard, le condizioni enterprise di Claude, GPT e Gemini non addestrano i loro modelli sui dati API. Si possono firmare DPA aggiuntivi che bloccano qualunque conservazione dei prompt. Il cliente sa esattamente quali dati passano, perché ogni chiamata è loggata.

Dati on-premise · solo quando obbligatorio. Per settori regolati — banche, sanità con dati clinici protetti, difesa — esistono opzioni di deployment self-hosted dei fornitori, oppure modelli open-source di frontiera fatti girare on-premise. Costa di più, richiede operatività più sofisticata, ma in quei casi è non negoziabile. Il fornitore che propone "tutto cloud, fidatevi" senza affrontare il tema dati on-premise non sa cosa sta vendendo.

Quando NON cambiare modello o agente

La tentazione opposta alla monocultura è il cambio perpetuo: ogni nuovo modello che esce, riscriviamo l'architettura. Anche questo è un errore. Cambiare un modello o un agente in produzione ha un costo nascosto — test di regressione dei prompt, verifica del costo reale sui volumi del cliente, validazione dell'output su casi limite, revisione dei permessi e dei log — che spesso supera il beneficio incrementale.

La regola operativa che usiamo: si cambia modello o agente in produzione solo se il nuovo offre almeno il quindici per cento di miglioramento misurabile sul singolo compito per cui lo si valuta — qualità, latenza, costo, autonomia o riduzione degli interventi umani, non un mix vago — e se il costo del cambio è coperto in meno di trenta giorni di esecuzione. Sotto questa soglia, il sistema attuale resta. Cambiare senza criteri costa più dei modelli obsoleti.

Test rapido · il tuo fornitore è davvero multi-modello?

Una griglia diagnostica per il vertice di un'azienda che sta valutando un fornitore AI. Cinque domande:

1. Quanti fornitori diversi tocca il tuo sistema in un giorno tipico? Risposta sana: almeno due (più realistico: tre o quattro). Risposta sospetta: uno solo.
2. Se il fornitore primario va offline per ventiquattro ore, cosa succede al mio sistema? Risposta sana: spostamento automatico al secondo fornitore entro pochi minuti, eventualmente con degrado parziale documentato. Risposta sospetta: "non è mai successo".
3. Quale è il costo per chiamata, oggi, su ciascun tipo di compito del mio sistema? Risposta sana: una tabella con i numeri reali. Risposta sospetta: "dipende dal volume" senza cifra.
4. Come si gestisce l'arrivo di un modello o agente nuovo? Quanto ci vuole per integrarlo? Risposta sana: pipeline esistente di validazione, ingaggio in due-tre giorni. Risposta sospetta: "valutiamo caso per caso" senza tempi.
5. Posso vedere il log strutturato di una chiamata? Quale modello o agente l'ha gestita? Risposta sana: sì, in dashboard, con istruzioni, versione, strumenti usati, costo ed esito. Risposta sospetta: "i log sono interni".

Tre risposte sane su cinque significano un fornitore competente. Due o meno significano che il fornitore sta improvvisando — e quando il prezzo del modello che usa sale, lo sapranno solo a bolletta arrivata.

Non comprate "l'Intelligenza Artificiale". Comprate un'infrastruttura ingegneristica costruita per reggere volumi crescenti, difendervi dai disservizi dei fornitori, abbattere il costo per inferenza, integrare nuovi modelli e nuovi agenti senza riscrivere il sistema. È l'unica cosa che conta per il vostro margine netto — il resto è gergo da pitch.

Lettura Jigen: la mappa sopra è la nostra al 2026-Q2. È destinata a cambiare — ogni trimestre rivediamo qualità, costo, latenza, autonomia, log e sicurezza operativa. Il fornitore che si lega a un singolo provider o non aggiorna mai la propria architettura sta facendo una scommessa che fra sei mesi gli costerà cara. Architettura multi-fornitore e multi-agente non sono opzioni di lusso — sono la base minima per un sistema in produzione 2026.