NDA para empresas de software: la guía definitiva con plantilla gratuita

Esta es una escena que se repite constantemente: una empresa de software contrata a un contratista para construir una función crítica. Comparten la arquitectura de la API, los esquemas de la base de datos y las especificaciones de datos del cliente. Seis meses después, el contratista trabaja para un competidor — y también lo hace el código base.

Un NDA para contratistas no habría garantizado una protección perfecta. Pero le habría dado una base legal para actuar, buscar daños y detener nuevas divulgaciones. Sin él, solo puede confiar en que el contratista sea honesto.

Esta guía cubre todo lo que una empresa de software necesita saber sobre los NDA para contratistas: las cláusulas que realmente importan, los tipos que se adaptan a diferentes relaciones con contratistas, las señales de alerta que deberían hacerle rechazar un acuerdo, y cómo conseguir que se firmen rápidamente. También hay una plantilla gratuita al final.

Si desea una visión más amplia de cómo las distinciones entre contrato vs. acuerdo se aplican a sus relaciones con contratistas, vale la pena leerlo primero.

Un NDA para contratistas (acuerdo de no divulgación) es un contrato jurídicamente vinculante que obliga a un contratista independiente — ya sea un desarrollador freelance, un subcontratista o una empresa de desarrollo offshore — a mantener su información confidencial en secreto. Define qué cuenta como confidencial, cuánto dura la obligación y qué ocurre si el contratista la incumple.

Para las empresas de software específicamente, la información confidencial no son solo planes de negocio o datos financieros. Es el código fuente, la arquitectura del sistema, las credenciales de acceso al repositorio, los datos del cliente, las integraciones de API, los algoritmos propietarios y las hojas de ruta de productos no publicadas. Ese es un alcance más amplio y más técnicamente específico que el que cubre un NDA genérico.

Un NDA para contratistas difiere de un acuerdo de confidencialidad para empleados de una manera importante: los empleados normalmente firman una cláusula de confidencialidad incluida en su contrato de trabajo, mientras que los contratistas firman un NDA independiente antes de que comience el trabajo. Esa estructura independiente importa. Crea una obligación separada y claramente definida que no está enredada con disputas de compensación o derecho laboral.

La respuesta corta sobre exigibilidad: un NDA para contratistas bien redactado es exigible en todas las jurisdicciones principales según los principios del derecho contractual. En Estados Unidos, los secretos comerciales también están protegidos por la Defend Trade Secrets Act (DTSA) a nivel federal y el Uniform Trade Secrets Act (UTSA) a nivel estatal — dándole dos vías legales independientes si un contratista se apropia indebidamente de su código.

La respuesta corta: los contratistas no son empleados, y esa diferencia importa legalmente.

Los empleados tienen varias obligaciones implícitas y estatutarias en torno a la confidencialidad que no se aplican automáticamente a los contratistas independientes. Un contratista puede, por defecto, usar el conocimiento que adquirió trabajando con usted para beneficiar a un competidor — a menos que haya contratado explícitamente lo contrario. Un NDA cierra esa brecha.

Los riesgos específicos para las empresas de software son mayores que en la mayoría de las industrias:

• Exposición del código fuente — Un contratista al que se le dio acceso al repositorio ve toda su implementación técnica. Si se va sin un NDA, puede replicar o vender ese conocimiento libremente.
• Acceso a datos del cliente — Muchos contratistas tocan bases de datos de clientes, registros de CRM o puntos finales de API que exponen información del cliente. Una violación aquí no es solo una pérdida competitiva; es una responsabilidad de GDPR o CCPA.
• Secretos comerciales en la arquitectura — Su diseño de sistema, la forma en que ha estructurado sus canalizaciones de datos, sus algoritmos propietarios — estos son secretos comerciales solo si se tratan como secretos. Un NDA es parte de ese tratamiento.
• Riesgo de paso a subcontratistas — Si su contratista contrata a sus propios subcontratistas (común en la subcontratación offshore), y esos subcontratistas no están sujetos a obligaciones de confidencialidad, sus secretos fluyen a través de una brecha en su marco legal.

