El perito informático en procedimientos mercantiles: disputas SaaS 2026

TL;DR: resumen rápido

Las disputas tecnológicas entre empresas ya no se resuelven con un apreton de manos

Llevo años como perito informático forense y los procedimientos mercantiles son el área que más ha crecido en mi práctica profesional. No es una sorpresa. ⚠️ Aquí figuraba que «el gasto en SaaS por empresa en España alcanzó los 64.000 euros anuales de media en 2025, según Gartner»: Gartner publica previsiones agregadas de gasto TI por región y por segmento, no una media de gasto por empresa desglosada para España, y la cifra no llevaba fuente. Lo que sostiene el argumento sin necesidad de cifra es la estructura del problema: cada contrato SaaS que se firma trae consigo un acuerdo de nivel de servicio, un tratamiento de datos por cuenta de tercero y un régimen de portabilidad, y los tres son objeto habitual de litigio. 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. También recibo casos de robo de propiedad intelectual entre socios que se separan, due diligence tecnológica en operaciones de compraventa de empresas que se tuercen, y disputas sobre SLAs que nadie se molesto en definir con precisión. 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

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 términos 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, vídeos), comparo funcionalidad por funcionalidad con el producto entregado.
• Pruebas funcionales sistemáticas: Ejecuto test cases basados en los requisitos contractuales. Documento cada funcionalidad que no existe, que falla o que difiere de lo prometido.
• Cuantificación 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.

Metodología de análisis:

• Definición de baseline: Establezco los parámetros 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.
• Monitorización continua: Implemento monitorización durante 7-14 días para documentar patrones de degradación.
• 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 técnicamente sencillos de demostrar pero requieren un histórico de monitorización.

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 problemas más graves y menos visibles en el momento de contratar. La empresa necesita cambiar de proveedor pero descubre que sus datos están atrapados en un formato propietario, que la API de exportación no funciona o que directamente no existe mecanismo de exportación.

El análisis pericial incluye:

• Formatos de datos: Que formato utiliza el SaaS internamente y si es estándar (JSON, CSV, XML) o propietario.
• API de exportación: Si existe, si funciona y si exporta todos los datos o solo un subconjunto.
• Cláusulas contractuales: Si el contrato garantiza la portabilidad y en que términos.
• Coste de migración: Estimación 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). El trabajo pericial 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, segregación 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 módulos o modifica los términos 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.
• Cláusulas contractuales: Si el contrato permitía al proveedor realizar cambios unilaterales y en que condiciones.
• Capturas web históricas: 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. Es un riesgo real: hay startups que cierran 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.
• Cuantificación del perjuicio: Calculo el valor de los datos perdidos, el coste de reconstrucción y el lucro cesante por interrupcion del negocio.
• Documentación de la negligencia: Si el proveedor no tenía plan de contingencia, escrow de código fuente ni política 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 tecnológicas 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 múltiples 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 tecnológica 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 tecnológico 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 problemas ocultos, el comprador esta pagando de más.

Una revisión técnica seria destapa con frecuencia problemas 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 áreas de revisión en una due diligence tecnológica

Un proceso de due diligence tecnológica debe cubrir siete áreas de forma sistemática.

1. Código fuente y arquitectura

• Calidad del código (métricas 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 tecnológico (frameworks actuales o obsoletos, versiones con vulnerabilidades conocidas).

2. Infraestructura y operaciones

• Infraestructura cloud vs on-premise (costes reales, contratos, compromisos mínimos).
• Automatización de despliegues (CI/CD, infraestructura como código).
• Monitorización 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, cesión de derechos de autor).
• Licencias de software (cumplimiento de licencias open source, especialmente copyleft como GPL).
• Patentes (si existen y si están 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).
• Rotación histórica del equipo técnico.

6. Proveedores y contratos tecnológicos

