Smart contracts defectuosos: por qué ni el software producto ni el arbitraje blockchain bastan
La responsabilidad europea por producto alcanza al software, pero la pérdida cripto típica sigue dependiendo de demandado identificable, Derecho internacional privado, prueba y ejecución.
Antonio Tejeda Encinas
Presidente del Comité Euro Americano de Derecho Digital – CEA Digital Law
Durante una década, el ecosistema blockchain vendió dos atajos. Que el código era la ley. Y que, cuando algo saliera mal, el arbitraje on chain resolvería la disputa. Los dos suenan modernos y los dos son insuficientes. El código ejecuta, pero no juzga: no sustituye al consentimiento, ni a las normas imperativas, ni a la responsabilidad civil, ni al control judicial. Y el arbitraje, por sí solo, no crea un demandado, ni una ley aplicable, ni una sede válida, ni un patrimonio sobre el que ejecutar. Cuando un smart contract falla y alguien pierde dinero, la pregunta seria no es quien tocó el código. Es otra: hay alguien jurídicamente alcanzable, bajo qué título, ante qué foro, con qué ley aplicable y con qué posibilidad real de cobrar.
El espejismo del software producto
La novedad que ha cambiado la conversación es la Directiva (UE) 2024/2853, sobre responsabilidad por los daños causados por productos defectuosos, que sustituye a la norma de 1985. Por primera vez, el Derecho europeo dice sin ambigüedad que el software es un producto, programas informáticos, software autónomo y sistemas de IA, con independencia de cómo se suministren, y que su desarrollador o productor puede ser tratado como fabricante, sometido a responsabilidad objetiva: sin necesidad de probar culpa, aunque sí el defecto, el daño y la relación causal. Para quien diseña, despliega o explota un smart contract, esto no es menor: un contrato inteligente es, técnicamente, software.
Parece que la pieza encaja. No encaja del todo, y ahí está lo interesante.
Hay tres cortes. Primero, el calendario: la Directiva se aplica a los productos puestos en el mercado o en servicio después del 9 de diciembre de 2026, de modo que lo anterior sigue bajo el régimen viejo. Segundo, el código abierto: su artículo 2(2) excluye expresamente el software libre y de código abierto desarrollado o suministrado fuera de una actividad comercial. Y tercero, el más importante, la cabeza de daño: la Directiva indemniza muerte o lesión personal, daño a bienes y destrucción o corrupción de datos, pero las pérdidas puramente económicas no activan por sí solas este régimen.
Ese tercer corte es el que desmonta el espejismo. Cuál es el daño típico cuando falla un smart contract. Una posición liquidada por un oráculo manipulado, un pool vaciado por una vulnerabilidad, un colateral perdido, unos tokens que ya no están. Eso no es lesión personal ni daño material clásico. Es pérdida patrimonial pura. Y alguien objetará: los tokens son datos; una wallet vaciada es corrupción de datos; luego sí entra. En el supuesto típico, el argumento es débil. Cuando un exploit transfiere los fondos, la cadena no se degrada ni pierde integridad: registra fielmente una operación económicamente lesiva. Lo afectado no es la disponibilidad ni la integridad del dato, sino la titularidad y el valor patrimonial atribuido al activo representado. La Directiva protege que el dato no se corrompa; no protege el interés económico sobre un activo representado como dato. El smart contract entra en Europa como software producto; la pérdida cripto típica sigue entrando mal por esa puerta.
El segundo corte, el del open source, tiene además un filo que conviene aprovechar, porque separa la descentralización auténtica de la impostada. El contribuidor que publica código libre al margen de toda explotación queda fuera del régimen. Pero un protocolo con token, comisiones, fundación, treasury, capital riesgo detrás o una interfaz que monetiza el acceso no se refugia sin más en la etiqueta open source: eso es actividad comercial, y la Directiva contempla que la responsabilidad se reactive cuando ese código se integra en un producto comercial. La etiqueta no es un salvoconducto.
El verdadero problema: encontrar al demandado
Cómo se llega entonces al responsable. No responsabilizando mecánicamente al programador, que es el reflejo fácil y casi siempre equivocado. Hay que mirar la operación por funciones: quien diseñó, quien desplegó, quien auditó, quien alimentó el oráculo, quien explotó la interfaz, quien custodió las claves, quien gobernó el protocolo, quien lo comercializó y quien indujo confianza. Esa lectura por capas no es una teoría nueva. Es un método. Y su utilidad es concreta: sirve para localizar al actor que de verdad no está descentralizado.
Aquí está el nervio de todo, porque es donde el análisis técnico se vuelve acción jurídica. Localizar a ese actor no resuelve nada por sí mismo; lo que lo convierte en accionable es el Derecho internacional privado. Si el operador de un front end, un emisor, un custodio o un proveedor de servicios dirige su actividad a consumidores europeos, ya no estamos ante una nebulosa técnica: estamos ante un profesional. Y entonces entran normas que no se esquivan con una cláusula. El artículo 6 del Reglamento Roma I protege al consumidor cuando el profesional dirige su actividad a su país de residencia habitual, y no permite que una elección de ley lo prive de las normas imperativas que le amparan. Los artículos 17 a 19 del Reglamento Bruselas I bis permiten, en esos supuestos, que el consumidor demande ante los tribunales de su propio domicilio, y solo admiten apartarse de ese foro protector en condiciones muy estrictas.
Ahí el arbitraje blockchain pierde su glamour. Una cláusula arbitral o de jurisdicción predispuesta, escondida en unos términos y condiciones, que pretenda mandar al usuario europeo a una sede cara o remota, puede quedar neutralizada o ser inoponible. Y conviene recordar que la responsabilidad por producto de la nueva Directiva tampoco se puede excluir ni limitar por contrato. La crítica al arbitraje no es económica, aunque el coste también pese: es estructural. El arbitraje puede servir en operaciones entre empresas, de importe relevante, con partes identificadas, convenio válido, sede clara y activos ejecutables. Lo que no puede es presentarse como solución universal, y menos frente a consumidores. No sustituye al Derecho internacional privado; como mucho lo complementa cuando está bien diseñado.
Tampoco se resuelve esto esperando una ley europea total que lo ordene todo, porque esa ley no va a llegar. La Comisión retiró en octubre de 2025 la propuesta de Directiva sobre responsabilidad civil por inteligencia artificial y la propuesta de Reglamento sobre la ley aplicable a los efectos frente a terceros de las cesiones de créditos. El mensaje para el jurista es claro: no hay vía única. Hay que trabajar con piezas dispersas, responsabilidad por producto, derecho nacional de daños, consumo, MiCA, Data Act, Roma I, Roma II, Bruselas I bis, y montar el caso por partes. El Data Act apunta en la misma dirección: su artículo 36 exige a determinados smart contracts robustez, control de acceso, interrupción y terminación seguras, archivo y auditabilidad. El legislador europeo ha dejado de ver el smart contract como una pieza neutral; empieza a tratarlo como infraestructura sometida a deberes de diseño.
Coda
La conclusión incomoda, pero es la honesta. La automatización no elimina el Derecho; elimina la comodidad del análisis fácil. Tratar el software como producto es un avance real, pero no convierte cada pérdida cripto en daño indemnizable. Buscar al responsable por capas es necesario, pero no basta si al final no hay un demandado identificable, un foro competente, una ley aplicable, una prueba técnica sólida y un patrimonio sobre el que ejecutar. Y el arbitraje, sin esas cuatro cosas, no es justicia: es decorado procesal.
Antes de desplegar o de invertir en una estructura basada en smart contracts, la pregunta útil no es si el código funciona. Es quien responde si algo falla, bajo qué título, ante qué tribunal y con qué patrimonio. Quien no sepa contestar a eso no tiene una operación descentralizada: tiene un riesgo sin dueño.
