Qué revisar primero en su aplicación web3 hecha con IA antes de mainnet

El 3 de febrero de 2026, investigadores de Deakin University publicaron un estudio sobre contratos inteligentes en Solidity escritos por tres agentes de programación con IA. Los autores señalan que los contratos eran sintácticamente correctos y funcionalmente completos, pero que muchos tenían fallos de seguridad que podrían aprovecharse en entornos reales. Lo que contaron fueron hallazgos de una sola herramienta de análisis estático, no ataques (estudio de arXiv sobre contratos inteligentes generados por LLM, 3 de febrero de 2026).

Si ha creado una aplicación blockchain con herramientas de IA y funciona en una red de pruebas, el siguiente tramo lleva al dinero real. Mainnet es la red real, donde las transacciones mueven valor real. Le sugerimos este orden: si de verdad necesita una blockchain, qué permite hacer el contrato, dónde están las claves y qué tiene que ocurrir en una red de pruebas (testnet) y en una auditoría antes de pasar a mainnet.

¿Por dónde empiezo sin arriesgar dinero real?

Trabaje sobre una copia del proyecto, hecha sin archivos .env ni ningún archivo que contenga una clave real, solo en una red de pruebas y con cuentas nuevas que no tengan nada de valor. No despliegue en mainnet, no mueva fondos reales y no pegue una clave real en ningún sitio mientras revisa. Pare a los 60 minutos y anote lo que todavía no sabe.

La página ethereum.org Networks indica que no se recomienda reutilizar cuentas de mainnet en redes de pruebas, ni al revés, así que cree cuentas nuevas para esta revisión.

¿Necesita mi aplicación una blockchain de verdad?

Es posible que no haga falta una blockchain, y esa pregunta va antes que cualquier línea de Solidity. El resumen de NIST de 2018 explica que muchas organizaciones parten del deseo de usar una blockchain en algún sitio y luego buscan dónde. Recomienda lo contrario: entender dónde encaja la tecnología y después buscar los sistemas que coinciden (NIST IR 8202, Blockchain Technology Overview, octubre de 2018).

NIST enumera características que hacen adecuada una blockchain, entre ellas muchos participantes, participantes distribuidos y la voluntad o la necesidad de no depender de un tercero de confianza. También enumera otros factores que conviene sopesar: los datos de una red sin permisos son por lo general públicos, no existe un proceso para eliminar los datos originales y muchas redes sin permisos procesan las transacciones más despacio que otros sistemas informáticos.

Responda por escrito a tres preguntas. Es un consejo nuestro, no una norma de NIST.

1. ¿Quién escribe en el registro y confían los lectores en quien lo escribe? Si solo es su aplicación y sus usuarios confían en usted, las características que enumera NIST no son lo que la aplicación necesita.
2. ¿Alguien ajeno a su empresa tiene que verificar el registro sin preguntarle a usted?
3. ¿Le parecería bien que estos datos fueran públicos y permanentes?

Si las respuestas son «solo nosotros», «no» y «no», compare con una base de datos convencional y con copias de seguridad antes de dedicar otra semana a los contratos.

¿Qué encontró el estudio de Deakin en el código Solidity escrito por IA?

En el estudio de Deakin los autores informan de 1.033 contratos de tres agentes de programación, revisados con Slither, una herramienta de análisis estático. Entre el 47,4 % y más del 75 % de los contratos de un agente tenían al menos una vulnerabilidad, según el agente, y los hallazgos de gravedad baja fueron el grupo más numeroso en los tres agentes (estudio de arXiv).

Los 34 prompts estaban redactados como podría describir una idea un desarrollador sin experiencia, y cada uno se ejecutó diez veces por agente. El recuento del propio estudio no cuadra exactamente con ese diseño, así que tome el total como aproximado.

Son hallazgos de una sola herramienta sobre contratos individuales, así que léalos como un patrón para su aplicación y no como una tasa. Las categorías contadas incluyen falta de validación de entradas, denegación de servicio, aleatoriedad insegura, problemas aritméticos, llamadas externas sin comprobar, reentrada, errores lógicos y control de acceso. Los autores señalan también que a más líneas de código, más hallazgos.

