
Auditorías Alucinadas: La IA Inventa El Bug
Encontró cuatro vulnerabilidades. Tres no existen. La cuarta era el parche.
Hay un sello circulando por ahí. Tipografía limpia, escudito, tres palabras: auditado por IA. No cuesta un duro, llega en noventa segundos y este año ha estado luciendo en páginas de proyectos que levantaron dinero de verdad. Debajo no hay más que un modelo de lenguaje que se leyó tu contrato, parió un informe seguro de sí mismo y —como ya dice en voz alta el Top 10 de OWASP para aplicaciones con LLM en su LLM09, Desinformación— no tiene mecanismo alguno para saber si algo de eso es cierto. La aritmética académica es poco piadosa: puestos a prueba contra 52 protocolos DeFi ya auditados, GPT-4 y Claude solo nombraban la mayoría de las vulnerabilidades reales en configuraciones que las sepultaban bajo inventos, unos treinta y nueve fantasmas por cada hallazgo genuino.
Y de ahí sale la forma del asunto, que es de una estupidez preciosa. El bot inventa un fallo. El desarrollador, que es un tío concienzudo, «arregla» la invención —a veces borrando una protección que sí estaba haciendo su trabajo—. El arreglo sale a producción. Y el agujero real, ese que el modelo jamás mencionó porque nadie escribió una respuesta en Stack Overflow sobre él, entra en producción luciendo sello de seguridad y traje de domingo. Nadie mintió. Todos fueron educadísimos. La pasta se fue igual.
El Esquema En Un Párrafo
Tres partes, un mismo documento. El proyecto fraudulento compra el sello porque es más barato que una auditoría y en una captura de pantalla se ve idéntico. El desarrollador honesto usa la herramienta porque es rápida y gratis, luego parchea hallazgos fantasma y quema su presupuesto de revisión en nada. El atacante lee el mismo informe —mismo modelo, mismo prompt, mismo contrato público— y presta atención justo a lo que todos se saltaron: las secciones que la herramienta marcó en verde. Una máquina que se equivoca en una dirección predecible no es una defensa. Es un mapa de dónde no está mirando nadie.
Una auditoría no es un documento. Es una persona poniendo su nombre sobre un riesgo. El sello vende el papeleo y pierde a la persona por el camino.
Un Error Muy Seguro De Sí Mismo
El informe siempre tiene una pinta estupenda. Etiquetas de severidad, referencias a líneas, un fragmento de remediación y un resumen ejecutivo escrito con la calma de quien nunca ha perdido dinero. Ese acabado es el producto. Fluidez y corrección son funciones distintas, y solo una de las dos se entrenó.
Los modos de fallo son concretos, no aleatorios. Los modelos inventan clases de vulnerabilidad que no aplican a la versión del lenguaje que tienen delante. Citan CVE que nunca se emitieron. Recomiendan librerías que jamás se publicaron, y por eso existe ya el slopsquatting como técnica de cadena de suministro: registras el nombre alucinado y esperas a que el siguiente desarrollador pegue la misma sugerencia. El atacante no tiene que adivinar en qué vas a confiar. Se lo pregunta al mismo modelo que tú.
Y luego están las omisiones, que salen más caras. Trail of Bits comprobó que la herramienta se atasca exactamente donde una auditoría se gana el precio: interacciones entre varios contratos, supuestos económicos, diseño de incentivos, el estado del protocolo tres bloques después del ataque. La reentrada de manual es fácil. Un invariante roto entre cuatro contratos y un oráculo es por donde sale el dinero de verdad.
Se lee como una auditoría, cuesta como un café y te cubre como la fotografía de un paraguas.
Por Qué El Modelo Inventa Fallos
Un modelo de lenguaje no está buscando defectos en tu código. Está prediciendo la continuación más plausible de un documento que empieza por «informe de auditoría de seguridad». Los informes plausibles contienen hallazgos. Así que aparecen hallazgos: el formato los exige y no hay ningún paso interno que compruebe si sobreviven al contacto con tu bytecode.
OWASP lo archiva como LLM09, Desinformación, y lo empareja con el exceso de confianza por un motivo: el peligro no es la frase equivocada, es la frase equivocada dicha con tono de especialista. La taxonomía de NIST sobre aprendizaje automático adversario lo formula más frío: en los sistemas generativos la seguridad no está calibrada con la corrección, y tratar la salida como evidencia es un fallo de control, no de modelo.
Añade ahora la capa de incentivos. Los proveedores venden cobertura, y la cobertura se demuestra más fácil con volumen. Una herramienta que reporta doce problemas parece más fuerte que una que reporta dos, y nadie promociona un escáner por la cantidad de cosas que ignoró correctamente. La sensibilidad se vende. La especificidad es la que te salva, y no sale bien en la foto.
Le pedimos a una máquina que se gana la vida escribiendo ficción un documento cuyo único valor es no ser ficción.
Vocabulario Descifrado
Seis términos. Apréndelos ahora o apréndelos después en un hilo de post-mortem.
Hallazgo alucinado
Lo que parece:
Un pequeño error dentro de un informe por lo demás útil.
Lo que es:
Una vulnerabilidad que el modelo generó porque el formato esperaba una. Tiene severidad, número de línea y arreglo, y nada de eso se refiere a algo real. OWASP llama a esta categoría desinformación: plausible, segura, falsa.
Tasa de falsos positivos
Lo que parece:
Un compromiso de ingeniería aceptable.
Lo que es:
Tu presupuesto de revisión, gastado por un desconocido. En el estudio de 52 protocolos, ajustar los modelos para que detectaran la mayoría de vulnerabilidades reales elevó los falsos positivos a unos treinta y nueve hallazgos de ruido por cada uno genuino: una proporción que convierte a tu ingeniero senior en un clasificador de tickets.
Slopsquatting
Lo que parece:
Typosquatting con nombre gracioso.
Lo que es:
Registrar nombres de paquetes que los modelos inventan, para que el siguiente desarrollador que siga la sugerencia instale el código del atacante. El estudio de USENIX contó unos 205.000 nombres alucinados únicos y comprobó que se repiten entre ejecuciones: las alucinaciones son lo bastante repetibles como para ser una cadena de suministro.
Sello «auditado por IA»
Lo que parece:
Garantía moderna y automatizada.
Lo que es:
Un gráfico. No hay firma auditora, ni alcance, ni metodología, ni firma personal, ni responsabilidad detrás. En la página de un token fraudulento cumple exactamente una función: convertir tu duda en un depósito.
Bug inducido por la remediación
Lo que parece:
Un parche que necesitaba una segunda pasada.
Lo que es:
Un defecto real y explotable introducido al aplicar el arreglo que la IA propuso para un problema imaginario: un guard eliminado, una comprobación reordenada, un modificador de acceso relajado para satisfacer un hallazgo que nunca existió. La auditoría no encontró el fallo. Lo entregó.
Alcance (scope)
Lo que parece:
Lenguaje contractual aburrido al principio de un PDF.
Lo que es:
La única parte de cualquier auditoría que te dice qué no se revisó: hash del commit, contratos incluidos, supuestos, componentes fuera de alcance. Los informes alucinados nunca lo tienen, porque un alcance es una promesa y un modelo no puede prometer nada.
Todo esto es gratis, instantáneo y con aspecto profesional. Esa combinación jamás ha sido una buena noticia.
Cómo Funciona El Timo
Cinco fases. Solo la última tiene enlace en un explorador de bloques.
Fase 1: generar el papeleo
Pegas el contrato en un chat, pides una auditoría de seguridad al estilo de una firma conocida y recibes doce páginas con niveles de severidad, tabla de puntuación y un hueco con forma de logo arriba. Coste: cero. Tiempo: menos de dos minutos.
La salida no falsifica el informe de una firma concreta. Falsifica el género entero.
Fase 2: vestir la portada
Un escudo, una línea verde de «APROBADO», un número de referencia inventado y una fecha. En la página de un lanzamiento va justo al lado del bloqueo de liquidez y la hoja de ruta, haciendo el mismo trabajo que ambos: sustituir verificación por decoración.
Nadie hace clic en el sello. Toda la intuición comercial del asunto está ahí.
Fase 3: dejar que los equipos honestos hagan lo mismo de buena fe
Esta es la parte que escala. Un desarrollador real pasa una revisión con IA, recibe una lista de hallazgos y empieza a parchear. Se van horas en problemas fantasma; el riesgo genuino de la lógica económica nunca sale porque al modelo no le enseñaron los incentivos, solo la sintaxis.
El proyecto fraudulento falsifica el informe. El honesto se lo cree. Los dos acaban igual de descubiertos.
Fase 4: envenenar el arreglo
Algunas remediaciones hacen daño activo. Quitar un guard de reentrada que el modelo llamó redundante, ampliar un modificador para callar un «hallazgo» de control de acceso, cambiar una llamada comprobada por una sin comprobar para ahorrar gas. El diff es pequeño, se revisa rápido y se fusiona con la tranquilidad de un ticket resuelto.
La línea más peligrosa de cualquier repositorio es la que se añadió para resolver un problema que no existía.
Fase 5: cobrar el sello
Los inversores ven una auditoría. Los formularios de listado aceptan una auditoría. Los agregadores muestran una auditoría. Nada en esa cadena verifica la firma, el alcance ni el hash del commit, y cuando alguien lo comprueba el depósito lleva quince días dentro del contrato.
El sello no necesita aguantar un escrutinio. Necesita aguantar los diez segundos previos a una compra.
La Cronología: Cómo Llegamos Aquí
Hitos documentados, en orden.
Marzo de 2023: el primer benchmark honesto
Trail of Bits publica su evaluación de Codex y GPT-4 para revisión de contratos y describe el patrón que todos redescubrirían después: útil en clases de fallo de manual, poco fiable en el razonamiento multi-contrato y económico para el que existen las auditorías.
La conclusión no fue «inútil». Fue «no sustituye», que es mucho más difícil de vender.
Junio de 2023: llega el número de los falsos positivos
Los investigadores prueban GPT-4 y Claude contra 52 protocolos DeFi reales con vulnerabilidades conocidas y ya auditadas. Se puede empujar a los modelos a nombrar la mayoría de los fallos reales, pero solo con ajustes que generan un torrente de inventados al lado.
La cobertura se puede comprar. La precisión es la factura que llega después, pagada en horas de ingeniero.
2023 a 2024: el sello «auditado por IA» se convierte en producto
Los servicios de revisión automática se multiplican y su salida empieza a aparecer como señal de confianza en páginas de lanzamiento de tokens, a menudo sin auditor con nombre, sin alcance, sin hash de commit y sin forma de verificar que se ejecutara herramienta alguna.
La industria del sello no esperó a que la tecnología estuviera lista. Nunca lo ha hecho.
Enero de 2024: los mantenedores conocen el «slop»
Daniel Stenberg, de curl, documenta informes de vulnerabilidad generados por IA llegando a su programa de recompensas —detallados, bien formateados, completamente inventados— y en julio de 2025 escribe directamente sobre el problema de volumen: los equipos gastan tiempo real en desmentir hallazgos escritos por máquinas.
A los defensores les están haciendo denegación de servicio con documentos que tardaron nueve segundos en producirse.
2024 a 2025: la alucinación se vuelve cadena de suministro
El estudio de alucinación de paquetes de USENIX Security 2025 mide 576.000 muestras de código generado, encuentra que aproximadamente una de cada cinco dependencias recomendadas no existe e identifica unos 205.000 nombres inventados únicos: una lista de objetivos lista para usar, hoy conocida como slopsquatting.
La misma imaginación que inventa tu fallo inventa la librería que lo arregla, y otro la registra primero.
2025: los estándares se ponen al día
El Top 10 de OWASP de 2025 para aplicaciones con LLM nombra explícitamente LLM09, Desinformación, y describe la salida confiadamente errónea y el exceso de confianza humano como un riesgo de seguridad en sí mismo, no como una queja de calidad.
Cuando el riesgo recibe número oficial, la excusa «no sabíamos que hacía eso» caduca.
Tres años, una sola dirección: mejor prosa, la misma epistemología, más distribución.
Señales Que Merecen Acción
- Un sello sin firma auditora, sin informe y sin hash de commitUna auditoría real dice quién la hizo, qué versión vio y qué excluyó. Lo que no tenga esas tres cosas es decoración.
- El informe tiene la misma fecha que el despliegue del contratoLa revisión humana dura días o semanas y produce un ciclo de arreglo y re-test. Una garantía del mismo día es un documento, no un proceso.
- Los hallazgos son genéricos y no citan ni una línea de tu códigoReentrada, desbordamiento de enteros, llamada sin comprobar: copiado de un temario. Un hallazgo genuino es incómodamente específico de tu arquitectura.
- Un problema «crítico» que no puedes reproducirPide la secuencia de transacciones que lo explota. Las alucinaciones no sobreviven a la petición de una prueba de concepto.
- Librerías recomendadas que no existenComprueba el registro antes de instalar nada que sugiera un modelo. Un nombre inventado que sí resuelve es peor que uno que falla.
- Ningún vínculo verificable entre la auditoría y este despliegueEl informe debe corresponder al bytecode desplegado. Código auditado en testnet y código desplegado en mainnet son dos productos distintos.
Ninguna de estas señales exige saber Solidity. Todas exigen leer la primera página.
Los Números
Solo cifras publicadas. Ninguna estimación propia.
~39 falsos positivos por hallazgo real
En el estudio de 52 protocolos, la configuración que permitía a GPT-4 y Claude sacar la mayoría de vulnerabilidades reales producía unos treinta y nueve hallazgos inventados por cada uno genuino.
19,7% de los paquetes recomendados no existen
Sobre 576.000 muestras de código generado por LLM en el estudio de USENIX Security 2025, casi una quinta parte de las dependencias sugeridas eran alucinadas.
205.000 nombres de paquete inventados únicos
El mismo estudio los catalogó y comprobó que las alucinaciones se repiten entre ejecuciones, que es justo lo que hace rentable registrarlas.
LLM09: un riesgo oficial, no una opinión
El Top 10 de OWASP de 2025 para aplicaciones con LLM lista la desinformación y el exceso de confianza como riesgo de seguridad con impacto documentado.
El Segundo Acto: Quién Responde Por La Firma De Un Robot
La pregunta interesante no es técnica. Cuando el contrato falla, todo el mundo va a buscar la auditoría y descubre que al otro lado no hay nadie.
No hay firma a la que demandar
Una auditoría es un encargo profesional: auditores con nombre, un alcance, una metodología acordada y, a veces, un seguro. Un PDF generado tiene un autor al que no se puede citar a declarar y un proveedor cuyos términos lo eximen de todo.
El exchange ve un trámite
Las listas de comprobación para listar preguntan si existe una auditoría, rara vez quién la hizo. Ese hueco es todo el modelo de negocio del sello, y se está cerrando demasiado despacio.
La aseguradora lee el alcance
La cobertura por fallo de contrato inteligente depende de una revisión documentada del código desplegado. «Le pasamos un modelo» no es un control, y los suscriptores han empezado a decirlo por escrito.
Usa la revisión con IA como un detector de humo: barato, siempre encendido, útil para lo evidente. No dejes que firme la inspección del edificio.
Garantía sin responsabilidad es teatro. Lo único que ha cambiado es que ahora el vestuario es buenísimo.
Por Qué Caen Equipos Competentes
Aquí no hace falta ninguno de los errores habituales, y eso es lo incómodo.
La salida se juzga por su fluidez
Los humanos valoran los documentos por estructura y tono. Un informe generado tiene mejor estructura y tono que la mayoría de los reales, porque es exactamente el eje en el que se optimizó.
Los resultados negativos son invisibles
Puedes contar los fallos que una herramienta encontró. No puedes contar los que decidió no mencionar, y ese número no aparece nunca en una comparativa de compra.
La fecha de lanzamiento quiere un tick verde
Las fechas necesitan un artefacto, no una conversación. Una herramienta que devuelve un informe limpio en noventa segundos es, organizativamente, dificilísima de rebatir.
Agotamiento por triaje
Después de treinta hallazgos fantasma, el trigésimo primero recibe una mirada más corta. La fatiga de alertas no es descuido: es la salida previsible de una mala relación señal-ruido.
La lección no es que la revisión con IA no valga nada. Es que es un linter con muy buena letra, y a un linter nunca se le ha permitido firmar una release.
Qué Hacer De Verdad
Ordenado por cuánto ayuda.
- Verifica al auditor antes de leer la auditoría. Firma con nombre, ingenieros con nombre, informe publicado en el dominio de la propia firma y un hash de commit que coincida con el bytecode desplegado. Dos de tres es un suspenso.
- Exige una prueba de concepto para cada hallazgo. Una vulnerabilidad real viene con una secuencia de transacciones reproducible o un test que falla. Las alucinaciones no pueden producirla, y por eso este es el filtro más barato que tienes.
- Nunca fusiones una remediación de IA sin revisión humana del diff. Trata un arreglo sugerido como un pull request no confiable de un desconocido seguro de sí mismo, rápido y que a veces inventa el problema que resuelve.
- Comprueba en el registro cada dependencia recomendada. Existencia, propietario, fecha de publicación, historial de descargas. Un paquete recién creado con exactamente el nombre que sugirió tu modelo es el ataque de slopsquatting, no una casualidad.
- Usa la IA como prefiltro, nunca como última puerta. Pásala antes que los humanos, para despejar lo obvio. El orden importa: una máquina delante de un especialista ahorra tiempo; una máquina en lugar de uno compra silencio.
Comprobaciones Para Esta Semana
Ninguna lleva mucho tiempo y todas se saltan.
Abre el sello de auditoría de los últimos tres proyectos en los que pusiste dinero
Sigue el enlace. Si no lleva a un informe en la web del propio auditor, invertiste contra una imagen.
Compara el hash del commit del informe con el código desplegado
Código verificado en el explorador frente al hash del informe. Bytecode distinto significa un contrato sin auditar guardando dinero de contrato auditado.
Revisa cada dependencia que un asistente te recomendó este mes
Página del registro, historial del mantenedor, primera fecha de publicación. Todo lo que tenga pocas semanas y un nombre sospechosamente perfecto se quita hoy.
Pide a tu revisor de IA una prueba de concepto de su propio hallazgo principal
Observa qué pasa cuando tiene que producir una ruta de explotación en vez de un párrafo. Ese es el test de fiabilidad y lleva cinco minutos.
Revisa el diff de cada «arreglo de seguridad» fusionado este trimestre
Busca específicamente guards eliminados, modificadores ampliados y comprobaciones reordenadas. Los bugs inducidos por remediación se esconden en commits que suenan tranquilizadores.
Una auditoría que no verificaste es un rumor con tipografía.
Checklist De Verificación De Auditorías con IA
Mejor al lado del memorándum de inversión que en un marcador que nunca abres.
Identifica la firma y los ingenieros con nombre; una garantía anónima no es garantía.
Encuentra el informe en el dominio del propio auditor, no un PDF alojado por el proyecto.
Compara el hash del commit auditado con el bytecode verificado realmente desplegado en cadena.
Lee primero la sección de alcance: lo excluido importa más que lo aprobado.
Exige una prueba de concepto reproducible para cada hallazgo crítico y alto.
Revisa toda remediación sugerida por IA como código no confiable antes de fusionarla.
Verifica que cada paquete recomendado existe, con mantenedores e historial reales.
Confirma que un especialista humano revisó la lógica económica y multi-contrato, no solo la sintaxis.
¿Recibiste un Mensaje Sospechoso?
Usa nuestro detector con IA para analizar posibles estafas al instante.
Conclusiones Clave
- 1La revisión con IA genera hallazgos porque el formato espera hallazgos; OWASP lo llama LLM09 Desinformación y trata el exceso de confianza como riesgo de seguridad.
- 2La proporción publicada de falsos positivos es brutal: unos treinta y nueve hallazgos inventados por cada real en los ajustes que detectan la mayoría de fallos genuinos.
- 3Las omisiones cuestan más que las invenciones: la lógica económica y las interacciones entre contratos son justo donde la revisión automática es más débil y por donde sale el dinero.
- 4Aplicar el arreglo de un fallo imaginario puede crear uno real; toda remediación de IA es un diff no confiable hasta que la lee un humano.
- 5Las dependencias alucinadas ya son una cadena de suministro: el 19,7% de los paquetes sugeridos no existía y hay unos 205.000 nombres inventados esperando registro.
- 6Un sello «auditado por IA» sin firma, sin alcance y sin hash de commit es marketing; verificar significa un humano con nombre aceptando un riesgo con nombre.
Un sello no es un guardaespaldas. Si nadie firma la auditoría con su nombre, lo único auditado es tu paciencia — y lo único vaciado, tu cartera.
Preguntas Frecuentes
Fuentes y Citas
Investigación compilada de datos de blockchain disponibles públicamente, informes de seguridad y documentación de la comunidad.
blog.openzeppelin.com
blog.trailofbits.com
docs.code4rena.com
Verificación: Todas las transacciones y direcciones de blockchain referenciadas en este artículo pueden verificarse de forma independiente a través de los exploradores de blockchain enlazados. Animamos a los lectores a realizar su propia verificación.
Metodología: Cada caso requiere al menos tres fuentes independientes más evidencia on-chain verificable antes de publicarse. Estándares completos: /es/methodology
Aviso legal: Esta evaluación se basa en datos disponibles públicamente, incluidos registros on-chain, comunicados oficiales e incidentes documentados. Es un análisis periodístico y educativo, no asesoramiento legal, una acusación de conducta delictiva ni una resolución judicial. Las empresas, proyectos, dominios, carteras y personas nombradas se describen según las fuentes citadas; una empresa puede aparecer porque fue suplantada por estafadores, no porque hiciera algo indebido. Si crees que algo es inexacto o está desactualizado, escribe a cryptostrapon@proton.me y lo corregiremos registrando el cambio. Política editorial