Software e IA come prodotto difettoso: profili di responsabilità e risarcimento del danno

Software e IA come prodotto difettoso: profili di responsabilità e risarcimento del danno

Possiamo considerare l’IA come un prodotto difettoso in caso di anomalie? La progressiva integrazione di componenti software nei beni di consumo, nei processi industriali e nei servizi tecnologici ha reso necessario un ripensamento della disciplina della responsabilità per danno da prodotto difettoso, originariamente concepita con riferimento a beni prevalentemente materiali.

Il quadro normativo europeo è stato oggetto di una complessiva riforma ad opera delladirettiva (UE) 2024/2853del Parlamento europeo e del Consiglio, del 23 ottobre 2024. Il nuovo intervento legislativo, fondato sul principio della responsabilità oggettiva degli operatori economici, intende adeguare la tutela risarcitoria alle peculiarità dell’economia digitale, ampliando l’ambito applicativo della disciplina e rafforzando gli strumenti di tutela dei soggetti danneggiati.

Tra le innovazioni più significative assume particolare rilievo l’espressa inclusione del software nella nozione giuridica di prodotto, ai sensi dell’art. 4 della direttiva, con conseguente possibile applicazione della disciplina anche ai sistemi di intelligenza artificiale.

Parallelamente, l’art. 7 introduce criteri di valutazione della “difettosità” che tengono conto delle caratteristiche evolutive dei prodotti digitali e dei requisiti di cybersicurezza. Tali innovazioni trovano riscontro nello schema italiano di recepimento (Atto del Governo n. 434), che prevede, tra l’altro, la riformulazione degli artt. 115 e 117 del Codice del consumo.

Il presente contributo si propone, pertanto, di esaminare le principali novità introdotte dalla direttiva (UE) 2024/2853 e il relativo processo di recepimento nell’ordinamento italiano, approfondendo i presupposti della responsabilità per danno da prodotto difettoso, le peculiarità applicative ai software e ai sistemi di intelligenza artificiale e le conseguenze pratiche per le imprese che sviluppano, commercializzano o integrano soluzioni tecnologiche. Per un inquadramento generale sul risarcimento dei danni causati dall’Intelligenza Artificiale rinviamo a un nostroprecedente approfondimento.

La direttiva (UE) 2024/2853 e il recepimento nazionale

La disciplina europea della responsabilità per danno da prodotto difettoso trova la propria origine nella direttiva 85/374/CEE, recepita nell’ordinamento italiano con il D.P.R. 24 maggio 1988, n. 224, le cui disposizioni sono successivamente confluite negli artt. 114-127 del D.Lgs. 6 settembre 2005, n. 206 (Codice del consumo).

Tale disciplina, fondata su un regime di responsabilità oggettiva del produttore, è stata integralmente ripensata dalla direttiva (UE) 2024/2853, che introduce un quadro normativo armonizzato, volto a contemperare la tutela dei soggetti danneggiati con le esigenze di certezza giuridica degli operatori economici.

Come espressamente previsto dall’art. 1 della direttiva, la nuova disciplina stabilisce norme comuni in materia di responsabilità degli operatori economici per i danni causati da prodotti difettosi alle persone fisiche, perseguendo l’obiettivo di garantire un elevato livello di protezione nel mercato interno.

Nell’ordinamento italiano, il recepimento della direttiva è stato previsto dall’art. 1 della legge 17 marzo 2026, n. 36 (Legge di delegazione europea 2025), che include il provvedimento europeo nell’Allegato A, n. 4.

In attuazione della delega, il Governo ha predisposto lo schema di decreto legislativo identificato come Atto del Governo n. 434, approvato in via preliminare il 4 agosto 2026 e successivamente sottoposto all’esame parlamentare. Acquisiti i pareri delle competenti Commissioni, il Consiglio dei ministri ha approvato il provvedimento in esame definitivo il28 ottobre 2026, in vista della sua promulgazione e pubblicazione.

Sotto il profilo sistematico, l’art. 1 dello schema dispone l’integrale sostituzione del Titolo II della Parte IV del Codice del consumo, riformulando gli artt. 114-127. Particolare rilievo assumono il nuovo art. 115, relativo alle definizioni, l’art. 116, concernente gli operatori economici responsabili, l’art. 117, dedicato alla nozione di prodotto difettoso, nonché gli artt. 119 e 120, che disciplinano rispettivamente l’esibizione degli elementi di prova e il regime delle presunzioni.

Quanto all’applicazione temporale, l’art. 22 della direttiva fissa al 9 dicembre 2026 il termine per il recepimento. A seguito della rettifica pubblicata nella Gazzetta ufficiale dell’Unione europea il 7 maggio 2026, l’art. 2, par. 1, prevede che la nuova disciplina si applichi ai prodotti immessi sul mercato o messi in servizio dopo l’8 dicembre 2026.

Per i prodotti immessi sul mercato anteriormente continuerà invece a trovare applicazione il previgente regime, conformemente alla disciplina transitoria di cui all’art. 21 della direttiva.

Il software e l’intelligenza artificiale come prodotto difettoso

Una delle innovazioni più significative introdotte dalla direttiva (UE) 2024/2853 riguarda l’ampliamento della nozione giuridica di prodotto, che supera la tradizionale centralità dei beni materiali per ricomprendere espressamente anche le componenti immateriali dell’economia digitale. Ai sensi dell’art. 4, par. 1, n. 1), della direttiva, infatti, nella definizione di prodotto rientrano, oltre ai beni mobili, l’elettricità, i file per la fabbricazione digitale, le materie prime e, soprattutto, il software.

Come chiarito dal considerando n. 13, tale qualificazione opera indipendentemente dalle modalità di distribuzione e utilizzazione del programma informatico, sia esso incorporato in un dispositivo fisico, distribuito attraverso una rete di comunicazione, accessibile mediante infrastrutture cloud oppure commercializzato secondo il modelloSoftware-as-a-Service(SaaS).

La disciplina può pertanto trovare applicazione anche ai sistemi di intelligenza artificiale, il cui sviluppatore o fornitore può assumere la qualifica di fabbricante ai fini della responsabilità per danno da prodotto difettoso.

L’ampliamento riguarda altresì i cosiddettiservizi correlati, definiti dall’art. 4, par. 1, n. 3), come servizi digitali integrati o interconnessi a un prodotto, la cui assenza impedirebbe a quest’ultimo di svolgere una o più delle proprie funzioni. Tali servizi, quando ricorrono i presupposti normativi, sono qualificati come componenti del prodotto.

Si pensi, ad esempio, ai servizi di monitoraggio sanitario collegati a dispositivi intelligenti oppure ai sistemi digitali che consentono il controllo da remoto di apparecchiature elettroniche. Rimangono invece esclusi dalla nozione di prodotto i servizi autonomi in quanto tali e le mere informazioni contenute nei file digitali.

Una specifica delimitazione è inoltre prevista dall’art. 2, par. 2, della direttiva, che esclude il software libero e open source sviluppato o fornito nell’ambito di un’attività non commerciale. L’esclusione non si estende, tuttavia, al fabbricante che incorpori tali componenti in un prodotto successivamente commercializzato, come precisato dal considerando n. 15.

Queste innovazioni trovano espressa attuazione nell’art. 115 delCodice del consumo, nella formulazione prevista dall’art. 1 dello schema di decreto legislativo A.G. n. 434, che recepisce le nuove definizioni europee. Ne deriva un significativo ampliamento dell’ambito applicativo della responsabilità per danno da prodotto difettoso, destinato a interessare direttamente software house, sviluppatori di sistemi di IA e imprese che integrano tecnologie digitali nei propri prodotti.

Quando un software o un sistema di IA può essere considerato un prodotto difettoso?

L’estensione della disciplina ai software e ai sistemi di intelligenza artificiale impone di verificare quali condizioni consentano di qualificare tali tecnologie come prodotto difettoso. Il riferimento normativo è costituito dall’art. 7, par. 1, della direttiva (UE) 2024/2853, secondo cui un prodotto è considerato difettoso quando non offre la sicurezza che un consumatore può legittimamente attendersi oppure quella prescritta dal diritto dell’Unione o nazionale.

Tale definizione è recepita nell’art. 117, comma 1, del Codice del consumo, come riformulato dall’art. 1 dello schema di decreto legislativo (A.G. n. 434).

La valutazione della difettosità non dipende, pertanto, dalla mera presenza di anomalie tecniche, bensì dall’idoneità del prodotto a garantire il livello di sicurezza giuridicamente esigibile. A tal fine, l’art. 7, par. 2, della direttiva, riprodotto nel nuovo art. 117, comma 2, individua una serie non tassativa di circostanze rilevanti, tra cui la progettazione e le caratteristiche tecniche del prodotto, le istruzioni d’uso, l’utilizzazione ragionevolmente prevedibile e gli effetti derivanti dall’interconnessione con altri prodotti.

Particolare rilievo assume la lettera c) dell’art. 7, par. 2, che impone di considerare gli effetti sulla sicurezza della capacità del prodotto di continuare ad apprendere o acquisire nuove funzionalità dopo l’immissione sul mercato.

La disposizione assume evidente importanza per i sistemi di intelligenza artificiale, il cui comportamento può evolvere nel tempo, generando rischi non immediatamente riconoscibili nella fase di progettazione. Analogamente, la lettera e) attribuisce rilevanza al momento in cui il prodotto esce dall’effettivo controllo del fabbricante, mentre la lettera f) richiama espressamente i requisiti di cybersicurezza rilevanti per la sicurezza del prodotto.

Ne consegue che anche vulnerabilità informatiche, aggiornamenti difettosi o carenze nella gestione della sicurezza possono concorrere a qualificare un software come prodotto difettoso. Il tema si collega all’art. 10, par. 2, della direttiva, recepito nel nuovo art. 118, comma 2, del Codice del consumo, che limita la possibilità di escludere la responsabilità per difetti sopravvenuti riconducibili al software, ai relativi aggiornamenti o alla mancata adozione di aggiornamenti necessari per mantenere la sicurezza, quando tali elementi rimangano sotto il controllo del fabbricante.

Occorre, tuttavia, distinguere la difettosità rilevante ai fini della responsabilità del produttore dalla semplice inesatta esecuzione della prestazione contrattuale. Non ogni errore di programmazione, malfunzionamento o risultato inesatto generato da un sistema di IA determina automaticamente la qualificazione come prodotto difettoso, essendo necessario accertare una carenza del livello di sicurezza richiesto dalla normativa.

La responsabilità per prodotto difettoso: fabbricanti, sviluppatori e operatori della filiera digitale

Un’ulteriore innovazione della direttiva (UE) 2024/2853 riguarda l’ampliamento della platea dei soggetti chiamati a rispondere dei danni derivanti da un prodotto difettoso. L’art. 8 della direttiva, recepito nell’art. 116 del Codice del consumo, secondo la formulazione prevista dall’art. 1 dello schema di decreto legislativo (A.G. n. 434), individua un sistema di responsabilità che tiene conto della crescente complessità delle catene produttive e distributive, particolarmente evidente nel settore delle tecnologie digitali.

Il principale soggetto responsabile rimane il fabbricante del prodotto, la cui definizione, contenuta nell’art. 4, n. 10), della direttiva, ricomprende chiunque sviluppi, produca o fabbrichi un prodotto, ne affidi a terzi la progettazione o fabbricazione, oppure lo commercializzi presentandosi come fabbricante mediante l’apposizione del proprio nome o marchio.

La responsabilità si estende, ai sensi dell’art. 8, par. 1, lett. b), anche al fabbricante di un componente difettoso, qualora questo sia stato integrato o interconnesso con il prodotto sotto il controllo del fabbricante e ne abbia determinato la difettosità, ferma restando la responsabilità di quest’ultimo.

