¿Es seguro el código generado por IA? Los riesgos reales y qué cambia con la revisión

Sí, una vez que un ingeniero cualificado revisa cada línea, la prueba y verifica sus dependencias. No, tal como sale del modelo. La diferencia no es la IA. Es si alguien comprobó el trabajo antes de que tu empresa dependiera de él.

Esa respuesta es corta a propósito, porque la pregunta merece una respuesta franca antes que nada. Nuestra explicación más amplia sobre el vibe coding y el desarrollo asistido por IA solo le dedica un párrafo. Los riesgos, la revisión que los caza y las preguntas para un proveedor necesitan más espacio.

La lista honesta de riesgos: qué sale mal en el código IA sin revisar

Un modelo de IA no conoce tu negocio, y no carga con ninguna consecuencia cuando se equivoca. Predice código de apariencia plausible a partir de los patrones de sus datos de entrenamiento, y «de apariencia plausible» no afirma ni «correcto» ni «seguro». Estos son los cuatro modos de fallo que más se repiten en el código que nadie ha revisado.

Vulnerabilidades de seguridad. Los grandes modelos de lenguaje aprendieron de código público, errores incluidos. El 2025 GenAI Code Security Report, de Veracode, encontró vulnerabilidades de seguridad conocidas en el 45 % de las tareas de código analizadas: consultas de base de datos propensas a inyección, cross-site scripting, inyección en registros, criptografía débil. Ninguno de estos fallos es exótico. Son los mismos errores que los desarrolladores junior han cometido siempre, solo que producidos a velocidad de máquina. Para una empresa española, la factura no se detiene en el incidente técnico: en cuanto se filtran datos personales por una de estas grietas, y si la brecha entraña un riesgo para los derechos de las personas, el RGPD obliga a notificarla a la AEPD, por lo general en un plazo de 72 horas, y el caso pasa a ser tanto jurídico como informático. La AEPD explica cómo se notifica una brecha de datos personales.

Dependencias alucinadas. Pídele a un modelo de IA que resuelva un problema y a veces recomendará un paquete de software que no existe. Parece una instrucción de importación normal, se lee como plausible, y es ficticio. En un estudio presentado en USENIX Security 2025, la tasa media mínima de paquetes alucinados fue del 5,2 % en modelos comerciales y del 21,7 % en modelos de código abierto. Un atacante puede registrar un paquete real con ese nombre inventado, de modo que el siguiente desarrollador que «corrige» el error de importación instala malware en su lugar. Los investigadores de seguridad llaman ahora a este riesgo slopsquatting, y las sesiones de vibe coding sin revisar son su hábitat natural.

Errores de lógica sutiles. No todos los fallos se anuncian con un cuelgue. Un cálculo de descuento que redondea mal al pasar de la base imponible al total con IVA, un filtro de fechas que descarta en silencio el último día del mes, una comprobación de permisos que funciona para todos los roles menos para el que nadie probó: estos fallos salen limpios, funcionan durante semanas y solo emergen cuando un cliente nota que el total está mal. Un modelo de IA no tiene ningún interés en cazarlos, porque ya produjo una respuesta que parece terminada.

Deuda de mantenibilidad. Un código que nadie entiende es un pasivo incluso cuando hoy funciona. Los modelos de IA duplican con frecuencia la lógica en vez de reutilizarla, porque cada prompt recibe una respuesta nueva, sin memoria de lo que la base de código ya contiene. Seis meses después, un cambio pequeño en un sitio rompe algo sin relación, y el equipo que depura no tiene ningún autor a quien preguntar por qué el código original hacía lo que hacía.

Nada de esto es un argumento contra el código escrito por IA. Cada uno de estos cuatro problemas es exactamente lo que existe para cazar un paso de revisión, y ninguno exige instrumental exótico: basta con una persona que lea el resultado antes de la publicación.

Qué cambia cuando el código generado por IA se revisa

Un código asistido por IA y revisado es un producto distinto de una producción hecha con vibe coding, aunque el mismo modelo haya escrito los dos. Dos prácticas hacen el trabajo de verdad.

