Hay dos tipos de empresarios. El primero cree que es dueño porque paga: nómina, proveedores, impuestos, el "equipo completo", los meses duros, los errores, la repetición de las tareas... todo. El segundo, es dueño de verdad: porque aunque mañana se vaya la persona clave, el negocio sigue.
La diferencia no está en el dinero. Está en el control del activo.
Ese activo no es el local. No es la maquinaria. No es el uniforme. Es lo que no se ve: el código que factura, la lógica que decide, el software que sostiene la operatividad del negocio, la receta que hace que el cliente vuelva, el proceso que evita pérdidas, el know-how que convierte un negocio común en uno con ventaja.
Y cuando ese activo no está amarrado a la empresa, basta con que quien lo creó salga de nómina —o que el tercero contratado entre en desacuerdo— para que el golpe llegue: por WhatsApp... o por notificación formal:
"Eso lo hice yo."
"Eso está a mi nombre."
"Ustedes no pueden usarlo."
Cuando usted lee eso, no está frente a un "tema legal". Está frente a una verdad operativa: su empresa estaba funcionando... pero funcionando con un activo prestado.
EL CASO REAL DEL MIXÓLOGO (REPÚBLICA DOMINICANA)
Un restaurante tenía un mixólogo bajo contrato de trabajo. El problema no era que "no había contrato". El problema era más común y más peligroso: sí había relación laboral, pero la función creativa no quedó detallada por escrito y tampoco se pactó, con claridad, que la titularidad y el uso empresarial de las recetas, fichas y estándares creados durante la relación correspondían al negocio.
El negocio creció. Los tragos se volvieron identidad. Y entonces pasó lo que pasa en la vida real: o se rompe la relación, o la competencia lo seduce.
En cualquiera de los dos escenarios, llega el golpe, por WhatsApp, correo o por notificación formal, con una frase que paraliza operaciones:
"Las recetas están registradas a mi nombre. Son de mi propiedad. Ustedes no pueden seguir usándolas ni siquiera mencionándolas en el menú."
Y ahora imagine la escena que pasa de verdad: es viernes, hay reservaciones, y el gerente le llama con una pregunta que no es jurídica... es de supervivencia:
"¿Servimos el trago firma o lo sacamos del menú hoy mismo?"
Ahí nace la zona gris. Y la zona gris cuesta dinero, reputación y sueño. Cambiar recetas es perder identidad. Mantenerlas es operar con riesgo. Negociar es pagar rescate.
La lección no es "vamos a pelear". La lección es más simple, y por eso casi nadie la aplica: documente funciones creativas y pacte titularidad desde el primer día. Si no, usted no tiene un activo; usted tiene una discusión esperando a pasar.
Si no se pacta y no se controla, no se posee.
LO QUE LA LEY REALMENTE PRESUME (Y LO QUE NO PRESUME)
1) Obras creativas bajo empleo o encargo: sin pacto expreso, usted se expone
La Ley 65-00 es más estricta de lo que la mayoría de empresarios cree: En obras creadas bajo relación laboral o bajo encargo, el punto de partida práctico es "lo pactado". Si usted no deja una estipulación contractual clara sobre titularidad/cesión patrimonial, puede terminar discutiendo después lo que debió quedar cerrado desde el inicio.
Traducción sin rodeos: Manuales, documentación, procedimientos, materiales técnicos y creativos... no quedan "blindados" por el simple hecho de pagar salario. Hay que pactarlo.
2) Software: la presunción existe, pero el truco es quién quedó como "productor"
En programas de computadoras, la ley gira alrededor del "productor del programa": quien toma la iniciativa y la responsabilidad de la realización. En ese régimen hay presunciones a favor del productor.
Ahora viene el detalle que cambia todo y que casi nadie entiende hasta que le pasa: Productor no es "el que paga" por definición. Productor es quien, en la práctica, dirige, organiza y controla la realización.
La línea-martillo para que esto quede grabado:
Si el repositorio y las cuentas críticas no están a nombre de su empresa, el "productor real", en la práctica, puede ser otro.
Por eso, en software usted necesita dos líneas simultáneas: titularidad pactada y control operativo diseñado. Si solo hace una, queda cojo.
Presunción legal no es control operativo.
La ley puede ayudar a discutir derechos. Pero no le devuelve por arte de magia el repositorio, las llaves cloud, la documentación ni el historial de versiones. El secuestro moderno no se hace con demandas: se hace con credenciales.
Esto no aplica solo a proveedores externos. También aplica a desarrollos internos: si el software lo construye su propio equipo, usted necesita lo mismo (titularidad pactada + control diseñado), porque el riesgo aparece cuando alguien sale de nómina, se lleva credenciales, o el know-how queda concentrado en una sola persona.
EL PROBLEMA MÁS COMÚN EN SOFTWARE (Y EL MÁS CARO): USTED FINANCIA Y OTRO REVENDE
Esto pasa mucho en fintech, logística, salud, construcción y cualquier negocio que encarga un "sistema propio" para sostener su operación o construir una ventaja competitiva.
Usted paga meses de desarrollo. Paga reuniones, pruebas, ajustes, cambios. Paga incluso los errores. En la práctica, usted financia la maduración de un producto.
Y un día ocurre la escena que nadie olvida: un cliente, un amigo o un empleado le manda un link:
"Mira, esto se parece muchísimo a lo de ustedes..."
Usted abre la demo y le da un golpe en el estómago: los mismos flujos, la misma lógica, el mismo camino del usuario. Cambiaron colores, cambiaron logo, cambiaron el nombre... Y le están vendiendo a otro lo que su dinero ayudó a construir.
Eso es marca blanca.
Primer error: creer que pagar equivale a exclusividad
Si el contrato para el desarrollo del software no prohíbe con precisión reutilizar, adaptar, vender, licenciar ni explotar derivados para terceros, usted pagó por su versión, no por el control del activo.
Segundo error: enfocarse solo en "titularidad" y olvidar "control de copia"
Si el proveedor controla repositorio y entorno, puede crear forks, ramas y versiones paralelas sin que usted lo note. Y cuando usted lo note, ya es demasiado tarde.
La solución es cerrar el hueco
Debe quedar pactado, claro, ejecutable y sin ambigüedad, que:
- El desarrollo financiado por usted pertenece patrimonialmente a la empresa
- Existe exclusividad
- Está prohibida la marca blanca (aunque cambien nombre, logo o parte del código)
- Está prohibido crear para terceros equivalentes funcionales usando los mismos flujos, reglas, integraciones o arquitectura aprendidos en su proyecto
- El proveedor está obligado a entregar, a través del repositorio corporativo del Cliente, todo el código fuente, versiones, historial (commits), documentación y artefactos asociados
Aquí la frase que separa al dueño del ingenuo:
Si usted no prohíbe la marca blanca por contrato y no controla el repositorio, usted puede estar financiando el producto que luego le compite.
PATENTES E INVENCIONES (INCLUIDA INDUSTRIA FARMACÉUTICA): DONDE SÍ EXISTE UNA REGLA FUERTE
En invenciones patentables, el juego cambia. El Art. 8 de la Ley 20-00 regula las invenciones realizadas en cumplimiento o ejecución de un contrato de obra/servicio o de trabajo, y establece que el derecho a la patente por esa invención pertenece al contratante o empleador, salvo pacto en contrario.
Traducción de empresario: en innovación dura, usted no puede "improvisar propiedad" después. Se gobierna al inicio o se paga al final.
KNOW-HOW Y SECRETO EMPRESARIAL: AQUÍ GANA EL QUE DEMUESTRA ORDEN
Para recetas, mezclas, fichas, técnicas internas y procesos, el carril práctico suele ser secreto empresarial: información valiosa porque no es pública y porque la empresa adopta medidas razonables para mantenerla bajo control.
Y aquí la frase clave, sin dramatismo: medidas razonables no es paranoia; es orden.
QUÉ DEBE HACER UN DUEÑO (SIN VOLVERSE ABOGADO)
- El know-how no puede vivir en la cabeza de una persona. Tiene que vivir en la empresa. Eso significa que recetas, fichas, técnicas y procesos deben estar guardados en un lugar corporativo (carpeta oficial, sistema interno, manual con versiones), no en el celular, no en un Drive personal, no en una libreta que "solo él maneja".
- Acceso limitado no es desconfianza; es diseño. No todo el mundo necesita ver todo. El equipo ejecuta el método; la empresa controla el mapa completo. El acceso se da por rol, no por amistad.
- Documentación con disciplina. Cada receta o proceso crítico tiene su ficha, su versión y su responsable. Si se cambia un paso, se actualiza ahí. Así el negocio produce igual aunque cambie la gente... y así nadie se lleva "la verdad" en su cabeza.
- Obligación de entrega y actualización. Lo que se crea para el negocio se entrega al negocio y se mantiene actualizado como parte del trabajo. No es un favor, no es "cuando tenga tiempo".
- Acuerdos de confidencialidad y no uso bien hechos. Para que el know-how no sea conversación, sino activo corporativo.
- En software, repositorio y llaves corporativas. El repositorio debe estar bajo cuenta de la empresa, con más de un administrador interno. Las cuentas de nube, dominios, despliegue y bases de datos deben estar a nombre de la empresa. El proveedor entra como invitado revocable, no como dueño.
- Prohibición clara de marca blanca, derivados y equivalentes funcionales. Si su ventaja está en la lógica del sistema, eso debe estar prohibido de forma expresa y ejecutable: Reempaque, reutilización, licenciamiento a terceros, derivados, forks, versiones y explotación fuera del negocio del cliente.
Las empresas no se rompen solo por competencia. Se rompen cuando descubren tarde que activos materiales e inmateriales de primer orden estaban en manos prestadas.
Si su negocio depende de software, recetas, procesos o know-how, el trabajo serio es convertir eso en control: pactado, documentado y operable aunque cambie la gente.
Para más artículos de interés visite nuestras publicaciones.