El OWASP Smart Contract Top 10 de 2026 es una lista general de riesgos de los contratos inteligentes, no una lista sobre código escrito por IA. Sitúa en primer lugar las vulnerabilidades de control de acceso y en segundo las de lógica de negocio, y se basa en datos de incidentes de 2025 que abarcan 122 incidentes de contratos inteligentes.

Convierta esto en cinco preguntas para la persona que revise su contrato.

1. ¿Quién puede llamar a cada función que mueve dinero o cambia quién tiene el control? ethereum.org señala que cualquier cuenta puede llamar a una función pública o externa, lo cual es un problema si cualquiera puede entonces realizar una operación delicada, como acuñar tokens (ethereum.org, Smart contract security).
2. ¿Los cálculos con dinero siguen reglas que usted pueda enunciar en frases sencillas? OWASP describe los fallos de lógica de negocio como fallos de diseño que rompen las reglas previstas. Escriba cada regla como una frase y pida una prueba por regla.
3. ¿Se actualiza un saldo antes de enviar el dinero? ethereum.org explica que un contrato malicioso puede volver a llamar a uno vulnerable antes de que termine la primera llamada, y recomienda el orden «comprobaciones, efectos e interacciones» (checks-effects-interactions), es decir, primero las comprobaciones, luego los cambios de estado y después las llamadas a otras cuentas.
4. ¿Qué versión de Solidity usa el código? Desde la versión 0.8.0 el compilador rechaza el código que provoca un desbordamiento por exceso o por defecto de un entero; las versiones anteriores necesitan comprobaciones explícitas o una biblioteca (ethereum.org). La línea que empieza por pragma solidity muestra qué versiones acepta un archivo; la versión que realmente se usa se fija en la configuración de compilación del proyecto, así que pida ambas.
5. ¿Cuánto de este código hace falta? El estudio señala que los modelos de IA a veces añaden código innecesario y a veces inventan funciones que no existen. ethereum.org aconseja reutilizar bibliotecas auditadas como OpenZeppelin Contracts.

Para obtener un primer inventario, pegue esto en su herramienta de IA, trabajando sobre una copia del proyecto.

Solo lectura. No edite, cree ni borre ningún archivo y no ejecute ningún comando.
No abra archivos .env y no imprima ninguna clave, frase semilla ni secreto; indique solo el nombre del archivo y el número de línea.
Lea los archivos Solidity de CARPETA-DE-CONTRATOS y escriba una tabla con una fila por función pública o externa que incluya su nombre, quién puede llamarla, si mueve ETH o tokens, si cambia una dirección de propietario, administrador o actualización, y qué llamadas externas hace.
Después enumere: el rango de versiones de Solidity de la línea pragma de cada archivo; cada lugar donde una variable de estado se actualiza después de una llamada externa; cada dirección de propietario, administrador o rol y dónde se establece; cada lugar donde el código lee una clave privada, una frase semilla o una variable de entorno, solo con el nombre del archivo y el número de línea.
No sugiera correcciones. Si algo no puede responderse a partir del código, escriba DESCONOCIDO. Pare después de la tabla y las listas.

Los autores del estudio escriben que una autorrevisión de los desarrolladores basada en un LLM no puede sustituir a una verificación rigurosa ni a una auditoría independiente.

¿Dónde se guardan las claves y las carteras?

Una clave privada es lo que demuestra que usted puede mover fondos o cambiar un contrato, así que nunca va al repositorio, a un prompt, a un chat ni a un archivo de reglas de una herramienta de IA. NIST afirma que quien roba una clave privada obtiene acceso total a todos los activos digitales que esa clave controla, y que una transferencia hecha con ella por lo general no puede deshacerse.

La lista de vectores de ataque de OWASP más allá del código del contrato dice que muchas de las mayores pérdidas de 2025 vinieron de amenazas externas a la cadena (off-chain) y operativas, entre ellas la manipulación de multifirmas, los ataques a la cadena de suministro, el malware que vacía carteras (drainers) y el phishing.

De ahí salen cuatro reglas.

