Revisión integral de contratos de TI

Por qué la revisión de contratos de TI es especialmente arriesgada

Los contratos de obra en el ámbito de TI y los contratos de servicios pertenecen a las áreas en las que la realidad jurídica y la técnica chocan con frecuencia. El desarrollador o proveedor de software promete un sistema funcional, pero ¿qué ocurre si el proyecto se retrasa meses? ¿Qué derechos tiene usted si el software no se ajusta a la especificación acordada?

Los abogados del despacho ARROWS se encuentran con casos en los que los órganos de administración de las empresas firmaron un contrato sin una revisión jurídica exhaustiva y más tarde descubrieron graves deficiencias. A menudo se trata de situaciones en las que el proveedor se reservó el derecho de modificar unilateralmente las funcionalidades o la lista de precios sin el consentimiento del cliente.

Otro problema frecuente es la penalización contractual por resolución anticipada del contrato, desproporcionadamente elevada, que en la práctica impide cambiar de proveedor. Una vez firmado el contrato, su posición negociadora se debilita drásticamente y los cambios son difíciles de imponer. Por ello, en los contratos de TI tiene sentido abordar la configuración de los procedimientos de cambio, las cláusulas de salida y las sanciones en el marco de contratos y negociación.

Principales riesgos jurídicos en los contratos de TI

Indeterminación del alcance de los trabajos

El scope (objeto de la prestación) es la parte más importante del contrato, pero también la fuente más frecuente de litigios. Si el anexo técnico no define con precisión qué forma parte de la implementación y qué corresponde ya a un desarrollo de pago, surgen conflictos.

Un caso típico se da a menudo cuando el contrato indica «implementación del sistema de información», pero no aborda la migración de datos históricos ni la integración con API de terceros, lo que después lleva a la facturación de trabajos adicionales.

Los abogados del despacho ARROWS recomiendan estructurar el contrato por fases de análisis, diseño, desarrollo, pruebas, despliegue y estabilización, definiendo en cada fase entregables concretos.

Ausencia de SLA o SLA inexigible

El SLA es un parámetro de calidad del servicio jurídicamente vinculante que define los tiempos de respuesta, el tiempo de resolución de incidencias y la disponibilidad garantizada. Sin un SLA de calidad no tiene una posibilidad práctica de exigir el cumplimiento. Si el proveedor incurre reiteradamente en mora o incumple el SLA, suele ser oportuno evaluar también la estrategia procesal, incluidas las pruebas y las pretensiones, lo que forma parte del ámbito de litigios mercantiles y judiciales.

Un SLA eficaz contiene:

• Tiempo de respuesta : Plazo en el que el proveedor debe confirmar la recepción de la incidencia.
• Tiempo de resolución : Plazo máximo para eliminar el defecto o proporcionar una solución alternativa.
• RTO y RPO : Tiempo máximo admisible de interrupción y pérdida máxima admisible de datos.
• Disponibilidad : Porcentaje garantizado del tiempo en que el sistema está en funcionamiento.
• Sanciones : Penalizaciones contractuales o descuentos concretos por incumplimiento de los parámetros.

Responsabilidad por los datos y la seguridad

Se trata de un límite jurídico que las partes deben delimitar con claridad. Un incidente de seguridad tiene no solo consecuencias técnicas, sino también jurídicas conforme al RGPD y a la Ley de Ciberseguridad checa (en adelante «ZKB»). El marco práctico para la configuración contractual de los roles de responsable y encargado del tratamiento y para minimizar los riesgos al involucrar a terceros lo resume también la novedad Plataforma SaaS en la UE: tratamiento jurídico de las condiciones generales, el RGPD y los acuerdos de licencia para resultados de IA.

Un problema jurídico típico surge cuando el contrato establece que el proveedor no responde por la pérdida de datos. Tal disposición puede ser contraria a las disposiciones imperativas del Código Civil checo (Ley n.º 89/2012 Sb., en adelante «CC») sobre la indemnización de daños. Debe tener definido:

• Estándares de seguridad : Obligación de cumplir normas concretas.
• Cooperación ante incidentes : Obligación del proveedor de notificar los incidentes sin demora.
• Copias de seguridad y recuperación : Reglas para las copias de seguridad y las pruebas de recuperación.
• Seguro : Obligación del proveedor de contar con un seguro de responsabilidad profesional.

Propiedad intelectual y vendor lock-in

¿Quién ejerce los derechos patrimoniales sobre el código resultante, el diseño y las bases de datos? Según la Ley de Derechos de Autor checa (en adelante «LDA»), salvo pacto en contrario, el autor concede únicamente una licencia de uso de la obra, no el derecho a modificarla.

Imagine una situación en la que, años después, quiere modernizar el sistema, pero el proveedor original ya no existe y usted no tiene acceso a los códigos fuente, con lo que cae en la trampa del llamado vendor lock-in.

Los abogados de ARROWS recomiendan negociar una licencia lo más amplia posible con derecho a realizar modificaciones y, en el software a medida, insistir en la entrega de los códigos fuente o en el uso del depósito de código (escrow). Las consecuencias prácticas de unas relaciones contractuales mal configuradas y la prevención de futuros litigios se desarrollan también en la novedad Prevención de litigios en un holding: configuración de las relaciones contractuales entre sociedades vinculadas.

Procedimiento de aceptación

El momento de la aceptación es jurídicamente clave, porque con él se transmite el riesgo de daño sobre la cosa y empieza a correr el plazo de garantía. Si el contrato no contiene criterios objetivos, el proveedor puede afirmar que la obra está terminada aunque el sistema presente defectos.

