1. Come accade solitamente
Nel software il problema nasce quasi sempre in modo banale: una demo, una call tecnica, un repository condiviso “solo per qualche giorno”, un pitch deck mandato a un potenziale partner, una prova di integrazione con un cliente enterprise. Poi, mesi dopo, compare una funzione molto simile in un prodotto altrui e tutti iniziano a cercare la famosa “versione di prima”.
Gli algoritmi proprietari raramente sono un singolo file magico chiamato algoritmo_finale_vero_definitivo.py, anche se molti progetti hanno almeno una cartella con quel tipo di nome, di solito creata alle 2:17 di notte. Più spesso sono un insieme di codice sorgente, configurazioni, pesi di modello, prompt, pipeline, documentazione tecnica, benchmark, notebook, dataset di test, log e scelte architetturali.
Nel mondo AI la situazione è ancora più scivolosa: il valore può stare in un metodo di ranking, in una strategia di fine-tuning, in un sistema di feature engineering, in una catena di prompt, in un modo particolare di valutare gli output o in una combinazione di passaggi che, presi singolarmente, sembrano innocui. È un po’ come il sugo della nonna: tutti vedono pomodoro e basilico, pochi sanno quando entra davvero il sale.
Un punto di vista insolito: anche il “fallimento” può essere prezioso. Test scartati, metriche peggiori, modelli non adottati e commit intermedi possono dimostrare un percorso di sviluppo coerente. In una contestazione, la storia tecnica conta quasi quanto il risultato finale.
2. Cosa devi dimostrare
Il punto non è dimostrare magicamente che “l’algoritmo è tuo”, ma costruire una documentazione credibile sull’esistenza di certe versioni, in certi momenti, con certi contenuti tecnici.
In pratica può essere utile dimostrare:
- l’esistenza di una specifica versione del codice sorgente;
- la presenza di una certa logica algoritmica in un documento tecnico;
- la versione di un modello, di una pipeline o di un prompt system;
- il contenuto di una demo inviata a terzi;
- la data di preparazione di benchmark, test e risultati;
- lo stato di un repository o di un pacchetto software;
- il contenuto di e-mail, chat o materiali condivisi con partner, clienti o collaboratori;
- la sequenza evolutiva tra prototipo, MVP e versione commerciale;
- le condizioni di accesso con cui l’algoritmo è stato mostrato o consegnato.
L’obiettivo è rendere più difficile la classica frase “questa idea era già nell’aria”. Certo, anche il tostapane intelligente era “nell’aria” prima che qualcuno lo collegasse davvero a un’app, ma nei conflitti professionali servono file, date, versioni e contesto.
3. Cosa raccogliere
Prepara un pacchetto documentale ordinato, leggibile anche da chi non vive dentro il tuo IDE.
Raccogli, quando disponibili:
- file sorgenti originali;
- repository esportato in ZIP, con struttura delle cartelle conservata;
- changelog e note di rilascio;
- documentazione tecnica in PDF;
- diagrammi dell’architettura;
- notebook, script di training, file di configurazione;
- prompt, policy interne e catene operative usate dal sistema AI;
- dataset di test o descrizione dei dataset, se condivisibili;
- risultati di benchmark e report di valutazione;
- screenshot del prodotto, della dashboard o della demo;
- video brevi che mostrano il funzionamento;
- e-mail e chat esportate relative a invii, demo, accordi o feedback;
- contratti, NDA, preventivi, proposte commerciali e materiali di pitch;
- log di sistema o report interni che mostrano esecuzioni e versioni;
- file README con spiegazione chiara di cosa contiene il pacchetto.
Una buona abitudine: crea un file “indice” che spiega cosa c’è nel pacchetto, perché è rilevante e a quale versione del progetto si riferisce. È meno glamour di un modello generativo, ma quando bisogna ricostruire i fatti vale oro.
4. Come procedere
Parti identificando le versioni che contano davvero. In genere sono: primo prototipo funzionante, versione mostrata a terzi, versione consegnata o integrata, versione prima di una negoziazione importante, versione prima di una possibile contestazione.
Crea una cartella pulita per ogni versione, usando nomi chiari e date coerenti, per esempio Algoritmo_Ranking_B2B_v0.9_2026-05-01. Inserisci dentro codice, documenti, screenshot, report e un breve README. Evita di mischiare appunti casuali, export incompleti e file duplicati senza spiegazione: il caos digitale è simpatico solo nei meme sui desktop pieni di icone.
Procedura pratica:
- individua le versioni chiave dell’algoritmo;
- esporta i file originali senza modificarli inutilmente;
- aggiungi un README descrittivo;
- crea un archivio ZIP per ogni versione rilevante;
- conserva anche i singoli file più importanti;
- documenta eventuali condivisioni con terzi tramite e-mail, chat o verbali;
- attesta i pacchetti e i documenti principali;
- archivia tutto in più copie sicure;
- registra in un foglio interno cosa è stato attestato e perché.
Quando aggiorni l’algoritmo in modo sostanziale, ripeti il processo. Una sola attestazione fatta all’inizio è utile, ma una sequenza ordinata di versioni racconta molto meglio l’evoluzione del progetto.
5. Errori da evitare
L’errore più frequente è aspettare il problema. Quando arriva la contestazione, i file sono stati rinominati, compressi, spostati su chat, risalvati da qualche tool e trasformati in una piccola palude di metadati incoerenti.
Altri errori comuni:
- attestare solo uno screenshot e dimenticare il codice;
- salvare solo il file finale senza contesto tecnico;
- modificare i file dopo averli attestati;
- usare nomi vaghi come final.zip, nuovo.zip, ultimo_buono2.zip;
- condividere codice o demo senza traccia scritta;
- ignorare contratti, NDA e regole di accesso;
- non separare ciò che è proprietario da ciò che deriva da librerie, framework o componenti open source;
- dimenticare dipendenze, configurazioni e parametri necessari a capire il funzionamento;
- conservare tutto in un solo computer o in un solo account cloud.
Oltre all’attestazione tecnica, valuta sempre misure organizzative: controllo degli accessi, permessi nei repository, accordi scritti, policy interne, tracciamento delle consegne, gestione dei collaboratori esterni e revisione delle licenze di terze parti. L’attestazione gratuita è utile perché permette di fissare subito una versione importante senza trasformare ogni passaggio tecnico in un mini-progetto amministrativo.
6. Dopo la documentazione
Dopo aver documentato l’algoritmo, integra questa pratica nel ciclo di sviluppo. Ogni rilascio importante dovrebbe avere una piccola “fotografia documentale”: cosa è cambiato, chi ci ha lavorato, quali file lo descrivono, dove sono conservati.
Coinvolgi le persone giuste in base al contesto: responsabili tecnici, management, consulenti IP, consulenti legali, advisor aziendali, partner contrattuali o assicurativi. Se l’algoritmo viene mostrato a investitori, clienti o fornitori, prepara prima una versione condivisibile e tieni separati i materiali riservati.
In caso di conflitto o sospetto uso improprio, raccogli con calma le prove già disponibili, evita modifiche impulsive ai file, conserva le comunicazioni e chiedi supporto professionale prima di inviare accuse o richieste formali. Nel software, come in cucina, la ricetta conta; ma quando qualcuno dice di aver inventato la stessa salsa, serve anche sapere chi aveva il barattolo in dispensa per primo.