1. Use claves distintas para tareas distintas: una clave desechable para la red de pruebas, otra para desplegar y otra para administrar el contrato. ethereum.org desaconseja reutilizar cuentas entre redes de pruebas y mainnet.
2. No deje que una sola cuenta controle el contrato. ethereum.org dice que una única dirección de propietario es un punto único de fallo y que, si sus claves se ven comprometidas, el atacante puede atacar el contrato. Sugiere varias cuentas administrativas o una cartera multifirma (multisig) que exija un número mínimo de firmas, por ejemplo 3 de 5. Una multifirma solo ayuda si cada firmante es una persona o un dispositivo distinto y sus claves se protegen como cualquier otra clave.
3. Guarde las claves de firma en una cartera de hardware u otro almacén que su herramienta de IA no pueda leer. NIST señala que muchos usuarios guardan las claves privadas en hardware seguro especial.
4. Si alguna vez hubo una clave real en el repositorio, en su historial o pegada en un chat, trátela como expuesta y marque la hoja de comprobación del final como NO LISTO. No mueva fondos durante esta revisión. Sustituir la clave significa crear una nueva, trasladar lo que tenía la anterior y retirar sus roles en el contrato, como un paso aparte y planificado.

Para buscar secretos en una copia del proyecto, ejecute estos dos comandos en su propia ventana de terminal, no a través de una herramienta de IA.

grep -rIlE -i "private_key|mnemonic|seed phrase|secret" . --exclude-dir=node_modules --exclude-dir=.git
git log --all --full-history --oneline -- '*.env*'

El primer comando muestra los nombres de los archivos que mencionan esas palabras y el segundo muestra los commits que tocaron un archivo env. Los dos pueden listar archivos inofensivos, y un resultado vacío significa que estos comandos no encontraron nada, no que no exista nada.

¿Qué tiene que ocurrir en una red de pruebas y en una auditoría antes de mainnet?

Nuestro orden sugerido es ensayar el contrato en una red de pruebas, hacer que lo revise alguien que no lo escribió, corregir lo que encuentre, volver a ensayar la versión final y solo entonces desplegar en mainnet. ethereum.org dice que hay que probar cualquier código de contrato en una red de pruebas antes de desplegarlo en mainnet, y que el código de un contrato desplegado normalmente no puede modificarse para corregir fallos de seguridad, así que todos los controles de abajo se hacen antes del lanzamiento.

ethereum.org describe una parada de emergencia, una función que bloquea las llamadas a funciones vulnerables, y sugiere descentralizar su control con un timelock o una multifirma, porque esa función aumenta la necesidad de que los usuarios confíen en quien pueda activarla.

Decida por escrito quién puede pausar, quién puede actualizar y qué puede hacer cada uno. Un derecho a pausar o actualizar es también un poder del que alguien puede abusar o que alguien puede robar, así que protéjalo como la clave de administrador. Una vía de actualización es en sí misma algo que auditar, y OWASP sitúa las vulnerabilidades de proxy y capacidad de actualización en décimo lugar de su lista de 2026.

Así encajan las comprobaciones. Imagine a un fundador que crea con una herramienta de IA una aplicación de recompensas para aficionados. Los miembros ganan tokens por asistir a partidos y una función de administración acuña más.

El fundador pregunta quién puede llamar a esa función, si alguien que no sea la cuenta autorizada puede acuñar y quién puede pausarla, y anota las respuestas en la hoja de comprobación del final de la página. Supongamos que además la IA deja la clave de despliegue en un archivo de configuración. Esa clave cuenta como expuesta, la hoja dice NO LISTO y se planifica su sustitución como un paso aparte. El ensayo en la red de pruebas de la versión final tiene que demostrar que solo la cuenta autorizada puede acuñar, que la pausa funciona y que los pasos de despliegue funcionan. Una línea que sigue en DESCONOCIDO significa que el contrato espera.

¿Qué sabemos y qué no hemos verificado?

La página de arXiv del estudio de Deakin no dice que haya sido revisado por pares. Usó una sola herramienta de análisis estático sobre contratos individuales. Cada contrato salió de una sola petición, los prompts los redactó a su vez un modelo de IA y el estudio no informa de ninguna comparación con contratos escritos por personas. Sus autores dicen que usaron la clasificación propia de Slither, que deja fuera las vulnerabilidades de préstamos flash (flash loans), y que Slither no puede detectar vulnerabilidades complejas y basadas en el mercado.

