1) Por qué aparecen las disputas en proyectos IT

En IT, muchas controversias contractuales no nacen por “falta de voluntad”, sino por diferencias sobre lo que se prometió y cuándo se consideró cumplido. Tres focos se repiten: (i) el alcance de los entregables, (ii) el tratamiento contractual de los cambios (scope creep) y (iii) la aceptación como mecanismo de cierre del ciclo de trabajo.

Cuando el contrato no fija de forma operativa el “qué”, “cómo”, “con qué evidencia” y “qué ocurre si no hay respuesta”, el desacuerdo se desplaza desde la ejecución hacia la prueba. Y ahí suele perder quien no definió criterios y procedimientos.

2) Entregables: alcance, evidencia y expectativas realistas

Las disputas sobre entregables suelen concentrarse en cuatro preguntas:

1. Alcance: ¿El entregable incluye documentación, instrucciones de operación, soporte de traspaso o solo el artefacto técnico?
2. Definición: ¿Existe un criterio objetivo que identifique el entregable (versión, módulos, datos, endpoints, scripts, informes)?
3. Evidencia: ¿Qué prueba se entrega para verificar el cumplimiento? Por ejemplo, actas de revisión, logs, casos de prueba, checklist de requisitos, y trazabilidad a requerimientos.
4. Condición: ¿Está sujeto a dependencias o supuestos (accesos, entorno, datos de muestra, políticas de seguridad)?

Un consejo práctico: redactar el entregable como una “unidad verificable”. Si no se puede verificar con materiales y criterios acordados, el entregable se vuelve discutible.

3) Cambios: cómo evitar que el “cambio” sea un arma de doble filo

En proyectos IT, los cambios son normales. Lo que no debe normalizarse es que un cambio se ejecute sin que el contrato lo “absorba” formalmente. Cuando una parte realiza trabajo adicional, la otra puede discutir si formaba parte del alcance original o si requería ajuste de precio, calendario o condiciones.

Para gestionar cambios sin fricción, suelen funcionar bien estos elementos:

• Procedimiento de solicitud (quién pide, cómo se documenta y en qué plazos).
• Evaluación de impacto (coste, calendario, dependencias, riesgos y requisitos de seguridad).
• Trazabilidad (referenciar el cambio a requerimientos, tickets o anexos).
• Aprobación (firma o validación por las personas con autoridad definida).

La clave legal y operativa es mantener el cambio en un carril contractual. Si no existe carril, el conflicto se traslada a la interpretación.

4) Aceptación: plazos, criterios y efectos de “silencio”

La aceptación suele ser el punto de quiebre. Dos escenarios aparecen con frecuencia:

• Aceptación tardía o discutida: se retrasa la revisión, o el cliente alega problemas cuando ya debería haberse activado un procedimiento de corrección.
• Silencio del cliente: se debate si la falta de respuesta equivale a aceptación o, por el contrario, si la entrega queda indefinidamente abierta.

Para minimizar disputas, conviene que el contrato establezca:

1. Plazos de revisión y mecanismo de notificación de incidencias.
2. Criterios verificables (por ejemplo, conformidad con requisitos funcionales y no funcionales, criterios de seguridad, rendimiento mínimo, y resultados de pruebas).
3. Rondas de corrección (qué ocurre si hay no conformidades y en qué condiciones se reabre la aceptación).
4. Efectos: qué implica aceptarse (facturación, garantía, arranque de soporte) y qué ocurre si hay incumplimiento de criterios.

Este diseño evita que la aceptación funcione como una “palanca” para renegociar el proyecto cuando ya se ha ejecutado.

Checklist rápido para reducir riesgo contractual

Para seguir leyendo

Si te interesa aplicar esta lógica a otros contratos IT, consulta estos artículos relacionados:

• Licencias de software en la práctica: cómo documentar el uso para tu cliente
• Guía para IT: contratos de prestación de servicios digitales y alcance del entregable
• Guía de auditoría legal para empresas IT: qué revisar en licencias, SOW y anexos