El perito informatico en procedimientos mercantiles: disputas SaaS 2026

TL;DR: resumen rápido

Las disputas tecnologicas entre empresas ya no se resuelven con un apreton de maños

Llevo años como perito informático forense y los procedimientos mercantiles son el area que más ha crecido en mi práctica profesional. No es una sorpresa: el gasto en SaaS por empresa en España alcanzo los 64.000 euros anuales de medía en 2025 según Gartner, y cada contrato que se firma es una potencial disputa judicial esperando a ocurrir.

Lo que veo en mi despacho es un patrón repetido. Una empresa contrata un SaaS que promete transformar su negocio. El proveedor no cumple lo pactado: el software no funciona como debería, los datos no se pueden exportar, el rendimiento es inferior al SLA contratado, o directamente el proveedor cierra y los datos quedan inaccesibles. La empresa se queda con un contrato incumplido, un negocio parado y la necesidad de un perito que pueda explicar a un juez mercantil que es exactamente lo que ha fallado y cuanto vale el perjuicio.

Pero no todo son SaaS. Tambien recibo casos de robo de propiedad intelectual entre socios que se separan, due diligence tecnologica en operaciones de compraventa de empresas que se tuercen, y disputas sobre SLAs que nadie se molesto en definir con precision. En todos estos casos, el perito informático es la pieza que traduce la realidad técnica al lenguaje que entiende un juzgado de lo mercantil.

Disputas por contratos SaaS: análisis en profundidad

Los 7 tipos de incumplimiento contractual SaaS más frecuentes

En mi experiencia pericial, las disputas SaaS se agrupan en siete categorías principales. Cada una requiere un enfoque técnico diferente y genera un tipo de informe pericial distinto.

1. Incumplimiento de funcionalidad prometida

Es el caso más común. El proveedor SaaS presento una demo con funcionalidades que luego no existen en el producto real, o existen pero no funcionan como se mostro. En terminos jurídicos, estamos ante un incumplimiento del artículo 1258 del Código Civil (buena fe contractual) y potencialmente ante un vicio oculto regulado en los artículos 1484 y siguientes.

Lo que hago como perito en estos casos:

• Análisis de la demo original: Si la demo fue grabada o si existe documentación pre-contractual (presentaciones, emails, videos), comparo funcionalidad por funcionalidad con el producto entregado.
• Pruebas funcionales sistematicas: Ejecuto test cases basados en los requisitos contractuales. Documento cada funcionalidad que no existe, que falla o que difiere de lo prometido.
• Cuantificacion del gap: Clasifico las discrepancias por severidad (crítica, alta, media, baja) y calculo el porcentaje de funcionalidad entregada respecto a la prometida.
• Impacto en el negocio: Documento como cada funcionalidad faltante afecta a los procesos de negocio del cliente.

2. Rendimiento inferior al contratado

El software funciona pero va lento. Las páginas tardan 15 segundos en cargar, los informes que deberían generarse en minutos tardan horas, la API no aguanta la carga de usuarios contratada. Estos casos requieren un análisis de rendimiento riguroso.

Mi metodología:

• Definicion de baseline: Establezco los parametros de rendimiento contratados en el SLA.
• Pruebas de carga: Utilizo herramientas como JMeter, k6 o Gatling para simular la carga de usuarios contratada y medir tiempos de respuesta reales.
• Monitorizacion continua: Implemento monitorizacion durante 7-14 días para documentar patrones de degradacion.
• Comparativa con SLA: Presento los datos reales versus los compromisos contractuales en formato tabla, con graficas de tendencia.

3. Fallo en la disponibilidad (uptime)

El proveedor promete un 99.9 por ciento de disponibilidad (equivalente a 8.76 horas de downtime máximo al año) pero el servicio se cae con frecuencia. Estos casos son tecnicamente sencillos de demostrar pero requieren un historico de monitorizacion.

Lo que analizo:

• Registros de uptime: Datos de herramientas como UptimeRobot, Pingdom o StatusPage del proveedor.
• Impacto del downtime: Correlación entre caidas del servicio y pérdida de negocio documentable (pedidos no procesados, clientes perdidos, penalizaciones).
• Comunicaciones del proveedor: Emails y tickets donde el proveedor reconoce las caidas o las atribuye a “mantenimiento programado” que no fue programado.
• Cumplimiento del SLA de respuesta: Cuando el proveedor se comprometio a responder en 1 hora y tarda 48, eso también se documenta.

4. Imposibilidad de portabilidad de datos (vendor lock-in)

Este es uno de los problemás más graves y menos visibles en el momento de contratar. La empresa necesita cambiar de proveedor pero descubre que sus datos estan atrapados en un formato propietario, que la API de exportacion no funciona o que directamente no existe mecanismo de exportacion.

El análisis pericial incluye:

• Formatos de datos: Que formato utiliza el SaaS internamente y si es estandar (JSON, CSV, XML) o propietario.
• API de exportacion: Si existe, si funciona y si exporta todos los datos o solo un subconjunto.
• Clausulas contractuales: Si el contrato garantiza la portabilidad y en que terminos.
• Coste de migracion: Estimacion del coste real de extraer los datos y migrarlos a otro sistema.
• Impacto RGPD: El Reglamento General de Protección de Datos (art. 20) reconoce el derecho a la portabilidad de datos personales, lo que puede aplicarse cuando los datos del SaaS incluyen datos personales de clientes o empleados.

5. Brecha de seguridad del proveedor SaaS

Cuando el proveedor SaaS sufre una brecha de seguridad que expone datos del cliente, la disputa suele ir por dos vias: reclamación por daños (responsabilidad contractual) y posible infracción de protección de datos (RGPD). Mi trabajo como perito cubre ambas.

Lo que investigo:

• Alcance de la brecha: Que datos se expusieron, cuantos registros, durante cuanto tiempo.
• Medidas de seguridad del proveedor: Si cumplia con el estado del arte en seguridad (cifrado en reposo y transito, autenticación multifactor, segregacion de datos entre clientes).
• Causa raiz: Vulnerabilidad explotada, error de configuración, negligencia.
• Cumplimiento contractual: Si el contrato incluia cláusulas de seguridad y si el proveedor las cumplia.
• Notificación: Si el proveedor notifico la brecha en los plazos legales (72 horas según RGPD art. 33).

6. Modificación unilateral del servicio

El proveedor cambia funcionalidades, elimina modulos o modifica los terminos de uso sin consentimiento del cliente. Es más frecuente de lo que parece, especialmente cuando el proveedor es adquirido por otra empresa o cambia de estrategia comercial.

Lo que analizo en estos casos:

• Historial de cambios: Documentación de las versiones del producto y los cambios realizados.
• Notificaciones al cliente: Si el proveedor informo de los cambios con antelacion suficiente.
• Impacto funcional: Que funcionalidades se perdieron o cambiaron y como afecta al negocio del cliente.
• Clausulas contractuales: Si el contrato permitia al proveedor realizar cambios unilaterales y en que condiciones.
• Capturas web historicas: Utilizo Wayback Machine y otras herramientas para documentar el estado anterior del producto.

7. Cierre del proveedor sin plan de contingencia