L’art. 8 contempla inoltre la responsabilità dell’importatore e del rappresentante autorizzato quando il fabbricante sia stabilito fuori dall’Unione europea, nonché, in via subordinata, del fornitore di servizi di logistica.

Il nuovo art. 116, commi 3 e 4, del Codice del consumo disciplina altresì la responsabilità sussidiaria del distributore e, alle condizioni previste dall’art. 6, par. 3, del regolamento (UE) 2022/2065 (Digital Services Act), di determinati fornitori di piattaforme online, qualora non venga identificato, secondo le modalità e i termini prescritti, un operatore economico responsabile stabilito nell’Unione.

Prodotto difettoso e danno risarcibile: quali pregiudizi sono tutelati dalla nuova disciplina?

L’ampliamento della nozione di prodotto difettoso si accompagna a una significativa revisione delle categorie di danno suscettibili di risarcimento. La disciplina è contenuta nell’art. 6 della direttiva (UE) 2024/2853, cui dà attuazione il nuovo art. 123 del Codice del consumo, nella formulazione prevista dall’art. 1 dello schema di decreto legislativo (A.G. n. 434). Le disposizioni individuano specifiche tipologie di pregiudizio risarcibile, mantenendo distinta la responsabilità speciale del produttore dalle altre forme di responsabilità civile.

In primo luogo, l’art. 6, par. 1, lett. a), riconosce il diritto al risarcimento dei danni derivanti dalla morte o dalle lesioni personali, comprendendovi espressamente anche i danni psicologici riconosciuti da un punto di vista medico.

Tale previsione assume particolare rilievo per i software e i sistemi di intelligenza artificiale impiegati in ambito sanitario, nei quali un difetto di funzionamento potrebbe determinare conseguenze pregiudizievoli per l’integrità psicofisica dell’utilizzatore.

La successiva lett. b) contempla il danneggiamento o la distruzione di beni, escludendo tuttavia il prodotto difettoso in sé, il prodotto danneggiato da una propria componente difettosa integrata o interconnessa dal fabbricante o sotto il suo controllo, nonché i beni utilizzati esclusivamente per finalità professionali.

Di particolare interesse per l’economia digitale è l’art. 6, par. 1, lett. c), che introduce espressamente la risarcibilità dei danni derivanti dalla distruzione o corruzione di dati non utilizzati per finalità professionali. La nuova previsione, recepita nell’art. 123, comma 1, lett. c), del Codice del consumo, consente di ricomprendere nel risarcimento anche i costi necessari per il recupero o il ripristino dei dati personali perduti a causa di un software difettoso.

Il legislatore europeo ha tuttavia inteso circoscrivere l’operatività della disciplina speciale. Ai sensi dell’art. 6, par. 2, il risarcimento comprende le perdite patrimoniali conseguenti alle tipologie di danno espressamente contemplate, nonché i pregiudizi non patrimoniali risarcibili secondo il diritto nazionale, fermo il richiamo all’art. 2059 c.c. contenuto nel nuovo art. 123.

L’accertamento della responsabilità per prodotto difettoso: onere della prova e nuove presunzioni

Tra le innovazioni più rilevanti della direttiva (UE) 2024/2853 assumono particolare importanza le disposizioni volte ad agevolare l’accertamento giudiziale della responsabilità per danno da prodotto difettoso, soprattutto nei casi caratterizzati da un’elevata complessità tecnologica.

La disciplina interviene sulle difficoltà probatorie del danneggiato, che spesso non dispone delle conoscenze tecniche e delle informazioni necessarie a dimostrare la difettosità di un software o di un sistema di intelligenza artificiale.

A tale esigenza risponde anzitutto l’art. 9 della direttiva, recepito nel nuovo art. 119 del Codice del consumo, secondo la formulazione prevista dall’art. 1 dello schema di decreto legislativo (A.G. n. 434). La disposizione introduce uno specifico meccanismo di esibizione giudiziale degli elementi di prova, consentendo al danneggiato, che abbia fornito elementi sufficienti a rendere plausibile la domanda risarcitoria, di ottenere dal giudice un ordine di esibizione nei confronti dell’operatore economico.

L’esibizione deve essere circoscritta a quanto necessario e proporzionato, nel rispetto della riservatezza delle informazioni e dei segreti commerciali. Nei giudizi riguardanti prodotti digitali, essa potrebbe interessare, ad esempio, la documentazione tecnica, i registri di funzionamento e le informazioni relative agli aggiornamenti software.

Il successivo art. 10 della direttiva, attuato dal nuovo art. 120 del Codice del consumo, introduce un articolato sistema di presunzioni relative. Pur confermando, al comma 1, che il danneggiato deve dimostrare il difetto, il danno e il nesso causale, il comma 2 prevede che la difettosità del prodotto possa presumersi quando il convenuto ometta di esibire le prove richieste, quando sia dimostrata la violazione di requisiti obbligatori di sicurezza pertinenti oppure quando il danno derivi da un malfunzionamento evidente verificatosi durante un utilizzo ragionevolmente prevedibile.

Il comma 3 contempla, inoltre, una presunzione del nesso causale quando il difetto sia accertato e la natura del danno risulti compatibile con esso.

Particolarmente significativa per i sistemi di intelligenza artificiale è la previsione dell’art. 10, par. 4, recepita nell’art. 120, comma 4, che consente di presumere il difetto, il nesso causale o entrambi quando la complessità tecnica o scientifica renda eccessivamente difficile la prova e il danneggiato dimostri la probabilità dei relativi presupposti.

La riforma non introduce, dunque, un’inversione generalizzata dell’onere probatorio, ma un sistema di strumenti processuali destinati a riequilibrare l’asimmetria informativa tra danneggiato e produttore, ferma restando, ai sensi dell’art. 120, comma 5, la possibilità per quest’ultimo di fornire prova contraria.

Prodotto difettoso, AI Act e cybersecurity

La nuova disciplina della responsabilità per danno da prodotto difettoso si inserisce in un quadro normativo europeo sempre più articolato, nel quale assumono particolare rilevanza il regolamento (UE) 2024/1689 (AI Act) e il regolamento (UE) 2024/2847 (Cyber Resilience Act). Tali provvedimenti, pur perseguendo finalità differenti, concorrono alla definizione degli standard di sicurezza applicabili alle tecnologie digitali e, conseguentemente, alla valutazione della difettosità del prodotto.

In particolare, l’art. 15 dell’AI Act stabilisce specifici requisiti di accuratezza, robustezza e cybersicurezza per i sistemi di intelligenza artificiale ad alto rischio, mentre gli artt. 13 e 14 del Cyber Resilience Act introducono obblighi relativi alla progettazione sicura, alla gestione delle vulnerabilità e alla segnalazione degli incidenti per i prodotti con elementi digitali rientranti nel relativo ambito applicativo.

La conformità alla normativa settoriale non costituisce, tuttavia, un’esimente generale dalla responsabilità civile. L’art. 11 della direttiva, recepito nel nuovo art. 118 del Codice del consumo, individua tassativamente le circostanze che consentono all’operatore economico di escludere la propria responsabilità.

Tra queste rientra l’impossibilità oggettiva di individuare il difetto sulla base delle conoscenze scientifiche e tecniche disponibili, secondo la disciplina dei cosiddettirischi di sviluppo. Particolare attenzione merita, inoltre, l’art. 118, comma 2, che limita l’operatività dell’esimente relativa alla sopravvenienza del difetto quando questo sia riconducibile, sotto il controllo del fabbricante, al software, agli aggiornamenti o alla mancata adozione delle misure necessarie a mantenerne la sicurezza.

Assistenza legale qualificata in materia di responsabilità e prodotti digitali

Il nostro Studio Legale presta assistenza e consulenza alle imprese nelle materie del diritto commerciale e delle nuove tecnologie, con particolare riferimento alla cybersicurezza e allaregolamentazione dell’intelligenza artificiale, offrendo supporto nella prevenzione e nella gestione dei rischi legali connessi allo sviluppo e all’impiego di soluzioni tecnologiche.

Contattaci per un confronto.

 

Ai sensi dell’art. 70-quater della Legge 633/1941, ai fini della tutela del diritto d’autore, si dichiara che il presente contenuto è riservato, e ne è vietata la riproduzione o l’estrazione di testo, anche mediante sistemi di intelligenza artificiale.

Contratto di cessione software: perchè formalizzare per iscritto il trasferimento di diritti?

Contratto di cessione software: perchè formalizzare per iscritto il trasferimento di diritti?

La cessione software è l’operazione attraverso la quale possono essere trasferiti, in tutto o in parte, i diritti di utilizzazione economica su un programma informatico. Nella prassi, tuttavia, i rapporti tra chi sviluppa il software, chi ne commissiona la realizzazione sono spesso lasciati a un accordo verbale o addirittura “implicito” tra le parti. Ne derivano spesso enormi incertezze in ordine all’estensione dei diritti acquisiti e alle attività che ciascuna parte è legittimata a svolgere.

Per tale ragione, è importante che la cessione software sia formalizzata mediante un accordo scritto, capace di individuare con chiarezza l’oggetto del trasferimento, i diritti coinvolti e gli impegni delle parti.

Il presente articolo si propone di esaminare la disciplina applicabile alla cessione software, chiarendone la funzione, le principali clausole e le differenze rispetto alla licenza d’uso.

La disciplina della cessione software nell’ordinamento italiano

Il contratto di cessione software non trova, nell’ordinamento italiano, una disciplina contrattuale organica dedicata esclusivamente a tale operazione. Il suo inquadramento richiede, pertanto, di coordinare le norme generali del codice civile in materia di contratti con le disposizioni speciali poste a tutela dei programmi per elaboratore.

Il principale riferimento normativo è costituito dalla legge 22 aprile 1941, n. 633, in materia didiritto d’autore, le cui disposizioni devono essere considerate anche alla luce della direttiva 2009/24/CE, relativa alla tutela giuridica dei programmi per elaboratore.

In particolare, gli artt. 1 e 2, n. 8, della legge sul diritto d’autore riconoscono protezione ai programmi per elaboratore come opere letterarie, purché originali e risultanti dalla creazione intellettuale dell’autore. La tutela riguarda la forma di espressione del programma e non si estende, in quanto tali, alle idee e ai principi che ne sono alla base.

Nell’ambito di tale disciplina, l’art. 64-bisindividua le principali facoltà riservate al titolare dei diritti sul software, tra cui la riproduzione, la modifica e la distribuzione al pubblico del programma. Rimangono ferme le eccezioni e le limitazioni previste dalla legge, in particolare dagli artt. 64-tere 64-quater.

Per quanto riguarda la circolazione dei diritti, l’art. 107 della medesima legge ammette il trasferimento dei diritti di utilizzazione economica nei modi e nelle forme consentiti dall’ordinamento. Il successivo art. 110 stabilisce, inoltre, che la trasmissione di tali diritti deve essere provata per iscritto: si tratta di una disposizione centrale per comprendere l’importanza della formalizzazione della cessione software.

A queste norme si affiancano le disposizioni del codice civile relative alla formazione, all’interpretazione e all’esecuzione dei contratti. A seconda del contenuto dell’accordo, possono assumere rilievo anche le regole previste per il rapporto nel quale la cessione software si inserisce, come uncontratto d’opera o di appalto avente a oggetto lo sviluppo del programma.

Che cos’è la cessione software? Le differenze rispetto alla licenza d’uso

Con il contratto di cessione software, un soggetto, denominatocedente, trasferisce a un altro soggetto, denominatocessionario, tutti o alcuni dei diritti di utilizzazione economica di cui è titolare su un programma per elaboratore.

Il cessionario acquista, pertanto, la titolarità dei diritti oggetto dell’accordo, secondo l’estensione e i limiti pattuiti. Il trasferimento può riguardare specifiche modalità di sfruttamento del programma ed essere disciplinato, nei limiti consentiti dall’ordinamento, anche sotto il profilo territoriale e temporale.

