Progetto IA ben costruito: i tre pattern che reggono

Un progetto IA ben costruito si riconosce da tre scelte fatte prima della prima riga di codice: un pattern architetturale adatto al bisogno — chiamata diretta al modello, RAG o agenti —, un investimento nella qualità dei dati superiore a quello dedicato alla scelta del modello, e una progressione per tappe che convalida prima di industrializzare. Un cattivo avvio costa mesi di ritardo e decine di migliaia di franchi. Un buon avvio non si nota: il progetto evolve senza drammi per anni.

Tre pattern coprono la maggior parte dei progetti

La diversità apparente dei progetti IA si riduce, in pratica, a poche cose. Nel 2026, tre pattern architetturali coprono la maggior parte dei progetti IA aziendali: la chiamata diretta a un modello via API, il RAG che ancora le risposte ai documenti interni, e gli agenti che eseguono compiti multi-fase. Individuare quello adatto al proprio caso d'uso è la decisione tecnica più strutturante della fase di definizione.

La chiamata diretta via API è il pattern più semplice: il modello viene interrogato attraverso la sua interfaccia programmatica, e la logica di business si costruisce attorno. Nessuna infrastruttura dedicata, un costo proporzionale all'uso, un prototipo funzionante in pochi giorni. È adatto a volumi moderati e compiti generici — riassunto, classificazione, generazione di contenuti standard. Il suo punto debole: la dipendenza da un unico fornitore, in un mercato dove i rapporti prezzo-prestazioni si muovono continuamente. Il rimedio è noto e poco costoso — uno strato di astrazione che isola la logica di business dal fornitore, per poterne cambiare senza riscrivere l'applicazione. Questa precauzione sembra superflua il primo mese; vale oro al primo cambio di modello.

Il RAG — Retrieval-Augmented Generation — è diventato lo standard non appena il sistema deve conoscere i vostri dati. I documenti aziendali vengono indicizzati in forma vettoriale; a ogni domanda, i segmenti più pertinenti vengono recuperati e forniti al modello, che risponde basandosi su di essi, con fonti citabili a supporto. È la risposta strutturale alle allucinazioni: ancorato a documenti verificati, il sistema resta fattuale — e può ammettere di non sapere. Ne descrivo il funzionamento e gli usi conversazionali in un chatbot può davvero servire i vostri clienti?.

Gli agenti costituiscono il livello di complessità successivo: un sistema capace di usare strumenti — ricerca, calcoli, chiamate API, basi di dati — e di pianificare una sequenza di azioni. È il pattern dei flussi di lavoro multi-fase: verificare uno stato in un sistema, decidere, aggiornare un altro sistema. La sua potenza ha due contropartite: un debug impegnativo e un costo operativo elevato — decine di chiamate al modello per un solo compito. Lo riservo ai casi in cui il valore automatizzato giustifica chiaramente questo costo.

Perché i vostri dati contano più del modello

L'errore più diffuso consiste nel concentrare l'attenzione sulla scelta del modello — quale fornitore, quale versione, quale benchmark — mentre è la qualità dei dati a determinare in modo sproporzionato la qualità del risultato.

Tre ragionamenti sostengono questa gerarchia. Anzitutto, sui progetti ancorati a dati aziendali — la maggioranza dei progetti seri —, lo scarto tra i principali modelli sul mercato è modesto rispetto allo scarto prodotto dallo stato dei documenti indicizzati: una base pulita su un modello medio batte regolarmente una base disorganizzata su un modello di punta. Poi, l'investimento nei dati è cumulativo: documenti puliti e strutturati servono tutti gli usi successivi, mentre la scelta di un modello va riconsiderata a ogni evoluzione del mercato. Infine, i progetti che si arenano condividono quasi sempre lo stesso tratto — uno sforzo di preparazione dei dati sottostimato, scoperto troppo tardi.

FiscalDoc me lo ha ricordato su piccola scala. Il valore di questa applicazione locale non viene dal modello che gira sotto: viene dalla struttura — categorie fiscali svizzere definite correttamente, convenzione di denominazione rigorosa, base indicizzata per la ricerca. Il modello è intercambiabile. La struttura, invece, è l'asset.

I cinque errori che costano di più

Alcuni errori si ripetono con una regolarità che merita un elenco — eccolo, in ordine decrescente di danno:

1. Iniziare dal fine-tuning. L'addestramento supplementare di un modello è raramente necessario in prima battuta: un RAG ben costruito produce risultati equivalenti per una frazione del costo. Si giustifica solo per uno stile molto particolare o un vocabolario che il RAG non copre.
2. Trascurare i dati. Il punto precedente ne ha mostrato il meccanismo; è l'errore più strutturante.
3. Fare a meno di una valutazione sistematica. Senza un set di riferimento — qualche decina di domande-risposte validate da esseri umani — è impossibile misurare un progresso. È l'investimento con il miglior rendimento di tutto il progetto.
4. Sottostimare i costi di produzione. Un prototipo economico può diventare costoso una volta esposto a utenti reali; il calcolo previsionale — utenti, frequenza, dimensione delle richieste — va fatto in fase di definizione, non alla prima fattura.
5. Costruire un monolite. Ricerca, modello, cache, interfaccia e valutazione saldati in un unico blocco rendono rischiosa ogni evoluzione. Un'architettura modulare costa poco all'inizio e preserva la capacità di sostituire un componente senza toccare gli altri.

Da dove iniziare? La progressione che funziona