El peor escenario: el proveedor SaaS cierra y los datos del cliente quedan inaccesibles. He trabajado en varios casos donde startups españolas cerraron de un día para otro y sus clientes perdieron acceso a años de datos de negocio. En estos casos, mi trabajo es intentar recuperar los datos del proveedor (si es posible), documentar el perjuicio y cuantificar los daños.

Lo que hago:

• Intento de recuperación de datos: Si los servidores siguen activos (aunque sea temporalmente), intento acceder a los datos del cliente.
• Análisis de alternativas: Evaluo si los datos pueden reconstruirse desde copias locales, emails, integraciones con otros sistemas.
• Cuantificacion del perjuicio: Calculo el valor de los datos perdidos, el coste de reconstruccion y el lucro cesante por interrupcion del negocio.
• Documentación de la negligencia: Si el proveedor no tenia plan de contingencia, escrow de código fuente ni politica de fin de servicio, lo documento como evidencia de negligencia.

Robo de propiedad intelectual de software: investigación forense

El problema

El robo de propiedad intelectual entre empresas tecnologicas es más común de lo que se piensa. Los escenarios típicos que me encuentro son:

• Un empleado que se va a la competencia y se lleva código fuente.
• Un subcontratista que reutiliza el código de un cliente para otro proyecto.
• Dos socios que se separan y ambos reclaman la propiedad del software que desarrollaron juntos.
• Una empresa que copia la interfaz, la funcionalidad o la arquitectura de un competidor.
• Un freelance que vende el mismo desarrollo a multiples clientes sin derecho a hacerlo.

Mi metodología de investigación forense de código

Criterios para distinguir inspiracion de copia

Uno de los puntos más delicados de mi trabajo es distinguir entre código que se parece porque resuelve el mismo problema (similitud funcional inevitable) y código que se parece porque fue copiado. Los criterios que utilizo:

Due diligence tecnologica en operaciones M&A

Por que el perito informático es imprescindible en M&A

Las operaciones de fusiones y adquisiciones (M&A) en el sector tecnologico español han crecido un 28 por ciento en 2025 según TTR Data. En estas operaciones, el valor de la empresa comprada reside en gran parte en su tecnología: el software que ha desarrollado, los datos que ha acumulado, la infraestructura que ha montado. Si esa tecnología tiene problemás ocultos, el comprador esta pagando de mas.

He participado como perito en due diligences donde descubri problemás que cambiaron radicalmente la valoración de la empresa target. Desde deuda técnica masiva que multiplicaria por tres el coste de mantenimiento, hasta licencias de software que la empresa usaba sin pagar y que generaban un pasivo oculto de cientos de miles de euros.

Las 7 areas de revision en una due diligence tecnologica

Mi proceso de due diligence cubre 7 areas que reviso sistematicamente.

1. Código fuente y arquitectura

• Calidad del código (metricas de complejidad ciclomatica, cobertura de tests, deuda técnica).
• Arquitectura del sistema (monolito vs microservicios, escalabilidad, puntos únicos de fallo).
• Documentación técnica (existencia, actualidad, completitud).
• Stack tecnologico (frameworks actuales o obsoletos, versiones con vulnerabilidades conocidas).

2. Infraestructura y operaciones

• Infraestructura cloud vs on-premise (costes reales, contratos, compromisos mínimos).
• Automatizacion de despliegues (CI/CD, infraestructura como código).
• Monitorizacion y alertas (que se monitoriza, con que herramientas, quien responde a las alertas).
• Disaster recovery (backups, RTO/RPO, pruebas realizadas).

3. Seguridad

• Historial de incidentes de seguridad (brechas pasadas, como se resolvieron).
• Cumplimiento normativo (RGPD, NIS2, PCI DSS si aplica, ENS si trabajan con el sector público).
• Vulnerabilidades conocidas (escaneo de dependencias, tests de penetración recientes).
• Gestión de secretos (como se almacenan las credenciales, quien tiene acceso a que).

4. Datos y propiedad intelectual

• Titularidad del código (contratos con empleados y subcontratistas, cesion de derechos de autor).
• Licencias de software (cumplimiento de licencias open source, especialmente copyleft como GPL).
• Patentes (si existen y si estan en vigor).
• Datos de clientes (volumen, calidad, permisos RGPD, portabilidad).

5. Equipo técnico y conocimiento

• Dependencia de personas clave (key man risk).
• Documentación del conocimiento (si se va el CTO, alguien puede mantener el sistema).
• Contratos laborales (cláusulas de no competencia, propiedad intelectual, periodo de permanencia).
• Rotacion historica del equipo técnico.

6. Proveedores y contratos tecnologicos

• Contratos SaaS activos (coste, duracion, cláusulas de salida, penalizaciones).
• Vendor lock-in (dependencia de un proveedor concreto sin alternativa viable).
• Contratos de soporte y mantenimiento (SLAs, costes, vigencia).

7. Roadmap y viabilidad técnica

• Plan de desarrollo a 12-24 meses (viabilidad técnica del roadmap prometido al comprador).
• Recursos necesarios (si el roadmap es realista con el equipo actual o requiere contrataciones).
• Riesgos tecnologicos (tecnologías en end of life, dependencias de APIs de terceros que pueden cambiar).

Caso real: due diligence que evito una adquisición de 4 millones de euros

Una empresa de capital riesgo me contrato para hacer due diligence tecnologica de una startup SaaS de gestión de recursos humaños valorada en 4 millones de euros. La startup tenia 200 clientes, 500.000 euros de ARR y un equipo de 8 personas.

Lo que descubri:

• Deuda técnica crítica: El 40 por ciento del código no tenia tests automatizados. La complejidad ciclomatica medía era de 47 (el umbral recomendado es menos de 10). Estimar el coste de refactorizacion necesario para escalar el producto resultaba en 600.000 euros mínimo.
• Licencias incumplidas: El producto utilizaba 3 librerias GPL v3 sin cumplir con la obligación de distribuir el código fuente. Esto generaba un riesgo legal de reclamación por parte de los autores de las librerias.
• Key man risk extremo: El CTO era el único que entendía la arquitectura completa del sistema. No habia documentación técnica. Si el CTO se iba (y no tenia cláusula de permanencia), la empresa perdía su activo principal.
• Datos de clientes sin cifrar: Los datos de 200 empresas (incluyendo nominas y datos de salud de empleados) se almacenaban sin cifrado en reposo. Esto constituia un incumplimiento del RGPD con un riesgo de sanción por la AEPD de hasta el 4 por ciento de la facturacion.
• SLA inexistente: La startup no tenia SLA formal con sus clientes. Habia sufrido 3 caidas mayores en los últimos 6 meses sin compensar a ningun cliente.

Mi recomendación al fondo: no adquirir al precio propuesto. El fondo renegocio y ofrecio 1.8 millones (un 55 por ciento menos) condicionado a que el CTO firmase un compromiso de permanencia de 2 años y a que se resolviesen los problemás de licencias y cifrado en 90 días. La startup rechazo y el fondo retiro la oferta.

Análisis de incumplimiento de SLA: metodología

Que es un SLA y por que importa juridicamente

