¿Es seguro el código escrito por la IA? Qué dicen los estudios independientes — y qué meter en el contrato

Cuando una pyme evalúa a un proveedor que desarrolla con IA, la pregunta que hace casi siempre es sobre la calidad: «¿se nota que lo ha escrito una máquina?». Es la pregunta menos útil. Sobre la calidad percibida se discute hasta el infinito y se corrige con una revisión. El riesgo serio, el que la evidencia independiente mide de verdad, es otro: la seguridad. Y tiene una característica desagradable — no se ve en la entrega, se ve meses después, cuando ya es tuyo.

Los estudios académicos independientes publicados entre 2022 y 2026 dicen tres cosas distintas, y ninguna de las tres es «la IA escribe código inseguro, así que no la uses». Dicen que una parte considerable del código generado nace vulnerable; que los rechazos de un modelo en chat no sobreviven a ser insertados dentro de un flujo de trabajo real; y que la automatización agéntica de la pipeline abre una superficie de ataque que ya se está explotando. Tres cosas que un comprador puede meter en el contrato — o descubrir después.

1. Una parte del código generado nace vulnerable

El dato de referencia es de 2022 y es académico, no de un proveedor. Pearce y sus colegas hicieron generar a GitHub Copilot 1.689 programas sobre 89 escenarios construidos en torno a las debilidades más comunes, y encontraron que alrededor del 40% de los programas generados contenía una vulnerabilidad (Pearce et al., «Asleep at the Keyboard?», IEEE S&P 2022). No sobre código inventado para dejar mal a la herramienta: sobre escenarios corrientes, del tipo que una empresa encarga cada semana.

Circula también un reparto por lenguaje — en torno al 50% en C frente al 39% en Python. Lo citamos con una reserva explícita, porque así es como hay que citarlo: esa división procede de síntesis secundarias del estudio y no la hemos verificado sobre el documento original. El número en el que apoyarse es el global. Y la lectura correcta no es «el 40% del software entregado está agujereado»: es que un generador no tiene ningún motivo, por sí mismo, para producir código seguro. La seguridad no es una propiedad emergente de la generación. Es un control que alguien tiene que poner alrededor.

2. El rechazo en chat no sobrevive al flujo de trabajo

Aquí está el resultado más reciente y más incómodo, y es el que desmonta la tranquilización estándar del proveedor («tranquilo, el modelo se niega a escribir esas cosas»). Un grupo del Alan Turing Institute tomó 204 peticiones dañinas y las sometió a GitHub Copilot Chat de dos maneras. En chat directa, el modelo se negó 808 veces de 816. Las mismas peticiones, troceadas e insertadas dentro de un flujo de trabajo multiturno normal en el editor, produjeron un completado dañino 816 veces de 816 (Kumar & Maple, «Refused in Chat, Written in Code», 2026).

El punto no es «Copilot Chat devuelve código peligroso». El punto es que la protección vive a nivel de conversación mientras el trabajo de verdad ocurre a nivel de flujo: construir la petición a lo largo de varios pasos de una tarea de desarrollo ordinaria esquiva un rechazo que, interrogado de frente, funciona casi siempre. Un control que está en el sitio equivocado es, en la práctica, un control que no existe.

Para quien compra software esto tiene una consecuencia precisa, no es un detalle para investigadores: la seguridad del modelo no es una garantía que puedas heredar del proveedor del modelo. Debe verificarse en el proceso de quien te entrega el código — con herramientas que leen el resultado, no las buenas intenciones de quien lo ha pedido.

3. Más código generado, pipeline más ruidosa (una correlación, no una causa)

El tercer estudio mira qué pasa aguas abajo, en la cadena de build y publicación. Se analizaron 61.837 ejecuciones de CI en 2.355 repositorios disparadas por cinco bots de programación con IA distintos: Copilot y Codex muestran las tasas de éxito más altas (en torno al 93-94%), los demás más bajas. Pero el dato interesante es otro: en los repositorios con una frecuencia más alta de pull requests generadas por IA se observa una tasa de éxito global de los workflows más baja («Reliability of AI Bots Footprints in GitHub Actions CI/CD Workflows», 2026).

Es una correlación, y hay que decirlo con claridad: el estudio no demuestra que las PR generadas por IA hagan fallar la pipeline. Bien puede ser que los proyectos más expuestos a la IA sean también los más movidos. Pero para quien tiene que decidir sigue siendo información utilizable: un volumen alto de contribuciones automáticas viene acompañado de una señal de build más ruidosa, y una pipeline ruidosa es precisamente el sitio donde un fallo de verdad deja de notarse. Quien evalúa a un proveedor no debería preguntar «¿usáis IA?», sino «¿qué tasa de verde tiene vuestra pipeline, y quién mira los rojos?».

