NDA en desarrollo de software: qué cubre y qué no

En un NDA unilateral solo una parte revela información y solo la otra se obliga a protegerla. Encaja cuando el cliente muestra su operación al proveedor y este apenas comparte nada sensible. En un NDA bilateral (o mutuo), ambas partes revelan y ambas se obligan.

En desarrollo de software lo bilateral suele ser más realista: el cliente comparte su proceso y sus datos, y el proveedor comparte metodologías, precios, arquitecturas de referencia o componentes propios durante la fase de propuesta. Un acuerdo bilateral también suele negociarse más rápido, porque ninguna parte percibe el texto como impuesto.

Conviene revisar quién firma exactamente: la sociedad concreta, si el acuerdo se extiende a empresas del grupo y si las personas físicas que van a recibir la información (empleados, autónomos, asesores) quedan obligadas a través de la parte firmante.

El objeto del acuerdo debe decir para qué se comparte la información: por ejemplo, «evaluar y, en su caso, ejecutar el desarrollo de una aplicación de gestión de devoluciones». Ese propósito limita el uso permitido: usar la información para otra cosa sería incumplir aunque no se revele a nadie.

La definición de información confidencial es la cláusula más delicada. Hay dos enfoques:

• Por marcado: solo es confidencial lo que se identifica como tal, por escrito o, si se comunica de palabra, confirmado por escrito en un plazo breve. Es preciso, pero exige disciplina y deja fuera lo que se olvide marcar.
• Por naturaleza: es confidencial toda información que una persona razonable entendería como reservada por su contenido o por las circunstancias. Es más protector, pero más difícil de delimitar en caso de conflicto.

Muchos acuerdos combinan ambos enfoques y añaden ejemplos concretos: código fuente, esquemas de bases de datos, credenciales, datos de clientes, documentación técnica, información económica. En la normativa española, la Ley 1/2019 de Secretos Empresariales exige, entre otros requisitos, que el titular haya adoptado medidas razonables para mantener la información en secreto; un NDA firmado antes de compartirla es una de esas medidas, aunque no la única.

Todo NDA razonable excluye ciertos supuestos. No son una debilidad del acuerdo, sino lo que lo hace aplicable. Las exclusiones típicas son:

• Información que ya era pública o lo llega a ser sin culpa de quien la recibe.
• Información que quien la recibe ya conocía legítimamente antes de la revelación, y puede demostrarlo.
• Información desarrollada de forma independiente, sin usar la recibida.
• Información recibida legítimamente de un tercero que no estaba obligado a guardar secreto.
• Revelaciones exigidas por ley, por un tribunal o por una autoridad, normalmente con la obligación de avisar a la otra parte si está permitido y de revelar solo lo imprescindible.

En software, la exclusión por desarrollo independiente importa especialmente. Un proveedor que construye sistemas de gestión de almacenes para varias empresas necesita poder seguir haciéndolo. Lo que no puede es reutilizar las reglas de negocio, los datos o el diseño específico que le has enseñado. La forma de documentarlo es que el proveedor pueda demostrar el origen de su trabajo, por ejemplo con el historial de sus repositorios.

La información tendrá que circular dentro del proveedor: desarrolladores, responsables de proyecto, a veces asesores legales o auditores. El estándar habitual es permitir el acceso a quien lo necesite para el objeto del acuerdo, siempre que esté sujeto a obligaciones de confidencialidad al menos equivalentes.

Los subcontratistas merecen una mención explícita. Si el proveedor va a apoyarse en otra empresa para diseño, pruebas o una parte del desarrollo, el acuerdo debería decir si necesita autorización previa, exigir que el subcontratista firme compromisos equivalentes y dejar claro que el proveedor responde por los incumplimientos de quien subcontrate. Lo mismo vale para servicios en la nube o herramientas externas donde se vaya a alojar la información, incluidas herramientas de IA que procesen documentos o código.

Hay que distinguir dos plazos: el periodo durante el cual se intercambia información bajo el acuerdo y el tiempo que dura la obligación de secreto después. Es frecuente fijar la obligación en varios años tras la última revelación; para secretos empresariales o código fuente puede pactarse que dure mientras la información conserve su carácter confidencial. Un plazo demasiado corto deja desprotegida información que sigue siendo valiosa; uno indefinido para todo puede ser difícil de cumplir y de hacer valer.

Al terminar la relación, el acuerdo debe prever la devolución o destrucción de la información, a elección de quien la reveló, y una confirmación por escrito. Es razonable admitir excepciones para copias de seguridad automáticas que no pueden borrarse selectivamente, siempre que sigan protegidas y no se usen.

Finalmente, la ley aplicable y la jurisdicción o el arbitraje que resolverá conflictos. Entre empresas españolas lo natural es la ley española y los tribunales de una ciudad concreta. Con proveedores de otros países es una cláusula que conviene negociar, porque condiciona el coste real de reclamar.

1. Firma el NDA antes de compartir información sensible, no después de la primera reunión técnica.
2. Comparte solo lo necesario en cada fase: para una propuesta suelen bastar datos anonimizados o de ejemplo.
3. Si el proveedor va a tratar datos personales, añade el contrato de encargo de tratamiento que exija la normativa de protección de datos; el NDA no lo sustituye.
4. Resuelve la propiedad del código y la reutilización de componentes en el contrato de desarrollo, no en el NDA.
5. Pregunta qué herramientas externas y subcontratistas tocarán la información.

Un buen NDA es corto, claro y aplicable. Firmarlo sin leerlo es tan arriesgado como exigir uno tan restrictivo que ningún proveedor serio pueda cumplirlo. Si estás preparando un desarrollo de software a medida, conviene tener el acuerdo listo antes de la primera reunión de análisis y revisado por tu asesor jurídico.