Software sviluppato con l’AI: chi è proprietario del codice generato da ChatGPT o Claude?

Le piattaforme AI possono utilizzare il mio codice o la mia idea per addestrare i loro modelli?

Quando uno sviluppatore inserisce codice sorgente, documentazione tecnica, know-how o idee di prodotto in una piattaforma AI, la domanda diventa diversa: che uso può farne il fornitore del servizio?

In Europa esistono presidi normativi. Il GDPR si applica quando l’input contiene dati personali e impone, tra l’altro, liceità, trasparenza, limitazione delle finalità, minimizzazione e sicurezza del trattamento (artt. 5 e 6 GDPR). Il Data Act disciplina invece l’accesso e l’uso dei dati, anche non personali, nel mercato digitale europeo, ed è applicabile dal 12 settembre 2025 (Regolamento UE 2023/2854).

Poi ci sono i termini di servizio, che cambiano molto da piattaforma a piattaforma. OpenAI, ad esempio, dichiara che i contenuti degli utenti business, inclusi ChatGPT Business, ChatGPT Enterprise e API, non vengono usati di default per addestrare i modelli. Per gli utenti individuali, invece, l’uso dei contenuti per il miglioramento dei modelli dipende anche dalle impostazioni e dall’eventuale opt-out.

Anthropic adotta una distinzione simile: per i prodotti commerciali, come Claude for Work, Anthropic API e Claude Gov, dichiara che input e output non sono usati di default per il training. Per i prodotti consumer, invece, la disciplina è diversa e può includere l’uso delle conversazioni o delle sessioni di coding per migliorare i modelli, secondo le condizioni applicabili.

Google distingue a sua volta tra servizi consumer e ambienti business o cloud. Per Gemini in Google Workspace, Google dichiara che i contenuti non sono usati per addestrare modelli Gemini fuori dal dominio senza permesso; per Gemini Enterprise Agent Platform afferma che i dati non sono usati per addestrare o perfezionare modelli AI/ML senza previa autorizzazione o istruzione del cliente.

Il punto, però, resta pratico. Queste dichiarazioni sono importanti, ma non eliminano il problema: chi può verificare davvero, dall’esterno, come quei dati vengano trattati in ogni passaggio tecnico, organizzativo o infrastrutturale? In caso di codice strategico, know-how non pubblico, credenziali, architetture proprietarie o idee di prodotto non ancora protette, la regola più sicura resta la più semplice: non inserirli nel prompt.

Per un’impresa, quindi, l’uso dell’AI nello sviluppo software non dovrebbe dipendere dalla prudenza del singolo sviluppatore. Serve una regola interna chiara su quali strumenti usare, con quali account, per quali attività e con quali limiti. Perché il modo più efficace per proteggere un’informazione riservata è evitare che smetta di esserlo.

In prospettiva, l’AI Act dovrebbe rendere più chiaro il quadro, soprattutto sul piano degli obblighi di trasparenza e documentazione dei fornitori. Alcune scadenze, però, sono già arrivate e altre arriveranno nei prossimi mesi (approfondisci: AI Act rinviato: le imprese possono permettersi di aspettare? – Canella Camaiora). Resta il fatto che, per un’impresa, la tutela più solida non può dipendere solo da ciò che il provider dichiara nei propri termini di servizio. Se un’informazione è davvero strategica o riservata, il modo più sicuro per proteggerla resta non inserirla nella piattaforma.

Un altro utente può ricevere suggerimenti simili ai miei?

Sì, è possibile. I sistemi di AI generativa non lavorano come un consulente che riserva una soluzione a un solo cliente. Producono risposte sulla base di modelli probabilistici, istruzioni ricevute e dati disponibili. Per questo, due utenti che formulano richieste simili possono ricevere output simili, soprattutto quando chiedono soluzioni tecniche standard, porzioni di codice ricorrenti o architetture comuni.

Non a caso, molte piattaforme inseriscono nei propri termini di servizio un disclaimer su questo effetto collaterale dell’AI generativa: gli output possono non essere unici e utenti diversi possono ricevere risultati uguali o simili, anche senza alcun trasferimento diretto di contenuti tra un account e l’altro.

Questo non significa necessariamente che la piattaforma abbia “copiato” il lavoro di un utente per consegnarlo a un altro. Spesso significa solo che, davanti a problemi simili, il modello tende a proporre soluzioni simili. Nel software questo è particolarmente evidente: molte funzioni, strutture e pattern di sviluppo sono già diffusi, documentati e ripetuti.

Il punto, però, è importante per chi cerca un vantaggio competitivo. L’output generato dall’AI non è automaticamente esclusivo solo perché nasce da un prompt dell’utente. Se la richiesta è generica, anche il risultato tenderà a esserlo. La protezione diventa più solida solo quando interviene un contributo umano riconoscibile: scelte progettuali, integrazione nel prodotto, adattamento al contesto, revisione del codice e organizzazione complessiva del software.

Per un’impresa, quindi, l’AI può aiutare nello sviluppo, ma non dovrebbe essere trattata come il luogo in cui depositare la parte più riservata del progetto. Se un’idea, un’architettura o una soluzione tecnica devono restare davvero distintive, occorre gestirle fuori dalla piattaforma o inserirle solo dopo aver valutato bene termini di servizio, account utilizzato e livello di riservatezza richiesto. Altrimenti il rischio non è solo che qualcuno “copi” il risultato, ma che quel risultato non sia mai stato davvero esclusivo.

Si può registrare il risultato sviluppato con l’AI?

Sì. Il fatto che una soluzione sia stata sviluppata anche con l’aiuto dell’AI non impedisce, di per sé, di proteggerla o registrarla. Occorre però capire quale sia l’oggetto della tutela.

Se il risultato è un software, potrà venire in rilievo la tutela autorale e, nella prassi italiana, anche il deposito presso il Registro Pubblico Speciale per i programmi per elaboratore tenuto dalla SIAE (approfondisci: La registrazione del software in SIAE: tra tutela legale e pianificazione fiscale – Canella Camaiora).

Se invece la soluzione risolve un problema tecnico in modo nuovo e non ovvio, si può valutare la tutela brevettuale. Qui l’AI può aver aiutato nella ricerca o nello sviluppo, ma l’inventore deve essere una persona fisica e deve aver dato un contributo inventivo riconoscibile. La titolarità del brevetto potrà poi spettare all’azienda, al committente o ad altro soggetto, secondo contratti, rapporti di lavoro e regole applicabili (approfondisci: Invenzioni e Intelligenza Artificiale: come cambia la brevettazione).

In altri casi, ciò che merita protezione non è il codice in sé, ma l’aspetto esterno del prodotto, l’interfaccia, la forma di un dispositivo, il layout o l’esperienza visiva. In queste ipotesi può avere senso valutare una registrazione come disegno o modello, purché ricorrano i requisiti previsti.

Il punto, quindi, non è chiedersi in astratto se “si possa registrare qualcosa fatto con l’AI”. La domanda corretta è: quale parte del risultato voglio proteggere? Il codice, la soluzione tecnica, l’aspetto esterno, il nome, il logo, il database, il know-how? A seconda della risposta cambiano lo strumento di tutela, i requisiti e il soggetto che può procedere alla registrazione.

Per questo, quando l’AI entra nello sviluppo, conviene conservare traccia del percorso: specifiche, prompt rilevanti, revisioni, test, decisioni progettuali, contratti con collaboratori e licenze degli strumenti usati. Non per appesantire il lavoro, ma per poter dimostrare da dove arriva il risultato e a quale titolo può essere protetto, registrato o valorizzato.