Tre proprietà distinte determinano chi possiede realmente uno strumento digitale: il codice che lo fa funzionare, i dati che contiene, e la configurazione o il modello che codificano le vostre regole di business. Un contratto che garantisce un repository di codice accessibile, un'esportazione disponibile in qualsiasi momento e il diritto di far evolvere lo strumento tramite terzi risponde a tutte e tre. La maggior parte dei contratti SaaS, e una parte dei contratti di sviluppo su misura mal redatti, non risponde a nessuna delle tre.
Tre proprietà, tre domande diverse
La prima proprietà è il codice. Esiste un repository — uno spazio dove il codice sorgente vive, versionato e datato — a cui avete un accesso reale, o solo la promessa che vi sarà consegnato se lo chiedete? La differenza tra i due emerge solo il giorno in cui il rapporto si tende.
La seconda sono i dati. Potete estrarli integralmente, in un formato utilizzabile, nel momento in cui lo decidete, oppure dovete aprire un ticket e attendere la buona volontà di un supporto? È la domanda che approfondisco in Come migrare i propri dati fuori da un SaaS senza rompere nulla.
La terza proprietà è la più spesso dimenticata: la configurazione, o il modello. I workflow pazientemente costruiti in uno strumento no-code, le regole di business configurate in un ERP, la messa a punto di un modello di IA sui vostri stessi dati — tutto questo lavoro ha un valore reale, ma vive spesso interamente all'interno di uno strumento che non possedete. Il giorno in cui ve ne andate, questa logica resta presso il fornitore, perché non è mai stata vostra, solo affittata insieme al resto.
Cosa significa «proprietario», concretamente, in un contratto?
La parola «proprietario» si insinua facilmente in una brochure commerciale e molto più difficilmente in una clausola contrattuale precisa. Tre elementi trasformano l'intenzione in una realtà verificabile.
Un repository di codice accessibile in continuo, e non solo consegnato una volta chiuso il progetto: dovete poterlo consultare in qualsiasi momento, non solo quando il fornitore decide di aprirvelo. Un'esportazione dei dati self-service, disponibile senza dipendere da un intervento del fornitore — la differenza tra un pulsante che azionate voi stessi e una richiesta che formulate sperando in una risposta. E il diritto, esplicito, di far evolvere lo strumento tramite terzi: senza clausola di esclusività che vi leghi al fornitore originale per qualsiasi modifica futura, e con una documentazione sufficiente perché un altro sviluppatore possa riprendere il lavoro senza dover indovinare.
Possedere uno strumento presuppone quindi queste tre proprietà distinte — il codice, i dati, la configurazione o il modello — ognuna rispondente alla stessa esigenza: un accesso reale, non una promessa.
Il su misura fatto bene consegna il codice di default
È un impegno che considero non negoziabile nel mio lavoro: quando costruisco uno strumento su misura, il repository di codice appartiene al cliente fin dal primo giorno, senza che debba chiederlo, e senza sovrapprezzo per accedervi. Il sito che state leggendo in questo momento, mcva.ch, è stato ricostruito esattamente secondo questo principio — codice accessibile, documentato, trasferibile se un giorno smetterò di essere l'unico a intervenirvi.
FiscalDoc, l'applicazione locale che ho costruito per la mia stessa fiscalità, porta lo stesso principio alle sue estreme conseguenze: possiedo lo strumento, possiedo il codice, possiedo i dati, possiedo persino il modello di IA che li analizza. Ho documentato questo caso in FiscalDoc: sostituire 1'400 CHF/anno di SaaS con un'IA locale. Non è una questione di fiducia verso il fornitore, è una questione contrattuale, e un progetto su misura ben inquadrato la regola fin dall'inizio, non a posteriori.
Le trappole dei CMS interni e delle configurazioni prigioniere
La trappola più ingannevole non è il SaaS classico, che si identifica abbastanza facilmente come affittato. È il CMS o lo strumento «fatto in casa», costruito da un'agenzia, presentato come un asset proprio dell'azienda, mentre il codice non è documentato da nessuna parte, nessun repository è accessibile al di fuori di quell'agenzia, e ogni minima evoluzione deve necessariamente passare da lei. La parola «su misura» ha servito da rivestimento a un blocco tanto rigido quanto un SaaS chiuso, a volte di più.
La configurazione prigioniera segue la stessa logica per un'altra via. Settimane passate a configurare automazioni in uno strumento no-code, a costruire scenari complessi in un CRM, ad affinare regole in un ERP: questo lavoro ha un valore reale, ma esiste solo all'interno della licenza che lo fa funzionare. Il giorno in cui volete andarvene, questa logica non si esporta, resta rinchiusa in un formato che solo il fornitore sa leggere.
Alcuni segnali tradiscono, in modo abbastanza affidabile, uno strumento che non vi appartiene realmente:
- nessun repository di codice accessibile, solo la parola del fornitore;
- l'esportazione richiede un ticket di supporto anziché un gesto self-service;
- nessuna documentazione tecnica permette a terzi di riprendere il lavoro;
- nessuno oltre al fornitore originale è mai realmente riuscito a intervenire;
- la vostra logica di business esiste solo in un formato proprietario, illeggibile altrove.
Come verificare cosa possedete, fin da oggi
L'esercizio non richiede una competenza giuridica avanzata per iniziare: ponete, a ogni fornitore del vostro stack software, le tre domande di fondo — dov'è il codice, come escono i dati, chi può far evolvere lo strumento domani. Le risposte, o la loro assenza, vi collocano immediatamente sulla scala della proprietà reale.
Questo inventario si ricollega a quello che raccomando in nLPD: dove dormono realmente i dati della vostra PMI?: sapere dove vivono i vostri dati è metà del lavoro, sapere chi ne detiene le chiavi è l'altra metà. Si ricollega anche alla questione dell'hosting — un hosting svizzero non dice nulla sulla proprietà del codice che vi gira sopra, come spiego in Ospitare in Svizzera: cosa cambia davvero — e a quella dell'uscita, il giorno in cui la proprietà si rivela insufficiente e bisogna migrare, trattata in Come migrare i propri dati fuori da un SaaS senza rompere nulla.
Il momento giusto per chiarire queste tre proprietà non è mai dopo una controversia. È prima di firmare, o in mancanza di ciò, al prossimo rinnovo — è uno dei punti che verifico sistematicamente nell'inquadramento di una soluzione su misura, e uno dei temi a cui torno in Cosa dovrebbe fare una PMI svizzera di fronte all'IA nel 2026?
Da ricordare
— Uno strumento digitale si possiede attraverso tre proprietà distinte: il codice, i dati, e la configurazione o il modello che codifica le vostre regole di business. — «Proprietario» non significa nulla senza un repository di codice accessibile, un'esportazione self-service e il diritto di far evolvere lo strumento tramite terzi. — Il su misura non protegge automaticamente dal blocco: un CMS interno mal documentato può rinchiudere quanto un SaaS chiuso.
FAQ
Se ho pagato per uno sviluppo su misura, il codice mi appartiene automaticamente? Non necessariamente. Tutto dipende dai termini del contratto: una cessione esplicita dei diritti non ha nulla a che vedere con una semplice licenza d'uso, anche quando la fattura è identica. Verificate, sia nei contratti già firmati sia in quelli futuri, la clausola sulla proprietà intellettuale invece di darla per scontata a vostro favore.
Un CMS «proprietario» costruito dalla mia agenzia è per forza un problema? Non per forza, ma merita una verifica. Un repository di codice accessibile e documentato, anche presso un unico fornitore, resta gestibile. Il vero problema emerge quando nulla è documentato e nessun altro potrebbe riprendere in mano lo strumento se il rapporto si interrompesse domani.
Scopro di non possedere nulla di ciò che credevo di possedere: cosa fare? Iniziate dall'inventario piuttosto che dal confronto: quali strumenti, quali dati, quale codice, presso chi. Portate poi la questione della proprietà al prossimo rinnovo contrattuale, il momento in cui il fornitore ha più da perdere rifiutando. Per gli strumenti veramente critici, una ricostruzione su misura diventa a volte la soluzione più sicura sul lungo periodo.
Un modello di IA che ho affinato presso un fornitore mi appartiene? In generale, no, di default: il modello di base resta proprietà del fornitore, e il vostro fine-tuning resta il più delle volte sotto licenza anziché essere trasferito. I termini variano molto da un fornitore all'altro — è una clausola da leggere prima di investire tempo nell'affinare un modello, non dopo.
Possedere il proprio codice costa per forza più che affittare un SaaS? Non sistematicamente, e il divario si è ridotto negli ultimi anni: lo sviluppo assistito dall'IA ha fatto scendere il costo di costruzione di uno strumento su misura, come ho documentato con FiscalDoc. La domanda merita di essere riposta da zero, funzione per funzione, piuttosto che risolta per abitudine.
Non sapreste dire, oggi, chi detiene realmente il codice dei vostri strumenti? La Diagnosi d'Uso dell'IA: sessanta minuti per esporre i vostri flussi reali, identificare cosa merita il su misura, cosa resta in SaaS, e cosa non ha bisogno di IA affatto. 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 direttamente al fianco delle PMI svizzere. Percorso.