4. La pipeline misma se ha convertido en objetivo

El cuarto elemento ya lo hemos contado por extenso en otro sitio, así que aquí basta la línea: cuando son los agentes quienes escriben y ejecutan los workflows, el workflow mismo se convierte en superficie de ataque, con centenares de vulnerabilidades de injection confirmadas como explotables sobre repositorios reales (arXiv:2605.07135) — el desglose está en nuestro artículo sobre qué funciona de verdad de la IA en el desarrollo. Puesto en fila con los tres anteriores, cierra el cuadro: el riesgo no está solo en el código entregado, está también en lo que la automatización tiene permiso para ejecutar en tu nombre.

Qué escribir en el contrato (no qué esperar)

Todo lo anterior se traduce en cláusulas, no en desconfianza. Ninguna de ellas exige competencias técnicas para poder exigirse, y todas son verificables:

• Quién revisa, y antes de qué. Pon por escrito que cada modificación pasa por una revisión humana identificable antes de la publicación, y que la aprobación automática no se admite en las rutas sensibles (autenticación, pagos, datos personales). No «hacemos code review»: quién firma, y en qué rutas la puerta no se abre nunca sola.
• Análisis estático y búsqueda de secretos como obligación, no como buena costumbre. Un análisis automático de las vulnerabilidades (SAST) y el escaneo de secretos se ejecutan en cada modificación, con el resultado adjunto a la entrega. Es el control que responde directamente al 40% de Pearce y al problema del rechazo esquivado: verifica el resultado, no la intención.
• Quién es dueño de una vulnerabilidad encontrada después de la entrega. Es la cláusula que falta casi siempre. Define una ventana de responsabilidad, los plazos de subsanación por gravedad y quién paga: sin ella, el coste del 40% recae entero sobre ti, meses después de firmar la recepción.
• Qué puede ejecutar la pipeline. Qué automatismos tienen acceso a las credenciales de producción, cuáles pueden abrir e integrar modificaciones por su cuenta, y qué requiere una acción humana. Si la automatización puede mover código hasta producción sin una firma, el perímetro de seguridad no es el que crees.
• Dónde acaba tu código. Qué herramientas de IA se usan sobre tu repositorio, si el código alimenta el entrenamiento de terceros y cómo se gestionan los secretos en el entorno de desarrollo. Son las mismas preguntas que hay que hacerle a cualquier proveedor SaaS — las hemos recogido aquí.

Ninguna de estas cláusulas prohíbe la IA. Todas mueven el riesgo a donde puede gestionarse: al proceso del proveedor, antes de la entrega, en vez de a tu cuenta de resultados después.

Nuestra posición, dicha desde dentro

Nosotros escribimos el código con IA cada día, en esta web y en nuestros productos — y precisamente por eso nuestro proceso se parece mucho a la lista de aquí arriba: cada cambio supera una serie de comprobaciones en verde, una revisión humana antes de la publicación y automatismos con permisos explícitos y acotados, sin atajos en las rutas críticas. No es prudencia de folleto: es la infraestructura que convierte la velocidad de la IA en una ventaja que perdura, en lugar de una deuda de seguridad que habrá que saldar más tarde. Un proveedor que ya ha tenido que construir estos controles te lo dice; quien solo vende la demo, todavía no.

La decisión que hay que tomar

No es «IA sí o IA no». Es una sola pregunta, y hay que hacerla antes de firmar: ¿cuáles de estas cláusulas están ya en el contrato que estás a punto de aceptar? Si la respuesta es ninguna, el problema no es la herramienta que usa tu proveedor — es que el riesgo de seguridad, tal como están las cosas, es enteramente tuyo y no está escrito en ninguna parte.

Si estás evaluando a un proveedor o estás a punto de llevar la IA dentro de tu desarrollo, los controles que enganchamos a cada flujo — incluidos los de cumplimiento — están descritos en nuestro overlay de conformidad. Y para entender por qué departamento conviene empezar, con qué controles alrededor, hemos convertido el primer paso en una valoración de autoservicio y gratuita: haz la valoración de preparación para la IA — y luego, si tiene sentido, hablamos.

Este artículo tiene una finalidad orientativa. Las cifras citadas provienen de estudios académicos independientes, realizados sobre herramientas y periodos específicos: deben leerse como indicaciones de dirección sobre el tipo de riesgo, no como una medida del código que recibirás. El reparto por lenguaje del estudio de 2022 lo recogen síntesis secundarias y no está verificado sobre el documento original. Este texto no constituye asesoramiento legal ni una evaluación de seguridad: cada contrato debe valorarse en el contexto de la empresa concreta.