Serie pyme · Todo depende de la calificación: según cómo se califique el caso, tienes cuatro días o tienes cinco años
La mayoría de las reclamaciones contra proveedores tecnológicos no se pierden por el fondo. Se pierden por el plazo. Y el plazo no está escrito en el contrato: depende de cómo se califique jurídicamente lo que ha pasado, que es la primera pregunta del caso y casi nunca la primera que se hace.
La horquilla es enorme. Según cómo se califique el mismo hecho, el plazo va de cuatro días a cinco años.
Primera decisión: ¿es un defecto o es otra cosa?
Esta es la pregunta decisiva, y conviene hacerla antes que ninguna otra.
Si lo entregado sirve pero tiene defectos, estamos en el terreno del saneamiento, con plazos cortos. Si lo entregado es sustancialmente distinto de lo pactado o inhábil para el fin del contrato, no hay defecto: hay entrega de cosa distinta, lo que la jurisprudencia llama aliud pro alio. Y entonces no se aplican los plazos cortos del saneamiento, sino el incumplimiento contractual ordinario de los artículos 1101 y 1124 del Código Civil, con la prescripción general de cinco años.
La diferencia práctica es casi todo el caso. Un ERP que se implanta y no permite emitir facturas conformes, un sistema que no soporta el volumen para el que se contrató, un software que no realiza la función que se compró: eso no es un vicio oculto, es otra cosa distinta de la pactada. Y muchos proyectos tecnológicos fracasados pueden encajar en ese supuesto, no en el de los plazos breves.
Dicho de otro modo: antes de alarmarse con los cuatro días, hay que preguntarse si el supuesto es de defecto o de inhabilidad.
Segunda decisión: qué contrato es, y si realmente hay compraventa
No existe el «contrato tecnológico». Hay tres familias, y la calificación arrastra el régimen.
El contrato de obra —implantación de un ERP, desarrollo a medida, migración— es el más favorable al cliente, porque el proveedor compromete un resultado: no cumple entregando horas y esfuerzo, cumple entregando un sistema que funciona.
El arrendamiento de servicios —mantenimiento, soporte, un SaaS por suscripción— es incumplimiento contractual ordinario, con la prescripción general de cinco años del artículo 1964.2 del Código Civil. No hay plazos breves.
La compraventa mercantil de mercaderías es donde están los plazos cortos, y conviene no aplicarlos a la ligera. El artículo 336 del Código de Comercio da cuatro días desde la recepción para reclamar por defectos de cantidad o calidad cuando la mercancía se recibe enfardada o embalada, y niega la acción por defectos visibles al comprador que examinó la mercancía al recibirla y la aceptó. El artículo 342 da treinta días desde la entrega para reclamar los vicios internos, y es un plazo de caducidad: transcurrido, el derecho se pierde.
Pero ese régimen presupone que lo entregado es una mercadería, y eso dista de ser evidente en materia informática. Es claro para el hardware. Es discutible para una licencia de software, y no se sostiene para un servicio en la nube, que no es entrega de cosa alguna. Antes de dar por aplicable el artículo 342 conviene mirar si de verdad hubo compraventa de mercaderías o si el negocio era otro.
Y una precisión sobre el artículo 1490 del Código Civil: los seis meses que establece son el plazo de las acciones de saneamiento por vicios ocultos, que se aplica de modo subsidiario en la compraventa mercantil. No es un techo para una acción de incumplimiento ordinario, ni se extiende a los supuestos de aliud pro alio.
El problema añadido es que la mayoría de los contratos tecnológicos son mixtos: un ERP se compra, se implanta y se mantiene. Tres tramos, tres regímenes. Y el proveedor alegará que lo que falló era el tramo del plazo más corto.
Tercera decisión: qué se reclama
El artículo 1124 permite elegir entre exigir el cumplimiento o resolver, en los dos casos con indemnización. La elección no es neutra: resolver obliga a montar el sistema otra vez con otro proveedor y a soportar ese coste; exigir el cumplimiento mantiene atado a quien ya ha fallado.
La indemnización cubre daño emergente y lucro cesante, conforme al artículo 1106, con el límite de previsibilidad del artículo 1107 —salvo dolo, en el que el deudor responde de todos los daños que conocidamente se deriven del incumplimiento—.
El lucro cesante es donde se pierde el dinero. La jurisprudencia exige certeza, no hipótesis: «habríamos facturado un veinte por ciento más» no se indemniza. Lo que sí, si está documentado, es el pedido concreto que se perdió, la penalización que hubo que pagar al propio cliente, el coste del proveedor sustituto, las horas que la plantilla dedicó a suplir el fallo. La diferencia entre una reclamación cobrada y una desestimada suele estar en esa lista.
Cuarta decisión: qué dice la cláusula de limitación
Casi todos los contratos tecnológicos limitan la responsabilidad al importe facturado en los últimos doce meses o a créditos de servicio del acuerdo de nivel de servicio. Entre empresarios, estas cláusulas son, en principio, válidas, sin perjuicio de los límites legales y de las circunstancias de cada caso.
Dos excepciones que hay que mirar siempre. El dolo: el artículo 1102 declara nula la renuncia anticipada a la acción para exigir responsabilidad por dolo, de modo que si el proveedor sabía que el sistema no iba a hacer lo prometido y lo vendió igual, la cláusula no le cubre. Y los créditos de servicio, que operan como cláusula penal: si son la única consecuencia pactada, hay que discutir si excluyen la indemnización general o se acumulan, con el artículo 1154 como herramienta de moderación.
Lo que hay que hacer, y en este orden
Congelar la prueba antes que nada. En un servicio en la nube, la prueba del fallo está en el servidor del proveedor y puede desaparecer al cursar la baja. No canceles el servicio sin haber extraído y conservado antes los registros, los tickets y el histórico de versiones.
Requerimiento fehaciente y fechado, con descripción del incumplimiento y plazo de subsanación. Y aquí una advertencia importante: el requerimiento extrajudicial interrumpe la prescripción, conforme al artículo 1973, pero no interrumpe la caducidad. Si el supuesto es de vicios internos del artículo 342, los treinta días corren igual aunque se haya enviado una carta impecable. El requerimiento sirve, además, para constituir en mora conforme al artículo 1100; lo que no hace es generar automáticamente intereses, porque los del artículo 1108 se refieren a obligaciones de pago de una cantidad de dinero, y una indemnización no es cantidad líquida hasta que se determina.
Cuantificar con documentos. Facturas, pedidos, correos de clientes, partes de horas. Una estimación sin soporte no es una reclamación, es una queja.
Y la pericial informática. Si el pleito va a decidir si el sistema cumplía la funcionalidad pactada, el informe del perito decide el caso. Lo que el perito necesita es la documentación contractual de requisitos.
El error que está detrás de casi todas las reclamaciones perdidas
Y ahí está el problema de fondo. En la mayoría de los proyectos no existe ningún documento que diga qué tenía que hacer el sistema. Hay una propuesta comercial con capturas de pantalla, una cadena de correos y un pliego que nadie firmó ni anexó al contrato.
Sin requisitos documentados no solo es difícil probar el incumplimiento: es difícil incluso calificarlo, porque la frontera entre un defecto y una cosa distinta de la pactada se traza comparando lo entregado con lo prometido. Si no hay constancia de lo prometido, no hay aliud pro alio que alegar, y entonces sí aparecen los plazos breves.
De modo que la reclamación se gana o se pierde en la fase de contratación, no en la de pleito. Anexar los requisitos funcionales, fijar criterios de aceptación medibles y acordar quién prueba qué cuesta una tarde, y es lo que decide si el día del conflicto tienes cuatro días o cinco años.
Este artículo tiene carácter divulgativo y no constituye asesoramiento jurídico. La calificación del contrato y del supuesto depende de cada caso concreto, y de ella dependen los plazos: conviene examinarla antes de reclamar.