Para equipos que gestionan múltiples contratistas simultáneamente, la sobrecarga administrativa de rastrear el estado del NDA es real. Por eso resulta útil una gestión documental para empresas de TI a escala — necesita saber qué contratistas han firmado, cuándo y dónde residen los acuerdos ejecutados.

Advertencia justa: un NDA por sí solo no es una estrategia de seguridad completa. Todavía necesita controles de acceso, procedimientos de baja y gestión de permisos del repositorio. El NDA es su recurso legal cuando esos controles técnicos fallan o cuando un contratista actúa de manera engañosa a pesar de tener acceso que le fue autorizado.

No toda relación con un contratista necesita la misma estructura de NDA. Elegir el tipo incorrecto desperdicia capital de negociación e incluso puede señalar que no entiende la relación.

NDA unilateral

Este es el formato estándar para la mayoría de las relaciones con contratistas. Solo una parte — típicamente la empresa de software — divulga información confidencial, y solo el contratista está obligado a mantener la confidencialidad. Está contratando a alguien para construir algo. Está compartiendo sus especificaciones, su arquitectura, su contexto de cliente. Ellos no están compartiendo nada propietario con usted.

Use un NDA unilateral cuando: contrate a un desarrollador freelance, contrate a un contratista de QA o trabaje con un especialista individual para un proyecto acotado.

NDA mutuo (bilateral)

Ambas partes comparten información confidencial y ambas están obligadas. Esto es apropiado cuando está evaluando una empresa de outsourcing que le presentará su propia metodología, procesos o PI propietarios — y ellos tienen un interés legítimo en proteger esa información también.

En la práctica, las empresas de desarrollo offshore a menudo solicitan NDA mutuos. Es razonable. Solo asegúrese de que las definiciones de "información confidencial" no sean tan amplias de su parte que la comunicación normal del proyecto se restrinja.

NDA multilateral

Cubre tres o más partes en un solo acuerdo — útil cuando un proyecto involucra a su empresa, un contratista principal y un subcontratista especializado que todos necesitan compartir información entre sí. Un documento en lugar de tres bilaterales. Más complejo de redactar, pero más sencillo de gestionar.

Estos dos documentos a menudo se confunden, y esa confusión causa problemas reales. Protegen cosas diferentes y funcionan mejor juntos.

Un NDA para contratistas protege la información confidencial que comparte con el contratista. Gobierna lo que no pueden divulgar. No dice nada sobre quién es dueño del trabajo que producen.

Un acuerdo de cesión de PI hace lo contrario: gobierna quién es dueño del producto de trabajo creado durante la relación. En la mayoría de las jurisdicciones, un contratista independiente es dueño del copyright del código que escribe a menos que haya un acuerdo escrito que ceda esa propiedad a usted.

Esto es por qué importa: si tiene un NDA pero no una cesión de PI, el contratista no puede divulgar sus secretos — pero podrían ser dueños del código que escribieron para usted. Esa es una brecha significativa.

Para una empresa de software, típicamente necesita ambos:

1. 1.
   El NDA protege la información confidencial que comparte durante la relación
2. 2.
   La cesión de PI transfiere la propiedad del producto de trabajo a usted

Algunos contratos agrupan ambos en un solo documento (común en acuerdos de consultoría), pero mantenerlos separados hace que el alcance de cada obligación sea más claro y más fácil de exigir individualmente.

El blog de Chaindoc tiene una guía dedicada sobre cómo crear un NDA seguro que cubre la estructura general del NDA con más profundidad — vale la pena leerla junto con esta guía específica para contratistas.

Una cláusula de no competencia restringe al contratista de trabajar para competidores o iniciar un negocio competidor por un período definido después de que termina la relación. Un NDA restringe lo que pueden divulgar, pero no les impide trabajar para su competidor — solo les impide llevarse sus secretos con ellos.

En la práctica: si un desarrollador senior conoce toda su arquitectura técnica, incluso un NDA perfectamente ejecutado no le impide reconstruirla de memoria para un competidor. Una cláusula de no competencia aborda ese riesgo directamente.

