Como estructurar un acuerdo de codesarrollo corporacion-startup (sin matar a la startup)

La decision que viene antes del acuerdo

La mayoria de las negociaciones de codesarrollo comienzan en el lugar equivocado. Ambos equipos legales abren sus documentos de plantilla y empiezan a intercambiar borradores antes de que las personas que realmente haran el trabajo hayan acordado las cuatro preguntas que determinan si la relacion tendra exito o fracasara. Cuando esas preguntas afloran, las posiciones ya estan atrincheradas y la negociacion se ha vuelto adversarial.

Las cuatro decisiones no son detalles legales. Son decisiones de negocio que condicionan todo lo demas. Deben ser tomadas por los responsables de negocio, en conversacion, antes de que intervengan los abogados. Una vez acordadas, la redaccion legal es relativamente sencilla. Sin acuerdo sobre ellas, ningun nivel de precision legal salvara la relacion.

Decision 1: quien es propietario de la PI que se crea?

Esta es la pregunta que la mayoria de los codesarrollos dejan implicita y sobre la que versan la mayoria de los conflictos. La corporacion asume que es propietaria de todo lo construido con sus datos, su experiencia en el sector y su presupuesto. La startup asume que retiene la tecnologia core porque sus ingenieros la escribieron y constituye la base de su producto. Ambas suposiciones tienen alguna base legal y ninguna es completamente correcta. El resultado es un problema que emerge en el peor momento posible: normalmente cuando la relacion ya esta bajo tension.

Las opciones viables, en orden de frecuencia con que realmente funcionan:

• La startup es propietaria del resultado, la corporacion obtiene una licencia definida. La startup retiene su PI, incluidas las mejoras realizadas durante el proyecto. La corporacion recibe una licencia que especifica lo que puede hacer con el resultado (uso interno, comercializacion en mercados definidos, sublicencia a filiales o no). Es la estructura mas favorable para el fundador y la mas sencilla de gestionar.
• La corporacion es propietaria del resultado del proyecto, la startup retiene la tecnologia subyacente. Lo que posee la corporacion es la configuracion especifica, la integracion y cualquier funcionalidad a medida construida para ella. La startup retiene la plataforma, los algoritmos, los metodos propietarios. Ambas partes reciben una licencia sobre lo que posee la otra para los propositos del proyecto. Es viable pero requiere una definicion muy precisa de lo que cuenta como "tecnologia subyacente."
• Un vehiculo creado al efecto posee la PI. Se crea una nueva entidad para albergar la PI desarrollada conjuntamente, en la que ambas partes tienen participacion accionarial. Es la estructura juridicamente mas defendible, la mas compleja de establecer, y normalmente solo tiene sentido cuando el resultado del codesarrollo es lo suficientemente significativo como para convertirse en un negocio independiente.
• Copropiedad. Parece equitativa. Casi siempre es la peor opcion en la practica. Los copropietarios pueden normalmente usar la PI de forma independiente, pero ninguno puede licenciarla a un tercero ni demandar por infraccion sin el consentimiento del otro. Dos empresas tomando esas decisiones juntas, con intereses comerciales potencialmente divergentes, es una receta para la paralisis.

Decision 2: hay participacion accionarial?

Algunos codesarrollos son puramente contractuales: la startup entrega un servicio o un producto, la corporacion lo paga, la relacion es comercial. Otros implican que la corporacion toma una participacion en la startup, o que ambas partes cofundan una nueva entidad. Esta decision cambia toda la naturaleza de la relacion y debe ser explicita desde la primera conversacion.

La participacion accionarial no es automaticamente mejor para ninguna de las partes. Para la startup, puede senalar compromiso y asegurar un socio estrategico. Tambien puede introducir un accionista con derechos de veto e incentivos diferentes al equipo fundador. Para la corporacion, el capital proporciona ventaja si la startup tiene exito. Tambien crea obligaciones, posibles conflictos de interes y complejidad de gobernanza que la mayoria de los equipos legales y financieros corporativos no estan preparados para gestionar eficientemente.

