Contratto di Sviluppo Software su Misura

Il Contratto di Sviluppo Software su Misura in Italia è il contratto con cui un fornitore si obbliga a realizzare per il committente un sistema informatico progettato specificamente per le sue esigenze, non reperibile come prodotto standard. Lo strumento si fonda sulla Legge sul Diritto d'Autore (L. 633/1941), in particolare sugli artt. 64-bis-64-quater sui programmi per elaboratore, e sulla disciplina dell'appalto di cui agli artt. 1655-1677 del Codice Civile.

Lo sviluppo su misura si caratterizza per la realizzazione di un software personalizzato, con specifiche concordate tra le parti e una struttura di progetto articolata in fasi. Gli artt. 64-bis ss. L. 633/1941 attribuiscono all'autore i diritti esclusivi sul programma; il contratto deve quindi disciplinare espressamente la titolarità del software, distinguendo le ipotesi di cessione dei diritti al committente da quelle di concessione in licenza, e regolando la sorte del codice sorgente. La struttura di appalto (art. 1655 c.c.) comporta l'obbligo di eseguire l'opera a regola d'arte, con collaudo e garanzia per i vizi.

Lo strumento è impiegato per la realizzazione di gestionali aziendali personalizzati, piattaforme web e applicazioni mobili, sistemi integrati di fatturazione elettronica e soluzioni verticali su misura. Il progetto è di norma scandito da stati di avanzamento e collaudi intermedi.

Il contratto deve identificare le parti, descrivere le specifiche funzionali e tecniche, disciplinare i SAL, il collaudo, la garanzia sui vizi, la titolarità del codice e dei diritti, la manutenzione e gli aspetti di protezione dei dati (GDPR). Sul portale forms-legal.com sono disponibili i modelli collegati di servizi informatici IT, servizi di marketing digitale, servizi di traduzione e servizi fotografici e video.