Dicho esto, las cláusulas de no competencia para contratistas independientes solo son exigibles en algunas jurisdicciones, y los tribunales las examinan por razonabilidad — específicamente alcance (qué industrias o roles están restringidos), geografía (qué región) y duración (cuánto tiempo). California, por ejemplo, se niega en gran medida a exigir las no competencias para contratistas. Muchos países de la UE tienen restricciones similares.

Para la mayoría de las empresas de software que trabajan con contratistas:

• Siempre use un NDA — exigible casi en todas partes, protección esencial
• Use una no competencia selectivamente — para contratistas senior con acceso profundo a la PI central, en jurisdicciones donde la exigibilidad es realista, con un alcance estrecho y razonable
• No incorpore las no competencias en los NDA — manténgalas en el acuerdo principal de servicios o en una cláusula separada para que las disputas sobre una no invaliden la otra

Las plantillas de NDA genéricas a menudo omiten el alcance específico de software que hace que estos acuerdos sean realmente protectores. Estas son las 10 cláusulas que todo NDA para contratistas de una empresa de software debería incluir.

1. Definición de información confidencial (específica para software)

Enumere categorías explícitas, no confíe en el lenguaje genérico de captura global. Para las empresas de software, eso significa: código fuente y binarios compilados, arquitectura de sistema y especificaciones técnicas, esquemas de base de datos, claves de API y credenciales de autenticación, datos del cliente y listas de clientes, hojas de ruta de productos y funciones no publicadas, y herramientas internas o flujos de trabajo propietarios.

2. Política de acceso al repositorio

Especifique a qué repositorios de código puede acceder el contratista, el nivel de permiso concedido (lectura, escritura, administrador), y la obligación de no retener copias después de que termine la relación. Esta cláusula es específica del software y la mayoría de las plantillas genéricas no la incluyen.

3. Manejo de datos del cliente

Si el contratista accederá a cualquier dato del cliente — incluso en un entorno de pruebas o staging — especifique los usos permitidos, la prohibición de retener copias, y la obligación de notificación si sospecha una violación de datos que involucre esa información.

4. Referencia cruzada de cesión de PI

Indique que este NDA opera junto con un acuerdo de cesión de PI separado, y que las obligaciones de confidencialidad del contratista son independientes de la cesión de PI — la violación de ningún documento afecta la exigibilidad del otro.

5. Devolución o destrucción de materiales

Al terminar la relación, el contratista debe devolver o destruir certificadamente todas las copias de información confidencial — incluyendo código descargado localmente, documentación almacenada en unidades de nube personales, y credenciales de API. Exija confirmación por escrito.

6. Paso a subcontratistas

Si el contratista usa subcontratistas, esos subcontratistas deben estar sujetos a obligaciones de confidencialidad equivalentes antes de recibir cualquier información confidencial. El contratista principal sigue siendo responsable de las violaciones de sus subcontratistas.

7. Término y supervivencia

Las obligaciones de confidencialidad para secretos comerciales (código fuente, algoritmos centrales) deben subsistir indefinidamente después de que termine la relación. Para otra información confidencial, tres a cinco años es el estándar. Establezca explícitamente que el NDA sobrevive a la terminación del acuerdo principal de servicios.

8. Exclusiones de la confidencialidad

Exclusiones estándar: información ya conocida públicamente, información desarrollada independientemente sin referencia a sus divulgaciones, información recibida de un tercero sin restricciones de confidencialidad. Sea específico — exclusiones demasiado amplias crean brechas.

9. Ley aplicable y jurisdicción

Nombre la jurisdicción gobernante explícitamente. Para relaciones con contratistas transfronterizas, considere especificar la arbitración como mecanismo de resolución de disputas — típicamente es más rápida y predecible a través de fronteras que el litigio.

10. Remedios y alivio injuntivo

Establezca explícitamente que una violación causará daño irreparable que justifica el alivio injuntivo sin requerir prueba de daños monetarios específicos. Este es el lenguaje estándar del NDA pero crítico — sin él, tendría que cuantificar pérdidas antes de que un tribunal actúe, lo cual es difícil con violaciones de PI.