• Contratos SaaS activos (coste, duración, 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 tecnológicos (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 tecnológica de una startup SaaS de gestión de recursos humanos valorada en 4 millones de euros. La startup tenía 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 tenía tests automatizados. La complejidad ciclomatica media 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 había documentación técnica. Si el CTO se iba (y no tenía cláusula de permanencia), la empresa perdía su activo principal.
• Datos de clientes sin cifrar: Los datos de 200 empresas (incluyendo nóminas 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 facturación.
• SLA inexistente: La startup no tenía SLA formal con sus clientes. Había sufrido 3 caidas mayores en los últimos 6 meses sin compensar a ningun cliente.

La recomendación técnica en un caso así: 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 problemas 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

Qué es un SLA y por que importa jurídicamente

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

Mi proceso de análisis

Cinco escenarios de disputa mercantil tecnológica

Se ordenan por lo que cada uno enseña sobre la prueba. En los cinco, la pregunta pericial es la misma que plantea el art. 1101 CC: qué obligación existía, cómo se acredita que se incumplió y cómo se ata ese incumplimiento al daño.

Escenario 1: SaaS de gestión de pedidos que colapsa en el pico de campaña

Contexto: Empresa de e-commerce con facturación 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 media de ventas por hora del año anterior durante ese periodo).

Trabajo pericial: cotejo de los logs del proveedor con los datos de la pasarela de pago del cliente, que son dos fuentes independientes y bajo control de partes distintas. Lo que se acredita:

• El sistema empezo a degradarse con 180 pedidos por minuto (36 por ciento de la capacidad contratada).
• La caída 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 había realizado pruebas de carga antes del Black Friday a pesar de que el contrato lo exigía.

Qué lo hace concluyente: que la degradación empiece muy por debajo de la capacidad contratada convierte el incidente en un incumplimiento de la obligación principal, no en una incidencia puntual. Y el incumplimiento del SLA de respuesta se acredita solo con marcas de tiempo, sin discusión técnica posible.

Consecuencia típica: en esta familia de disputas, el importe reconocido suele quedar por debajo del reclamado, porque el lucro cesante se estima sobre ventas que no llegaron a producirse. Cuanto más granular sea la cuantificación —pedido a pedido, con histórico comparable—, menos margen hay para esa reducción.

Escenario 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 casi idénticas.

Trabajo pericial: adquisición forense del portátil devuelto —parcialmente borrado— y comparación del código del nuevo producto, accesible públicamente, con el repositorio Git de la empresa 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 portátil, 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 líneas de código maduro (imposible de desarrollar desde cero en 3 meses).

Qué lo hace concluyente: ninguno de los indicios basta por separado. La similitud estructural admite explicación —dos desarrolladores con la misma formación resuelven parecido—, y el envío del repositorio al correo personal, por sí solo, no acredita uso posterior. Lo que cierra el análisis son los dos hallazgos que no tienen lectura alternativa: el mismo error en el cálculo de comisiones, que solo se explica por copia, y un primer commit masivo de código maduro, incompatible con un desarrollo desde cero en el plazo transcurrido.

Marco jurídico aplicable: la infracción de derechos sobre el programa se articula por las acciones del art. 138 TRLPI, y la captación de la ventaja competitiva por la Ley 3/1991 de Competencia Desleal, cuyo art. 14 tipifica la inducción a la infracción contractual.

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

Contexto: Empresa industrial quería adquirir una compañia de software de gestión logística por 6 millones de euros. El encargo pericial es la due diligence tecnológica.

Lo que aparece en una revisión de este tipo:

• El producto estaba construido sobre una versión de Oracle Database cuya licencia había expirado 18 meses antes. El coste de regularizacion era de 340.000 euros.
• Había 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 cesión de propiedad intelectual. El código que habían escrito (un 60 por ciento del total) no pertenecía legalmente a la empresa.
• El sistema no había pasado una auditoría 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 asumía 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.

Escenario 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).

Trabajo pericial: reconstrucción a partir de los tickets de soporte, los avisos de incidencia del proveedor y los datos de monitorización del cliente. Para cada incidente se documenta:

• 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.

El dato que cambia la naturaleza de la reclamación es la reincidencia: 14 de los 23 incidentes comparten la misma causa raíz (saturación de la base de datos) y que el proveedor había sido notificado del problema tras el tercer incidente sin tomar medidas correctivas.

Qué lo hace concluyente: acreditar que el proveedor fue advertido tras el tercer incidente y no adoptó medidas correctivas traslada el caso desde el incumplimiento del SLA —que suele resolverse con los créditos de servicio previstos en el contrato, casi siempre irrisorios— hasta el incumplimiento contractual del art. 1101 CC, con indemnización de daños. Es la diferencia entre cobrar un descuento en la siguiente factura y cobrar el perjuicio.

Escenario 5: migración SaaS fallida que paralizo una empresa 3 semanas

Contexto: Empresa de logística con 200 empleados. Contrato la migración de su ERP on-premise a un SaaS de gestión empresarial. El proyecto tenía un plazo de 6 meses y un coste de 180.000 euros.

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

• Se habían perdido 14 meses de datos históricos de facturación.
• Los pedidos en curso no se habían migrado.
• La integración con el sistema de almacen no funcionaba.
• No había plan de rollback al sistema anterior (que ya había sido desactivado).

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

Trabajo pericial: examen del plan de migración —formalmente inexistente—, de los scripts de migración de datos, de la ausencia de pruebas previas y de la falta de plan de reversión. La conclusión técnica es que el proveedor incumplió las buenas prácticas básicas de migración de sistemas (no hizo backup verificado, no hizo pruebas en entorno de staging, no mantuvo el sistema anterior como fallback).

Qué lo hace concluyente: en una migración, la lex artis está razonablemente asentada y es fácil de contrastar punto por punto —copia de seguridad verificada, pruebas en entorno de preproducción, ventana de ejecución que no deje el fin de semana sin soporte, y sobre todo plan de reversión con el sistema anterior operativo hasta la aceptación—. Cuando faltan las cuatro, la discusión deja de ser sobre si hubo mala suerte.

El Código de Comercio y las disputas tecnológicas

Marco legal aplicable

Las disputas tecnológicas 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 indemnización 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 prácticamente toda reclamación por incumplimiento de contrato SaaS.

El papel del perito es acreditar técnicamente los cuatro elementos:

1. Que existía 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 tecnológico

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. Recomendación: consulta primero con tu abogado mercantilista y después con un 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 económicamente 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 tecnológica?

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 múltiples productos, equipo distribuido y decenas de integraciones, pueden necesitarse 8 semanas o más. 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 sistemas evalua el cumplimiento de normas 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. Un informe pericial debe estar diseñado para que un juez mercantil pueda entenderlo 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 métricas. 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?

Puede serlo, pero no por la vía del régimen especial del software, y conviene no confundirlo porque es donde más reclamaciones se caen.

El artículo 96 del TRLPI protege el programa de ordenador, y en su apartado 1 extiende esa protección a la documentación preparatoria, la documentación técnica y los manuales de uso. Su apartado 4, en cambio, es explícito en sentido contrario: «no estarán protegidos mediante los derechos de autor (…) las ideas y principios en los que se basan cualquiera de los elementos de un programa de ordenador, incluidos los que sirven de fundamento a sus interfaces». Es decir: lo que hace que una interfaz funcione así —la lógica de interacción, el flujo, la disposición funcional— queda fuera.

Lo que sí puede prosperar es una reclamación por la interfaz como obra autónoma, si su expresión gráfica concreta es original, o por la vía de la competencia desleal cuando la imitación genera confusión o aprovecha indebidamente el esfuerzo ajeno (Ley 3/1991). Son fundamentos distintos, con requisitos distintos, y el trabajo pericial también es distinto: documentar la similitud gráfica y descartar que responda a convenciones de diseño o a limitaciones técnicas —que es la defensa estándar— pesa más que medir el parecido.

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 tecnológico 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 inversión y private equity?

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

Metodología forense detallada para disputas SaaS

Fase 1: definición 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 sistemas 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 inútil. 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.
• Exportación de datos del SaaS (si aun es posible).
• Copia de los registros de monitorización (si existen).
• Capturas web con sellado temporal (Wayback Machine, Archive.today).

Para datos del lado del proveedor (si hay cooperación o orden judicial):

• Logs del servidor.
• Registros de incidencias y tickets de soporte.
• Histórico de versiones del software.
• Métricas 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 varía significativamente.

Para incumplimiento funcional: Comparo sistematicamente cada funcionalidad contratada con la funcionalidad real. Documento cada discrepancia con capturas de pantalla, vídeos 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 monitorización para calcular métricas reales de disponibilidad, rendimiento y tiempo de respuesta. Genero graficas de tendencia y tablas comparativas. Identifico patrones (por ejemplo, degradación 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 cronología de desarrollo.

Para due diligence: Reviso sistematicamente las 7 áreas 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 soluciones temporales y el coste de migración a un nuevo proveedor.

Lucro cesante: Beneficio dejado de obtener como consecuencia del incumplimiento. Requiere datos históricos de facturación y una proyección razonable de lo que se habría facturado sin el problema.

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

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

Fase 5: elaboración del informe pericial

El informe pericial debe seguir una estructura estandarizada, y esta es la que mejor funciona 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. Cuantificación 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 tácticas 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

Qué es un escrow de código fuente

Un escrow de código fuente es un depósito del código fuente de un software en manos 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 disputas mercantiles tecnológicas, 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 depósito y la frecuencia de actualización. Comparado con el coste de una disputa mercantil (que fácilmente supera los 50.000 euros), es una inversión insignificante.

Lo que verifico como perito en un escrow

Cuando un cliente me pide que verifique un depósito 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 depósito se actualiza con la frecuencia pactada (si el proveedor actualiza el software cada mes, el escrow debería actualizarse cada mes).

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 depósito es real y utilizable.

Medidas cautelares en disputas tecnológicas: 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 suspensión de una actividad antes de que se dicte sentencia. En disputas tecnológicas, son especialmente importantes porque la evidencia digital es volátil y puede ser destruida fácilmente.

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

Depósito 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 monitorización: El juez ordena al proveedor que conserve los logs de sus sistemas durante todo el procedimiento. Sin esta orden, el proveedor podría alegar que los logs se borran automáticamente según su política de retención.

Prohibición 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 sistemas 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 tecnológicas

Estos son los errores más frecuentes que cometen las empresas (y a veces sus abogados) cuando se enfrentan a una disputa tecnológica.

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 problemas (lo cual destruye la evidencia del incumplimiento previo).

Conviene saberlo: 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.

Medida preventiva: implementa tu propia monitorización 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 problemas 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 métricas 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

Hay 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 débil. Recomendación práctica: antes de renovar un contrato SaaS importante, pídele 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 elección 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 líneas 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 facturación generada con el software).
• Facturación 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 tecnológicos mercantiles

Aumento de disputas por IA como servicio (AIaaS)

Los contratos de IA como servicio (modelos de lenguaje, vision por computador, recomendaciones) están generando un tipo nuevo de disputa: el cliente contrata un modelo de IA que promete un 95 por ciento de precisión 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 tecnológicos 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 tecnológicas 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 tecnológica

Los juzgados mercantiles están saturados y los plazos son cada vez más largos. La mediación tecnológica (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 comprensión de los aspectos tecnológicos de la disputa.

Qué hace falta para peritar un procedimiento mercantil tecnológico

En una disputa mercantil sobre tecnología conviven dos competencias que rara vez van juntas, y la carencia de cualquiera de las dos se nota en el informe.

La primera es técnica de producción: haber construido y operado los sistemas de los que se discute. Un SLA no se evalúa leyendo el contrato, sino sabiendo qué significa que un sistema empiece a degradarse al 36 % de la carga contratada, por qué eso apunta a un cuello concreto y qué debería haber medido el proveedor antes. Quien no ha operado un SaaS en producción tiende a aceptar como causa raíz la primera explicación que le da el proveedor.

La segunda es procesal: saber para qué sirve el informe. Un dictamen dirigido a un juzgado mercantil no es un documento técnico con la conclusión al final; es un documento que tiene que sostener, en este orden, que existía una obligación, que se incumplió, que hubo daño y que hay relación de causalidad —el esquema del art. 1101 CC—. Un análisis impecable que no está estructurado así obliga al juez a hacer el trabajo de traducción, y ese trabajo no siempre se hace.

Formación y credenciales de quien firma este artículo: ex-CTO, cinco certificaciones de AWS, experiencia construyendo y operando sistemas SaaS en producción, metodología de cadena de custodia conforme a ISO 27037 e informes estructurados según norma AENOR. El ejercicio pericial se ampara en el art. 335.1 de la Ley de Enjuiciamiento Civil, que admite como perito a quien posee conocimientos técnicos en la materia sin exigir un título oficial cuando este no existe para el campo de que se trate.

Tres preguntas que conviene hacer a cualquier perito antes de contratarlo

Sirven para cualquier candidato, incluido quien escribe:

1. ¿Tiene experiencia específica en disputas mercantiles tecnológicas, o solo en penal o civil? Los procedimientos mercantiles tienen su propia lógica, sus plazos y su lenguaje. Un perito acostumbrado al ámbito penal puede no estar preparado para lo que exige un juzgado mercantil.
2. ¿Puede explicar un concepto técnico complejo a un juez no técnico? La capacidad de comunicación pesa tanto como la técnica: el mejor análisis del mundo no sirve si no se entiende.
3. ¿Está dispuesto a ratificar el informe en juicio y a responder a la contraparte? Hay peritos que entregan informes y no comparecen. La ratificación es parte esencial del trabajo y no se puede delegar, porque un informe que su autor no defiende vale muy poco.

Cómo se trabaja

• Consulta inicial gratuita de 30 minutos, sin compromiso, para evaluar la viabilidad técnica de la pericia, estimar plazo y coste y discutir la estrategia probatoria.
• Presupuesto cerrado por escrito tras esa consulta, que incluye el análisis, la elaboración del informe y la ratificación en juicio.
• Cobertura nacional, con peritación en remoto cuando la naturaleza del caso lo permite —que en disputas tecnológicas es lo habitual— y desplazamiento al juzgado cuando hace falta.
• Imparcialidad: si los datos demuestran que el proveedor cumplió, eso es lo que dice el informe. La credibilidad de un perito se construye sobre lo que está dispuesto a no afirmar.

Preguntas que los jueces mercantiles hacen al perito informático

Estas son las preguntas que un magistrado de lo mercantil formula con más frecuencia al perito informático en la ratificación. Conviene llevarlas preparadas, porque casi todas apuntan al mismo sitio: la solidez del método, no la conclusión. 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 teóricamente manipulable, pero la manipulación deja rastros detectables. El hash SHA-256 y la cadena de custodia 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 ocultación 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 monitorización) y su integridad esta garantizada por hashes criptográficos. Si la contraparte alega fabricación, 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 históricos de facturación del cliente y he proyectado la facturación esperada durante el periodo de incumplimiento. La proyección 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 estimación 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 jurídicamente 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 calificación 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 términos 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 cotidianos para cada concepto técnico de mi informe.

Cláusulas contractuales que habrían evitado los cinco escenarios

Para cada uno de los cinco escenarios anteriores, esta es la cláusula que habría evitado o mitigado el problema. Es la parte más aprovechable del artículo, porque se puede exigir antes de firmar.

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

Si el contrato hubiera incluido: “El proveedor realizara pruebas de carga simulando el tráfico esperado para eventos de pico (Black Friday, campañas 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 penalización.”

Escenario 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 indemnización mínima predeterminada, más el beneficio obtenido por el infractor.”

Escenario 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.

Escenario 4 (SLA clinicas dentales): cláusula de penalización automática

Si el contrato hubiera incluido: “Por cada hora de downtime que exceda el SLA mensual contratado, el proveedor abonara al cliente un crédito 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 penalización y el proveedor abonara los costes documentados de migración a un proveedor alternativo.”

Escenario 5 (migración fallida): cláusula de plan de migración y rollback

Si el contrato hubiera incluido: “El proveedor entregara un plan de migración detallado al menos 30 días antes de la fecha prevista de migración. 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 migración, el proveedor activara el plan de rollback en un plazo máximo de 4 horas.”

La moraleja es clara: la mayoría de los litigios tecnológicos 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 tecnológico supera los 50.000 euros. La cuenta sale sola.

Recursos recomendados para empresas en disputa tecnológica

Para el CEO o director general

• Mantener la calma y no comunicar el conflicto públicamente hasta tener estrategia legal definida.
• No intentar negociar directamente con el proveedor sin asesoría 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 monitorización 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, vídeos, 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. ⚠️ Figuraba aquí un «European SaaS Spending Report» de Gartner como fuente del gasto medio por empresa en SaaS. La cifra ya se retiró del cuerpo por no ser comprobable —los informes de Gartner están tras muro de pago— y la referencia se retira con ella: una fuente en la bibliografía afirma que algo del texto se apoya en ella.
9. ONTSI. Informe de digitalización de las pymes 2025 (datos 2024): el 34,9 % de las pymes utiliza servicios en la nube. ontsi.es
10. TTR Data (2025). “M&A Technology Report Spain”. Transacciones tecnológicas en España.
11. INE. Encuesta sobre el uso de TIC y del comercio electrónico en las empresas, año 2024 y primer trimestre de 2025. ine.es
12. ⚠️ Bain and Company (2025), «European SaaS Survival Report», citado para la tasa de cierre de startups SaaS. No he podido verificarlo: bain.com responde con el desafío de Cloudflare, que no se resuelve ni con navegador. No se retira —la consultora publica informes de ese tipo— pero queda señalado: es el mismo perfil que la entrada 8 de esta misma bibliografía, un informe de consultora con título verosímil y sin enlace que sostenía una cifra, y que sí resultó no ser localizable.
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.

Sobre el autor: Jonathan Izquierdo es perito informático forense, ex-CTO y cinco veces certificado AWS. Elabora informes periciales para procedimientos mercantiles con cadena de custodia conforme a ISO 27037, al amparo del art. 335.1 de la Ley de Enjuiciamiento Civil.