La cessione software può rispondere all’interesse di un’impresa a disporre del programma per svilupparlo, modificarlo o valorizzarlo commercialmente. La possibilità di compiere tali attività dipenderà, tuttavia, dai diritti effettivamente trasferiti e dal contenuto dell’accordo concluso con il cedente.

Diversa è la funzione del contratto dilicenza d’uso, mediante il quale il titolare autorizza un altro soggetto a utilizzare o sfruttare il software secondo le condizioni stabilite, senza che ciò comporti, di per sé, il trasferimento della titolarità dei diritti sul programma.

La licenza può essere esclusiva o non esclusiva e avere un contenuto più o meno ampio: può consentire l’utilizzo del programma per determinate finalità oppure attribuire ulteriori facoltà, come quella di autorizzare terzi, ove ciò sia previsto dall’accordo. Restano ferme le facoltà che la legge riconosce al legittimo utilizzatore.

Occorre, inoltre, distinguere la cessione dei diritti dalla consegna di una copia del software. L’art. 109 della legge sul diritto d’autore stabilisce, infatti, che la cessione di uno o più esemplari dell’opera non comporta, salvo patto contrario, la trasmissione dei relativi diritti di utilizzazione. La disponibilità di una copia non è, dunque, sufficiente a dimostrare che il destinatario abbia acquisito tali diritti.

La distinzione assume particolare rilievo quando un’impresa commissiona lo sviluppo di un programma o acquisisce un applicativo da un fornitore. In tali circostanze, per stabilire quali diritti spettino alle parti, occorre esaminare il contenuto degli accordi, le prestazioni previste e la disciplina applicabile al rapporto.

La titolarità dei diritti sul software: dipendenti, sviluppatori esterni e terzi

Per stabilire se e in quali termini possa essere concluso un contratto di cessione software, occorre anzitutto verificare a chi spettino i diritti di utilizzazione economica sul programma. Tale accertamento richiede di distinguere la posizione dell’autore, che ha apportato il contributo creativo, da quella del soggetto titolare dei diritti patrimoniali di sfruttamento.

Una disciplina specifica è prevista per il software realizzato nell’ambito di un rapporto di lavoro subordinato. L’art. 12-bisdellalegge sul diritto d’autorestabilisce che, salvo patto contrario, il datore di lavoro è titolare del diritto esclusivo di utilizzazione economica del programma creato dal dipendente nell’esecuzione delle proprie mansioni o su istruzioni impartite dallo stesso datore di lavoro. Al lavoratore permane, invece, il diritto morale di essere riconosciuto autore dell’opera.

Più articolata è la questione del software la cui realizzazione sia affidata a professionisti o sviluppatori esterni. L’art. 12-bissi riferisce espressamente al lavoratore dipendente; tuttavia, la giurisprudenza di merito ne ha in alcuni casi applicato i principi in via analogica anche al lavoro autonomo, riconoscendo al committente, salvo diverso accordo, la titolarità originaria dei diritti di utilizzazione economica sul programma commissionato.

La verifica diviene ancor più importante quando alla realizzazione del programma abbiano contribuito più soggetti oppure siano state integrate componenti preesistenti o soggette a licenze di terzi. In tali ipotesi, occorre accertare l’origine dei diversi elementi e le condizioni che ne consentono l’utilizzo.

Una cessione software predisposta con attenzione dovrà, dunque, tenere conto della provenienza del programma e dei diritti effettivamente disponibili in capo al cedente, così da individuare con chiarezza l’oggetto del trasferimento e prevenire contestazioni sulla sua titolarità.

Cessione software e forma scritta: l’importanza della prova

Un aspetto decisivo della cessione software riguarda la prova dell’avvenuto trasferimento dei diritti. L’art. 110 della legge sul diritto d’autore prescrive che«la trasmissione dei diritti di utilizzazione deve essere provata per iscritto». In termini analoghi, l’art. 2581 del codice civile richiede la prova scritta del trasferimento dei diritti di utilizzazione per atto tra vivi.

La scrittura è richiesta, dunque, a fini probatori (ad probationem) e non, in via generale, quale requisito di validità del contratto (ad substantiam). Ciò significa che, qualora la cessione software sia stata effettivamente concordata e ricorrano gli altri presupposti richiesti, la sola mancanza di un contratto scritto non ne determina automaticamente la nullità.

Tale distinzione non elimina, tuttavia, le difficoltà che possono sorgere in caso di contestazione. In una controversia tra cedente e cessionario, la parte che intenda far valere il trasferimento deve poterlo dimostrare. La prova testimoniale incontra i limiti previsti dall’art. 2725 del codice civile, salvo le eccezioni applicabili; possono invece assumere rilievo, nei casi consentiti, altri mezzi di prova, come la confessione o il giuramento.

La prova scritta non deve necessariamente coincidere con un documento unico denominato “contratto di cessione”: può risultare anche da altra documentazione idonea a dimostrare l’accordo. Quando si tratta di comunicazioni o documenti informatici, la loro efficacia deve essere valutata secondo le regole applicabili, tenendo conto delle caratteristiche e della provenienza del documento.

Occorre, inoltre, distinguere la trasmissione dei diritti dalle ipotesi in cui essi sorgano direttamente in capo al committente. La Corte di cassazione ha chiarito che l’art. 110 l.d.a. non si applica quando, in ragione del rapporto di appalto, l’acquisto dei diritti è a titolo originario e non si realizza un trasferimento.

La formalizzazione rimane, in ogni caso, una cautela importante: consente di individuare il programma e l’estensione dei diritti attribuiti, riducendo le incertezze sull’assetto concordato. Una fattura, la consegna del programma o il pagamento del corrispettivo non necessariamente chiariscono, da soli, se le parti abbiano voluto una cessione software e quali diritti ne siano oggetto.

Quali diritti possono essere trasferiti con la cessione software

Il contratto di cessione software può avere a oggetto tutti i diritti di utilizzazione economica sul programma oppure soltanto alcune delle facoltà che li compongono. La scelta dipende dagli interessi delle parti e dai diritti di cui il cedente può effettivamente disporre.

Tra le facoltà di particolare rilievo vi è il diritto di riproduzione del programma, che comprende la realizzazione di copie, permanenti o temporanee, totali o parziali. A esso si affiancano i diritti di traduzione, adattamento, trasformazione e modifica del software, nonché di riproduzione del programma risultante da tali interventi.

L’individuazione di queste facoltà è rilevante quando il cessionario intenda sviluppare nuove funzionalità, adattare il programma alle proprie esigenze oppure affidarne l’evoluzione a soggetti terzi.

La cessione software può comprendere anche il diritto di distribuzione al pubblico del programma o delle sue copie, inclusa la locazione, nonché la possibilità di autorizzare terzi all’utilizzo, nei limiti dei diritti acquisiti e degli accordi applicabili. Si tratta di facoltà distinte, la cui estensione deve essere definita con attenzione.

Per evitare incertezze, è opportuno precisare le modalità di sfruttamento attribuite al cessionario, l’eventuale ambito territoriale e temporale del trasferimento e le versioni del programma interessate. Occorre, inoltre, individuare le componenti preesistenti o appartenenti a terzi e verificare se il loro utilizzo rimanga soggetto a specifiche licenze.

L’esercizio dei diritti acquisiti deve comunque coordinarsi con le limitazioni previste dalla legge. Ad esempio, l’art. 64-tertutela la possibilità, per chi abbia diritto di utilizzare una copia del programma, di effettuare una copia di riserva quando questa sia necessaria per l’uso.

Dai diritti patrimoniali devono essere distinti i diritti morali dell’autore, che sono inalienabili e permangono anche dopo la cessione. Tra essi rientrano il diritto di rivendicare la paternità dell’opera e quello di opporsi alle modificazioni che possano pregiudicare l’onore o la reputazione dell’autore. La permanenza di tali prerogative non esclude, di per sé, gli interventi sul software compresi nelle facoltà trasferite, nel rispetto della disciplina applicabile.

Le clausole principali del contratto di cessione software

La redazione di un contratto di cessione software richiede una precisa individuazione del programma e dei diritti che le parti intendono trasferire. Il contenuto dell’accordo deve essere calibrato sulle caratteristiche dell’operazione e sulle esigenze del cedente e del cessionario.

Anzitutto, è opportuno identificare il software oggetto della cessione, specificandone la versione, i moduli e gli ulteriori elementi compresi nell’accordo. Un’adeguata descrizione, eventualmente accompagnata da un allegato tecnico, permette di distinguere il programma trasferito dalle componenti che le parti intendano escludere.

La disciplina della cessione dovrà precisare i diritti di utilizzazione economica attribuiti al cessionario e il momento in cui il trasferimento è destinato a produrre effetti. Le parti potranno inoltre regolare l’eventuale corrispettivo, le modalità di pagamento e, se concordato, il collegamento tra il trasferimento, il collaudo o il pagamento stesso.

Particolare attenzione merita la consegna del codice sorgente. L’accordo dovrebbe chiarire se, quando e con quali modalità esso debba essere messo a disposizione del cessionario, insieme alla documentazione e alle informazioni tecniche necessarie per l’installazione, la gestione e lo sviluppo del programma..

È inoltre opportuno individuare le componenti preesistenti e quelle appartenenti a terzi, comprese le librerie distribuite con licenzeopen source. Il contratto potrà specificare quali elementi siano inclusi nella cessione e quali, invece, rimangano soggetti alle rispettive condizioni di licenza.

Un ulteriore profilo riguarda le dichiarazioni e garanzie del cedente sulla disponibilità dei diritti trasferiti e sull’eventuale esistenza di vincoli o pretese di terzi. Le parti potranno disciplinare le rispettive responsabilità e prevedere, ove appropriato, impegni di manleva.

Infine, quando la cessione software si accompagna ad altre prestazioni, è utile regolare distintamente le eventuali attività di collaudo, assistenza e manutenzione, precisandone contenuto, durata e costi.

Mancata formalizzazione della cessione software: ci sono rischi?

La mancata o incompleta formalizzazione della cessione software è foriera di determinati rischi.

Un primo rischio è rappresentato dall’insorgere di controversie sull’estensione dei diritti. L’impresa potrebbe ritenere di poter modificare il software, affidarne lo sviluppo a un diverso fornitore o concederlo ai propri clienti, mentre lo sviluppatore potrebbe sostenere di averne autorizzato soltanto un utilizzo circoscritto.

Un problema distinto riguarda la disponibilità del codice sorgente e della documentazione tecnica. Anche quando all’impresa spettino i diritti sul programma, la mancanza degli elementi necessari per intervenire sul codice può rendere difficoltosa la correzione degli errori o la prosecuzione dello sviluppo, soprattutto se il rapporto con il fornitore si interrompe.

L’assenza di una disciplina dettagliata può inoltre rendere più difficile ricostruire la provenienza delle componenti incorporate nel programma e verificare le condizioni delle licenze di terzi. Ciò assume rilievo qualora l’impresa intenda modificare o distribuire il software, attività da valutare anche alla luce dei diritti e degli obblighi relativi a tali componenti.

Le incertezze sulla cessione software possono, infine, emergere nelle operazioni di investimento o di acquisizione societaria. Durante le verifiche preliminari, investitori e potenziali acquirenti possono richiedere la documentazione relativa alla titolarità del programma e ai rapporti con gli sviluppatori. Eventuali lacune possono allungare le verifiche, comportare richieste di ulteriori garanzie e incidere sulla valutazione dell’operazione.

Assistenza legale in materia di cessione software

La cessione software serve per disciplinare la circolazione dei diritti su un programma informatico e definirne le possibilità di utilizzazione economica.

Affinché l’operazione risponda alle sue finalità, è opportuno valutare il ruolo che il programma assumerà nell’organizzazione e nel modello commerciale dell’impresa. Le esigenze di chi utilizza un applicativo per attività interne possono essere diverse da quelle di chi intende sviluppare un prodotto, integrarlo in altri sistemi o metterlo a disposizione di terzi. L’assetto contrattuale dovrà essere coerente con tali obiettivi e con i diritti di cui il cedente dispone.