El enfoque correcto incluye:

• Criterios de aceptación : Lista de condiciones que el sistema debe cumplir.
• Pruebas de aceptación : Derecho del cliente a realizar pruebas en un plazo razonable.
• Categorización de defectos : División de los defectos en críticos y menores.
• Pagos condicionados : Vinculación de la última parte del precio a la firma satisfactoria del acta.

Proceso de escalado y resolución de controversias

Durante la implementación pueden surgir desacuerdos y, sin un proceso definido, la controversia suele agravarse innecesariamente. Un buen contrato contiene niveles de resolución que van desde el escalado al comité de dirección, pasando por la mediación, hasta el procedimiento judicial.

Los abogados del despacho ARROWS señalan que un escalado bien configurado ahorra a menudo meses de tiempo y cientos de miles de coronas en tasas judiciales.

Procedimiento práctico en la revisión de un contrato de TI

Fase 1: Auditoría jurídica

Antes de cambiar nada, es necesario identificar los riesgos. Los abogados de ARROWS analizan el borrador del contrato y señalan los puntos críticos que son contrarios a sus intereses o a la legislación vigente. Un ejemplo puede ser una cláusula inaceptable que limita la indemnización de daños a una cantidad simbólica.

Fase 2: Negociación y observaciones

Los proveedores afirman a menudo que utilizan «plantillas corporativas estándar» que no pueden modificarse. La experiencia de ARROWS demuestra que todo contrato es negociable, especialmente si se argumenta con la conformidad con la legislación checa y la simetría de derechos y obligaciones.

Fase 3: Finalización y firma

Los cambios se incorporan mediante revisiones o adendas. Es importante garantizar que los anexos técnicos no contradigan la parte jurídica principal del contrato, un error frecuente al completar la documentación.

Seguridad y RGPD en los contratos de TI

La implementación de software implica casi siempre el acceso a datos personales. Si el proveedor accede a los datos de sus clientes o empleados, se convierte en encargado del tratamiento y es necesario celebrar un contrato de encargo del tratamiento.

Si el proveedor accede a los datos personales de sus clientes o empleados, se convierte, conforme al art. 28 del RGPD, en encargado del tratamiento y usted debe celebrar con él un contrato de encargo del tratamiento.

El contrato debería garantizarle el derecho a realizar una auditoría de seguridad en el proveedor, lo que exige también la Directiva NIS2, transpuesta a la ZKB.

El plazo contractual para que el proveedor notifique un incidente de seguridad debe ser inferior a 72 horas, para que usted, como responsable del tratamiento, pueda cumplir a tiempo su obligación legal frente a la autoridad de control.

Situaciones específicas y elementos clave

Cloud vs. on-premise

En la nube (SaaS) son clave la disponibilidad, la ubicación del almacenamiento de datos y el proceso de exit management, es decir, cómo recuperará sus datos al terminar el contrato. En este caso, los datos se almacenan en el proveedor, lo que exige garantías específicas.

En las soluciones on-premise, es decir, instaladas en su propia infraestructura, es determinante el alcance de la licencia (perpetua o temporal). Además, es necesario regular la garantía de la obra y el mantenimiento, lo que incluye el derecho a nuevas versiones y parches de seguridad.

Desarrollo ágil vs. Waterfall

El método Waterfall se caracteriza por un alcance, un precio y un plazo fijos, y jurídicamente suele tratarse como un contrato de obra con énfasis en la aceptación del conjunto. Es adecuado para proyectos claramente definidos.

El desarrollo ágil es jurídicamente más complejo, porque a menudo se factura según el tiempo registrado. Aquí es necesario regular contractualmente el derecho del cliente a cambiar prioridades, la definición de tarea terminada y el mecanismo de tope presupuestario, para que el proyecto no se encarezca desproporcionadamente.

Cómo proceder ante problemas durante la implementación

Si descubre que el contrato es desventajoso ya en el curso del proyecto, intente negociar una adenda al contrato. A menudo es posible intercambiar una concesión en el calendario por un endurecimiento del SLA o por la incorporación de la licencia que falta.

Si el proveedor incumple, es necesario reclamar formalmente los defectos de conformidad con el contrato y la ley, ya que la documentación es clave para un eventual litigio. Si el incumplimiento es esencial, el CC permite resolver el contrato, aunque se trata de una solución extrema que requiere un análisis.

Los abogados del despacho ARROWS le ayudarán a analizar la situación y a elegir la estrategia que minimice los daños.

Resumen final

La revisión de un contrato de TI es un elemento básico de la gestión de riesgos que protege la inversión en tecnología frente a defectos jurídicos. Estos pueden resultar, al final, más costosos que el propio software.

El riesgo típico de ignorar esta cuestión incluye la firma del contrato sin revisión, el consiguiente vendor lock-in, la imposibilidad de migrar los datos y elevados costes de litigios en caso de fallo del proveedor.

Los abogados del despacho ARROWS están especializados en Derecho de las TI y propiedad intelectual. Nuestro objetivo no es solo la corrección jurídica, sino sobre todo la funcionalidad comercial y la exigibilidad del contrato en la práctica.

Si planea un proyecto de TI o necesita revisar sus relaciones contractuales actuales, el despacho de abogados ARROWS le ayudará a establecer condiciones justas y seguras. Contáctenos en consultas@arws.cz para una consulta sin compromiso.