Un ingeniero humano lee cada línea. No una muestra, no las partes «que parecen arriesgadas»: cada línea, antes de la fusión. Las decisiones de arquitectura, las fronteras de seguridad y los casos límite siguen siendo decisiones de revisión, nunca aceptadas por la palabra del modelo. Es ahí donde se cazan los secretos escritos en el código, las validaciones ausentes y las dependencias sospechosas. Nuestra propia versión de esta práctica, sprint a sprint, está descrita en detalle en cómo definimos el alcance, construimos y revisamos.

El análisis de dependencias se ejecuta en cada build. Cada push y cada pull request dispara un análisis automatizado de dependencias, Dependabot más una auditoría de dependencias en el pipeline de CI, de modo que un paquete que arrastra un aviso de seguridad de nivel moderado o superior hace fallar el build en lugar de llegar a producción. Es ahí donde una dependencia alucinada o comprometida se caza aunque un revisor la haya pasado por alto en el diff.

Una cosa merece decirse con franqueza, porque los proveedores no siempre lo son. No ofrecemos test de intrusión dentro de una construcción estándar. Si un proyecto necesita una evaluación de seguridad independiente, lo nombramos en el alcance y ayudamos a organizarla, la misma transparencia que cómo aseguramos cada construcción muestra por entero.

Esa franqueza es el punto central. Un proveedor que te dice exactamente qué controles se ejecutan, y cuáles no, es un proveedor cuyas demás afirmaciones puedes creer. Un proveedor que agita una «seguridad de nivel empresa» sin nombrar una sola práctica te pide el mismo salto de fe que un modelo de IA sin revisar ya da sobre su propia producción.

Cómo evaluar las prácticas de seguridad reales de un proveedor

Todos los talleres de desarrollo con IA te dirán que su código es seguro. Pocos saben describir cómo lo saben. Antes de las preguntas, sitúa el marco legal, porque en España delimita la conversación entera.

Empieza por el RGPD. Si el software trata datos personales, el responsable del tratamiento eres tú, no tu proveedor y desde luego no el modelo. Ante la Agencia Española de Protección de Datos (AEPD), «lo escribió una IA» no es una defensa: la obligación de aplicar medidas de seguridad apropiadas y de proteger los datos desde el diseño sigue siendo tuya, la haya tecleado quien la haya tecleado. El RGPD exige que las medidas técnicas y organizativas se definan durante todo el ciclo de vida del tratamiento y que la protección de datos se incorpore desde el diseño.

Encima está el Reglamento europeo de Inteligencia Artificial (AI Act), el Reglamento (UE) 2024/1689, que fija obligaciones según el nivel de riesgo de cada sistema de IA. Aquí conviene deshacer una confusión que sale cara: el Reglamento regula los sistemas de IA que se comercializan, se ponen en servicio o se utilizan, no el hecho de que un software se escribiera con ayuda de IA. Si el producto que te entregan incorpora funciones de IA, su categoría de riesgo pesa en tus obligaciones. En España, la Agencia Española de Supervisión de la Inteligencia Artificial (AESIA) es una de las autoridades que vigilan su aplicación. Si tu software se escribió con IA pero el producto resultante no incorpora IA, un proveedor que insinúe que el Reglamento te alcanza igualmente por esa sola vía vende miedo. El RGPD, en cambio, se aplica en los dos casos, desde el primer dato personal. El Esquema Nacional de Seguridad (ENS, Real Decreto 311/2022) se suma si vas a trabajar con el sector público o para él, y también la Directiva NIS2 si operas en un sector esencial o importante, donde la seguridad de la cadena de suministro alcanza también al software a medida que encargas.

Con el marco sobre la mesa, lleva estas preguntas a una llamada de alcance y escucha los detalles, no los adjetivos.

