Sotto il cofano, una soluzione su misura ben progettata si riconduce quasi sempre a quattro mattoni: un'interfaccia snella, un motore — un modello di intelligenza artificiale eseguito localmente o richiamato via API a seconda della sensibilità dei dati —, un database semplice e, opzionalmente, un agente conversazionale che interroga il tutto in linguaggio naturale. FiscalDoc, l'applicazione che ho costruito per gestire la mia fiscalità personale, illustra questo schema nella sua forma più essenziale. Quanto segue generalizza questa architettura e spiega onestamente cosa la fa crescere.
Quali sono i quattro componenti che ricorrono quasi sempre?
Il primo mattone è l'interfaccia: la facciata attraverso cui un utente inserisce un'informazione o legge un risultato. In FiscalDoc si tratta di un semplice modulo web — carico un PDF o una foto e lo strumento fa il resto. A questa scala, nulla giustifica un framework front-end pesante né un'app mobile nativa: un modulo pulito, una tabella filtrabile, qualche pulsante bastano per quasi tutti gli usi interni di una PMI. La sofisticazione visiva diventa utile soprattutto quando persone esterne all'azienda usano lo strumento — il che cambia le cose, come vedremo più avanti.
Il secondo mattone, il motore, è la scelta che struttura tutto il resto. Un modello di intelligenza artificiale aperto, eseguito localmente, si impone quando nessun dato deve lasciare l'azienda — è la scelta che ho fatto per FiscalDoc, con un modello aperto in esecuzione sul mio Mac, senza alcuna chiamata di rete per il cuore dell'elaborazione. Una chiamata API verso un modello proprietario resta, al contrario, perfettamente difendibile quando i dati trattati sono poco sensibili e la rapidità di realizzazione è prioritaria. Tra i due, non esiste una risposta universale, solo un compromesso specifico per ogni caso d'uso, che approfondisco in Progetto IA ben costruito: i tre pattern che reggono — la chiamata diretta, il RAG e gli agenti vi sono presentati come i tre pattern che coprono la maggior parte dei progetti, indipendentemente dalla scelta tra locale e API.
Il terzo mattone, il database, sorprende spesso per la sua modestia. FiscalDoc indicizza diverse centinaia di documenti all'anno in un database SQLite locale — un file, non un server. Per un uso limitato a una manciata di utenti e qualche migliaio di record, un database semplice svolge il lavoro che si crede riservato a un'infrastruttura pesante. Il passaggio a un sistema più robusto — database ospitato, replica, backup automatizzati — diventa necessario solo quando più persone scrivono contemporaneamente, o quando il volume supera ciò che una singola macchina gestisce comodamente.
Il quarto mattone è opzionale, ed è importante dirlo chiaramente: un agente conversazionale che interroga il database e i documenti in linguaggio naturale. In FiscalDoc posso chiedere di ritrovare le fatture MCVA superiori a 2'000 CHF nell'ultimo trimestre e ottenere una risposta costruita al volo. Questo livello aggiunge un vero comfort, ma non è mai la prima cosa da costruire: una dashboard filtrabile copre già la maggior parte delle esigenze di ricerca, e l'agente conversazionale giustifica il suo costo di sviluppo solo se le domande poste sono davvero varie e imprevedibili.
Dove ospitare questi quattro mattoni?
La scelta dell'hosting segue direttamente quella del motore, non il contrario. Una macchina locale — una postazione di lavoro correttamente dimensionata in memoria — basta per un uso individuale o un piccolo team, con un modello aperto che non si connette mai a Internet per il cuore dell'elaborazione. Un'infrastruttura svizzera o europea diventa pertinente non appena più utenti devono accedere allo stesso strumento da postazioni diverse, senza per questo voler affidare i dati a un cloud fuori dalla propria giurisdizione. Un cloud di un editore con impegni contrattuali di non conservazione resta un'opzione ragionevole per i dati meno sensibili, quando la velocità di realizzazione conta più del controllo totale sul luogo di esecuzione. Ho definito questa griglia a tre livelli — impegni contrattuali, hosting svizzero o europeo, modello aperto su infrastruttura controllata — in l'articolo sull'architettura dei progetti IA, e la riprendo a ogni definizione di soluzione su misura.
Perché spesso bastano poche centinaia di righe?
FiscalDoc sta in una cartella di poche centinaia di righe di codice. Non è un'impresa: è la conseguenza diretta di un perimetro rimasto volutamente ristretto. Uno strumento che serve un utente o un piccolo team, per una funzione precisa e ben descritta, non ha bisogno né di gestire migliaia di connessioni simultanee, né di anticipare casi che non si presenteranno mai. La disciplina più redditizia, in questo tipo di progetto, consiste nel resistere alla tentazione di costruire per un uso ipotetico invece che per il bisogno reale individuato all'inizio.
Ciò che è cambiato anche, in diciotto mesi, è il costo stesso della produzione. Non ho scritto FiscalDoc riga per riga: l'ho costruito dialogando con un assistente di codice, sera dopo sera, fino a ottenere uno strumento che mi somiglia — ho descritto questo metodo in il mio resoconto sullo sviluppo assistito. Ciò che dimostro alla scala di uno studio individuale, la stessa logica lo permette, funzione per funzione, per esigenze di PMI più ampie. Il caso completo — costi, compromessi, limiti — è documentato in FiscalDoc: sostituire 1'400 CHF/anno di SaaS con un'IA locale.
Cosa fa crescere un progetto?
Ad oggi ho documentato pubblicamente solo un caso completo costruito secondo questo schema — FiscalDoc. Ma la sua architettura non ha nulla di casuale: corrisponde a ciò che resta una volta eliminato il superfluo, e cambia non appena una delle tre condizioni seguenti evolve.
- Le integrazioni. Collegare lo strumento a un sistema contabile esistente, a un ERP o a una casella di posta aziendale moltiplica i punti di rottura: ogni integrazione aggiunge il proprio contratto di interfaccia, la propria gestione degli errori, la propria manutenzione nel tempo.
- Il multiutenza. Non appena più persone devono accedere allo stesso strumento con diritti diversi, serve un'autenticazione reale, una gestione dei ruoli e spesso una tracciabilità di chi ha fatto cosa — un cantiere a sé stante, distinto dalla logica di business stessa.
- La conformità. Uno strumento che tratta dati di terzi — clienti, collaboratori — coinvolge la LPD (Legge sulla protezione dei dati) oltre alla semplice scelta dell'hosting: registro dei trattamenti, contratto di sub-fornitura se viene utilizzato un componente esterno, politica di conservazione. Questo aspetto merita di essere affrontato in fase di definizione, non scoperto strada facendo.
Nessuno di questi tre fattori scoraggia il su misura. Cambiano il suo budget e il suo rigore, non la sua pertinenza. Ciò che invalidano, invece, è l'idea che un progetto di questo tipo si risolva sempre in poche serate: superata questa soglia, la definizione del progetto merita lo stesso rigore di un progetto SaaS di perimetro equivalente — è esattamente ciò che stabilisco all'inizio di ogni soluzione su misura. Questa anatomia è solo uno dei cantieri possibili: la roadmap complessiva è definita in Cosa deve fare una PMI svizzera di fronte all'IA nel 2026?
Da ricordare
— Una soluzione su misura si riconduce quasi sempre a quattro mattoni: interfaccia snella, motore scelto in base alla sensibilità dei dati, database semplice, agente conversazionale opzionale. — L'hosting segue la scelta del motore: postazione locale, infrastruttura svizzera o europea, oppure cloud di un editore con impegni contrattuali. — Tre fattori fanno crescere un progetto: integrazioni, multiutenza, conformità — cambiano il budget, non la pertinenza del su misura.
FAQ
Bisogna sempre privilegiare un modello IA locale rispetto a un'API? No. Il locale si impone quando nessun dato può lasciare l'azienda; l'API resta spesso più rapida da implementare per dati poco sensibili. È un compromesso caso per caso, non un principio assoluto.
Una PMI senza competenze tecniche interne può considerare questo tipo di strumento? Sì, a condizione che una terza parte competente conduca il dialogo con l'assistente di codice e riveda ciò che viene prodotto. Il risultato — codice e dati — appartiene allora interamente all'azienda, il che resta l'interesse centrale dell'approccio.
Quanto tempo richiede un progetto di questo tipo? Dipende interamente dal perimetro: qualche serata per un bisogno circoscritto come FiscalDoc, diverse settimane non appena intervengono integrazioni o multiutenza. Nessuna cifra generale sarebbe onesta senza una definizione preliminare del progetto.
Un database semplice come un database SQLite locale è davvero affidabile per una PMI? Per un uso con uno o pochi utenti e volumi di qualche migliaio di record, sì, ampiamente. Raggiunge i suoi limiti non appena più persone scrivono simultaneamente o il volume supera ciò che una singola macchina gestisce comodamente — il segnale stesso che annuncia un cambiamento di scala.
E nella vostra azienda? La Diagnosi d'Uso dell'IA: sessanta minuti per definire i vostri flussi reali, identificare cosa merita una soluzione su misura, cosa resta in SaaS e cosa non ha affatto bisogno di IA. Prenotare una diagnosi
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 al fianco diretto delle PMI svizzere. Percorso.