¿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. Lo que sigue es la versión larga: qué sale mal de verdad cuando el código generado por IA se publica sin revisar, qué caza un proceso de revisión real y qué preguntarle a un proveedor antes de confiarle el tema. Si llegas desde nuestra explicación más amplia sobre el vibe coding y el desarrollo asistido por IA, aquí tienes el desarrollo a fondo de una pregunta que allí solo recibe un párrafo.

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". Entre los riesgos documentados o plausibles del código generado por IA están las vulnerabilidades de seguridad, las dependencias inexistentes, los errores lógicos y los problemas de mantenibilidad; su frecuencia depende del modelo, del contexto y de los controles aplicados. 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. Un informe de Veracode, elaborado por una empresa comercial y basado en su propia metodología, el 2025 GenAI Code Security Report, comunicó vulnerabilidades de seguridad conocidas en el 45 % de las muestras de código analizadas: validaciones de entrada ausentes, consultas de base de datos propensas a inyección, credenciales escritas en el propio código en texto plano; ese porcentaje no debe generalizarse a todo el código generado por IA sin describir la muestra y el método. Ninguno de estos fallos es exótico. Son los mismos errores que los desarrolladores junior han cometido siempre, y pueden producirse a gran velocidad y en grandes volúmenes, por lo que la revisión humana y las pruebas siguen siendo necesarias. 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 indica que el responsable debe notificar una brecha a la autoridad de control cuando sea probable que suponga un riesgo para los derechos y libertades de las personas, con ese plazo general de 72 horas desde que se tiene constancia de ella.

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; estas cifras corresponden a las condiciones y al conjunto de modelos evaluados por ese estudio en concreto. La literatura de seguridad ha identificado el riesgo de que un atacante registre un paquete con un nombre sugerido por un modelo pero inexistente en el registro, de modo que el siguiente desarrollador que "corrige" el error de importación instalaría malware en su lugar; esto no debe presentarse como una práctica universal ni como prueba de que cada paquete alucinado haya sido registrado con fines maliciosos. 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. Una revisión humana competente puede detectar secretos escritos en el código, validaciones ausentes o dependencias sospechosas, aunque no garantiza por sí sola la ausencia de vulnerabilidades: se combina con pruebas, análisis automatizados y controles de dependencias. 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 establece normas armonizadas para el desarrollo, la introducción en el mercado, la puesta en servicio y la utilización de sistemas de IA, con obligaciones que dependen, entre otros factores, del nivel de riesgo del sistema. Aquí conviene deshacer una confusión que sale cara: el Reglamento se centra en los sistemas de IA introducidos en el mercado, puestos en servicio o utilizados, no en el simple hecho de que un software se escribiera con ayuda de IA; el uso de una herramienta de IA durante la programación no basta por sí solo para determinar la aplicabilidad, hay que analizar el sistema o producto resultante, los roles y las actividades concretas. Si el producto que te entregan incorpora funciones de IA, su categoría de riesgo pesa en tus obligaciones. La aplicación del Reglamento implica varios órganos y autoridades competentes; la Agencia Española de Supervisión de la Inteligencia Artificial (AESIA) participa en el marco español, pero la autoridad competente concreta debe determinarse según la función y el sector afectados. 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) puede resultar aplicable a las entidades y relaciones comprendidas en su ámbito jurídico si vas a trabajar con el sector público o para él, aunque conviene verificar el alcance concreto del propio Real Decreto y del contrato en lugar de darlo por automático; suma 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 todo lo demás de la lista, porque es la práctica de la que dependen todos los demás guardarraíles.

Preguntas frecuentes sobre la seguridad del código IA

¿Es seguro usar código generado por IA en producción?

Puede serlo, una vez que un ingeniero revisa cada línea, las dependencias se analizan y el software se prueba contra criterios de aceptación reales. No es seguro por defecto. El código IA sin revisar sale con frecuencia con exactamente las vulnerabilidades descritas más arriba.

¿Cuál es el mayor riesgo de seguridad del código generado por IA?

La validación de entrada ausente o débil y las credenciales escritas en el código están entre los hallazgos más frecuentes: el informe de Veracode de 2025 los comunicó en el 45 % de las muestras que analizó, con su propia metodología. Dos errores antiguos y bien entendidos, que todo proceso de revisión de código está hecho para cazar.

¿Puede el código generado por IA contener dependencias falsas o alucinadas?

Sí. Los modelos recomiendan a veces paquetes de software que no existen, un problema documentado que los investigadores llaman alucinación de paquetes. Existe el riesgo de que un atacante registre un paquete malicioso bajo uno de esos nombres, así que instalar el "arreglo" podría instalar malware. El análisis de dependencias y la revisión lo cazan los dos.

¿Bastan las herramientas automáticas para hacer seguro el código generado por IA?

Ninguna herramienta por sí sola garantiza la seguridad. La revisión humana de cada línea y el análisis automatizado de dependencias son las prácticas que hacen el trabajo de verdad hoy en Globaprom. Pregunta a cualquier proveedor qué controles se ejecutan exactamente, y cuáles no, en lugar de creerte una lista de herramientas.

¿Cómo sé si un proveedor revisa de verdad el código generado por IA?

Pregunta quién lee el código y cuándo, en una frase. Una respuesta real nombra un rol y una etapa: un ingeniero, antes de cada fusión. Un proveedor que no puede responder con esa precisión probablemente no tenga ningún paso de revisión.

¿El código generado por IA es más o menos seguro que el que escribe una persona desde cero?

Ni una cosa ni la otra, por sí solo. La seguridad viene de la revisión y de las pruebas, no de quién o qué tecleó el primer borrador. El código IA revisado y el código humano revisado acaban seguros por la misma razón: alguien lo comprobó.

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 →