Il Contratto di Sviluppo Software su Misura in Italia è necessario ogni volta che un committente commissiona a un fornitore esterno la realizzazione di un sistema informatico progettato specificamente per le proprie esigenze, e non reperibile come prodotto commerciale standard. Il primo e più comune scenario è lo sviluppo di gestionali aziendali personalizzati: sistemi ERP su misura, CRM aziendali, software di contabilità e fatturazione elettronica integrata (nel rispetto del D.Lgs. 127/2015 e delle specifiche tecniche SDI dell'Agenzia delle Entrate), sistemi di gestione del magazzino, piattaforme di project management. Il secondo scenario è lo sviluppo di piattaforme web e applicazioni mobile: e-commerce con logiche di business specifiche, marketplace B2B o B2C, portali di prenotazione, applicazioni su iOS e Android per clienti finali, sistemi di accesso clienti (customer portal). Il terzo scenario è lo sviluppo di software industriale e di controllo: sistemi SCADA per il monitoraggio di impianti industriali, software per macchinari CNC con protocolli proprietari, sistemi embedded, firmware per dispositivi IoT. Il quarto scenario è lo sviluppo di sistemi informativi sanitari: cartelle cliniche elettroniche, sistemi di telemedicina, software per la gestione di studi medici — settore soggetto anche alla normativa MDR (Reg. UE 2017/745) se il software ha funzione diagnostica o terapeutica qualificandosi come dispositivo medico, nonché alle Linee Guida AGENAS e al Fascicolo Sanitario Elettronico (FSE 2.0). Il quinto scenario è lo sviluppo di piattaforme SaaS da commercializzare verso terzi: in questo caso la titolarità del codice rimane di norma in capo al fornitore, che concede una licenza d'uso al committente; il contratto deve regolare il regime della proprietà intellettuale diversamente rispetto a uno sviluppo classico. Il sesto scenario è l'integrazione e il middleware tra sistemi legacy: connettori tra sistemi ERP e piattaforme e-commerce, ETL per la migrazione di dati tra database eterogenei, API Gateway per l'esposizione di servizi legacy verso applicazioni moderne. Il settimo scenario è lo sviluppo di soluzioni di intelligenza artificiale e machine learning personalizzati: in questo caso il contratto deve affrontare le questioni aperte sulla titolarità dei modelli addestrati, delle output generate dall'AI e del dataset di training — temi che il Regolamento UE sull'AI (AI Act, Reg. UE 2024/1689) inizierà a disciplinare in modo organico. In tutti questi contesti, la mancanza di un contratto scritto con specifiche funzionali allegate espone il committente al rischio di controversie sul perimetro del lavoro, di dispute sulla titolarità del codice e di perdita dell'investimento in caso di insolvenza del fornitore.

Il Contratto di Sviluppo Software su Misura in Italia deve contenere una serie di elementi essenziali per essere giuridicamente completo, tecnicamente preciso e resistente a eventuali controversie in fase di esecuzione o post-consegna. Il primo elemento è l'identificazione completa delle parti: per il committente, ragione sociale o denominazione, codice fiscale e partita IVA, sede legale, PEC istituzionale, numero REA della Camera di Commercio competente, nome e qualifica del referente di progetto; per il fornitore, ragione sociale, partita IVA, numero REA, PEC, eventuali certificazioni tecnologiche (ISO 9001, ISO/IEC 27001 per la sicurezza informatica), nome del project manager designato per il progetto. Il secondo elemento è la specifica funzionale e tecnica (SRS — Software Requirements Specification): documento allegato come Allegato A al contratto, firmato da entrambe le parti, che definisce in dettaglio tutte le funzionalità del software da sviluppare (user story, casi d'uso, wireframe), i requisiti di integrazione con sistemi terzi (API, database, ERP, sistemi di pagamento), i requisiti non funzionali (performance — es. tempi di risposta massimi — disponibilità, scalabilità, sicurezza, accessibilità WCAG 2.1 se richiesta). L'SRS è il documento di riferimento per il collaudo: senza di esso, non esistono parametri oggettivi per verificare se il software consegnato rispetti i requisiti concordati. Il terzo elemento è il piano SAL con timeline e deliverable: suddivisione del progetto in fasi (analisi, design, sviluppo, testing, deployment) con le date previste di ogni milestone, i deliverable attesi per ogni SAL (mockup, prototipo navigabile, versione beta, versione definitiva) e le quote di corrispettivo sbloccabili a ogni milestone. Il quarto elemento essenziale è la clausola sulla titolarità del software: cessione scritta dei diritti patrimoniali di utilizzazione al committente ex artt. 107–110 LDA al saldo del corrispettivo, con specifica indicazione dei diritti ceduti (riproduzione, distribuzione, modifica, creazione di opere derivate); regime delle librerie e dei framework di terze parti inclusi nel software (elenco allegato delle licenze open source — MIT, Apache 2.0, GPL, LGPL — con le relative restrizioni d'uso); obblighi del fornitore di consegnare il codice sorgente completo con documentazione tecnica (architettura del sistema, documentazione API, manuale utente) alla consegna finale. Il quinto elemento è la procedura di collaudo: durata del periodo di testing (es. 30 giorni lavorativi dalla consegna), utilizzo di un bug tracker condiviso, classificazione dei bug per gravità (blocker, critical, major, minor) con i relativi SLA di risoluzione, procedura di accettazione formale (firma del verbale di collaudo positivo). Il sesto elemento è la garanzia post-rilascio (6-12 mesi dalla messa in produzione) per la correzione gratuita dei bug, con SLA garantiti, e le condizioni della manutenzione evolutiva successiva (a corpo o a tempo). Il settimo elemento è la clausola GDPR: nomina del fornitore come Responsabile del Trattamento ex art. 28 GDPR se accede a dati personali durante lo sviluppo o il testing, e attestazione dell'impegno del fornitore a rispettare il principio di privacy by design ex art. 25 GDPR nell'architettura del sistema. L'ottavo elemento sono le penali per ritardo nella consegna dei SAL ex art. 1382 c.c. (quantificate in percentuale del corrispettivo per ogni settimana di ritardo) e la clausola risolutiva espressa ex art. 1456 c.c. per inadempimenti gravi (es. abbandono del progetto, consegna di software gravemente difforme dalle specifiche). Su forms-legal.com il modello professionale integra tutti questi elementi, con campi guidati per la compilazione di ogni sezione critica — dalla specifica funzionale alle penali, dalla titolarità del codice alla nomina GDPR — permettendo a committente e fornitore di strutturare un contratto completo senza omissioni rischiose.