Si el capital forma parte de la conversacion, la valoracion, el instrumento (acuerdo simple para equity futuro, nota convertible, compra directa de acciones) y los derechos de gobernanza que conlleva deben resolverse antes de redactar el acuerdo de codesarrollo. Son demasiado determinantes para tratarlos como un anexo.

Decision 3: cual es el alcance de la exclusividad?

Las corporaciones casi siempre piden exclusividad. La solicitud es legitima: estan invirtiendo presupuesto, abriendo acceso interno y asumiendo un riesgo reputacional sobre una empresa en fase temprana. Quieren saber que un competidor no obtendra la misma ventaja seis meses despues.

El problema es que "exclusividad" puede significar cosas muy diferentes, y la version que protege el interes legitimo de la corporacion casi nunca es la que se solicita primero. La exclusividad total en un sector vertical, "no puedes trabajar con ninguna otra empresa del sector financiero", puede bloquear a una startup B2B de todo su mercado objetivo. La startup firma porque necesita el acuerdo. Descubre la restriccion cuando intenta cerrar su proximo cliente y no puede.

Esta seccion del acuerdo debe especificar con precision cuatro dimensiones de la exclusividad: que es exclusivo (el resultado, la tecnologia, una aplicacion de mercado), donde se aplica (alcance geografico), durante cuanto tiempo, y que hace que la exclusividad expire antes (hitos de ingresos, objetivos de despliegue, o simplemente el paso del tiempo).

Decision 4: cuales son las condiciones de salida?

Las condiciones de salida son tan importantes como las de entrada y reciben una fraccion de la atencion. Todo codesarrollo termina de una de cuatro formas: tiene exito y ambas partes continuan; tiene exito y la corporacion adquiere la startup; una parte se retira antes de la finalizacion; o el proyecto simplemente se queda sin impulso y muere silenciosamente. El acuerdo debe regular explicitamente los cuatro resultados.

Las preguntas que necesitan respuesta: que ocurre con la PI desarrollada conjuntamente si la corporacion termina anticipadamente? La startup puede quedarse con lo construido sobre su propia tecnologia? Que pasa si la startup es adquirida por un competidor de la corporacion durante el proyecto? Cuales son las obligaciones de pago si una parte sale antes de alcanzar los hitos? Hay un derecho de tanteo sobre la adquisicion?

Estos no son casos extremos. En mi experiencia a traves de docenas de colaboraciones corporacion-startup, las relaciones que terminan mal casi siempre lo hacen precisamente en uno de estos puntos de transicion, en ausencia de un marco preacordado. Para mas informacion sobre los patrones que causan el fracaso de las colaboraciones corporacion-startup, el marco practico de colaboracion corporacion-startup cubre la dinamica estructural en detalle.

Lo que el acuerdo realmente necesita cubrir

Una vez resueltas las cuatro decisiones de negocio, puede comenzar la redaccion legal. El error comun es usar una plantilla estandar de NDA mas acuerdo de servicios y adaptarla al contexto del codesarrollo. El codesarrollo es un tipo de relacion distinto para el que las plantillas estandar no estan disenadas.

Las clausulas esenciales mas alla de la PI y la exclusividad:

Plan de trabajo y gobernanza de hitos. No solo que se entregara, sino quien lo aprueba, en que plazo, con que proceso cuando hay desacuerdo. Cuanto mas precisa sea esta seccion, menos conflictos surgiran. Los entregables vagos producen conversaciones vagas sobre si se han cumplido.

Intercambio y propiedad de datos. Cuando la corporacion proporciona datos propietarios (registros de clientes, datos operativos, inteligencia de mercado) para que la startup los use en el desarrollo o el entrenamiento de modelos, el acuerdo debe especificar que puede hacer la startup con esos datos, si pueden usarse para mejorar el producto general de la startup, si pueden retenerse al finalizar el proyecto, y que ocurre con los modelos o insights derivados. Este es un territorio cada vez mas regulado en Europa bajo el RGPD y la Ley de IA de la UE.

