L'architettura di un progetto di intelligenza artificiale: tre pattern e la disciplina che li rende duraturi

Nota rivista il 25 maggio 2026. Articolo inizialmente pubblicato nel marzo 2026 — riscrittura integrale.

L'architettura di un progetto di intelligenza artificiale designa l'insieme delle scelte tecniche strutturanti: quale modello è utilizzato, sotto quale modalità di accesso, come sono gestiti i dati, come sono orchestrati i componenti. Queste scelte condizionano durevolmente il costo, la performance e l'evolutività del risultato. Una cattiva partenza tecnica costa mesi di ritardo e decine di migliaia di franchi; una buona partenza non si vede, perché permette l'evoluzione serena del progetto su più anni.

Questa nota espone i tre pattern di architettura che strutturano la pratica nel 2026, qualifica i criteri che distinguono il loro uso appropriato, e identifica la disciplina che rende queste scelte duraturi oltre l'avvio iniziale.

Tre pattern di architettura che strutturano la pratica

La diversità apparente dei progetti di intelligenza artificiale si riconduce, in pratica, a tre pattern di architettura fondamentali. Comprendere ciò che distingue questi tre pattern, e sapere quale corrisponde a un caso d'uso dato, costituisce la decisione tecnica più strutturante di un progetto.

Il pattern API Wrapper: l'accesso diretto ai modelli via interfaccia programmatica

Il pattern più semplice consiste nel chiamare un modello di linguaggio attraverso la sua interfaccia programmatica, e nel costruire la logica di mestiere dell'applicazione intorno a questa chiamata. Nessuna infrastruttura dedicata da gestire, nessun materiale specializzato da approvvigionare. Il costo operativo è proporzionale all'uso effettivo.

Questo pattern conviene alla prototipazione rapida, ai volumi moderati, e ai casi d'uso che non richiedono una conoscenza fine di dati specifici all'impresa: riassunto di testi generici, classificazione semplice, generazione di contenuto standard. Una PMI può raggiungere un prototipo funzionale in qualche giorno con questo approccio.

Il suo limite principale risiede nella dipendenza da un fornitore unico. Il mercato dei modelli evolve rapidamente, e gli arbitraggi prezzo-performance si spostano regolarmente. Costruire fin dalla partenza uno strato di astrazione che isola la logica di mestiere dal fornitore di modello preserva la libertà di cambiare fornitore senza riscrivere l'applicazione. Questa disciplina — spesso designata con il termine Provider Pattern — non è un lusso; è un'assicurazione operativa il cui costo iniziale è marginale e il cui valore si rivela al primo cambio di fornitore.

Il pattern RAG: ancorare le risposte ai dati propri dell'impresa

Il pattern RAG — per Retrieval-Augmented Generation — è diventato lo standard per i progetti d'impresa che richiedono una conoscenza dei dati propri dell'organizzazione. Invece di iniettare tutto nel prompt inviato al modello, si combina un motore di ricerca semantica con un modello di linguaggio.

Il funzionamento si scompone in tre tappe. Anzitutto l'indicizzazione: i documenti dell'impresa — manuali, procedure interne, base di conoscenza, catalogo prodotto, corpus giuridico — sono suddivisi in segmenti e convertiti in rappresentazioni vettoriali che catturano il loro senso semantico. Poi la ricerca: quando un utente pone una domanda, il sistema identifica i segmenti più pertinenti per similarità vettoriale, piuttosto che per semplice corrispondenza di parole chiave. Infine la generazione: il modello riceve la domanda accompagnata dai segmenti pertinenti, e produce una risposta contestualizzata che può citare le proprie fonti.

Questo pattern risponde alla sfida centrale dei modelli di linguaggio utilizzati da soli: le allucinazioni. Ancorando ciascuna risposta a documenti verificati, il sistema resta fattuale. Quando la base di conoscenza non contiene la risposta a una domanda, il sistema può dirlo esplicitamente piuttosto che inventare.

La sua qualità dipende tuttavia direttamente dalla qualità dei dati indicizzati. Documenti obsoleti, mal strutturati, contraddittori o incompleti producono risposte mediocri, quale che sia il modello utilizzato. Il lavoro di preparazione dei dati — spesso trascurato nel discorso commerciale intorno agli strumenti — rappresenta, nella pratica osservata in studio sui progetti MCVA, una parte sostanziale dello sforzo totale — tipicamente tra la metà e i due terzi sui progetti seri. Questa osservazione merita di essere posta all'inquadramento, perché modifica sostanzialmente la stima dello sforzo.