Il nostro Studio Legale presta assistenza in materia didiritto d’impresaediritto delle nuove tecnologie, con particolare riferimento alla contrattualistica informatica e alla tutela della proprietà intellettuale e industriale. Lo Studio affianca imprese e professionisti nella predisposizione, negoziazione e revisione degli accordi relativi al software.

Contattaci per un confronto.

 

Ai sensi dell’art. 70-quater della Legge 633/1941, ai fini della tutela del diritto d’autore, si dichiara che il presente contenuto è riservato, e ne è vietata la riproduzione o l’estrazione di testo, anche mediante sistemi di intelligenza artificiale.

Decreto 179/2026: entra in vigore la normativa nazionale di adeguamento all’AI Act

Decreto 179/2026: entra in vigore la normativa nazionale di adeguamento all’AI Act

Il 23 ottobre 2026 entra in vigore ilDecreto 179, pubblicato nella Gazzetta Ufficiale n. 234 dell’8 ottobre 2026, con il quale il legislatore nazionale ha adeguato l’ordinamento italiano al Regolamento (UE) 2024/1689, meglio noto comeAI Act.

Il Decreto 179 rende concretamente operativo a livello nazionale il sistema di applicazione del Regolamento europeo, individuando le autorità competenti, disciplinandone i poteri di vigilanza e sanzionatori e introducendo specifiche disposizioni in materia di sperimentazione e sandbox.

L’obiettivo del presente contributo è esaminare il contenuto del Decreto 179 privilegiando i profili di maggiore interesse operativo per imprese e soggetti che impiegano sistemi di intelligenza artificiale.

Il calendario delle scadenze dell’AI Act

L’entrata in vigore del Decreto 179 deve essere coordinata con il calendario di applicazione progressiva dell’AI Act. IlRegolamento (UE) 2024/1689, infatti, ha previsto sin dall’origine un’applicazione graduale delle proprie disposizioni, successivamente interessata da modifiche del calendario relativo, in particolare, ai sistemi di intelligenza artificiale ad alto rischio.

Una prima parte della disciplina europea è già applicabile dal 2 febbraio 2025, con riferimento, tra l’altro, alle definizioni, all’alfabetizzazione in materia di intelligenza artificiale e alla maggior parte delle pratiche di IA vietate. Dal 2 agosto 2025 sono divenute applicabili ulteriori disposizioni concernenti la governance europea, i modelli di intelligenza artificiale per finalità generali e il sistema sanzionatorio.

Dal 2 agosto 2026 l’AI Act è entrato nella sua fase generale di applicazione, pur permanendo alcune significative disposizioni soggette a termini successivi. In particolare, ulteriori divieti introdotti nell’art. 5 troveranno applicazione dal 2 dicembre 2026, mentre la disciplina relativa ai sistemi ad alto rischio ricompresi nell’Allegato III diverrà applicabile dal 2 dicembre 2027.

Per i sistemi ad alto rischio collegati ai prodotti disciplinati dalla normativa europea di armonizzazione indicata nell’Allegato I, il termine è invece fissato al 2 agosto 2028. Sul calendario aggionato delle scadenze rinviamo a un nostroprecedente approfondimento.

È all’interno di questa scansione temporale che deve essere letto il Decreto 179. Il legislatore nazionale interviene, infatti, mentre una parte significativa dell’AI Act è già direttamente applicabile, predisponendo l’apparato istituzionale necessario a garantirne l’effettiva attuazione nell’ordinamento italiano.

Parallelamente, lo stesso Decreto 179 fissa specifici termini per l’adozione dei successivi provvedimenti attuativi: alcune misure dovranno essere adottate entro novanta giorni, mentre per l’adeguamento della formazione professionale sono previsti termini di sei mesi e, in materia di parametri per l’equo compenso, un termine di dodici mesi.

AgID, ACN e autorità di settore nel Decreto 179

Uno dei profili centrali del Decreto 179 riguarda la definizione dell’assetto istituzionale nazionale chiamato ad assicurare l’attuazione dell’AI Act. Il legislatore ha scelto un modello di vigilanza articolato, nel quale le competenze sono distribuite tra autorità generali e autorità settoriali, con meccanismi di coordinamento destinati a evitare sovrapposizioni e vuoti di tutela.

L’Agenzia per l’Italia Digitale (AgID) assume il ruolo di autorità nazionale di notifica. In tale veste, è responsabile delle procedure relative alla valutazione, designazione e notifica degli organismi di valutazione della conformità, nonché del loro successivo monitoraggio.

L’Agenzia per la cybersicurezza nazionale (ACN) riveste invece una posizione centrale sul versante della vigilanza del mercato. Il Decreto 179 la individua quale principale autorità competente sui sistemi di intelligenza artificiale e quale punto di contatto unico nazionale, attribuendole compiti di controllo, coordinamento e intervento nei confronti degli operatori soggetti alla disciplina europea.

Accanto ad AgID e ACN operano le autorità competenti nei settori regolamentati. In particolare, per i sistemi di IA ad alto rischio utilizzati nell’erogazione di servizi finanziari, assumono rilievo la Banca d’Italia, la CONSOB e l’IVASS, secondo i rispettivi ambiti di vigilanza. Restano inoltre ferme le competenze del Garante per la protezione dei dati personali, nei casi espressamente previsti dal Regolamento.

Intelligenza Artificiale, poteri dell’ACN e profili di cybersicurezza

Nel sistema delineato dal Decreto 179, l’Agenzia per la cybersicurezza nazionale assume un ruolo particolarmente incisivo, non soltanto quale autorità di vigilanza del mercato, ma anche quale soggetto chiamato a presidiare l’intersezione tra conformità dei sistemi di intelligenza artificiale esicurezza informatica.

L’art. 15 attribuisce infatti all’ACN i poteri di vigilanza e ispettivi previsti dall’AI Act e dalla disciplina europea sulla vigilanza del mercato, consentendo all’Agenzia di verificare il rispetto degli obblighi applicabili ai sistemi immessi sul mercato, messi in servizio o utilizzati in Italia.

Il Decreto 179 rafforza inoltre il carattere interistituzionale della vigilanza. L’ACN è chiamata a coordinarsi con le autorità settoriali competenti e con il Garante per la protezione dei dati personali e può individuare forme di cooperazione operativa e informativa con Guardia di finanza, Polizia di Stato, Arma dei Carabinieri e Direzione investigativa antimafia, nei rispettivi ambiti di competenza. La vigilanza può essere attivata a seguito della segnalazione di incidenti gravi, della presentazione di reclami, di comunicazioni provenienti da altre autorità oppure d’ufficio dalla stessa Agenzia.

Vigilanza, ispezioni e reclami: come funziona l’enforcement dell’AI Act in Italia

La disciplina introdotta dal Decreto 179 assume particolare rilievo anche sotto il profilo dell’enforcement, poiché definisce le modalità attraverso le quali le autorità nazionali possono intervenire in presenza di possibili violazioni dell’AI Act.

Il sistema è costruito secondo una logica di vigilanza diffusa e coordinata, nella quale i controlli possono essere attivati non soltanto a seguito di iniziative delle autorità, ma anche sulla base di segnalazioni e reclami provenienti dall’esterno.

In particolare, il procedimento di vigilanza dell’ACN può essere avviato a seguito della segnalazione di un incidente grave ai sensi dell’art. 73 dell’AI Act, della presentazione di un reclamo non manifestamente infondato, di una segnalazione proveniente da altre autorità ovvero d’ufficio.

Il Decreto 179 attribuisce inoltre alle autorità nazionali di vigilanza del mercato il compito di ricevere e trattare i reclami previsti dall’art. 85 del Regolamento, assicurando il pieno contraddittorio. Qualora il reclamo venga presentato a un’autorità priva di competenza, questo deve essere trasmesso d’ufficio all’autorità competente, con contestuale comunicazione al reclamante.

Le sanzioni del Decreto 179

Uno degli aspetti di maggiore rilievo operativo del Decreto 179 è rappresentato dalla disciplina sanzionatoria, che rende concretamente azionabile nell’ordinamento nazionale il sistema di enforcement previsto dall’AI Act.

Il legislatore individua le autorità competenti all’irrogazione delle sanzioni e coordina il procedimento nazionale con l’art. 99 del Regolamento, confermando un apparato particolarmente severo, costruito in funzione della natura e della gravità della violazione.

Le pratiche vietate ai sensi dell’art. 5 dell’AI Act sono soggette, salvo che il fatto costituisca reato, a una sanzione amministrativa pecuniaria fino a 35 milioni di euro ovvero, se superiore, fino al 7% del fatturato mondiale totale annuo dell’esercizio precedente.

Per la violazione di numerosi obblighi gravanti sui soggetti della filiera dell’intelligenza artificiale, il Decreto 179 prevede invece sanzioni fino a 15 milioni di euro o al 3% del fatturato mondiale, mentre la comunicazione alle autorità o agli organismi notificati di informazioni inesatte, incomplete o fuorvianti può comportare una sanzione fino a 7,5 milioni di euro o all’1% del fatturato.

Ulteriori violazioni sono assoggettate a sanzioni fino a un milione di euro o allo 0,5% del fatturato mondiale annuo. Per PMI, microimprese e start-up innovative continua ad applicarsi il criterio proporzionato previsto dall’AI Act.

Particolarmente significativa è, tuttavia, la previsione di misure non pecuniarie. In presenza di violazioni caratterizzate da scarsa offensività o pericolosità, l’autorità può ordinare al soggetto interessato di eliminare l’infrazione e di astenersi dal ripeterla, indicando anche le misure correttive da adottare e il termine entro cui conformarsi. Qualora la violazione sia già cessata, può essere disposta una dichiarazione pubblica concernente l’illecito e il soggetto responsabile. L’inosservanza dell’ordine di adeguamento può determinare l’applicazione della sanzione pecuniaria con un aumento sino a un terzo.

Regulatory Sandbox per Start up: lo Spazio di sperimentazione italiano per l’IA

Tra le innovazioni più rilevanti introdotte dal Decreto 179 assume particolare importanza l’istituzione dello Spazio di sperimentazione italiano per l’intelligenza artificiale, previsto dall’art. 26 in attuazione dell’art. 57 dell’AI Act.

Si tratta di una vera e propriaregulatory sandbox, concepita come ambiente controllato nel quale fornitori e potenziali fornitori di sistemi di IA possono sviluppare, testare e validare soluzioni innovative sotto la vigilanza delle autorità nazionali competenti.

Lo Spazio di sperimentazione è posto sotto la vigilanza diretta di AgID e ACN, che ne assicurano congiuntamente la gestione secondo le rispettive competenze. La finalità è quella di promuovere un apprendimento regolatorio fondato sulle evidenze emerse durante la sperimentazione e di agevolare l’accesso al mercato europeo dei sistemi conformi alla disciplina dell’AI Act.

Il Decreto 179 attribuisce particolare rilievo alle piccole e medie imprese e alle start-up, per le quali è prevista una priorità di accesso secondo criteri che dovranno essere definiti dai successivi provvedimenti attuativi.

Il Gruppo operativo incaricato della gestione tecnica dello Spazio è chiamato a monitorare l’esecuzione dei piani di sperimentazione anche mediante strumenti di logging, auditing e tracciabilità delle modifiche, nonché attraverso verifiche di compliance normativa e regolatoria.

Il legislatore nazionale prevede inoltre la possibilità di istituire ulteriori spazi di sperimentazione per sistemi di IA impiegabili in ambito duale, per applicazioni destinate all’attività giudiziaria e a livello regionale o locale. È altresì previsto il coordinamento con la sperimentazione FinTech per i sistemi destinati ai settori bancario, finanziario e assicurativo.

