Guerra de software: cómo resolver disputas legales entre desarrolladoras y clientes sin morir en el intento

Según datos del Standish Group, más del 70% de los proyectos de software no cumplen con los plazos, el presupuesto o las funcionalidades acordadas. Detrás de esa cifra hay algo que pocas veces se menciona en los informes técnicos: conflictos legales. Retrasos que se convierten en reclamaciones, código fuente cuya titularidad nadie definió por escrito y niveles de servicio que jamás se formalizaron en un SLA. Cuando la relación entre una empresa desarrolladora y su cliente se rompe, el daño no es solo económico; también afecta a la continuidad operativa, a la reputación y, en un sector donde la confianza lo es todo, a la capacidad de cerrar futuros contratos. Lo que muchos responsables de pymes tecnológicas no saben es que la mayoría de estas disputas pueden prevenirse —o al menos resolverse de forma ágil— con el asesoramiento adecuado. Despachos especializados como eDefense, abogados de derecho digital llevan años gestionando este tipo de conflictos, donde el conocimiento técnico del negocio IT resulta tan decisivo como el jurídico.

La experiencia demuestra que la mayoría de las disputas en proyectos de software no surgen de fallos técnicos, sino de ambigüedades contractuales. El patrón más frecuente es también el más evitable: un proyecto que arranca con un presupuesto aceptado por correo electrónico, sin un contrato que defina con precisión el alcance funcional, los criterios de aceptación, la titularidad del código o las condiciones de resolución.

Cuando el cliente pide funcionalidades adicionales que no estaban contempladas —lo que en el sector se conoce como scope creep o deriva funcional— y la desarrolladora las ejecuta sin formalizar un addendum, se genera una zona gris que solo se hace visible cuando algo falla. ¿Se ha entregado lo pactado o no? Sin un documento de especificaciones funcionales firmado, la respuesta depende de la interpretación de cada parte.

Otro foco habitual de conflicto es la propiedad intelectual del código fuente. La Ley de Propiedad Intelectual española (Real Decreto Legislativo 1/1996) protege el software como obra intelectual desde el momento de su creación. Pero eso no resuelve la pregunta clave: ¿pertenece al programador que lo escribió, a la empresa desarrolladora que lo empleó o al cliente que financió el proyecto? Sin una cláusula de cesión de derechos de explotación expresamente redactada, la titularidad por defecto puede no coincidir con lo que las partes asumieron.

Un contrato de desarrollo de software bien redactado no es un trámite burocrático; es una herramienta de ciberseguridad jurídica. Del mismo modo que ninguna empresa despliega un sistema en producción sin un plan de contingencia, ningún proyecto debería iniciarse sin una arquitectura contractual que cubra, como mínimo, los siguientes puntos críticos:

Objeto y alcance preciso del encargo. Definir si se trata de un desarrollo a medida, una integración con sistemas existentes, un producto SaaS o una consultoría. El anexo de especificaciones funcionales y técnicas es tan importante como el cuerpo del contrato, ya que establece los entregables concretos y los criterios de validación.

Cesión de derechos de propiedad intelectual. Debe quedar explícito qué derechos de explotación —reproducción, distribución, transformación, comunicación pública— se ceden al cliente y cuáles retiene la desarrolladora (por ejemplo, sobre librerías propias reutilizables). La falta de esta cláusula es, probablemente, la causa número uno de litigios en el sector.

Acuerdos de nivel de servicio (SLA). Para proyectos que incluyan mantenimiento o soporte posterior, las métricas de disponibilidad, tiempos de respuesta y penalizaciones por incumplimiento deben formalizarse por escrito. Un SLA ambiguo es peor que no tener ninguno, porque genera una falsa sensación de seguridad.

Confidencialidad y protección de datos. En proyectos donde la desarrolladora accede a datos personales del cliente o de sus usuarios, el contrato debe incluir un acuerdo de encargado de tratamiento conforme al artículo 28 del RGPD. La ausencia de este documento no solo genera riesgo jurídico; puede derivar en sanciones directas de la Agencia Española de Protección de Datos.

Cláusula de resolución de disputas. Establecer un procedimiento escalonado —negociación directa, mediación y, como último recurso, arbitraje o jurisdicción ordinaria— evita que cualquier desacuerdo escale directamente a los tribunales, un proceso costoso y lento para ambas partes.