Il pattern agenti: delegare l'esecuzione di compiti multi-tappa

Il pattern agenti rappresenta il livello di complessità successivo. Un agente è un sistema alimentato da modello capace di utilizzare strumenti — ricerca web, calcoli, chiamate di API, interrogazioni di basi di dati — e di pianificare una sequenza di azioni per compiere un compito complesso.

Questo pattern conviene ai compiti che necessitano di più tappe coordinate: ricerca di informazione, analisi intermedia, decisione sul seguito da dare, esecuzione di un'azione in un sistema di mestiere. L'automazione di workflow complessi — verifica di uno stato di ordine in un sistema di gestione esistente seguito da un aggiornamento in un altro, per esempio — costituisce il caso d'uso tipico.

Il vantaggio operativo è sostanziale quando il pattern è appropriato: automazione end-to-end di processi di mestiere che richiedevano classicamente più interventi umani. Il suo limite risiede nella complessità di messa in opera — il debug di un agente multi-tappa è esigente — e nel costo operativo elevato: un agente può effettuare diverse decine di chiamate al modello per trattare un singolo compito complesso. Questo pattern è da riservare ai casi d'uso a forte valore aggiunto in cui la complessità giustifica il costo di esercizio e di manutenzione.

La disciplina strutturante: la qualità dei dati prevale sulla scelta del modello

L'errore più frequente osservabile sui progetti di intelligenza artificiale consiste nel concentrare l'attenzione sulla scelta del modello, mentre la qualità dei dati determina in modo sproporzionato la qualità del risultato finale.

Tre osservazioni sostengono questa qualifica.

Anzitutto, sui progetti che si appoggiano su dati propri dell'impresa — la maggioranza dei progetti seri — la differenza di qualità tra i principali modelli disponibili è relativamente modesta paragonata alla differenza prodotta dalla qualità dei dati indicizzati. Un sistema RAG nutrito con documenti puliti e strutturati su un modello di capacità media produce regolarmente migliori risultati di un sistema RAG nutrito con documenti disorganizzati su un modello di punta.

Poi, l'investimento nella qualità dei dati presenta un carattere cumulativo e duraturo. I dati puliti e strutturati una volta servono a tutti gli usi successivi. La scelta di un modello, invece, deve essere riconsiderata regolarmente perché il mercato evolve. Investire lo sforzo nei dati piuttosto che nella selezione del modello produce dunque un valore più duraturo.

Infine, la pratica osservabile mostra che i progetti che falliscono condividono una caratteristica comune: hanno sottostimato lo sforzo di preparazione dei dati, e l'hanno scoperto troppo tardi. I progetti che riescono investono fin dall'inquadramento iniziale in questa preparazione, e accompagnano il dispiegamento di processi di manutenzione dei dati che preservano la qualità nel tempo.

Cinque errori ricorrenti che la pratica osserva

Oltre alla scelta del pattern e all'attenzione ai dati, cinque errori ricorrenti meritano di essere identificati perché producono costi di opportunità sostanziali.

Iniziare con l'addestramento complementare di un modello. L'addestramento complementare — spesso designato con il termine fine-tuning — è raramente necessario in prima intenzione. Nella grande maggioranza dei casi, un sistema RAG con prompt ben costruiti produce risultati equivalenti per una frazione del costo e dello sforzo. L'addestramento complementare è pertinente in situazioni specifiche in cui il modello deve adottare uno stile molto particolare o padroneggiare un vocabolario tecnico che il RAG non copre correttamente. Prima di investire in questa via, è generalmente produttivo spingere oltre l'ottimizzazione del RAG.

Ignorare la qualità dei dati. Il punto è stato sviluppato sopra, ma merita di essere ricordato perché costituisce probabilmente l'errore più strutturante.

Trascurare la valutazione sistematica. Senza metriche di qualità — pertinenza, fedeltà alle fonti, completezza — è impossibile misurare i progressi oggettivamente. Mettere in atto un quadro di valutazione fin dall'avvio del progetto, con un insieme di riferimento di qualche decina di domande-risposte validate umanamente, costituisce l'investimento operativo il cui rendimento è il più elevato.

Sottostimare i costi operativi in produzione. Un prototipo che consuma un budget moderato in fase esplorativa può raggiungere un budget sostanzialmente più importante una volta passato in produzione reale. Il calcolo previsionale basato sul numero di utenti attesi, la frequenza di utilizzo e la taglia media delle richieste merita di essere condotto all'inquadramento, piuttosto che scoperto in esercizio.