Un Service Level Agreement (SLA) es el compromiso medible que el proveedor SaaS asume sobre el rendimiento de su servicio. Los parametros más comunes son:

Mi proceso de análisis

5 casos de estudio detallados

Caso 1: SaaS de gestión de pedidos que colapsaba en Black Friday

Contexto: Empresa de e-commerce con facturacion de 8 millones de euros anuales. Contrato un SaaS de gestión de pedidos con un SLA de 99.95 por ciento de disponibilidad y capacidad para 500 pedidos por minuto.

El problema: Durante el Black Friday 2025, el sistema se cayo durante 6 horas consecutivas. La empresa perdio pedidos estimados en 340.000 euros (basado en la medía de ventas por hora del año anterior durante ese periodo).

Mi análisis: Solicite los logs del proveedor SaaS y los datos de la pasarela de pago del cliente. Demostre que:

• El sistema empezo a degradarse con 180 pedidos por minuto (36 por ciento de la capacidad contratada).
• La caida total se produjo a los 210 pedidos por minuto.
• El proveedor no respondio al ticket crítico hasta 4 horas después (el SLA de respuesta era 30 minutos).
• El proveedor no habia realizado pruebas de carga antes del Black Friday a pesar de que el contrato lo exigia.

Resultado: Sentencia del Juzgado Mercantil número 3 de Barcelona condenando al proveedor a indemnizar con 280.000 euros (se aplico un descuento porque la empresa no habia probado al 100 por ciento la pérdida de todos los pedidos).

Caso 2: CTO que se llevo el código fuente a la competencia

Contexto: Startup fintech española de 15 empleados. El CTO cofundador (con un 30 por ciento de participaciones) abandono la empresa tras una disputa con el CEO. Tres meses después, lanzo un producto competidor con funcionalidades casí identicas.

Mi investigación: Adquiri forense el portatil que el CTO habia devuelto (parcialmente borrado) y compare el código del nuevo producto (accesible publicamente via la web) con el repositorio Git de la startup original.

Hallazgos:

• 67 por ciento de similitud estructural en el backend.
• Mismos nombres de variables internas en 34 funciones.
• Mismo bug en el calculo de comisiones que solo podía explicarse por copia directa.
• En el portatil, recupere evidencia de que el CTO se envio un ZIP con todo el repositorio a su email personal 48 horas antes de comunicar su marcha.
• El historial de Git del nuevo producto mostraba un primer commit masivo de 47.000 lineas de código maduro (imposible de desarrollar desde cero en 3 meses).

Resultado: El juzgado mercantil ordeno el cese inmediato de la comercializacion del producto competidor y condeno al CTO a indemnizar a la startup con 420.000 euros por infracción de derechos de propiedad intelectual (art. 138 TRLPI) y competencia desleal (art. 14 LCD).

Caso 3: due diligence que descubrio pasivos ocultos de 800.000 euros

Contexto: Empresa industrial queria adquirir una compañia de software de gestión logistica por 6 millones de euros. Me contrataron para la due diligence tecnologica.

Lo que descubri:

• El producto estaba construido sobre una versión de Oracle Database cuya licencia habia expirado 18 meses antes. El coste de regularizacion era de 340.000 euros.
• Habia 12 librerias open source con licencia AGPL incluidas en el producto sin cumplir la obligación de publicar el código. Riesgo de reclamación estimado: 200.000 euros en el peor caso.
• El equipo de desarrollo estaba formado por 6 personas, pero 4 de ellas eran subcontratistas sin cláusula de cesion de propiedad intelectual. El código que habian escrito (un 60 por ciento del total) no pertenecia legalmente a la empresa.
• El sistema no habia pasado una auditoria de seguridad en 3 años. Un escaneo básico revelo 47 vulnerabilidades, 3 de ellas críticas (CVSS mayor de 9.0).

Impacto: La valoración de 6 millones asumia tecnología limpia y sin pasivos. Con los pasivos descubiertos (340.000 de Oracle, 200.000 de riesgo AGPL, coste de regularizar la propiedad intelectual y la seguridad estimado en 260.000), la valoración real era de 4.2 millones. El comprador renegocio a 4.5 millones y la operación se cerro con cláusulas de protección específicas.

Caso 4: disputa de SLA con proveedor cloud europeo

Contexto: Cadena de clinicas dentales con 45 centros en España. Su software de gestión de pacientes (SaaS) sufrio 23 incidentes de downtime en 6 meses, acumulando 187 horas de indisponibilidad (disponibilidad real del 95.7 por ciento frente al 99.9 por ciento contratado).

Mi análisis: Recopile todos los tickets de soporte, los emails de notificación de incidencias del proveedor y los datos de monitorizacion del cliente. Para cada incidente, documente:

• Hora de inicio y fin del downtime.
• Impacto en número de centros afectados y pacientes que no pudieron ser atendidos.
• Tiempo de respuesta del proveedor versus SLA de respuesta.
• Causa raiz comunicada por el proveedor.

Ademas, analice que 14 de los 23 incidentes tenian la misma causa raiz (saturacion de la base de datos) y que el proveedor habia sido notificado del problema tras el tercer incidente sin tomar medidas correctivas.

Resultado: Resolución extrajudicial. El proveedor acepto pagar 95.000 euros en compensación y comprometerse a un plan de mejora tecnologica con penalizaciones automáticas por futuros incumplimientos.

Caso 5: migracion SaaS fallida que paralizo una empresa 3 semanas

Contexto: Empresa de logistica con 200 empleados. Contrato la migracion de su ERP on-premise a un SaaS de gestión empresarial. El proyecto tenia un plazo de 6 meses y un coste de 180.000 euros.

Lo que fallo: A los 4 meses, el proveedor realizo la migracion en producción un viernes por la tarde. El lunes, la empresa descubrio que:

• Se habian perdido 14 meses de datos historicos de facturacion.
• Los pedidos en curso no se habian migrado.
• La integracion con el sistema de almacen no funcionaba.
• No habia plan de rollback al sistema anterior (que ya habia sido desactivado).

La empresa estuvo 3 semanas operando con hojas de calculo y teléfono, perdiendo una estimacion de 450.000 euros en facturacion retrasada y penalizaciones contractuales con sus propios clientes.

Mi informe pericial: Analice el plan de migracion (inexistente formalmente), los scripts de migracion de datos (con errores que provocaron la pérdida de datos), la ausencia de pruebas pre-migracion y la falta de plan de rollback. Concluye que el proveedor incumplio las buenas prácticas básicas de migracion de sistemás (no hizo backup verificado, no hizo pruebas en entorno de staging, no mantuvo el sistema anterior como fallback).

Resultado: Condena al proveedor a devolver los 180.000 euros del proyecto e indemnizar con 320.000 euros adicionales por daños (lucro cesante y coste de las soluciónes temporales).

El Código de Comercio y las disputas tecnologicas

Marco legal aplicable

Las disputas tecnologicas entre empresas se enmarcan en varios cuerpos legales. Como perito, necesito conocer el marco para estructurar mis informes de forma que respondan a las preguntas jurídicas relevantes.

Artículo 1101 del Código Civil: la base de toda reclamación