• ¿Quién lee el código, y cuándo? Quieres un rol nombrado (un ingeniero sénior, no «el equipo») y una etapa (antes de la fusión, no «en algún momento»). «Nuestro proceso lo revisa» no es una respuesta; «un ingeniero lee cada línea antes de la fusión» sí lo es.
• ¿Qué herramientas se ejecutan en cada build, y qué comprueban de verdad? El análisis de dependencias es común y verificable: pregunta qué herramienta, y si un control fallido bloquea una publicación o solo registra un aviso.
• ¿Qué no hacéis? Un proveedor que nombra sus límites, sin test de intrusión de serie, sin tal certificación, sean cuales sean los suyos, te dice algo verdadero. Un proveedor sin ningún límite no lo revisa nadie, tú incluido.
• ¿A quién pertenece el código una vez entregado? Seguridad y propiedad son preguntas ligadas. Un proveedor que te cede la plena propiedad del código no tiene ningún interés en esconder un atajo en una base de código que te entregará entera.
• ¿Por dónde pasa mi código, y dónde viven mis datos? El proveedor envía tu base de código a un modelo alojado en algún sitio. Pregunta en cuál, bajo qué contrato, y si tus datos de producción llegan a transitar por él. Un proveedor que no tiene la respuesta no ha leído sus propias condiciones de uso, y a la AEPD esa excusa no le interesará.
• ¿Puedo llevar a mi propio asesor técnico a la llamada? Un proveedor seguro de sus prácticas recibe bien un segundo par de ojos. El que se resiste a la idea también te dice algo.

Construimos nuestra página de seguridad en torno a esta prueba exacta: enunciar las prácticas con la claridad suficiente para que tu asesor pueda verificarlas, y decir con claridad lo que no hacemos. Pasa las afirmaciones de cualquier proveedor, las nuestras incluidas, por el mismo filtro.

Señales de alerta: cuando un proveedor no sabe responder a estas preguntas

Algunas respuestas son peores que ninguna respuesta.

«Nuestra IA escribe código seguro por defecto.» Ningún modelo lo hace. Esta afirmación contradice el hallazgo de Veracode de arriba y todos los demás estudios independientes sobre el tema. Un proveedor que la repite no ha leído la investigación, o espera que tú no la hayas leído.

Tranquilización vaga en lugar de una práctica nombrada. «Nos tomamos la seguridad en serio» y «protección de nivel empresa» no describen nada verificable. Pregunta qué significan esas fórmulas en la práctica, y observa si la respuesta se vuelve más concreta o más abstracta.

Certificaciones que nadie puede mostrar. «Nivel bancario» y «nivel militar» son adjetivos de marketing, no normas. Si un proveedor reivindica la ISO 27001, la certificación del ENS o, en el caso de un proveedor SaaS estadounidense, un informe SOC 2, pide verlo: un certificado lleva un organismo, un número y una fecha de caducidad. Si no puede mostrarlo, no lo tiene. Desconfía también del «cumplimos el RGPD» enarbolado como un sello. No existe un certificado genérico de cumplimiento del RGPD que se exhiba a demanda como un ISO 27001; el RGPD es una obligación legal, no un trofeo, y agitarlo como una insignia suele delatar que no se ha trabajado.

Ninguna respuesta a «qué no hacéis». Toda práctica de seguridad real tiene una frontera. Un proveedor incapaz de nombrar la suya no es más seguro. Es menos concreto, que es otra cosa, disfrazada de seguridad.

Silencio sobre quién revisa la producción. Si un proveedor no puede describir su proceso de revisión en una frase clara, probablemente no exista uno. Esa única carencia pesa más que casi cualquier otra señal de alarma, porque es la práctica de la que dependen todos los demás guardarraíles.

Preguntas frecuentes sobre la seguridad del código IA

Haz las preguntas difíciles antes de firmar

La posición más segura con cualquier proveedor, nosotros incluidos, es preguntar exactamente quién revisa tu código y qué pasa cuando un control falla. Describe lo que necesitas construir y responderemos a las dos preguntas en la primera llamada, junto con un alcance cerrado, un precio cerrado y una fecha de entrega.

Pide un presupuesto cerrado →