La misma plantilla de NDA no se adapta igual de bien a cada relación con un contratista. Así es como el perfil de riesgo — y por tanto los requisitos del NDA — difieren según el tipo de contratista.

Desarrollador freelance

Un freelancer que trabaja en una sola función o módulo tiene una exposición acotada: ve lo que es relevante para su tarea, y eso es todo. Su NDA puede ser relativamente estándar aquí — unilateral, con definición de información confidencial específica de software y una cláusula de acceso al repositorio. El proceso de firma debe ser simple y rápido: enviar, firmar, proceder. La fricción aquí le hace perder buenos contratistas.

Subcontratista (a través de una agencia principal)

Esta es una configuración más riesgosa de lo que parece. Cuando contrata a una agencia y ellos subcontratan el trabajo a desarrolladores individuales, a menudo no sabe quiénes son esos desarrolladores ni a qué pueden acceder. Su NDA con la agencia debería incluir una cláusula de paso a subcontratistas (Cláusula 6 anterior) y exigir que se le notifique de todos los subcontratistas que accederán a sus sistemas. Considere exigir NDA directos con subcontratistas clave si tendrán acceso al repositorio.

Empresa de desarrollo offshore

Aquí es donde los NDA necesitan más cuidado. Una empresa offshore puede tener sus propios acuerdos estándar que parecen integrales pero están regidos por ley extranjera con exigibilidad limitada en su jurisdicción. Adiciones clave para relaciones offshore:

• Cláusula de ley aplicable y jurisdicción que especifique su jurisdicción para disputas
• Disposiciones explícitas de cumplimiento de GDPR/CCPA si están involucrados datos del cliente
• Un NDA mutuo si la empresa compartirá metodología propietaria — pero asegúrese de que el alcance de su información confidencial sea al menos tan amplio como el de ellos
• Arbitraje internacional (reglas ICC o AAA) para resolución de disputas

Para equipos que gestionan contratistas a través de estos diferentes tipos, el software de gestión de contratos para empresas de TI puede rastrear qué contratista tiene qué acuerdo, cuándo se firmó, y cuándo vence o debe revisarse — en lugar de depender de una hoja de cálculo compartida que inevitablemente está desactualizada.

El error más común que cometen las empresas de software no es redactar un mal NDA — es firmarlo demasiado tarde.

El NDA debe estar en vigor antes de que se comparta cualquier información confidencial. Eso suena obvio, pero en la práctica se omite durante conversaciones iniciales, llamadas de descubrimiento y sesiones de definición técnica donde está compartiendo contexto del sistema para ayudar al contratista a entender el proyecto.

Este es el orden correcto de firma para una relación típica con un contratista:

1. 1.
   NDA — Firme primero, antes de cualquier llamada de descubrimiento donde discutirá arquitectura técnica, datos del cliente o especificaciones del sistema
2. 2.
   Acuerdo de cesión de PI — Firme antes de que comience cualquier trabajo (idealmente junto con o inmediatamente después del NDA)
3. 3.
   Statement of Work (SOW) — Define el alcance, entregables, cronograma y pago; firme antes de que comience el trabajo. Vea nuestra guía sobre contratos SOW para saber qué incluir.
4. 4.
   Master Services Agreement (MSA) o contrato de desarrollo de software — El marco rector de la relación continua

Una regla útil: si está a punto de decirle algo a un contratista potencial que no querría que sea público, el NDA ya debería estar firmado.

Para conversaciones iniciales antes de haber seleccionado un contratista — llamadas exploratorias, procesos de RFP — puede compartir solo contexto general no confidencial, o usar un NDA mutuo ligero que ambas partes firmen rápidamente. La segunda opción es más limpia.

Para equipos que ejecutan ciclos frecuentes de incorporación de contratistas, automatizar el flujo de trabajo de NDA e incorporación de contratistas elimina el error de tiempo — el sistema activa el envío del NDA antes de que se otorgue el primer acceso.

La mayoría de las veces, usted enviará NDA a los contratistas. Pero los contratistas — especialmente las agencias establecidas — a veces presentan los suyos. Esto es lo que debería hacerle detenerse.

Definición de "información confidencial" demasiado amplia de su parte

