Punti chiave

  • Quattro decisioni devono essere prese esplicitamente prima di redigere qualsiasi accordo: proprieta della PI, coinvolgimento azionario, ambito dell'esclusiva e condizioni di uscita.
  • La co-proprieta della PI sembra equa ma e quasi sempre la peggiore opzione nella pratica.
  • Le clausole di esclusiva sono l'errore strutturale piu comune negli accordi di co-sviluppo. L'ambito conta piu della durata.
  • Il modello di governance (chi decide cosa, con quale velocita, con quale autorita) e importante quanto i termini legali. La maggior parte degli accordi lo omette completamente.
  • In Europa, un co-sviluppo strutturato correttamente puo accedere ai finanziamenti di Horizon Europe, il che cambia fondamentalmente la struttura economica per entrambe le parti.

La decisione che viene prima dell'accordo

La maggior parte delle negoziazioni di co-sviluppo parte dal posto sbagliato. Entrambi i team legali aprono i loro documenti template e iniziano a scambiarsi bozze prima che le persone che faranno davvero il lavoro abbiano concordato le quattro domande che determinano se la relazione avra successo o fallira. Quando quelle domande emergono, le posizioni sono gia trincerate e la negoziazione e diventata avversariale.

Le quattro decisioni non sono dettagli legali. Sono decisioni di business che condizionano tutto il resto. Devono essere prese dai responsabili di business, in conversazione, prima che intervengano gli avvocati. Una volta concordate, la stesura legale e relativamente semplice. Senza accordo su di esse, nessun livello di precisione legale salvera la relazione.

Decisione 1: chi e proprietario della PI che viene creata?

Questa e la domanda che la maggior parte dei co-sviluppi lascia implicita e sulla quale verte la maggior parte dei conflitti. La corporate assume di essere proprietaria di tutto cio che e stato costruito con i suoi dati, la sua competenza di settore e il suo budget. La startup assume di trattenere la tecnologia core perche i suoi ingegneri l'hanno scritta e costituisce il fondamento del loro prodotto. Entrambe le assunzioni hanno una certa base legale e nessuna e completamente corretta. Il risultato e un problema che emerge nel momento peggiore possibile, di solito quando la relazione e gia sotto pressione.

Le opzioni praticabili, in ordine di frequenza con cui funzionano davvero:

  • La startup e proprietaria dell'output, la corporate ottiene una licenza definita. La startup trattiene la propria PI, inclusi i miglioramenti apportati durante il progetto. La corporate riceve una licenza che specifica cosa puo fare con l'output (uso interno, commercializzazione in mercati definiti, sublicenza a sussidiarie o meno). E la struttura piu favorevole ai fondatori e la piu semplice da gestire.
  • La corporate e proprietaria dell'output del progetto, la startup trattiene la tecnologia sottostante. Cio che la corporate possiede e la specifica configurazione, l'integrazione e qualsiasi funzionalita su misura costruita per essa. La startup trattiene la piattaforma, gli algoritmi, i metodi proprietari. Entrambe le parti ricevono una licenza su cio che possiede l'altra per gli scopi del progetto. E praticabile ma richiede una definizione molto precisa di cosa costituisce "tecnologia sottostante."
  • Un veicolo appositamente creato detiene la PI. Viene creata una nuova entita per detenere la PI sviluppata congiuntamente, in cui entrambe le parti detengono partecipazioni azionarie. E la struttura legalmente piu difendibile, la piu complessa da configurare, e di solito ha senso solo quando l'output del co-sviluppo e abbastanza significativo da diventare un'attivita autonoma.
  • Co-proprieta. Sembra equa. E quasi sempre la peggiore opzione nella pratica. I co-proprietari possono tipicamente usare la PI in modo indipendente, ma nessuno puo licenziarla a terzi o intentare causa per violazione senza il consenso dell'altro. Due aziende che prendono quelle decisioni insieme, con interessi commerciali potenzialmente divergenti, e una ricetta per la paralisi.

La domanda da porsi prima di scegliere una struttura: se questo co-sviluppo produce qualcosa di genuinamente prezioso, chi deve poterlo commercializzare, in quali mercati e con quale esclusiva? Lavora a ritroso da quella risposta. La struttura di proprieta della PI deriva dall'intenzione commerciale, non il contrario.

Decisione 2: c'e coinvolgimento azionario?