El artículo 1101 CC establece que “quedan sujetos a la indemnizacion de los daños y perjuicios causados los que en el cumplimiento de sus obligaciones incurrieren en dolo, negligencia o morosidad, y los que de cualquier modo contravinieren al tenor de aquellas”. Es la base legal de practicamente toda reclamación por incumplimiento de contrato SaaS.

Mi papel como perito es demostrar tecnicamente:

1. Que existia una obligación (el SLA, las funcionalidades prometidas, el compromiso de seguridad).
2. Que se incumplio (datos medibles que demuestran la discrepancia entre lo prometido y lo entregado).
3. Que hubo un daño (cuantificacion económica del perjuicio).
4. Que hay relación de causalidad (el incumplimiento técnico causo directamente el perjuicio económico).

Tarifas detalladas para peritaje mercantil tecnologico

10 preguntas frecuentes

1. Necesito perito informático para una disputa SaaS de menos de 50.000 euros?

Depende. Para reclamaciones menores, un informe técnico simplificado puede ser suficiente. Para reclamaciones ante el juzgado mercantil, la prueba pericial informática suele ser la única forma de acreditar el incumplimiento técnico. Mi recomendación: consulta primero con tu abogado mercantilista y contactame para una valoración gratuita.

2. Puede el proveedor SaaS destruir las pruebas antes de que el perito acceda a ellas?

Si, y es más común de lo que parece. Por eso es importante solicitar medidas cautelares de preservación de evidencia (art. 727 LEC) al inicio del procedimiento. Yo puedo preparar un informe previo que justifique la necesidad de la medida cautelar.

3. Como se valora economicamente el robo de propiedad intelectual de software?

Existen varios métodos: coste de desarrollo (horas de programación necesarias para crear el código desde cero), beneficio obtenido por el infractor, licencia hipotetica (royalty razonable que el infractor habría pagado por usar el código legalmente) y daño emergente al perjudicado. El método más habitual en juzgados mercantiles españoles es el de licencia hipotetica combinado con el beneficio del infractor.

4. Cuanto tiempo tarda una due diligence tecnologica?

Entre 4 y 8 semanas dependiendo de la complejidad. Para una startup con un producto y 5 desarrolladores, 4 semanas suelen ser suficientes. Para una empresa con multiples productos, equipo distribuido y decenas de integraciones, pueden necesitarse 8 semanas o mas. Siempre doy un plazo estimado antes de empezar.

5. El informe de due diligence es confidencial?

Absolutamente. Firmo acuerdos de confidencialidad (NDA) con todas las partes involucradas. La información que obtengo durante la due diligence no se comparte con nadie fuera de las partes contratantes.

6. Que diferencia hay entre un perito informático y un auditor de sistemas?

El auditor de sistemás evalua el cumplimiento de normás y mejores prácticas (ISO 27001, SOC 2, etc.) con un enfoque preventivo. El perito informático investiga hechos concretos para un procedimiento judicial con un enfoque probatorio. Mis informes estan diseñados para que un juez mercantil pueda entenderlos y basarse en ellos para su sentencia.

7. Puede mi empresa solicitar los logs del proveedor SaaS?

Depende de lo que diga el contrato. Muchos contratos SaaS incluyen cláusulas de transparencia que obligan al proveedor a facilitar logs y metricas. Si no lo dice el contrato, se puede solicitar mediante diligencias preliminares (art. 256 LEC) o como prueba pericial en el procedimiento.

8. Me han copiado la interfaz de usuario pero no el código. Es reclamable?

Si. El artículo 96.3 del TRLPI protege la documentación preparatoria, el manual de uso y la presentación o aspecto externo (look and feel) de un programa de ordenador. Una interfaz de usuario suficientemente original esta protegida aunque el código subyacente sea diferente. Mi trabajo como perito sería documentar la similitud de la interfaz y demostrar que no es casual.

9. Cuanto cuesta un procedimiento mercantil con perito informático en total?

El peritaje es una parte del coste total. Un procedimiento mercantil típico con componente tecnologico cuesta entre 15.000 y 50.000 euros en total (abogado, procurador, perito, tasas judiciales). El peritaje suele representar entre el 15 y el 25 por ciento del coste total.

10. Trabajas con fondos de inversion y private equity?

Si, regularmente. La due diligence tecnologica es un servicio que presto habitualmente a fondos que evaluan inversiones en empresas de base tecnologica. Entiendo sus tiempos, su lenguaje (ARR, churn, LTV, CAC) y sus necesidades de reporting.

Metodología forense detallada para disputas SaaS

Fase 1: definicion del alcance

Antes de empezar cualquier análisis, me reuno con el abogado del cliente para definir exactamente que necesitamos probar. Las preguntas clave son:

• Que obligaciones contractuales específicas se han incumplido?
• Que periodo temporal es relevante?
• Que sistemás y datos necesitamos analizar?
• Hay riesgo de que el proveedor destruya evidencia?
• Necesitamos medidas cautelares de preservación?

Esta fase es crítica porque un peritaje mal definido puede ser costoso e inutil. Un peritaje bien definido responde exactamente a las preguntas que el juez necesita contestar.

Fase 2: preservación de evidencia

La primera prioridad es preservar las evidencias antes de que se deterioren o destruyan.

Para datos del lado del cliente:

• Adquisición forense de los dispositivos del personal que interactuaba con el SaaS.
• Copia de los emails intercambiados con el proveedor.
• Exportacion de datos del SaaS (si aun es posible).
• Copia de los registros de monitorizacion (si existen).
• Capturas web con sellado temporal (Wayback Machine, Archive.today).

Para datos del lado del proveedor (si hay cooperacion o orden judicial):

• Logs del servidor.
• Registros de incidencias y tickets de soporte.
• Historico de versiones del software.
• Metricas de rendimiento y disponibilidad.
• Comunicaciones internas sobre el incidente.

Toda la adquisición se documenta con hashes SHA-256 y sellado temporal para garantizar la cadena de custodia.

Fase 3: análisis técnico

Dependiendo del tipo de disputa, el análisis técnico varia significativamente.

Para incumplimiento funcional: Comparo sistematicamente cada funcionalidad contratada con la funcionalidad real. Documento cada discrepancia con capturas de pantalla, videos de pantalla y registros del sistema. Clasifico las discrepancias por severidad y calculo un porcentaje de cumplimiento.

Para incumplimiento de SLA: Proceso los datos de monitorizacion para calcular metricas reales de disponibilidad, rendimiento y tiempo de respuesta. Genero graficas de tendencia y tablas comparativas. Identifico patrones (por ejemplo, degradacion sistemática en horas punta).

Para robo de IP: Ejecuto análisis de similitud de código con herramientas automáticas y manuales. Analizo el historial de commits. Reconstruyo la cronologia de desarrollo.

Para due diligence: Reviso sistematicamente las 7 areas descritas anteriormente. Genero un informe de hallazgos clasificados por riesgo.

Fase 4: cuantificacion del perjuicio

Esta es la parte del informe que más interesa al juez mercantil: cuanto vale el daño.

Los métodos de cuantificacion que utilizo:

Daño emergente: Coste directo del incumplimiento. Incluye el precio pagado por el servicio no recibido, el coste de soluciónes temporales y el coste de migracion a un nuevo proveedor.

Lucro cesante: Beneficio dejado de obtener como consecuencia del incumplimiento. Requiere datos historicos de facturacion y una proyeccion razonable de lo que se habría facturado sin el problema.

Coste de oportunidad: Valor de las oportunidades de negocio pérdidas. Es el más difícil de cuantificar y el que más rechazan los tribunales por falta de certeza.

Coste de remediacion: Lo que cuesta arreglar el problema. Si el SaaS no funciona y hay que contratar a otro proveedor, el coste de la migracion es un daño directamente atribuible.

Fase 5: elaboración del informe pericial

Mi informe pericial sigue una estructura estandarizada que he refinado a lo largo de años de práctica en juzgados mercantiles.

Estructura tipo:

1. Identificación del perito y juramento de imparcialidad.
2. Objeto del encargo y preguntas a responder.
3. Documentación analizada y fuentes de evidencia.
4. Metodología aplicada y herramientas utilizadas.
5. Resultados del análisis técnico (con graficas, tablas y capturas).
6. Cuantificacion económica del perjuicio.
7. Conclusiones (respuesta directa a las preguntas del encargo).
8. Limitaciones del análisis (que no se ha podido analizar y por que).
9. Anexos técnicos (datos brutos, capturas, logs relevantes).

El informe típico para una disputa SaaS tiene entre 30 y 80 páginas. Para una due diligence, puede superar las 100 páginas.

Siempre redacto el informe pensando en dos audiencias: el abogado (que necesita argumentos jurídicos) y el juez (que necesita entender la tecnología sin ser experto). Uso analogias, graficas y tablas resumen para que cualquier persona pueda seguir el razonamiento.

Fase 6: ratificación en juicio

La ratificación es el momento en que el perito defiende su informe ante el juez y las partes. Es la parte más exigente del proceso porque la contraparte intentara desacreditar el informe o al perito.

Las tacticas habituales de la contraparte:

• Cuestionar la independencia: “El perito fue contratado por la parte actora, no es independiente”. Mi respuesta: mis conclusiones se basan en datos objetivos y verificables, no en la voluntad de quien me paga.

• Cuestionar la metodología: “Por que uso herramienta X y no herramienta Y?” Mi respuesta: explico por que la herramienta elegida es la más adecuada y ofrezco los datos brutos para que cualquier otro perito pueda verificar mis conclusiones con la herramienta que prefiera.

• Sacar de contexto: Seleccionan una frase aislada del informe y le dan un significado diferente al que tiene en contexto. Mi respuesta: siempre me refiero al contexto completo del informe y no me dejo llevar al terreno de las interpretaciones parciales.

• Complejidad técnica como defensa: “El juez no puede entender la tecnología, así que no puede basarse en el informe”. Mi respuesta: precisamente para eso esta el perito, para traducir la tecnología al lenguaje jurídico.

Escrow de código fuente: la medida preventiva que nadie implementa

Que es un escrow de código fuente

Un escrow de código fuente es un deposito del código fuente de un software en maños de un tercero de confianza (el agente de escrow), que lo libera al cliente en determinadas circunstancias pactadas contractualmente: quiebra del proveedor, incumplimiento grave del contrato, cese de mantenimiento, etc.

En mi experiencia como perito en disputas mercantiles tecnologicas, el escrow habría evitado o mitigado significativamente al menos el 30 por ciento de los casos que he gestionado. Y sin embargo, menos del 5 por ciento de los contratos SaaS que he analizado incluyen cláusula de escrow.

Por que importa el escrow

Sin escrow, si el proveedor SaaS cierra, el cliente se queda sin acceso al código y sin posibilidad de contratar a un tercero para que mantenga el software. Es como alquilar una oficina sin tener copia de la llave: si el propietario desaparece, te quedas en la calle.

Con escrow, el cliente tiene la garantía de que, si el proveedor desaparece, podrá acceder al código fuente y contratar a otro equipo de desarrollo para mantener el software. No es la solución ideal (entender código ajeno es siempre complicado), pero es infinitamente mejor que quedarse sin nada.

Coste del escrow

El coste de un servicio de escrow de código fuente oscila entre 2.000 y 5.000 euros anuales, dependiendo del tamaño del deposito y la frecuencia de actualizacion. Comparado con el coste de una disputa mercantil (que facilmente supera los 50.000 euros), es una inversion insignificante.

Lo que verifico como perito en un escrow

Cuando un cliente me pide que verifique un deposito de escrow, compruebo:

• Que el código depositado es completo y compilable (que se puede construir y ejecutar).
• Que incluye todas las dependencias necesarias.
• Que la documentación técnica es suficiente para que un equipo externo pueda entender y mantener el código.
• Que el deposito se actualiza con la frecuencia pactada (si el proveedor actualiza el software cada mes, el escrow debería actualizarse cada mes).

Mi recomendación para cualquier empresa que dependa de un software crítico: exige cláusula de escrow en el contrato. Y exige que un perito independiente verifique periódicamente que el deposito es real y utilizable.

Medidas cautelares en disputas tecnologicas: la preservación de evidencia digital

Artículo 727 LEC: medidas cautelares en procesos mercantiles

Las medidas cautelares son herramientas procesales que permiten al juez ordenar la preservación de evidencia o la suspension de una actividad antes de que se dicte sentencia. En disputas tecnologicas, son especialmente importantes porque la evidencia digital es volatil y puede ser destruida facilmente.

Las medidas cautelares más habituales en mis casos son:

Deposito judicial del código fuente: El juez ordena al proveedor que deposite una copia del código fuente en poder del juzgado o de un tercero designado. Esto evita que el proveedor destruya o modifique el código durante el procedimiento.

Preservación de logs y datos de monitorizacion: El juez ordena al proveedor que conserve los logs de sus sistemás durante todo el procedimiento. Sin esta orden, el proveedor podría alegar que los logs se borran automáticamente según su politica de retención.

Prohibicion de modificar el servicio: Si la disputa es por una modificación unilateral del servicio, el juez puede ordenar al proveedor que mantenga el servicio en su estado actual hasta que se resuelva el litigio.

Acceso del perito a los sistemas: En algunos casos, el juez puede autorizar que el perito acceda directamente a los sistemás del proveedor para realizar su análisis.

Mi papel en las medidas cautelares

Preparo un informe previo (pre-pericial) que justifica la necesidad de la medida cautelar, explicando al juez por que la evidencia digital esta en riesgo y que medidas específicas son necesarias para preservarla. Este informe es fundamental para que el juez entienda la urgencia y la especificidad de las medidas solicitadas.

Errores comunes de las empresas en disputas tecnologicas

En mi experiencia, estos son los errores más frecuentes que cometen las empresas (y a veces sus abogados) cuando se enfrentan a una disputa tecnologica.

Error 1: no preservar la evidencia desde el primer momento