Si el NDA de un contratista define su información confidencial como "cualquier información compartida durante la relación" sin límites significativos, podría terminar restringido de compartir lo que aprendió — su propia arquitectura, su propio contexto de cliente — con futuros contratistas que hagan trabajo similar. Un NDA mutuo debería tener definiciones claramente delimitadas y equilibradas en ambos lados.

Término indefinido para información que no es secreto comercial

Un término de confidencialidad indefinido para información comercial general (no secretos comerciales específicos) a menudo es inaplicable y es una señal de alerta de que el acuerdo no fue redactado cuidadosamente. En algunas jurisdicciones, los tribunales anulan las obligaciones de confidencialidad indefinidas para información comercial ordinaria como una restricción irrazonable al comercio. Resista y defina un término específico.

Cláusula de arbitraje unilateral

Si el NDA especifica arbitraje solo en la jurisdicción del contratista, con los árbitros elegidos por el contratista, eso es un mecanismo de cumplimiento asimétrico. Tendría que viajar para hacer cumplir sus propios derechos de confidencialidad. Establezca una jurisdicción neutral o especifique reglas de arbitraje de un organismo reconocido (ICC, AAA) sin una sede sesgada por jurisdicción.

Falta de exclusión de PI

Algunos NDA presentados por contratistas incluyen lenguaje que podría interpretarse como otorgando al contratista algunos derechos sobre lo que aprende sobre su PI — particularmente si "información confidencial" se define tan ampliamente que abarca cualquier conocimiento que adquiera. Si el NDA no excluye explícitamente su PI preexistente de cualquier restricción sobre su uso, aclárelo.

Sin cláusula de devolución o destrucción

Un NDA para contratistas sin una obligación explícita de devolución o destrucción permite que el contratista retenga copias de su código y documentación después de que termine la relación. Eso no es aceptable. Hágalo un requisito.

Los riesgos no son hipotéticos. Estos casos ilustran lo que cuesta realmente la apropiación indebida de secretos comerciales.

Cadence Design Systems v. Avanti Corporation (265 M$)

Avanti, una empresa de software EDA competidora, fue encontrada culpable de haber usado el código fuente propietario de Cadence — supuestamente traído por antiguos empleados de Cadence que se unieron a Avanti. El caso resultó en una sentencia que superó los 265 millones de dólares y condenas penales para varias personas. El mecanismo subyacente fue la salida de empleados, pero el mismo riesgo se aplica a los contratistas: un contratista que trabaja en múltiples empresas es un vector de transferencia de código, intencional o no.

La lección: incluso las empresas de software bien dotadas con protecciones de PI establecidas enfrentan este riesgo. Los acuerdos de confidencialidad con cualquiera que acceda al código propietario son parte de la higiene básica de PI — no un extra opcional.

Waymo v. Uber (245 M$)

Waymo, la filial de vehículos autónomos de Alphabet, demandó a Uber después de que un antiguo ingeniero de Google supuestamente se llevó archivos técnicos confidenciales a una startup que fue posteriormente adquirida por Uber. El acuerdo alcanzó aproximadamente 245 millones de dólares en acciones. Notablemente, el ingeniero había firmado NDA y acuerdos de PI con Google — lo que significó que Waymo tenía base legal para perseguir el caso agresivamente.

El contrapunto es igualmente importante: los NDA y las cesiones de PI no evitaron la violación. Pero le dieron a Waymo la base legal para actuar. Sin ellos, Waymo no habría tenido un mecanismo exigible para buscar un acuerdo de esa magnitud. Ese es el valor real de un NDA para contratistas bien redactado: no la prevención, sino la exigibilidad cuando la prevención falla.

Ambos casos involucraron secretos comerciales mucho más sofisticados que la mayoría de las relaciones con contratistas. Pero el patrón es universal en el software: el código confidencial se mueve con las personas que lo escriben. Su NDA para contratistas es el mecanismo legal que hace que ese movimiento sea actionable.

Conseguir que un NDA se firme rápidamente importa. Un proceso de firma engorroso significa que los contratistas lo omiten o lo firman tarde — ambos son fallas. Así es como hacerlo correctamente y rápido.