Per una PMI svizzera, la differenza tra i progetti che vanno a buon fine e quelli che si arenano dipende in gran parte dalla sequenza. Prima la fase esplorativa: una chiamata diretta al modello, un caso d'uso preciso e misurabile, qualche settimana. La sua modestia è la sua forza — investimento contenuto, apprendimenti immediati, un vero margine di errore. Poi il prototipo arricchito: un RAG sui vostri dati, una valutazione sistematica, i primi utenti interni, nell'arco di qualche mese. Infine la messa in produzione, con ciò che la rende duratura: feedback degli utenti organizzato, miglioramento continuo dei prompt, manutenzione della base documentale.

Gli agenti ed eventuale fine-tuning arrivano dopo la messa in produzione, sulla base di osservazioni reali — mai di ipotesi. Questa disciplina dell'attesa separa i progetti che consolidano valore da quelli che accumulano complessità. È la progressione che applico nelle mie soluzioni su misura, e vale indipendentemente dal fornitore: un progetto che pretende di saltare la fase esplorativa merita la vostra diffidenza.

Dove vanno i vostri dati? Tre livelli di sovranità

Non appena il progetto tocca dati coperti dalla LPD^[1] o da obblighi settoriali, la questione della localizzazione va affrontata in fase di definizione. Tre approcci strutturano la pratica, per vincolo crescente. Gli impegni contrattuali di non conservazione, negoziabili con i grandi fornitori per le loro offerte enterprise, coprono la maggioranza dei casi in cui i dati sono sensibili senza essere critici. L'hosting su infrastruttura svizzera o europea garantisce che i dati non escano dalla giurisdizione — la via delle esigenze normative o contrattuali esplicite. La distribuzione di modelli aperti su infrastruttura controllata, infine, mantiene tutto all'interno dell'azienda, al prezzo di una competenza tecnica e di un investimento hardware reali — FiscalDoc ne è la prova di esistenza su scala di una singola persona: un modello open source sul mio Mac, zero dati che escono.

Per i settori strettamente regolamentati — finanza, sanità, pubblica amministrazione —, un'analisi del rischio formale in fase di definizione evita costosi ripensamenti a metà percorso.

In fondo, un'architettura IA solida non è una competenza inaccessibile ai decisori non tecnici; è una disciplina: il pattern giusto per il bisogno giusto, i dati prima del modello, la modularità prima della velocità, la sovranità affrontata esplicitamente. Questa griglia si inserisce nell'approccio complessivo che descrivo in Cosa deve fare una PMI svizzera di fronte all'IA nel 2026? — e si verifica progetto dopo progetto nei miei accompagnamenti.

Da ricordare

— Tre pattern coprono la maggior parte dei progetti IA nel 2026: chiamata diretta via API, RAG ancorato ai vostri documenti, agenti multi-fase — la fase di definizione inizia da questa scelta. — La qualità dei dati pesa più della scelta del modello: una base pulita su un modello medio batte una base disorganizzata su un modello di punta. — Procedere per tappe — esplorazione, prototipo valutato, produzione monitorata — e riservare agenti e fine-tuning al periodo successivo alla produzione.

FAQ

Bisogna addestrare un modello sui dati della mia azienda? Raramente, e mai in prima battuta. Un RAG ben costruito — i vostri documenti indicizzati, recuperati e forniti al modello a ogni domanda — produce risultati equivalenti per una frazione del costo e dello sforzo. Il fine-tuning si giustifica solo per uno stile o un vocabolario molto specifici, dopo aver portato il RAG ai suoi limiti.

Quale modello scegliere per iniziare? Meno decisivo di quanto si pensi. Lo scarto tra i principali modelli sul mercato è modesto rispetto all'effetto della qualità dei vostri dati. La scelta ragionevole: un modello comune, dietro uno strato di astrazione che permette di cambiarlo senza riscrivere l'applicazione — il mercato si muove troppo in fretta per restare vincolati.

Quanto tempo prima di un primo risultato utile? Una fase esplorativa ben definita — un caso d'uso preciso, una chiamata diretta al modello — offre i suoi insegnamenti in poche settimane. Il prototipo ancorato ai vostri dati richiede poi qualche mese, valutazione inclusa. Diffidate tanto delle promesse di distribuzione completa in quindici giorni quanto dei progetti che pianificano diciotto mesi prima del primo test utente.

Come garantire che i miei dati restino in Svizzera? Esistono tre livelli, per vincolo crescente: impegni contrattuali di non conservazione con il fornitore del modello, hosting su infrastruttura svizzera o europea, oppure distribuzione di un modello aperto sulla propria infrastruttura. Il livello giusto dipende dalla reale sensibilità dei dati trattati — è una decisione di definizione, non un dettaglio tecnico.

Un progetto IA sta prendendo forma nella vostra azienda? La Diagnosi d'Uso IA: sessanta minuti per mappare i vostri flussi reali, identificare ciò che merita una soluzione su misura, ciò che resta in SaaS e ciò che non ha affatto bisogno di IA. Prenotare una diagnosi

Fonti

[1] Legge federale sulla protezione dei dati (LPD), revisione del 25 settembre 2020, entrata in vigore il 1° settembre 2023. www.fedlex.admin.ch/eli/cc/2022/491/fr [↩]

Jérôme Deshaie è CEO e fondatore di MCVA Consulting SA, agenzia aumentata con sede in Vallese. Quindici anni al servizio di grandi marchi internazionali, ora in diretta per le PMI svizzere. Percorso.