Opportunità per start-up e imprese digitali

Il Decreto 179 introduce anche strumenti potenzialmente favorevoli allo sviluppo dell’ecosistema nazionale dell’intelligenza artificiale. Per start-up e imprese digitali, il nuovo quadro normativo rappresenta un fattore di maggiore certezza regolatoria, soprattutto nella fase di sviluppo, validazione e immissione sul mercato di soluzioni basate su IA.

Il Decreto Legislativo in esame valorizza espressamente il ruolo delle PMI e delle start-up e promuove forme di collaborazione finalizzate al trasferimento tecnologico, alla ricerca applicata e alla sperimentazione.

Accanto alla dimensione regolatoria, il Decreto 179 interviene anche sulla protezione del patrimonio tecnologico delle imprese che sviluppano sistemi di intelligenza artificiale. L’art. 52 modifica infatti l’art. 98 del Codice della proprietà industriale, chiarendo espressamente che possono essere tutelati come segreti commerciali, quando ricorrono i requisiti previsti dalla legge, anche i dati, gli algoritmi e i metodi matematici utilizzati per l’addestramento dei sistemi di IA. La disposizione ricomprende in tale nozione anche le architetture dei modelli, le funzioni di ottimizzazione, le procedure e le configurazioni di addestramento e, più in generale, gli elementi tecnico-computazionali funzionali allo sviluppo del sistema.

La norma non attribuisce, quindi, un nuovo diritto esclusivo sull’algoritmo in quanto tale, ma chiarisce che questi elementi possono essere protetti attraverso la disciplina del know-how e dei segreti commerciali. La tutela opera, tuttavia, soltanto quando l’informazione sia effettivamente segreta, possieda un valore economico proprio in ragione della sua riservatezza e sia sottoposta a misure ragionevolmente adeguate a mantenerla tale.

Per start-up, software house e imprese che sviluppano soluzioni di intelligenza artificiale, il profilo assume una rilevanza concreta. La protezione dell’asset tecnologico dipenderà infatti anche dalla capacità dell’impresa di dimostrare di avere adottato adeguati presidi contrattuali, organizzativi e tecnici, quali accordi di riservatezza, clausole specifiche nei rapporti con sviluppatori e fornitori, sistemi di controllo degli accessi, segregazione delle informazioni e procedure interne di gestione del know-how.

Assistenza legale in materia di Intelligenza Artificiale

Il nostro Studio Legale assiste imprese e start-up nei principali ambiti del diritto dell’innovazione e delle nuove tecnologie, con particolare riferimento allanormativa sull’intelligenza artificiale, alla AI compliance, alla cybersicurezza e alla proprietà industriale. Supportiamo le aziende nella costruzione di modelli di governance conformi al quadro europeo e nazionale, capaci di coniugare sviluppo tecnologico, tutela dei diritti e gestione del rischio regolatorio.

Contattaci per un confronto.

Ai sensi dell’art. 70-quater della Legge 633/1941, ai fini della tutela del diritto d’autore, si dichiara che il presente contenuto è riservato, e ne è vietata la riproduzione o l’estrazione di testo, anche mediante sistemi di intelligenza artificiale.

Conferimento di software e costituzione di start up innovativa

Conferimento di software e costituzione di start up innovativa

Qual è il momento migliore per effettuare il conferimento di software? Quando si costituisce una start up il programma informatico può già costituire un asset economicamente significativo, talvolta essenziale per l’attuazione stessa del progetto imprenditoriale.

La circostanza che il software venga utilizzato dal suo autore – sia anche socio, amministratore o fondatore della stessa – non determina di per sé, il trasferimento alla società dei relativi diritti di utilizzazione economica. Occorre, quindi, verificare quale soggetto ne sia effettivamente titolare e individuare il titolo giuridico attraverso il quale la start-up acquisisce il diritto di utilizzare e sfruttare economicamente il programma.

Il problema assume particolare importanza quando l’attività d’impresa è esercitata prevalentemente attraverso internet, un’applicazione o una piattaforma digitale. In simili modelli di business, il software rappresenta ilcoredel patrimonio aziendale.

In tale prospettiva, il conferimento di software è la modalità eletta attraverso cui il programma e i relativi diritti possono essere attribuiti alla società sin dalla sua costituzione. Il trasferimento può, tuttavia, avvenire anche in un momento successivo, mediante cessione, licenza o altro titolo idoneo a garantire alla società la disponibilità giuridica dell’asset.

L’obiettivo del presente contributo è, pertanto, esaminare la disciplina del conferimento di software nelle società di capitali, con particolare attenzione alla costituzione di una start-up innovativa, distinguendo il conferimento effettuatoab initiodal successivo trasferimento dei diritti sul programma.

Il conferimento in natura e il trasferimento dei diritti sul software. I riferimenti normativi

Nelle società di capitali il conferimento rappresenta l’apporto mediante il quale il socio contribuisce alla formazione del patrimonio sociale, ricevendo in contropartita la partecipazione nella società. Accanto al conferimento in denaro, l’ordinamento ammette il conferimento di beni e diritti suscettibili di una valutazione economica. Nellesocietà a responsabilità limitata,in particolare, l’art. 2464 c.c. stabilisce espressamente che possono essere conferiti «tutti gli elementi dell’attivo suscettibili di valutazione economica»,mentre l’art. 2465 c.c. assoggetta i conferimenti di beni in natura e di crediti a una specifica relazione di stima. Per le società per azioni, gli artt. 2342 e 2343 c.c. contemplano analogamente il conferimento di beni in natura e crediti, secondo una disciplina valutativa parzialmente differente.

Il conferimento di software deve essere ricondotto a tale categoria, avuto riguardo non tanto al supporto materiale sul quale il programma è eventualmente memorizzato, quanto ai diritti di utilizzazione economica che ne consentono lo sfruttamento. Il software costituisce infatti un bene immateriale protetto dalla disciplina sul diritto d’autore. L’art. 1 della legge 22 aprile 1941, n. 633 include espressamente i programmi per elaboratore tra le opere protette, qualificandoli come opere letterarie, in conformità alla disciplina europea oggi contenuta nella direttiva 2009/24/CE.

La protezione riguarda, in particolare, i diritti patrimoniali che consentono al titolare di autorizzare o vietare la riproduzione del programma, la sua modificazione, adattamento, trasformazione e distribuzione, secondo quanto previsto dall’art. 64-bis della legge sul diritto d’autore. Tali diritti, in quanto dotati di autonoma rilevanza economica, possono essere trasferiti alla società. L’art. 107 della medesima legge stabilisce infatti che i diritti di utilizzazione economica possono essere acquistati, alienati o trasmessi nelle forme consentite dalla legge, mentre l’art. 110 richiede che la loro trasmissione sia provata per iscritto.

La verifica preventiva della titolarità dei diritti

Prima di procedere al conferimento di software è necessario accertare con precisione chi sia titolare dei diritti di utilizzazione economica sul programma. Tale verifica assume particolare rilievo nelle start-up, nelle quali lo sviluppo tecnologico precede frequentemente la costituzione della società e può coinvolgere, oltre ai fondatori, programmatori, dipendenti, collaboratori o software house esterne.

Quando il programma è stato realizzato personalmente da uno dei fondatori, occorrerà anzitutto verificare che questi ne sia effettivamente l’autore e che non abbia precedentemente ceduto o vincolato i diritti di sfruttamento economico.

Qualora, invece, il software sia stato creato congiuntamente da più soggetti, la ricostruzione della titolarità diviene necessariamente più articolata: la direttiva 2009/24/CE prevede che, in caso di creazione congiunta da parte di più persone fisiche, i diritti esclusivi appartengano congiuntamente agli autori.

Una specifica disciplina riguarda il software realizzato nell’ambito di un rapporto di lavoro subordinato. Ai sensi dell’art. 12-bisdella legge n. 633/1941, salvo patto contrario, il datore di lavoro è titolare del diritto esclusivo di utilizzazione economica del programma creato dal lavoratore dipendente nell’esecuzione delle proprie mansioni o su istruzioni impartite dal datore di lavoro. La medesima regola trova corrispondenza nell’art. 2, par. 3, della direttiva 2009/24/CE.

Particolare attenzione deve essere riservata al software commissionato a professionisti o società esterne. In questi casi è indispensabile esaminare ilcontratto di sviluppoper stabilire quali diritti siano stati attribuiti al committente e con quale estensione. Il contratto dovrebbe chiarire espressamente se siano previste una cessione dei diritti, una licenza e i relativi limiti di utilizzo. La stessa prassi contrattuale istituzionale evidenzia l’importanza di disciplinare separatamente consegna del codice sorgente e titolarità dei diritti sul software.

Conferimento di softwareab initio: la costituzione della società

Il conferimento di software può essere realizzato direttamente in sede di costituzione della società, quando uno dei soci attribuisce alla società i diritti patrimoniali sul programma ricevendo, in contropartita, la partecipazione sociale corrispondente al valore dell’apporto. In tale ipotesi il software entra sin dall’origine nel patrimonio della società e costituisce uno degli elementi sulla base dei quali viene determinato il capitale sociale e, ove previsto, l’eventuale soprapprezzo.

Con particolare riferimento alla società a responsabilità limitata, l’art. 2464 c.c. consente di conferire tutti gli elementi dell’attivo suscettibili di valutazione economica e stabilisce che le quote corrispondenti ai conferimenti di beni in natura devono essere integralmente liberate al momento della sottoscrizione. Il conferimento di software effettuatoab initiodeve pertanto essere eseguito contestualmente alla costituzione, attraverso l’effettiva attribuzione alla società dei diritti che ne costituiscono l’oggetto.

Sotto il profilo documentale, assume particolare importanza l’esatta individuazione del bene conferito. L’atto costitutivo deve indicare i conferimenti di ciascun socio e il valore attribuito ai beni conferiti in natura; nel caso del software sarà quindi opportuno identificare con sufficiente precisione il programma, la versione oggetto del conferimento e, soprattutto, l’estensione dei diritti patrimoniali trasferiti.

A seconda delle caratteristiche del progetto, potranno assumere rilievo anche il codice sorgente, la documentazione tecnica e gli ulteriori elementi necessari per consentire alla società di utilizzare, modificare e sviluppare autonomamente il programma.

Il conferimento richiede inoltre la relazione giurata prevista dall’art. 2465 c.c., redatta da un revisore legale o da una società di revisione legale iscritti nell’apposito registro. La relazione deve descrivere il bene conferito, indicare i criteri adottati per la sua valutazione e attestare che il valore riconosciuto al software sia almeno pari a quello attribuitogli ai fini della determinazione del capitale sociale e dell’eventuale soprapprezzo.

L’aspetto più critico riguarda indubbiamente la determinazione del valore economico da attribuire al programma e ai relativi diritti di utilizzazione. A differenza del conferimento in denaro, infatti, il conferimento di software, quale bene immateriale, impone di individuare criteri idonei a tradurre in termini economici un asset la cui consistenza non è immediatamente desumibile da un valore nominale o da un prezzo di mercato univoco.

Occorre considerare, in concreto, le caratteristiche del programma, il suo grado di sviluppo e di maturità, le funzionalità effettivamente implementate, la possibilità di sfruttamento economico, la capacità di generare ricavi e, ove già esistenti, i dati relativi all’utilizzo commerciale. Possono inoltre assumere rilievo la documentazione tecnica disponibile, l’architettura del software, la possibilità di aggiornamento ed evoluzione del prodotto e l’esistenza di diritti di terzi o di componenti soggette a specifiche licenze.

Per le società per azioni la disciplina è differente, poiché l’art. 2343 c.c. prevede, in via ordinaria, una relazione giurata redatta da un esperto designato dal Tribunale, ferme restando le specifiche procedure alternative contemplate dagli artt. 2343-tere seguenti.