Alcuni co-sviluppi sono puramente contrattuali: la startup eroga un servizio o un prodotto, la corporate lo paga, la relazione e commerciale. Altri implicano che la corporate acquisisca una quota nella startup, o che entrambe le parti co-fondino una nuova entita. Questa decisione cambia l'intera natura della relazione e deve essere esplicita fin dalla prima conversazione.

Il coinvolgimento azionario non e automaticamente migliore per nessuna delle parti. Per la startup, puo segnalare impegno e consolidare un partner strategico. Puo anche introdurre un azionista con diritti di veto e incentivi diversi dal team fondatore. Per la corporate, il capitale fornisce un upside se la startup ha successo. Crea anche obblighi, potenziali conflitti di interesse e complessita di governance che la maggior parte dei team legali e finanziari aziendali non sono attrezzati a gestire in modo efficiente.

Se il capitale fa parte della conversazione, la valutazione, lo strumento (accordo semplice per equity futuro, nota convertibile, acquisto diretto di azioni) e i diritti di governance che ne derivano devono essere risolti prima di redigere l'accordo di co-sviluppo. Sono troppo determinanti per essere trattati come un allegato.

Decisione 3: qual e l'ambito dell'esclusiva?

Le corporate chiedono quasi sempre l'esclusiva. La richiesta e legittima: stanno investendo budget, aprendo accessi interni e assumendosi un rischio reputazionale su un'azienda in fase iniziale. Vogliono sapere che un concorrente non otterr a lo stesso vantaggio sei mesi dopo.

Il problema e che "esclusiva" puo significare cose molto diverse, e la versione che protegge il legittimo interesse della corporate non e quasi mai quella che viene chiesta per prima. L'esclusiva totale in un settore verticale, "non puoi lavorare con nessun'altra azienda di servizi finanziari", puo bloccare una startup B2B dall'intero mercato target. La startup firma perche ha bisogno dell'accordo. Scopre il vincolo quando cerca di chiudere il prossimo cliente e non puo.

Questa sezione dell'accordo deve specificare con precisione quattro dimensioni dell'esclusiva: cosa e esclusivo (l'output, la tecnologia, un'applicazione di mercato), dove si applica (ambito geografico), per quanto tempo, e cosa fa scadere anticipatamente l'esclusiva (traguardi di fatturato, obiettivi di deployment, o semplicemente il trascorrere del tempo).

Decisione 4: quali sono le condizioni di uscita?

Le condizioni di uscita sono importanti quanto quelle di ingresso e ricevono una frazione dell'attenzione. Ogni co-sviluppo finisce in uno di quattro modi: ha successo e entrambe le parti continuano; ha successo e la corporate acquisisce la startup; una parte si ritira prima del completamento; o il progetto semplicemente esaurisce lo slancio e muore silenziosamente. L'accordo deve disciplinare esplicitamente tutti e quattro gli esiti.

Le domande che necessitano risposta: cosa succede alla PI sviluppata congiuntamente se la corporate rescinde anticipatamente? La startup puo tenere cio che e stato costruito sulla propria tecnologia? Cosa succede se la startup viene acquisita da un concorrente della corporate durante il progetto? Quali sono gli obblighi di pagamento se una parte esce prima che vengano raggiunti i traguardi? C'e un diritto di prelazione sull'acquisizione?

Questi non sono casi limite. Nella mia esperienza attraverso decine di collaborazioni corporate-startup, le relazioni che finiscono male lo fanno quasi sempre esattamente in uno di questi punti di transizione, in assenza di un quadro pre-concordato. Per approfondire i pattern che causano il fallimento delle collaborazioni corporate-startup, il framework pratico per la collaborazione corporate-startup copre le dinamiche strutturali in dettaglio.

Cosa deve davvero coprire l'accordo

Una volta risolte le quattro decisioni di business, puo iniziare la stesura legale. L'errore comune e usare un template standard di NDA piu accordo di servizi e adattarlo al contesto del co-sviluppo. Il co-sviluppo e un tipo di relazione distinto per cui i template standard non sono stati progettati.

Le clausole essenziali al di la della PI e dell'esclusiva:

Piano di lavoro e governance dei milestone. Non solo cosa verra consegnato, ma chi lo approva, in quale tempistica, con quale processo quando c'e disaccordo. Piu questa sezione e precisa, meno conflitti sorgono. I deliverable vaghi producono conversazioni vaghe su se siano stati raggiunti.

