Un estudio reciente del sector reveló que los equipos que despliegan código generado por IA a gran escala registran tasas de fallos en producción notablemente más altas y picos inesperados en el gasto en la nube. Para las empresas europeas que ya navegan entre las obligaciones de NIS2 y DORA, ese hallazgo no es una preocupación abstracta: se traduce directamente en requisitos de gestión de riesgos TIC que los reguladores esperan que puedas demostrar, documentar y auditar. La pregunta no es si tus equipos utilizan herramientas de codificación con IA, porque casi con toda seguridad lo hacen. La pregunta es si tu gobernanza mantiene el ritmo con el resultado.

Los riesgos de la generación de código con IA son fáciles de subestimar porque las herramientas son genuinamente impresionantes a nivel superficial. Un desarrollador obtiene una función funcional en segundos, las pruebas pasan en local y el PR parece limpio. Lo que el modelo no puede decirte es si esa función introduce una sutil condición de carrera bajo carga, filtra una credencial a través de un log o incorpora una dependencia con un CVE conocido que tu escáner aún no ha catalogado. La brecha entre “funciona en staging” y “es seguro en producción” es exactamente donde se concentran los fallos.

El ángulo del gasto en la nube se debate menos, pero es igualmente real. Los LLM tienden a generar código correcto pero sin conciencia de costes: bucles sobredimensionados, llamadas a API redundantes y patrones de almacenamiento que se disparan con el tráfico real. Los equipos que despliegan rápido con asistencia de IA y revisan lentamente para optimizar la eficiencia acaban descubriendo la factura antes de descubrir el problema de arquitectura.

Por qué NIS2 y DORA convierten esto en un problema de gobernanza, no solo de calidad

NIS2 exige que las entidades cubiertas implementen medidas proporcionales al riesgo que plantean su cadena de suministro TIC y sus prácticas de desarrollo. DORA, aplicable a las entidades financieras y sus proveedores TIC críticos, va más lejos: exige marcos documentados de gestión de riesgos TIC, clasificación de incidentes y pruebas de resiliencia. El riesgo empresarial de las herramientas de codificación con IA encaja de lleno en ambos marcos, porque el modelo que genera tu código es, en la práctica, un insumo de terceros en tu cadena de suministro de software.

Los reguladores aún no han emitido directrices que nombren herramientas LLM específicas, pero la obligación ya está en el texto. Si un incidente en producción se remonta a código generado por IA que eludió tus controles habituales de revisión, la pregunta de una autoridad supervisora de NIS2 o de una auditoría DORA será: ¿qué controles tenías en vigor y los seguiste? “El desarrollador usó Copilot” no es una respuesta válida a esa pregunta.

El modelo genera código más rápido de lo que tu proceso de revisión fue diseñado para gestionar. Una gobernanza que no contempla esa brecha de velocidad es una gobernanza que fallará bajo auditoría.

Los modos de fallo concretos que vale la pena mapear

Vulnerabilidades de seguridad en código generado por LLM

La investigación académica y del sector muestra de forma consistente que los LLM reproducen patrones inseguros de sus datos de entrenamiento. Inyección SQL, validación incorrecta de entradas, secretos codificados en duro y deserialización insegura aparecen en el output generado por IA, con frecuencia en código que parece idiomático y bien estructurado. El riesgo se agrava porque los desarrolladores que revisan código generado por IA tienden a leerlo como leerían el suyo propio: buscando errores lógicos en lugar de antipatrones de seguridad.

El análisis estático y las herramientas SAST detectan un subconjunto de estos problemas, pero no todos. Los modelos entrenados en repositorios públicos han procesado millones de ejemplos de código que pasó la CI y aun así contenía vulnerabilidades. Tu escáner es tan bueno como su conjunto de reglas, y el código generado por IA puede introducir patrones para los que ese conjunto de reglas no fue escrito.

Exposición a dependencias y a la cadena de suministro

Las herramientas de codificación con IA sugieren imports y llamadas a paquetes basándose en datos de entrenamiento con una fecha de corte. Un modelo puede recomendar con total confianza una versión de librería que era actual hace dieciocho meses y que desde entonces ha acumulado tres divulgaciones de CVE críticos. A menos que tu pipeline aplique una política de dependencias en el momento de la sugerencia y no solo en el momento de la compilación, estás confiando en que el desarrollador detecte la diferencia.

Fallos de código generado por IA bajo carga en producción