Il trasferimento del software dopo la costituzione: cessione, licenza e altri titoli di disponibilità

Il software può entrare nella disponibilità giuridica della società anche in un momento successivo alla sua costituzione.

Una prima possibilità è rappresentata dalla cessione dei diritti patrimoniali sul software. Ai sensi dell’art. 107 della legge n. 633/1941, i diritti di utilizzazione economica possono essere acquistati, alienati o trasmessi secondo le forme consentite dalla legge; l’art. 110 richiede inoltre che la loro trasmissione sia provata per iscritto. La cessione consente quindi di trasferire alla società, nei limiti previsti dall’accordo, la titolarità dei diritti di sfruttamento economico del programma.

Diversa dakl conferimento di software è lalicenza, mediante la quale il titolare conserva la proprietà dei diritti sul software ma attribuisce alla società la facoltà di utilizzarlo secondo le condizioni pattuite. Il contratto dovrà quindi definire con precisione durata, ambito territoriale, eventuale esclusiva, facoltà di modifica, riproduzione, distribuzione o sublicenza e, più in generale, le modalità di sfruttamento consentite. Per una start-up il ricorso alla licenza può risultare sufficiente sotto il profilo operativo, ma non equivale all’acquisizione della titolarità dell’asset.

Il trasferimento successivo può inoltre essere realizzato mediante un vero e proprio conferimento di software nell’ambito di un aumento di capitale. In tal caso il titolare dei diritti apporta il software alla società ricevendo in contropartita nuove partecipazioni e trovano applicazione le regole previste per i conferimenti in natura, compresi gli obblighi di valutazione già esaminati.

Quando il programma sia registrato presso il Pubblico Registro Software tenuto dalla SIAE, possono essere trascritti anche gli atti che trasferiscono, integralmente o parzialmente, i relativi diritti di utilizzazione economica.

La scelta tra cessione, licenza e conferimento di software deve pertanto essere effettuata in funzione dell’assetto che i soci intendono attribuire alla proprietà intellettuale della start-up.

Start-up innovativa e software: la titolarità della privativa quale requisito per l’iscrizione nella sezione speciale

Il conferimento di software può assumere una rilevanza ulteriore quando la società intenda acquisire la qualifica di start-up innovativa. L’art. 25 del D.L. 18 ottobre 2012, n. 179richiede, infatti, oltre ai requisiti generali previsti dalla norma, il possesso di almeno uno dei requisiti qualificanti relativi al contenuto innovativo dell’impresa. Tra questi rientra la titolarità, anche quale depositaria o licenziataria, di determinate privative industriali oppure, alternativamente, la titolarità dei diritti relativi a un programma per elaboratore originarioregistrato presso il Registro pubblico speciale per i programmi per elaboratore, purché direttamente afferente all’oggetto sociale e all’attività d’impresa.

Mentre per le privative industriali la legge contempla espressamente anche la posizione del depositario e del licenziatario, con riferimento al software richiede la titolarità dei relativi diritti. Secondo l’interpretazione fornita dal Ministero e richiamata dalla prassi camerale, tale nozione comprende non soltanto l’autore del programma, ma anche la persona fisica o giuridica alla quale siano stati validamente trasferiti i diritti esclusivi di sfruttamento economico. Ne consegue che il conferimento di software, o una precedente cessione dei relativi diritti patrimoniali, può assumere un ruolo determinante qualora la società intenda utilizzare proprio questo requisito per ottenere la qualifica di start-up innovativa.

Sul piano pratico, non è sufficiente che la società utilizzi il programma nell’esercizio della propria attività. Il software deve essere registrato presso ilPubblico Registro Softwaretenuto dalla SIAE, nel quale possono essere iscritti i programmi già pubblicati dotati dei requisiti di originalità e creatività. All’esito della procedura viene rilasciata un’attestazione recante, tra l’altro, la data e il numero progressivo della registrazione. Qualora i diritti siano stati successivamente trasferiti, il Registro consente inoltre la trascrizione degli atti relativi alla loro cessione.

In sede di iscrizione nella sezione speciale del Registro delle imprese, il possesso del requisito è attestato mediante dichiarazione del legale rappresentante. La modulistica ufficiale aggiornata nel 2026 identifica il requisito relativo alla proprietà industriale e al software con il codice 068; la prassi delle Camere di commercio richiede inoltre che la domanda sia corredata dalla dichiarazione di possesso dei requisiti e, con riferimento al software registrato, alcune Camere indicano espressamente l’allegazione dell’attestato di registrazione rilasciato dalla SIAE.

Assistenza legale in materia di diritto dell’innovazione.Start-up e digital business.

Il conferimento di software è una scelta destinata a incidere sulla struttura patrimoniale e sull’assetto giuridico della start-up.

Una corretta pianificazione della proprietà intellettuale postula una verifica preventiva sulla provenienza del codice, i rapporti con sviluppatori e collaboratori, l’eventuale presenza di componenti di terzi e la documentazione necessaria a ricostruire la titolarità dei diritti.

Il nostro Studio Legale presta assistenza in materia di diritto d’impresa e diritto dell’innovazione, affiancando start-up e imprese tecnologiche nella fase di costituzione, nella regolamentazione dei rapporti tra soci e nella predisposizione degli strumenti contrattuali necessari alla tutela e al trasferimento degli asset digitali (conferimento di software, cessione di programma informatico e contratti di licenza).

Contattaci per un confronto.

Ai sensi dell’art. 70-quater della Legge 633/1941, ai fini della tutela del diritto d’autore, si dichiara che il presente contenuto è riservato, e ne è vietata la riproduzione o l’estrazione di testo, anche mediante sistemi di intelligenza artificiale.

 

 

 

Contratto di servizi: quale disciplina si applica e quando è possibile il recesso

Contratto di servizi: quale disciplina si applica e quando è possibile il recesso

L’espressione “contratto di servizi” è frequentemente utilizzata nella prassi commerciale per indicare accordi aventi ad oggetto lo svolgimento, in favore di un cliente, di una o più attività organizzate. Si tratta, tuttavia, di una denominazione assai ampia, che non identifica necessariamente un autonomo tipo contrattuale dotato di una disciplina unitaria nel codice civile. Sotto la medesima espressione possono infatti ricadere rapporti profondamente differenti per struttura, contenuto e funzione economica.

La disciplina applicabile a un contratto di servizi non può essere individuata soltanto leggendo il titolo attribuito dalle parti al documento. Occorre verificare quali prestazioni siano effettivamente dedotte in contratto, quale interesse economico il rapporto sia destinato a soddisfare e, soprattutto, se l’accordo possa essere ricondotto integralmente o prevalentemente a uno dei tipi disciplinati dal codice civile.

La questione assume particolare rilevanza nella vita concreta del rapporto. Dalla qualificazione giuridica del contratto di servizi possono dipendere, infatti, il regime della responsabilità, le modalità di determinazione del corrispettivo, la disciplina dell’inadempimento, la durata del rapporto e, soprattutto, la possibilità di sciogliersi anticipatamente dal vincolo.

L’obiettivo di questo articolo è quindi esaminare i principali criteri attraverso i quali deve essere qualificato un contratto di servizi, distinguendo tra contratti tipici, atipici e a causa mista, per comprendere quali norme trovino applicazione e, in particolare, in quali ipotesi possa operare il recesso del committente previsto dall’art. 1671 c.c.

La qualificazione giuridica del contratto di servizi

Per individuare la disciplina applicabile a un contratto di servizi non è sufficiente fare riferimento alla denominazione utilizzata dalle parti. Espressioni qualiservice agreement, contratto di assistenza, contratto di gestione, contratto di consulenza o, più genericamente, “contratto di servizi” descrivono l’operazione economica soltanto in termini generali, ma non ne determinano necessariamente la qualificazione giuridica.

Sul piano civilistico occorre distinguere, infatti, l’attività di interpretazione del contratto da quella successiva di qualificazione. Mediante l’interpretazione, condotta secondo i criteri degli artt. 1362 e ss. c.c., si ricostruisce la comune intenzione delle parti e si individuano gli effetti che esse hanno concretamente inteso perseguire. Solo successivamente il rapporto così ricostruito viene qualificato, verificando se esso sia riconducibile a uno dei tipi contrattuali disciplinati dalla legge oppure debba essere considerato atipico o misto. La Corte di cassazione ha più volte ribadito questa distinzione, precisando che la qualificazione consiste proprio nell’attribuzione del correttonomen iurisall’assetto di interessi risultante dall’accordo.

Ne deriva che ilnomen iurisscelto dai contraenti rappresenta certamente un elemento da considerare, ma non assume carattere decisivo. Ai fini della qualificazione rilevano soprattutto il contenuto effettivo delle obbligazioni, le modalità di esecuzione del rapporto e la funzione economico-giuridica concretamente perseguita. La giurisprudenza di legittimità valorizza, in questa prospettiva, la causa concreta, intesa come interesse che lo specifico accordo è diretto a realizzare, da ricostruire attraverso una lettura complessiva e funzionale del contratto.

Contratto di servizi atipico e contratto a causa mista

La difficoltà di ricondurre il contratto di servizi a un unico schema legale deriva anche dall’ampiezza riconosciuta dall’ordinamento all’autonomia negoziale. L’art. 1322 c.c. consente infatti alle parti non soltanto di determinare liberamente il contenuto dei contratti tipici, nei limiti imposti dalla legge, ma anche di concludere contratti che non appartengono ai tipi espressamente disciplinati, purché siano diretti a realizzare interessi meritevoli di tutela. Il contratto di servizi può quindi presentarsi come contratto atipico oppure come contratto misto, nel quale confluiscono elementi propri di più figure negoziali.

Nelcontratto atipicole parti costruiscono un regolamento di interessi che non trova una corrispondenza completa in uno specifico tipo legale. Nelcontratto misto, invece, all’interno di un’unica operazione economica vengono combinati elementi riconducibili a differenti contratti tipici. La giurisprudenza di legittimità individua normalmente la disciplina del contratto misto attraverso ilcriterio dell’assorbimento o della prevalenza: trovano applicazione, in primo luogo, le norme del tipo contrattuale cui appartengono gli elementi prevalenti, senza tuttavia escludere la rilevanza delle disposizioni proprie delle componenti secondarie, purché compatibili con la disciplina del contratto prevalente.

Un esempio significativo è rappresentato dai contratti di service per spazi ad uso ufficio o di coworking. In tali rapporti la disponibilità di un locale può accompagnarsi alla fornitura di arredi, reception, connessione internet, pulizia, manutenzione, gestione della corrispondenza, sale riunioni e ulteriori servizi organizzativi. L’interesse del cliente può pertanto non esaurirsi nel semplice godimento di un immobile, tipico della locazione, ma consistere nell’ottenimento di uno spazio di lavoro immediatamente operativo e corredato da un complesso coordinato di prestazioni.

Proprio con riferimento a una fattispecie di questo genere, la giurisprudenza di merito ha recentemente qualificato un contratto diserviceavente ad oggetto un ufficio “chiavi in mano” come contratto a causa mista, caratterizzato da elementi della locazione e dell’appalto di servizi, valorizzando l’insieme delle prestazioni necessarie a rendere lo spazio efficiente e utilizzabile.

Considerazioni analoghe possono riguardare uncontratto di servizi informaticiche comprenda assistenza, manutenzione e licenza software, oppure un accordo di gestione immobiliare che cumuli attività materiali, amministrative e negoziali. Oppure ilcontratto di sponsorizzazioneo promozione di determinati beni o servizi.

A quali contratti tipici può essere ricondotto un contratto di servizi?

La corretta qualificazione del contratto di servizi richiede di verificare, caso per caso, quale sia la prestazione caratterizzante e quale funzione economica il rapporto sia destinato a realizzare. Il codice civile contempla, infatti, diverse figure contrattuali che possono avere ad oggetto lo svolgimento di un’attività o la fornitura di un servizio, ma ciascuna di esse presenta presupposti e disciplina differenti.