Costruire un sistema monolitico. Un sistema che mescola in un solo blocco indissociabile il motore di ricerca, il modello di linguaggio, la cache, l'interfaccia utente e lo strato di valutazione è difficile da far evolvere e da debuggare. Un'architettura modulare, in cui ciascun componente è indipendente, permette di sostituire un elemento senza toccare gli altri. Questa modularità non richiede uno sforzo sostanziale alla partenza, ma preserva l'evolutività del sistema nel tempo.

La strategia progressiva raccomandata per una PMI

Per una PMI svizzera che avvia un progetto di intelligenza artificiale, un approccio progressivo distingue i progetti che giungono in porto da quelli che si insabbiano.

La fase esplorativa anzitutto, condotta con un pattern API Wrapper su un caso d'uso preciso e misurabile. Questa fase, che si svolge tipicamente su poche settimane, valida che il concetto regga in piedi nel contesto specifico dell'impresa. La sua modestia è la sua forza: un investimento contenuto, un rischio limitato, apprendimenti immediati.

Il prototipo arricchito poi, generalmente con un pattern RAG sui dati propri dell'impresa, accompagnato da una valutazione sistematica della qualità e da primi test utente. Questa fase, che si svolge su qualche mese, aggiusta il sistema alle condizioni reali di uso e identifica gli aggiustamenti necessari prima della messa in produzione.

La messa in produzione con monitoring completa la sequenza. Questa fase dispiega il sistema nel suo contesto d'uso obiettivo, con i processi di feedback utente, di miglioramento continuo dei prompt e di manutenzione dei dati che preservano la qualità nel tempo.

La valutazione di un eventuale addestramento complementare di modello, o dell'aggiunta di agenti per automatizzare workflow complessi, interviene soltanto dopo questa messa in produzione, sulla base di osservazioni reali piuttosto che di ipotesi. Questa disciplina di attesa distingue i progetti che consolidano un valore operativo da quelli che impilano strati di complessità senza beneficio tangibile.

La sovranità dei dati trattati

Per i progetti che toccano dati soggetti alla Legge federale sulla protezione dei dati^[1] o a obblighi settoriali specifici, tre approcci strutturano la pratica, per ordine di vincolo crescente.

Gli impegni contrattuali di non-ritenzione anzitutto, negoziabili con i principali fornitori di modelli per le loro offerte enterprise. Questo approccio conviene alla maggioranza dei casi in cui i dati sono sensibili senza essere strategicamente critici.

L'hosting su infrastruttura europea o svizzera poi, che garantisce che i dati non lascino la giurisdizione interessata. Questo approccio conviene ai contesti in cui la localizzazione è un'esigenza esplicita, sia regolamentare sia contrattuale.

Il dispiegamento su infrastruttura controllata completa l'elenco, generalmente con modelli aperti. Questo approccio garantisce che i dati restino integralmente sull'infrastruttura dell'impresa, al prezzo di una competenza tecnica interna e di investimenti materiali che possono essere sostanziali.

Per le imprese soggette a regolamentazioni settoriali strette — settore finanziario, sanità, amministrazione pubblica — un'analisi di rischio formale condotta all'inquadramento iniziale del progetto evita arbitraggi costosi a metà percorso.

La disciplina che distingue la serietà

La scelta di un'architettura per un progetto di intelligenza artificiale non è una questione di competenza puntuale inaccessibile ai decisori non tecnici. È una questione di disciplina metodica: porre il pattern appropriato per il caso d'uso, investire nella qualità dei dati prima della scelta del modello, costruire fin dalla partenza le condizioni di evolutività del sistema, trattare esplicitamente la questione della sovranità piuttosto che eluderla.

Questa disciplina distingue, anche qui, i progetti che producono un valore duraturo da quelli che consumano budget senza trasformare effettivamente il funzionamento dell'organizzazione. Non richiede genio tecnico particolare. Richiede un'attenzione sostenuta al rigore professionale degli arbitraggi iniziali.

Sul pattern RAG in particolare, e sulle architetture conversazionali che se ne servono come pilastro, vedere anche la nota I chatbot alimentati da modelli generativi: dalle FAQ scriptate agli agenti che agiscono.

Sources

[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/it [↩]

Jérôme Deshaie è CEO di MCVA Consulting SA, studio svizzero di consulenza strategica in intelligenza artificiale, con sede in Vallese.