NDA en proyectos tecnológicos: cláusulas y errores frecuentes

Los fragmentos siguientes son ejemplos hipotéticos pensados para un proyecto de software. Sirven para ver qué nivel de concreción conviene, no para copiarlos tal cual.

• Finalidad: «La Parte Receptora utilizará la Información Confidencial exclusivamente para evaluar la viabilidad técnica y económica de una aplicación de planificación de rutas y, en su caso, preparar una propuesta». Limitar la finalidad impide usos laterales, como reutilizar el análisis para otro cliente.
• Información que se observa: «Tendrá también la consideración de Información Confidencial la que la Parte Receptora conozca al acceder a sistemas, instalaciones o entornos de la Parte Reveladora, aunque no se le entregue por escrito». En proyectos tecnológicos se aprende mucho mirando pantallas y reuniones de demostración.
• Necesidad de conocer: «El acceso se limitará al personal que lo necesite para la finalidad, que estará sujeto a obligaciones de confidencialidad no menos estrictas que las de este Acuerdo». Es preferible a listar nombres, que cambian durante el proyecto.
• Servicios externos: «No se cargará Información Confidencial en servicios de terceros, incluidos los de inteligencia artificial, salvo los autorizados por escrito por la Parte Reveladora». Sin esta frase, el acuerdo calla sobre algo que hoy ocurre a diario.
• Medidas de protección: «La Parte Receptora aplicará a la Información Confidencial medidas no inferiores a las que aplica a su propia información de naturaleza similar y, como mínimo, control de accesos y almacenamiento cifrado». Una referencia concreta evita discutir qué es «razonable».
• Aviso de incidente: «La Parte Receptora comunicará sin demora cualquier acceso o revelación no autorizados de los que tenga conocimiento y colaborará para limitar sus efectos».
• Sin licencia ni obligación de contratar: «Nada en este Acuerdo concede licencia sobre derechos de propiedad intelectual o industrial ni obliga a las partes a celebrar un contrato posterior». Aclara que firmar el NDA no compromete a encargar el proyecto.

Son los dos tipos de información donde el NDA genérico se queda más corto, porque no basta con decir que son confidenciales: hay que decidir cómo se comparten.

Con el código fuente existente, lo prudente es compartir solo lo necesario para la fase en curso. Para valorar la modernización de una aplicación puede bastar con acceso de lectura temporal a un repositorio o con un extracto, sin derechos de escritura ni copias locales permanentes. El acuerdo puede prever que el acceso se dé mediante cuentas nominales, que se revoque al acabar la evaluación y que no se conserven clones. Si el proveedor también enseña código propio (una librería, un componente previo), la cláusula debería funcionar en ambos sentidos.

Con los datos de prueba, el punto clave es que un NDA no habilita por sí solo a tratar datos personales. Si el proveedor va a recibir datos reales de clientes o empleados, hace falta además el contrato de encargo de tratamiento que exige el artículo 28 del Reglamento general de protección de datos, con su contenido mínimo: instrucciones documentadas, confidencialidad del personal, medidas de seguridad, supresión o devolución al terminar, entre otros. En la fase de propuesta lo habitual es no llegar a eso: datos sintéticos, muestras seudonimizadas o un volumen reducido preparado por el propio cliente.

• Credenciales: nunca dentro de documentos compartidos; si hacen falta, cuentas específicas, con caducidad y revocadas al terminar.
• Entornos de demostración: si el proveedor monta una demo con información del cliente, el acuerdo debe aclarar dónde se aloja y cuándo se destruye.
• Resultados de una prueba de concepto: el NDA protege lo que se revela, pero no dice de quién es lo que se construye. Eso va en el contrato de la prueba.

Muchos problemas nacen de pedir al NDA cosas que no le corresponden, o de dar por resuelto en el NDA algo que debía estar en el contrato de desarrollo.

Cuando se firma el contrato de desarrollo, conviene que diga qué pasa con el NDA anterior: si queda sustituido por la cláusula de confidencialidad del contrato, si sigue vigente para la información compartida antes, o ambas cosas. Dos textos con definiciones distintas de lo que es confidencial generan dudas innecesarias.

• Firmar tarde: la primera reunión técnica ya incluye diagramas, nombres de sistemas y problemas internos. El acuerdo debería estar firmado antes.
• Usar una plantilla de otro ámbito: un NDA pensado para una operación societaria no prevé accesos a sistemas, repositorios ni herramientas en la nube.
• Definición sin límites: declarar confidencial «toda información de cualquier tipo» parece proteger más, pero dificulta demostrar qué se incumplió y puede chocar con el conocimiento general del proveedor.
• Omitir la finalidad: sin un objeto concreto, cualquier uso que no sea revelación queda en zona gris.
• Callar sobre servicios de terceros: alojamiento, mensajería, gestores de tareas o herramientas de IA reciben información a diario.
• Meter en el NDA lo que no es confidencialidad: cesiones de propiedad intelectual, exclusividades o penalizaciones desproporcionadas que bloquean la firma y retrasan el proyecto.
• No controlar lo entregado: si nadie registra qué se compartió y con quién, la devolución o destrucción al final es imposible de verificar.
• Firmas sin poder suficiente: comprobar que quien firma puede obligar a la sociedad.

1. ¿La finalidad describe el proyecto concreto y no un uso abierto?
2. ¿Cubre la información observada en accesos y demostraciones, no solo la entregada por escrito?
3. ¿Dice algo sobre servicios externos, incluidas herramientas de IA?
4. ¿Están previstos cómo se comparten el código y los datos de prueba, y cómo se retiran esos accesos?
5. Si habrá datos personales, ¿hay un encargo de tratamiento además del NDA?
6. ¿Quedan fuera del NDA la propiedad del código, la aceptación y los plazos, para regularlos en el contrato?
7. ¿Se registra qué información se ha entregado y a quién?

Un acuerdo bien adaptado a un proyecto tecnológico suele ser breve y preciso, y se negocia rápido porque ninguna parte siente que firma algo imposible de cumplir. Si vas a encargar un desarrollo de software a medida, podemos revisar contigo qué información conviene compartir en cada fase para que el acuerdo y la forma de trabajar encajen.