Año Uno de las Aplicaciones de IA: ¿Solo sabe decir "sí", ignorando los riesgos? El cuaderno de bitácora del desarrollo de software se abre por completo

marsbit发布于2026-06-16更新于2026-06-16

文章摘要

El año de la IA aplicada: ¿Solo "sí" y sin considerar riesgos? El diario de navegación del desarrollo de software se abre por completo. El rápido aumento del uso de IA para generar código, con menos supervisión, introduce riesgos ocultos en código aparentemente correcto, lo que puede provocar pérdidas de datos o activos. El proyecto de código abierto **Narwhal AI Code Risks**, de Narwhal-Lab (Universidad de Pekín), recopila casos reales, señales tempranas y rutas de riesgo típicas para ayudar a los desarrolladores a identificar peligros. Un ejemplo claro es el incidente de configuración del oráculo cbETH de Moonwell, donde un error semántico en un precio (1.12 USD en lugar de ~2200 USD) pasó todas las revisiones y causó una pérdida de ~1.78 millones de dólares. El riesgo no siempre se muestra con errores; a menudo, el código funciona pero su semántica es errónea. La IA ya no solo completa código, sino que modifica configuraciones, gestiona dependencias y actúa mediante agentes, creando cadenas de acciones más largas y difíciles de rastrear. Los riesgos se clasifican en 7 categorías: cadena de suministro, vulnerabilidades a nivel de código, configuración de nube/infraestructura, riesgos de agentes, riesgos en dominios verticales, propiedad intelectual/cumplimiento y factores humanos. El proyecto organiza la información en tres niveles: `cases/` (eventos reales verificados), `inferred/` (señales tempranas por confirmar) y `scenarios/` (patrones de riesgo claros). Su objetiv...

Los riesgos de que la IA escriba código se esconden en código aparentemente correcto, pudiendo provocar fugas de datos o pérdida de activos. El proyecto de código abierto Narwhal AI Code Risks ha recopilado casos reales, señales tempranas y rutas de riesgo típicas para ayudar a los desarrolladores a identificar peligros con antelación y evitar cometer los mismos errores.

En 2026, el código se genera a un ritmo cada vez mayor, pero se despliega con cada vez menos revisión.

Cada vez más, los requisitos del usuario se introducen en un cuadro de diálogo, la IA lee el contexto, completa funciones, añade dependencias, ajusta configuraciones y genera pruebas de paso.

Cuando te das cuenta, ya hay un fragmento de código en el repositorio, esperando a ser fusionado.

Los usuarios ya han adquirido el nuevo hábito: primero dejar que la IA lo escriba y lo haga funcionar, y si hay problemas, entonces ver qué hay que cambiar.

Pero en el mundo del software, lo más peligroso suele ser el código que parece anodino: sintácticamente correcto, con interfaces legales, pruebas aprobadas, comentarios perfectos.

Sin embargo, aún puede introducir nombres de paquetes que no existen, abrir permisos excesivos, exponer bases de datos... o incluso permitir que un agente que puede llamar directamente a herramientas del sistema, bajo un ataque de inyección de prompt, saque datos sensibles de un sistema interno.

Lo realmente peligroso no es que se encienda una luz de error, sino que todos los indicadores de riesgo muestren normalidad.

Hasta ahora, los riesgos de que la IA escriba código estaban dispersos por todas partes: un caso escondido en un blog de seguridad, una pista registrada en un Issue. Cuando el siguiente equipo se enfrentaba a un problema similar, tenía que reconstruir desde cero el origen del riesgo y dedicar una enorme cantidad de tiempo y esfuerzo a realizar mediciones empíricas a gran escala del código.

El Narwhal AI Code Risks, recientemente abierto por el Narwhal-Lab de la Universidad de Pekín, ya ha organizado estos fragmentos de información, clasificándolos en tres tipos: eventos reales, señales tempranas y rutas de riesgo típicas, para que los investigadores puedan consultarlos.

Enlace del paper: https://github.com/Narwhal-Lab/Narwhal-aicode-risks

Cuando pasan las 28 comprobaciones, el sistema aún se desvía

La primera pista fue un Pull Request ya fusionado, cuyo campo de autoría mostraba claramente a Claude Opus 4.6 y Copilot, junto con cuatro desarrolladores humanos. Las 28 comprobaciones se aprobaron: nadie detectó el problema.