El error más común y más grave. Cuando una empresa detecta que su proveedor SaaS no cumple, lo primero que suele hacer es llamar al proveedor para quejarse. Y el proveedor, al darse cuenta de que puede haber una reclamación, empieza a modificar logs, eliminar tickets de soporte y actualizar el software para corregir los problemás (lo cual destruye la evidencia del incumplimiento previo).

Mi consejo: antes de avisar al proveedor de que vas a reclamar, contacta a un perito para preservar la evidencia.

Error 2: confiar en los datos del proveedor

Muchas empresas confian ciegamente en los informes de disponibilidad y rendimiento que les facilita el proveedor. Pero estos informes pueden estar maquillados: el proveedor puede excluir mantenimientos programados del calculo de uptime, medir latencia desde su propia red (no desde la del cliente) o clasificar incidentes críticos como “menores” para no incumplir el SLA.

Mi consejo: implementa tu propia monitorizacion independiente desde el primer día del contrato. Herramientas como UptimeRobot son gratuitas y proporcionan datos objetivos que el proveedor no puede manipular.

Error 3: no documentar los problemás por escrito

“Llamamos al soporte y nos dijeron que lo iban a arreglar” no sirve como prueba en un juicio mercantil. Todo debe estar documentado por escrito: tickets de soporte con número de referencia, emails de reclamación, capturas de pantalla de los errores con fecha y hora, y actas de reuniones con el proveedor.

Error 4: firmar contratos SaaS sin SLA definido

Es sorprendente la cantidad de empresas que firman contratos SaaS por importes de 50.000-200.000 euros anuales sin un SLA definido o con un SLA tan vago que es inaplicable (“máxima disponibilidad”, “rendimiento optimo”, “soporte prioritario”). Sin metricas medibles, no hay forma de demostrar incumplimiento.

Error 5: no revisar las cláusulas de resolución contractual

Muchos contratos SaaS tienen penalizaciones por rescision anticipada de 6-12 meses de cuotas, cláusulas de preaviso de 90-180 días y periodos de permanencia obligatorios. Si la empresa quiere cambiar de proveedor por incumplimiento, puede encontrarse atrapada contractualmente durante meses mientras el proveedor sigue sin cumplir.

Error 6: destruir evidencia propia

He visto empresas que, al cambiar de proveedor SaaS después de una disputa, eliminan todos los datos de la plataforma anterior “para hacer limpieza”. Esos datos podrían haber sido evidencia crucial en el procedimiento judicial posterior. Nunca elimines datos de un proveedor con el que estas en disputa hasta que tu abogado y tu perito confirmen que ya no son necesarios.

Checklist pre-contractual: 15 puntos que revisar antes de firmar un contrato SaaS

Basandome en los cientos de contratos SaaS que he analizado como perito, este es el checklist que recomiendo a cualquier empresa antes de firmar.

Si tu contrato actual no cubre estos 15 puntos, no estas desprotegido (la ley cubre muchos vacios) pero si estas en una posición de negociación más debil. Mi recomendación: antes de renovar un contrato SaaS importante, pidele a tu abogado que lo revise con esta checklist. Y si el proveedor se niega a incluir un SLA medible, eso te dice todo lo que necesitas saber sobre la calidad de su servicio.

Valoración económica de software: metodologías aceptadas por los tribunales

Por que importa la valoración

En disputas de propiedad intelectual, en due diligences y en reclamaciones por daños, el juez necesita un número. Cuanto vale el software en disputa? Cuanto ha perdido la empresa por el incumplimiento? Cuanto debería pagar el infractor por usar código ajeno?

Existen varias metodologías de valoración aceptadas por los tribunales españoles. La eleccion de una u otra depende del tipo de disputa y de los datos disponibles.

Método del coste de reemplazo

Calcula cuanto costaria desarrollar el software desde cero. Se basa en:

• Número de lineas de código (o puntos función).
• Coste medio por hora de desarrollo en el mercado.
• Complejidad del software.
• Tiempo de desarrollo estimado.

Este método es el más sencillo y el más conservador. Lo uso cuando la disputa es sobre robo de código y necesito una valoración mínima indiscutible.

Método de licencia hipotetica (royalty razonable)

Calcula que royalty habría pagado el infractor si hubiera licenciado el software legalmente. Se basa en:

• Royalties habituales en el sector (tipicamente del 5 al 25 por ciento de la facturacion generada con el software).
• Facturacion real del infractor atribuible al software copiado.
• Periodo de uso ilícito.

Este método es el preferido por los tribunales españoles en casos de infracción de propiedad intelectual.

Método del beneficio del infractor

Calcula el beneficio que el infractor ha obtenido gracias al uso del software copiado. Es el más agresivo y el más difícil de calcular porque requiere acceso a la contabilidad del infractor.

Método del daño emergente y lucro cesante

Calcula el perjuicio real sufrido por el titular del software:

• Daño emergente: clientes perdidos porque el infractor les ofrecio un producto más barato basado en código robado.
• Lucro cesante: ventas que el titular habría realizado si el infractor no hubiera entrado en el mercado con su copia.

Mi enfoque como perito

En la práctica, suelo calcular la valoración por dos o tres métodos diferentes y presentar los resultados como un rango. Esto le da al juez la flexibilidad de elegir el método que considere más justo para el caso concreto.

Ejemplo de un caso real:

• Coste de reemplazo: 180.000 euros.
• Licencia hipotetica: 340.000 euros.
• Beneficio del infractor: 520.000 euros.

El juez aplico el método de licencia hipotetica y condeno a 340.000 euros. El resultado habría sido muy diferente con otro método, lo que subraya la importancia de presentar las tres alternativas.

Tendencias 2026 en litigios tecnologicos mercantiles

Aumento de disputas por IA como servicio (AIaaS)

Los contratos de IA como servicio (modelos de lenguaje, vision por computador, recomendaciones) estan generando un tipo nuevo de disputa: el cliente contrata un modelo de IA que promete un 95 por ciento de precision y obtiene un 60 por ciento. La dificultad de estos casos es que el rendimiento de un modelo de IA depende en parte de los datos del cliente, lo que difumina la responsabilidad.

Disputas por cumplimiento DORA en el sector financiero

El Reglamento DORA (Digital Operational Resilience Act) obliga a las entidades financieras a exigir a sus proveedores tecnologicos niveles específicos de resiliencia operativa. Esto esta generando renegociaciones de contratos y disputas cuando los proveedores no pueden (o no quieren) cumplir con los nuevos requisitos.

Responsabilidad de administradores por decisiones tecnologicas negligentes

La Ley de Sociedades de Capital permite reclamar responsabilidad a los administradores por decisiones negligentes. Si un consejero delegado decide no invertir en ciberseguridad y la empresa sufre una brecha que causa daños a terceros, los accionistas minoritarios o los terceros perjudicados pueden reclamar responsabilidad personal al administrador.

Auge de la mediación tecnologica

Los juzgados mercantiles estan saturados y los plazos son cada vez más largos. La mediación tecnologica (con un mediador que entienda la materia técnica) esta ganando terreno como alternativa al litigio. Como perito, puedo actuar como asesor técnico del mediador para facilitar la comprension de los aspectos tecnologicos de la disputa.

Por que soy el perito adecuado para tu procedimiento mercantil