La figura più rilevante è quella dell’appalto, definito dall’art. 1655 c.c. come il contratto con il quale una parte assume, con organizzazione dei mezzi necessari e gestione a proprio rischio, il compimento di un’opera o di un servizio verso un corrispettivo. L’elemento distintivo è quindi rappresentato dall’organizzazione imprenditoriale dell’attività e dall’assunzione del rischio da parte dell’appaltatore.

Diversa è laprestazione d’operadisciplinata dall’art. 2222 c.c., che ricorre quando una persona si obbliga a compiere un’opera o un servizio con lavoro prevalentemente proprio e senza vincolo di subordinazione. In questo caso assume particolare rilievo l’attività personale del prestatore, mentre nell’appalto prevale l’organizzazione dei mezzi necessari all’esecuzione del servizio. Quando la prestazione abbia natura propriamente intellettuale, vengono invece in rilievo gli artt. 2229 e ss. c.c. e, in particolare, l’art. 2230 c.c.

Un contratto di servizi può altresì presentare elementi delmandato, qualora l’attività principale consista nel compimento di uno o più atti giuridici per conto del cliente, secondo la definizione contenuta nell’art. 1703 c.c. Se, invece, la prestazione centrale consiste nel consentire il godimento di un bene per un determinato periodo, può assumere rilievo la disciplina della locazione di cui all’art. 1571 c.c.

Particolare attenzione meritano infine i servizi eseguiti in maniera continuativa o periodica. Lasomministrazione, ai sensi dell’art. 1559 c.c., riguarda propriamente prestazioni periodiche o continuative di cose; tuttavia, quando l’appalto ha ad oggetto prestazioni continuative o periodiche di servizi, l’art. 1677 c.c. dispone l’applicazione, in quanto compatibili, tanto delle norme sull’appalto quanto di quelle sulla somministrazione.

Occorre esaminare la prestazione concretamente dedotta in contratto, il ruolo dell’organizzazione imprenditoriale, l’eventuale carattere personale dell’attività, la presenza di atti giuridici da compiere per conto del cliente e, più in generale, l’interesse economico prevalente perseguito dalle parti.

Contratto di servizi: norme suppletive e norme imperative

Una volta individuata la corretta qualificazione del contratto di servizi, occorre stabilire in quale rapporto si pongano le clausole concordate dalle parti e la disciplina prevista dalla legge.

Le norme civilistiche possono infatti avere carattere dispositivo oppure imperativo. Le prime operano, di regola, quando le parti non abbiano regolato diversamente una determinata questione e possono essere derogate mediante una specifica previsione contrattuale. In questa prospettiva assume particolare rilievo l’art. 1374 c.c., secondo cui il contratto obbliga le parti non soltanto a quanto espressamente previsto, ma anche alle conseguenze che ne derivano secondo la legge e, in mancanza, secondo gli usi e l’equità.

La qualificazione giuridica del rapporto svolge quindi una funzione essenziale proprio sul piano dell’integrazione del contratto. Se, ad esempio, un contratto di servizi viene ricondotto alla disciplina dell’appalto, le disposizioni codicistiche proprie di tale figura possono trovare applicazione per tutti gli aspetti non diversamente regolati dalle parti, nei limiti in cui si tratti di norme derogabili.

Diverso è il rapporto con le norme imperative. L’autonomia contrattuale incontra infatti il limite delle disposizioni inderogabili poste dall’ordinamento: l’art. 1418 c.c. stabilisce, in via generale, la nullità del contratto contrario a norme imperative, salvo che la legge disponga diversamente. In determinati casi, inoltre, la legge può intervenire direttamente sul contenuto negoziale, sostituendo le clausole difformi mediante il meccanismo previsto dall’art. 1339 c.c.

Durata del contratto: disdetta, recesso e risoluzione

Nel contratto di servizi – come in qualsiasi altro contratto – occorre distinguere tra scadenza, disdetta, recesso e risoluzione, poiché si tratta di istituti differenti, che producono effetti diversi e trovano fondamento in presupposti non coincidenti.

La scadenza determina la cessazione naturale di un contratto a tempo determinato al termine pattuito. La disdetta, invece, opera normalmente nei rapporti destinati a rinnovarsi automaticamente e consiste nella dichiarazione con cui una parte impedisce il rinnovo per un ulteriore periodo.

Diverso è il recesso, ossia il potere riconosciuto a una parte di sciogliere unilateralmente il rapporto prima della sua naturale cessazione, quando tale facoltà sia prevista dal contratto o dalla legge. L’art. 1373 c.c. contiene la disciplina generale del recesso unilaterale, ferma restando l’applicazione delle disposizioni speciali previste per singoli tipi contrattuali.

La disposizione prevede che:«Se a una delle parti è attribuita la facoltà di recedere dal contratto, tale facoltà può essere esercitata finché il contratto non abbia avuto un principio di esecuzione. Nei contratti a esecuzione continuata o periodica, tale facoltà può essere esercitata anche successivamente, ma il recesso non ha effetto per le prestazioni già eseguite o in corso di esecuzione. Qualora sia stata stipulata la prestazione di un corrispettivo per il recesso, questo ha effetto quando la prestazione è eseguita. È salvo in ogni caso il patto contrario».

Ancora differente è la risoluzione per inadempimento, disciplinata dagli artt. 1453 e ss. c.c. Essa presuppone, nei contratti a prestazioni corrispettive, l’inadempimento di una delle parti e, ai sensi dell’art. 1455 c.c., richiede che tale inadempimento non sia di scarsa importanza avuto riguardo all’interesse dell’altra parte. Il codice civile contempla inoltre ulteriori cause di risoluzione, quali l’impossibilità sopravvenuta e l’eccessiva onerosità sopravvenuta.

La distinzione assume particolare rilievo anche nell’accordo qui in esame, il contratto di servizi. Una clausola che stabilisca, ad esempio, una durata annuale con rinnovo automatico e preveda un termine entro il quale comunicare la disdetta disciplina anzitutto la durata e il rinnovo del rapporto. Essa non comporta necessariamente, per ciò solo, l’esclusione di un diverso diritto di recesso riconosciuto dalla disciplina legale applicabile.

Il recesso dal contratto di servizi qualificabile come appalto: l’art. 1671 c.c.

Quando il contratto di servizi sia qualificabile come appalto, assume particolare rilievo l’art. 1671 c.c., secondo cui il committente può recedere dal contratto anche dopo l’inizio dell’esecuzione dell’opera o della prestazione del servizio, purché tenga indenne l’appaltatore delle spese sostenute, dei lavori eseguiti e del mancato guadagno.

Si tratta di un diritto potestativo di recesso che, secondo la giurisprudenza, può essere esercitatoad nutum, senza necessità di dimostrare una giusta causa o un inadempimento dell’appaltatore.

Laratiodella disposizione risiede nel fatto che l’opera o il servizio sono destinati a soddisfare l’interesse del committente: quando tale interesse viene meno, l’ordinamento non impone necessariamente la prosecuzione del rapporto, ma tutela l’appaltatore sul piano economico mediante l’indennizzo previsto dalla legge. Il recessoexart. 1671 c.c. si distingue pertanto dalla risoluzione per inadempimento, poiché non richiede l’accertamento della gravità della condotta dell’altra parte. Anche un contratto di servizi correttamente eseguito può, in linea di principio, essere sciolto mediante tale facoltà, quando ne ricorrano i presupposti.

Il recesso non è del tutto privo di conseguenze economiche. Il committente deve ristorare l’appaltatore per le spese già sostenute, per le prestazioni eseguite e per il mancato guadagno relativo alla parte di rapporto non eseguita. Quest’ultima voce non coincide necessariamente con l’intero ammontare dei corrispettivi che sarebbero maturati sino alla scadenza: ciò che rileva è il guadagno effettivamente perduto, tenendo conto dei costi non più sostenuti e delle concrete conseguenze economiche determinate dalla cessazione anticipata.

Contratto di servizi e recesso nella giurisprudenza più recente

La giurisprudenza più recente conferma quanto sia decisiva, nella disciplina del contratto di servizi, la corretta qualificazione del rapporto. In particolare, la Corte di cassazione ha chiarito che, quando un contratto di servizi presenti i caratteri dell’appalto, la previsione di una durata determinata e di un meccanismo di rinnovo automatico non esclude, di per sé, l’applicazione dell’art. 1671 c.c.

Con l’ordinanza n. 15335 del 31 maggio 2024, la Suprema Corte ha affermato che l’accordo relativo alla durata e alla rinnovazione del rapporto non costituisce automaticamente una deroga al diritto di recesso del committente. Il rinnovo automatico opera, infatti, sul diverso piano della durata del contratto, mentre resta distinta la facoltà del committente di recedere anche durante l’esecuzione, con il correlato obbligo di indennizzare l’appaltatore secondo quanto previsto dall’art. 1671 c.c.

Il principio è stato ulteriormente precisato dalla Cassazione nel 2025. Con l’ordinanza n. 6487 dell’11 marzo 2025, la Corte ha distinto il regime applicabile ai contratti di servizi continuativi o periodici a seconda della loro durata: se il rapporto è a tempo determinato, trova applicazione l’art. 1671 c.c.; se, invece, la durata non è stabilita né determinabile, viene in rilievo l’art. 1569 c.c., che consente il recesso dal rapporto di somministrazione a tempo indeterminato mediante congruo preavviso.

La giurisprudenza di merito offre indicazioni altrettanto significative sul problema della qualificazione. Il Tribunale di Santa Maria Capua Vetere, con sentenza n. 809 del 10 marzo 2025, ha esaminato un contratto diservicerelativo a uno spazio ad uso ufficio, valorizzando non soltanto la concessione in godimento del locale, ma anche il complesso delle prestazioni di equipaggiamento, cura e manutenzione. Il rapporto è stato ricondotto a un contratto a causa mista, con elementi della locazione e dell’appalto di servizi.

Assistenza legale nella contrattualistica d’impresa

Il nostro Studio Legale presta assistenza in materia didiritto d’impresae contrattualistica civile e commerciale, occupandosi della predisposizione, revisione e interpretazione dei contratti, e scioglimento dei relativi rapporti negoziali.

Contattaci per un confronto.

 

Ai sensi dell’art. 70-quater della Legge 633/1941, ai fini della tutela del diritto d’autore, si dichiara che il presente contenuto è riservato, e ne è vietata la riproduzione o l’estrazione di testo, anche mediante sistemi di intelligenza artificiale.

 

 

 

Studio di fattibilità legale nei progetti digitali: perché rivolgersi a un avvocato?

Studio di fattibilità legale nei progetti digitali: perché rivolgersi a un avvocato?

Lo studio di fattibilità consiste nell’attività di analisi preventiva finalizzata a individuare il quadro normativo applicabile a un progetto e a verificare la compatibilità delle soluzioni ipotizzate con le vigenti disposizioni di legge.

Invero, la realizzazione di un progetto digitale richiede, normalmente, una pluralità di valutazioni preliminari che non si esauriscono nell’analisi della sostenibilità economica o della fattibilità tecnica. Un software, una piattaforma online, un’applicazione mobile o un prodotto fondato sull’impiego di sistemi di intelligenza artificiale possono risultare tecnicamente realizzabili e commercialmente sostenibili, ma essere al contempo soggetti a vincoli normativi idonei a incidere in misura significativa sulla struttura del progetto.

In altre parole, lo studio di fattibilità consente di verificare, in un momento in cui l’architettura del progetto è ancora suscettibile di modifiche, la conformità normativa della soluzione imprenditoriale, evitando che emergano problematiche giuridiche dopo lo sviluppo del prodotto o l’avvio dell’attività.