Luego, un bot de liquidación tardó unos minutos en tomar una garantía valorada en 1,778,044.83 dólares.

El precio de cbETH en el archivo de configuración se estableció en la tasa de conversión con ETH, aproximadamente 1.12 dólares, en lugar de su precio real cercano a los 2,200 dólares.

Así, un error semántico de precio atravesó todo el proceso de desarrollo, revisión y fusión, convirtiéndose finalmente en una pérdida real en el sistema financiero. Este es el aspecto más llamativo del incidente de configuración del oráculo de Moonwell cbETH.

El problema radica en que el código no presentaba errores de sintaxis y los desarrolladores humanos no bloquearon de inmediato el flujo anómalo. Al contrario, parecía completo, fluido, era una entrega de ingeniería normal.

Pero precisamente esta aparente normalidad bajo la superficie lo convierte en un ejemplo típico de incidente de seguridad.

El riesgo de la codificación con IA radica en que no siempre se manifiesta como un error.

Muchas veces, se viste con la apariencia de una respuesta correcta y entra silenciosamente en el flujo de ingeniería. El código funciona, las comprobaciones pasan, el PR se fusiona, pero la semántica del negocio ya se ha desviado del mundo real.

En proyectos de bajo riesgo, esta desviación semántica puede ser solo una reelaboración; pero en escenarios sensibles como finanzas o sistemas de datos empresariales, provocará directamente filtraciones de datos, exposición de permisos y pérdida de activos.

Cuando la IA participa escribiendo código, modificando configuraciones, haciendo revisiones, o incluso firmando conjuntamente en los PR, ¿tenemos la suficiente certeza de saber cómo ocurre cada desviación?

Señales verdes de paso que no iluminan todos los rincones

Al principio, la IA que ayudaba a escribir código se limitaba principalmente a completar fragmentos locales. Si la sintaxis era incorrecta, el compilador mostraba un error, las pruebas unitarias fallaban y el flujo de CI lo rechazaba.

Hoy en día, la codificación con IA va mucho más allá, mientras que la supervisión tarda en llegar.

Puede leer archivos, modificar configuraciones, instalar dependencias, generar scripts de infraestructura, y también, a través de agentes, planificar de forma autónoma entre múltiples tareas.

La IA ya no se limita a estar al lado pasando herramientas; ha comenzado a integrarse en cadenas más largas de la ingeniería de software.

Los límites originalmente claros en la ingeniería de software han sido reconectados por los agentes de IA en rutas más largas y difíciles de rastrear.

Registros dispersos que necesitan un cuaderno de bitácora público

Los incidentes de seguridad rara vez tienen conclusiones completas desde el principio. Algunos tienen pruebas suficientes y pueden entrar en el directorio como casos reales; otros se quedan en capturas de pantalla de la comunidad, discusiones entre investigadores o divulgaciones preliminares, y solo son adecuados para seguir observándolos; otros más no están vinculados a un solo evento real, pero ya han formado un patrón claro, adecuado para realizar simulaciones preventivas.

Narwhal AI Code Risks divide el material en tres capas: `cases/`, `inferred/` y `scenarios/`.

cases/ registra eventos reales con fuentes públicas y una cadena de evidencias que los respalda; inferred/ guarda señales tempranas que aún no están completamente confirmadas, pero que merecen un seguimiento continuo; scenarios/ organiza escenarios típicos que no están vinculados a un solo evento, pero cuya ruta de riesgo es lo suficientemente clara.

Sin un registro público como este, los riesgos de la codificación con IA pueden convertirse fácilmente en recuerdos a corto plazo en internet.

Hoy se recuerda un nombre de paquete, mañana se discute una exposición de datos, y en unos meses queda sepultado por la nueva ola de herramientas. Cuando surge un problema similar de nuevo, el equipo sigue entrando como una mosca ciega en zonas de navegación de riesgo desconocido.

Lo que hace Narwhal AI Code Risks es fijar estos fragmentos dispersos de riesgo, para que quienes vengan después puedan consultar la misma página.

Siguiendo siete tipos de índice, ver el camino del riesgo

Los problemas que trae la escritura de código por IA no están solo en el código. Están en las dependencias, en los permisos, en las llamadas a herramientas de los agentes, y aún más, en la forma en que los humanos confían en la salida de la IA.