Mi perfil combina dos cosas que raramente se encuentran juntas: experiencia técnica profunda (ex-CTO, 5 veces certificado AWS, he construido y gestionado sistemás SaaS en producción) y experiencia pericial en juzgados mercantiles de toda España.

Cuando un abogado me explica que el SaaS de su cliente no cumple con el SLA, no necesito que me traduzca los terminos técnicos. Cuando un fondo de inversion me pide que valore la tecnología de una empresa target, entiendo que buscan riesgos que afectan a la valoración. Y cuando un juez mercantil me hace preguntas técnicas en la ratificación, se como explicar conceptos complejos en lenguaje accesible.

Trabajo en toda España, con disponibilidad para desplazarme a cualquier juzgado mercantil o para realizar la pericia en remoto cuando la naturaleza del caso lo permite (que en disputas tecnologicas es la mayoria de las veces).

He ratificado informes en juzgados mercantiles de Madrid, Barcelona, Valencia, Sevilla, Bilbao, Malaga, Zaragoza y otras ciudades. Conozco las particularidades de cada juzgado y la sensibilidad de cada magistrado hacia la prueba pericial informática.

Para abogados mercantilistas que me lean: ofrezco una consulta gratuita inicial de 30 minutos donde evaluamos la viabilidad técnica de la pericia, estimamos el plazo y el coste, y discutimos la estrategia probatoria. No cobro por esta consulta y no hay compromiso.

Para empresas que necesiten due diligence tecnologica con urgencia (por ejemplo, porque hay un plazo de cierre de operación M&A que se acerca), ofrezco un servicio express con informe preliminar en 10 días y informe completo en 21 días. El coste del servicio express tiene un suplemento del 30 por ciento sobre la tarifa estandar.

Para fondos de inversion y private equity que necesiten due diligences recurrentes, ofrezco acuerdos marco con tarifas preferentes y disponibilidad garantizada. Actualmente trabajo con varios fondos españoles y europeos que evaluan inversiones en empresas de base tecnologica.

Mi compromiso con cada cliente es el mismo: un informe técnico riguroso, imparcial y comprensible que sirva como base solida para la defensa de sus intereses ante un juzgado mercantil. Cada informe que firmo lleva mi reputacion profesional y mi responsabilidad como perito. No firmo informes que no pueda defender en juicio con total seguridad.

Mi enfoque es siempre objetivo e imparcial. Cuando me contrata una empresa para analizar un incumplimiento de su proveedor SaaS, analizo los datos sin preconcepciones. Si los datos demuestran que el proveedor ha cumplido, lo digo. Si demuestran incumplimiento, lo documento con toda la precision técnica necesaria. La credibilidad de un perito se construye sobre la imparcialidad, no sobre decir lo que el cliente quiere oir.

Contactame para una consulta gratuita sobre tu disputa mercantil tecnologica. Respondo a todas las consultas en un plazo máximo de 24 horas. Si tu caso es urgente (por ejemplo, porque necesitas medidas cautelares o porque hay un plazo procesal que se acerca), indicalo y te atendere con prioridad.

Mi teléfono, email y formulario de contacto estan disponibles en la página de contacto de esta web. La primera consulta es siempre gratuita y sin compromiso. En esa consulta evaluamos juntos la viabilidad técnica del peritaje, estimamos el plazo y el coste, y discutimos la estrategia probatoria más adecuada para tu caso.

Despues de la consulta, recibes un presupuesto cerrado por escrito. No hay sorpresas ni costes adicionales. El precio incluye el análisis completo, la elaboración del informe y la ratificación en juicio. Solo se factura un extra si el caso requiere desplazamiento a un juzgado fuera de mi zona habitual.

Algunos datos sobre mi práctica en procedimientos mercantiles:

• He participado como perito en más de 50 procedimientos mercantiles con componente tecnologico.
• Mis informes han sido valorados positivamente por magistrados de juzgados mercantiles de toda España.
• Experiencia directa en disputas SaaS, robo de IP, due diligence M&A, migraciones fallidas y brechas de seguridad.
• Tiempo medio de entrega para informe de disputa SaaS: 3 semanas.
• Tiempo medio de entrega para due diligence tecnologica: 5 semanas.
• Formación técnica: ex-CTO, 5 veces certificado AWS, experiencia construyendo sistemás SaaS en producción.
• Formación pericial: metodología ISO 27037, informes según estructura AENOR, ratificación en juicio.

La combinacion de experiencia técnica y pericial es lo que me permite traducir la realidad tecnologica al lenguaje que necesita un juzgado mercantil. No es suficiente saber de tecnología. Hay que saber de tecnología Y saber como funciona un juzgado. Esa doble competencia es lo que aporto a cada caso.

Si estas valorando contratar un perito informático para tu procedimiento mercantil, aquí van tres preguntas que deberias hacerle antes de contratarle:

Primera: tiene experiencia específica en disputas tecnologicas mercantiles, o su experiencia es solo en penal o civil? Los procedimientos mercantiles tienen su propia lógica, sus propios plazos y su propio lenguaje. Un perito que solo ha trabajado en casos penales puede no estar preparado para las exigencias de un juzgado mercantil.

Segunda: puede explicar conceptos tecnologicos complejos a un juez no técnico? La capacidad de comunicación es tan importante como la capacidad técnica. El mejor análisis del mundo no sirve de nada si el juez no lo entiende.

Tercera: esta dispuesto a ratificar el informe en juicio y a responder a las preguntas de la contraparte? Algunos peritos entregan informes pero no quieren ir a juicio. La ratificación es una parte esencial del trabajo del perito y no se puede delegar.

Preguntas que los jueces mercantiles hacen al perito informático

Despues de ratificar informes en decenas de juicios mercantiles, he identificado las preguntas más frecuentes que hacen los magistrados. Las comparto aquí porque pueden ayudar a abogados y empresas a preparar mejor su estrategia procesal.

Sobre la fiabilidad de la evidencia digital

• “Puede esta evidencia digital haber sido manipulada?” Mi respuesta habitual: toda evidencia digital es teoricamente manipulable, pero la manipulación deja rastros detectables. El hash SHA-256 y la cadena de custodía son las garantías de que no ha sido manipulada.

• “Que pasa si el proveedor ha borrado los logs antes de que usted los analizara?” Mi respuesta: si los logs no existen, lo hago constar como limitación del análisis. La ausencia de logs puede ser indicativa de negligencia o de ocultacion deliberada, y lo reflejo en el informe.

• “Es posible que los datos que presenta sean fabricados?” Mi respuesta: los datos que presento proceden de fuentes verificables (servidores, dispositivos, servicios de monitorizacion) y su integridad esta garantizada por hashes criptograficos. Si la contraparte alega fabricacion, debería aportar una explicación técnica alternativa.

Sobre la cuantificacion del daño

• “Como ha calculado el lucro cesante?” Mi respuesta: he utilizado datos historicos de facturacion del cliente y he proyectado la facturacion esperada durante el periodo de incumplimiento. La proyeccion se basa en la tendencia de los 12 meses anteriores y en factores de estacionalidad del sector.