Derechos de publicacion. La startup puede querer publicar resultados de investigacion, casos de estudio o articulos tecnicos. La corporacion casi nunca lo quiere, al menos no sin revision. Una clausula de derechos de publicacion que requiera la aprobacion corporativa antes de cualquier divulgacion externa, con un periodo de revision definido y un mecanismo de aprobacion tacita si no se recibe respuesta, equilibra ambos intereses.

Derechos de sublicencia. Puede la corporacion dar el resultado desarrollado conjuntamente a sus filiales? A sus clientes? A integradores terceros? Esto importa enormemente para la economia y la posicion competitiva de la startup, y con frecuencia queda ambiguo en los primeros borradores.

Cambio de control. Abordado anteriormente como condicion de salida, pero vale la pena especificarlo en el propio acuerdo: que constituye un cambio de control, que derechos activa y para quien.

Estructura de pago. Los pagos por hitos alinean mejor los incentivos que los honorarios basados en tiempo. La corporacion paga cuando se entregan resultados definidos. La startup tiene un objetivo claro y objetivo. Los conflictos sobre si el trabajo se ha realizado son mucho menos frecuentes cuando la definicion de "hecho" esta en el contrato y no en el correo electronico de alguien.

Gobernanza operativa: la parte que la mayoria de los acuerdos omiten

Un acuerdo de codesarrollo no es solo un documento legal. Es un marco operativo para que dos organizaciones que funcionan de manera diferente colaboren sin que una absorba a la otra. Los terminos legales regulan lo que ocurre cuando las cosas van mal. El modelo de gobernanza determina si las cosas van bien.

El modelo de gobernanza debe responder cuatro preguntas que la mayoria de los acuerdos no abordan:

Quien es el unico responsable de la toma de decisiones en cada parte? No un comite. No "el equipo relevante." Una persona concreta con autoridad para aprobar cambios de alcance, resolver conflictos y hacer compromisos vinculantes en nombre de su organizacion. Sin esto, cada decision escala. Cada escalada requiere tiempo que la startup no tiene.

Cual es la cadencia y el formato de las revisiones de progreso? Reuniones operativas semanales para asuntos operativos, revisiones estrategicas mensuales para la alineacion estrategica. Ambas con asistentes definidos, resultados definidos y derechos de decision definidos. Si el responsable corporativo cambia a los seis meses (lo hara), la nueva persona se incorpora a una relacion estructurada, no a una no documentada.

Cual es el proceso para los cambios de alcance? Ocurriran. La corporacion querrra agregar algo. La startup descubrira que la especificacion original era incorrecta. El proceso para manejar esto, propuesta, periodo de revision, umbral de aprobacion, impacto presupuestario, debe existir antes de que llegue la primera solicitud de cambio de alcance.

Como se escalan los conflictos antes de que se conviertan en crisis? Una ruta de escalada por niveles: responsable operativo, responsable de negocio, patrocinador ejecutivo. Un plazo definido en cada nivel. Esto no es una senal de desconfianza. Es una senal de que ambas partes se toman en serio el exito de la relacion.

Exclusividad: la clausula que acaba con las startups

Esto merece una seccion propia porque las consecuencias son lo suficientemente graves como para que una clausula mal redactada pueda hacer que una startup sea imposible de financiar, de vender y operativamente restringida durante anos.

El problema no es la exclusividad como concepto. Una corporacion que invierte un presupuesto significativo y abre acceso interno tiene un interes legitimo en no armar inmediatamente a un competidor. El problema es que los equipos legales corporativos optan por el lenguaje de exclusividad mas amplio posible, y los fundadores de startups lo firman porque necesitan el acuerdo y no tienen el poder de negociacion para rechazarlo en ese momento. Descubren la restriccion cuando intentan cerrar su proximo cliente y no pueden, o cuando van a levantar su Serie A y un VC pregunta sobre compromisos de exclusividad.