L’obiettivo del presente articolo è esaminare la funzione dello studio di fattibilità legale, illustrando i principali ambiti nei quali una valutazione giuridica preventiva può incidere sulle scelte progettuali e chiarendo per quali ragioni l’analisi della conformità normativa dovrebbe accompagnare, sin dalle fasi iniziali, la progettazione e lo sviluppo di un nuovo prodotto o servizio digitale.

Cos’è uno studio di fattibilità legale e quale funzione svolge

Lo studio di fattibilità legale può essere definito come un’attività di analisi preventiva diretta a verificare se un determinato progetto, nella configurazione concretamente ipotizzata, sia compatibile con il quadro normativo applicabile e a individuare gli eventuali adempimenti, limiti o condizioni necessari per la sualegittima realizzazione.

Esso si distingue, pertanto, sia dallo studio di fattibilità tecnica, che riguarda la concreta possibilità di sviluppare e implementare una determinata soluzione, sia dalla valutazione economico-finanziaria, normalmente volta ad accertarne la sostenibilità e le prospettive di mercato.

L’analisi giuridica dovrebbe precedere la redazione di contratti, informative, condizioni generali o altri documenti dicompliance,poiché richiede anzitutto di qualificare correttamente l’attività che si intende svolgere. È dalla qualificazione giuridica del prodotto o del servizio che discende l’individuazione delle norme applicabili e, conseguentemente, degli obblighi che devono essere osservati.

Tale passaggio assume particolare rilevanza nei progetti digitali, nei quali funzionalità apparentemente simili possono determinare conseguenze giuridiche profondamente differenti. Un software destinato esclusivamente alla gestione amministrativa di uno studio professionale, ad esempio, pone questioni diverse rispetto a un’applicazione che elabora informazioni sanitarie per fornire indicazioni funzionali a una decisione clinica.

Allo stesso modo, una piattaforma che si limita a pubblicare contenuti propri non è necessariamente soggetta alle medesime regole di un servizio che consente l’interazione o l’intermediazione tra utenti.

Studio di fattibilità: qualificazione giuridica del progetto e mappatura dei rischi

Una volta ricostruite le caratteristiche essenziali del progetto, lo studio di fattibilità deve procedere all’individuazione degli aspetti suscettibili di incidere sulla sua realizzazione. Tale attività presuppone una conoscenza sufficientemente dettagliata non soltanto del prodotto o del servizio che si intende offrire, ma anche delle modalità concrete attraverso le quali esso sarà sviluppato, distribuito e utilizzato.

L’analisi deve pertanto considerare l’eventuale ricorso a fornitori tecnologici esterni, l’impiego di infrastrutturecloud, software, API o modelli sviluppati da terzi, le categorie di utenti cui il servizio è destinato e i territori nei quali esso sarà commercializzato.

Lo studio di fattibilità fa una sorta di mappatura dei rischi normativi del progetto. Alcune criticità possono riguardare la necessità di ottenere autorizzazioni o rispettare requisiti di accesso al mercato; altre possono interessare il trattamento dei dati personali, la tutela dei consumatori, la disciplina della proprietà intellettuale, l’utilizzo di tecnologie di terzi, la sicurezza informatica o la ripartizione delle responsabilità contrattuali.

Lo studio di fattibilità nei settori regolamentati

Lo studio di fattibilità assume particolare rilievo quando il progetto digitale si inserisce in un settore regolamentato, nel quale la disciplina applicabile può subordinare l’esercizio dell’attività, la commercializzazione di un prodotto o l’erogazione di un servizio al rispetto di specifici requisiti sostanziali, organizzativi o autorizzativi.

Un esempio particolarmente significativo è rappresentato daisoftware impiegati in ambito sanitario. Non qualsiasi applicazione che abbia attinenza con la salute costituisce, per ciò solo, un dispositivo medico. Occorre invece esaminarne la destinazione d’uso e le specifiche funzioni svolte, verificando se ricorrano i presupposti previsti dal Regolamento (UE) 2017/745 e, in caso positivo, quale classificazione debba essere attribuita al software.

Considerazioni analoghe valgono per altri mercati sottoposti a discipline speciali. Un progettofintech, ad esempio, deve essere analizzato tenendo conto delle concrete attività svolte, distinguendo il mero sviluppo di una soluzione tecnologica dall’eventuale prestazione di servizi finanziari o di pagamento soggetti a specifiche regole.

Una piattaforma digitale che consenta l’intermediazione, la pubblicazione o la diffusione di contenuti di terzi può, invece, richiedere la verifica della disciplina prevista dal Digital Services Act e degli obblighi che essa ricollega alle diverse categorie di intermediari e piattaforme online.

In simili ipotesi, lo studio di fattibilità consente di accertare preventivamente se il modello progettato possa essere realizzato nella forma originariamente prevista e di individuare, prima dell’accesso al mercato, gli eventuali requisiti regolatori che devono essere incorporati nello sviluppo del prodotto o nell’organizzazione dell’attività.

Conformità al GDPR: la protezione dei dati personali fin dalla progettazione

Lo studio di fattibilità deve necessariamente comprendere una valutazione preliminare delle modalità con cui saranno trattati idati personali degli utenti, dei clienti o di altri soggetti interessati.

Questa impostazione trova un preciso fondamento nell’art. 25 del Regolamento (UE) 2016/679, che consacra i principi della protezione dei dati fin dalla progettazione e per impostazione predefinita. Le Linee guida 4/2019 dell’European Data Protection Board chiariscono, in particolare, che le misure dirette ad attuare efficacemente i principi di protezione dei dati devono essere considerate già al momento della determinazione dei mezzi del trattamento e, dunque, nella fase in cui vengono compiute le principali scelte progettuali.

Nell’ambito dello studio di fattibilità, occorrerà quindi ricostruire quali categorie di dati saranno trattate, per quali finalità e sulla base di quale presupposto di liceità, verificando altresì i tempi di conservazione, i soggetti che potranno accedervi, il ricorso a responsabili esterni, l’eventuale trasferimento dei dati verso Paesi terzi e l’adeguatezza delle misure tecniche e organizzative previste.

Particolare attenzione deve essere riservata ai progetti che comportino profilazione, monitoraggio sistematico degli utenti, trattamento su larga scala di categorie particolari di dati o comunque operazioni suscettibili di determinare un rischio elevato per i diritti e le libertà delle persone fisiche.

In tali ipotesi può rendersi necessaria una valutazione d’impatto sulla protezione dei dati ai sensi dell’art. 35 GDPR, da svolgersi prima dell’inizio del trattamento. IlGarante per la protezione dei dati personalievidenzia espressamente il carattere preventivo della DPIA e la sua funzione nell’ambito del principio di responsabilizzazione del titolare.

Studio di fattibilità e Intelligenza Artificiale

Quando il progetto prevede l’impiego di soluzioni basate sull’intelligenza artificiale, lo studio di fattibilità dovrebbe comprendere una specifica verifica della disciplina applicabile. La mera circostanza che un software utilizzi algoritmi, modelli di intelligenza artificiale o servizi forniti da terzi non è infatti sufficiente a determinare il relativo regime giuridico: occorre esaminare le caratteristiche del sistema, le finalità per le quali viene utilizzato, il contesto nel quale opera e il ruolo assunto dai diversi soggetti coinvolti.

Il principale riferimento normativo è oggi rappresentato dalRegolamento (UE) 2024/1689, c.d. AI Act, che disciplina lo sviluppo, l’immissione sul mercato, la messa in servizio e l’utilizzo dei sistemi di intelligenza artificiale secondo un modello fondato sulla graduazione del rischio. Il Regolamento trova applicazione, in via generale, dal 2 agosto 2026, sebbene alcune disposizioni siano divenute applicabili anticipatamente e altre siano assoggettate a specifici regimi transitori.

Nell’ambito dello studio di fattibilità, occorre pertanto verificare anzitutto se la soluzione rientri nella nozione normativa di sistema di IA e quale posizione assuma l’impresa rispetto ad essa, distinguendo, a seconda dei casi, tra fornitore,deployer, importatore o distributore.

Deve quindi essere accertata l’eventuale riconducibilità del sistema alle pratiche vietate, ai sistemi soggetti a particolari obblighi di trasparenza o alle categorie ad alto rischio. Dal 2 agosto 2026 trovano, ad esempio, applicazione gli obblighi di trasparenza previsti dall’art. 50 dell’AI Actper determinate forme di interazione con sistemi di IA e per taluni contenuti generati o manipolati artificialmente.

La verifica assume particolare rilievo anche quando l’impresa non sviluppi autonomamente il modello, ma integri nel proprio prodotto API, modelli o servizi di intelligenza artificiale forniti da soggetti terzi. Tale circostanza non esclude, di per sé, l’insorgenza di autonomi obblighi normativi in capo al soggetto che incorpora o utilizza la tecnologia all’interno del proprio servizio.

In Italia, il quadro europeo deve inoltre essere coordinato con la legge 23 settembre 2025, n. 132, le cui disposizioni sono espressamente destinate a operare conformemente all’AI Act.

Contratti, proprietà intellettuale e dipendenza dai fornitori tecnologici

Lo studio di fattibilità di un progetto digitale deve estendersi anche ai rapporti contrattuali e ai diritti di proprietà intellettuale sui quali si fonda l’architettura tecnologica del prodotto o del servizio. Nella pratica, infatti, anche progetti sviluppati internamente possono dipendere in misura significativa da componenti appartenenti a terzi, quali librerie software, API, infrastrutturecloud, database, modelli di intelligenza artificiale, piattaforme di pagamento o altri servizi tecnologici integrati.

La verifica assume rilievo, anzitutto, sotto il profilo della titolarità e delle condizioni di utilizzazione del software. Nell’ordinamento europeo, i programmi per elaboratore sono oggetto di una specifica tutela autorale ai sensi della Direttiva 2009/24/CE. Ne consegue che l’utilizzo, la modifica, la distribuzione o l’integrazione di componenti software e database devono essere valutati alla luce dei diritti effettivamente acquisiti e delle condizioni previste dalle relative licenze.

Lo studio di fattibilità deve pertanto accertare se l’impresa disponga dei diritti necessari sul codice sviluppato internamente o da collaboratori esterni e se le licenze relative alle componenti di terzi consentano l’impiego concretamente programmato. La medesima attenzione deve essere riservata al softwareopen source: l’assenza di un corrispettivo economico non implica, infatti, l’assenza di condizioni giuridiche di utilizzo, essendo ogni componente disciplinata dalla specifica licenza applicabile.

Ulteriori verifiche riguardano i contratti con i fornitori tecnologici, che possono disciplinare limiti di utilizzo delle API, disponibilità del servizio, responsabilità, trattamento dei dati, possibilità di recesso e continuità operativa. Uno studio di fattibilità adeguatamente svolto consente quindi di accertare se l’impresa possieda effettivamente i diritti e le autorizzazioni contrattuali necessari per sviluppare e commercializzare il progetto secondo il modello previsto.

Assistenza legale per start up e imprese digitali. Rivolgiti al nostro Studio Legale

Il parere di un avvocato consente di ricondurre le caratteristiche tecniche del prodotto o del servizio entro le corrette categorie giuridiche, coordinando discipline che, nei progetti digitali, tendono frequentemente a sovrapporsi.

Lo studio di fattibilità non sostituisce le successive attività di compliance, ma ne rappresenta il presupposto logico. Per le startup e, più in generale, per le imprese che sviluppano nuovi servizi o prodotti digitali, la valutazione legale presentiva è uno step assolutamente consigliabile.

Il nostroStudio Legalesupporta imprese e startup nell’avvio di progetti tecnologici in conformità alla normativa di legge.

Contattaci per un confronto.

 

Ai sensi dell’art. 70-quater della Legge 633/1941, ai fini della tutela del diritto d’autore, si dichiara che il presente contenuto è riservato, e ne è vietata la riproduzione o l’estrazione di testo, anche mediante sistemi di intelligenza artificiale.