Antonio Tejeda Encinas | Presidente del Comite Euro Americano de Derecho Digital -CEA Digital Law | CEO Meta Channel Corporation
Durante años, una parte del ecosistema blockchain ha trabajado sobre una idea cómoda: que el código podía sustituir al Derecho. La fórmula servía para explicar proyectos, atraer inversión y presentar la automatización como si fuera una categoría jurídica propia. Pero no lo es. El código ejecuta instrucciones. El Derecho determina consecuencias.
La diferencia importa cuando un smart contract mueve valor económico.
Un contrato inteligente puede liquidar una posición, transferir fondos, bloquear garantías, activar pagos, depender de un oráculo o integrarse en una estructura de inversión. Puede hacerlo de forma automática y conforme a las reglas programadas. Pero si el resultado perjudica económicamente a un usuario, si una interfaz genera confianza, si un protocolo se comercializa como seguro o si una estructura se presenta como descentralizada mientras existen promotores, sociedades, treasury, gobernanza concentrada o explotación económica organizada, la discusión jurídica no puede terminar diciendo que el código funcionó.
Ahí empieza el problema.
La Directiva (UE) 2024/2853, sobre responsabilidad por productos defectuosos, introduce un dato relevante: el software queda incluido expresamente dentro del concepto de producto. Esto alcanza a programas informáticos, software autónomo y sistemas de inteligencia artificial, con independencia de cómo se suministren. Para quienes diseñan, despliegan, integran o explotan smart contracts, la consecuencia es clara: el software utilizado en el mercado ya no puede analizarse como una pieza puramente técnica, ajena a los criterios ordinarios de responsabilidad.
Pero ese avance no debe exagerarse.
Que el software pueda ser producto no significa que cualquier pérdida cripto quede automáticamente cubierta por la responsabilidad europea por producto. La Directiva tiene límites importantes. Se aplica a productos puestos en el mercado o en servicio después del 9 de diciembre de 2026. Excluye el software libre y de código abierto desarrollado o suministrado fuera de una actividad comercial. Y no está pensada para absorber sin más cualquier pérdida patrimonial pura derivada de una operación económica fallida.
Este límite es esencial.
En muchos conflictos vinculados a smart contracts, el daño típico no consiste en una lesión personal, un daño físico a bienes o una corrupción de datos en sentido estricto. Lo habitual es una pérdida económica: una posición liquidada, un colateral perdido, un pool vaciado, unos tokens transferidos, una expectativa destruida o una pérdida de valor asociada a la ejecución de una operación. La cadena puede haber registrado correctamente lo ocurrido. El dato puede seguir íntegro. Lo afectado no es necesariamente la integridad técnica del registro, sino la posición patrimonial del usuario.
Por eso no basta con afirmar que el software ya es producto. Esa afirmación abre una vía, pero no resuelve por sí sola la pérdida cripto típica. El caso tendrá que construirse con más precisión: defecto, daño cubierto, causalidad, legitimación pasiva, ley aplicable, tribunal competente, prueba técnica y posibilidad real de ejecución.
Ahí aparece el verdadero núcleo del problema: el Derecho Internacional Privado.
En una operación blockchain pueden coincidir usuarios europeos, desarrolladores en otro continente, una fundación constituida en una jurisdicción favorable, una sociedad que explota la interfaz, proveedores de oráculos, auditores, custodios, exchanges, titulares de treasury, miembros relevantes de gobernanza y una comunidad que formalmente decide, pero que en la práctica puede estar condicionada por pocos actores. La descentralización técnica no elimina automáticamente las conexiones jurídicas. A veces las distribuye. A veces las oculta. A veces desplaza el foco hacia quien controla la relación económica real con el usuario.
No se demanda al código. Se demanda, cuando procede, a quien puede ser jurídicamente vinculado con el daño.
Ese sujeto no tiene por qué ser el programador. En muchos casos no lo será. Puede ser quien explota comercialmente el front end, quien estructura el token, quien dirige su actividad a usuarios europeos, quien presta servicios sobre criptoactivos, quien controla elementos esenciales del protocolo, quien administra una treasury, quien induce confianza económica, quien comercializa el acceso o quien conserva una posición de control material bajo una apariencia descentralizada.
La responsabilidad no nace de haber escrito código. Nace de la función desempeñada, del control ejercido, del beneficio obtenido, de la confianza generada y de la conexión entre esa conducta y el perjuicio sufrido.
Esta distinción evita dos errores. El primero es buscar automáticamente un desarrollador al que imputar cualquier pérdida. El segundo es aceptar que la palabra descentralización basta para que desaparezca cualquier centro de responsabilidad. Ninguna de las dos respuestas es seria. La primera simplifica mal el problema técnico. La segunda deja sin tratamiento jurídico operaciones que mueven valor real y que, en muchos casos, son promovidas, financiadas, explotadas y gobernadas por actores identificables.
La misma cautela debe aplicarse al open source.
El código abierto desarrollado o suministrado fuera de una actividad comercial no puede convertirse en el responsable universal de lo que otros construyen, integran o explotan después. Esa protección tiene sentido. Pero no es lo mismo publicar código abierto que lanzar un protocolo con token, comisiones, capital riesgo, interfaz propia, incentivos financieros, treasury, marketing y gobernanza organizada. En ese segundo escenario, la etiqueta open source no debería utilizarse como blindaje automático. La clave no está solo en el repositorio, sino en la explotación económica del sistema.
Algo parecido ocurre con el arbitraje on chain.
Puede tener utilidad en relaciones entre operadores profesionales, con partes identificadas, convenio válido, sede clara, reglas aplicables, cuantía suficiente y activos ejecutables. Pero no puede presentarse como respuesta universal a los conflictos derivados de smart contracts. Menos aún cuando la cláusula aparece en condiciones predispuestas y coloca al usuario europeo en una posición procesal difícil, costosa o directamente impracticable.
En relaciones con consumidores europeos, el uso de blockchain no elimina las normas protectoras. Si un operador dirige su actividad a Europa, capta usuarios europeos, ofrece una interfaz, estructura un producto o presta un servicio orientado a ese mercado, deberá contar con reglas que limitan la elección de ley, la elección de foro y la eficacia de determinadas cláusulas contractuales. No es un detalle formal. Es lo que permite convertir una pérdida técnica o económica en una reclamación viable.
Esto tampoco significa que toda pérdida cripto genere responsabilidad.
Hay riesgos de mercado asumidos por el usuario. Hay pérdidas derivadas de volatilidad. Hay supuestos sin defecto probado. Hay fallos sin causalidad acreditable. Hay estructuras verdaderamente descentralizadas donde no será sencillo localizar un sujeto jurídicamente alcanzable. Y hay casos en los que la prueba técnica no permitirá sostener una reclamación con garantías.
Pero una cosa es reconocer esos límites y otra aceptar que cualquier infraestructura basada en smart contracts pueda mover valor económico sin una mínima estructura de imputación. Si hay explotación organizada, control relevante, apariencia de confianza, captación de usuarios y beneficio económico, el análisis jurídico no puede quedarse en la superficie tecnológica.
El Data Act confirma esta dirección en un ámbito concreto. Al imponer a determinados smart contracts requisitos de robustez, control de acceso, interrupción o terminación segura, archivo y auditabilidad, el legislador europeo deja claro que el contrato inteligente no se trata ya como una simple herramienta neutral. Cuando cumple una función relevante dentro de una operación regulada, se le exigen condiciones de diseño, seguridad y trazabilidad.
Para los desarrolladores serios, esto no debería verse como un ataque. Es una condición de entrada en mercados más exigentes. Si un proyecto pretende captar usuarios, mover activos, integrarse en servicios financieros, operar con empresas o relacionarse con consumidores, no basta con decir que el código ha sido auditado. Hace falta gobernanza, documentación, asignación de roles, gestión de incidentes, trazabilidad, criterios de actualización, control de accesos cuando proceda y una estructura jurídica coherente con la realidad económica del proyecto.
Para los usuarios e inversores, la consecuencia es práctica. Antes de confiar fondos a una estructura basada en smart contracts, no basta con mirar la rentabilidad prometida, la auditoría técnica o el discurso de descentralización. Hay que saber quién está detrás de la interfaz, qué entidad presta el servicio, qué jurisdicción se invoca, qué protección conserva el usuario, qué patrimonio existe para responder y qué ocurre si el problema no es un bug evidente, sino una mala estructura de incentivos, una manipulación de oráculos, una gobernanza capturada o una decisión operativa presentada como decisión comunitaria.
Blockchain no necesita quedar fuera del Derecho para desarrollarse. Necesita estructuras jurídicas compatibles con la función económica que pretende cumplir.
El código puede automatizar la ejecución. No puede resolver por sí solo la imputación de responsabilidad, la competencia judicial, la ley aplicable, la prueba o la ejecución patrimonial. La pregunta relevante, antes de desplegar, financiar, auditar o utilizar una estructura basada en smart contracts, no es únicamente si el código funciona. Es quién responde si falla. Cuando esa pregunta no tiene respuesta, el problema no es la descentralización. Es una exposición jurídica mal estructurada.
