En el artículo La Web3 y su impacto en las transacciones corporativas, analizamos cómo la Web3 modifica el registro de operaciones, la gestión de activos digitales y la ejecución de acuerdos entre empresas. Estas aplicaciones no solo dependen de la blockchain utilizada, sino también del código de los contratos inteligentes, de las fuentes externas de datos, de las claves criptográficas y de los mecanismos de gobernanza.
Cuando un contrato controla activos o automatiza obligaciones, un error de programación o configuración puede producir efectos financieros inmediatos. La auditoría técnica trata de identificar estos riesgos antes del despliegue o de una actualización. Si ya se ha producido un incidente, el análisis forense de contratos inteligentes trata de reconstruir las transacciones, preservar los datos pertinentes y distinguir aquello que puede demostrarse mediante la blockchain de lo que todavía depende de evidencias externas.
Aunque son actividades complementarias, la auditoría y el análisis forense tienen objetivos, métodos y limitaciones diferentes. Comprender esta distinción es necesario tanto para reducir la exposición técnica como para documentar adecuadamente posibles pérdidas, fraudes o controversias.
Los ejemplos técnicos presentados a lo largo del artículo se refieren principalmente a Ethereum y a otras redes compatibles con la máquina virtual de Ethereum, o EVM. Las blockchains con otros modelos de cuenta, ejecución, actualización o finalidad pueden requerir procedimientos distintos de auditoría y análisis forense.
La auditoría y el análisis forense
La auditoría técnica tiene un carácter principalmente preventivo, aunque también puede examinar contratos ya desplegados. Su objetivo es identificar vulnerabilidades, errores de lógica, permisos excesivos, dependencias inseguras y divergencias entre los requisitos del proyecto y el comportamiento efectivo del código.
Este trabajo debe realizarse antes del despliegue inicial y siempre que se produzcan cambios relevantes en la lógica, las bibliotecas utilizadas, las integraciones externas o los mecanismos de gobernanza. En aplicaciones actualizables, la sustitución de la implementación puede hacer que parte de la auditoría anterior resulte insuficiente para evaluar la nueva versión.
El análisis forense parte de una situación diferente. Normalmente existe una transferencia no autorizada, la explotación de una vulnerabilidad, un cambio administrativo cuestionado u otra incidencia que debe reconstruirse. El objetivo consiste en determinar cómo se produjo el incidente, qué funciones se ejecutaron, qué activos se movieron, qué componentes participaron en la operación y hasta qué punto las evidencias permiten atribuir responsabilidades.
Una auditoría no garantiza que el contrato nunca vaya a ser explotado. Del mismo modo, un análisis forense no siempre consigue identificar a los responsables ni recuperar los activos. El resultado depende del alcance, la calidad de la información disponible, la arquitectura utilizada y las evidencias existentes fuera de la blockchain.
Los riesgos no se limitan al código fuente
Las aplicaciones basadas en contratos inteligentes pueden integrar interfaces, carteras, oráculos, bibliotecas, puentes entre redes, servicios de autenticación, proveedores de nodos y mecanismos administrativos. Una evaluación centrada únicamente en el contrato principal puede pasar por alto vulnerabilidades en las integraciones de las que depende su funcionamiento.
La clasificación OWASP Smart Contract Top 10 de 2026 reúne diez categorías relacionadas con vulnerabilidades y vectores de explotación: fallos de control de acceso, fallos en la lógica de negocio, manipulación de oráculos de precios, ataques facilitados por préstamos flash, ausencia de validación de entradas, llamadas externas no comprobadas, errores aritméticos, reentrancia, overflow y underflow de enteros y vulnerabilidades en proxies y mecanismos de actualización. El orden y la definición de las categorías se basan en incidentes de seguridad y datos de investigación recopilados en 2025. La lista es un documento de concienciación, no un inventario exhaustivo ni un sustituto del modelado de amenazas de cada aplicación.
Los fallos de control de acceso pueden permitir que una cuenta no autorizada modifique parámetros, emita activos, suspenda operaciones o sustituya la implementación del contrato. Los errores de lógica de negocio aparecen cuando el programa ejecuta correctamente las instrucciones recibidas, pero estas no representan de forma adecuada las reglas económicas o contractuales previstas.
La manipulación de oráculos de precios puede llevar al contrato a utilizar una referencia influida artificialmente, desactualizada o inadecuada para la liquidez del mercado observado. Los errores de redondeo, escala y precisión pueden distorsionar los cálculos y producir pérdidas, incluso mediante explotaciones repetidas. La reentrancia se produce cuando una llamada externa transfiere el control de la ejecución y el contrato llamado consigue volver a invocar una función vulnerable antes de que se hayan completado los cambios de estado necesarios.
No todos los daños proceden de una vulnerabilidad explotada por un tercero. Las funciones administrativas legítimas también pueden utilizarse de forma abusiva para retirar liquidez, emitir activos o mover valores depositados, como puede ocurrir en determinados rug pulls.
«Rug pull» es una expresión utilizada en el mercado de criptoactivos, y no una categoría jurídica con una definición única, para designar esquemas en los que los responsables de un token, proyecto o protocolo atraen a participantes y después utilizan el control que conservaron para retirar liquidez, desviar activos depositados o emitir y vender una cantidad significativa de tokens. La operación no depende necesariamente de la explotación de una vulnerabilidad: puede llevarse a cabo mediante funciones administrativas previstas en el propio contrato.
La calificación de un caso concreto exige examinar el código, los permisos, la información facilitada a los participantes y el movimiento de los activos. El fracaso del proyecto o la caída del valor de un token no permiten, por sí solos, calificarlo como rug pull.
En una demanda presentada en 2025, la SEC utilizó esta expresión para describir la alegación de que el demandado mantuvo desbloqueados tokens de proveedor de liquidez, o tokens LP, y los utilizó para retirar y vender activos de la correspondiente reserva de liquidez. El acuerdo anunciado por la SEC se alcanzó sin admisión ni negación de las alegaciones. La referencia ilustra el uso del término en el mercado, no una definición jurídica general ni una conclusión judicial aplicable a otros casos.
El compromiso de claves privadas representa otro vector relevante. Incluso un contrato sin vulnerabilidades conocidas puede ejecutar una operación perjudicial si la autoriza una credencial administrativa válida que haya sido robada o utilizada indebidamente. Por tanto, el análisis debe abarcar la forma de almacenamiento de las claves, las carteras utilizadas, los controles de acceso, la segregación de funciones y los procedimientos de recuperación.
Los atacantes también pueden explotar el factor humano sin obtener la clave privada ni vulnerar la lógica del contrato. Pensemos en una aplicación móvil que funcione como cartera de criptoactivos e incluya un navegador integrado para acceder a protocolos DeFi. Una dApp maliciosa puede reproducir el diseño, el logotipo, la identidad visual y otros elementos de una cartera o un servicio legítimos. El usuario puede confundir el contenido controlado por la página con la interfaz nativa de la aplicación y autorizar una transferencia, un permiso para mover tokens o una firma cuyo efecto real no comprende.
La interfaz mostrada puede variar según el entorno. La página puede detectar la presencia de un proveedor de Ethereum expuesto por la cartera y mostrar el flujo fraudulento únicamente en el navegador integrado, mientras presenta un contenido neutro o aparentemente inocuo en un navegador convencional. Esta variación depende del código utilizado por el defraudador y no constituye una característica necesaria de las dApps. El mismo dominio también puede mostrar la interfaz falsa en un navegador convencional y solicitar la conexión mediante una extensión, un código QR o un deep link. La detección del entorno y estos mecanismos de conexión no son, por sí solos, indicios de fraude: las soluciones legítimas también seleccionan el flujo en función del dispositivo y de la disponibilidad de una extensión. La interfaz del proveedor se describe en la EIP-1193, y MetaMask Connect documenta el uso de extensiones, códigos QR y deep links.
La interfaz del proveedor permite que la página envíe solicitudes, pero no le facilita directamente las claves privadas. La firma o autorización sigue sujeta al mecanismo de la cartera o de la cuenta. La validación criptográfica demuestra que se han satisfecho las reglas de autorización de la cuenta, pero no que el usuario haya comprendido el contenido o las consecuencias de la operación. Según el estándar utilizado, una autorización de gasto, un permiso de operador o una firma reutilizable pueden permitir el movimiento posterior de los activos. Este tipo de phishing mediante firmas está documentado en aplicaciones Web3.
En otro escenario, el defraudador se hace pasar por un integrante del soporte técnico y afirma que la cartera está en riesgo. La víctima puede ser inducida a revelar la frase semilla, instalar una aplicación falsa, conceder acceso remoto al dispositivo o aprobar una operación supuestamente necesaria para proteger los activos. La suplantación de canales de soporte y la solicitud de la frase semilla son formas documentadas de fraude contra usuarios de carteras. En otras variantes, el defraudador solicita la instalación de herramientas de control remoto. Estos mecanismos aparecen, respectivamente, en la documentación de MetaMask sobre la suplantación del soporte técnico y en casos de fraude relacionado con criptoactivos documentados por el INCIBE.
El análisis forense debe comprobar si el contenido variaba en función de la presencia y el tipo de proveedor, la red seleccionada, el navegador, la aplicación, el agente de usuario, la página de procedencia o los parámetros de la URL. También debe registrar qué cuentas exponía el proveedor a la página. En el modelo de permisos utilizado por carteras como MetaMask, el proveedor devuelve las direcciones a las que el usuario ha autorizado el acceso de la dApp. Esto no significa que una dirección sea necesariamente desconocida antes de la conexión, pues la página puede recibirla de otra fuente. El método «eth_requestAccounts«, por ejemplo, devuelve las direcciones autorizadas por el usuario. Cuando estén disponibles, deben preservarse el HTML, el código JavaScript, los recursos cargados, las respuestas del servidor, las redirecciones, los registros de navegación y de red, la información sobre DNS y alojamiento y las comunicaciones mantenidas con el defraudador. La reproducción de la página debe realizarse en un entorno aislado y con cuentas de prueba.
El alcance de una auditoría técnica
La auditoría comienza con la comprensión de los requisitos y de la arquitectura. Antes de buscar vulnerabilidades concretas, es necesario establecer qué debe hacer el contrato, qué comportamientos deben estar prohibidos, quién puede ejecutar cada función y qué propiedades deben mantenerse verdaderas durante todo el ciclo de funcionamiento.
Estas propiedades, denominadas con frecuencia invariantes, pueden establecer que el total de activos contabilizados se corresponda con los saldos de los participantes, que solo determinadas cuentas tengan permiso para actualizar el contrato o que una retirada nunca supere el importe disponible.
La revisión manual no consiste en una simple inspección visual del código. Trata de comprender los flujos de ejecución, los cambios de estado, los controles de acceso, las dependencias, las llamadas externas, los mecanismos de actualización y la lógica económica de la aplicación. También debe examinar la documentación técnica y comparar el comportamiento implementado con los requisitos definidos.
Esta evaluación puede combinarse con análisis estático, pruebas unitarias y de integración, ejecución simbólica y simulaciones en entornos controlados. Cada técnica identifica categorías distintas de problemas y tiene sus propias limitaciones. Por este motivo, la ejecución de una herramienta automatizada no sustituye la interpretación humana de los resultados.
En sistemas de mayor criticidad, la verificación formal puede utilizarse para demostrar que la implementación satisface determinadas propiedades especificadas matemáticamente. Sin embargo, no demuestra que el contrato esté libre de cualquier error. Como explica la documentación de Ethereum sobre verificación formal, la conclusión se limita a las propiedades, el modelo y la especificación utilizados. Una especificación incompleta puede dejar fuera del análisis comportamientos vulnerables.
La auditoría también debe comparar el código fuente examinado con el bytecode efectivamente desplegado. Esta correspondencia depende, según el caso, de la versión del compilador, la configuración del optimizador, la versión de destino de la EVM, las bibliotecas vinculadas, los metadatos, los argumentos del constructor y los demás parámetros de compilación y despliegue. La publicación del código fuente en un explorador de bloques facilita el análisis, pero no exime de confirmar su correspondencia con el programa ejecutado por la red.
El informe debe identificar con claridad la versión analizada, la dirección del contrato, la red, el bloque de referencia, las herramientas utilizadas, las pruebas realizadas y las limitaciones detectadas. Los cambios posteriores en el código, la configuración o las dependencias pueden exigir una nueva evaluación.
Contratos actualizables y mecanismos de gobernanza
El código desplegado en una dirección determinada de una red como Ethereum no suele poder sustituirse directamente. Esto no significa, sin embargo, que todas las aplicaciones mantengan la misma lógica durante toda su existencia.
Los patrones de actualización de contratos inteligentes permiten modificar el código ejecutado mediante migraciones, contratos auxiliares o proxies. En un patrón de proxy habitual, los usuarios interactúan con un contrato que conserva el estado, mientras que las llamadas se reenvían a otra dirección que contiene la implementación de la lógica. El cambio de esta dirección modifica el comportamiento de la aplicación sin alterar la dirección utilizada por los participantes.
Esta flexibilidad permite corregir vulnerabilidades y añadir funcionalidades, pero introduce nuevos riesgos. Una inicialización incorrecta puede dejar accesibles funciones administrativas. Las incompatibilidades entre las estructuras de almacenamiento pueden corromper saldos o parámetros. El compromiso de la cuenta encargada de la actualización puede permitir el despliegue de una implementación maliciosa.
Por ello, la auditoría debe identificar el proxy, la implementación activa, el administrador, los permisos existentes y los procedimientos necesarios para aprobar una actualización. También debe comprobar si existen carteras multifirma, retrasos programados, votaciones u otros controles destinados a reducir el riesgo de un cambio unilateral.
En análisis de este tipo, no basta con examinar la implementación asociada al proxy en el momento de la investigación. Es necesario determinar qué lógica estaba activa en el instante exacto de cada llamada pertinente, teniendo en cuenta el orden de las transacciones dentro del bloque y los posibles cambios realizados durante la propia transacción. La implementación ejecutada durante el incidente puede ser distinta de la utilizada cuando comienza la investigación.
El grado de finalidad debe evaluarse conforme a las reglas de la red examinada. Una operación que haya alcanzado la finalidad, o el nivel de confirmación considerado suficiente para el caso, normalmente no puede eliminarse ni modificarse unilateralmente en el historial. Esto no impide la devolución de los activos mediante una nueva transacción, su bloqueo mediante funciones administrativas o, en situaciones excepcionales, una bifurcación o una decisión de gobernanza capaz de modificar los efectos del incidente.
Reconstrucción forense de un incidente
El análisis forense comienza con la delimitación del periodo, las redes, las direcciones, los contratos y los activos implicados. A partir de este alcance, el historial de transacciones puede ordenarse cronológicamente para reconstruir las llamadas ejecutadas y los cambios provocados en el estado de la aplicación.
La investigación puede examinar la transacción inicial, las llamadas internas, los datos enviados a las funciones, los eventos emitidos, el consumo de recursos, los contratos intermedios y el movimiento posterior de los activos. La comparación entre el estado anterior y el posterior ayuda a determinar qué variables se modificaron y qué condición permitió la ejecución.
Los eventos deben contrastarse con la ejecución y con los cambios de estado, ya que los genera el propio código del contrato y, de forma aislada, no demuestran que el hecho representado se produjera tal como se describe.
Cuando el incidente afecta a un contrato actualizable, también deben reconstruirse los cambios de implementación y de permisos administrativos. Si el resultado dependió de un oráculo, es necesario identificar la fuente, el valor facilitado y el momento en que se utilizó ese dato. En operaciones entre redes, el análisis debe identificar la arquitectura del puente o del protocolo de mensajería y correlacionar las operaciones pertinentes en las redes de origen y destino con los mensajes, pruebas, validadores, oráculos o retransmisores utilizados, cuando existan.
Los datos on-chain deben contrastarse con la información existente fuera de la blockchain. Los repositorios de código, sistemas de despliegue, registros de acceso, dispositivos, carteras corporativas, comunicaciones internas, servicios en la nube, interfaces web e información conservada por proveedores de servicios pueden explicar cómo se obtuvo una credencial o quién aprobó un cambio.
El informe debe separar los hechos directamente observables, las inferencias sustentadas por un conjunto de indicios y las hipótesis todavía no confirmadas. Esta distinción evita que las relaciones técnicas entre transacciones se presenten como identificación concluyente de personas o como prueba de intención.
Rastreo on-chain y límites de la atribución
Muchas blockchains públicas permiten consultar transacciones, direcciones, contratos y movimientos de activos. Esta transparencia favorece el rastreo financiero, pero no elimina las dificultades de atribución.
Las direcciones suelen funcionar como identificadores seudónimos. La validación de una operación demuestra que se ha satisfecho el mecanismo de autorización previsto para la cuenta, pero no identifica automáticamente a la persona que utilizó la clave o el mecanismo de firma, ni demuestra que se tratara de su controlador legítimo.
Una cartera corporativa puede utilizar múltiples firmas, computación multipartita, un proveedor de custodia o un contrato de autorización programable. La conclusión de que una sola persona controlaba la operación puede ser incorrecta incluso cuando se conoce la dirección implicada.
El análisis de patrones temporales, importes, direcciones de destino e interacciones recurrentes puede indicar relaciones entre carteras. Estas técnicas de agrupación son útiles, pero producen inferencias sujetas a falsos positivos. Los servicios de mezcla, los puentes, los protocolos descentralizados y las direcciones compartidas por proveedores de custodia aumentan esta complejidad.
La atribución suele exigir el cruce con datos identificativos, registros de acceso, dispositivos, comunicaciones e información conservada por plataformas de intercambio u otros proveedores de servicios de criptoactivos. El acceso a estos registros depende de la fuente, la base jurídica y el procedimiento aplicable. Cuando su obtención requiera el levantamiento del secreto, una orden coercitiva o la cooperación formal de un proveedor, también dependerá de la intervención de la autoridad competente.
El Reglamento (UE) 2023/1113, asociado a la denominada Travel Rule, exige que los proveedores incluidos en su ámbito de aplicación obtengan y transmitan determinada información sobre los originantes y los beneficiarios de las transferencias de criptoactivos. Esta obligación puede hacer que existan datos relevantes para una investigación, pero no concede a abogados ni a investigadores privados un derecho general a exigir la identificación del titular de cualquier cartera.
Recopilación y conservación de las evidencias
Las capturas de pantalla y los archivos PDF generados por exploradores de bloques pueden formar parte del conjunto probatorio y documentar lo que mostraba una interfaz en un momento determinado. Sin embargo, no conservan necesariamente todos los datos subyacentes, pueden omitir campos y dependen de la interpretación realizada por el servicio utilizado. Por este motivo, no deben constituir la única fuente del análisis.
Cuando sea posible, los datos deben extraerse en un formato estructurado mediante las interfaces facilitadas por los nodos de la red. En Ethereum, por ejemplo, la API JSON-RPC permite consultar bloques, transacciones, recibos, código desplegado, registros y otros elementos necesarios para la reconstrucción.
Operar un nodo propio puede aumentar la independencia de la recopilación, pero no es obligatorio en todos los casos. Un proveedor de infraestructura puede facilitar los datos necesarios, aunque la disponibilidad de estados históricos, trazas de ejecución y métodos auxiliares varía según el servicio. Por ello, es necesario documentar el servicio utilizado, las solicitudes realizadas, las respuestas recibidas y las limitaciones técnicas. La comparación entre fuentes independientes puede reducir el riesgo de depender de una sola representación.
Para responder de forma inmediata a consultas sobre estados antiguos, normalmente se necesita un nodo de archivo o un servicio equivalente. Un nodo completo conserva bloques y transacciones históricos y, en determinadas configuraciones, puede reconstruir estados anteriores mediante la reejecución de las transacciones. Sin embargo, como suele eliminar estados históricos intermedios, esta reconstrucción puede resultar costosa desde el punto de vista computacional o no estar disponible a través de la interfaz utilizada. Un nodo de archivo conserva estos estados para su consulta directa. La documentación de Ethereum sobre nodos de archivo diferencia estas configuraciones y explica su uso en auditorías, investigaciones y análisis de seguridad.
La identificación de la red debe incluir, cuando proceda, el identificador de la cadena, el hash del bloque génesis y los hashes de los bloques de referencia pertinentes, pues el nombre de la red o el identificador de la cadena, por sí solos, pueden no ser suficientes en entornos privados o mal configurados.
Las trazas de ejecución y las diferencias de estado son resultados derivados por herramientas e interfaces específicas de los clientes, no objetos de consenso equivalentes a bloques o recibos. La recopilación debe registrar el cliente, su versión, el tipo de trazador y sus parámetros. Geth, por ejemplo, genera estos datos mediante sus propias interfaces de rastreo de la EVM.
En la capa de los contratos, deben recopilarse el bytecode desplegado y, cuando existan o estén disponibles, las direcciones del proxy y de la implementación, el código fuente verificado, las interfaces binarias de aplicación o ABI, las bibliotecas, la versión del compilador y los parámetros de compilación. Debe identificarse el origen de cada elemento, distinguiendo los datos obtenidos directamente de la red de los facilitados por exploradores, repositorios o responsables del proyecto.
El procedimiento de extracción debe registrar las herramientas, sus versiones, los comandos o solicitudes utilizados, las fechas y horas con sus correspondientes husos horarios, los responsables y los archivos generados. Estos elementos permiten que otro profesional reproduzca la consulta y evalúe los resultados de manera independiente.
Integridad, cadena de custodia y datación
Después de la recopilación, los archivos generados deben conservarse tal como fueron adquiridos. Las conversiones, normalizaciones y demás transformaciones deben realizarse sobre copias de trabajo. Un manifiesto debe relacionar cada archivo con su origen, el método de extracción, el responsable, la fecha y hora con el correspondiente huso horario, la fuente temporal utilizada y su resumen criptográfico. También puede calcularse un hash del paquete final que reúna el manifiesto y los archivos conservados.
Un hash criptográfico, como SHA-256, produce un resumen derivado del contenido. Cuando el valor recalculado se compara con un hash calculado con anterioridad y conservado de forma fiable, una divergencia indica que el contenido comparado ya no es idéntico. En las funciones criptográficas seguras, una modificación mínima produce, con una probabilidad extremadamente elevada, un resultado diferente. El NIST describe los resúmenes criptográficos como medios para detectar modificaciones producidas desde su generación.
Un hash, por sí solo, no demuestra quién produjo el archivo, cuándo empezó a existir ni si su contenido es verdadero. También es necesario distinguir los hashes de los archivos individuales del hash del paquete: una nueva compresión puede modificar el paquete aunque los archivos internos permanezcan idénticos.
La cadena de custodia debe permitir reconstruir quién recopiló, recibió, transfirió, almacenó, consultó o analizó cada elemento, con las fechas, finalidades y actuaciones correspondientes. El grado de formalización exigido depende del contexto probatorio y del procedimiento aplicable, pero las posibles lagunas pueden reducir la capacidad de demostrar el origen y la integridad de la evidencia. Por ello, deben registrarse las copias generadas, las transformaciones aplicadas, las ubicaciones de almacenamiento y los controles destinados a impedir o revelar cambios no documentados. La trazabilidad debe comenzar en el momento de la adquisición o conservación y abarcar las modificaciones producidas hasta el estado actual.
La ISO/IEC 27037:2012 ofrece directrices para la identificación, recogida, adquisición y conservación de posibles evidencias digitales. Su adopción puede mejorar la coherencia metodológica, pero no garantiza, por sí sola, que la evidencia vaya a ser admitida o considerada suficiente en un procedimiento judicial.
El uso de un sello de tiempo electrónico cualificado puede reforzar la demostración de que los datos asociados ya existían, en esa forma, en el momento indicado. De acuerdo con el artículo 41 del Reglamento eIDAS, el sello de tiempo electrónico cualificado goza de la presunción de exactitud de la fecha y la hora indicadas y de integridad de los datos asociados.
Esta presunción solo deriva de un servicio cualificado en los términos del Reglamento. Un registro temporal común o una anotación en una blockchain no se convierten automáticamente en un sello de tiempo electrónico cualificado. La presunción tampoco demuestra la veracidad de la información, la autoría de una transacción, el control de una cartera ni la intención de los implicados.
Regulación europea aplicable
No existe una única norma aplicable a todos los usos empresariales de la Web3. El marco jurídico depende de la actividad realizada, los activos implicados, el sector, la función desempeñada por la empresa y los datos tratados.
El Reglamento MiCA regula determinados emisores de criptoactivos y proveedores de servicios de criptoactivos. Una empresa no queda automáticamente sujeta a MiCA por el mero hecho de utilizar blockchain o contratos inteligentes en un proceso interno.
Para las entidades financieras incluidas en su ámbito de aplicación, entre ellas los proveedores de servicios de criptoactivos autorizados conforme a MiCA, el Reglamento DORA establece obligaciones relacionadas con la gestión del riesgo relacionado con las tecnologías de la información y la comunicación, la notificación de incidentes graves relacionados con las TIC, las pruebas de resiliencia operativa digital y la gestión del riesgo relacionado con las TIC derivado de proveedores terceros. Estas obligaciones no se extienden indistintamente a cualquier organización que utilice una aplicación Web3.
El tratamiento de datos personales sigue sujeto al RGPD. Mantener los datos originales fuera de la blockchain y registrar únicamente un hash no garantiza automáticamente el cumplimiento. Según las directrices finales del Comité Europeo de Protección de Datos, adoptadas el 7 de julio de 2026, las direcciones de carteras, los identificadores, los metadatos y los hashes pueden constituir datos personales cuando permitan identificar directa o indirectamente a una persona. Las directrices también aclaran que los hashes sin clave o sin salt (es decir, sin un valor aleatorio adicional) no suelen ofrecer una protección de la confidencialidad suficiente para almacenar datos personales en una blockchain pública.
La arquitectura debe incorporar la protección de datos desde el diseño, la minimización, la limitación del plazo de conservación, la definición de responsabilidades y medios para que los interesados ejerzan sus derechos. Cuando sea probable que el tratamiento entrañe un alto riesgo para los derechos y libertades de las personas físicas, la evaluación de impacto relativa a la protección de datos es obligatoria.
El Reglamento (UE) 2023/2854, conocido como «Reglamento de Datos» o «Data Act», también puede ser aplicable cuando se utilizan contratos inteligentes para ejecutar un acuerdo, o una parte de este, destinado a poner datos a disposición. Su artículo 36 establece requisitos de solidez y control de acceso, resolución unilateral e interrupción seguras, archivo y continuidad de los datos y coherencia con el acuerdo de intercambio de datos. También prevé una evaluación de conformidad y una declaración UE de conformidad. Este régimen tiene un alcance específico y no se aplica automáticamente a todos los contratos inteligentes.
La Directiva NIS2 alcanza a entidades de sectores concretos y utiliza, como regla general, criterios relacionados con el tamaño de la organización, además de prever determinadas excepciones. No se aplica a cualquier empresa por el mero hecho de utilizar blockchain. También debe comprobarse la situación de la transposición nacional: el 8 de julio de 2026, la Comisión Europea comunicó que España todavía no había notificado la transposición íntegra de la Directiva.
Estos instrumentos tienen ámbitos distintos y varios de ellos pueden ser relevantes para una misma actividad, pero sus obligaciones no siempre se acumulan en su totalidad. En el caso de las entidades financieras incluidas en su ámbito de aplicación, DORA se considera un acto jurídico sectorial de la Unión a efectos del artículo 4 de NIS2. Cuando sus requisitos sean al menos equivalentes, las disposiciones correspondientes de NIS2 sobre gestión de riesgos, notificación, supervisión y ejecución no se aplican de forma acumulativa. Por tanto, el análisis normativo debe tener en cuenta no solo el alcance individual de cada norma, sino también las reglas que rigen su interacción.
Conclusión
Los contratos inteligentes permiten automatizar operaciones y registrar transacciones de forma verificable, pero hacen que parte de los riesgos dependa del código, las integraciones, las claves criptográficas y los mecanismos de gobernanza.
La auditoría técnica trata de identificar estos riesgos, preferentemente antes del despliegue o de una actualización, y también puede reevaluar contratos ya desplegados. Para ello, debe examinar no solo las vulnerabilidades de programación, sino también los requisitos, permisos, dependencias, actualizaciones, oráculos y controles administrativos.
Cuando el incidente ya se ha producido, el análisis forense trata de reconstruir las operaciones y conservar los datos de forma documentada y reproducible. La transparencia de las blockchains públicas puede facilitar el rastreo, pero no resuelve automáticamente la identificación de los responsables ni sustituye las evidencias conservadas por sistemas, dispositivos y proveedores externos.
La utilidad de las conclusiones depende de la delimitación del alcance, la conservación de los datos originales, la distinción entre hechos e inferencias y la exposición clara de las limitaciones. Estas cautelas permiten obtener resultados técnicamente fundamentados, verificables y compatibles con la valoración jurídica aplicable a cada caso.
Más información sobre la La Web3 y su impacto en las transacciones corporativas.