Los entornos de staging rara vez replican con precisión los patrones de tráfico, los niveles de concurrencia o los volúmenes de datos de producción. Las implementaciones generadas por IA que manejan un conjunto de datos de prueba de unos pocos miles de registros pueden exhibir un comportamiento O(n²) a escala de producción, o mantener conexiones de base de datos abiertas de formas que agotan los límites del pool. Estos fallos suelen aparecer horas o días después del despliegue, lo que dificulta el análisis de causa raíz y alarga el tiempo medio de recuperación.

Un marco de control práctico para equipos de DevOps

El objetivo no es prohibir las herramientas de codificación con IA. Ese tren ya ha salido y las ganancias de productividad son reales. El objetivo es insertar los controles correctos en los puntos adecuados para que la velocidad impulsada por IA no supere tu postura de riesgo.

  • Filtra por seguridad, no solo por funcionalidad: exige que SAST, el escaneo de dependencias y la detección de secretos pasen antes de que cualquier PR asistido por IA pueda fusionarse. Trátalos como verificaciones bloqueantes, no como advertencias orientativas.
  • Aplica el anclaje de dependencias y la trazabilidad: bloquea las dependencias transitivas y ejecuta análisis de composición de software contra un feed de vulnerabilidades actualizado y curado. No te fíes del conocimiento del modelo sobre versiones de paquetes.
  • Añade un paso de revisión de rendimiento para el código generado por IA en rutas críticas: cualquier función que gestione enrutamiento de solicitudes, consultas a bases de datos o transformación de datos merece una revisión explícita de complejidad algorítmica y uso de recursos, no solo de corrección.
  • Registra y clasifica los commits asistidos por IA: etiqueta los PRs que sean sustancialmente generados por IA. Esto te proporciona los datos para correlacionar patrones de incidentes con el output de IA a lo largo del tiempo, que es exactamente el tipo de evidencia que pedirá una auditoría DORA.
  • Ejecuta pruebas de caos y de carga antes de promover a producción: si tu pipeline no las incluye ya, el desarrollo acelerado por IA las convierte en obligatorias. Los fallos que solo aparecen bajo carga real deben encontrarse en un entorno controlado.

El papel de tu infraestructura en la nube en este contexto

La capa de infraestructura importa aquí por dos razones. En primer lugar, si tu proveedor de nube está sujeto a una jurisdicción extranjera, tus datos de incidentes, tus logs de auditoría y tu telemetría de código pueden ser accesibles para autoridades fuera de la UE. En el marco de Schrems II y la soberanía digital, ese es un riesgo que tus equipos legal y de cumplimiento deben haber evaluado de forma explícita, no dado por supuesto.

En segundo lugar, las anomalías de coste que puede introducir el código generado por IA son mucho más fáciles de detectar y contener en una infraestructura donde tienes observabilidad completa y transparencia en la facturación. Los picos de gasto inesperados en entornos donde la asignación de costes es opaca o donde la capacidad reservada se agrupa en niveles de precios poco transparentes son más difíciles de detectar antes de que se vuelvan significativos.

Convertir la obligación de cumplimiento en disciplina operativa

NIS2 y DORA crean un requisito de documentación que la mayoría de los equipos considera oneroso. La perspectiva más útil es que crean un incentivo para construir los controles que deberías haber construido de todos modos. Un marco maduro de gestión de riesgos TIC que cubra el riesgo empresarial de las herramientas de codificación con IA, realice un seguimiento de los fallos de código generado por IA por categoría y pueda demostrar los plazos de remediación no solo está preparado para la auditoría: es una organización de ingeniería que se recupera más rápido.

Los equipos que tendrán dificultades son los que tratan la generación de código con IA como una decisión puramente individual del desarrollador, sin ninguna capa de gobernanza organizativa. A la velocidad que permiten estas herramientas, el juicio individual no es un control escalable. La revisión sistemática, la aplicación automatizada y la responsabilidad documentada sí lo son.

El desarrollo acelerado por IA ya está aquí, y el argumento de productividad es lo suficientemente sólido como para que resistirlo no sea una estrategia viable para equipos de infraestructura competitivos. Gestionarlo correctamente, con controles proporcionales al riesgo y documentación proporcional a tus obligaciones regulatorias, es a la vez alcanzable y necesario. El estudio que vincula el código generado por IA con tasas de fallos más altas es un dato que merece tomarse en serio, no como razón para frenar, sino como razón para gobernar con más deliberación.