Paso 1: Preparar el documento NDA

Use la plantilla a continuación o su propia versión personalizada. Asegúrese de que todas las cláusulas específicas de software estén en su lugar antes de enviar. Una adición de último momento después de que el contratista haya revisado el documento extiende innecesariamente el cronograma.

Paso 2: Enviar para firma electrónica

Suba el NDA a una plataforma de firma electrónica que proporcione un registro de auditoría a prueba de manipulaciones. Esto no es una preferencia burocrática — es probatorio. Si alguna vez necesita hacer cumplir el NDA, necesita prueba de que una persona específica firmó un documento específico en un momento específico, y que el documento no fue modificado posteriormente.

Chaindoc utiliza verificación blockchain para registrar cada evento de firma en un libro de contabilidad inmutable. A diferencia de un simple registro de auditoría en PDF que reside en los servidores de una empresa, un registro blockchain no puede ser alterado retroactivamente por ninguna de las partes. Eso importa en disputas donde el abogado del contratista cuestiona si el documento que está viendo es el que su cliente firmó.

Paso 3: Verificar identidad antes de la firma

Una firma de "usuario en gmail.com" no prueba que la persona con la que contrató firmó realmente. Use verificación por OTP de correo electrónico como mínimo; para relaciones de alto valor, la verificación por SMS o identificación gubernamental proporciona una no repudiación más fuerte.

Paso 4: Almacenar con controles de acceso

El NDA firmado debe residir en un sistema de gestión documental con acceso basado en roles — accesible para su equipo legal y liderazgo senior, no almacenado en una carpeta de correo electrónico compartida. Etiquételo con el nombre del contratista, fechas de la relación y referencia del proyecto para que sea recuperable bajo presión.

Paso 5: Rastrear vencimiento y renovación

Si su NDA tiene un término definido, rastree la fecha de vencimiento. Un NDA que venció hace seis meses no lo protege hoy.

Para empresas de software que gestionan flujos de trabajo documentales para equipos de TI, automatizar este proceso — activar el envío del NDA cuando se añade un contratista, recordatorio automático antes de que se otorgue el acceso, alertas de vencimiento — elimina la sobrecarga manual que causa fallas de tiempo. Vea los precios de Chaindoc para planes de equipo que incluyen flujos de trabajo documentales para contratistas.

Para una mirada más profunda al lado del cumplimiento legal de las firmas electrónicas, la ESIGN Act (EE. UU.) y eIDAS (UE) ambos confirman que los NDA firmados electrónicamente tienen el mismo peso legal que el papel.

La plantilla a continuación es un punto de partida — un NDA unilateral para contratistas con cláusulas específicas de software integradas. Cubre las 10 cláusulas enumeradas en esta guía e incluye valores predeterminados de jurisdicción de EE. UU. (regido por las leyes del estado que especifique, protección de secretos comerciales DTSA referenciada).

Descargue la plantilla de NDA para contratistas de Chaindoc:

• Descargar PDF
• Descargar DOCX

Qué incluye la plantilla:

• Definición de información confidencial específica de software (código fuente, arquitectura, credenciales, datos del cliente, hojas de ruta)
• Cláusula de política de acceso al repositorio
• Obligación de paso a subcontratistas
• Cláusula de devolución o destrucción con requisito de certificación
• Cláusula de referencia cruzada de cesión de PI
• Cláusula de alivio injuntivo
• Marcador de ley aplicable (complete su estado o jurisdicción)
• Término de 3 años para información confidencial general / indefinido para secretos comerciales

Aviso legal importante: Esta plantilla se proporciona con fines informativos y no constituye asesoramiento legal. La exigibilidad varía según la jurisdicción y las circunstancias específicas. Para relaciones de alto valor, relaciones novedosas con contratistas o situaciones transfronterizas, haga revisar el acuerdo por un abogado calificado antes de usarlo.

Para un conjunto completo de documentos de incorporación de contratistas — NDA, SOW y términos de pago — las herramientas de gestión de contratos para empresas de TI de Chaindoc le permiten construir plantillas una vez y enviarlas consistentemente a cada nuevo contratista.