Condivisione e proprieta dei dati. Quando la corporate fornisce dati proprietari (registri clienti, dati operativi, intelligence di mercato) che la startup usa nello sviluppo o nel training di modelli, l'accordo deve specificare cosa puo fare la startup con quei dati, se possono essere usati per migliorare il prodotto generale della startup, se possono essere trattenuti dopo la fine del progetto, e cosa succede a eventuali insight o modelli derivati. E un territorio sempre piu regolamentato in Europa sotto il GDPR e l'AI Act dell'UE.

Diritti di pubblicazione. La startup potrebbe voler pubblicare risultati di ricerca, case study o articoli tecnici. La corporate quasi mai lo vuole, almeno non senza revisione. Una clausola sui diritti di pubblicazione che richieda l'approvazione corporate prima di qualsiasi divulgazione esterna, con un periodo di revisione definito e un meccanismo di approvazione tacita se non arriva risposta, bilancia entrambi gli interessi.

Diritti di sublicenza. La corporate puo dare l'output sviluppato congiuntamente alle sue sussidiarie? Ai suoi clienti? A integratori terzi? Questo conta enormemente per l'economia e la posizione competitiva della startup, ed e frequentemente lasciato ambiguo nelle prime bozze.

Cambio di controllo. Affrontato sopra come condizione di uscita, ma vale la pena specificarlo nell'accordo stesso: cosa costituisce un cambio di controllo, quali diritti attiva e per chi.

Struttura dei pagamenti. I pagamenti per milestone allineano meglio gli incentivi rispetto ai compensi basati sul tempo. La corporate paga quando vengono consegnati output definiti. La startup ha un obiettivo chiaro e oggettivo. Le dispute su se il lavoro sia stato fatto diventano molto piu rare quando la definizione di "fatto" e nel contratto e non nella casella di posta di qualcuno.

Governance operativa: la parte che la maggior parte degli accordi salta

Un accordo di co-sviluppo non e solo un documento legale. E un framework operativo per due organizzazioni che lavorano diversamente per collaborare senza che una assorba l'altra. I termini legali disciplinano cosa succede quando le cose vanno male. Il modello di governance determina se le cose vanno bene.

Il modello di governance deve rispondere a quattro domande che la maggior parte degli accordi non affronta:

Chi e il singolo decisore da ciascuna parte? Non un comitato. Non "il team rilevante." Una persona nominata con l'autorita di approvare cambiamenti di scope, risolvere dispute e prendere impegni vincolanti per conto della propria organizzazione. Senza questo, ogni decisione viene escalata. Ogni escalation richiede tempo che la startup non ha.

Qual e la cadenza e il formato delle revisioni di avanzamento? Standups operativi settimanali per questioni operative, revisioni strategiche mensili per l'allineamento strategico. Entrambe con partecipanti definiti, output definiti e diritti decisionali definiti. Se lo stakeholder corporate cambia sei mesi dopo (cambiera), la nuova persona entra in una relazione strutturata, non in una non documentata.

Qual e il processo per i cambiamenti di scope? Accadranno. La corporate vorra aggiungere qualcosa. La startup scoprira che la specifica originale era sbagliata. Il processo per gestire questo, proposta, periodo di revisione, soglia di approvazione, impatto sul budget, deve esistere prima che arrivi la prima richiesta di cambiamento di scope.

Come vengono escalate le dispute prima che diventino crisi? Un percorso di escalation a livelli: responsabile operativo, responsabile di business, sponsor esecutivo. Una tempistica definita a ogni livello. Questo non e un segnale di sfiducia. E un segnale che entrambe le parti fanno sul serio nel far funzionare la relazione.

Il pattern di fallimento piu comune che ho visto: il co-sviluppo viene negoziato e firmato a livello esecutivo, poi consegnato al middle management per l'esecuzione, senza alcun modello di governance in atto. Il fondatore della startup manda email a un responsabile acquisti che non ha autorita per approvare nulla. Passano sei mesi. Non viene lanciato nulla. Entrambe le parti si incolpano a vicenda. L'accordo e perfettamente legale e completamente inutile.

Esclusiva: la clausola che uccide le startup

Questo merita una sezione a se perche le conseguenze sono abbastanza gravi da rendere una startup impossibile da finanziare, da vendere e operativamente vincolata per anni a causa di una sola clausola mal redatta.

Il problema non e l'esclusiva come concetto. Una corporate che investe un budget significativo e apre accessi interni ha un legittimo interesse a non armare immediatamente un concorrente. Il problema e che i team legali aziendali optano per il linguaggio di esclusiva piu ampio possibile, e i fondatori di startup lo firmano perche hanno bisogno dell'accordo e non hanno il potere contrattuale per opporsi in quel momento. Scoprono il vincolo quando cercano di chiudere il prossimo cliente e non possono, o quando vanno a raccogliere il loro Serie A e un VC chiede degli impegni di esclusiva.

