Qué revisar antes de desplegar en mainnet un contrato inteligente hecho con IA

Si su aplicación blockchain hecha con herramientas de IA funciona en una red de pruebas (testnet), el siguiente tramo lleva al dinero real. Mainnet es la red real, donde las transacciones mueven valor real. Le sugerimos este orden: si necesita una blockchain, qué permite hacer el contrato, dónde están las claves y qué tiene que ocurrir en una red de pruebas y en una auditoría antes de pasar a mainnet. Según ethereum.org, el código de un contrato desplegado normalmente no puede modificarse para corregir fallos de seguridad, así que todo esto va primero.

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, un programa que revisa el código en busca de errores conocidos, no ataques (estudio de arXiv sobre contratos inteligentes generados por LLM, 3 de febrero de 2026).

El 29 de octubre de 2026 introdujimos cuatro problemas en un proyecto de demostración de fan tokens y ejecutamos sobre él los cinco comandos de abajo. Los problemas eran una función de acuñación abierta, un retiro que paga antes de actualizar el saldo, una versión que no coincide y una clave incluida en un commit de git.

¿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. Use solo una red de pruebas, con cuentas nuevas que no tengan nada de valor. La página Networks de ethereum.org no recomienda reutilizar cuentas de mainnet en redes de pruebas, ni al revés.

Mientras revisa, no despliegue en mainnet, no mueva fondos reales y no pegue una clave real en ningún sitio. Pare a los 60 minutos y anote lo que todavía no sabe.

¿Necesita mi aplicación una blockchain de verdad?

Quizá no, y si de verdad necesita una blockchain es la pregunta que va antes que cualquier línea de Solidity. Muchas organizaciones parten del deseo de usar una blockchain en algún sitio y luego buscan dónde, explica el resumen de NIST de 2018. 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).

Entre las características que NIST enumera como propias de una blockchain adecuada están muchos participantes, participantes distribuidos y la voluntad o la necesidad de no depender de un tercero de confianza. También menciona 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. Son 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?

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. Los autores informan de 1.033 contratos de tres agentes de programación, revisados con Slither, una herramienta de análisis estático. 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ó 10 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. Se basa en datos de incidentes de 2025 que abarcan 122 incidentes de contratos inteligentes, y sitúa en primer lugar las vulnerabilidades de control de acceso y en segundo las de lógica de negocio.

¿Qué debo preguntar a la persona que revise el contrato?

Convierta esos riesgos en cinco preguntas. Nuestro contrato de demostración falló en dos de ellas y planteó una tercera.

1. ¿Quién puede llamar a cada función que mueve dinero o cambia quién tiene el control? 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). La función mint de nuestra demostración era pública y no comprobaba quién la llama, así que cualquiera podía acuñar.
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? Un contrato malicioso puede volver a llamar a uno vulnerable antes de que termine la primera llamada, explica ethereum.org. Recomienda el orden «comprobaciones, efectos e interacciones» (checks-effects-interactions): primero las comprobaciones, luego los cambios de estado y después las llamadas a otras cuentas. El withdraw de nuestra demostración enviaba ETH antes de poner el saldo a cero, el orden del que advierte ethereum.org.
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, y 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. En nuestra demostración las dos no coincidían: la línea pragma decía ^0.7.6 y la configuración de compilación indicaba 0.8.24.
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.

Tres comandos en su propio terminal señalan los lugares de las preguntas 1 y 4. La configuración de compilación de nuestra demostración estaba en hardhat.config.js; en otro entorno, busque el archivo que indica la versión del compilador.

grep -rn "pragma solidity" contracts
grep -n solidity hardhat.config.js
grep -nE "function .*(public|external)" contracts/*.sol

En la demostración, el último comando mostró las líneas de mint y withdraw, dos funciones que hay que leer enteras.

También puede pegar este prompt en su herramienta de IA mientras trabaja 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: 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.

Trate su respuesta como pistas que abrir, no como hallazgos. 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?

Fuera del código y fuera del alcance de su herramienta de IA. 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, con claves protegidas 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.

/usr/bin/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. Un resultado vacío significa que estos comandos no encontraron nada, no que no exista nada.

En nuestra demostración, el primer comando mostró tres archivos. La configuración de compilación lee la clave del entorno, como se esperaba, y un README solo advierte sobre las claves. El .env contenía una: el hallazgo real. El segundo mostró el commit que añadió el .env y el que lo dejó de rastrear; la clave seguía en el historial del primero. En un segundo repositorio de pruebas ese mismo día, git show del commit que añadió el .env imprimió la clave de demostración: permanece en el historial hasta que se reescribe.

El primer comando llama a grep por su ruta completa porque en nuestro Mac el grep del shell era una función que envolvía otra herramienta de búsqueda, ugrep. Omitió el archivo oculto .env; /usr/bin/grep lo mostró.

¿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ó y corregir lo que encuentre. Después se vuelve a ensayar la versión final y solo entonces se despliega 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. Por eso todas las etapas de abajo se hacen antes del lanzamiento.

ethereum.org describe una parada de emergencia, una función que bloquea las llamadas a funciones vulnerables. Sugiere descentralizar su control con un timelock o una multifirma, porque la parada 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: OWASP sitúa las vulnerabilidades de proxy y capacidad de actualización en décimo lugar de su lista de 2026.

¿Qué aspecto tiene esto en una aplicación concreta?

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. Las respuestas van a la hoja del final. 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.

Los cuatro problemas que introdujimos en nuestra demostración quedan en la hoja antes de cualquier ejecución en la red de pruebas: una acuñación sin cuenta autorizada (línea 2), un retiro que paga antes de poner el saldo a cero (línea 4), un pragma que no coincide con la configuración de compilación (línea 5) y una clave en el historial de git (línea 6). En un proyecto real, una clave real en el historial bastaría por sí sola para que la hoja diga NO LISTO, según la regla 4 de las claves de arriba.

Tras las correcciones, 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.

¿Cuáles son los límites de estas fuentes y comprobaciones?

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). También dicen 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. Para ese sitio web, nuestros cuatro niveles de controles antes del lanzamiento dependen de quién puede abrir la aplicación, qué datos guarda y si se mueve dinero.

Nuestra propia ejecución del 29 de octubre de 2026 usó un proyecto de demostración creado para esta revisión, y los comandos de arriba señalaron cada problema que habíamos introducido. 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 comprobar 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: PRAGMA ____ | CONFIGURACIÓN DE COMPILACIÓN ____ | CÓDIGO QUE NO SÉ EXPLICAR: ____ | ESTADO:
6 CLAVES: PALABRAS CLAVE 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
• ethereum.org, Networks