El informe de NIST es de octubre de 2018 y describe blockchain en general, no la programación de contratos inteligentes. El estudio y las páginas de ethereum.org tratan de Solidity en Ethereum, mientras que NIST y OWASP son más amplios. No se cubren otras cadenas de bloques, la normativa sobre tokens ni el código de un sitio web que se conecta a una cartera.

El prompt, los comandos y el límite de 60 minutos no se han probado en un proyecto real creado con IA, y nada de esto sustituye a una auditoría. Si sus respuestas a las tres preguntas indican que no necesita una blockchain, salte las secciones sobre el contrato.

¿Qué puedo revisar hoy?

Dedique 60 minutos a una copia. Rellene la hoja de abajo y marque cada línea como OK, DESCONOCIDO o NO LISTO; una línea que no haya podido comprobar queda en DESCONOCIDO.

HOJA DE COMPROBACIÓN PARA EL LANZAMIENTO WEB3 (trabaje sobre una copia, solo red de pruebas, claves desechables, pare a los 60 minutos)
PROYECTO:
CADENA Y RED DE PRUEBAS:
REVISADO POR Y FECHA:

1 NECESIDAD DE UNA BLOCKCHAIN: QUIÉN ESCRIBE: ____ | QUIÉN DEBE VERIFICAR SIN PREGUNTARNOS: ____ | LOS DATOS PUEDEN SER PÚBLICOS Y PERMANENTES: SÍ / NO | DECISIÓN: NECESARIA / NO NECESARIA / DESCONOCIDO
2 QUIÉN PUEDE LLAMAR: FUNCIONES QUE MUEVEN DINERO O CAMBIAN EL CONTROL: ____ | CADA UNA TIENE UNA CUENTA AUTORIZADA CON NOMBRE: SÍ / NO | ESTADO: OK / DESCONOCIDO / NO LISTO
3 REGLAS DEL DINERO: REGLAS ESCRITAS COMO FRASES: ____ | UNA PRUEBA POR REGLA: SÍ / NO | ESTADO:
4 LLAMADAS EXTERNAS: SALDO ACTUALIZADO ANTES DE ENVIAR: SÍ / NO / DESCONOCIDO | ESTADO:
5 VERSIÓN DE SOLIDITY: ____ | CÓDIGO QUE NO SÉ EXPLICAR: ____ | ESTADO:
6 CLAVES: PALABRAS BUSCADAS ENCONTRADAS EN EL CÓDIGO O EN EL HISTORIAL: ____ | CLAVES POR TAREA: RED DE PRUEBAS / DESPLIEGUE / ADMINISTRACIÓN | LA ADMINISTRACIÓN ES UNA MULTIFIRMA: SÍ / NO | ESTADO:
7 PRUEBAS Y HERRAMIENTAS: PRUEBAS UNITARIAS EJECUTADAS: SÍ / NO | ANÁLISIS ESTÁTICO EJECUTADO: SÍ / NO | ENSAYO EN RED DE PRUEBAS DE LOS PASOS DE DESPLIEGUE: SÍ / NO | ESTADO:
8 AUDITORÍA Y PLAN ANTE FALLOS: AUDITORÍA INDEPENDIENTE HECHA: SÍ / NO | QUIÉN PUEDE PAUSAR: ____ | QUIÉN PUEDE ACTUALIZAR: ____ | MONITORIZACIÓN: SÍ / NO | ESTADO:

RECUENTO DE LÍNEAS QUE NO ESTÁN OK: ____
NOTAS: CADA LÍNEA DESCONOCIDO Y NO LISTO, CON LO QUE VIO

Siguiente paso

Fuentes

Comprobadas el 11 de octubre de 2026.

• arXiv, estudio sobre contratos inteligentes generados por LLM (Deakin University), 3 de febrero de 2026
• OWASP, Smart Contract Top 10 de 2026
• NIST IR 8202, Blockchain Technology Overview, octubre de 2018
• ethereum.org, Smart contract security (seguridad de los contratos inteligentes)
• ethereum.org, Networks