La compilazione del Contratto di Sviluppo Software su Misura in Italia richiede una fase preparatoria strutturata, in cui committente e fornitore definiscono e documentano tutti gli elementi tecnici e legali del progetto prima di procedere alla firma. Prima della compilazione del contratto, il committente deve: redigere o commissionare la specifica funzionale (SRS) del software, che descriva in dettaglio tutte le funzionalità richieste, le integrazioni con sistemi terzi e i requisiti non funzionali di performance e sicurezza; definire il budget complessivo del progetto e la ripartizione in SAL; verificare se il software tratterà dati personali degli utenti e, in caso affermativo, predisporre la nomina ex art. 28 GDPR per il fornitore e valutare se è necessaria una DPIA ex art. 35 GDPR. Nella sezione dati del committente, inserire: ragione sociale o denominazione completa, codice fiscale, partita IVA, sede legale con indirizzo completo, PEC istituzionale, nome e qualifica del referente tecnico di progetto (CTO, responsabile IT, project manager interno). Nella sezione dati del fornitore, inserire: ragione sociale completa, partita IVA, numero REA della Camera di Commercio, sede legale, PEC, eventuali certificazioni tecnologiche possedute, nome e qualifica del project manager designato per questo specifico progetto. Nella sezione oggetto del contratto, descrivere sinteticamente il software da sviluppare e rinviare all'Allegato A (SRS) per la descrizione funzionale completa: è fondamentale che l'SRS sia allegato al contratto come parte integrante e sia firmato da entrambe le parti. Nella sezione piano SAL, inserire per ogni milestone: denominazione del SAL (es. SAL 1 — Analisi e Design), data prevista di completamento, deliverable attesi (es. documento di analisi funzionale, mockup di interfaccia, prototipo navigabile, versione beta, versione finale), quota di corrispettivo da sbloccate al completamento del SAL (es. 30% alla firma, 20% al SAL 1, 30% al SAL 2, 20% al collaudo). Nella sezione corrispettivo, indicare l'importo totale del contratto (IVA esclusa), il piano di fatturazione collegato ai SAL, le modalità di pagamento (bonifico bancario entro 30 o 60 giorni dalla fattura) e gli interessi moratori automatici ex D.Lgs. 231/2002 in caso di ritardo. Nella sezione titolarità del software, specificare se i diritti patrimoniali sul software sviluppato sono ceduti al committente (opzione standard — specifica che la cessione avviene ex artt. 107–110 LDA al saldo del corrispettivo totale) o se il fornitore mantiene la titolarità concedendo una licenza d'uso esclusiva; allegare l'elenco delle librerie open source incluse nel software con le rispettive licenze. Nella sezione collaudo, indicare la durata del periodo di testing (es. 30 giorni lavorativi), i criteri di classificazione dei bug per gravità, i tempi di risoluzione garantiti per ogni categoria e la procedura di accettazione formale. Le clausole limitative della responsabilità del fornitore e le penali devono essere espressamente approvate con doppia firma ex art. 1341, comma 2, c.c. Il contratto deve essere firmato in duplice originale; per la firma digitale qualificata è sufficiente un originale elettronico per parte.