Actualmente, Narwhal AI Code Risks divide los riesgos en 7 categorías: cadena de suministro (supply chain), vulnerabilidades a nivel de código, configuración de la nube e infraestructura, riesgos de agentes, riesgos de dominio vertical, riesgos de propiedad intelectual y cumplimiento normativo, y factores humanos.

En los riesgos de cadena de suministro, la IA puede recomendar dependencias que no existen. En las vulnerabilidades a nivel de código, la IA puede volver a introducir en el código de negocio problemas como el recorrido de rutas (path traversal), la falta de validación de entradas o problemas de autorización. En la configuración de la nube y la infraestructura, la IA puede otorgar permisos excesivos, buckets de almacenamiento públicos o puertos expuestos con tal de hacer funcionar el código. Los riesgos de los agentes son aún más complejos, ya que no solo generan texto, sino que comienzan a ejecutar acciones. Los artefactos generados por la IA están sembrando peligros en sistemas reales.

El motor de la IA está encendido, y el cuaderno de bitácora acaba de abrirse

Cuando la IA avanza paso a paso hacia el mundo real, la prevención y gestión de sus riesgos asociados no debería limitarse a análisis posteriores a los hechos o a discusiones dispersas.

Lo realmente importante de Narwhal AI Code Risks es convertir los casos de riesgo en conocimiento reutilizable.

Los desarrolladores pueden usarlo para identificar problemas similares; los investigadores en seguridad pueden tomarlo como una biblioteca de muestras; los fabricantes de herramientas pueden extraer de él reglas de detección y puntos de referencia para evaluaciones; la comunidad de código abierto también puede seguir complementándolo con nuevos casos, nuevas evidencias y nuevos tipos de riesgo.

El motor de la IA está rugiendo, y cada desviación también debería dejar sus coordenadas. El riesgo nunca desaparece por ser ignorado, pero la experiencia puede ser registrada y transmitida. Lo verdaderamente valioso no es descubrir una vulnerabilidad, sino evitar que quienes vengan después tengan que caer en la misma trampa.

Lo que Narwhal AI Code Risks está haciendo es dejar un cuaderno de bitácora de código abierto para el mundo del software en el Año Uno de las Aplicaciones de IA.

Referencias:

https://github.com/Narwhal-Lab/Narwhal-aicode-risks

Este artículo procede del WeChat público "新智元" (New Zhi Yuan), autor: LRST

相关问答

Q¿Cuál es el propósito principal del proyecto Narwhal AI Code Risks recién publicado?

AEl proyecto Narwhal AI Code Risks tiene como propósito recopilar y organizar casos reales, señales tempranas y rutas típicas de riesgo asociadas al código generado por IA. Sirve como un registro público y de código abierto (un "diario de navegación") para ayudar a los desarrolladores a identificar riesgos ocultos de manera temprana, evitar errores repetidos y convertir la experiencia en conocimiento reutilizable para la comunidad.

QSegún el artículo, ¿por qué el código generado por IA puede ser particularmente peligroso incluso cuando parece correcto?

AEl código generado por IA puede ser peligroso porque a menudo parece sintácticamente correcto, pasa las pruebas y las revisiones, pero puede contener errores semánticos sutiles, como configuraciones incorrectas (ej. precio de un activo), permisos excesivos, dependencias inexistentes o vulnerabilidades de seguridad. El riesgo no se manifiesta como un error de compilación, sino como una desviación funcional que puede causar pérdidas financieras, fugas de datos o exposiciones del sistema en escenarios críticos.

Q¿En qué consistió el incidente real de Moonwell cbETH mencionado como ejemplo en el texto?

AEl incidente de Moonwell cbETH fue un caso real en el que un Pull Request (creado con ayuda de IA como Claude y Copilot) que modificaba un archivo de configuración fue aprobado tras pasar 28 verificaciones. El error consistió en que el precio de cbETH se configuró incorrectamente en aproximadamente 1.12 dólares (la relación de conversión con ETH) en lugar de su valor real cercano a los 2,200 dólares. Este error semántico permitió que un bot de liquidación reclamara garantías por un valor de 1,778,044.83 dólares, demostrando cómo un fallo no sintáctico puede causar grandes pérdidas.

Q¿Cómo clasifica el proyecto Narwhal AI Code Risks los diferentes tipos de materiales o evidencias de riesgo?