Antes de aceptar cualquier clausula de exclusividad, una startup debe tener claras cuatro alternativas que protegen el interes legitimo de la corporacion sin restringir la capacidad de la startup para construir un negocio:

• Exclusividad limitada en el tiempo. Exclusiva por un periodo definido (12 a 18 meses es razonable para la mayoria de los codesarrollos), tras el cual la startup es libre de trabajar con otros en el mismo espacio. La corporacion obtiene una ventaja inicial. La startup no firma su mercado.
• Exclusividad geografica. La corporacion obtiene exclusividad en los mercados donde realmente opera. Si la corporacion es un banco europeo, la exclusividad en banca europea es relevante. La exclusividad en banca estadounidense no lo es, y la startup no deberia cederla.
• Exclusividad por caso de uso. Exclusiva para esta aplicacion especifica (deteccion de fraude en banca minorista, por ejemplo), no para la tecnologia subyacente ni para todo el sector de servicios financieros. La startup retiene la capacidad de construir otras aplicaciones sobre la misma base tecnica.
• Derecho de tanteo. No es exclusividad en absoluto. La corporacion obtiene el derecho de igualar cualquier oferta que reciba la startup de un competidor antes de que la startup la firme. Es significativamente mas debil que la exclusividad pero significativamente mas fuerte que nada, y es un termino medio razonable cuando las posiciones estan muy alejadas.

Ninguna de estas alternativas es estandar. Todas son negociables. El trabajo de la startup es entender que exclusividad esta dando realmente antes de firmar, y saber que dimensiones puede permitirse ceder y cuales no.

La dimension de la financiacion de la UE

Esto es especifico del contexto europeo y sistematicamente infrautilizado. Un codesarrollo entre una corporacion y una startup, si se estructura desde el principio con el consorcio adecuado y el alcance de proyecto correcto, puede optar a financiacion de Horizon Europe. Esto cambia la economia para ambas partes de maneras que no son inmediatamente obvias.

Un consorcio formado por corporacion mas startup mas al menos una organizacion de investigacion o academica de diferentes Estados miembros de la UE puede solicitar convocatorias relevantes de Horizon Europe bajo el Pilar 2 o a traves de asociaciones especificas. Si tiene exito, cada socio del consorcio recibe su parte del presupuesto directamente de la Comision Europea en forma de subvencion, no como prestamo, no como equity, no como ingresos de los otros socios del consorcio. La contribucion de la corporacion a los costes de desarrollo de la startup se reemplaza, total o parcialmente, por financiacion de la UE en forma de subvencion. Los costes de desarrollo de la startup se cubren sin dilusion adicional.

La cuestion de la propiedad de la PI, que es la mas dificil de resolver en un codesarrollo comercial, esta en parte regulada por el modelo de acuerdo de subvencion de Horizon Europe, que proporciona un marco probado para la PI de fondo, la PI de primer plano, los derechos de acceso y las obligaciones de explotacion. Muchas startups y corporaciones encuentran mas facil acordar la PI en el contexto de Horizon Europe que en uno puramente comercial, precisamente porque el marco existe y no se inventa para la ocasion.

La restriccion: el proyecto debe diseñarse con la solicitud de financiacion de la UE en mente desde el principio, no adaptarse posteriormente. El alcance, la composicion del consorcio, la ambicion de innovacion y el impacto esperado deben cumplir los criterios de la convocatoria especifica. Un codesarrollo comercial que ya esta en marcha no puede reempaquetarse como un proyecto de Horizon Europe. Pero un codesarrollo que aun no ha comenzado puede disenarse para calificar, y la diferencia en los resultados de financiacion puede ser significativa. Para una comparacion de los principales instrumentos de la UE y como elegir entre ellos, consulta EIC Accelerator vs Horizon Europe: cual es el mejor para tu startup.