No todos los conflictos se pueden prevenir. A veces, pese a un contrato razonablemente bien redactado, las partes interpretan sus obligaciones de forma diferente. En esos casos, actuar con rapidez y con el asesoramiento correcto marca la diferencia entre un problema gestionable y un litigio que se prolonga durante años.

El primer paso suele ser la reclamación extrajudicial: una comunicación formal, con validez jurídica, en la que se expone el incumplimiento y se requiere su subsanación en un plazo determinado. Este paso, que muchas empresas tecnológicas omiten por desconocimiento o por creer que “es solo una carta”, tiene un efecto disuasorio notable. En la práctica, un porcentaje significativo de las disputas se resuelven en esta fase, especialmente cuando la comunicación está respaldada por un análisis técnico-jurídico sólido que demuestra al contrario la debilidad de su posición.

Si la vía extrajudicial no prospera, la mediación tecnológica se ha consolidado como una alternativa eficaz en España. A diferencia de un procedimiento judicial, la mediación permite que ambas partes expongan sus posiciones ante un tercero neutral con conocimiento del sector, lo que acelera la resolución y, en muchos casos, permite preservar la relación comercial. No es una opción menor: la Ley 5/2012, de mediación en asuntos civiles y mercantiles, dota al acuerdo alcanzado de fuerza ejecutiva si se eleva a escritura pública.

El último recurso es el procedimiento judicial. Los litigios civiles y mercantiles vinculados a contratos tecnológicos presentan una complejidad añadida: el juez debe evaluar cuestiones técnicas —como si un código cumple o no con las especificaciones funcionales— que requieren informes periciales informáticos. Aquí es donde contar con abogados que entienden tanto la vertiente legal como la realidad operativa del sector IT supone una ventaja competitiva real, no un mero argumento comercial.

Hay un aspecto de las disputas entre desarrolladoras y clientes que rara vez se aborda y que tiene implicaciones directas de ciberseguridad: ¿qué ocurre con los accesos y los datos cuando la relación se rompe?

Un desarrollador externo que ha tenido acceso a servidores, repositorios de código, bases de datos con información personal o credenciales de servicios cloud durante el proyecto representa un riesgo si la separación no se gestiona de forma ordenada. El contrato debe prever un protocolo de offboarding técnico que incluya la revocación de accesos, la devolución o destrucción certificada de datos y la transferencia ordenada de documentación técnica.

No es un escenario teórico. Empresas que han roto relaciones con proveedores tecnológicos sin formalizar la transición se han encontrado con repositorios inaccesibles, credenciales bloqueadas o, en los peores casos, con datos de sus clientes en manos de un tercero con el que ya no existe relación contractual. La normativa NIS2, en vigor desde octubre de 2024 para entidades esenciales e importantes, refuerza la obligación de gestionar la seguridad de la cadena de suministro TIC, lo que incluye expresamente la relación con proveedores de software.

Más allá de las disputas entre desarrolladoras y clientes, existe otro tipo de conflicto que afecta a miles de empresas cada año en España: las reclamaciones de los grandes fabricantes de software por uso ilícito de licencias. Compañías como Microsoft, Adobe, Autodesk o SAP realizan auditorías periódicas y, cuando detectan indicios de uso no autorizado, envían reclamaciones extrajudiciales que pueden derivar en indemnizaciones considerables.

Muchas de estas reclamaciones llegan a empresas que no eran conscientes del incumplimiento: licencias adquiridas por un empleado anterior que nunca se regularizaron, instalaciones de evaluación que se quedaron activas tras el periodo de prueba o discrepancias entre el número de puestos contratados y los realmente desplegados. Contar con un asesoramiento especializado desde el momento en que se recibe la primera comunicación del fabricante es clave para negociar con criterio y evitar pagar más de lo estrictamente debido.

El sector tecnológico español madura a buen ritmo, pero su cultura contractual no siempre avanza al mismo paso. La velocidad a la que se cierran acuerdos, se inician desarrollos y se despliegan soluciones no debería estar reñida con la seguridad jurídica. Un contrato sólido, revisado por profesionales que entienden cómo funciona realmente un proyecto de software, no frena un negocio: lo protege.

Para las pymes tecnológicas —el tejido mayoritario del sector en España—, invertir en prevención legal no es un lujo reservado a grandes corporaciones. Es, probablemente, la decisión más rentable que pueden tomar antes de que la próxima disputa, que estadísticamente es cuestión de tiempo, les estalle entre las manos.