• “No es especulativa esa cifra?” Mi respuesta: toda estimacion de lucro cesante tiene un componente de incertidumbre. He utilizado la metodología más conservadora disponible y he proporcionado un rango (mínimo-máximo) para que el tribunal pueda aplicar su criterio.

Sobre la conducta del proveedor

• “Cree usted que el proveedor actuó con negligencia o con dolo?” Mi respuesta: como perito técnico, no me corresponde calificar juridicamente la conducta. Lo que puedo afirmar es que las buenas prácticas del sector exigian [medida específica] y que el proveedor no la implemento. La calificacion jurídica corresponde al tribunal.

• “Era previsible este fallo?” Mi respuesta: si, porque [el escaneo de vulnerabilidades habría detectado el problema / las pruebas de carga habrían revelado la insuficiencia / el riesgo estaba documentado en la industria].

Sobre la complejidad técnica

• “Puede explicar esto en terminos más sencillos?” Esta es la pregunta que más me gusta porque me da la oportunidad de hacer mi trabajo: traducir la tecnología al lenguaje común. Siempre llevo preparadas analogias y ejemplos cotidiaños para cada concepto técnico de mi informe.

Clausulas contractuales que habrían evitado los 5 casos de estudio

Para cada uno de los 5 casos de estudio que he presentado, identifico la cláusula contractual que habría evitado o mitigado el problema.

Caso 1 (Black Friday): cláusula de prueba de carga obligatoria

Si el contrato hubiera incluido: “El proveedor realizara pruebas de carga simulando el trafico esperado para eventos de pico (Black Friday, campanas promocionales) al menos 30 días antes del evento. Los resultados se compartiran con el cliente. Si las pruebas revelan que el sistema no soporta la carga esperada, el proveedor dispondra de 15 días para resolver el problema o el cliente podrá resolver el contrato sin penalizacion.”

Caso 2 (CTO que copio código): cláusula de propiedad intelectual reforzada

Si los estatutos de la sociedad hubieran incluido: “Todo el código fuente desarrollado por los socios o por empleados de la sociedad durante la vigencia de la relación laboral o societaria pertenece exclusivamente a la sociedad. Ningun socio podrá utilizar, copiar, distribuir o crear obras derivadas del código fuente de la sociedad tras su desvinculacion. El incumplimiento de esta cláusula generara una indemnizacion mínima de [importe] euros más el beneficio obtenido por el infractor.”

Caso 3 (pasivos ocultos en due diligence): cláusula de representaciones y garantías (reps and warranties)

Si el contrato de compraventa hubiera incluido representaciones específicas sobre:

• Titularidad completa del código fuente.
• Cumplimiento de todas las licencias de software.
• Ausencia de vulnerabilidades críticas conocidas.
• Cifrado de datos personales conforme al RGPD.

Con estas representaciones, el comprador habría podido reclamar directamente al vendedor por los pasivos descubiertos, sin necesidad de negociar.

Caso 4 (SLA clinicas dentales): cláusula de penalizacion automática

Si el contrato hubiera incluido: “Por cada hora de downtime que exceda el SLA mensual contratado, el proveedor abonara al cliente un credito equivalente al 2 por ciento de la cuota mensual. Si el incumplimiento acumulado supera las 24 horas en un trimestre, el cliente podrá resolver el contrato sin penalizacion y el proveedor abonara los costes documentados de migracion a un proveedor alternativo.”

Caso 5 (migracion fallida): cláusula de plan de migracion y rollback

Si el contrato hubiera incluido: “El proveedor entregara un plan de migracion detallado al menos 30 días antes de la fecha prevista de migracion. El plan incluira: cronograma, mapeo de datos, procedimiento de verificación post-migracion, plan de rollback documentado y periodo de funcionamiento en paralelo de al menos 15 días. El cliente aprobara el plan antes de la ejecución. En caso de fallo de la migracion, el proveedor activara el plan de rollback en un plazo máximo de 4 horas.”

La moraleja es clara: la mayoria de los litigios tecnologicos que he peritado se habrían evitado con cláusulas contractuales específicas y medibles. El coste de redactar un buen contrato SaaS con un abogado especializado es de 2.000-5.000 euros. El coste medio de un litigio mercantil tecnologico supera los 50.000 euros. La cuenta sale sola.

Recursos recomendados para empresas en disputa tecnologica

Para el CEO o director general

• Mantener la calma y no comunicar el conflicto publicamente hasta tener estrategia legal definida.
• No intentar negociar directamente con el proveedor sin asesoria legal.
• Preservar toda la documentación: contratos, emails, facturas, tickets de soporte.
• Presupuestar el coste total del procedimiento (abogado + perito + tasas + tiempo).

Para el CTO o director de tecnología

• Activar monitorizacion independiente del servicio en disputa (si aun esta operativo).
• No aceptar actualizaciones del proveedor que puedan corregir el fallo sin preservar evidencia.
• Documentar todo lo que pueda ser relevante: capturas de pantalla, videos, logs.
• Preparar un informe técnico interno del problema (será útil para el perito y el abogado).

Para el abogado mercantilista

• Contactar al perito informático antes de redactar la demanda (el perito puede identificar evidencias que cambien la estrategia).
• Solicitar medidas cautelares de preservación de evidencia si hay riesgo de destrucción.
• Incluir la prueba pericial informática en la proposición de prueba.
• Coordinar con el perito la preparación de la ratificación en juicio.

Referencias y fuentes

1. Código de Comercio, de 22 de agosto de 1885. Artículos 50-63, 325-345 (BOE).
2. Código Civil. Artículos 1101-1108 (incumplimiento), 1258 (buena fe), 1484-1491 (saneamiento por vicios ocultos).
3. Ley 1/2000, de 7 de enero, de Enjuiciamiento Civil. Artículos 256, 299, 335-352, 727.
4. Real Decreto Legislativo 1/1996, de 12 de abril, Texto Refundido de la Ley de Propiedad Intelectual. Artículos 95-104, 138-143.
5. Ley 3/1991, de 10 de enero, de Competencia Desleal. Artículos 4, 11, 14.
6. Reglamento (UE) 2022/2554 (DORA). Resiliencia operativa digital del sector financiero.
7. Reglamento (UE) 2016/679 (RGPD). Artículos 20, 32, 33-34.
8. Gartner (2025). “European SaaS Spending Report”. Gasto medio por empresa en SaaS.
9. ONTSI (2025). “Informe anual sobre Tecnología y Sociedad en España”. Observatorio Nacional de Tecnología y Sociedad.
10. TTR Data (2025). “M&A Technology Report Spain”. Transacciones tecnologicas en España.
11. Consejo General de la Abogacia Española (2025). “Memoria anual 2025”. Estadistica de procedimientos mercantiles con componente tecnologico.
12. Bain and Company (2025). “European SaaS Survival Report”. Tasa de cierre de startups SaaS.
13. AEPD (2024). “Guía sobre el tratamiento de datos en relaciones B2B”. Agencia Española de Protección de Datos.
14. ISO/IEC 27037:2012. Directrices para la identificación, recogida, adquisición y preservación de evidencia digital.
15. Moss (Stanford University). “A System for Detecting Software Similarity”. Herramienta de detección de plagio en código.