Auto Secure LoginPlataforma

¿El código escrito con IA es seguro? Riesgos y cómo revisarlo

El código escrito con IA suele funcionar al primer intento. Eso prueba que funciona, no que sea seguro. Trátelo como el código de un contratista nuevo con quien nunca ha trabajado: útil, y revisado antes de publicarlo.

Actualizado el 20 de octubre de 2026

Bastante seguro, con revisión

Los asistentes de programación con IA producen código probable, no código seguro garantizado. Aprendieron de ejemplos públicos, y muchos ejemplos están simplificados, desactualizados o no tienen protecciones. El código que una persona revisó, probó, cuyas dependencias se comprobaron, en el que se buscaron secretos y que se publicó con permisos limitados puede estar bien. El código pegado directamente en un producto en funcionamiento es un riesgo para el negocio: exposición de datos, caídas del servicio y arreglos de emergencia.

Patrones inseguros que la IA repite

  • SQL injection (inyección de SQL): la entrada del usuario se pega dentro de una consulta a la base de datos, así que una búsqueda o un inicio de sesión preparados con mala intención se convierten en un comando. Busque consultas armadas uniendo texto; use consultas parametrizadas.
  • Falta de autorización: el código comprueba que alguien inició sesión, pero no que la factura en /invoice/1007 sea suya. Pregunte: ¿qué impide que el usuario A llegue a los datos del usuario B?
  • Secretos escritos en el código: una clave de API de ejemplo que se reemplaza por una real y se sube al repositorio. Las claves van en un gestor de secretos.
  • Criptografía débil: métodos anticuados para guardar contraseñas, códigos de restablecimiento predecibles o cifrado hecho en casa. Use bibliotecas actuales y bien mantenidas.

Paquetes inventados y slopsquatting

A veces las herramientas de IA recomiendan paquetes de software que no existen. Los atacantes registran esos nombres con código malicioso y esperan a que alguien los instale, un truco apodado slopsquatting. Un estudio presentado en USENIX Security 2025 (en inglés) probó 16 modelos que generan código con 576,000 muestras y encontró que al menos el 5.2% de los paquetes sugeridos por modelos comerciales y el 21.7% de los sugeridos por modelos de código abierto eran inventados, con 205,474 nombres inventados distintos.

Antes de instalar algo que sugiere una IA, confirme que el paquete existe, que se mantiene y que se usa ampliamente para ese fin. Tenga el mayor cuidado con los comandos de instalación para copiar y pegar.

Bibliotecas desactualizadas y licencias

Los asistentes entrenados con ejemplos viejos pueden sugerir versiones antiguas o bibliotecas que ya se reemplazaron. Sus dependencias son parte de su producto: una falla conocida en una de ellas se convierte en su falla.

Cada dependencia también tiene una licencia. Algunas exigen avisos o compartir el código fuente. Una licencia inesperada puede retrasar un lanzamiento o complicar la venta del negocio, así que registre las dependencias y revise sus condiciones antes de publicar. Nuestra guía sobre de quién es el contenido hecho con IA trata la propiedad de lo que produce la IA.

"Funciona" no es lo mismo que "es seguro"

Una demostración prueba el camino ideal. No dice nada sobre datos faltantes o maliciosos, sesiones vencidas, solicitudes duplicadas, archivos demasiado grandes, pagos fallidos ni un usuario que hurga en los datos de otra persona. Pruebe esos casos a propósito.

Un proceso de revisión que un equipo pequeño puede seguir

  1. Revisión humana por alguien que entienda qué hace el código, qué datos toca y quién puede llegar a él.
  2. Escaneo de seguridad automatizado para detectar inyecciones, funciones inseguras y criptografía débil.
  3. Revisión de dependencias y un SBOM, una lista de cada componente, para poder reaccionar cuando una biblioteca reporta una falla.
  4. Pruebas de casos de falla: usuarios sin autorización, datos incorrectos, sesiones vencidas, errores de red.
  5. Búsqueda de secretos en el código, la configuración y los registros; cambie cualquier secreto real que encuentre, no se limite a borrarlo.
  6. Publicación con mínimo privilegio, para que una falla tenga poco a su alcance.

Las mismas reglas se aplican a las funciones de IA dentro de su app; vea el OWASP Top 10 para apps de IA.

Alguien tiene que hacerse cargo del código

La IA es una compañera para hacer borradores, no una autoridad. Asigne a una persona que entienda cada cambio, apruebe sus dependencias, revise las licencias y decida cuándo está listo. Pídale a la IA alternativas, explicaciones y pruebas, y luego verifique con criterio humano y con herramientas. Nuestra guía sobre el vibe coding explica los riesgos de publicar código que nadie leyó.

Dónde encaja ASL

En ASL, cada versión se reconstruye y se compara con lo que está funcionando antes de declararla publicada, y los conjuntos de pruebas controlan cada despliegue. Si su equipo construyó algo rápido con IA y quiere una segunda opinión, nuestro equipo de desarrollo de software a medida puede revisarlo en cuanto a seguridad, dependencias y casos de falla. Vea también desarrollo de apps con seguridad desde el primer día. Contáctenos para conversarlo.

Preguntas frecuentes

¿Es seguro usar código generado con IA?

Puede serlo, después de una revisión humana, un escaneo de seguridad, la revisión de dependencias, pruebas de casos de falla y la búsqueda de secretos. Nunca lo publique sin leerlo.

¿Qué es el slopsquatting?

Registrar nombres de paquetes que las herramientas de IA inventan y llenarlos de código malicioso, de modo que cualquiera que instale el paquete sugerido queda comprometido.

¿Con qué frecuencia las herramientas de IA inventan paquetes?

Un estudio de USENIX Security de 2025 encontró que al menos el 5.2% de los paquetes sugeridos por modelos comerciales y el 21.7% de los sugeridos por modelos de código abierto no existían.

¿Qué es un SBOM?

Un Software Bill of Materials (lista de materiales del software): una lista de cada componente de su software, para que pueda responder rápido cuando uno reporta una vulnerabilidad.

¿Cuál es la falla de seguridad más común en el código escrito con IA?

La falta de controles de autorización está entre las más dañinas: el código confirma que un usuario inició sesión, pero no que pueda ver ese registro en particular.

Guías relacionadas

Conozca el producto completo

Consulte funciones, acceso actual y límites

Help / Ayuda