Prima di accettare qualsiasi clausola di esclusiva, una startup deve avere chiare quattro alternative che proteggono il legittimo interesse della corporate senza limitare la capacita della startup di costruire un'azienda:

  • Esclusiva a tempo limitato. Esclusiva per un periodo definito (12-18 mesi e ragionevole per la maggior parte dei co-sviluppi), dopodihe la startup e libera di lavorare con altri nello stesso spazio. La corporate ottiene un vantaggio iniziale. La startup non firma via il suo mercato.
  • Esclusiva geografica. La corporate ottiene l'esclusiva nei mercati in cui opera effettivamente. Se la corporate e una banca europea, l'esclusiva nel settore bancario europeo e rilevante. L'esclusiva nel settore bancario statunitense non lo e, e la startup non dovrebbe cederla.
  • Esclusiva per caso d'uso. Esclusiva per questa specifica applicazione (rilevamento frodi nel retail banking, per esempio), non per la tecnologia sottostante ne per l'intero settore dei servizi finanziari. La startup mantiene la capacita di costruire altre applicazioni sulla stessa base tecnica.
  • Diritto di prelazione. Non e esclusiva. La corporate ottiene il diritto di pareggiare qualsiasi offerta che la startup riceva da un concorrente prima che la startup la firmi. E significativamente piu debole dell'esclusiva ma significativamente piu forte di niente, ed e un ragionevole punto di mezzo quando le posizioni sono distanti.

Nessuna di queste alternative e standard. Tutte sono negoziabili. Il lavoro della startup e capire quale esclusiva sta davvero concedendo prima di firmare, e sapere quali dimensioni puo permettersi di cedere e quali no.

La dimensione del finanziamento UE

Questo e specifico del contesto europeo ed e sistematicamente sottoutilizzato. Un co-sviluppo tra una corporate e una startup, se strutturato fin dall'inizio con il consorzio giusto e l'ambito di progetto corretto, puo accedere ai finanziamenti di Horizon Europe. Questo cambia la struttura economica per entrambe le parti in modi che non sono immediatamente ovvi.

Un consorzio composto da corporate piu startup piu almeno un'organizzazione di ricerca o accademica di diversi Stati membri dell'UE puo candidarsi a bandi rilevanti di Horizon Europe nell'ambito del Pilastro 2 o attraverso partnership specifiche. In caso di successo, ogni partner del consorzio riceve la propria quota del budget direttamente dalla Commissione Europea come sovvenzione, non come prestito, non come equity, non come ricavi dagli altri partner del consorzio. Il contributo della corporate ai costi di sviluppo della startup viene effettivamente sostituito, in tutto o in parte, da finanziamenti UE a fondo perduto. I costi di sviluppo della startup sono coperti senza ulteriore diluizione.

La questione della proprieta della PI, che e la piu difficile da risolvere in un co-sviluppo commerciale, e in parte disciplinata dal modello di accordo di sovvenzione di Horizon Europe, che fornisce un quadro collaudato per la PI di background, la PI di foreground, i diritti di accesso e gli obblighi di sfruttamento. Molte startup e corporate trovano piu facile concordare sulla PI nel contesto di Horizon Europe che in uno puramente commerciale, proprio perche il quadro esiste e non viene inventato per l'occasione.

Il vincolo: il progetto deve essere progettato con la domanda di finanziamento UE in mente fin dall'inizio, non adattato successivamente. L'ambito, la composizione del consorzio, l'ambizione di innovazione e l'impatto atteso devono soddisfare i criteri dello specifico bando. Un co-sviluppo commerciale gia avviato non puo essere riconfezionato come progetto Horizon Europe. Ma un co-sviluppo che non e ancora iniziato puo essere progettato per qualificarsi, e la differenza nei risultati di finanziamento puo essere significativa. Per un confronto tra i principali strumenti UE e come scegliere tra di essi, vedi EIC Accelerator vs Horizon Europe: quale scegliere per la tua startup.

Prossimo passo

Stai rivedendo un accordo di co-sviluppo o strutturandone uno da zero?

La maggior parte degli accordi di co-sviluppo che rivedo ha gli stessi tre problemi strutturali, e quasi mai sono quelli su cui entrambe le parti hanno trascorso piu tempo a negoziare. Una conversazione di 30 minuti e di solito sufficiente per identificare i punti deboli prima che diventino dispute.

Inizia la conversazione