AEl proyecto clasifica los materiales en tres categorías principales almacenadas en directorios distintos: 1) `cases/`: registra eventos reales con fuentes públicas y cadenas de evidencia sólidas. 2) `inferred/`: conserva señales tempranas que aún no están completamente confirmadas pero merecen seguimiento. 3) `scenarios/`: recopila escenarios típicos con rutas de riesgo claras, que no están vinculados a un único evento pero son representativos.

Q¿Cuáles son las siete categorías principales de riesgo identificadas por el proyecto Narwhal AI Code Risks?

ALas siete categorías principales de riesgo son: 1) Riesgos en la cadena de suministro (Supply Chain), 2) Vulnerabilidades a nivel de código, 3) Configuración de la nube e infraestructura, 4) Riesgos de Agent (agentes de IA que ejecutan acciones), 5) Riesgos en dominios verticales (como finanzas o salud), 6) Riesgos de propiedad intelectual y cumplimiento normativo, y 7) Factores humanos (como la confianza excesiva en la salida de la IA).

你可能也喜欢

XRP Ledger 发布 3.2.0 版本升级并启用 XRPLd 新品牌名

XRP Ledger发布了3.2.0版本,这是对其底层区块链基础设施的一次重要升级。本次更新的核心是将运行网络的软件名称从“rippled”更名为“xrpld”,以更好地反映整个项目生态。 与此前侧重于前端功能的版本不同,3.2.0版本优先进行了后端升级和效率提升,旨在增强网络性能并为未来的扩展做准备。关键改进包括内存优化措施,预计可节省高达40%的服务器内存使用。 此次升级引入了名为“fixCleanup3_2_0”的修改,为单资产金库、借贷协议、权限系统、去中心化交易所、多用途代币和权限域等多个模块带来了安全性增强。开发团队还新增了不变性检查,以确保已删除账户不会在账本上留下不一致的数据,从而加强整个网络的完整性和可靠性。 对于开发者而言,新版本增加了一项重要功能:应用程序无需连接服务器即可检索XRP Ledger协议和服务器定义信息,这将极大便利钱包、区块链浏览器和API等的开发工作。 在可扩展性和稳定性方面,更新包括可配置的区块大小、通过nuDB实现的高效数据库存储,以及将gRPC服务器的TLS/双向TLS支持改为可选,以提升企业用户的性能和连接性。此外,默认对等端口从51235更改为2459,并修复了涉及自动做市商、支付、代币托管、多用途代币、订单簿和RPC等多个方面的问题。出于性能考虑,3.2.0版本暂时禁用了交易不变性检查,但开发团队表示这不会构成安全威胁。

TheNewsCrypto4小时前

XRP Ledger 发布 3.2.0 版本升级并启用 XRPLd 新品牌名

TheNewsCrypto4小时前

交易

现货
合约

热门文章

如何购买S

欢迎来到HTX.com!我们已经让购买Sonic(S)变得简单而便捷。跟随我们的逐步指南,放心开始您的加密货币之旅。第一步:创建您的HTX账户使用您的电子邮件、手机号码注册一个免费账户在HTX上。体验无忧的注册过程并解锁所有平台功能。立即注册第二步:前往买币页面,选择您的支付方式信用卡/借记卡购买:使用您的Visa或Mastercard即时购买Sonic(S)。余额购买:使用您HTX账户余额中的资金进行无缝交易。第三方购买:探索诸如Google Pay或Apple Pay等流行支付方法以增加便利性。C2C购买:在HTX平台上直接与其他用户交易。HTX场外交易台(OTC)购买:为大量交易者提供个性化服务和竞争性汇率。第三步:存储您的Sonic(S)购买完您的Sonic(S)后,将其存储在您的HTX账户钱包中。您也可以通过区块链转账将其发送到其他地方或者用于交易其他加密货币。第四步:交易Sonic(S)在HTX的现货市场轻松交易Sonic(S)。访问您的账户,选择您的交易对,执行您的交易,并实时监控。HTX为初学者和经验丰富的交易者提供了友好的用户体验。

2.6k人学过发布于 2025.01.15更新于 2026.06.02

如何购买S

相关讨论

欢迎来到HTX社区。在这里,您可以了解最新的平台发展动态并获得专业的市场意见。以下是用户对S(S)币价的意见。

活动图片