Il Contratto di Sviluppo Software su Misura in Italia è soggetto a un quadro normativo composito che coinvolge il diritto d'autore, il diritto civile dei contratti, la normativa sulla protezione dei dati personali e la disciplina dei pagamenti commerciali. La Legge sul Diritto d'Autore (L. 22 aprile 1941, n. 633, artt. 64-bis–64-quater) protegge il software come opera dell'ingegno fin dalla sua creazione, senza necessità di registrazione. I diritti patrimoniali di utilizzazione — riproduzione, traduzione, adattamento, distribuzione, comunicazione al pubblico — sono trasferibili solo con atto scritto che ne specifichi l'oggetto e l'estensione (art. 110 LDA): un contratto privo di clausola scritta di cessione non trasferisce i diritti patrimoniali al committente. I diritti morali dell'autore (art. 22 LDA) sono inalienabili. Il Codice Civile disciplina l'appalto (artt. 1655–1677 c.c.): l'oggetto del contratto deve essere sufficientemente determinato (art. 1346 c.c.) — le specifiche funzionali allegate assolvono a questa funzione; i vizi dell'opera devono essere denunciati entro sessanta giorni dalla scoperta, a pena di decadenza dall'azione di garanzia (art. 1667, comma 2, c.c.); l'azione per i vizi si prescrive in due anni dalla consegna (art. 1667, comma 3, c.c.). Le clausole che limitano la responsabilità del fornitore o impongono decadenze al committente devono essere specificamente approvate per iscritto dal committente (art. 1341, comma 2, c.c.) — la doppia firma è obbligatoria per l'efficacia di tali clausole. Il Regolamento UE 2016/679 (GDPR) impone il principio di privacy by design (art. 25) per i software che trattano dati personali: l'architettura tecnica deve incorporare fin dalla progettazione le misure di protezione dei dati. Quando il fornitore accede ai dati personali del committente durante lo sviluppo o il testing, deve essere nominato Responsabile del Trattamento ex art. 28 GDPR con nomina scritta. La Valutazione d'Impatto (DPIA, art. 35 GDPR) è obbligatoria per software che trattano dati su larga scala, dati particolari ex art. 9 GDPR o effettuano profilazione sistematica. Il D.Lgs. 9 ottobre 2002, n. 231 disciplina i pagamenti commerciali: termine massimo 30 giorni, elevabile a 60 per accordo scritto tra imprese; in caso di ritardo, decorrono automaticamente interessi al tasso BCE + 8 punti percentuali e un'indennità forfettaria di € 40. Il D.Lgs. 7 marzo 2005, n. 82 (CAD) conferisce alla firma digitale qualificata la stessa efficacia giuridica della firma autografa (art. 21, comma 2, CAD). I contratti con soggetti pubblici sono soggetti alle regole del Codice dei Contratti Pubblici (D.Lgs. 31 marzo 2023, n. 36) per gli appalti sopra soglia.

Gli errori più frequenti nella redazione del Contratto di Sviluppo Software su Misura in Italia sono responsabili della maggior parte delle controversie tra committenti e fornitori nel settore ICT. Il primo errore è non allegare le specifiche funzionali firmate: senza un documento SRS allegato e controfirmato da entrambe le parti, non esiste un parametro oggettivo per valutare se il software consegnato rispetti i requisiti concordati, generando dispute infinite su cosa fosse incluso nel prezzo e cosa sia una «change request» aggiuntiva. Il secondo errore è non regolare la titolarità del codice sorgente con clausola scritta ex art. 110 LDA: il committente che ha pagato lo sviluppo ma non ha acquisito per iscritto i diritti patrimoniali non è il proprietario del software e potrebbe non poterlo modificare, aggiornare o affidare la manutenzione a un fornitore diverso senza il consenso dello sviluppatore originale. Il terzo errore è non prevedere l'escrow o la consegna progressiva del codice sorgente a ogni SAL: se il fornitore diventa insolvente a metà progetto, il committente perde l'investimento e non ha accesso al codice sviluppato fino a quel momento, salvo intervento del curatore fallimentare ex D.Lgs. 14/2019. Il quarto errore è definire SAL senza criteri di accettazione (acceptance criteria): un SAL approvato senza criteri oggettivi non garantisce la qualità del software consegnato e rende impossibile al committente rifiutare milestone difettosi senza essere accusato di inadempimento. Il quinto errore è omettere la clausola di privacy by design e la nomina del Responsabile del Trattamento ex art. 28 GDPR per i software che trattano dati personali: il committente-titolare del trattamento risponde delle violazioni GDPR del software acquisito, con sanzioni fino a € 20 milioni o 4% del fatturato mondiale. Il sesto errore è non disciplinare il regime delle librerie open source incluse nel software: le librerie con licenza GNU GPL impongono la pubblicazione del codice sorgente delle applicazioni derivate — un obbligo che il committente potrebbe scoprire solo dopo la consegna, quando il software è già in produzione. Il settimo errore è non includere penali per ritardo nella consegna dei SAL: senza penali (art. 1382 c.c.), il committente può far valere solo il risarcimento del danno ex art. 1218 c.c., che deve provare in giudizio con oneri processuali significativi. L'ottavo errore è non prevedere la procedura di accettazione formale del collaudo: senza un verbale firmato di accettazione del software, il committente che utilizza il software potrebbe essere ritenuto tacitamente accettante dell'opera, perdendo i diritti di garanzia per i vizi non ancora manifestati (art. 1667, comma 2, c.c.).